How to Secure Your Information on AWS: 10 Best Practices

The 2017 Deep Root Analytics incident that exposed the sensitive data of 198 million Americans, or almost all registered voters at the time, should remind us of the risks associated with storing information in the cloud. Perhaps the most alarming part is that this leak of 1.1 terabytes of personal data was avoidable. It was simple negligence. The data repository was in an AWS S3 bucket that had its access set to public, so anyone could find it—and download much of it—by navigating to an Amazon subdomain.

Sponsorships Available

We all know that the misconfiguration of an S3 bucket is a common mistake. That’s because organizations oftentimes overlook IaaS systems like AWS. But such negligence isn’t defensible over the long term. Indeed, the Deep Root Analytics leak emphasizes the importance of organizations adopting a strategy that can help them avoid this type of costly misstep by focusing on properly configuring their AWS assets.

The AWS platform itself has strong security thanks to extensive investments by Amazon. Even then, the strongest defenses are vulnerable to attack by resourceful bad actors. As we saw back in 2016 in the Dyn DDoS attack, a large-scale attack can still overwhelm the sophisticated security protocols of AWS.

Let’s keep this in mind as we set the record straight on the shared responsibility model. Specifically, it’s important to clarify what organizations and CSPs are responsible for protecting under this framework.

Understanding the Shared Responsibility Model

Under a shared responsibility model, both the vendor and the customer are responsible for securing the cloud. The vendor, Amazon, is responsible for the security “of the cloud,” i.e. its infrastructure that includes hosting facilities, hardware and software. Amazon’s responsibility includes protection against intrusion and detecting fraud and abuse.

The customer, in turn, is responsible for the security (Read more...)