1

Proper management of the configuration of your infrastructure components is vital to security, compliance and business continuity. Unfortunately, configuration drift in systems and applications is common, which leaves the organization vulnerable to attack. Indeed, about 1 in 8 breaches result from errors such as misconfigured cloud environments, and security misconfiguration ranks #5 on the OWASP list of the top 10 web application security risks .

In this post, you’ll learn what configuration drift is and how you can prevent it.

What is configuration drift*?*

A practical configuration drift definition is that any system configuration will, over time, diverge from its established known-good baseline or industry-standard benchmark. While minor drift might not cause issues, the reality is that even one misconfigured setting can expose the organization to data breach es and downtime, so the more severe configuration drift, the higher the risk.

What causes configuration drift?

More often than not, drift is the result of administrative users making changes to the system. Causes behind configuration drift include:

  • Software patches: Applications, operating systems and networks frequently require patches for regular maintenance or to resolve an issue. However, these software or firmware patches can also cause configuration changes that might go undetected.
  • Hardware upgrades: As businesses grow, so do their IT infrastructures. Hardware upgrades can lead to changes in configuration both at the hardware and software levels.
  • Ad-hoc configuration and troubleshooting: Each day, organizations deal with tens or even hundreds of events that require quick fixes to a network, operating system or applications. Though these quick fixes solve the problem at hand, they can involve configuration changes that hurt security.
  • Unauthorized changes: All modifications should be made based on an approved change request. Any unauthorized change could compromise the availability, performance or security of your IT systems.
  • Poor communication in IT: Configuration drift can also occur when one IT team makes a change but does not inform other teams about it, or when team members don’t exactly know which configuration states are standard and approved.
  • Poor documentation: If configuration changes are not properly documented, team members may not be able to determine whether systems are properly configured.

Examples of configuration drift

Here are some configuration drift examples:

Configuration changes hastily made

It’s the end of the work week, and the system engineer is about to leave. One of his colleagues informs him that a critical application is having an issue. He cannot leave the problem to be resolved on Monday but, at the same time, he wants to fix it quickly so he can head home. He makes some changes to the application configuration to fix the problem. However, he also modifies a critical setting that blocked unprotected public access to the system — causing configuration drift that leaves the infrastructure exploitable. Since he’s in a hurry, he doesn’t document his changes, so this drift could go unnoticed until it’s exploited.

New application installations or upgrades

A company upgrades a business application to gain new features. The upgrade process makes some crucial configuration changes to allow connections through previously blocked ports. A few months later, during a security audit, auditors discover this misconfiguration. Even if the open port hasn’t caused any harm yet, it still jeopardizes the company’s compliance status.

Risks linked to configuration drift

Configuration drift increases the organization’s risk of the following consequences:

  • Network breaches: An improper configuration change can leave the door open for an outsider to enter a private network. It’s arguably the biggest security threat an enterprise can face, as network infiltration can lead to data theft, activity surveillance, and malware or virus infections.
  • Data breaches: Improper configuration of on-prem or cloud data storage increases the risk of someone stealing or corrupting the data, which can result in steep financial losses and reputation damage. For example, IBM Security reports that the average cost of a ransomware infection in 2021 was $2.73 million.
  • Downtime: Misconfigurations can lead to downtime, either directly or by opening the door to attacks. For instance, configuration drift in web server can allow a DoS attack that brings down the server. Downtime hurts company production and employee productivity, and can lead to lost revenue as customers turn to more reliable vendors.
  • Poor performance: Configuration changes can drag down the performance of systems and applications, even if they do not cause complete downtime.
  • Compliance issues: Today, data security and privacy are governed by strict regulations, such as ISO 27001, PCI DSS, HIPAA, or GDPR . Configuration drift can lead to non-compliance and result in hefty fines.

Tips for avoiding configuration drift

NIST Special Publication 800-128 offers guidance for avoiding configuration drift. Here are some of the key recommendations:

Implement continuous monitoring and regular audits

Auditing the configuration of your systems on a regular basis is a good start. But even if you review them once a week, that’s still more than enough time for a misconfiguration to lead to a breach, downtime or a compliance violation.

Therefore, it’s imperative not only hold regular audits but to monitor configuration changes continuously. That way, improper modifications can be corrected immediately. In addition, be sure to hold audits when new devices are added or ad -hoc changes are made.

Automate processes

Manual review of system configurations is slow and error-prone, so misconfigurations may not be detected promptly, or at all. With attackers ready to exploit the slightest misstep in security, manual processes just won’t cut it.

Consider investing in a configuration management tool that automates the process of finding configuration gaps. It should be able to scan all network device s and applications, spot any configuration changes, and notify the security team. Some automated tools can even be set up to revert the changes and restore a known-good configuration.

Use a repository of benchmarks and baselines

Establishing baseline configurations can save time and avoid confusion. Your teams can quickly determine whether configuration drift has occurred and restore your systems to their intended state.

Consider using benchmarks from industry leaders like CIS or NIST to build your baselines. Some configuration management tools provide templates to simplify this process. Be sure to review and update them regularly, especially when there are changes to your IT environment or applicable regulatory mandates.

Standardize configuration change management

Implementing rigorous change management, tracking and analysis is vital to IT security and availability, and configuration changes should be included. Controlling configuration changes as they happen helps prevent configuration drift and the associated risks. Documentation is vital to change management. Any configuration change should be documented and communicated using standard protocols set by the enterprise.

