Page 36 - FCW, June 2017

DrillDown
The role of automation
One of the best examples is the Secu- rity Content Automation Protocol Security Guide (SSG). This open- source community project empha- sizes better vulnerability management, compliance reporting and continuous monitoring. It incorporates the Pay- ment Card Industry Data Security Standard, U.S. military requirements from the Defense Information Systems Agency’s Security Technical Imple- mentation Guides (STIGs), require- ments from the National Security Agency and civilian mandates such as the Federal Information Security Modernization Act.
The SSG addresses many security and compliance needs and provides best-practice responses to those needs. It exemplifies how getting everyone to the table at the outset of compliance content creation can positively affect development fur- ther down the line. Because 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 innova- tion, but it moves quickly, which means application development moves quick- ly. That makes it impossible to manual- ly inspect every line of code in modern software applications, especially given the velocity of agile development.
Therefore, it’s critical for agencies to automate their compliance scan- ning processes. In the same way that developers run unit tests when build- ing code, they should be conducting scans to make sure their code is not drifting away from established secu- rity and compliance policies or that they are not incorporating unsecure code that has known fixes.
Compliance is necessary, but it does not need to be considered a necessary evil.
OpenSCAP is a good place to start. Brought to you by many of the same folks who developed the SSG, the OpenSCAP project is certified by the National Institute of Standards and Technology and driven by the open- source community. It provides agen- cies with tools that enable them to automate infrastructure scans and vul- nerability checks to ensure that their information systems remain compli- ant, contain the latest security patches and minimize risks.
That approach allows compliance checking to be a “living document” composed of automated processes. It can be applied to the entire life cycle of a system rather than constrained to a labor-intensive, annual event that can bring a halt to development. No wonder NIST has made security automation one of its top development initiatives.
Necessary but not evil
Some Linux-based operating sys- tems now ship with security base- lines already in place thanks to the coordinated efforts of a community of collaborators across the government, educational and commercial sectors. That collaboration can bring tremen- dous 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 being developed, the government collaborat- ed with NSA’s Information Assurance division, Red Hat and more than 100 community members from defense and civilian agencies. The resulting
compliance baseline was developed in half the time — 932 days — and the resulting DISA STIG was natively integrated into the vendor’s next ser- vice pack release.
Due to increased community par- ticipation, Red Hat Enterprise Linux 7 was released with a Defense Depart- ment vendor STIG. That process went from 1,988 days to zero, and the development community has grown to more than 200 contributors.
Agencies that use Linux containers have alternatives that did not exist a year ago. In March, NIST certified the OpenSCAP tools as approved configuration and vulnerability scan- ners. Developers now have the means to scan and validate what’s running inside their containers using govern- ment-approved tools. They can ensure that 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 neces- sary evil. Instead, agencies should treat security compliance tools and content as an open-source project and continuously incorporate lessons learned from across the community because when done properly, com- pliance 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. n
Shawn Wells is chief security strat- egist for Red Hat’s Public Sector organization.
30 June 2017 FCW.COM