How DevOps and CIS Security Controls Fit Together

The Center for Internet Security’s Critical Security Controls has become an industry standard set of controls for securing the enterprise. Now on version 8, the original 20 controls are down to 18 with several sub controls added.

The first six basic controls can prevent 85 percent of the most common cyber attacks, and even though the controls have been developed with traditional data centers and process in mind, there is no reason they can’t be adapted to DevOps practices.

DevOps and CIS Security

A quick review of the basic controls will provide some ideas of how they fit for DevOps and where they don’t align with DevOps practices. Control 1 and Control 2 are about inventories: inventory and control of enterprise and software assets.

Infrastructure in a cloud environment becomes virtualized infrastructure – containers and repositories, virtual machines, lambda functions, microservices, APIs, etc. The principle still stands, however, that knowing what underlying infrastructure is authorized in your environment and detecting unauthorized deployments is critical.

In a highly dynamic cloud system with ephemeral servers being deployed and destroyed constantly, it’s even more important to know whether what is being deployed should be deployed and whether it is authorized to be in your environment. Consider your current controls and how you monitor your runtime environment. How do you know what is running is authorized to be running and is running approved apps and services?

If you don’t have an answer for those questions, review your architectural diagrams and CI/CD pipeline and think about tools at your disposal to get a better view of your “hardware” assets. Those may be native to your cloud environment, third-party solutions and/or an inventory management process you point in place. There is an additional advantage to tracking and ensuring the assets in your environment are authorized and should be running: cost savings. Running only what you need, when you need it provides a security control and is good for the bottom line.

Software inventories also offer an interesting challenge that would traditionally be managed with a CMDB and ITSM processes. For some parts of DevOps, this could still work. It’s a good practice to have a defined set of authorized and standardized tools for the pipeline and a repository of allowed libraries and software available for developers.

On the other hand, a cloud environment may be changing so rapidly that maintaining a software inventory is impractical. The key is controlling risk. Knowing what is running in your environment and whether it is intended and authorized also means you know if something shouldn’t be there. That software or service may not be malicious. It may simply introduce additional risk and removing it would be a good thing.

One possible application of this is allow-listing what applications are allowed on containers. Within your CI/CD pipeline, scanning a container for running applications, and adding a rule enforcing a quality gate for which applications are allowed would break the build if it finds anything outside the allow-list. If, for instance, the scan finds SSH running but SSH isn’t necessary for the application this could cause the quality gate to fail and break the build. A developer would need to remove this library to proceed, reducing the attack surface and creating a cleaner build.

Control 7 is vulnerability management (VM), and I wrote about this process in a previous blog post about detective and preventive controls. VM should be implemented as a quality gate before deployment, and it is critical at runtime as well. Knowing what vulnerabilities are in your environment and remediating those vulnerabilities as often as possible keeps your applications and service secure. DevOps is particularly suited to rapid patching and updates, so this control fits in neatly with the paradigm and should be built in from the beginning. As with application monitoring, vulnerability scanning can also be used to enforce a quality gate in the pipeline, ensuring vulnerability systems are not deployed into the production.

Controls 5 and 6 are about managing privileges. Ideally, administrative privileges are already extremely limited and controlled since there should be little need for elevated access in most cases. DevOps tools, like Hashicorp’s Vault, have ways to manage access and processes – these include checking out privileged access keys that expire in a short amount of time, thereby limiting risk exposure. This is consistent with the zero-trust model, and limiting what can be done, by whom, and when, all limit attack surface in a very tidy way.

Secure configuration is the fourth control, and, once again, this should be something that fits nicely into the build pipeline. Assessing the configuration of builds prior to production deployment is another quality gate that can be built right into the pipeline. For instance, if a virtual machine or container has a policy that it must comply with CIS benchmarks, assessing that compliance could be a quality gate. Runtime assessment should also be included to monitor for configuration drift and the cloud environment itself should also be continually assessed. There are many tools to assess whether the underlying cloud infrastructure is secure and you should be monitoring to validate your cloud configurations are following best practices.

Finally, log monitoring and analysis is the last of the basic controls. There are a number of cloud-native logging tools for the various cloud platforms, and many of those already have specific security monitoring built in. As with other controls, the pipeline itself shouldn’t be neglected and application, access, and other logging should be implemented for build and deployment tools. This not only provides detective controls for things like unauthorized access, but it also provides forensic evidence for incident response or even operational tuning when things aren’t going exactly as planned. Repudiation is a key element of security and logging ensures you know who did what and when.

Use Tripwire to Meet the CIS Controls

See how simple and effective security controls can create a framework that helps you protect your organization and data from known cyberattack vectors by downloading this guide here.