Why compliance demands a DevOps approach

Stop me if you’ve seen this scenario before: A compliance policy is developed behind closed doors by federal security advisors. Once published, it’s sent to IT managers, who take one look and think, “Well, this won’t really work.”

They begin the arduous process of trying to provide feedback, which amounts to submitting a request into a suggestion box, and waiting for an answer that may or may not come. The public comment process is often opaque; you don’t know if or why your comments were rejected and it’s difficult to appeal your case.

This classic “waterfall” approach to the creation of security and compliance procedures is in direct contrast to the fast and agile DevOps approach to application development that many agencies embrace today. Over the past few years, the federal government has turned to Silicon Valley startups filled with former Presidential Innovation Fellows to bring agencies into the 21st century. These people understand the value of DevOps development principles, but they’ve been asked to meld those principles with an antiquated waterfall security process with gated checkpoints, starts-and-stops, and long development cycles.

Consider a DevOps approach, where the creation of compliance content happens in tandem with application development and involves input from many different stakeholders. Solicit feedback from numerous key stakeholders, including developers, system administrators, security managers, and especially end users. Incorporating multiple lines of feedback right from the start can ensure that developers’ concerns regarding the balance of security, compliance, and innovation are addressed early in the process and that security managers have a better understanding of how their policies impact both development and end-user experiences.

One of the best examples of this is the Security Content Automation Protocol Security Guide, aka, the SCAP Security Guide (SSG). This is an open source community project that emphasizes better vulnerability management, compliance reporting and continuous monitoring. Guidance has been incorporated, such as commercial PCI DSS standards, U.S. military requirements from the Defense Information Systems Agency's Security Technical Implementation Guide (STIG), national security requirements from NSA, and civilian mandates such as FISMA. The guide addresses many security and compliance needs and provides best practice responses to those needs.

The SSG exemplifies how getting everyone to the table at the outset of compliance content creation can positively impact development further down the line. Since security policies will have been baked into the development process from the beginning, there’s no need for annual “check the box” moments that disrupt development. As a result, security no longer impedes innovation, but instead enables it and provides a safe place for innovation.

Open source software drives this innovation, but it also moves very quickly -- which means that application development moves very quickly. This makes it impossible to manually inspect every line of code comprising modern software applications, especially with the velocity of agile development.

Therefore, it’s critical for agencies to automate their compliance scanning processes. In the same way developers run unit tests during development to build code, they should be doing scans to make sure their code is not drifting away from established security and compliance policies or that they are not incorporating unsecure code that has known fixes.

OpenSCAP is a good place to start. Brought to you by many of the same folks who developed the SCAP Security Guide, OpenSCAP is a NIST-certified open source community-driven project. It provides agencies with tools that enable them to automatically scan infrastructure and automate vulnerability checking to ensure their information systems remain compliant, contain the latest security patches, and minimize risks. This allows compliance checking to be a “living document,” composed of automated processes. It can be attributed to the entire lifecycle of a system, rather than a labor-intensive, annual event that can put a halt to development. No wonder NIST has made security automation one of its top development initiatives.

Some Linux-based operating systems now ship with security baselines already in place thanks to the coordinated efforts of a community of collaborators across the government, educational and commercial sectors. That collaboration can bring tremendous benefits.

For example, when DISA created the Red Hat Enterprise Linux 5 STIG, the closed-loop process took 1,988 days. By contrast, when the Red Hat Enterprise Linux 6 STIG was developed, the government collaborated with NSA Information Assurance, the vendor, and more than 100 community members from across the defense and civilian government. The resulting compliance baseline was developed in half the time -- 932 days -- and the resulting DISA STIG was natively integrated into vendor’s next service pack release.

Due to increased community participation, the vendor’s most recent release of Red Hat Enterprise Linux 7 included a DoD Vendor STIG upon release. In total, the process went from a 1,988 days to zero, and the development community has grown to more than 200 contributors from across commercial and government agencies.

Agencies using Linux containers also have alternatives that did not exist even a year ago. In March 2017, the OpenSCAP tools were certified by NIST as an approved configuration and vulnerability scanner. Developers now have the means to scan and validate what’s running inside of their containers using U.S. government approved tooling. They can ensure the latest security updates have been applied, underlying configuration adheres to policy, and all code remains within compliance parameters.

Compliance is necessary, but it does not need to be considered a necessary evil. By treating security compliance tools and content as an open source project and continuously incorporating lessons learned from across the community, compliance -- done properly -- can help automate and scale security. Integrating the creation of compliance and security measures with the development process is a better way to minimize risk without sacrificing innovation.