DevSecOps Automation

September 2017 ยท 5 minute read

Why automate security?

One of the key tenets of the DevOps movement is to reduce bottlenecks and improve speed and efficiency.

Want to know one of the most inefficient processes in the SDLC (software development life cycle) right now? Security.

Want to know why? Two reasons- manual processes and lack of resources (i.e. people).

Manual processes

Traditional security processes are laden with manual processes, including…

  • Secure code reviews
  • Penetration tests
  • Developing security guidelines
  • Security audits (think PCI and ISO 27001 checklists)

And even when we do automate things using our big shiny tools, we spend half our time manually combing through the results looking for false positives!

100:10:1

100:10:1. This is the ratio of developers to operations to security in the average technology organization today (source). And if you just read that and said, “we’re not a technology organization, so that number doesn’t apply to us”, think again.

Every company is a technology organization!

If you’re developing software or integrating systems and networks into your business, then guess what- you’re a technology organization. If you’re still not convinced, answer the following question honestly- what would happen if suddenly your systems, applications, and network stopped working? If the answer doesn’t scare you, then congratulations- you’re living in the 16th century; I don’t know how you’re reading this article right now. (However, if you do ever make it to 2017, bet on the Warriors in the playoffs. Trust me, you won’t regret it.)

This ratio cannot and does not scale when all our processes are manual ones. Think about it- if 100 developers are waiting on 1 security engineer to test their code before deploying it to production, and the security engineer’s processes take him even half a day to execute… that’s a 50 day delay between code being ready and being released into production! Nevermind the fact that these numbers will simply compound over time, AND that’s assuming the security engineer finds no defects!

Bottleneck This is the bottleneck that results from the 100:10:1 ratio and manual processes

So how does security keep up with the speed of DevOps? We’re going to have to take a page from our developers’ playbook and build out an automation pipeline to match their development pipeline.

Security pipeline

It is only through building a security pipeline that mirrors our development pipeline that we can easily integrate security into existing development processes. I’ve spoken about this at ToorCon, but here are the key points to remember when building out your security automation pipeline:

  • Start small, with existing security tools (Fortify, AppScan, WebInspect, etc.) acting as compensating controls in the meantime.
  • Build modular tools that allow for flexibility of both platforms and programming language. Tools like Docker help with this.
  • Reduce repeated mistakes that you’re seeing in your applications. By focusing on getting rid of these first, you will get some quick wins for your program, which is key to keeping top level support. Not only that, the hardest part is often knowing where to start; looking at past mistakes makes this part easy.
  • Use unit tests for security tests. Developers likely already use unit tests to prevent bugs from popping up, why not use it to prevent previous security vulnerabilities as well?
  • Using infrastructure as code (through tools like Ansible, Chef, and Puppet) allows you to target your systems as well as your applications.
  • Automate detections of exploits found in pentests. Pentests are still important for catching the more complex security vulnerabilities that may be present in your applications. But the same issues should not be coming up every quarter. Instead, you can use your pentest results as a source for automated tests (this can be the hardest part, remember?).
  • APIs are key. All of your tools (be they custom or off-the-shelf) should have APIs. Period. This makes integrating them together much easier than trying to glue together different languages, platforms, and formats.
  • Make results actionable. Don’t waste your developers’ time sifting through false positives or trying to understand what the problem really is. Whenever possible, include a proof-of-concept exploit scenario that allows them to understand how the problem is really a problem.

Where to start

Remember how I said the hardest part is knowing where to start? Here are a few resources you can use to understand what you should be testing for first:

  • SD Elements: plug in what type of application you’re building, and you’ll get a list of things your developers need to do to ensure that they are writing secure code in that environment. This can also be a list of things to begin testing for in your applications right away.
  • OWASP Top 10 Cheat Sheet: There are some really good recommendations in here around the OWASP top 10. This is a good launching point if you’re trying to secure web applications.
  • CWE/SANS Top 25 Most Dangerous Software Errors: An oldie, but a goodie. This is a list of common security vulnerabilities present in applications. While it came out in 2011, it’s still just as relevant today.
  • Old findings and mistakes: I stated it above, but it bears repeating because it is just so critical. Tackle old findings and vulnerabilities first, because if they showed up once, they’ll likely show up again. Don’t let that happen.

DevOps - one final point

If you’re scared of this whole DevOps movement, I understand. We’re moving faster and faster, when security has historically been the one to slow things down. If you’re not yet convinced of the importance of speeding up deployment of applications, consider this…

The goal of DevOps is to help speed up the release of software. That means features get pushed faster, we can test our hypotheses faster (think A/B testing), and bugs get fixed faster. But guess what else? Security vulnerabilities can get fixed faster too.

Slow realization

If that last point doesn’t get you excited about DevOps, I don’t know what will.

Final takeaway

If you remember one thing about this whole concept of building a security automation pipeline, remember this:

Your goal should be to build an integrated system, with actionable results.

By building automation into our security practices, we overcome the bottleneck that results from manual processes and a lack of resources, and enable our security program to match the speed of DevOps.