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!]

PCI – Going Beyond the Standard: Part 12, Change Control

This may be the 12th post in my series, but I cannot stress the importance of good change control enough. I have said [too] many times that maintaining a good security posture is difficult enough, but to make things easier for bad guys from the INSIDE is just plain dumb.

If nothing in your environment changes, the only way risk can increase is by a change in the external threat landscape. Your Vulnerability Management processes should have this mostly covered.

Like almost every other process in security, change control should start with robust policy and procedure, and a well designed and up-to-date, Asset Management system. If you have not only a complete listing of your physical assets, but your business processes, data stores, system and data ownership, personnel & skill-sets, regulatory dependencies, and system criticality mapped out, you have the foundation for very effective change management. Difficult to create?; yes, difficult to maintain?; only if you don’t do it properly.

Speaking of change management, if you don’t have a change control board, get one. It does not matter what you call it, but it should contain enough of the right people to ensure that both the IT and the business side of the organisation can have full insight into the risk management process, and the upcoming changes to the environment, AND to make sure these changes are in-line with the business’s goals.

Good change control starts with a policy, is clearly explained in procedures, and is central to ANY changes that can affect the continued security of your information assets. From patching, to firewall rules, to application upgrades, to server on-boarding, everything must be reviewed and approved by the APPROPRIATE level of authorisation channel. Change control can never be seen as a bottle-neck or it will be bypassed, so unless you are able to rank your changes into distinct approval channels you will end up doing too much, or too little, neither of which is sustainable.

As far as PCI is concerned, you could email your change requests to whomever is responsible, and maintain the list on a spreadsheet. For small organisations this may be appropriate, but of all things to put online, standardise, and at least partial automate, change control is way up at the top of the list. Right next to your Asset Management System itself in fact. Or even better, PART of it!

Here’s how I think Change Control should be done;

  1. The ‘Paperwork’: You will need a –

 i.   Change Control Policy – Keep it simple, even something like; “All changes to IT systems (including, but not limited platforms, application, and data) will be subject to an appropriate review and approval process as determined by the highest data classification.”, is better than most organisations have in place.

ii.  Data Classification Policy – Without a data classification policy there is no way to determine the correct level of review and authorisation required. Patching will not go to your review board, but major application upgrades certainly will. Only appropriate processes are sustainable.

iii. Change Control Procedure – Specific and easy to follow instructions enabling EVERYONE in the organisation to request a change in a uniform manner.

  1. Change Control Board – It does not matter what you call this, Change Control Board (CCB), Change Advisory Board (CAB) or Rumpelstiltskin, the charter is the same; Bring to bear all relevant resources from the business and IT sides (and SMEs if appropriate) to review and approve all changes that meet the established criteria. This should include relevant system / data / process owners where appropriate.
    o
  2. Integrated Asset Management System (AMS) – Without an integrated AMS you lose the ability to add a second layer of criticality rating to your change requests (Data Classification being your first). A proper entry into the asset register will include process dependencies, regulatory implications, max. data classification, and a system ‘importance’ rank. When these assets are available to the change control requester as a drop-down list, the full impact of the requested change is immediately apparent, and the correct level of review and approval automatically assigned. If each asset also had the system / data / process owners assigned, the review board can be built and perhaps even alerted automatically.
    o
  3. Change Closure Checklist – Too often changes are closed before the correct testing is performed, but again, what testing and approval is appropriate should be tied to the importance of the change. Vulnerability scan results, penetration testing results, user testing input, and so on are just a sample of the things that could / should be done before any change is closed.
    o
  4. Periodic Review Against Management Metrics – The change was made for the benefit of the business in some fashion, right? How do you measure success? The answer of course is; “That depends.”, but a specific date / time should be set to review the changes made to ensure that all success criteria are met. This should not be complicated or labour intensive, ever, but the review process is the only way to feed back efficiency improvements into the risk management process. Nothing is perfect.

The above list assumes you have included the basic information required to request a change (Documentation of Impact, Back-Out Procedures etc.), but the PCI minimums are rarely sufficient for an organisation that really cares about this stuff. Again, you don’t want the request process to be ridiculously long or complex, but if you don’t provide enough information up-front, you cannot perform the correct review process, nor can you measure success of the results.

Finally, if your change control process is not owned by your Governance function, you will never be able to bring the correct business oversight to bear. IT and IT Security are only ever enablers, it’s the business side that needs to own the goals.

Another crazy long blog, apologies, but change control is just that important.

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!]