Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

04:55 PM
Connect Directly

How the Best DevSecOps Teams Make Risk Visible to Developers

DevOps-minded CISOs say enterprise security teams need to do a better job scoring and visualizing risk for developers and business executives.

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."

Related Content:




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.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
The Governance Guru
The Governance Guru,
User Rank: Strategist
3/12/2019 | 10:57:03 PM
Comprehensive action items for DevSecOps practitioners
This post couldnt have said it better to demonstrate the different things that every DevSecOps practitioner should try to incorporate into their program. I think this will help further the "Security as Code" culture that is so important to embrace. Also establishing this simple, effective score is almost analogous to the NPS score that companies are using to see how they are doing with their customers.
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Look Beyond the 'Big 5' in Cyberattacks
Robert Lemos, Contributing Writer,  11/25/2020
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: I think the boss is bing watching '70s TV shows again!
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-12-01
Privilege Escalation vulnerability in Microsoft Windows client McAfee Total Protection (MTP) prior to 16.0.29 allows local users to gain elevated privileges via careful manipulation of a folder by creating a junction link. This exploits a lack of protection through a timing issue and is only exploit...
PUBLISHED: 2020-12-01
containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim’s API socket verified that...
PUBLISHED: 2020-12-01
FusionCompute versions 6.3.0, 6.3.1, 6.5.0, 6.5.1 and 8.0.0 have a privilege escalation vulnerability. Due to improper privilege management, an attacker with common privilege may access some specific files and get the administrator privilege in the affected products. Successful exploit will cause pr...
PUBLISHED: 2020-12-01
HUAWEI nova 4 versions earlier than and SydneyM-AL00 versions earlier than have an out-of-bounds read and write vulnerability. An attacker with specific permissions crafts malformed packet with specific parameter and sends the packet to the affected prod...
PUBLISHED: 2020-12-01
HCL iNotes is susceptible to a sensitive cookie exposure vulnerability. This can allow an unauthenticated remote attacker to capture the cookie by intercepting its transmission within an http session. Fixes are available in HCL Domino and iNotes versions 10.0.1 FP6 and 11.0.1 FP2 and later.