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

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.
Aviation Faces Increasing Cybersecurity Scrutiny
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/22/2019
Microsoft Tops Phishers' Favorite Brands as Facebook Spikes
Kelly Sheridan, Staff Editor, Dark Reading,  8/22/2019
Capital One Breach: What Security Teams Can Do Now
Dr. Richard Gold, Head of Security Engineering at Digital Shadows,  8/23/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-15540
PUBLISHED: 2019-08-25
filters/filter-cso/filter-stream.c in the CSO filter in libMirage 3.2.2 in CDemu does not validate the part size, triggering a heap-based buffer overflow that can lead to root access by a local Linux user.
CVE-2019-15538
PUBLISHED: 2019-08-25
An issue was discovered in xfs_setattr_nonsize in fs/xfs/xfs_iops.c in the Linux kernel through 5.2.9. XFS partially wedges when a chgrp fails on account of being out of disk quota. xfs_setattr_nonsize is failing to unlock the ILOCK after the xfs_qm_vop_chown_reserve call fails. This is primarily a ...
CVE-2016-6154
PUBLISHED: 2019-08-23
The authentication applet in Watchguard Fireware 11.11 Operating System has reflected XSS (this can also cause an open redirect).
CVE-2019-5594
PUBLISHED: 2019-08-23
An Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") in Fortinet FortiNAC 8.3.0 to 8.3.6 and 8.5.0 admin webUI may allow an unauthenticated attacker to perform a reflected XSS attack via the search field in the webUI.
CVE-2019-6695
PUBLISHED: 2019-08-23
Lack of root file system integrity checking in Fortinet FortiManager VM application images of all versions below 6.2.1 may allow an attacker to implant third-party programs by recreating the image through specific methods.