Following the DevOps Focus Groups held last autumn, Alex Manly, Principal DevOps Consultant, Contino, reviews how to go faster, safely.

Two seemingly contradictory imperatives are bearing down on the modern global enterprise organisation.

On the one hand, security is a huge challenge that can have dire consequences if improperly handled. A known vulnerability led to TalkTalk being hacked in 2015, for example, resulting in a record‑breaking fine for the company and a massive brain drain as embarrassed IT professionals sought to distance themselves from the brand.

On the other hand, as software continues to ‘eat the world’, high‑velocity IT becomes the foundation of competitiveness in the modern marketplace. Every business must become an agile and innovative software delivery machine in order to survive.

Which leads us to the enterprise IT paradox: go faster and innovate. But always stay secure.

Why is this difficult and what can be done?

Going faster: software‑defined everything and DevOps

As software becomes the key market differentiator, every company – regardless of industry – is becoming a software company.

Simultaneously, the remit of software is expanding. Infrastructure can now be provisioned in the cloud via APIs, i.e., codified through scripts and templates. Nearly your entire stack (compute, storage, network…) can now, in principle, be defined by software and provisioned through the same delivery cycle as software: build, test, deploy.

This means that infrastructure can be provisioned much more rapidly and software deployed more quickly and frequently.

In this world of software‑defined everything, the old (‘procedural’) approach of making a change on system A, then the same change on system B and so on, does not scale. Instead, to effectively manage and control these large, distributed, software‑defined systems you need to change your mindset and employ two foundational tools: configuration management and automation.

Configuration management tools allow you to define the desired state of your systems in code and manage them such that they continuously reconverge on this desired state. This means that complicated distributed systems (e.g. environments in the public cloud) have the ability to heal and fix themselves.

Automation allows you to spin up and spin down these self‑healing systems with minimal manual input.

The result is that you can spin up and spin down highly‑consistent environments quickly and cheaply. When combined with a DevOps approach, this provides the foundation for a hugely accelerated software delivery cycle.

But how can security keep up with infrastructure that is constantly being torn down and automatically reprovisioned or with continuous deployment and iterative experimentation?

A study by 451 Research showed that when organisations try to go faster by moving to the cloud, for example, the number one headache is security, with data sovereignty and compliance not far behind.

Why is security at speed so hard?

Security at speed: conflicts and change

Security compliance has traditionally been a drag on performance. Perceived and actual conflicts between the need to go faster and the need to be secure and compliant created divisions between development teams (go fast!), operations teams (go slow!) and security teams (be safe!).

The security team becomes the ‘Department of “No”’ and as a result is marginalised over time, creating a self‑reinforcing downward spiral of division.

And this is getting worse as security becomes more important in the enterprise. Cyber crime is more profitable than ever, with incidents rising year‑on‑year and reams of regulation following in their wake.

What’s more, technologies and regulations are constantly changing, forcing security teams to constantly have to test for different issues in different ways. They get caught up in reactive cycles, only responding when something goes wrong, because proactively preempting myriad security issues in an ever‑evolving threat landscape is simply too large a challenge to be taken on with the limited resources available.

So how can you increase the rate of deployments, accelerate feedback loops and breed a culture of innovation, i.e., increase the rate of change – whilst ensuring that you meet security standards that are stricter than ever before and that struggle with change? „

Dev Sec Ops and shifting security left

The solution is to shift security left. This means including security as early as possible in the software delivery pipeline and embedding security into the very processes that you use to go faster: software‑defined security.

You can codify testing, monitoring and reporting, embed them in the continuous delivery pipeline and then generate fast feedback loops regarding the state of your infrastructure security, across your system.

Essentially, all the governance standards of your organisation can be ‘hardened’ into your infrastructure via code before you ever deploy applications onto it.

This makes security efficient and repeatable. It reduces errors and means that issues can be resolved quicker because different systems don’t have different configurations.

This is sometimes referred to as DevSecOps: bringing security into the DevOps world.

This involves a lot of work up front – you first need an automated continuous software delivery pipeline supported by DevOps practices – but it is the most consistent and reliable way of including your security practices at every stage of the software delivery pipeline. And of resolving the paradox between speed and security.

What are the benefits?

With DevSecOps, you will know that your applications and your infrastructure are automatically and continuously reconverging on optimal security settings that you have defined in advance in code.

If root access is limited (a common feature of effective automation aimed at maximising consistency), you will know who made which changes and when. This traceability makes it much easier to track down the origin of problems when they do occur.

Lastly, thanks to the availability of a wide range of open source tools, automated testing can be included at every stage of the pipeline. Potential vulnerabilities are identified as early as possible and can be easily traced and rectified.

The result is that you can now validate the security settings of your machines, automatically generate a report that is human‑readable and can be shared with your security teams so that, when they come along with a big binder of compliance and regulations, it’s easy to point them in the right direction. This reduces the chasm between the theory of security and how it is actually practiced on the ground and brings the previously‑marginalised security team right into the loop.

What is good security?

Good security has now become a function of good software delivery hygiene: of good continuous integration, deployment automation and automated testing. This new way of working results in more compliance, less risk and greater productivity.

Most importantly, security is no longer a ‘drag’ on performance, it’s a key element of business success that guarantees consistency and reliability over the long term.

This article originally appeared in the DevOps Focus Groups Supplement as part of the January 2017 issue of TEST Magazine. Edited for web by Jordan Platt.