The organization must implement and abide by a formal policy, process, and procedures for managing configurations and changes to IT assets.

Control Type: Administrative

Control Function: Preventive

One of the most common mistakes organizations make in their IT environments is treating everything as a one-and-done deal. They simply purchase devices, provision them, deploy them, and call it good. There is a large amount of risk that comes with this practice, as the organization is bound to lose substantial visibility into its assets without any plans for documenting and tracking the specific assets. Measures like monitoring and logging, system refreshes, and health/performance checkups can help mitigate this risk from a technical standpoint. But before all of these, the organization should start by implementing a comprehensive configuration and change management program.

In Stage 1 of this framework, asset inventories were created of hardware, software, cloud services, etc. A configuration and change management program takes things a step further by thoroughly documenting how the assets are configured, and when and why changes are made to them. Configuration management involves documenting approved settings, customizations, software installations, and security measures for each system or class of systems. Change management is the process for receiving, reviewing, approving, and documenting desired changes to the baseline states produced by configuration management. The two processes combined are often referred to simply as CM. Larger organizations often separate configuration and change management into separate functions, each with a dedicated department. Small and medium-sized organizations often combine them into one process, often with a small group of management personnel driving it. A combined team of configuration and change management authorities is usually referred to as a CMB (CM Board) for combined functions, while a dedicated change management team is often referred to as a CCB (Change Control Board).

Baselining is the first step in CM. Baselines provide a clear map of the systems in their raw, freshly provisioned state. Baselines should explain the programs installed, specific Windows settings/customizations added, and the security controls implemented. This mapping should be as granular as possible, with business purpose, dependencies, and rationale clearly articulated. Organizations should be able to look at their asset inventory and clearly articulate what each device needs to have, what it needs to be able to do, and how it needs to be organized.

In a standard enterprise environment, devices are organized into classes rather than unique devices. For example, twenty laptops purchased for the finance department will all need to have the exact same features and functions available. On the other hand, ten laptops for the quality assurance department will need some of the same features, but also a ton of different ones. Thus, each department needs its own corresponding device baseline. However, each unique baseline should still stem from one master baseline for the entire organization. This should be a basic template that suits the largest population of devices in the organization, meaning it contains programs, settings, and customizations that need to apply to every device in the organization regardless of department. Then, the master baseline can be used to create a sub-baseline for each unique department, with all that department’s requirements and nuances applied.

All necessary parties should formally agree on the baseline before it is approved; this may include IT staff, department managers, and end users. The baseline state needs to be scrutinized to ensure that it falls within the bounds of the organization’s risk appetite. This may involve performing cost-benefit and risk analyses on the baseline proposal. Once agreed upon, baselines should be captured and stored so that they can be deployed to end devices that require the specific class of configuration. This is often done by capturing and storing the baseline configuration on a local server, such as a PXE imaging server or cloud service.

To keep all devices within the bounds of the organization’s risk appetite, they must be tracked continuously. Part of this process involves documenting and reviewing all deviations from the baseline that occur over time. Deviations from baselines may include new updates and patches, upgrades to new OS versions, new applications added, and adjustments to settings/customizations. Deviations can also be unintentional and even malicious, such as insecure features added by end users, intrusions by adversaries, and failed updates. Malicious deviations should be met with automatic rejection. At that point, the deviations become incidents, and the CMB/CCB needs to pass the situation over to the incident response team. If there was a well-meaning rationale for the attempted deviation from a real employee, the CMB/CCB can hear their case later on and try to come to an understanding of the issue.

Similar to deviations are exceptions. Sometimes, pre-implemented security controls end up interfering with legitimate business workflows. In such cases, departments/employees may request an exception to the security control. If the exception request is approved, the specific user devices are unenrolled from the control or feature. Exceptions need a great deal of scrutiny, as they involve removing an asset from a control or functionality that was previously determined to be necessary. If the requested exception involves removing a control that was deemed necessary for the organization’s risk appetite, the CMB/CCB needs to evaluate compensating control opportunities that can address the original risk from a different angle while allowing the desired functionality to be realized.

Mature information security programs often use platforms to track and alert on deviations, regardless of how small they are. The output from these detections then serves as input for the change management board to review. The change management board should have a deep understanding of the baseline states and each configuration’s rationale. However, they should also understand the nuances of business operations. It would be no good for anyone if the change management board took baselines as absolute and shot down any change request simply because it goes against the baseline. There may be legitimate business justification for new software or system modifications. The change management board should hear the justifications for such a change from the originating body, whether it be a department or an individual user. This information should then be weighed when making the approval decision. It is a good idea to have a formal process for requesting changes so that the CMB/CCB is not constantly bombarded on all platforms by employees throwing out every last desired change they want to see. The organization should publish an official Request for Change (RFC) template that employees must use to request changes. A typical RFC should include input for the following elements:

  • A description of the desired change.
  • An explanation of the expected impact on the business as a whole.
  • An assessment of the risk(s) that may be involved with making the change.
  • A rollback plan to be used if the change fails.
  • Identities of specific individuals/groups that will be involved with the change.
  • A proposed schedule for implementing the change.
  • The systems and services that will be affected by the change.

RFCs can then be received by the CMB/CCB via an official avenue such as a group email inbox or ticketing system. The RFC will inform the initial change assessment, and the CMB/CCB can then request further contact with the change request originator for deeper insight.

Every decision made by the CM authority needs to be documented with a description of the change, rationale, and affected parties included. Before an approved change is fully codified, testing needs to be performed to ensure the desired functionality is present and that there are no undesired effects. Typically, the actual testing is assigned to the IT/cybersecurity staff and is performed in an isolated sandbox environment on a clean copy of the original baseline. The results of tests should then be immediately communicated back to the CMB/CCB. If the change has no major effects on functionality, the CMB/CCB can proceed with final approval. If undesired effects are found, then the CMB/CCB needs to investigate alternate avenues for implementing the change. Sometimes, none will be found, and the CMB/CCB will have to ultimately reject the change request.

Once changes have been approved and introduced into the environment, the organization needs to capture the changes in the next iteration of the baseline. For example, an organization’s employees from all departments are requesting a professional ChatGPT license so that they can automate busy work and focus more on core tasks. The change management board hears their rationale for the request, researches the costs and effects of the potential change, and eventually decides to purchase and deploy organization-wide ChatGPT licenses. Therefore, when a new baseline is made for the next version of Windows, the baseline should include the pre-deployed ChatGPT desktop app.

For a CM process to work as intended, the entire workplace needs to know of its presence and how to interact with it. Some organizations may only accept formal change requests from department managers, while others may allow a more democratic change process, allowing individual employees to submit requests or suggestions. The exact model depends on how often the CM authority meets, and how cumbersome implementing changes is for the IT environment.

To ensure that the change management process and procedures are clearly understood by the entire organization, a configuration and change management policy should be drafted and published. Such a policy should typically include:

  • An overview of the IT configuration process, such as how baselines are created, how they are assigned, and when new iterations are made.
  • The composition of the CMB/CCB, including roles and responsibilities, contact information, meeting frequency, etc.
  • An explanation of the change process: how change requests flow to the CMB/CCB, how approval is made, and how approved changes are deployed.
  • Requirements for requesting changes/exceptions.
  • Instructions on how to submit change/exception requests to the CMB/CCB.
  • An overview of how assets are scanned for compliance with baseline states.
  • An overview of how the organization will respond to uncovered deviations.
  • How baseline requirements are enforced, and what responsibilities end users have to uphold them.