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.