DevOp’s Role in Application Security
Nearly 70 percent of organizations that participated in an IBM/Ponemon Institute study published earlier this year said they lacked visibility into the overall state of application security. Further, 35 percent of them do not use any major application security testing methods to identify application vulnerabilities.
Most web applications have at least two serious security vulnerabilities at any given time, according to WhiteHat Security research published in June. The average time-to-fix application vulnerabilities is also trending upward, found the company. In 2015 this important metric was 150 days, up from about 100 days in 2013.
Traditional Application Security Strategies Are Not Working
This increase “indicates that traditional application security strategies of detecting and remediating are not working…,” wrote WhiteHat Chief Marketing Officer Tamir Hardof on the company blog, adding, “Whether it’s an issue around feedback between developers and security teams, a lack of security resources or too little involvement from the executive board, it’s clear application security is a problem that requires organization-wide collaboration from developers, security practitioners and business leaders.”
Sonatype, a company that manages a central repository of open source software components, uncovered some concerning application security issues related to the use of these components. For instance, 6.1 percent of downloads include a known security defect. This is a big problem, given that use of the components is skyrocketing. Sonatype’s repository for Java components saw 31 billion requests for downloads in 2015, up from 17 billion in 2014.
“The application security professional’s usual response to that is ‘that doesn’t mean those vulnerabilities ended up in our applications,'” said Derek Weeks, a VP and DevOps advocate at Sonatype, in an interview with eSecurity Planet. “But when we looked across 25,000 applications we saw an average of 6.8 percent of components across those apps had at least one known vulnerability. That tells me that from the beginning of the software supply chain to the end products developed through these supply chains, there isn’t enough control.”
While companies know security needs to become a more central part of application development, they are struggling with how to make this happen.
DevSecOps: A New Approach
DevSecOps is a new approach that holds promise, writes Cybric Chief Innovation Officer Mike Kail in a column for eSecurity Planet. Like DevOps, DevSecOps emphasizes collaboration and communication between software developers and other IT professionals while automating many elements of software delivery. Its technological linchpins are virtualization and containerization, and it seeks to create a culture based on the idea that everyone is responsible for security.
“To start adopting a DevSecOps approach means implementing automated sources to scan source code and all libraries up and down the stack in your organization, not just using point solutions,” he writes. “It also means integrating security tools into a common platform via APIs. Everyone in the organization should be empowered to recognize that security is part of their responsibility.”
Whether or not they call what they are doing DevSecOps, many DevOps teams are beginning to adopt some application security best practices, among them standardizing on third-party software and keeping it current and testing preparedness with security games.
Security games or war gaming typically involves creating two teams of developers, operations and security personnel: one team that launches attacks upon their own applications, supporting systems and networks and another that monitors for attacks, identifies breach points and defends the systems, explains Sonatype’s Weeks, in a column written for eSecurity Planet.
War Game Exercises Good For DevOps Teams
In explaining why War Games exercises are a good idea for DevOps teams, Weeks writes: “Let’s face it, no one really wants to be attacked; let alone be a victim of a successful breach. But there are two kinds of companies: those that have been hacked and those who don’t know it. To beat the attackers at their own game, you need to think, plan and attack like them. By purposely subjecting yourself to ethical, friendly fire, you can improve and harden your defenses.”
Ann All is the editor of Enterprise Apps Today and eSecurity Planet. She has covered business and technology for more than a decade, writing about everything from business intelligence to virtualization.
This article was originally published on August 30, 2016