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.
Using Different Assessment Types for the Right Purpose
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.
Dynamic and Static Analysis Workflow
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.
Understanding Remediation vs. Mitigation
After you have identified a vulnerability, you can address it in two different ways:
- Remediation: Fixing the security defect by changing the code that contains the defect or making a configuration change. This eliminates the risk.
- Mitigation: Implementing controls to make it less likely that the vulnerability is exploited. This reduces the risk but does not eliminate it because the vulnerability is still present in the code.
Working With Scanning Results
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.
Picking the Right Metrics to Report On
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:
- Flaw density
- Risk reduced (vulnerability severity reduced)
- Most common flaw types (use to guide education efforts)
- Compliance over time
- Onboarding time + other operation metrics
When presenting to the different stakeholders of the program, be aware of what each constituency is interested in – because it varies:
- CISO + senior management: Profitability of the investment
- Business leaders: Resource allocation
- Development: Staying on top of flaws
Keeping a regular cadence is vital. Hooper has made these activities part of his program:
- Monthly scorecards
- Monthly executive dashboards
- Annual reviews
- Real-time dashboards for developers
Optimizing the Program in Year Two
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:
For More Information
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.