One of the biggest challenges security practitioners and leaders face in their mission to embed application security (AppSec) into the software development life cycle is a lack of engagement from developers. Leaders in DevSecOps teams who've tackled this challenge say that contrary to popular belief among cybersecurity pros, the root problem has nothing to do with developer apathy.
Instead, they say that security has done a lousy job making AppSec risks truly visible to developers — and to the line of business.
More fundamentally, traditional cybersecurity practices are not providing the kind of actionable feedback to developers that helps them figure out how to make changes in their daily work that will actually reduce AppSec risk. On the flip side, providing this kind of metrics-driven security feedback is where the DevSecOps approach truly excels, as shown by a number of key practices shared last week at the RSA Conference (RSAC) by security leaders from the likes of Target, Comcast, Mastercard, and Highmark Health.
"We fundamentally believe that developers want to create secure applications, and it is our job as security practitioners to make that as easy as possible for them to do," said Jodie Kautt, vice president of cybersecurity for Target.
Kautt was one of several DevOps-minded security leaders to take the podium as a part of the DevSecOps Days program at RSAC, in which a key theme that bubbled up was how mature DevSecOps teams are making metrics more relatable and contextualized for developers and business stakeholders. What these teams realized is that laundry lists of unresolved vulnerabilities and huge, dusty policy tomes simply do not move the needle on developer behavior.
As an alternative, they shared a number of tips and best practices to start driving risk discussions based on data and business context.
Let Data Be Your Guide
Getting the security message across to developers, operations staff, application owners, and business leadership doesn't have to be an uncrackable problem, said Anna Marie Zettlemoyer, vice president of security engineering for Mastercard. The best risk leaders make their case by finding the right metrics to tell their story.
"Let data be your guide, part of your analysis, and part of your influence," Zettlemoyer said. "Even when teams don't speak the same language and we just aren't understanding each other, the data can be a really great common denominator. People might not trust you at first, but they will trust the numbers."
Use Audience-Centric Metrics
But not just any numbers will do. They've also got to be audience-centric to really make an impact, said Omar Khawaja, CISO for Highmark Health.
"If I'm going up in front of the board. do you think I'm going to present to them the number of vulnerabilities in our applications? Do you think the board even knows what that means?" he said. "No. they care about business risk."
He said it's much more valuable for security people like himself to partner with people in business continuity, application owners and start cross-referencing the vulnerability statistics against the business criticality of affected applications to give the numbers context — and then simplify scoring so that it is possible to show the state of security in the most critical apps. Similarly, Zettlemoyer said security leaders should be developing metrics that as much as possible show the bottom-line impact of security risks.
"So, make friends with your accountants to help you figure out where that impact is going to be on the balance sheet," she suggested.
Establish Transparent Risk Scoring
Some organizations, including Target, have evolved the contextualization and simplification of security metrics by developing consistent application risk scoring. At Target, the security team developed what the company calls the Product Intelligence score, which wraps in data from its vulnerability databases, GRC tooling, application management systems, dynamic scanning information, penetration tests, and the like. It weighs the output from those systems against business criticality of the application being scored, and also accounts for things such as the types of security services used by the development team and whether or not the team has a trained "Security Ninja," or security champion, in its ranks. The output of all of that information is a single score that ranges anywhere from 300 to 850.
"It all comes down to one number — think of that number as your credit score," said Kautt, who explained that this score makes it easy to measure product and application teams across the board at the company, and to show visible security gains made over time on each application.
Key to simplifying with scoring is being extremely open about how the scores are developed.
"The score is transparent," said Jennifer Czaplewski, director of product security for Target. "We give them all of the information that they need so they don't just have to trust us that their score is 745 but that they can see for themselves how it was derived."
Creating Simplified Dashboards
The transparency of Target's Product Intelligence score is delivered through a dashboard that links to the data sources that Czaplewski and Kautt mentioned. In addition, the dashboard contextualizes how an application's Product Intelligence score compares with other applications in the Target portfolio. Another crucial element is that it visualizes and explains what teams need to do to start improving their scores.
"It's not just the simplicity of the number that has made this so successful for us, but it's that we highlight which actions teams can take in order to improve their Product Intelligence," Kautt said. She and Czaplewski said they've done all of this with just a pair of software engineers and open source tooling from Apache Superset.
This sounds remarkably similar to the approach taken by Larry Maccherone and his team at Comcast. As senior director of DevSecOps transformation for Comcast, Maccherone has led the charge to develop a dashboard tool that visualizes each application team's progress on a handful of key security practices. He recommends that any security team thinking of using an interactive dashboard as a means of self-assessment and accountability for development teams not get hung up in the minutiae of which key practices to measure but instead pick something and start doing it. Just like DevOps teams iterate with software, security teams should seek to create a minimum viable dashboard and iterate on it as they go along.
"There are lots of starting points beyond the ones we chose," he said. "What I want you to focus on here though is how we use this."
According to him, it's all about getting developers, application owners, and executives focused on making incremental changes to the risk posture of their software. One of the most valuable ways that both Comcast and Target are using scoring and dashboarding is to provide senior management with a way to hold product teams and developers accountable for the security of their applications.
For example, the security team trained the president of Comcast to read their visualization and engineering leads are required to bring their scores to meetings with the president about their progress on development work.
The more visible the risk is, the more embedded security awareness and improvement becomes within the business culture of an organization. When organizations start to enact the kinds of practices named by DevSecOps leaders at RSAC, good things start to happen organically.
"It was music to my ears when I walked into a CIO staff meeting a couple weeks ago and heard two officers bantering back and forth about where they were ending up with their scores at the end of the year," Kautt said, explaining that she's also seen teams throwing parties when they make their yearly Product Intelligence scoring goals. "Security is now driving the culture, without us asking for any of that."
Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.