Is your IaC model a road map for hackers? – The new battery

0

Cyber ​​attackers see things differently than the rest of us. So is it really surprising that what a DevOps engineer views as just a piece of Infrastructure as Code (IaC), a determined hacker views as a route planner to the core of an organization’s systems?

According Matt JohnsonBridgecrew by Prisma Cloud champion developer, codifying the infrastructure using tools such as AWS CloudFormation or open source Terraform means you end up with reusable definitions of the infrastructure – a huge advantage when building, deploying and managing complex systems.

The problem is that these definitions can include misconfigurations, security holes, or even hard-coded credentials, which will be recycled and redeployed each time you use this code.

Also, as Johnson told The New Stack, it’s a cliché that “if a developer needs to do something, they go to Google, they find a solution on Stack Exchange or Stack Overflow, and then that is copied and pasted into its codebase”. This means that misconfigurations and other people’s vulnerabilities are now also their misconfigurations.

Part of the problem is that many publicly available IaC models were originally intended to serve as examples or tutorials, “to get people to ‘Hello World,'” as Johnson put it. If they had been produced with all the relevant security features, he added, they would be 100 times longer, making them much less digestible as a learning aid.

“It’s definitely a user issue”

Deck crewthe security platform company acquired by Palo Alto Networks Last year, scanned popular Terraform registers and the Cloud Native Computing Foundation artifacthub.io using his verification tooland found “major issues” with more than 50% of the patterns or artifacts.

“The reality is that you’re more likely to download insecure default infrastructure as code than secure default infrastructure,” Johnson said.

It’s important to remember that the problem – and the ultimate responsibility for fixing it – does not lie with the suppliers. Amazon Web Services, for example, offers tools to help customers detect if IaC changes might cause issues, including AWS CloudFormation Hooks and AWS CloudFormation Drift Detection.

“It’s definitely a user issue,” Johnson said. “Terraform or AWS CloudFormation aren’t things that aren’t secure. It is a set of tools that can be used or misused.

But while users may be alarmed to discover that they have integrated insecure IaC into their own systems, their discomfort will increase further when they realize that the very ubiquity of this code means attackers potentially have a roadmap. through their systems.

“If you use one of these modules,” Johnson said, “I can see exactly what is and isn’t configured in that module.”

This means that in addition to gaining insight into possible entry points, attackers can map out potential lateral moves in advance, prioritize where to move next, decide on the best exploits to deploy – and all with a good idea of ​​the targets they can hit. .

“The more holes you have, the more likely you are to find a path all the way through,” he said – and misconfigurations can give a direct route to the underlying system.

Avoiding public IaC models is not a solution in itself. Users are perfectly capable of adding their own faults, even if they are not faults at the time. “A secure default this year could be an insecure default next year, due to a change in encryption type,” Johnson noted.

IaC surfacing recommendations

DevOps – or should it be DevSecOps – has already solved the problem of developers “forgetting” to run security tests on code by automating the tests and storing those tests as code. So when it comes to configuration code, Johnson said, the obvious thing is to have automated tools to do the same thing.

But “historically, security tools weren’t designed to be operated by engineers and developers,” he added. “They were designed to be understood by security guards, who are of a whole different breed.”

There is another obstacle, he says. Analyze the infrastructure of a typical modern organization and it will identify hundreds, if not thousands, of common vulnerabilities and exposures (CVEs) and, in parallel, hundreds, if not thousands, of Infrastructure as Code recommendations. But that can leave developers paralyzed as to what to tackle first.

The challenge, then, is to translate that information into something acceptable to a developer and to do so without forcing the developer out of their tools, environment, or workflow. “Let’s try to bring this information out as soon as possible with a helpful suggestion of what they can do to fix this,” Johnson said.

Bridgecrew’s Checkov finds and identifies misconfigurations in IaC code, including CloudFormation and Terraform, as well as other file types, including Kubernetes and Docker. But with Bridgecrew’s acquisition by Palo Alto Networks, the technology has been integrated into Prisma Cloud’s cloud-native application protection platform, meaning Checkov’s insights can be put into a broader context with new data. other information about the vulnerability.

“The big new feature we’ve been working on is this idea of supply chain chart“, Johnson said. This creates a graph of which CVEs are in which containers and which are deployed by which piece of infrastructure as code. “So we can really visualize where there is a tangible attack path or not.”

For example, if a CVE is running in an application that isn’t connected to the internet, chances are it won’t be as prioritized as a CVE running on a public load balancer allowing full access to Internet.

And that analysis needs to be extended to developers’ own toolchains, which themselves often rely on publicly available components, Johnson said: “We’re seeing more and more people trying to attack the CI/CD pipeline himself.”

After all, he added, “Why try to attack something in production if you can inject your own code into the developer’s system who then puts it into production for you?”

So the Palo Alto Networks platform now includes additional checks and policies to verify the configuration of developer pipelines, Johnson said: “Because the pipeline configuration itself is codified, we can review that and say “Hey, you should probably enable at least two internal approvals before someone can merge.

It’s hard to imagine the developers retreating to the walled gardens in which they worked. The benefits of automation, IaC, and reusability are too great, even as the dangers associated with them are becoming increasingly evident.

That means automation is the only way to solve this problem, Johnson said. But this automation should alert developers as well as security personnel and give them a clear indication of the risks they face rather than just saying no. “As a developer,” he said, “that’s what I would want.”

The New Stack is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.

Featured image by Radek Kilijanek on Unsplash.


Source link

Share.

Comments are closed.