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

4/20/2018
06:00 PM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

Trust: The Secret Ingredient to DevSecOps Success

Security practitioners must build trusted relationships with developers and within cross-functional DevOps teams to get themselves embedded into continuous software delivery processes.

RSA CONFERENCE 2018 - San Francisco - As evident by the speaker tracks and hallway discussions here this week at the RSA Conference, the marriage of DevOps and security principles driving the DevSecOps movement is finally gaining traction in the security community.

Old pros in cybersecurity are finally moving past the denial stage - "No, DevOps isn't a fad. Yes, it's possible to bake security into it." Now comes the hard part of evolving the security mindset, practices, and tools to suit the fast pace of DevOps methods and toolchains. 

There are a lot of logistics that go into the process, but the foundational effort that DevSecOps veterans say should to trump all others is that of trust-building. 

"You have to start with building trust. In order to do that, the first thing it takes is listening and understanding the development team's challenges," explained Bankim Tejani, senior manager of digital product security for Under Armour. "What are they trying to accomplish? How are they doing it? Why they're using this particular tooling? What kind of scale are they gaining out of it? What kind of efficiencies are they gaining out of it? Then align what you're doing with security to that, to support that."

This was a theme that continually came up during Monday's DevOps Connect event, and it was further expounded upon by appsec experts and DevSecOps-savvy security leaders here this week. Security and development experts explained that at the end of the day, failed attempts to add security into the DevOps process can be chalked up to a fundamental lack of trust from the dev team.

Security's attempts to force impractical policies and overly ambitious fix rates cements the belief in DevOps teams that security won't ever understand what it means to deliver software in modern enterprise. And when the developers don't believe security has their back, they stop answering security team emails. They stop attending meetings called by the CISO's minions. And they otherwise disintermediate security from the day-to-day processes of delivering software. At that point, the security team enters the "nag zone."

According to a survey released this week by Sonatype that primarily questioned the developer community, 72% of participants see security not as trusted partners, but as "nags." That nag cred is quickly earned when the security team goes to the developers with binders full of vulnerabilities that are unprioritized and have no guidance for how they need to be fixed with a mandate that they're all acted upon.

Caroline Wong, vice president at Cobalt.io and a speaker at the conference, owned up to this kind of activity in past lives at organizations like eBay and Zynga. She explained that the path to DevSecOps epiphany and improved trust was to stop mandating and start asking questions.

"The first thing that we started to try to do was to ask some questions that we had not asked before. Specifically, what's important to you? Asking the developers and the technology teams, 'What are you trying to accomplish?'" she says. "It turns out, developers have things like quarterly goals and deadlines and they're trying to make new features so they can make money for the business. And when we were approaching them with these piles of work to do, that did not instill trust."

The more her teams could do the work of prioritizing the vulnerabilities that really meant something to the business risk posture and the work of advising developers to find a path to making fixes, the more trust her team could build.

It's also crucial for security teams to do a reality check and honestly decide what kind of security improvements can be asked for in the context of demands made on developers by the business. For example, when her appsec team asked developers how much time they could honestly spend on the rework of vulnerability fixes, the honest goal that they came up with together was a 20% reduction in flaws on customer-facing websites.

"Now 20% is not a number that security people like. Security people like a number like 90%, or a number like a number like 95%," she says. "But if we'd gone in and said 'We're going to try to eliminate 90% of the bugs on the website,' we probably would've gotten the same response that we got before, which was people stop coming to our meetings, people stop inviting us to our meetings, people stop reading our e-mails."

Ultimately, security people need to keep a couple of core interpersonal elements in mind when they're establishing trust within DevOps teams, says Larry Maccherone, who is currently driving a DevSecOps transformation at Comcast as the senior director in the company's Technology and Product division's Security and Privacy group.

"I have this formula for trust. It's credibility, plus reliability, plus empathy, all divided by apparent self-interest," he says. "Now, self interest is never zero. I wouldn't be spending my time talking to you if there wasn't some self-interest. But the more of that there is the more you need on the numerator to make up for that."

So as security professionals building trust with devs, it means establishing credibility by understanding the developer tools and developer lingo inside and out. Maccherone does this by exclusively hiring developers on his security staff. It means having developer's backs by doing the stuff you tell them you're going to do.

And it means really striving to understand the developer's ethos, to empathize with the things they struggle with. All of that makes it a lot easier for devs to trust you as a security person when you turn around and start asking for things, he said.

As a part of that equation, it's also important to remember the simple life principle that you've got to give a little to get a little. As Paula Thrasher, director of digital services at government integrator CSRA, explained, one of the first situations she worked in that truly established trust was where embedding security tools into an overall developer tool chain ended up speeding up the development process, while also making it more secure.

"That was a huge 'ah-ha' moment for me. That to really bring adoption, one it has to be really collaborative, but two there's got to be a compelling case for the effort that developers have to put in, they're going to get something back out of it," she said.

Related Content:

 Interop ITX 2018

Join Dark Reading LIVE for two cybersecurity summits at Interop ITX. Learn from the industry’s most knowledgeable IT security experts. Check out the security track here. Register with Promo Code DR200 and save $200.

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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/23/2020
Modern Day Insider Threat: Network Bugs That Are Stealing Your Data
David Pearson, Principal Threat Researcher,  10/21/2020
Are You One COVID-19 Test Away From a Cybersecurity Disaster?
Alan Brill, Senior Managing Director, Cyber Risk Practice, Kroll,  10/21/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-27743
PUBLISHED: 2020-10-26
libtac in pam_tacplus through 1.5.1 lacks a check for a failure of RAND_bytes()/RAND_pseudo_bytes(). This could lead to use of a non-random/predictable session_id.
CVE-2020-1915
PUBLISHED: 2020-10-26
An out-of-bounds read in the JavaScript Interpreter in Facebook Hermes prior to commit 8cb935cd3b2321c46aa6b7ed8454d95c75a7fca0 allows attackers to cause a denial of service attack or possible further memory corruption via crafted JavaScript. Note that this is only exploitable if the application usi...
CVE-2020-26878
PUBLISHED: 2020-10-26
Ruckus through 1.5.1.0.21 is affected by remote command injection. An authenticated user can submit a query to the API (/service/v1/createUser endpoint), injecting arbitrary commands that will be executed as root user via web.py.
CVE-2020-26879
PUBLISHED: 2020-10-26
Ruckus vRioT through 1.5.1.0.21 has an API backdoor that is hardcoded into validate_token.py. An unauthenticated attacker can interact with the service API by using a backdoor value as the Authorization header.
CVE-2020-15272
PUBLISHED: 2020-10-26
In the git-tag-annotation-action (open source GitHub Action) before version 1.0.1, an attacker can execute arbitrary (*) shell commands if they can control the value of [the `tag` input] or manage to alter the value of [the `GITHUB_REF` environment variable]. The problem has been patched in version ...