The record-keeping that is the backbone of a good CM/CC system has another great payoff waiting for you, in the event that disaster strikes and you have to reload a bare-iron backup processing facility (or virgin VMs in the cloud) before you can get back into normal business operations. Those CM/CC records give you a known configuration baseline to use to verify that the backup images you loaded are configured, in all details, the way your management processes said they should be—the way your live production systems had been configured just before disaster struck.
Your organization should start by developing a configuration management plan if it does not have one in operation already. A configuration management (CM) plan defines how an organization will manage the configuration of its hardware and software assets. It defines details such as the roles, responsibilities, policies, and procedures that are applicable. A configuration control board (CCB), which ITIL guidance refers to as a change advisory board (CAB), will manage the CM plan. As the CCB is comprised of qualified stakeholders from the organization, they will often be the authors, editors, reviewers, and approvers of the organization's configuration policies and procedures. They will also be tasked with applying and enforcing the CM plan and helping technical administrators adhere to and understand the CM plan. Most importantly, the CCB controls and approves changes throughout the lifecycle of the IT systems, which is why they may also be known as the change control board.
Configuration management and change control focus on the life history of individual configuration items and on sets of configuration items. A configuration item (CI) is one discrete part of an IT system, like a piece of hardware or software, that has configurable settings or parameters and should be under formal configuration control. A baseline configuration is a defined, desired set of configurations for a specific CI (or combine multiple CIs into an IT system), which has been formally reviewed and approved. A baseline configuration is valid for a given point in time and may need to be adjusted over time as software or hardware versions change, new vulnerabilities are discovered, or different usage and needs dictate the need for change. When the baseline configuration needs to change, it should be done only through predefined change control procedures. Deciding what a CI should be is a matter of perspective. Consider as an example that a modern platform system such as Microsoft Office Professional might contain between 5,000 to 10,000 individual files, or about 2 GB of code, configuration data, settings, forms, and templates. To the Microsoft Office developer team, each of those files is a CI. To your company's systems administrators who download licensed distribution kits, configure them, and install them onto dozens or hundreds (or more!) of endpoint systems throughout your company, they may see each new patch version of Office as one CI or see it as thousands of CIs (all those files and all of the patches to them). Fortunately, Microsoft (and many other platform product vendors) provide some pretty extensive maintenance management tools to help you manage their products as deployed systems, rather than as deployed swarms of a huge and unwieldy number of files.
Execute Change Management Process
As the systems security analyst and administrator, your duties may combine or overlap with those of other systems administrators who actually install, manage, and maintain the operating systems, applications, platforms, web pages, and datasets that make up your organization's IT architecture. Without their extensive training and significant experience with those products, it's probably unrealistic for you to try to manage both the security configuration and the product configuration for each installed product. Let's look at a few of the methods and tools used in establishing and managing both kinds of configurations.
Manual configuration is the easiest to understand conceptually—it involves the administrator viewing and changing the configuration settings directly, either by editing a configuration settings data file or by using something like the Windows Registry Editor (regedit). Registry edits (or their equivalents in other operating systems environments) can also be done using batch or script files. Either way, this is a fine-grained, detailed, step-by-step process, which can be useful if you're stepping through various settings to diagnose a problem or as part of an incremental hardening process.
Configuration scanning tools can read the stored data structures used by the operating system and installed programs, extract information from those settings, and in some cases test some of those configuration settings for validity. The resulting list of all of these settings is sometimes called a configuration enumeration. NIST maintains a set of Common Configuration Enumerations that have been associated with security issues that are tracked in the National Vulnerability Database (NVD), and more recent versions of configuration scanning tools can help you detect similarities between a CCE and your system's current configuration. The CCE database can then provide you with insights and recommendations, drawn from best practices in the field, as to changes you should make in your systems to improve their overall security.
In the same breath, NIST and others often provide, specify, or recommend systems hardening information as it pertains to a given configuration enumeration. As a result, some professionals refer to the total bundle (the enumerated configuration and its related hardening information) as an enumeration or as a set of hardening standards for a particular configuration. Since the purpose of having the enumerated configurations in the first place is to collate hardening recommendations with specific configuration items and settings, this is to be expected. If in doubt as to what is meant or included, ask for clarification.
Another useful tool is a configuration change detection tool. It is different than a configuration scanner tool in that instead of asking the IT asset “Are you configured correctly?” it asks, “Did your configuration change?” It takes a snapshot of a given system's configurations, presumably after it was configured correctly and securely. Then, if any of the configurations are changed, it sends an alert to one or more relevant security stakeholders. Vendors are adding additional features and capabilities to both scanner tools and change detection tools, blurring the line between the two. Some tools now do both.
When you want to control how your security tools share data, you can use the Security Content Automation Protocol (SCAP). SCAP is a way for security tools to share data. It is an XML-based protocol that has many subcomponents called specifications, including one for CCE. It is a taxonomy for describing configuration requirements, which is essential because of the sheer number of configurations and their nuanced differences.
CCEs are written for, and are grouped by, specific IT products or technology types. The vulnerability equivalent to CCE is the Common Vulnerabilities and Exposures (CVE). CVE is more widely adopted than CCE because the vulnerability scanner market is larger and more mature than the configuration scanner market. In fact, some major vulnerability scanning tool vendors have added CCE (configuration) scanning to their traditional CVE (vulnerability) capabilities. Learn more about CCEs at https://nvd.nist.gov/config/cce/index.
In addition to other standards and guides, vendors (especially OS vendors) typically publish secure build outlines for their own products and often make tools available for provisioning and monitoring configurations.
Identify Security Impact
Any proposed change, even applying a patch kit or bug fix to alleviate a security problem, may inadvertently introduce a new vulnerability or a new risk into your systems and your business operations. Change packages should be examined to identify any potential changes to your operational procedures for getting work done with the affected systems and assets. Descriptions of the changes, and in particular the issues or vulnerabilities that are acknowledged