In recent years, close to 70 percent of exposed records–5.4 billion of them in total–were caused by unintentional internet exposure due to misconfigured services and portals–services like Amazon Simple Storage Service, known as S3.
Run a Google search for "S3 breach" and you'll see a who's who of major organizations across industries: Accenture, the United States Department of Defense, Walmart, Verizon, Experian, FedEx, Dow Jones. All of them have suffered a data breach as a result of a misconfigured open S3 container. And they're far from alone. According to RedLock CSI (Cloud Security Intelligence) 53 percent of businesses using cloud storage services like AWS S3 had inadvertently exposed one or more of their cloud services to the Internet.
An Avoidable Problem
The default configuration for S3–shorthand for AWS Simple Storage Service–is closed to the Internet. In that configuration, it's reasonably secure (or as secure as the application accessing it, anyway). But not everyone is using it in that configuration, as evidenced by those 5.4 billion exposed records.
To their credit, in the wake of these exposures, AWS changed their management console such that it basically screams at you if you're about to make a dangerous change to S3. But S3 is one of hundreds of user-configurable services in just one IaaS platform, and relying on correct user behavior–even users who are being screamed at–is a recipe for more exposures.
How to Get Safe, Smart, and Secure on S3
Reversing the trend on these preventable data breaches starts with three things: people, processes, and technology. It sounds trite, but in this case there are some practical things you can do that make a real difference in ensuring S3 security. (Remember: you're reading a security vendor's blog post. Claiming the technology can't solve everything is close to a revolutionary act.)
Everyone knows we have a talent problem in both security and cloud. Cloud security experts are the rarest of breeds. I've found five.
Rather than running your recruiters ragged trying to find that one-in-a-million hire, focus on what's achievable in the near term: train your own. Create centers of excellence for cloud security and invest in creating leaders in the field. It will pay off. (Bonus: the people getting trained will like it.)
Even the world's best IT organizations, the headline-grabbing superstars, have proven they don't always have their act together on security compliance. (Just ask any one of the blue-chip companies that have lost their crown jewels via an S3 exposure). When it comes to the cloud, organizations need to implement processes that control who can spin up instances, the documentation required to do so, and then put in place audit procedures to make sure those rules are followed.
Those audit procedures come back to people: this stuff needs to be someone's job. Anyone with an intern can make compliance checks routine.
You can't secure what you can't see. While cloud providers offer security monitoring tools, they offer limited use cases aimed mainly at known threat categories. They aren't in the business of analytics: they produce a sea of data points, but narrowly focused on single workflow instances or storage objects, with no broader context across the estate. Cloud providers offer the bare minimum, but third-party vendors are working to address this challenge. Here's what ExtraHop is doing.
ExtraHop Reveal(x) Eliminates the Dark Space in S3
ExtraHop Reveal(x) transforms application protocols and payloads to automatically surface anomalous activity in the enterprise. But we've also built the product as an open platform, recognizing that (a) there's interesting data everywhere, and (b) we can combine it with wire data (what we get when we decode all of those payloads and protocols), in potentially useful ways. By ingesting cloud-native data, combining it with ExtraHop wire data, and applying a world-class user experience to the results, we deliver a contextualized view across on-premise applications and multiple cloud providers.
This is the idea behind our AWS integration. We hoover up AWS events from CloudTrail, infrastructure metrics from CloudWatch, and VPC Flow logs, then we mash them up with ExtraHop wire data. We apply machine learning to the 4,600 data features we extract from application payloads, combine the output with cloud-native data from AWS, and use the resulting situational awareness to surface anything genuinely interesting, including outbound S3 access. Same goes for rogue EC2 instances, data exfiltration from RDS, and plenty of other opportunities for user misbehavior. Dark space eliminated.
Philosophically, we treat cloud environments as part of a broader attack surface-it just so happens the infrastructure is operated by a hyperscale provider, and one whose accountability to you, the operator, is… "tightly bounded," let's say. Technologically, we bring all your stuff together in one place, so there's one net to cast for misconfigurations, non-compliant services, and active threats.
Unite the Clans
As a practice, cloud security is past its infancy but far from mature. As enterprises evolve their approach to securing cloud infrastructure and applications, they should take advantage of a key underpinning of cloud platforms: standardization. While it's possible to deploy any kind of app to the cloud, and the variations are close to infinite, these platforms are supported by a standard set of components, APIs, and management infrastructure.
In other words, the SecOps team's job is a whole lot easier when there's a trustworthy system of record (i.e. the AWS or Azure APIs), a common set of components (EC2, RDS, et al), and process frameworks that apply equally well to securing on-premise and cloud environments (NIST, CERT).
That covers standardization in process and technology, but the last frontier is to unite the people who operate cloud environments. As with on-premise infrastructure, IT and Security executives should build relationships between SecOps and IT Ops to mutual benefit. SysAdmins and app developers should be the front lines in securing infrastructure, with training and governance from Security teams.
And this brings us full circle to people and process. ExtraHop can tell you what's out there and who's doing what with it. That should lead to more than just putting out fires, though. IT and Security teams need to better understand how their customers are using (and sometimes inadvertently misusing) S3 and other cloud components, and to treat it as a training opportunity. It can form the basis for better processes-who can do what with cloud-and better training to get people safer, smarter, and more secure on S3 (and everything else).