Secure DevOps #1 — Identity

This is the second in a series of posts that will outline a framework I’ve developed and successfully deployed for applying effective security to a DevOps environment.

Part 0 — Setting The Scene
Part 1 — Identity
Part 2 — Environment
Part 3 — Secure SDLC
Part 4 — Embedded Expertise

Traditional security controls are often slow, clunky, and outdated. They exist because once you’ve bought into a control it’s a difficult position to back out of — nothing having gone wrong whilst the control was in place is a terrifying precedent to go against for the person who chooses to remove it later down the line.

And so controls stack, and wither, and get superseded but rarely get replaced.

Identity is an outlier here, and should be considered reborn. It’s not traditionally seen as a security control at all — more of a necessity for any IT environment. Its design, management, and administration is not usually in the security realm, relegated instead to an administrative function.

In securing a DevOps operation, identity happens to be one of the most versatile and reliable controls available to us, and can be exploited to everyone’s benefit.

This is basically a win/win scenario for users and for security. Get this part right and the rest should flow.

Given the ubiquity of identity across IT, it’s a given for nearly all users and therefore doesn’t need to be seen as a control at all. And yet from a security point of view, the insight we can get from a properly designed and implemented identity solution is immense. If everything is integrated to the same identity provider, then everything can be logged, everything can be alerted on, everything can be audited, and more importantly everything can be locked down — with precision — in a matter of seconds.

Strong Identity Integration

For a DevOps environment, identity needs to be integrated at all levels. Teams are likely going to be using SSH for a large part of their work, and this presents the opportunity to integrate key management into the identity solution. Transparent authentication benefits your engineers and provides them with some desperately needed agility.

System and service accounts should all be backed-off to your identity solution too. No more local accounts for operational purposes. Again, this is win/win — new systems can inherit identity information with permission groups with no additional work and configuration each time a new instance is created — there’s no headache in ensuring accounts are appropriately restricted each time. It’s a once-and-done operation — done ahead of time, and inherited throughout. And for security, it means the single point of identity information is all that is needed for monitoring and alerting yet again. As much as a problematic user can be shut down in seconds, so too can a compromised service account.

Multi-factor Authentication

Multi-factor authentication should be built in to privileged actions. Implementation of this will depend on your specific circumstances (whether this is cloud, on-premises, hybrid, whether this is sensitive data, brochureware, etc) depending on where your risk appetite sits. Given that we’ve insisted on a single, centralised identity solution, the integration is neat and can be implemented on a number of factors — source IP, role, target system, etc.

The added benefit here being the centralised management and configuration meaning that should a particular activity’s risk profile change due to any number of circumstances, the applicability of multi-factor can be configured in or out trivially and without disruption. More lovely agility — and not at the expense of control.

Code Signing

All code which reaches a production environment should be attributable to a person. Whether they wrote it themselves, or imported it from another project/source, if that code is expected to be run in production then it needs to be traceable.

Since the identity solution already supports the integration of keys, we have a cryptographic means of attributing actions to an individual account. And since everyone needs an account to get started, we maintain the single, centralised control. Again, without having to cost anyone their agility. A later post in this series will explore source code control in more detail and beyond code signing.

Tools like Git allow for integration with identity solutions to implement code signing.

Maker / Checker

Particularly at the point of code reaching a production environment, consideration should be given as to whether the sensitivity of the actions being performed by the code need additional scrutiny. This will depend very heavily on what you’re producing, to what standards, and on the sensitivity of the affected data.

This control provides a number of things — firstly it implements a very neatly integrated version of the principle of ‘segregation of duties’ which, amongst other things, contains the potential impact of a single rogue actor, and forces collusion between multiple parties to be able to cause damage. Secondly, it provides the agility needed for a developer to create and test multiple iterations of their own code without interruption. Only when it comes to pass into production does it have the additional challenge and scrutiny. A further exploration of environmental controls will be undertaken in a later post in this series.

Summary

Setting Identity up as one of the cornerstones of your DevOps environment is the first step in establishing an agile environment that isn’t hamstrung by aged security controls, processes, and operational inefficiencies, but is instead enabled and extended by the control.

It has long been a stated aim of information security teams to be seen as an ‘enabling’ function, rather than ‘blockers’, but to achieve this aim a little humility is required, and a lot of work to understand what is being secured, and how people are working.

If a control relies on an end user to operate it, then it will fail. Controls need to be transparent or otherwise beneficial to the user. Security needs to be looked at as a by-product, not the sole reason for existence.

Having a centralised identity solution which is fully integrated across tools and platforms being used means there is no friction to adoption since the operational benefits sell themselves. Security comes as a by-product and control is the default state.