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.

Endpoint

8/19/2019
10:00 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

Tough Love: Debunking Myths about DevOps & Security

It's time to move past trivial 'shift left' conceptions of DevSecOps and take a hard look at how security work actually gets accomplished.

The security community talks a lot about DevSecOps — look at any vendor's marketing materials. But very few are suggesting any significant changes to the way that security is practiced. DevOps is a fundamental shift in the way we think about building software and is intended to dramatically improve speed and quality. At its core, DevOps prescribes the following:

  • Get work flowing by breaking it into small pieces
  • Create tight feedback loops
  • Create a culture of innovation and learning

The exact problems that used to plague software are still major problems for security. Most organizations only do security on a subset of their code, such as the "critical" or "externally facing" applications and APIs, leaving the vulnerability backlog rampant across the portfolio and the attack visibility practically zero. The truth is, there are a few DevOps myths that are making the problem worse. Here are six:

Myth 1: "DevOps Is All About Automation." The automation is often the most visible part of DevOps, and it may be all that security folks perceive. The reality is that automation can also help to explain how your software factory actually works to the security team. Challenge security to experiment with applying the DevOps techniques to their own work and help them get started on their own DevOps journey.

Myth 2: "We Need to Shift Security Left." "Shift left" is a catchy phrase, but don't just push legacy security tools onto developers who don't have the background to use them. Instead, help developers find modern security tools that integrate into the DevOps pipeline, produce accurate and usable results, and aren't just DevOps lipstick on traditional security tools. Hopefully, your security team will come to realize that security can achieve the same kind of DevOps transformation and benefits as development.

Myth 3: "Increasing Velocity Reduces Security." Security doesn't actually have anything to do with velocity. But often the same automation and processes that lead to high-quality software can be leveraged by security to deliver assurance much faster and more reliably. DevOps actually establishes the infrastructure that security has been lacking for so long. By turning security into code, organizations can dramatically increase the speed, coverage, and accuracy of their security efforts.

Myth 4: "DevOps Makes Security Harder." Many security folks are already overwhelmed with the scale and complexity of their challenge, and they may view DevOps as making their job harder. They may unwittingly slow, derail, or undermine your DevOps transformation, so bring them along on the journey. Include the security team in your planning. Have them read "The Phoenix Project" and have regular interaction with development teams.

Myth 5: "Developers Don't Care about Security." This is one of the most pernicious myths in DevOps. After teaching application security to thousands of developers, my impression is that developers are smart, interested, and curious about security. They want to learn to do things right and avoid security vulnerabilities. Consider that in many organizations, security is poorly defined, a moving target, and full of landmines that can derail projects or careers. Consider becoming part of a development team for a time and working to make security explicit and fully automated so that anytime applications are "clean" they can go into production at whatever velocity the project wants.

DevOps has been widely adopted and has achieved impressive results across a wide array of organizations. It's time to move past trivial "shift left" conceptions of DevSecOps and take a hard look at how security work actually gets accomplished. You'll find massive bottlenecks, wasted effort, duplicated work, feedback loops of weeks, months, or years, and many other problems. Let's call an end to security exceptionalism — there's nothing that special here. The vast majority of security is working on well-understood problems such as injection, path traversal, cross-site scripting, etc. Let's unleash the power of DevOps and radically improve security.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: Modern Technology, Modern Mistakes.

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
mdwydick
50%
50%
mdwydick,
User Rank: Apprentice
8/20/2019 | 10:14:54 AM
How is "Shifting security to the left" a 'myth' ?
Hello!

Overall, I feel like this is an article trying to play 'devil's advocate' for DevOps teams and developers. I understand where you are coming from for most of the claims made on the post and can even get behind some of the 'myths' but the "Shift-left" one does not really make sense. You are not supporting the case that "Shifting security to the left" is a myth, you are merely saying that legacy tools shouldn't be pushed on DevOps teams. A stronger claim would try to explaining that 'shift left' is an impossible task or that it does not result in cost savings, which, is quite the opposite; but that's what I would do if I am trying to debunk that claim.  

Also, shifting secuirty to the left is not just about the tools but also about processes that need to be in place to support secuirty through the pipeline. An example of this would be architecting an application with security in mind, threat modeling, having 'security standards' in place so developers can reference them as they start to code, providing training to developers and DevOps team on application security topics so they can have an existing awareness prior to start building their applications. I feel like the article is norrowing the definition of shift left security to 'archaic tools' when it's quite the oposite (At least in my experience). 

Finally, I would have added a final myth saying that "Security is only the responsability of security professionals" because that is not the case.  In this day and age, everyone in a corporation is responsible for security and should be held accountable for it; if I click on a phishing email, I am sure I would get in as much trouble (if not more) as the team managing the email security tool. So, ultimetely, a better approach would be to marry development and security and have DevSecOps instead of just SecOps. 

Hope to see more DevOps and AppSec articles! :)
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19040
PUBLISHED: 2019-11-17
KairosDB through 1.2.2 has XSS in view.html because of showErrorMessage in js/graph.js, as demonstrated by view.html?q= with a '"sampling":{"value":"<script>' substring.
CVE-2019-19041
PUBLISHED: 2019-11-17
An issue was discovered in Xorux Lpar2RRD 6.11 and Stor2RRD 2.61, as distributed in Xorux 2.41. They do not correctly verify the integrity of an upgrade package before processing it. As a result, official upgrade packages can be modified to inject an arbitrary Bash script that will be executed by th...
CVE-2019-19012
PUBLISHED: 2019-11-17
An integer overflow in the search_in_range function in regexec.c in Oniguruma 6.x before 6.9.4_rc2 leads to an out-of-bounds read, in which the offset of this read is under the control of an attacker. (This only affects the 32-bit compiled version). Remote attackers can cause a denial-of-service or ...
CVE-2019-19022
PUBLISHED: 2019-11-17
iTerm2 through 3.3.6 has potentially insufficient documentation about the presence of search history in com.googlecode.iterm2.plist, which might allow remote attackers to obtain sensitive information, as demonstrated by searching for the NoSyncSearchHistory string in .plist files within public Git r...
CVE-2019-19035
PUBLISHED: 2019-11-17
jhead 3.03 is affected by: heap-based buffer over-read. The impact is: Denial of service. The component is: ReadJpegSections and process_SOFn in jpgfile.c. The attack vector is: Open a specially crafted JPEG file.