The technology industry moves from one buzz word to another, and when it comes to working practices and techniques to make us deliver better value, quicker, DevOps springs to mind. Just as people are getting used to DevOps, say hello to DevSecOps. In this post, I’m going to share some thoughts about what it means and why you shouldn’t panic.

DevOps and DevSecOps, what’s the difference?

This is a great question and much like the question “What is DevOps?”, has numerous answers, so does DevSecOps. In short, you will not be shocked to learn we are talking about development, security and operations. The mantra is really to ensure everyone is accountable for security.

The objective is that when it comes to implementing security decisions and the actions associated with it, happens at the same speed as development and operations.

It’s true that the two methodologies share similar aspects, including the use of automation and continuous processes to enable greater collaboration cycles. The major difference comes where DevOps prioritises speed of delivery, DevSecOps shifts security to the left.

Establishing some basics

First of all, let’s talk about some high level facts from data breaches from the brilliant people over at Information is Beautiful, for context, everything here is up to the end of 2019.

  • 62% of breaches are due to hacking
  • 6% of breaches are due to mistakes
  • 6% of breaches are insider jobs
  • Hacking accounts for two thirds of breaches, however half the number of personal records are stolen compared to poor security
  • Lost devices account for 13% of breaches but only 1% of the total records lost
  • 70% of the most common passwords are exploited in this data.

So what have we learned. First of all, organisations which look at only a couple of attack vectors are making a huge mistake, you need to be spreading your spend over all vectors for your industry and weighting spend depending on risk.

Although this isn’t mapped in the data, the second and biggest point is tooling. Even in security, less is more. The more security tooling you have the harder it is to collaborate across your organisation.

What hinders security innovation?

Most organisations fall behind when it comes to security because of a few major reasons, of course many more exist but I believe these are the most common.

  • Manual processes and culture
  • Point in time assessments
  • Friction with InfoSec teams
  • Misunderstanding of context
  • Political interference internally
  • Fear of failure
  • Lack of external thinking

The art of achieving levels of collaboration, automation and continuous feedback to improve your security and make it integral to your efforts is around breaking down the points above which exist in your organisation.

The DevOps, Sec ratio

Now for the key part of this article really and the whole concept of “everyone is responsible for security”. Think of it this way, numbers matter when it comes to defending the realm. Skills help but anyone has the ability to identify an anomaly.

Take the above image, for example, for every 100 operations engineers we have, we may have 10 developers and one (just one) security engineer, and that security engineer, is hard to find and cannot do everything. So pool your resources, you now have 111 people who can help identify those anomalies.

The art of DevSecOps

The art of doing security properly within a DevOps context, yes I mean DevSecOps is broadly split into four teams, these teams may not be separate teams either. Each of those teams also have distinct responsibilities, these are mapped out in the following table.

TeamResponsibility
Security EngineeringExperiment, automate and test
Security OperationsHunt, detect and contain
Compliance OperationsRespond, manage, train
Security ScienceLearn, measure and forecast

Security is a design constraint

Security has to be built-in to be effective, it has always been a design constraint and it always will be. Anything you build is only as safe as where you put it, what it’s in and how you inspect it, what talks to it and how that is protected.

If you can remember one thing from this article, I want it to be what is at the above, these are the five principles of security practice, which are; Encryption, Authentication, Logging, Asset Management and Zoning & Containment.

Security as code

Back on track to be more about DevOps now, the key thing is to implement your security as code. Paper policies simply do not stand up the to constant evolution of cloud and lessons learned from continuous feedback.

Summary

Of course all this is great, but without continuous feedback which is effective as well as appropriate measures in place to get high fidelity feedback that is clearly actionable by development teams, you will go nowhere fast.

For me, DevSecOps is fundamentally about two things, firstly and importantly it’s bringing security into that DevOps culture in your organisation, secondly, it’s about shifting left the responsibilities involved in information security, taking you away from a small team of experts to a broad team of domain experts about their product, who better to understand it than the people who wrote it and manage it.

Finally, I want to set out five foundations for your DevSecOps journey.

  • Don’t measure at a team level, measure globally – Security’s goal is to help the business achieve goals, avoid siloed thinking.
  • Measure outcomes vs outputs – Measuring work is not tied to tangible outcomes.
  • Maturity – Prioritise resilience over a notion of maturity, that comes with time.
  • Don’t miss the forest for the trees – Focusing on components too much can mean missing the bigger picture.
  • Don’t try to measure failure – Failure is inevitable, incentivizing failure avoidance is unrealistic at best.