Maksim Kabakou - Fotolia
Security Think Tank: In the cloud, anti-human approaches set us up to fail
Security learning is a career-long process, so as 2021 draws to a close, participants in the Computer Weekly Security Think Tank sum up the most important cyber lessons they’ve taken away from the past 12 months
What surprised me the most in 2021 is that we continue to build new security approaches with the same anti-human patterns we’ve seen before, setting us up for the same kinds of failures we’ve been trying to stamp out for years. It’s no surprise that Gartner predicts 99% of cloud breaches will involve configuration mistakes that are the organisation’s own fault.
Our businesses all run on complex infrastructure, and it’s been evolving fast – almost every organisation is hybrid now, mixing different cloud flavours, on-premise, and new overlays like Kubernetes. Each of these evolutions is heralded as the modern, error-free way of doing things, because it will all be software defined – just say what you want, and the automation will take care of the rest.
The trouble is that, just like all other kinds of software, the control languages are arcane – they all suffer the same contradiction that you can’t have something that’s both powerful and error proof at the same time. Users always demand more features for more special cases, the complexity goes up, and the openings for errors creep back in. Yes, well-designed software-defined languages sweep away some old problems, but just end up replacing them with new ones.
Nobody in cloud networking has to worry that an internet gateway has a factory-set default password on it, because there’s no such thing anymore, and that’s great. But before we built on clouds, nobody made the mistake of a world-readable, internet-exposed Amazon S3 bucket with critical data on it – that wasn’t possible until we adopted the new techniques.
The crispest example that brought this home to me in 2021 was looking closely into the security controls baked into Kubernetes. Kubernetes has become really entrenched in 2021 as the current way to build cloud apps and infrastructure, and certainly, it comes with a lot of power – I prefer to use it in my own SaaS offerings. And, of course, Kubernetes lets you set up microsegmentation – the network equivalent of the social distancing we’ve all had to use in meatspace in 2021.
But if you’ve got good security instincts, you know to ask “what could possibly go wrong?” when you see new ways to do things. I recommend taking a look at how you differentiate a default permit-all policy from a default deny-all in Kubernetes – perhaps the single most basic thing you could want to do in any network access policy language.
Does the language work? Yes – I use it, and it’s nice and powerful. But it’s also anti-human, in that it’s far too hard for a human to read and parse accurately – the difference between the extreme opposites of “everything permitted” and “everything blocked” is a pair of empty curly braces. (It’s not even just the default statements – the “and” versus “or” language boils down to a difference of just one hyphen character in arcane YAML files.).
Now imagine trying to read a big stack of policy documents, squinting to spot the curly braces and the hyphens, and figure out what they all add up to. With great power comes great responsibility for mistakes.
You’d think by now we would have learned that humans are really bad at reading and understanding complex configuration rules. No matter how much we shift left, we continue to demand powerful, flexible IT tool chains, and this is inherently error prone, to the extent that self-inflicted security gaps are the dominant security problem.
It’s not as if we don’t know how to secure individual assets – good hardening guides are easy to find. The trouble is we don’t yet know how to make reliable systems...which makes me think of the old joke that if software developers built the real world, the first woodpecker would destroy Western civilisation.