If you’re running a workload in the cloud, take a moment to look at the activity logs for your public-facing resources. There’s bad guys there, and they’re probing your cloud infrastructure looking for misconfigurations they can exploit.
A lot has changed with how hackers go about stealing data or otherwise damaging an organization. The traditional approach involves picking an organization to target, and then searching for vulnerabilities to exploit.
A high-profile example is the infamous Sony hack. A certain country was unhappy about a particular movie, and they set about to attack the media company that produced it. Using a mix of backdoors, proxy tools, and malware, the attackers were able to destroy assets and publish sensitive data on the Internet. This is called an Advanced Persistent Attack, or APT.
Of course, this still happens and it must be guarded against. But another, more broadly dangerous kind of threat has emerged with cloud computing. Malicious actors now use automation tools to scan the entire internet searching for cloud misconfigurations, such as unrestricted SSH access (e.g., 0.0.0.0/0 on Port 22), orphaned and unpatched compute instances, and many others.
They don’t have to look too hard, and what they get back is essentially a long shopping list of cloud environments they can access. It’s relatively trivial to discover who owns these environments, so the attacker goes shopping.
You need to ask yourself some important questions when assessing your cloud security posture, and these questions must go well beyond whether or not your environment is passing compliance audits.
Within minutes of adding a new endpoint to the internet, a potential attacker has scanned it. A single cloud misconfiguration can put a target on your organization’s back and put your data at risk.
Assume for a moment that an attacker finds one of these vulnerabilities and gains access to your environment. What kind of damage could they do? Would it be easy for them to discover other cloud resources and where you store your sensitive data? Could they leverage Identity and Access Management (IAM) misconfigurations—such as overly permissive settings—to gain access to additional resources and data? Might they be able to extract that data into their own cloud account without detection?
Chances are you’re not going to like the answers. Take swift action to close these gaps in your cloud security posture when you find them. But also recognize that cloud configuration “drift” happens all the time, so you need to stay vigilant. A cloud environment that’s free of misconfiguration on Day 1 may not be on Day 2 (or hour 2).
If you rely too much on manual prevention and remediation of cloud misconfiguration, you’re too slow to counter these automated threats, because it only takes minutes for an attacker to go from accessing your environment to making off with your data. Look for ways to automate the prevention of misconfiguration in CI/CD, and the detection and remediation of misconfiguration when it does occur for security-critical resources in production.
Finally, make sure your penetration testers (pentesters) include cloud misconfiguration vulnerabilities. There’s a good chance they currently don’t factor in these kinds of attack vectors.