What is Compliance Scanning? 

Compliance scanning is the method used to ensure that system configuration is compliant with security policy controls. Unlike vulnerability scanning, which picks up on Common Vulnerabilities and Exposures (CVE), and out-of-date software patches, many cybersecurity vendors also offer compliance scanning tools that measure compliance based on a third-party template. However, these scans are typically a source of pain within IT because compliance scanning regularly reports false positives and often misses gaping security configuration issues that weren’t designed to protect against. The result is a general mistrust and disregard for compliance, which manifests operationally through: 

1. Alert Fatigue – Unintentionally encouraging administrators to ignore reports or mark too many findings as false positives without proper review. 
2. Shadow IT – Correcting glitches through custom scripts and manual manipulation, which solves the problem temporarily but quickly deprecates and fails to scale. 

Although rooted in good intention, compliance scanning’s broad acceptance can often cause a disparity between compliance and system management. To put it bluntly, periodic compliance scanning is a broken process and a headache for all those forced to participate. Instead, organizations should seek to code compliance right into modern deployment and configuration management practices to make all the security compliance controls part of the actual config file. You may then manage compliance drift the same way you currently manage with other drift — using source control, deployment configs, automated testing, etc.

Automation and Compliance Scanning 

At MindPoint Group, we’ve created Lockdown to explore how Configuration Management (CM) automation improves the process of applying system-level compliance requirements (also known as baselining) with third party security controls. With the open source community’s help, we’ve built a new paradigm for automating the application of STIG and CIS baselines to operating systems and applications. One of the hallmarks of effective automation is to do no harm. If your CM tool finds a correction it wants to make, you need to be sure that it is the right correction. You also need to account for different system types and purposes. One system may need to be configured differently based on its role in your environment. As a result, every aspect of Lockdown automations is modular and extensible, thus enabling custom policies or mitigations on top of the default controls. Suppose you take this automation and start using it in the delivery pipeline or resource management lifecycle. In that case, it enforces the desired compliance state throughout the system, application, or even environment lifecycle.  

Despite automation’s ability to enforce compliance with code, the business will likely require some sort of validation to verify the actions of an execution engine. Even a human-readable language like YAML requires some level of experience to interpret, so trying to pass an audit on your scripts alone will be difficult. Currently, the process is to config your system, then scan, then manually comb through the report to identify exceptions, false positives, and items needing mitigation. At A-Kar, we know this process all too well and strive to “tune” our baselines to align with the validation and scoring process. More specifically, we take the default scripts within Lockdown and re-configure the variables to match the compliance profile of the scan tool adopted within the organization. Since tasks in Lockdown scripts match to a corresponding baseline control, it’s possible to quickly modify a script to satisfy organizational exceptions and add new controls as necessary.  

In the future, we’d like to build an execution engine that features a policy builder, validation scanner, and scoring function to further streamline the process and abstract away the code from policy automation to make these tools available to all. This idea was the logical next step to the Testing Pipeline already being built into the Lockdown Enterprise Roles. This testing framework helps clients trigger Scan->Config ->Scan workflows that collect, diff, and score the system config before and after the baseline implementation. It strengthens compliance reporting because it provides:  

1. Scanner scoring before and after baseline implementation. 
2. Changed configuration details, including a mapping to specific security controls. 
3. Lists of settings that remained the same or did not require changes. 
4. Enumerated tasks that failed and how they map back to individual baseline controls. 

As a we audit to see that configuration management processes adequately enforce and report compliance. If we are provided scan results, we will typically ask to observe and test a sample system because we can’t be sure that the scan provided accurately reflects reality. Automated configuration management of compliance ensures consistent, secure, repeatable results and cuts down on managing config drift with shadow IT processes.  

Next Steps 

Whether you want to learn more about using Lockdown or are already using Lockdown and need help with a compliance roadmap, our team of security experts is ready to help. Contact us to learn more.