Larry Watlington, CISSP, discusses the implications of having a fundamental understanding of configuration management based on an established risk management framework.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
There is a riddle that goes: “There are two ducks in front of two duck, two ducks behind two ducks and two ducks beside two ducks. How many ducks are there?” For anyone who’s worked with a large or even medium-sized network, managing configuration control of hardware and software assets can be just as frustrating as getting ducks to march in a row.
I’m sure you’re saying: “But we have automation tools that manage our configuration management (CM) processes”. Yes, there are a lot of great CM tools on the market, but any tool is only as good or effective as the people, policies and processes that underpin them. This is my tool-agnostic view of the CM process.
The Role of Configuration Management
CM isn’t a cybersecurity competency you’ll see touted on TV shows. However, it is the foundation on which all other cybersecurity pillars are built. The adage “You can’t protect what you can’t see” has never been more real than it is now. Without a sound information system baseline and change control process, tasks like auditing, access management, flaw remediation and just about all other critical cybersecurity pillars are suspect at best.
In addition, the seventh pillar of the NIST Zero Trust Architecture states that “the enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.”
A lot of my experience is with the U.S. Government and Department of Defense, so in this article I’m using the NIST 800-53v5 CM security control family and the NIST 800-128 Security-Focused CM risk framework to describe how to keep CM simple. I should say this it’s easily translatable to any other frameworks.
Configuration Management is built around four fundamental phases shown in figure 1 below.
Each of these four fundamental phases can be overlayed onto the 14 Security Controls in the NIST 800-53v5 CM family. While scouring NIST Security Controls is not the way we want to spend a beautiful afternoon, the CM family of controls is actually a logical roadmap that sequentially builds in a very repeatable manner.
Maintaining the original color-coding above, figure 2 illustrates the concept:
Now, as with any security control family, it starts with a good plan, polices and procedures.
The Green Boxes
The green boxes represent the “Planning” phase and include policy and procedures as well as a CM plan. My CM plan comprises a comprehensive description of the roles, responsibilities, policies, and procedures that apply when managing the configuration of products and systems. Developing a sound plan that identifies roles, responsibilities and key stakeholders will dictate the success or failure of your CM process – I assure you.
The Yellow Boxes
The yellow boxes in the CM controls diagram represent your “Identify and Implement” phase. This is a cyclic process that starts with establishing baseline configurations (CM-2). Before I can establish a baseline, I need to identify the configuration items (CIs) to be managed. Figure 3, below, is a simple matrix I use to help categorize the CIs on my network; understanding the “what” makes it much easier to implement the “how” of my CM process.
Establishing this effective configuration change control process (CM-3) might well be one of the most challenging aspects of the overall CM process, requiring the involvement (and cooperation) of the human aspect of your organization. Personally, I insist that stakeholders at multiple levels within the organization must become a member of the configuration control board (CCB): while this function is often relegated to the IT and cybersecurity departments, the reality is that it’s critical to have functional leadership, engineering, software development and other key business functions participate in the CCB process.
The remaining yellow boxes constitute the security controls used in the “Control” phase and provide me with security guard rails as the changes are implemented into the environment.
These are:
- Security Impact Analysis (CM-4): This considers the impact of a change on the security state of the information system
- Access Restrictions (CM-5): These assess if changes are implemented in a controlled environment
- Configuration Settings (CM-6): These ensure the system is properly configured after changes are implements (STIGS/SCAP, Vulnerability Scans)
- Least Functionality (CM-7): Configures information systems and components to provide only essential capabilities
- Component Inventory (CM-8): A list of the physically identifiable components to include manufacturer, model and serial numbers, licenses, physical location, etc.
The Pink Boxes
The pink boxes highlight a set of security controls that support the “Monitor” phase of the change process. I’m not doing a deep dive into these controls here. However, they are critical to my continuous monitoring of user activities associated with the CIs.
- Software Usage Restrictions (CM-10): These track the use of software and associated documentation protected by quantity licenses to control distribution
- User-Installed Software (CM-11): This enforces software installation policies
- Information Location (CM-12): This identifies and documents the location and users who have access to specific system components
- Data Action Mapping: This develops and documents system operations that process personally identifiable information
- Signed Components (CM-14): These verify that systems components are digitally signed with an approved certificate
Words of Advice
The Greek philosopher Heraclitus taught the concept that the universe is in continual transformation and “The only constant in life is change”. This has never been more evident than today’s continual evolution of enterprise business networks. As cybersecurity professionals, we owe it to the organization to better manage the change evolution through solid CM policies, procedures and business practices.
Larry Watlington, CISSP, has over with 30+ years of combined experience in cybersecurity, risk management, telecommunications and IT leadership. He is a retired USAF Chief Master Sergeant and his cybersecurity work expands across multiple government and defense contractors. He has held roles as a security engineer, cybersecurity subject matter expert and an adjunct professor at multiple universities.
ISC2 Security Congress 2025ISC2 Security Congress 2025, taking place October 28–30 in Nashville and online, is the must-attend event for those eager to master how to build, defend, configure and manage key systems and ensure they are resilient to evolving cyberattacks. Annually, ISC2 Security Congress brings together thousands of cybersecurity professionals to network, share ideas and receive the best cybersecurity education from the brightest minds in the industry. This event is one of the top cybersecurity conferences of the year, with impactful sessions provided by subject matter experts, professionals on the frontline and leaders in the industry, all providing real-world and relatable knowledge to attending practitioners. View the full ISC2 Security Congress agenda and secure your place at the forefront of software security innovation. Register now. |
