Resolving the DevOps-security tension

A new set of software development practices – grouped under the umbrella of ‘DevOps’ – is fundamentally reshaping the way digital products and services are designed and delivered to users.

DevOps stands in stark contrast to the traditional approach, where product owners, designers, UX pros, developers, operations managers and quality assurers would generally work in a silo-based, linear value chain. Combined with the principles of Agile and the promise of rampant automation, DevOps allows for the simultaneous building, iterating and running of software. It enables rapid release cycles and early feedback from initial users. Insights are continually fed into the development streams, allowing teams to adjust and iterate software in shorter, quicker release cycles.

In this way, DevOps enables organisations to compress the time between ideation, creation and deployment. They’re able to release new features to market faster, and with greater relevance to users. The business enjoys lower development costs, shorter timeframes, and quicker value realisation.

At odds
However, the very flexibility and lack of rigorous process controls that makes DevOps attractive can be somewhat at odds with the pressing need to ensure strong cyber-security and data loss prevention.

DevOps’ very raison d'être is to enable frequent, rapid-fire software iterations; while the security, risk management and compliance teams focus on retaining control – slowing things down, aiming to minimise the number of potential incidents, and ensuring various safeguards are in place.

With cyber-security shooting to the top of boardroom agendas in the wake of a number of global and massively damaging threats in 2017 (look no further than ‘WannaCry’ for evidence), the DevOps-security tension can be a tricky one to resolve for local CIOs.

Urgent need
In South Africa, we have a very pressing cyber-security concern. Many security experts refer to the county as something of a ‘soft target’ for global crime syndicates.

So as local businesses scramble to provide digital services to a country where many of us have only become truly ‘connected’ (via the smartphone revolution) in the past few years, it’s essential to place a strong emphasis on users’ safety.

At 9TH BIT, we don’t believe that security and risk management can simply be 'shoe-horned', retroactively, into the development process, just before code is released in the wild. Security and risk frameworks aren’t fixed targets that we must aim towards, but are ongoing and ever-evolving properties of software and our processes.

Practical steps
After all, the world of cyber-crime never stands still, so it’s critical to stay one step ahead of emerging threats as they appear on the horizon, catering for them throughout the process of continuous delivery. And according to 9TH BIT partner, XebiaLabs, a company specialising in DevOps and continuous delivery tooling, there are several steps that can be taken to integrate security into DevOps, including:

· Assessing application risk - gain an understanding of the likely risks that a new product or feature may attract, particularly in terms of its impact on your entire technology ecosystem, and the data protection requirements that it may entail (what kind of sensitive data will the application be gathering/processing/displaying).

· Establishing common baseline security standards - for all applications (this should include the likes of CSP usage, cookies, TLS, and so on).

· Enabling test driven security - stress-test your approach by simulating security failures, ensuring the security control kick-in, and then verifying that all tests are passed.

· Managing secrets in code - build tightly-controlled, centralised security services to prevent any leaks.

· Testing and auditing the underlying infrastructure - such as ensuring that you check TLS configurations and certificate validity on an ongoing basis).

· Having a clear incident response plan - despite our best efforts, sometimes breaches may occur - so ensure you have a comprehensive incident response plan, which is practised, and where everyone’s roles are clear, so it can be easily executed when needed.

The fallacy of DevOps is that we can simply create processes, automate anything and everything that we can imagine, and then just leave it to run. Due to the dynamic nature of cyber-security, it’s simply not possible to automate the likes of threat modelling, secure design, secure coding rules, security testing and patch management.

DevOps and automation certainly remove many of the hassles and the low-value work involved in delivering software, but we should use these advantages to free up resources that are focused on a pragmatic and comprehensive security approach, embedded into every step of the development process.

By Barry de Waal, chief executive of strategy and sales at 9TH BIT Consulting