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

3/12/2019
04:55 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
The Governance Guru
50%
50%
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.
News
US Formally Attributes SolarWinds Attack to Russian Intelligence Agency
Jai Vijayan, Contributing Writer,  4/15/2021
News
Dependency Problems Increase for Open Source Components
Robert Lemos, Contributing Writer,  4/14/2021
News
FBI Operation Remotely Removes Web Shells From Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/14/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
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
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-28973
PUBLISHED: 2021-04-21
The ABUS Secvest wireless alarm system FUAA50000 (v3.01.17) fails to properly authenticate some requests to its built-in HTTPS interface. Someone can use this vulnerability to obtain sensitive information from the system, such as usernames and passwords. This information can then be used to reconfig...
CVE-2021-29456
PUBLISHED: 2021-04-21
Authelia is an open-source authentication and authorization server providing 2-factor authentication and single sign-on (SSO) for your applications via a web portal. In versions 4.27.4 and earlier, utilizing a HTTP query parameter an attacker is able to redirect users from the web application to any...
CVE-2021-31523
PUBLISHED: 2021-04-21
The Debian xscreensaver 5.42+dfsg1-1 package for XScreenSaver has cap_net_raw enabled for the /usr/libexec/xscreensaver/sonar file, which allows local users to gain privileges because this is arguably incompatible with the design of the Mesa 3D Graphics library dependency.
CVE-2020-23907
PUBLISHED: 2021-04-21
An issue was discovered in retdec v3.3. In function canSplitFunctionOn() of ir_modifications.cpp, there is a possible out of bounds read due to a heap buffer overflow. The impact is: Deny of Service, Memory Disclosure, and Possible Code Execution.
CVE-2020-23912
PUBLISHED: 2021-04-21
An issue was discovered in Bento4 through v1.6.0-637. A NULL pointer dereference exists in the function AP4_StszAtom::GetSampleSize() located in Ap4StszAtom.cpp. It allows an attacker to cause Denial of Service.