DevOps Demystified: A Primer for Security Practitioners

Key starting points for those still struggling to understand the concept.

Back when I was burning up the ISSA and ISACA speaking circuit, I passed out a quiz before each presentation. The quiz focused on application development terms that an entry-level software developer could easily answer, such as, "what's a software library?" and "what's an IDE?" As I spoke, I'd have a colleague grade the quizzes, and at the end we would announce the results. As you might imagine, my security brethren almost always failed the quiz — most would get three or four questions correct. That's 40%, or, in most classroom settings, an "F."

I'll willingly admit this was an unfair stunt because I knew what the results would be before I handed out the quiz; my point was not entirely to quiz-shame my security colleagues, most of whom did not have development backgrounds. Rather, I wanted to illustrate that without a basic understanding of software development terms, they would be hard pressed to have a meaningful discussion with their software development leadership on the topic of application security.

Today, I worry that security professionals have a similar knowledge gap and struggle to grasp the profound differences that DevOps influence is having on how we build and deploy code in key settings, such as medical device design, digital banking services, and software solutions for oil and gas exploration. I fear that this knowledge gap will cause some to miss a historic opportunity to include consistent security checks and controls in a deployment pipeline where security has been left to the 11th hour, or worse, a total afterthought.

This article is meant to demystify DevOps for security professionals, some who nobly have come to better understand application security terms, and now struggle to understand DevOps and its technology stack. Below you will find key starting points:

1. Recognize the opportunity that DevOps represents. Part of the reason that DevOps has quickly made the transition from obscurity to buzzword is that its positive effect on security has spread like wildfire across industry. Given standardized development "pipelines," the incorporation of DevOps affords the opportunity to "bake in" standard OS and server builds and run application vulnerability scanners as part of software deployment process. No longer do you have to run 11th-hour scans or worry about whether or not the last build introduced a nasty SQL injection that could put your entire web presence at risk. By getting the security team involved earlier in the application development process, the opportunity to strengthen software security becomes tangible.

2. Recognize the trade-off between speed and thoroughness in CI/CD pipelines. The upside of DevOps is building your security testing and baseline configurations into a pipeline. The downside is a smaller testing window to find vulnerabilities. You will have to negotiate with your DevOps pipeline owners to define the window of opportunity for vulnerability scanning — don't expect to be able to conduct a deep scan of the source code in a pipeline.

3. Understand the tool chain. The technology stack in the DevOps world will be foreign to you. It's likely that many, if not all, of the vendors will not be familiar to you. And more than likely you won't find them on the expo floor at RSA or BlackHat. That's OK. Work with your DevOps teams to learn where the vendors fit in the tool chain and where you can add security checks or recommend configurations. When considering release orchestration, testing, security, and application performance monitoring, odds are they will guide you to names like GitHub, Spinnaker, Chef, or Puppet.

4. Become a risk consultant to DevOps leaders. One trend that we are seeing across our enterprise client base is that security leaders are shifting to become risk advisers to the dev teams and DevOps pipeline managers. No longer does the security team wield an audit hammer or maintain the last sign-off before an application goes into production. These teams are no longer responsible for breaking the build for security purposes for arcane or hard-to-understand vulnerabilities. Today, development and DevOps pipeline managers want to release code in a secure fashion and need the security team's advice on what's risky and what isn't.

The door is wide open for security leaders to get on board with DevOps, which, along with the cloud, and even microservices, represents a major shift in how infrastructure and code are deployed. The savvy and sophisticated security leader will take advantage of this shift and capitalize by building security activities into the production pipeline. Leaders will also understand what security limitations DevOps presents and adjust accordingly.

Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

John Dickson is an internationally recognized security leader, entrepreneur, and Principal at Denim Group Ltd. He has nearly 20 years of hands-on experience in intrusion detection, network security, and application security in the commercial, public, and military sectors. As ... View Full Bio

Philips iSite and IntelliSpace PACS, iSite PACS, all versions, and IntelliSpace PACS, all versions. Default credentials and no authentication within third party software may allow an attacker to compromise a component of the system.

Pivotal Cloud Foundry On Demand Services SDK, versions prior to 0.24 contain an insecure method of verifying credentials. A remote unauthenticated malicious user may make many requests to the service broker with different credentials, allowing them to infer valid credentials and gain access to perfo...

Cloud Foundry UAA release, versions prior to v64.0, and UAA, versions prior to 4.23.0, contains a validation error which allows for privilege escalation. A remote authenticated user may modify the url and content of a consent page to gain a token with arbitrary scopes that escalates their privileges...