Configuration management should be the bedrock of how an IT department sets up, manages and audits its platforms -- but it's not something that happens overnight. Operations admins must plan and perform configuration management tasks carefully to ensure all IT systems are properly maintained and secured.
To prevent any gaps or oversights, approach the configuration management process in four distinct steps.
Step 1: Create a configuration management baseline
Most configuration management tools will automatically interrogate the IT environment and return the necessary information to create what's called a configuration management baseline. This baseline is a fixed set of system configurations that acts as a basis for detecting change.
As such, the chosen configuration management tool must interact well with virtualized, as well as physical, environments -- and handle workload movement, such as microservices across a network, without picking up the change as a configuration fault to correct.
However, IT ops admins should not trust the baseline to be 100% correct: Most tools will display various issues because they lack necessary information -- such as a device's driver version or an application's patch level. An IT admin can intervene manually to resolve these issues. The bigger problem is when the tool misses something completely.
This is less likely to happen at the hardware level, unless unusual systems are in place. Generally, even custom servers have a mass-produced motherboard and use standard PCI or other cards and interfaces, which a configuration management tool should be able to query successfully. It is more likely that problems will arise around software -- particularly that which has been developed in house or is used by few other organizations. The IT team must input information manually -- and ensure this information is maintained and up to date. The level of initial audit comes down to the level of risk that a company is willing to take: An organization that is willing to carry a large degree of risk might ignore hardware and software that has little effect on the overall business operation. Risk-averse companies, however, might extensively check actual physical attributes against those garnered by the configuration management tool.
During baseline development, check that the security systems in place across all, or part of, the environment do not stop the configuration management tool from doing its job. Ensure the configuration management tool registers as a trusted system -- otherwise, security tools could perceive it as a distributed denial-of-service or man-in-the-middle attack. If in doubt, talk to the configuration management tool vendor to determine an implementation plan that won't compromise security.
Configuration management vs. change management
Configuration management is often confused with change management in IT -- and it's easy to see why. These two processes are complementary, and closely related, but aren't one in the same.
For example, while configuration management aims to detect and track any changes made to IT systems and assets, change management works to assess and minimize the potential risks of those changes.
Step 2: Don't let the baseline become obsolete
The configuration management tool must now keep the baseline up-to-date to maintain a database of all changes that occur in the environment. IT admins must log every change -- no matter how small. The tool must work in tandem with help desk systems, service tools and any part of the environment that works on an auto-update basis, such as antivirus systems, to capture all activity.
During this step in the configuration management process, enforce strong policies and formal practices to prevent administrators from making ad hoc changes. In the best-case scenario, these changes cause the configuration management system to revert to a previously known environment, and, in the worst-case scenario, they cause a domino effect of efficacy degradation.
Wherever possible, make changes to the environment through the configuration management tool. For example, the tool should patch device drivers itself. It should also check any change against the existing baseline to ensure that the change is even possible. For example, as network routers age, the router vendor tends to provide OS updates. These updates get larger as new functionality grows and, at some point, the remaining available memory in older routers can no longer accept the upgrade. The configuration management tool should detect this, not commit the update, and then present the event as an issue for an administrator.
Step 3: Continuous auditing
As time goes on, the configuration management tool's database will change, and IT admins must check it regularly to ensure it is valid and correct. Again, the level of depth for this audit will depend on the organization's risk profile. One simple auditing method is to ensure that the configuration management tool can recognize when equipment has been removed from the environment. This task alone can uncover OS and application licences for which the IT organization pays erroneously -- and correcting this issue helps the configuration management tool pay for itself.
Next, take a sample of both existing hardware and software and manually compare what the configuration management tool believes is present and what the IT ops team knows is there. Correct any differences, and drill down into the data to determine why these differences exist. Is the configuration management tool poorly configured? Is it unfit for certain purposes? IT organizations must have sufficient faith in the tool's functionality.
Step 4: Test, test, test
Lastly, test to ensure the configuration management tool meets its intended purpose -- effectively. Find a segment of the environment to test, such as the installation of an OS upgrade, along with some driver updates. In this phase of the configuration management process, test that these updates commit properly -- and that a rollback works.
Identify any dependencies, such as an OS upgrade that requires preemptive device driver updates, and whether the tool can support these dependencies autonomously or if it needs manual intervention.