Learning to Deal with Change and the Unknowns: Page 2

(Page 2 of 2)

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.


Page 2 of 2

Previous Page
1 2
 





0 Comments (click to add your comment)
Comment and Contribute

 


(Maximum characters: 1200). You have characters left.