Skip to main content

Who's watching your data?

By Anonymous



Open to the internet
Let's face it, cybersecurity can be a scary business, so what better time of year to highlight the fears of cyber crime than Halloween?
We've all heard the scary stories, read the chilling books, and watched the horror movies where someone is being watched - picture the scene with the creepy guy standing outside the house, looking back in through the window. Most of us close our curtains and lock our windows and doors at night before going to bed, hoping not to encounter the creepy guy. But If we go to great lengths to stop someone peeping into our private lives, or getting into our home, then why don't we do the same with our data; especially our data that's in the cloud. It's scary to think that a lot of data, especially on public clouds is left open to the internet. According to our security market research, nearly 80% of databases in amazon cloud are left unencrypted, of which 30% are open to the internet. The smart hackers who know about this scour these unprotected havens looking for data they can exfiltrate.

We previously covered a story about Booz Allen Hamilton, who recently had a data leak in AWS. Lack of good security controls left their S3 bucket data open to the internet, which resulted in the exfiltration of over 60,000 sensitive files.

 Using the Booz Allen Hamilton incident as an example, let's discuss how you would go about implementing the right security controls and detection mechanisms to avoid such a mistake.

Convenience can sometimes lead to insecurity

 At the heart of Booz Allen Hamilton's incident investigation is speculation that they traded convenience for security best practices.  Initially creating a S3 bucket is easy. As you can see in screen-shot below, public access is not the default mode and AWS does not recommend making the bucket public.
So why would this happen?  We believe there are 2 main cases for this:
  1. Setting up the bucket before you have all necessary information about who will be accessing it and how they will be expected to access it.  This includes what credentials they will have and what IP address(es) they may be using.  In this case, it may be easier to just make the bucket public and come back to it later.  But, especially for overloaded security folks in large organizations, later will never come.
  2. The business purpose of the bucket changes without the security team’s knowledge.  If you create the bucket believing that nothing sensitive will be stored here, then it needs to stay that way.  If the business use of the bucket changes, the permissions around the bucket should be revisited.

Since AWS does not recommend the use of Access Control Lists (ACLs), users should be creating S3 bucket policies to establish granular permissions around the bucket and its contents.  However, policies can be a little cryptic if you are not familiar with them.  In order to help with this, AWS provides the policy generator tool.  As shown below, this tool makes it easier to select the actions you would like to allow (or deny), specify the resource (a bucket in this case), and the principal.  The “Principal” is the actor to which you are applying the permission.


If you use “*” in the Principal field, this will apply the permission to any unauthenticated user.  So, if you selected the actions of “GetObject” and “ListBucket”, this would essentially allow anybody on the Internet to enumerate and download the contents of the specified S3 bucket.  This may be the most convenient option if you don’t have all relevant data to create a more granular policy.  However, this may not be acceptable exposure for the contents of that S3 bucket, so we recommend gathering the necessary pieces before opening the bucket like this.

 Final thoughts

It's very easy to take shortcuts while setting up a S3 bucket in AWS. We saw how impactful this can be, as with the case of Booz Allen Hamilton.  To help prevent this type of incident happening in your environment, we recommend the following:
  • Enable file-level data collection in CloudTrail for your buckets, since it’s not enabled by default.
  • Use granular policies whenever possible.
  • Don't use * for Principal, unless it’s only going to house public data.

In addition, Sift Security's CloudHunter product can help make the job of protecting your S3 bucket data easier.  Some of the functionality we provide out of the box includes:


  • Alert you to ACL and policy changes.
  • Automatically detect when a bucket or object is being exposed to the Internet.
  • Allow you to lock permissions, so the permissions are automatically corrected before unauthorized access happens.




Popular posts from this blog

Data Exfiltration from AWS S3 Buckets

By
You will have no doubt heard by now about the recent Booz Allen Hamilton breach that took place on Amazon Web Services – in short, a shocking collection of 60,000 government sensitive files were left on a public S3 bucket (file storage in Amazon Web Services) for all to see. We are all probably too overwhelmed to care, given all the recent breaches we have been hearing about in the news. But with this breach it was different, it involved a trusted and appointed contractor whose job it was to follow security policies, put in place to avoid such incidents. So was this incident accidental or malicious? More, later about the tools we can use to tell the difference between the two. First, lets recap what happened. The Incident According to Gizmodo , the 28GB of data that was leaked not only contained sensitive information on recent government projects, but at least a half dozen unencrypted passwords belonging to government contractors with Top Secret Clearance – meaning anyone who got
Read more

Sift Joins Netskope, the Cloud Security Leader

By Anonymous
Four years ago, we started Sift with the mission of simplifying security operations and incident response for the public cloud. In that time, we have assembled a fantastic team, created an innovative cloud detection and response solution, and have worked with many market-leading customers. I’m delighted to share that we’ve taken yet another step forward — as announced today, Sift is now officially part of Netskope. You can read more about this on Netskope CEO Sanjay Beri’s  blog  or in the official  announcement  on the Netskope website. For our customers, investors, partners, and team, this is an exciting new chapter. Let me tell you why we’re so excited.  Since the beginning, Netskope has had an unmatched vision for the cloud security market. Having started in 2012, they initially focused on SaaS security and quickly followed that with IaaS security capabilities. Six years later, they are now more than 500 employees strong and used by a quarter of the Fortune 100. They are a l
Read more

Sift Security vs. Elastic Search and Elastic Graph

By
We are often asked, “What is the difference between Sift Security and Elastic Graph ?” This is a great question that typically comes from folks who are already familiar with Elasticsearch [0] and Elastic Graph [1]. The answer boils down to the following: Elastic Graph is a tool for visualizing arbitrary aggregate search results. Elasticsearch is a Restful search that distributed, and has analytics engine that solves a number of use cases such as mapping from Python to ES REST endpoints. Sift Security uses a graph database to simplify and accelerate specific security use cases. In this blog post, we describe the advantages of each of these approaches, and conclude with a discussion of when to use each. Advantages of Sift Security vs ElasticSearch and Elastic Graph Query speed Sift Security builds a property graph to represent security log events at ingestion time.  We do this work at ingestion time for one reason:  to speed up common investigative queries.  When investi
Read more