Secure DevOps #4 — Embedded Expertise
This is the final 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
The final piece to this framework describes what I believe to be the need for a much wider change within the information security community.
Information security has benefitted during its infancy from being given a certain amount of bandwidth to establish itself. Indeed, every client I’ve worked with in my information security career has been consistently growing its function throughout the period — and growing it substantially too.
Over this period, security has carved out a few roles and people fall neatly into one or another. Initially a generalist function grew from existing firewall operators. This generalism established itself as consultancy, and that expanded out into architecture. Meanwhile operations extended and split out engineering. (NB. I’m deliberately leaving risk alone here.)
In traditional models — supporting a business-as-usual operation and making changes through some version of a waterfall methodology, these divisions were nice and neat and allowed for some degree of flexibility. Your ops people were too busy keeping the lights on to answer the needs of project managers, and your consultants were more interested in future state than how to operate any individual piece of kit.
But over time this model started to suffer. Because of the silos, ops people became so far removed from any practical sense of ‘the business’ to consider themselves a business in their own right; and the consultants became so far removed from the security they were supposed to be consulting against that the main challenge was preventing the projects they were working on from noticing that the rich tapestry they were darning was actually made entirely of fog.
That’s not to say that there aren’t many, many excellent people working in both disciplines — people who understand the broader picture and who aren’t plaiting fog — but the cracks that exist around the status quo allow for a lot of filler.
When DevOps came along, suddenly the consultant who wasn’t close to the tech became a liability — for the project and for security. The project couldn’t get anything useful out of them so they went back to the time-tested “ignore them until they go away” approach. It’s hard to argue that this wasn’t fair though — because when the gist of the advice to the project was for them to spend several days answering stock questions derived from ISO27001 there was little to be gained and several days is potentially a lot of actual productive work that’s getting lost.
And for the ops guy who didn’t have an appreciation of multiple, tiny iterations, happening constantly to their environment?
Sure, there’s still space for both traditional roles because it’s not like they’re adding no value — they’re performing perfectly cromulent tasks. But it comes down to where the value is needed and how it’s being delivered.
In a larger enterprise, architecture can become important if done correctly.
What tends to happen though is that architects begat architects so that the architecture can be properly architected and the mistakes of previous architects can be architected out where possible. And where it’s not, then a whole bunch more architects are begat to agree an exception process and architect a way out of this lack of architect availability.
And that doesn’t pay for itself. Particularly in small/medium enterprises (SMEs) or in the types of companies that are looking to reap the rewards of a DevOps model.
Enter a new type of architect.
In fairness, I’ve invented this role as an architect because that’s what I was at the time that I first implemented this successfully. I had to undergo a massive personal transformation and upskilling process to make myself relevant in a brand-new world.
The role is probably more naturally aligned to a consultant because it’s not all technical, but it does require a more hands-on approach than any consultancy roles I’ve previously been in or that I’ve known other people working in.
The role combines all of the security disciplines:
- Consultancy to manage projects and customers effectively
- Operations to manage the relationship with the team that are responsible for keeping the wheels turning and who will ultimately inherit whatever is built
- Architecture to maintain alignment with a bigger picture (my main criticism of DevOps — and something for another post at another time — is that it has a very short-term world view and will ultimately be its own undoing)
- Engineering to understand how to actual implement something — be it a new appliance, a virtual machine, some automation, etc
To be able to properly embed, and ultimately to lead and inspire towards a security vision, the new architect needs to be able add value in the currency that a DevOps team can understand and can appreciate.
This is about hands-on, detailed advice and guidance. Knowledge transfer. Not just telling them the “what” but exploring and offering up the “why” too (you never know, you might inadvertently recruit a developer into our ranks when you show them how awesome it is to break into things). It’s as much about education (but not in a condescending way) as it is about collaboration.
You don’t have to be a developer and able to build something to the same quality and in the same time as the team, but you damn sure better be able to work with them at their pace to be able to ensure that what they’re doing is in line with what you need to get out of it.
The role becomes one of solving the problems that the whole team have, as part of that team. Your expertise becomes embedded within the dev cell (or clan, or guild, or whatever the children are calling it nowadays) and you can ensure your agenda is moving forward as you move the project’s agenda forward too.
This is where the whole idea of security being an “enabler” (one of my least favourite concepts, by the way) could come to be something more substantial than an over-promise in someone’s Powerpoint somewhere.
When approached this way, security doesn’t need to “enable”, it needs to get itself out of the way and become transparent. When the controls are transparent and don’t need to be operated then they work by default. When the architect is transparent and is part of the effort to deliver then they can steer and ultimately lead the effort to a result which is good for the DevOps team and good for security too.
In the next article I’ll pull the whole thing together into something more succinct and practical.
