In my last posting Proactive IT Support on Display I shared a story describing elements of Endsight’s configuration management process in action. I summarized steps in a well established process to identify, control, account for and audit changes and so I thought it made sense to expand on configuration management in more detail.
Configuration management is the process of identifying, controlling, accounting for and auditing changes made to a pre-established baseline.
- Configuration management is defined by (ISC)2 as “A process of identifying and documenting hardware components and software and the associated settings.
- The goal is to move beyond the original design to a hardened, operationally sound configuration.
- Changes are made and documented as new technology components are procured, hardened and then deployed to the environment.
- Configuration management will control changes and test documentation throughout the operational life cycle of each technology component and software title.
Configuration management is essential to disaster recovery. It is impossible to recover to a last known good configuration if there is no documentation or if the documentation is incorrect. Similarly for Cybersecurity, how would anyone know if something is out of place if there is not a pre-established “way” of configuring, documenting and changing the environment?
New system components and software need to be reviewed and documented out of the box. It seems like this should go with out saying, but in the real world, there are deadlines and people are waiting on new equipment or services. It takes discipline to adhere to the process. Basic documentation should include items like:
- Make / Model
- MAC Address
- Serial number
- Operating system
- If applicable, permanent IP address
- Organizational Department Label
System hardening and baselining
Manufacture default settings are rarely the most secure. Once documented, each component “type” should be configured to a pre-established, and well documented, baseline configuration. Baseline tasks should include:
- Removing unnecessary services
- Installing the latest service packs
- Renaming default accounts
- Changing default accounts
- Enabling security configurations
- Internal FireWalls
- Automatic updates
- Physical security – laptop locks for example
Change management is sometimes confused with configuration management, but it is not the same thing. Change management is a subordinate function of a broader configuration management process. The goal of change management is to assure system stability and to avoid “on the fly changes.” Change management processes include:
- Directive, administrative controls that should be incorporated into organizational policy
- Formal review of all proposed changes (no on the fly changes)
- Only approved changes are implemented
- Periodic re-assessment of the environment to evaluate the need for upgrades or modifications to the baseline configuration.
Change Management Process
A well defined change management process should include:
- Change request submital
- Risk / impact assessment
- Approve / reject change
- Scheduling / user notification / training
Sometimes, in an emergency, changes may need to be made. This should be rare and only a small number of people in the organization should be authorized to make an emergency change. Once implemented, that change should be filtered back through the change management process so that it can benefit from the validation and documentation protocols that are established.
Software updates and patches are periodic and often times, predictable changes to the computing environment. Patch management is an essential sub function of change management and configuration management.
- Patches often result from a vendor notification or penetration testing.
- There are many resources to assist with patch management
- cve.mitre.org – common vulnerabilities & exposures
- nud.nist.gov – Enables automation of vulnerability management, security measurement and compliance. NUD includes checklists, security related software flaws, incorrect configurations, product names, and impact metrics
- www.cert.gov on-line resource concerning common vulnerabilities and attacks
While there is a cost associated with configuration management. There’s a commercial that you may have seen that does a good job of illustrating the cost for not doing it. An auto mechanic talks about a costly engine repair that could have been avoided if the car’s owner had replaced his oil filter. The mechanic says, “You can pay me now, or you can pay me later.” The quote is just as valid with regard to Configuration Management.
The reason that configuration management is included as a key systems engineering practice is simple. It works! It keeps the business from incurring costs preventatively and helps IT stop fire fighting. This allows for the deeper attention on things like business continuity and cyber security.
Alternatively, a poorly implemented configuration management process will likely sit at the root of recurring performance issues and escalating end users support requests.
Are you wrestling with recurring IT repairs and fixes?
Would a clearer configuration management process fix the root issues?