This is part two of a two-part blog series on a presentation by Hooper Kincannon, Cyber Security Engineer at Unum Group, on “Secure from the Start: A Case Study on Software Security” at the Gartner Security & Risk Management Summit in National Harbor, MD. In this presentation, Hooper provided a great blueprint for starting a DevSecOps program. In part one, I summarized how Hooper got buy-in for his program and his overall plan for the initiative. In this blog, we delve into the details.
Hooper kindly shared his slides with us. Here is his helpful comparison of different assessment types, focusing on static analysis, dynamic analysis and manual penetration testing:
You have to make a choice which route you’d like to take. In Hooper’s case, he decided to build static and dynamic application security into the SDLC.
For dynamic analysis testing, Hooper recommeds the following workflow:
To make your DAST assessments successful, he recommended using a consistent scan duration, considering the various authentication mechanisms, and using the testing credentials only for testing.
For static analysis testing, he recommended the following workflow:
His recommendations for static analysis testing included being conscious of how you define applications, being aware of compilation instructions, and consistency of the process.
After you have identified a vulnerability, you can address it in two different ways:
How you use your scan results can make or break your program. If you’re fortunate, you’ll scan your application and get back a low volume of flaws. If you’re unlucky, it may be the opposite.
Hooper’s biggest recommendation is not to panic: The overall goal is to reduce risk, and that won’t happen overnight. Take your time to digest the results and discuss how to best prioritize them. For example, consider fixing dynamic results first because they are easier to discover by an attacker. Decide what you accept as trusted sources, especially in the case of input validation, and have a process for handling exceptions, such as acceptable risk, mitigations, and false positives. Hooper recommends that you do a readout of the results with the stakeholders.
Metrics are probably the most important deliverable coming out of your program. Security is a difficult metric to measure; reduction in risk is a bit easier.
Metrics that worked for Hooper are:
When presenting to the different stakeholders of the program, be aware of what each constituency is interested in – because it varies:
Keeping a regular cadence is vital. Hooper has made these activities part of his program:
One year after starting the program, Hooper had reached success with external high-risk applications. Next, he moved on to internal high-risk applications. In addition, he started to automate more and more of the program to make it repeatable and easier to manage. For most organizations, he recommends starting out with automation from day one, but even if you start out manually, you’re taking a step in the right direction.
Here is a picture of how Unum Group integrates Veracode into their SDLC:
If you’re interested in starting your own application security program, read our take on Everything You Need To Know About Getting Application Security Buy-In.