25. Configuration Management Overview
Configuration management is a process and discipline used to ensure that only authorized and validated changes are made to a system.
It is both a decision-making process and a set of control processes. The basic configuration management process includes identification, baselines, updates, and patches.
Main Components
Identification
Baseline identification of a system and its components, interfaces, and documentation.
Baseline
A security baseline is a minimum level of protection that can be used as a reference point. It helps ensure that updates to technology and architecture meet the minimum understood and acceptable security requirements.
Change Control
A process for requesting changes to a baseline and making changes to one or more components in that baseline. It includes review and approval for all changes, including updates and patches.
Verification and Audit
A regression and validation process used to verify that newly applied changes did not break anything in the system. An audit process checks that the current baseline matches the initial baseline plus all approved changes.
Inventory
Inventory means making a catalog or registry of all information assets the organization is aware of, whether they already exist or still need to be acquired.
This is the first step in asset management. It requires locating and identifying assets of interest, especially information assets.
You cannot protect what you do not know you have.
Keeping the inventory current with updates and patches is challenging. It is also difficult to identify every physical host and endpoint and gather data from all of them.
Baselines
A baseline is the total inventory of a system’s components, including hardware, software, data, administrative controls, documentation, and user instructions.
If controls are in place to reduce risks, the baseline can be used as a reference. Further comparisons and development are measured against it.
Baselines are also useful when protecting assets based on value. If assets are classified as high, medium, and low, separate baselines can be developed for each classification to provide the minimum required level of security.
Updates
Repairs, maintenance actions, and updates are frequently needed across system elements, from infrastructure to operating systems, application platforms, networks, and user interfaces.
These modifications must be acceptance tested to verify that newly installed or repaired functionality works as required.
They must also be regression tested to verify that the changes did not introduce other unexpected or incorrect behavior.
Ongoing security assessment and evaluation testing checks whether the same system that passed acceptance testing is still secure.
Patches
Patch management mainly applies to software and hardware devices that are regularly modified.
A patch is an update, upgrade, or modification to a system or component. Patches may be needed to address a vulnerability or improve functionality.
The challenge is maintaining all patches, since they may come at irregular intervals from many vendors. Some are critical and should be deployed quickly, while others may be less critical but still necessary because later patches may depend on them.
Some standards, such as PCI DSS, require organizations to deploy security patches within a certain time frame.
Patches should be tested before being rolled out across the organization. This is often difficult because many organizations do not have a testing environment that matches production exactly.
There is always a risk that not everything will be tested and that problems may appear in production but not in the test environment. To the extent possible, patches should be tested to ensure they will work correctly in production.
If a patch does not work or causes unacceptable effects, it may be necessary to roll back to a previous pre-patch state. The rollback criteria are usually documented in advance and performed automatically when those criteria are met.
Many vendors provide patch management solutions with automated or unattended updates. The risk of using unattended patching must be weighed against the risk of leaving systems unpatched. Unattended or automated patching may also cause unscheduled outages if production systems are taken offline or rebooted during the patch process.