Amazon’s AWS service offers S3, as simple, do-it-yourself cloud storage, with the option to divide data in up to 100 buckets on Amazon’s servers, each with different permissions and authentication rules.
Securing the servers is Amazon’s responsibility. Configuring and safeguarding the S3 buckets is the responsibility of the bucket owner. And that seems to be where things go wrong.
The S3 buckets come with strong security out of the box. But the owners end up misconfiguring the buckets, leaving their IP addresses wide open on the web for anyone to sniff out, using tools readily available on code repository sites. Further increasing vulnerability, many owners don’t encrypt their data.
Let’s create a case study about a large retailer that has 250 S3 buckets from Amazon. The S3 buckets are servers that need to be configured and secured by the retail company. They contain millions of records of data on customers who shop at the retailer on a frequent basis.
The S3 bucket is not the risk, though you might have read this in articles circulating around the web. The true risk is that information is compromised due to the bucket not being secured.
There are 4 main elements to define in scoping:
The Asset at Risk
Something that may be affected, either by diminished value or by creating a liability for the owner. Applying that lens, it’s the data in the S3 buckets that we are concerned about.
The Threat Actor
When looking at recent breaches that are occurring in these buckets we are seeing the main threat as an External Malicious Actor. These actors are out for confidential data that they can sell on the black market.
The Effect
In other words, what you are worried about happening. The three types of effects are confidentiality, integrity, availability (C-I-A). In this case, the effect would be “C”, a loss of confidential information.
The Loss Event
How much risk is associated with a breach of customer PII data in a misconfigured Amazon bucket?
Now that we have defined the loss event, we’re ready to dig in to the analysis by gathering data from experts within the organization (for instance, the incident response, business continuity, or disaster recovery teams).
The FAIR model provides the framework for our research. For any scenario, we need to understand the potential Magnitude (ultimately, the cost in dollars) and Frequency of losses, based on previous experience within the organization and the industry.
I would question the subject matter experts along these lines:
Loss Event Frequency or Threat Event Frequency
Loss Magnitude
Ask the experts for accurate cost data, based on known costs:
We’re ready to enter the data gathered into an application such as RiskLens (the technical advisor to the FAIR Institute) and use a Monte Carlo function to simulate a vast number of outcomes. The output is a smooth curve graph showing a range of potential losses in dollars on an annualized basis.
Final step: Compare the range to your appetite for risk and decide if risk controls are worth the investment. To protect against a breach of confidential information, controls may be to simply go back and correctly configure your AWS bucket or encrypt the data on the bucket.
This post has been updated. It was originally published on October 6, 2017
Related:
FAIR™ Analysis Case Study Webinar: Decrease Risk from Employees Working at Home
Anatomy of a FAIR Risk Analysis: Confidential Data in Email