The average business has thousands of misconfigurations every year, and 99% of them go unseen. Here’s why this cloud vulnerability is so dangerous, and what you can do in AWS to prevent it.
Earlier this year, the National Security Agency (NSA) published a new report on mitigating cloud vulnerabilities. In it, they listed the top four cloud vulnerabilities, and misconfiguration topped the list. (The others included poor access control, shared tenancy vulnerabilities, and supply chain security flaws.)
Misconfiguration is when there are critical gaps in your cloud security that leave your organization and your data at risk. It happens most commonly when you make errors while configuring the security controls, or you fail to implement them at all.
A few examples of misconfiguration risks include:
- Open administration ports that are vulnerable to third-party attacks
- Unauthorized app access that can open up a malicious connection
- Publicly accessible cloud files that can be utilized by hackers or identity thieves
The consequences of misconfiguration can be dire and expensive. On August 6th, Capital One agreed to pay $80 million in settlements over a year after the hack that caused over 140,000 customers’ social security numbers, 80,000 bank account numbers, and data from over 100 million credit card applications to be stolen.
In that case, the hacker was Paige Thompson, a former employee at Amazon who knew how to break into AWS servers and bragged about it online until it got her caught. She was arrested and charged with computer fraud in July 2019.
Capital One says that the bank was able to secure the lost information before the hacker could use it or release it. But that doesn’t undo the perceived damage to consumers, who trusted Capital One to keep their private information safe.
What’s upsetting is that these incidents aren’t even close to rare.
On average, business enterprises experience an average of 2,269 misconfiguration incidents every month. McAfee found that enterprises estimated they were experiencing 37 misconfigurations a month when they were actually experiencing closer to 3,500!
That’s close to 99% of misconfiguration incidents flying under the radar. Why on earth are misconfigurations so common — and so underestimated by enterprise owners?
Why abused misconfigurations are so common in the cloud
All misconfigurations are the result of human error.
That’s good news and bad news: It explains why they’re so common because humans will always be prone to err. At the same time, reliably anticipating and reversing the effects of human error in your cloud architecture is easier said than done.
Look at the examples of cloud misconfiguration:
- Disabled multifactor authentication for admins
- Unencrypted data
- Unrestricted outbound access
- Unprovisioned access to resources
They’re all direct consequences of either:
- A human being making a mistake during implementation, or
- Not having the right infrastructure or tools in place
Cloud misconfiguration is high-prevalence, low-sophistication
Nearly every organization has cloud misconfiguration issues that they’re not aware of, and many of them have hundreds or thousands of incidents per month that go unchecked. That means misconfigurations are an easy target for attackers, who know that every enterprise has them.
At the same time, it’s relatively easy to pull off a scheme that exploits cloud misconfiguration. It’s straightforward to access information that isn’t protected in the first place and doesn’t require much hacking sophistication.
There are dozens of examples of people with software or engineering backgrounds gaining access to sensitive data via misconfiguration. Security researchers and defense contractors regularly uncover personal information made private in publicly accessible cloud storage, including separate incidents with NGA and CENTCOM in 2017, and Elasticsearch in 2019.
What is the right cloud architecture to deter misconfiguration?
- What’s great about misconfigurations and human error is that we can take steps to prevent errors. The NSA has released guidelines on the cloud architecture components that can prevent misconfiguration.
A strong and secure cloud architecture should include:
- Identity and access management (IdAM): IdAM is a service that protects access to client resources as well as access to the backend.
- Computing: Virtualization and containerization are both methods of computing that reduce the risk of misconfiguration. Virtualization isolates storage and networking, while containerization isolates customer workloads.
- Networking: Cloud networking needs to isolate customer networks at all costs. Software-Defined Networking is the most commonly used cloud solution for backbone networking and separating customer networks in the cloud.
- Storage: Cloud nodes separate customer data in objects, blocks, and database records. That data must be protected from other customers’ views as well as internal and external unauthorized use.
Encryption key management protects cloud data
Encryption key management (EM) is an important part of preventing misconfiguration. It’s the management of processes that lead to generating, accessing, and storing security keys.
The goal is to manage keys in a centralized spot to minimize the amount of data access that’s possible. It also means managing the keys’ life cycles and secure distribution.
An EM strategy may include:
- Software-based EM services: These often integrate with other cloud services to minimize the customer development needed to manage customers’ data.
- Hardware Security Model services: These can use Bring-Your-Own-Key encryption with externally generated keys for added security.
- Third-party or customer-developed tools: These have the benefit of internal control, but at the cost of the advanced cloud infrastructure necessary for high-level security — it’s these systems that frequently have faults with more misconfiguration incidents.
What AWS can do to address misconfiguration
After the wake of the Capital One incident, Amazon Web Services’ Amazon GuardDuty introduced three new threat detections related to Amazon S3 and EC2-instance metadata exfiltration:
- Policy:IAMUser/S3BlockPublicAccessDisabled — This detection checks for S3 block public access disabling for S3 buckets in an AWS account and notifies you if access changes, which can be an indicator of misconfiguration. This is a low-severity detection.
- Stealth:IAMUser/S3ServerAccessLoggingDisabled — This detection lets you know that Amazon S3 server access logging has been disabled for a bucket, which again, can indicate malicious intent. This is a low-severity detection.
- UnauthorizedAccess:EC2/MetaDataDNSRebind — This detection lets you know that there’s a query to a domain that resolves to the EC2 metadata IP address coming from an EC2 instance in the AWS environment. This is a high-severity detection that can mean someone is using DNS rebinding to exploit vulnerabilities in apps or browsers on the EC2 instance.
Amazon Web Services is these available in all Regions where GuardDuty is active. Anyone already using Guard Duty does not have to take action to start using these detection types, which are now default.
Work with a cloud-managed service team to identify and reduce misconfigurations
Not all in-house IT teams are equipped to handle all misconfigurations on their own, especially when the average business has over 2,000 of them per month! A cloud-managed service provider can help you implement the tools to identify and fix misconfiguration, but also improve your overall cloud security status.
CloudHesive can support you on cloud security and cloud-managed services, keeping your enterprise (and its data) safe and secure. Our global footprint means that we’ve worked with international enterprises across the globe. Check out our case studies to see proven results with leading brands in eCommerce, K12 online learning, financial services, and more.
