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! :)
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
Fed Kaspersky Ban Made Permanent by New Rules
Dark Reading Staff 9/11/2019
NetCAT Vulnerability Is Out of the Bag
Dark Reading Staff 9/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
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
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16395
PUBLISHED: 2019-09-17
GnuCOBOL 2.2 has a stack-based buffer overflow in the cb_name() function in cobc/tree.c via crafted COBOL source code.
CVE-2019-16396
PUBLISHED: 2019-09-17
GnuCOBOL 2.2 has a use-after-free in the end_scope_of_program_name() function in cobc/parser.y via crafted COBOL source code.
CVE-2019-16199
PUBLISHED: 2019-09-17
eQ-3 Homematic CCU2 before 2.47.18 and CCU3 before 3.47.18 allow Remote Code Execution by unauthenticated attackers with access to the web interface via an HTTP POST request to certain URLs related to the ReGa core process.
CVE-2019-16391
PUBLISHED: 2019-09-17
SPIP before 3.1.11 and 3.2 before 3.2.5 allows authenticated visitors to modify any published content and execute other modifications in the database. This is related to ecrire/inc/meta.php and ecrire/inc/securiser_action.php.
CVE-2019-16392
PUBLISHED: 2019-09-17
SPIP before 3.1.11 and 3.2 before 3.2.5 allows prive/formulaires/login.php XSS via error messages.