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

In Security, Technology is Always the LAST Resort

The temptation to spend money to make something annoying just go away is almost irresistible. I’m not just talking about security now, this is a human condition. From get-rich-quick schemes, to diet pills, to online ‘dating’, we want instant gratification and / or results. Sadly we also expect the underlying cause of our issues to be miraculously fixed as part of the fee.

What do you mean “Get your fat arse off the couch and go for a walk!”, I paid you to make me thin!? There are no shortcuts to fitness, and there are no shortcuts in security.

None.

But with phrases like; ‘panacea’, ‘silver bullet’ and my personal favourite; ‘guaranteed hack-proof’, the cybersecurity industry is becoming one of the worst offenders. Money is clearly more important than good service to many security vendors, and to those expounding on their virtues.

And we’re letting them get away with it! Whether it’s because we’re lazy, don’t know the right questions to ask, or just don’t care, it’s immaterial. Vendors will keep making useless products and we’ll keep buying them if things don’t change. Vendors have sold F.U.D. for years and we’re bringing only a few of them to task (FireEye for example).

The more complicated vendors can make security appear, the easier it is to sell their technology. At least that’s how it seems. There’s really no escaping that security must be simple to be effective; forget big data, use baselines; forget microsegmentation, just segment properly, forget user and entity behavioural analytics, fix your access control. In fact, ignore every acronym in the Gartner ‘Top 10 Technologies for Information Security in 2016‘ and focus on the basics, I’ll almost guarantee they aren’t addressed appropriately.

From policies and procedures, to change control, to vulnerability management, to incident response, worry about the base processes. They are not only more effective than any new technology, they are a damned sight more sustainable, more scalable, and cheaper!

One of the universal truths in security is that you cannot fix a broken process with technology, you can only make a good process even better. Better in terms of accuracy, speed, effectiveness, efficiency, long-term cost, you name it, the underlying process had to have worked beforehand.

Take incident response (IR) for example. If you have top-notch plans, a well trained team, and robust vulnerability management, a technology that gives you earlier event warnings is of distinct value. As would technologies that; reduces false-positives; automatically quarantine infected machines; supplies greater forensic information up-front, and so on.

However, if your IR plans are crap, your team has no idea what to do, and your systems have not kept up with the threat landscape, no technology in the world will stop an event from becoming a business crippling disaster.

Be honest,  how many of you have:

  1. Firewalls but poor segmentation?
  2. Routers but no mapping of your business processes?
  3. Anti-Virus and no OS hardening?
  4. HSMs and no idea where all your data is?
  5. Centralised logging with no idea what ‘normal’ looks like?
  6. …and the list goes on.

How can you expect a new technology to help when you’ve haven’t optimised what you already have?

There are of course exceptions to every rule, and in this case the exception is to buy an Asset Management System. Everything else you do in security has your assets at the core. Do this well and everything else becomes much easier.

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

[For a little more information on technology purchases, this may help; Security Core Concept 2: Security Control Choice & Implementation]

PCI – Going Beyond the Standard: Part 6, Asset Management

The thing with security is that there is always more than 1 top priority, so the trick is not to choose which comes first, it’s to get them ALL assigned and moving forward at the same time. There are simply too many interdependencies, and you will only avoid the inevitable road-blocks or analysis paralysis if you plan accordingly.

Asset Management is one of those top priorities, and is at the core of everything else you will ever do in the development, maintenance, and continuous improvement of your security program.

If you do it properly that is.

Prior to v3.0 of the DSS, the requirement for asset management only went so far as an understanding of every system type, function, and number of them. Basically a spreadsheet to support the sample sizes and PCI validation efforts. But this undermines the entire assessment process itself, as the whole point of an assessment is that you are able to make educated judgment calls. Knowing that you have 20 Windows web servers tells you nothing about the potential impact of their loss, for example.

I think everyone’s heard the famous mis-quote by Peter Drucker; “If you can’t measure it, you can’t manage it.”, but how do you measure the value of an asset? The answer, like everything else in security, is simple. Not easy, and pretty much never done well, but it IS simple;

The value of each of your assets is directly related to the value of the data that flows through it.” and;

The value of your data is directly related to its importance to your business.

If you don’t know the above values you have a lot more problems than security.

It does not matter whether or not the ‘value’ is in financial or criticality terms, what matters is that every other security process must directly reflect its relative importance to your organisation. Does a web server have more importance to an e-commerce only merchant than it does to a plague/nest/whoop of lawyers (or whatever their collective noun is)? Maybe, maybe not. Would you expend far more effort protecting your intellectual property than you would your public web content? Of course you would, unless you’re irretrievably stupid (my favourite quote from A Fish Called Wanda).

But what IS an asset? It’s not just your servers, network devices and software, it’s your locations, your vendors, your business processes, and just as importantly, it’s your PEOPLE. Or more to the point, your people’s knowledge and skill-sets. There are often many single-points of failure in most organisations, and the one that’s most often overlooked is the human factor.

Unless you include ALL of these things, none of the following business processes will be anywhere near as effective, and perhaps not even possible:

  1. Risk Assessment – No point trying to examine your risks if you don’t know what those risks are related to.
  2. Gap Analysis & Security Control Acquisition – A logical follow on from a risk assessment, what are the gaps you have to fill? Can you use existing assets?
  3. Change Control – How can you give appropriate attention to change requests if you have no indication of regulatory relevance, maximum data classification, or the business criticality?
  4. Automated / Continuous Compliance Validation – If [for example] you don’t have a list of all the running services and listening ports against your systems, how can you hope to automate the detection of policy / compliance violations?
  5. Business Transformation – Try adjusting your business in the face of competition when you don’t know what you have and how it fits together.

Quite simply, Asset Management is too important and too core to security to give it real justice in a blog. Suffice to say, it is one of the easiest ways to centralise the required information to support every other process used to manage your security program. It is because Asset Management is so overlooked by PCI that everything else is seen as being so difficult.

This is one of the few areas where I actually recommend you look into implementing technology. An Asset Management System (AMS), especially if it forms the core of a Governance, Risk and Compliance tool. Surprisingly few do.

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