Cloud Hosting

Cybersecurity professionals jobs would be much easier if configurations stayed put once they were aligned to a known and secure baseline state. Unfortunately for them, configurations naturally deviate from their once-secure state over time as system changes take place. This issueknown as configuration driftmeans the more time its been since your most recent scan, the less confident you can be about the exposure of your attack surface.

What kinds of changes lead to configuration drift? Product improvement being a never-ending project, application owners are regularly modifying apps and infrastructure to improve end-user experience. Some of these changes are harmlesswhile others push systems away from their secure baseline to dangerous effect.

Configuration security is one of the foundational elements required to build an effective defense against cyberattacks. From a policy point of view, establishing secure configurations sets you off to a good start (using CIS-hardened images, for example). However, maintaining them can be much more of a challenge.

Taking a look at a few concrete examples can help illustrate how easy it is for configuration drift to occur. Quick fixes that seem harmless at first glance can prove prohibitively hazardous. In other cases, the struggle lies in communicating evidence of a changes acceptability to auditors.

1. Introducing new ports

Lets say theres an innovative approach to improving an apps customer experience. One of the steps of implementing this approach is opening a new communication port for proprietary protocol use. The business team initiates a change ticket. They find the app working impeccably once the new port is opened on the servers and firewalls.

When its time for a security audit six months later, auditors point to this undocumented open port as a substantial issue because it doesnt match the security policy. Now the security team must spend a great deal of time attempting to trace back to the change in question and assess the acceptability of the associated risk. Even if the risk is deemed acceptable given the context, it took auditors too long to get adequate information to make this determination.

When security teams track configuration drift and document modifications to the known hardened baseline, its much easier to provide audit evidence without misusing valuable time.

2. Privilege escalation

Escalated privileges are one way IT professionals can introduce a lot of risk to their systems unknowingly. For example, if an app developer logs into a single server repeatedly, they might want to cut a corner by adding the users group to the user rights categories they need for added convenience.

This way, they can bypass the special admin credentials required to make a production change. Checking out admin credentials from the password vault can be time-consuming, and the developer is likely to think that its not a huge risk since its a single server as opposed to an entire domain.

However, privilege escalation for even a single server can prove riskier in terms of configuration drift than the added convenience is worth. Now, the security teams wont be able to know what has occurred until the servers next manual audit.

3. Cloud storage

Using a public cloud provider requires that youre fully aware of which security responsibilities are your own and which fall under the purview of the provider. Amazon Web Services (AWS) blocks all public access by default when a user creates a new bucket. This is advantageous from a security perspective, but it could be seen as a hindrance to efficiency by the IT team.

To streamline certain IT operations, this automatic block setting might be a tempting one to disable. This might be done by IT at the point of set-up, or it could occur around a temporary use case and be quickly forgotten without being switched back to the default setting. This could also be the result of a mistake in an automated script.

Whatever the reason, changing bucket access settings can create the type of configuration drift that leaves organizations highly vulnerable to a breach. Following security configuration management (SCM) best practices helps offset these types of risks. But more even important than establishing these processes is continuously monitoring them for drift from their approved configuration state.

There is a world of Secure Configuration Management guidance out there, but lets look at configuration management from a maturity model perspective. Depending on the maturity of your organizations security program, you may be in the manual, scanning, or near-real time state of configuration management maturity.

1. Manual configuration monitoring

Manual configuration monitoring is a major time drain, leading teams to avoid doing it on a regular cadence when other priorities seem more pressing. This can then lead to systems being left unwatched until a detected compromise gets someones attention or its time for a routine upgrade.

Compliance regulations mean that a subset of these systems may be included in the scope of an audit due to compliance requirements. When this is the case, security teams often try limiting the number of systems to be included in the audit. Then, only the non-compliance of those particular systems will be acted upon if detected during an audit (leaving other systems potentially exposed).

2. Using a solution that scans for compliance

The next level of configuration management maturity is using a solution that automatically scans for compliance at scheduled intervals. This is not nearly as tedious as the previous stage of maturity, but it does still require a hefty amount of interaction to create administrative credentials for the tool to scan with, as well as someone to schedule or run the scans when required and remediate the results. This is typically done once a month or once a quarter to try to get ahead of the audit process.

Similarly to the previous stage, this stage can be limited in terms of which systems are covered by the processscans may be limited within a compliance zone. The systems outside that zone can become left behind and only checked when compromise or the need for an upgrade takes place.

The Center for Internet Security (CIS) advises in Critical Security Control #5 that all systems need to be provisioned with secure configurations and that configurations need to be maintained on an ongoing basis as changes occur over time.

3. System monitoring in near-real time

The next level of maturity is reached when the scanning process is closer to real-time rather than intermittently scheduled scans. This requires the provisioning of a lightweight agent for system monitoring without the requirement login credentials or OS auditing. The agent must be deployed on all systems via embedding into images or inclusion into processes of automated tools like Puppet or Chef.

When new changes occur that result in configuration drift, a remediation process can be initiated. One example of this is the automated creation of incident tickets or alerts sent to the security operations center (SOC) over the security incident and event management (SIEM) tool. Organizations like CIS offer proven guidelines for system configurations that actively reduce your attack surface, called benchmarks.

CIS recommends tracking the following metrics to accurately measure this data:

1. What is the percentage of business systems that are not currently configured with a security configuration that matches the organizations approved configuration standard ?

2. What is the percentage of business systems whose security configuration is not enforced by the organizations technical configuration management applications (by business unit)?

3. What is the percentage of business systems that are not up-to-date with the latest available operating system software security patches?

4. What is the percentage of business systems that are not up to date with the latest available business software application security patches?

5. What is the percentage of business systems not protected by file integrity assessment software applications?

6. What is the percentage of unauthorized or undocumented changes with security impact?

Avoiding configuration drift is an ongoing process, and one in which you can raise your organizations configuration management maturity level steadily over time to optimize for maximum effectiveness and efficiency. Benchmarks from organizations like CIS are a great focus for security and business teams to collaborate around so that configuration drift is altogether avoided or remediated swiftly.

Tim Erlin, VP, Product Management & Strategy, Tripwire

See the original post here:
Proven ways to stay ahead of configuration drift - ITProPortal