Cybersec Threat Hunter to DevOps: You’ve Been Framed…
DevOps and cloud native development have gifted cyber attackers an enlarged attack surface and the ability to use organizations’ own tools against them, according to one of Europe’s top threat researchers.
Tom Van de Wiele, principal technology and threat researcher at Finnish security firm WithSecure, speaking at the recent Sphere 2022 conference in Helsinki, said that over the past decade companies had become acutely aware of how their development environments can undermine application security.
They’d begun to consider what level of security they can bake into the development process. But building in scans and tests, and managing credentials and access more tightly, is not enough, he said.
Larger Attack Surface
The sheer scale of the cloud native ecosystem presented a much larger attack surface, which is exacerbated by the role of volunteers producing open source software that “gets included into a kind of black box” whether the code is delivered as an off-the-shelf product, custom project or by an external supplier.
Suffering From Structure
A large part of WithSecure’s business involves security consulting, Van de Wiele explained, and when it came to red teaming, “A lot of companies over the last five years as an objective for our tests have said ‘could you please start with our DevOps environment,’” he said.
What has become clear from this work is that “a lot of companies are suffering from their own structure,” he noted.
This is often because they will call in a specialist who is given privileges on the underlying user accounts to set up one part of the tool chain, say infrastructure as code. Then another consultant is pulled in for another stage, say Bitbucket, and is also given privileges.
“The problem these companies have, is they lose the oversight,” said Van de Wiele. This results in situations where a bank’s entire DevOps infrastructure is predicated on a single service account or a handful of user accounts. “People are on the beach, hammering nails into things, but no one really knows what we’re building, let alone if it’s going to go over the horizon.”
Opt-In Model
The problem was further explained by WithSecure CTO Christine Bejerasco. She said cloud platforms had clearly evolved security-wise.
“One nice thing about the model is it’s opt-in. So, for instance, you have all of this network traffic, ingress and egress blocked by default, and then you open it up bit by bit.”
This should make it harder to make a mistake, she said. “But of course, the moment you start tweaking things, and the bigger your cloud platform or your cloud estate becomes, the more mistakes you can have.”
The nature of the cloud meant that these misconfigurations should be easily picked up by logging, “they’re very auditable.” But, she continued, this demands a different way of thinking about security. “It’s not about the threat attacking you anymore. It’s about how you set up your system … helping people before the threat actors get into their cloud setup.”
A Question of Tooling
Addressing all these problems is partly a question of tooling, said Van de Wiele. So, in addition to ensuring source code and vulnerability scanning are integrated into the pipeline, companies need to segregate services, components and containers, and ensure transport between them is encrypted.
And organizations also need to understand how to quickly remediate software as it moves through the CI/CD pipeline
“Like that default setting? It turns out someone is abusing that worldwide and selling ransomware through that,” he said. “How flexible are you as a company to be able to make those changes while the sausage is being made? Or while there’s a new update for a piece of software that you need to incorporate? How resilient are you in adding those changes?”
Priorities, Focus, Risk Management
But they also need to realize security is a question of priorities, focus and risk management – and developers are not the best people to be making these calls.
“When you say DevOps, you think developers, techies, and that’s fine, but you need people in the departments as well that are able to tie the technical risk to the business risk,” Van de Wiele said. “And that sometimes gets forgotten, because not all of this is a technical decision.”
For example, he says, a customer bolting two commercial products together may be able to introduce scanning to find vulnerabilities. “But whatever you’re going to find, you won’t be able to fix anyway. Because you have to pick up the phone and call to say, ‘Hey, when can we expect an update?’”
Moreover, “Security is more than just sprinkling security on top and ticking a bunch of boxes,” he said. “It’s looking at what is going to bite us in the ankles. What can we live with? And then working your way backward to say, ‘OK, what changes do we need? And of course, what budget and people do we need to make this happen and to make this liveable?’”
Credential Management, Developer Distinctions
Organizations must also ensure “credential management is kept away from the actual application developers,” he said.
“A Java developer, they don’t need access to the .NET environment,” he said. The problem is most companies don’t make these distinctions. “They go, ‘Well, it says developer here. And if it sounds like a duck and looks like a duck…’”
And, no matter how much a developer or a team advocates for a given approach or framework, the organization needs to understand exactly what this means for the attackers trying to break into their systems.
“Too many times I hear in meeting rooms, ‘But the framework takes care of that,’” said Van de Wiele. “But guess what we’re using as ethical hackers against you? If we have to run a payload somewhere, instead of writing two lines of code, well, using your framework, it’s now one sentence. You’re making things easier for me.”
