Winter is coming, so let’s talk about clouds with leaking buckets.
As you may know, AWS is the market share leader in the public cloud services space, with 31% of the revenue pie (or 33% of a smaller revenue pie), and as uncle Ben preached to the young Peter Parker: “With great market share comes more probability that assets hosted on this infrastructure would get hacked” (yes, many people don’t know that Peter started his superhero career as the friendly neighborhood IT-man, but was overwhelmed with the number of people forgetting their passwords and opening support tickets, so he switched to a career in web development).
Anyways, a lot of companies use AWS, which means a lot of developers use AWS, and since practically every AWS customer utilizes S3 in some way – S3 is probably the most used cloud service in the world. Launched in 2006, it is also one of AWS’ oldest services, and as versions, features and abilities were upgraded or replaced, some of S3’s modules – including permissions – turned into very complicated and time-consuming to use.
To the uninitiated – “Buckets” are AWS’ basic containers, which hold the objects that are being stored and retrieved by processes running on the cloud. A company’s service running on AWS could be using hundreds of buckets, each containing hundreds or even millions of objects. AWS calls them “buckets” because you can simply drop things into them. Google Cloud also calls them buckets. Microsoft Azure calls them “blobs” because Microsoft.
All these buckets – like any digital object, actually – need to have their access privileges configured, so that only the relevant users and processes would be able to pull and push data from and into them.
AWS’ services’ access privileges are managed by multiple complex mechanisms inside IAM. The S3 service is a privileged (pun intended) service, in the sense that it supports “Resource-based policies”, in which the user can configure each resource and decide which actions by applications communicating with this resource are allowed or blocked.
What was supposed to enable better management of access, turned into a data leakage nightmare, as S3 buckets left misconfigured enabled anyone to get their hands on companies’ customer data, healthcare records, dating apps’ user data, exposure of a secret government data scraping mechanism,municipal data breach and other infamous and embarrassing incidents.
Why are these buckets misconfigured? Well, my neighbor told me yesterday that he heard from a very authoritative source (his aunt), that it is definitely maybe probably caused by the Covid-19 vaccination, but we believe there’s a simpler, less conspiratory explanation for that: It is soooooo easy to use wildcards (*) and it takes time and knowledge to craft the right least privilege policy.
It’s not just laziness (sorry, “passion for work and not for admin tasks”) – The reasons for providing higher-than-needed access to these components vary – temporarily adding an expert developer from another team to your crew to deal with a specific issue they can assist with, or maybe opening up a channel for a team working for another company that is co-developing the solution with you – in any case, these doors are left open after the invited guests had concluded their visit, so now even uninvited guests can enter through them.
AWS is obviously aware of this problem, and has recently began offering its users a wizard-like configuration tool, to ease the process of defining IAM policies. However, the outcome itself is just a template, so the users need to complete the policy manually by themselves. Even if the tool is used to produce an IAM policy, it fits that moment in time and will remain the same even as the user changes the actual structure and usage patterns within the bucket. Oh, and it doesn’t even support S3 bucket policies…
What’s needed is not only a flexible way to adapt the configuration to the actual and specific workflows the user is using, but one which is dynamic: constantly checking if there is a change in assets, relationships, access, outcomes, etc.; discovering gaps between current access privilege level and needed privilege level; alert on such gaps and suggest configuration changes; and even remediate the situation by automatically update the relevant configurations itself.
Look, we get this. The reason we started Solvo was to enable developers to do what they love and do best – code – and not spend time on managing access to their components, buckets and blurbs (or whatever they call the inhabitants of planet Azure).
Here’s the good news: We’re making it less boring, and much more secure, by making it semi-automatic or fully automatic to initially and constantly check the S3 buckets’ configurations, discover misconfiguration gaps, suggest changes and/or remediate the situation automatically.
Furthermore, the “access relationships” (i.e what can access what within a bucket and across buckets) are presented as a visual and not just in boring . The user can see which component can perform which action on which resource, and on top of it we provide some insights and advice on how to tweak the access configuration in order to make it more secure yet still frictionless from a workflow point of view. This visual representation is also a great way to discover redundant or unused privileges, such as a service that was granted access to an object, but never actually accessed that object – which would raise the question: does that service really need that privilege?
But our claim to fame is the automatically tailored access configuration process, where we understand the relationship between the components and how they utilize each other to perform the job to be done, then configure the access level of each of these components individually so that it will allow the process to take place but not offer higher access level than needed to perform the relevant tasks.
AWS Simple Email Service (SES) component to receive inbound emails, Let’s say you’re using and store these emails on Amazon S3 for further processing or archiving. Solvo analyzes the process and relationships between the SES and the S3 bucket, and then reconfigures the access level of the S3 bucket to the least-privileged access level needed in order for this process to continue its course without friction.
How do we do it? For each bucket, Solvo initially analyzes the current configuration definitions, then assesses the severity of its breach potential by how permissive they are in providing access to objects housed within that bucket. For example, if the said configuration allows an unauthenticated entity to change the bucket’s own access configuration – Solvo treats this as a very anomalous privilege, and raises a flag.
Solvo is also integrated with AWS’ CloudTrail service, which tracks user activity and API usage, and uses the CloudTrail logs to analyze the relationships between the identities and objects within the S3 bucket, and come up with suggested configuration changes, that will secure the work environment – without affecting automatic or manual workflow.
The result is an ongoing automatic process that takes the burden of configuring and maintaining access rights to S3 buckets from the development teams, allowing them to focus on actually developing, yet keeping the development (and later, production) environment secure. Yes, we’re your friendly neighborhood cloud-security gender-agnostic person (we’re still working on our costume. And theme song).
Want to take Solvo out for a test drive? Just click here and get the party started.