Survey Shows Reasons for Cloud Misconfigurations are Many and Complex

3 years ago 49

BOOK THIS SPACE FOR AD

ARTICLE AD

Using ‘policy as code’ helps the security team to be a cloud highway builder rather than a cloud toll booth operator

Media reports on misconfigured cloud resources are common. A researcher discovers the misconfiguration, reports it, and it is usually remedied. But in less time for it to be discovered and remedied, you can guarantee that hackers have already been there. Every misconfiguration report you read will describe a database that attackers have visited.

The reason is simple: hackers use the same internet scanning tools as the researchers, but are not required to spend time on notifying the owner before taking advantage of the discovery.

The NSA’s guidance on mitigating cloud vulnerabilities described misconfiguration as the most common cloud vulnerability. A new Fugue/Sonatype report (PDF), The State of Cloud Security 2021, confirms the issue as cloud professionals’ biggest concern, and delves into the causes and possible solutions to the problem.

“Basically, defenders need to start thinking like hackers, and to start using tools that let them see their own networks just as clearly as the hackers already do,” Fugue’s CEO Josh Stella told SecurityWeek.

Fugue surveyed more than 300 cloud professionals, including cloud engineers, cloud security engineers, DevOps, and cloud architects, to better understand the risks, costs, and challenges of managing cloud security at scale.

Gartner suggests that through 2023, at least 99 percent of cloud security failures will be the customer’s fault, mainly in the form of cloud resource misconfiguration. The practitioners do not disagree, with 83 percent of the survey respondents voicing concern that their organization is at risk of a cloud-based data breach.

The primary reason is insufficient focused resources to manage the size and complexity of enterprise cloud usage. There are too many APIs and interfaces to govern (cited by 32 percent of the respondents), a lack of controls and oversight (31 percent), a lack of policy awareness (27 percent), and negligence (23 percent). Twenty-one percent said they do not check Infrastructure as Code (IaC) prior to deployment, and 20 percent do not adequately monitor their cloud environment for misconfiguration.

“This year’s survey reveals that the complexities and dynamism of at-scale cloud environments outpace the ability of teams to keep them secure,” says Fugue’s Stella. “Engineering and security teams continue to ramp up the time and resources they invest in cloud security, but say they still lack the visibility and automation they need.”

However, he told SecurityWeek, “One somewhat worrying discovery is that only 32 percent of the professionals believe that cloud misconfiguration will increase. Sixty-eight percent said it will stay the same or decrease. Most practitioners feel that the risk to them is staying the same or even decreasing; but it is clear from empirical evidence that is increasing.”

This is probably optimism bias in operation. It explains why many surveys report respondents saying things are getting better against all the objective evidence. What they probably mean is they don’t believe bad things will happen to them; therefore, things must be getting better. Despite this, Stella added, “Eighty-three percent say their organization is at risk. That should be 100 percent, but 83 percent is pretty good.”

The most prevalent attacks against the cloud correlate with the most common misconfigurations experienced by the respondents. The top two are IAM issues (41 percent) and security group or firewall rules (40 percent); followed by object storage access policies, and encryption in transit disabled or not enabled (both at 31 percent). Encryption at rest disabled (or not enabled) follows at 28 percent.

“I was really pleased that this year for the first time,” said Stella, “IAM is the number one concern for misconfiguration. This aligns perfectly with what the hackers are doing – there is an IAM component in the majority of attacks.” In past issues of this annual survey, the respondents were concerned more about network security or S3 bucket configuration. “While those are very real concerns,” he added, “they are not as critical as IAM – which suggests that cloud practitioners are becoming more aware of how the attackers are hacking them.”

Stella tends to analyze every big cloud breach that occurs. “I try to recreate them in a sandbox environment. What I’ve learned is that the media overly simplified these breaches. The media tends to say, ‘Oh, there was another public S3 bucket’ – but it turns out it wasn’t a public S3 bucket. Some data was stolen from S3, but not because it was configured as a public instance. There are other routes to get there, and the hackers use them all.”

The result is that practitioners get a false sense of security. Based on media reports, they start thinking that simply setting the AWS feature ‘block public access’ makes them safe. “This is simply not true,” Stella told SecurityWeek. “It’s helpful, but when you look at the real-world breaches – such as Uber and Imperva – these are subtle and the hackers are clever and many practitioners suffer from a false sense of security that can at least partly be attributed to media over-simplification.”

The primary problem for cloud security is a combination of the complexity of corporate cloud infrastructures and the hackers’ use of large-scale automation to look for known errors, such as misconfigurations or exploitable versions of software.

Take the Capital One breach. “Capital One was never targeted,” Stella said. “The hacker [Paige Thompson] was running automation and discovered a misconfiguration through that automation that she knew how to exploit and which happened to map back to Capital One. If you have resources that are internet-facing – even indirectly in some cases – hackers probably know about your vulnerabilities before you. And if they know, there is a reasonably good likelihood that they have already exploited them.”

Staying ahead of the hackers manually is almost impossible because of the complexity of enterprise cloud usage, and the ease of changing things. “The ability to change course is ‘a good thing’,” says Stella. “But there’s a problem here. People tend to think that if they do a check or a security team audit that says, ‘this is okay’, that’s good enough. It’s not good enough. The reason is because it is really easy to change things in the cloud – which is a feature, not a bug. If you’re not paying sufficient attention, those changes can expose you to risk. What is safe today may be insecure tomorrow. You don’t need to prevent change, but you do need to understand and track it.”

And that’s where the complexity comes in. “Some of our customers have six or seven hundred different teams that are building and changing cloud applications every day,” explained Stella. “It is hard to imagine a security team being able to manage the security of millions of cloud resources manually. It’s impossible to have a human in the loop for every change because there’s hundreds every day – so from a security perspective you need to have the tooling that makes you a highway builder rather than a toll booth operator.” Defenders must be more like their attackers.

Stella’s primary recommendation is that defenders should start using ‘policy as code’, which is a way of automating the security function. “It gives the engineer automatic and immediate feedback on the security of what he is doing, before it is deployed.”

Policy as code is something that can be built entirely in-house, obtained from open-source products, or purchased from cloud security specialists.

Kevin Townsend is a Senior Contributor at SecurityWeek. He has been writing about high tech issues since before the birth of Microsoft. For the last 15 years he has specialized in information security; and has had many thousands of articles published in dozens of different magazines – from The Times and the Financial Times to current and long-gone computer magazines.

Previous Columns by Kevin Townsend:

Read Entire Article