LAS VEGAS -- It's much easier to successfully attack, and much more difficult to defend, cloud instances than on-premises networks, two Israeli security researchers said at the opening day of the BSides Las Vegas security conference.
Roei Sherman, Field CTO at Mitiga, and Adi Belinkov, Director of IT and Security at Mitiga, explained that what makes the cloud so easy to use also makes it easy to attack.
But the shared-responsibility model between cloud service providers and cloud clients, the lack of visibility by those clients into the cloud environment, and the lack of overall client control make it very difficult to adequately defend cloud instances, they said.
"And remember," said Sherman, "SaaS is cloud too."
"The cloud isn't just the cloud service provider," added Belinkov. "It's any system that provides services in the cloud."
For example, Belinkov and Sherman pointed out, an attacker targeting a physical network would need a rather large skill set and extensive knowledge about the targeted organization to have a good chance of success. On-prem defenders would have the home-field advantage of a well-defined perimeter, an understanding of their own network, a wide variety of defensive tools and a comprehensive incident-response plan ready to kick into action.
But in the public cloud, defenders have no home-field advantage because it's not their field. They have only limited knowledge about the network. They can't patch vulnerabilities. They can't see very far in the network beyond their own assets. They have fewer tools to defend their assets. The perimeter is poorly defined or largely nonexistent.
Meanwhile, an attacker operating in the cloud doesn't need much to succeed. The attacker doesn't need a large skill set, not when there is plenty of documentation about cloud environments and open-source cloud-hacking tools are available. The attacker doesn't need to know the details of the target's network.
A stolen set of cloud admin credentials may be all that's needed, letting an intruder use the same user interfaces and APIs as a legitimate cloud admin. Anomaly detectors, whether they report to the cloud service provider or the cloud client, would be none the wiser because the attacker's behavior would mimic that of a legit admin, cloning data buckets, adding integration apps, and creating access keys.
"The new perimeter in cloud is identity. It's a cliche already, but it's true," said Sherman as he displayed a slide stating: "Attackers don't break in; they log in."
It's also harder to investigate cloud breaches than on-premises ones, Belinkov and Sherman pointed out. If you're the cloud client, the cloud service provider's network architecture may be a total mystery. Even when it comes to your own data, it's difficult to verify whether a data bucket was compromised.
Logs are often turned off by default, and the logging format can be widely different between different cloud service providers. And if you have a cloud-incident response playbook, you may need a different one for each CSP.
Even CSPs often don't know what's going on, the researchers said. A perfect example was the Midnight Blizzard attacks on Microsoft, the biggest and most technologically adept CSP there is.
"Everything about the attack was cloud-only," Belinkov said. "And Microsoft missed it for months."
The lessons boil down into three main points, the researchers said:
1) Increase your cloud visibility by demanding adequate logs from your CSPs and that you're logging your SaaS platforms.
2) Use the security tools that the CSPs provide alongside your own cloud-native security tools.
3) Be proactive by red-teaming and threat-hunting on your cloud and SaaS assets, and building anomaly and behavioral detection for them.
"In the cloud," said Sherman, "we have a problem."
