On Friday 27th September our annual Inspire event took place and I got to host two sessions. One of them on applying security practices next to the more regular DevOps practices. I presented this session with my colleague Boaz Pat-El.

Of course, this blog could also have said: “what’s so hard about making security an integrated part of DevOps”, or just plain “What’s so hard about DevSecOps”. Also, I’m aware that there is a debate on the use of the term DevSecOps, but for now we’ll leave that for what it is.

State of DevOps Report 2019

Two days before this session the new annual State of DevOps report by Puppet was released and this year the focus was on security! One of the things measured in this year’s survey was in how many of phases did the respondents have security integrated. The following phases were given: requirements, design, building, testing, and deployment. In the below graph you see the percentage of respondents at each level of security integration. 

Figure 1: percentage of respondents at each level of security integration (source: 2019 State of DevOps Report)

Why is it so hard to integrate security?

It is clear security is very far from being well integrated in the different phases a typical project goes through. Why is that? Why is it so hard to integrate security in our way of work? The report mentions two main reasons for this:

1. Efforts will stall in the middle as we come to optimizing processes once we’ve accomplished the low-hanging fruit tasks. This is also where the business needs to be flexible, to accommodate developers and optimize throughput. It must change its processes to allow teams to collaborate with speed by removing unnecessary manual approval steps and look for ways to implement the required controls and traceability within an automated system.
2. As an organization evolves, teams go from adopting automation to address local pain points — for example, automating the deployment of a single service or application — to automating business processes that touch many teams.

Next to these I think there are a few more reasons it is so hard to integrate security:

• The lack of integration and compatibility of application security testing with other tooling requires teams to do heavy lifting, slowing down the delivery.
• Security tools often have many findings of which many of them can be false positives, managing these findings is a challenge.
• It doesn’t deliver new functionality or features, and is often an afterthought.

Approaching it from multiple angles

At Avanade we take a multifaceted approach and defined 4 key elements to address integrating security in the SDLC. This ensures nothing remains uncovered and risks are reduced. In the below figure we describe these elements.

Figure 2: 4 key elements to address when integrating security in the SDLC

In this blogpost I will go into the first one of the four elements, shifting left.

Shift Left

Shifting left is a term not specific to DevSecOps but is more broadly used to the need of early focus on quality in the SDLC. In traditional ways of working, and sometimes also in agile processes, the focus on quality is concentrated on the time just before deployment.

Figure 3: traditional and “shift left” quality model.

In the shift model we address quality attributes from day one, giving it attention in every phase of the process, every step of the way. For security this means we:

• engage early with SMEs: include security experts (virtually) in your team and keep them engaged from the Plan and Design phase onwards. SME’s can help describe requirements and will be able to uncover design flaws.
• plan and design for it to go wrong: address the security angle during activities such as requirements gathering, backlog refinement, and Sprint Planning.
• test and review: make security an integrated part of the quality gates in the process by automating application security testing where possible and including it in peer reviews.
• monitor continuously: production environments, including the ones hosting your deployment pipelines, should be monitored continuously for anomalies and vulnerabilities. Examples of use cases are:
  • Someone trying to logon from a different location
  • Admin account is created (and deleted)
• create a response plan: know how to respond in case of anomalies or vulnerabilities are detected. Address items as: how to notify impacted users, what is the internal escalation plan, and how to follow up incidents to prevent them from occurring again.

By shifting left our attention for security we will catch issues sooner, make going live a smooth experience, and reduce the chance of having production issues. Great thing about this that it is no rocket science, but the hard part is that it requires a different way of working to do this at scale. Not only in the development teams, but also related teams. For this flexibility is required from the organization, and leadership support is required. But you can start today and begin with involving your security experts early on!

In future blogposts I will discuss the remaining elements. Also, other colleagues will go into how to leverage existing open-source and commercial tools to integrate security in the deployment pipeline using several types of application security testing. Stay posted.