Learning to Deal with Change and the Unknowns

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

As organizations rush to put in firewalls, antivirus software, intrusion detection, intrusion prevention and a mile-long list of other technology solutions, they are failing to recognize that there are people and process issues that must be addressed.

Unless they are addressed, the defense in-depth strategy is seriously undermined. Two areas that are routinely skipped are termed ‘change management’ and ‘configuration management’ in the Information Technology Infrastructure Library (ITIL). It’s important to review these two often overlooked areas.

For the sake of talking about change management here, let’s consider a change to be a modification of state. If there is a variance in state, then a change has occurred. These changes can be both from proactive and reactive sources, as well as from authorized and unauthorized parties. These kinds of changes might include software updates from vendors, patches to operating systems and new code from the development group.

Now, not all changes are bad, but all changes do carry the risk of unknown outcomes due to the tremendous amount of vectors that affect actual implementation results. That means it is wise to scrutinize changes prior to their going into production to determine impacts in your unique environment.

A critical note is that change management isn’t about stopping change, it’s about controlling change to increase change success rates, reduce risk, enhance availability and improve security. Security is affected, you ask? Yes, it is, and there are several reasons for this.

First, as complexity increases and changes are introduced, then the possibility for mistakes to be made also increases. All one need do is look to the current IT literature to hear all the horror stories over software patches undoing bug fixes, opening security holes, etc. Due to all of the variables that exist in a modern system, the only way to check for impacts in a given environment is to test. Always remember that as the rate of errors increases, so does the likelihood of security flaws. So, it is very important to test security, as well as functionality prior to deploying a change into production.

Second, if changes are uncontrolled, then it is far more difficult to determine legitimate changes from security breaches. These breaches could be from hackers or even people making changes on systems that they should not have access to, but due to multiple control failures, actually do have access to.

The point is that if everything is in a state of flux, it is far harder to tell what is going on from an internal accountability perspective, let alone a security breach.

Configuration Management

Some people confuse change and configuration management. They are, in fact, two different topics.

While change management is concerned about controlling changes made to systems, configuration management, on the other hand, is concerned with controlling the various builds that are in use.

Each unique software and hardware build — meaning the sum of software, hardware and configuration components — is a configuration item (CI), as are all of the components. They are tracked in the Configuration Management Database (CMDB).

The goal of configuration management is to be aware of all the builds in use so that the data can be used in other areas, such as problem management, release management and incident management processes. It is very important that all key information about the systems and components be properly identified via a well-thought-out taxonomy and that the data in each CI be accurate.

Why does this matter to security?

Again, it is about tracking changes. Presumably, all builds in the CMDB are known good builds. Any deviation detected in the production system from the known build should be investigated. If it does not tie out to an authorized work order, then there has been a control failure. Either an internal party or an external party has made unauthorized changes.

Also, should there be a security breach or even a disaster, the actions necessary to recover the systems will rely on having accurate CI data to minimize downtime and expedite recovery.

Good change and configuration management processes are absolutely necessary to manage risks and enhance security. They also are process areas that will benefit operations, as well. Improvements in these areas can benefit IT operations, IT security and the business stakeholders.