FAQs

What is a configuration management plan?

A configuration management plan defines a process for establishing baseline configurations, monitoring systems for configuration changes, and remediating improper or authorized modifications.

How do I stop configuration drift?

Configuration drift is a common problem that can be managed with better security configuration management. In particular, you should:

  • Establish a baseline configuration for each system and application.
  • Document all configuration changes.
  • Monitor for changes to your configurations.
  • Avoid ad -hoc changes to fix problems quickly.

Related content:

Origina Article - Understanding and Preventing Configuration Drift

When it comes to the security of your enterprise assets and software, you can’t afford to leave anything to chance. Netwrix Change Tracker scans your network for devices and helps you harden their configuration with CIS-certified build templates. Then it monitors all changes to system configuration in real time and immediately alerts you to any unplanned modifications. System can help to:

  • Establish strong configurations faster.
  • Quickly spot and correct any configuration drift.
  • Increase confidence in your security posture with comprehensive information on security status.
  • Pass compliance audits with ease using 250+ CIS-certified reports covering NIST, PCI DSS, CMMC, STIG and NERC CIP.
13 Spice ups
2

Never heard such a term like configuration drift before. Your definition is too vague for me to understand.

An established known-good baseline is something fixed in time. Depending on baseline definitions, such baseline may change over time or not. In my experience, I’ve a mix of fixed baselines and moving baselines. Both have their sense and are used for different purposes. So moves of moving baselines are usually intentional when done by authorized persons.

An industry-standard benchmark is not a baseline. It may be used to assess what is defined by a baseline. And when the baseline is of type moving, repetition over time is expected to result in different benchmark results too.

Business needs are changing over time too. So it is expected that changing business needs result in changing system configuration baselines. Such changes are defined in change management process which itself is part of configuration management plan.

I still did not get what you mean by configuration drift nor its relation to mis-configuration. According to your definition, a configuration drift is also expected behavior when transitioning of one baseline to another baseline according to approved change requests to meet changes business needs. I would not consider implementation of such approved change request a mis-configuration. I would not expect configuration differences between two approved baselines as mis-configuration. So please clarify.

No. a configuration management plan is not limited to what you listed. Your list misses the definition of system to be managed so that you know what is outside of scope and system. Your definition misses configuration items (CI). I have no idea how you may define baselines without defining configuration items. Your list misses change management process. It is typical part of a configuration management plan. And I miss approval processes and audits in your listing. You mentioned monitoring but this is only covering a subset of relevant parts of a configuration management plan.

I did not yet read the whole of your topic nor did I yet lookup your sources and references. You mention standards. There exist standards for configuration management and for configuration management plans. When I had to do with such standards, I never read of configuration drift but I read of configuration management plan. And their definitions were significantly different of yours, regardless if approved or proposed international standards.

3

Oh I understand your terminology & description perfectly. I worked with the king of Unauthorized changes, Poor communication & Poor documentation. He would also delete previous patches meaning there was no way to roll back. It’s been 3 & a half years since he left & there is still not a week that I don’t have a point of screaming “Fudge Fudge FUDGE!! Why the FUDGING FUDGE would you FUDGING DO THAT!?”
He also had a particular hatred for Compliance issues & despised Configuration management plans

I quote the words that nearly broke me “You do all that stupid document stuff. You Love it & I don’t. It’s what YOU like to do”

No I’d also prefer to play the bubble game on my phone with my partner, like you…

4

Configuration drift is an extremely common term with software development, infrastructure-as-code, and DevOps. What is configuration drift? - Coder

5

Thanks for the link. But this does not convince me that it would be extremely common. It provides no definition but trying to describe by examples. In my understanding, it sounds like impact of insufficient software development or DevOps organization. I often worked in software or system development context. And I usually had either basic rules or advanced rules already established in such development organizations making risks of such configuration drift less likely although level of automation might have been limited. (Software) configuration management is mandated for certain regulated business domains. If this is well established, likelihood of configuration drift should be low. With established configuration management, the configuration manager should assist the developers to get an environment free of configuration shift, in addition to one where they practice intentionally configuration shift. But having established software development organization and software configuration management should assist developers to use such clean environments for submits to shared code base and only allow defined deployment outside of developer workplaces. Developers are not limited to a single workplace.

As a software configuration manager, I’ve acceptance criteria for accepting submits to shared code base (and later builds and deployments). I don’t care how much configuration drift a developer uses for development in his workplaces. But I shall offer the developers a means to create a new workplace to prepare submit to shared code base and to test for acceptance criteria, free of configuration shift.

In larger complex projects, I as configuration manager may detect earlier when configuration drift happens nevertheless so that I intervene when this appears to no longer be accidental. As a configuration manager, I manage those development pipelines and analyze causes of troubles. And as mentioned in the description of examples, it was most often insufficient communication and insufficient coordination when such configuration drift happened nevertheless. I remember a project when this was becoming too frequent and was talking with the team of too poor practice to better communicate within their team and with other teams when they want to submit interface changes. I further told them if they don’t know how to do better, then to talk with a specific other team and their lead engineer as they manage larger complexity and more frequent interface changes but succeed in doing such coordination within their team and with other teams as needed. The team leader of that team with too poor practice was assistant project manager too, and the project manager was sitting next to her. After my intervention, it took further 2-3 days until these configuration drifts returned of frequent to accidental. But we were using other terms, not configuration drift.