Application Security

8/23/2018
10:30 AM
Dave Meltzer
Dave Meltzer
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Embedding Security into the DevOps Toolchain

Security teams need to let go of the traditional security stack, stop fighting DevOps teams, and instead jump in right beside them.

The adoption of DevOps continues to grow rapidly, and security teams are still trying to keep up. A natural starting point has been to focus on application security and securing the code itself. Although this is definitely an important piece of the puzzle, DevOps today has moved beyond just building application code into binaries into building complete system infrastructure in containers and virtual machines.

With this increased scope of DevOps comes all of the risks of the tens of thousands of known vulnerabilities and misconfiguration issues associated with the operating system, services, and system components included in the build. Just performing security assessments on the source code alone is not sufficient to identify these risks.

With the focus on speed and providing customers a constant stream of new features, DevOps teams typically haven't prioritized security first. Security is widely believed to be an inhibitor to agility, and using traditional security methods can be a bottleneck to DevOps agility. Security and IT operations teams understand that it's not sustainable to leave security out of the picture completely, but if security doesn't work at the speed of DevOps, it will continue to be pushed aside. This is why integrating security into the actual DevOps life cycle is key to managing risk effectively in the world of rapid development.

When looking to implement security at the speed of DevOps, one should understand what DevOps teams mean by the "CI/CD pipeline" and what that looks like. (CI refers to continuous integration, and CD refers to continuous delivery.)

Continuous integration is the concept that developers should be checking-in new code on a frequent basis (this could be several times a day). Code is checked in to a source code repository like GitHub, where an automatic build system, such as Jenkins, compiles the code and checks the new build to ensure the code didn't break anything.

The new build then continues onto the continuous delivery stage, where it is automatically deployed into testing environments for more involved end-to-end, load, performance, and integration tests. If everything passes, the new build is ready to be deployed to production. 

When deploying the new build, the DevOps team needs to define the right environment to run the applications and then ensure that all components are configured correctly. Tools such as Ansible, Chef, and Puppet are used for this.

Integrating Security into the Process
By understanding the CI/CD pipeline, security teams can see where it makes sense to put security controls in place and how they can match up to the existing DevOps workflow.

As mentioned, checking the source code being committed into the CI is a good first measure. However, many organizations leave it at that when they should go on to address the overall application infrastructure as it moves through the pipeline. It's not just code going through CI/CD process; operating systems, third-party components, middleware, and databases are being built and deployed along with that code.

The CI/CD process involves a DevOps toolchain, a set of automated tools facilitating the building, testing, environment configuration, and deployment of these systems. By integrating security into this toolchain, organizations can add effective quality gates that fit within the existing process to assess for vulnerabilities, configurations, and compliance with frameworks and/or organizational standards. It's important have quality gates and assessments at the different stages of building, testing, and deploying because many changes can happen between the code committing and the system deploying. It's often more costly and frustrating to reject applications at the end of the CI/CD versus having visibility and addressing issues along each stage.

The most effective way to do this is to integrate security tools with CI/CD build tools (e.g., Jenkins, TeamCity, and Bamboo) and CI/CD configuration tools (e.g., Puppet, Chef, Ansible, and Salt) to fully automate these assessments. The assessments can then either stop issues from continuing down the pipeline or at least provide visibility into the risk the business is accepting. To ensure vulnerabilities aren't slipping through the cracks, having the additional ability to dynamically test systems in a live sandbox would be a great benefit.

Just as important as preventing issues from going into production, organizations will want to monitor and maintain the integrity of their production environments. Several, perhaps hundreds, of production environments were configured specifically to make the DevOps-produced applications work, so once you've set it up correctly, you want to monitor for any configuration changes.

DevOps will continue to grow, so organizations must implement security solutions that work at the speed of DevOps. DevOps is the new world of developing, releasing, and updating applications for a growing number of enterprises; therefore, security teams need to let go of the traditional security stack, stop fighting DevOps teams, and instead jump in right beside them.

Related Content:

Learn from the industry's most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Early-bird rate ends August 31. Click for more info

David Meltzer is Chief Technology Officer at Tripwire, a leading provider of security, compliance, and IT operations solutions for enterprises, industrial organizations, service providers, and government agencies (www.tripwire.com). He began building commercial security ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Higher Education: 15 Books to Help Cybersecurity Pros Be Better
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/12/2018
'PowerSnitch' Hacks Androids via Power Banks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/8/2018
How Well Is Your Organization Investing Its Cybersecurity Dollars?
Jack Jones, Chairman, FAIR Institute,  12/11/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: When Harry Met Sally
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-7690
PUBLISHED: 2018-12-13
A potential Remote Unauthorized Access in Micro Focus Fortify Software Security Center (SSC), versions 17.10, 17.20, 18.10 this exploitation could allow Remote Unauthorized Access
CVE-2018-7691
PUBLISHED: 2018-12-13
A potential Remote Unauthorized Access in Micro Focus Fortify Software Security Center (SSC), versions 17.10, 17.20, 18.10 this exploitation could allow Remote Unauthorized Access
CVE-2018-8033
PUBLISHED: 2018-12-13
The OFBiz HTTP engine (org.apache.ofbiz.service.engine.HttpEngine.java) handles requests for HTTP services via the /webtools/control/httpService endpoint. Both POST and GET requests to the httpService endpoint may contain three parameters: serviceName, serviceMode, and serviceContext. The exploitati...
CVE-2018-20127
PUBLISHED: 2018-12-13
An issue was discovered in zzzphp cms 1.5.8. del_file in /admin/save.php allows remote attackers to delete arbitrary files via a mixed-case extension and an extra '.' character, because (for example) "php" is blocked but path=F:/1.phP. succeeds.
CVE-2018-20128
PUBLISHED: 2018-12-13
An issue was discovered in UsualToolCMS v8.0. cmsadmin\a_sqlback.php allows remote attackers to delete arbitrary files via a backname[] directory-traversal pathname followed by a crafted substring.