Change Control

Change Control: Break the Vicious Cycle

Have you ever tried to fill a colander with water? Of course not, that would be ridiculous given that it’s full of holes. So why would you try to implement a security program without ensuring that whatever you fix does not get broken behind you?

Do you give your IT administrators permission to change the setting on your personal phone? Again, of course not, so why would you allow them to make significant changes to corporate assets without proper oversight?

While these analogies are flippant and geared toward emphasising my point, I would not be writing this blog if the issue of change control was not an enormously important one. At best, poor change control can cause additional unnecessary work, at worst you could be out of business. It’s bad enough that bad guys want to break in, most organisations I have seen are making it easier for them from the inside.

The definition of change control is; “…a systematic approach to managing all changes made to a product or system.“, and it’s purpose is “…to ensure that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted and that resources are used efficiently.” Sounds fair, right? No disruption? Efficient? Are these not good things?

The biggest issue is that change control requires not only planning, but extra effort. You have to fill out a form, send an email, or log into a GUI of some sort, all of which may take longer than making the change in the first place. Change control is time-consuming and can be seen as a bottleneck, both of which are no-nos in the rapid evolution towards more and more function. But what would you rather have; 1) an insecure service quickly, or 2) a secure service a very short time later?

Unfortunately, given that change control is a primary function of governance, few organisations have the oversight to implement change control well. so how can organisation perform this most critical of processes?

First, it has to be appropriate. There is little point in a 5 person company buying a change control software, but larger organisations should not be using email and spreadsheets. As long as the right people are involved in making the change decisions, this process can be as formal or informal as is sustainable. If this is ever seen as a burden, it will be either circumvented, or ignored altogether.

Often overlooked, but critical to change control success, are a few pre-requisites…

Change Control Pre-Requisites:

  1. Ensure that the asset register contains not only physical devices, but applications, CotS software, data stores, location, unique skill-sets etc.
  2. Assign business criticality and maximum data classification to all assets;
  3. Assign ownership to all assets;
  4. Map all assets to the business processes they support (note: these maps becomes assets in and of themselves); and
  5. Ensure that the change request form includes a list of the affected assets.

Change Control Form:

Every change request must, at a minimum, include these things.

  1. List of affected systems;
  2. Details related to affected users (if applicable);
  3. Criticality of change request;
  4. Indication of additional risk;
  5. Success criteria / test plan;
  6. Back-out or fix-forward plan; and
  7. Appropriate authorisation.

By mapping the affected asset to their corresponding business processes, their owners, and both their criticality and maximum data classification, you can automatically bring the right decision maker to bear to authorise the change.

Too often the business owners have little to no insight to technology changes, when in reality, they are the only ones who should be authorising the change. IT and IS are, and have always been, business enablers, nothing more. First and foremost, change control need to reflect the goals of the business. In the absence of governance, the above minimums are about the only way to see that this happens.

Of course, if you also link change control to your ticketing system and incident response processes you would have the Holy Grail, but baby steps…

[If you liked this article, please share! Want more like it, subscribe!]

Governance & Change Control

Security Core Concept 4: Governance & Change Control

You are probably wondering why I have taken a single aspect of the security program; change control, and raised it to the importance of a Core Concept. You are then probably wondering why I placed it under Governance, and not just an ISMS.

If you’re NOT wondering these things, I suspect you are new to security, or a friend of mine who’s reading this just to be nice.

However, if you accept my interpretation of what Governance is, it may make a little more sense; “Governance is where the IT and Business sides have appropriate conversations.” It’s a communication facilitator, where historically the business side rules and the IT side must do as it’s told, often without question.

You must also accept the concept of cybersecurity as a business enabler, and NOT a roadblock to profit or innovation. As I rather facetiously put it in The 6 Security Core Concepts;

Business: “I want this new functionality.”;

Security:“Sure, but do it this way.”

The business side is responsible for maintaining business growth / profit / market standing and a host of other objectives.This is far from easy, so they will do almost anything to meet those goals. It is up to IT and Security to encourage this innovation and out-of-the-box thinking, but do it in such a way as to ensure that the IT and security needs are built in from the beginning.

In a company with a well run Governance program, any ideas the business have will be run by the Governance Committee (or equivalent), which will include at least one, or more likely several members of the IT / Security teams (security, infrastructure, development etc.). The ideas will be discussed, input accepted EQUALLY from all participants, and a specific risk assessment report put together for senior leadership to review.The IT side’s input needs to include not only the risks, but the viability of the concept based on capital cost, resource allocation, outsourcing and so on.

That’s why they are enablers, because they are the ones who put the ideas into practical application. The greatest ideas in the world are useless if they stay on paper, and are potentially destructive if applied incorrectly.

Assuming I’ve made my point on Governance, and that you somewhat agree, I’ll move on to change control…

Change Control is defined by Wikipedia as; …”a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner.”

This needs no simplification, that’s EXACTLY what change control does …if it’s implemented properly. And that’s the issue in many organisations; the concept may be understood, but there are so many exceptions, and / or ways to circumvent the process, that you may as well not have change control at all.

Again, in The 6 Security Core Concepts I said; “If things don’t change, the only increase in security risk is from external sources. The threat landscape changes almost daily, why make things worse by screwing up internally?

That’s really what it boils down to; known, and acceptable change. If you’re following the Core Concept series, you have:

  1. Given Governance full responsibility and maybe some accountability for the institution and maintenance of the security program;
  2. Performed your Risk Assessment with the full knowledge and blessing from senior leadership;
  3. Made all appropriate adjustments to your processes and infrastructure based on the RA’s finding and accepted priorities, and
  4. Initiated the Check and Act portions of the ISMS function to ensure that the controls work, and are on their way to being optimised

So why would you now undo all of that work by changing something without the Governance committee’s blessing?

Change Control includes EVERYTHING that changes; systems, applications, data stores, patching, policies, procedures, new functionality, people …EVERYTHING.

Of course Governance can turn some changes into operational norms; patching for example. As long as the process for testing new patches, and rolling them out across the enterprise is appropriately formalised, the Governance committee does not have to discuss it.

But what about firewall rule-set changes? The business side is demanding the testing of some new functionality that involves “Turning off the firewalls for a couple of minutes.”? The answer is of course, no, or HELL no to be more precise, but who has the authority to tell the business that? Right, the Governance Committee.

The institution of a change control culture is painful and slow, as new processes will always meet with resistance. But this is one area where there is no room for half measures, you either do it (and make the negative consequences clear to all), or don’t bother starting.

Finally, I have not gone into any detail of who should actually be ON the Governance committee, and what its charter should be, but that’s because it varies too much between organisations of difference size, complexity, and function. As long as you have equal representation from the IT and business sides, the individuals themselves will make themselves obvious over time. A limited tenure is important though, or the committee may either stagnate, or be controlled by the most forceful individual.

Governance is the heart and soul of your security program, and change control it’s most potent weapon, neither can be ignored.

[If you liked this article, please share! Want more like it, subscribe!]