Configuration management consists of two concepts, often which are performed by the same group of employees:

Configuration management – this is the process that establishes the baseline of an information technology environment that includes a secure baseline.  

Change management – this is a process for requesting changes to the baseline.  

It applies to any and all changes made to a system, process, application, or security environment, or better yet, for purposes of the CISSP it applies to everything.  Let’s say you wanted to move the “register” button on your web application to somewhere else on the display page.  This might seem like a small change, but you would still be required to go through the change management process.  A change management board is the governing body that oversees the change activities and ensures that changes have the needed resources and are implemented correctly.  These are also known as change control boards (CCB).

Change management has four components:

  1. Decision – to make the change
    • Requires approvals from stakeholders
  2. Action – rolling out the change
  3. Confirmation – that the change was done correctly
    • Includes regression testing to provide assurance

Change controls – this is the fourth component, however it’s considered “present” throughout 1 – 3 as noted above.

  • Accounting/documentation process for changes
  • Identifies potentially affected components (scope)
    • Components are also called “configuration items” such as appliances and mobile code
    • Training, procedures, tacit knowledge, explicit knowledge, supporting documentation are all considered configuration items

Change package refers to the change itself along with all its documentation, typically tracked within a request for change (RFC).

The change management board (also CCB as noted above) – is a group of people who participate in regular meetings to review requests from the business side to:

  • Add components to the system
  • Grant an exception to a security control or set of controls
  • Grant access to a data set

The board can consist of experts from varying areas of the organization, to include:

  • Information technology groups
  • Senior management
  • Information security office
  • Users (business side)
  • Legal counsel
  • Accounting
  • HR

Information Technology Infrastructure Library (ITIL) version 4, calls change management Change Enablement. It has three change levels based on urgency:

  • Standard changes – low-risk and follow procedures,
  • Emergency changes – urgent (obviously)
  • Normal changes – neither of the other two levels.

Core Activities of CM

And yes, we have a mnemonic for each of the activities below since you may need to memorize the activity AND what happens in each activity. Since these are not phases they can be memorized in any order.

Change Initiation we’ll just use the “i” for the start of the mnemonic. Use the phrase “I Can’t Really Play Duffleboard”.

This includes a Request for Change (RFC), which results from suggestions, requests, help desk reports, corrective action plans, or other inputs.  The RFC typically addresses the following; bold letters are to help with mnemonic:

  • Identifying the Change requirements
  • Risk assessment
  • Priority for the change
  • Documentation of the RFC

Change Review and Approval (RA) includes the phrase “Richard Attenborough ‘EAS Rad!” (as in “he’s rad”):

  • Evaluating the RFC for completeness
  • Authorization path (who reviews/authorizes? Who is most impacted?)
  • Stakeholder reviews, resource identification and allocation
  • Resource allocation
  • Approvals or rejections
  • Documentation of approval or rejection

Implementation Evaluation includes the phrase “In England, STeVe dIED” (trying to keep it simple):

  • Scheduling the change
  • Testing it
  • Verifying rollback procedures
  • Implementing it
  • Evaluating it for proper and effective operation
  • Documenting the change in the production environment

If poor performance is noted during this category of activities, rollback plans should be looked at and should indicate if rollback should be performed or if a subsequent change should be requested.  The rollback plan would typically dictate this, but if a plan doesn’t exist, any future changes, including emergency changes, should be submitted through the change management process.

Deployment refers to controlled, inventoried, and managed movement between other environments such as Development to Test or Pre-production. No mnemonic needed for this and release.

Release refers to moving a system or change package into a production environment for immediate use by the end users.  

Moving on to Patch management. A sub-topic that should fall within the change management process.

Patches are initiated from the outside to improve or make more secure a given component of the IT environment. A routine patch is something that is regularly scheduled.  A reactive patch is typically a response to a threat or vulnerability.

Patching issues can include:

  • No interoperability – components not functioning harmoniously.
  • Poor designs – impact performance or introduce new vulnerabilities.
  • Required downtime – to deploy typically requires reboot or interruption with operations.
  • Expense – staff time.
  • Stored/archived virtualization – virtual machines in storage do not receive patching updates, so it’s important to check them for updates before putting them back into production.  
  • Timing of patches – this refers to the need to deploy patches timely across large organizations that may have differing time zones.  

Patching processes are typically standardized as follows:

  1. Notice of the patch – email notifications from the vendor, anti-malware vendor, or other authoritative sources can alert you that a patch is available.
  2. Patch analysis – to determine the applicability or necessity of the patch.
  3. Impact analysis – to determine the impact on operations and other systems.
  4. Testing – test environments should mimic production environments that include interdependencies to determine interoperability of the patch.
  5. Backup prior to applying the patch – this is to mitigate any problems after application of the patch.
  6. Application of the patch – this part doesn’t really need expansion…
  7. Confirm installation – use tools and organizational processes to ensure that the patch was applied across the organization.
  8. Solicit feedback – to address any non-system issues that result from the patch.
  9. Rollback/contingency – requires senior management decision because it involves acceptance of the risk to not use the patch.
  10. Documentation – ensure that appropriate patching records are kept in the asset inventory.

Patch management is a part of change management, the main difference is that patches are typically initiated from a third-party outside source (such as the anti-malware vendor), whereas configuration changes are started from the inside.  Patch management should be integrated with the change management process.

Blanket patch approvals – may exist for certain types of patches, such as:

  • Routine/minor patches – a threshold should be established for these.
  • Emergency security patches – because if left unpatched, could expose the organization to risk.

Difference between patch management and vulnerability management:

  • Vulnerability management is an internal, proactive search for weaknesses in the environment, whereas patch management is started from the outside and specific to a product.
  • Vulnerability management uses automated tools.  
  • Vulnerability management can only detect weaknesses based on the list or library of vulnerabilities that the scan uses.  If something has not been identified yet (but still exists), the vulnerability scan may not detect it. 

Exception requests, or number of exceptions to the baseline that are granted can indicate how effective the baseline is in meeting the business needs, which also indicates how effective the change management process is.  If a large number of exceptions are requested after a change is implemented, then it may not have been tested properly, or the right stakeholders may not have been included in the review, approval, implementation, and evaluation phases. 

Baselining refers to the minimum set of controls and the minimum standards for any configuration item.  Anything that renders the baseline inappropriate needs to follow the change management process to establish a new baseline or exempt the system from the current baseline.  The business owner of the system needs to agree with the exemption.

Configuration Automation

A “gold standard” or “gold image” is an older term that refers to a proper configuration that can be copied and applied to a system or component.  

A “script” or “recipe” refers to a configuration that can be applied to new systems using an automated tool that can update entries in the configuration management  database to show that automated creation or deployment of that system was done using a specific, correct, and approved script.

Bricking: essentially this means turning a device into a “brick”, or something that’s completely useless to a thief. Example with some iPhones, they will become “bricks” if the passcode is guessed too many times; not only will the physical phone be locked permanently, but the currently logged-in Apple ID will also be locked. Even if the phone is completely reset, the person resetting the iPhone will still need to know the previous passcode . This is merely one example. The CBK mentions mobile device management where bricking a device could be achieved from headquarters, likely with the push of a button.