Home Features Configure your buckets else leaks are going to cost you

Configure your buckets else leaks are going to cost you

IaaS

With several benefits that accompany digital transition, adoption to a cloud environment has also left several cracks in the system, thereby opening several windows of vulnerability. In fact, among the enterprises in APAC that have embarked on the digital transformation, the cloud has the highest adoption rate with nearly 69 percent. But what about cloud security? As we, at CISO MAG, publish the Power List of powerhouses in cloud security, we hark back to the few major threats and vulnerabilities in the space.

It is very evident from the stats and figures doing the rounds that cloud, be it traditional or hybrid, will rule the roost as one-stop solution for data center solutions for the next decade or so, until newer methods come to fore. Around cloud, one single or rather the most potent name to come to everyone’s mind is Amazon Web Services (AWS). But, AWS Simple Storage Service (S3) buckets have often been marred by configuration errors from vendor’s end, making buckets from AWS perhaps having rather larger holes than the data it accommodates. The recent and the famous one being the leak at Facebook.

Cybersecurity firm UpGuard was the first to notice the glaring error and ended up finding two data breaches in two different regions. The first originated from Mexico-based media company Cultura Colectiva which exposed around 146 GB of data that contained over 540 million records detailing comments, likes, reactions, account names, FB IDs, and other sensitive information. The second was a separate database from a Facebook-integrated app named ‘At the Pool’ which exposed data via an Amazon S3 bucket. This database contained the backup information like fb_user_id, fb_user, fb_friends, fb_likes, fb_music, fb_movies, fb_books, fb_photos, fb_events, fb_groups, fb+checkins, fb_interests, and passwords, according to UpGuard.

AWS cannot be blamed here the data was stored without any kind of password protection and could have easily be accessed by anyone with a mediocre knowledge of cloud systems.

“The public doesn’t realize yet that these high-level systems administrators and developers, the people that are custodians of this data, they are being either risky or lazy or cutting corners,” said Chris Vickery, director of cyber risk research at UpGuard. “Not enough care is being put into the security side of big data.”

Detectify Labs took a deep dive into ‘AWS S3 access controls – taking full control over your assets’ on a blog. It notes that “If you are vulnerable, attackers could get full access to your S3 bucket, allowing them to download, upload and overwrite files.”  It points out the S3 bucket name is most often not a secret. Once an attacker knows the name of the bucket, he can leverage multiple misconfigurations to access or even overwrite data, “leading to three different scenarios. By using the AWS Command Line to talk to Amazon’s API, the attacker can: Get access to list and read files in S3 bucket; write/upload files to S3 bucket; Change access rights to all objects and control the content of the files (full control of the bucket does not mean the attacker gains full read access to the objects, but they can control the content).”

According to the research firm, the company may not even find out that the attacker has full access to S3 bucket. The key solution is to change the privileges of your buckets. “AWS are aware of the security issue, but are not likely to mitigate it since it is caused by user misconfigurations,” it adds.

Securing buckets are of the biggest issues with AWS. Even though, the security teams from Amazon can apply security policies for the entire cluster of containers but providing security to each pod is often beyond their control. And this makes the system vulnerable. Even when you are trying to communicate or troubleshoot with the pod, the insight will stop traffic between the host and the cluster resulting in a security blind spots around your pods. One method to combat this is to have two solutions on your cloud network, one for handling VM policies while the other for governing the containers. But the only problem with the deployment of the two-step system is the complications that accompany it. You have probably moved to cloud to make sure that data management is easier and free of risk, not to make it even more complicated.  Another major hurdle with AWS is the lack of visibility. There is a belief among several cybersecurity leaders of large enterprises that storing data on premises means better control and visibility, which is not often the case when the data is moved to cloud servers and containers.

Here is the thing, necessity for cloud adoption varies from company to company. And in most cases, the benefits of cloud computing depend on the kind of business the organization is. Just like with any tool, organizations ultimately must consider their risk profiles, staffing and access, resource allocation, and regulatory policies within the organization, and risk appetite before making a decision about cloud storage.

It all comes back to you. There are reasons why AWS is the behemoth in the space, it is one among the most reliable ones out there. All you need to do is check all the boxes for any configurational glitches.