DevOps, the word, is a combination of “development” and “operations”. It represents more than just a team or a process or an idea. DevOps is actually an organizational culture or practice aimed at rapidly and continuously delivering software that is more reliable and more secure.
Whatever the definition, it is understood that the concept of DevOps is broad and must be implemented across several teams within an organization to achieve the desired results. The main goals are faster time to market, shortened release cycle and low rate of release failure. DevOps demands efficiency and speed at every point in the delivery cycle, from planning through to release. Automation tools are increasingly employed to achieve these goals, and a higher level of integration between teams in an organization.
Where does security fit in? Most organizations have some idea about how to make their software more secure, but the strategies are often at odds with the goals of their DevOps culture. The primary security-related challenge faced by organizations switching to DevOps is that the development organization modifies code faster and more often than the security team can keep up with. These are the top three challenges.
The security team doesn’t have time to perform proper security architecture reviews for each change.
Traditional threat modeling, security architecture review and security requirements compilation are time consuming and manual tasks that can easily add significant delays to software releases that defeat the purpose of DevOps practices. Security requirements management tools can be employed to automate much of this process and reduce the amount time it takes. This allows the practice to be repeated with more frequency and consistency without compromising on the level of quality in the product. Automation also helps ensure that nothing falls through the cracks for any application — either internal corporate standards or industry compliance specifications. Distinguishing between domain-agnostic and domain-based threats is critical in determining which parts of the threat modeling process can be automated.
The security team is unable to effectively communicate and track security requirements with the development team.
Efficient development and implementation is critical in a DevOps environment as this can often take the most amount of time, and any issues encountered can greatly affect the release schedule. Adding security requirements into the equation can slow down the process if the developers don’t know how to handle them, or are not familiar with security principles.
Effective teams need a platform that automatically delivers security requirements as work items/tickets directly to the developer’s Application Lifecycle Management (ALM) system (eg. JIRA), so they don’t have to change their workflow. Security requirements should exist comfortably in an Agile/Scrum backlog and prioritized alongside functional requirements. This keeps the development machine working with little resistance due to security requirements. Automation can assist in executing a simple principle: the earlier threats are addressed, the cheaper and quicker they can be avoided. SHIFT LEFT.
“Just in Time” training can help developers be more productive with secure coding. This concept is supplemental to up-front training, which is great for giving developers a baseline of security knowledge to work from. But what if they come to a problem and forgot some of the relevant concepts? What if they didn’t have time to do all the training before starting a project? “Just in Time” training can help deliver training to a developer as they are working on mitigating a specific threat. The training should have all the information that a developer needs to address the issue, including background, solution, code samples, or even computer based training modules. This saves time because they don’t have to research the solution on their own. It also makes a better developer because they are learning as they go.
The development team doesn’t have time to deal with all the findings from application security testing (AST) tools.
Security requirements, both functional and non-functional, must be validated through testing. In the last 10 years, tools have been developed to test application security, such as IBM AppScan, HP Fortify, Veracode, WhiteHat and CheckMarx. Static Application Security Testing (SAST), can scan source code files to detect and report common pitfalls in secure development. This can only occur once development actually begins. Dynamic Application Security Testing (DAST) happens after source code is compiled into an application, and runs a set of known attacks against an application. These tools are essential to the secure development process, and can be easily automated. Test automation, however, can cause problems in a DevOps environment if there are a large number of ‘findings’ reported by the scanning tools. Each finding must be addressed and fixed by the development team which can introduce uncertainty and risk into the schedule. Vulnerabilities found at this stage of the SDLC are often costly and time-consuming to remediate if the underlying architecture needs to be re-examined. If vulnerabilities and their associated mitigations are addressed earlier in the SDLC via security requirements management, then far fewer findings will occur at the testing stage. Fewer findings means less times spent on remediation, and getting the release out faster.
Scanning tools are only part of the story. In the 2014 Gartner research paper, Application Security: Think Big, Start With What Matters, it is said that “traditional AST really only covers about 40% or less of your codebase.” Our own internal analysis revealed that AST tools (SAST and DAST combined) only detect up to 54% of all known application vulnerabilities. This leaves a whopping 46% of all known vulnerabilities that cannot be detected by any AST tool. More effort is needed to implement test cases for all security requirements in a given project, to bridge this gap. Many organizations employ automated tools such as JUnit (back-end) and Selenium (front-end) to manage this in a DevOps environment. The security requirements platforms play a role by defining a prescriptive set of test cases so that development teams can build custom unit tests for each application. This ensures 100% test coverage for each application, including vulnerabilities that are not caught by regular scanners.
In general, the guiding principle is that security activities must happen faster in order to fit into Agile/DevOps (other rapid release cycle) processes. Employing security requirements management and automation at multiple stages of the development lifecycle is an effective strategy to improve security while maintaining a rapid cadence of releases.
Authored By: Shane Parfitt