Tesla is facing a possible multi-billion dollar fine¹ for its latest data breach which exposed customer bank account details¹ as well as employee PII, reportedly including Elon Musk’s SSN².
Tesla is blaming a “service technician”¹ for the breach, and suing them and one other employee, but does the company itself bear any responsibility?
Details of the breach are scarce so its hard to say exactly how it occurred and if the company could have done anything to prevent, but let's take a look at the following hypothetical scenario with some similar details and see if Chaos Security Engineering could identify possible security weaknesses before an adversary could exploit them.
Chaos Security Engineering (CSE) is the creation and execution of “experiments” to test that your security controls are working as desired. Many times security controls are non-existent, insufficient, or stop working over time, therefore its important to use CSE to regularly, automatically, and sporadically test these.
Let’s say XYZ Corp has 2 S3 buckets, one with company payroll info and one with customer banking information used to auto-debit their account monthly. Let’s also assume there is a service technician who has access to AWS but does not have a business need to access either buckets.
Right off the bat, I see a couple issues here, one, there is no blast radius with respect to HR data as well as customer data, these items should really be in complete separate AWS accounts. Two, additionally that data should not be in a file in an S3 bucket, even if the bucket is encrypted, this is something which should be in a database, with table and/or column level encryption. Then even if you had to make a backup of the database and store that in S3, the sensitive data would be encrypted.
Back to the topic of encryption, there are a number of ways to encrypt data in S3, ideally this should typically be done with a Customer Managed KMS (CMK) key, with IAM permissions disabled in the KMS resource policy. Common mistakes that companies often make are using the S3 default encryption, an AWS Managed KMS key, or allowing IAM permissions for the CMK.
With respect to SCE what kind of experiments might help here?
A frequent blunder I see is assigning the “ReadOnlyAccess” policy to low level accounts, such as service technician. While the name sounds rather trivial from a security point of view, it actually is quite dangerous and allows full S3 access. A much better policy would be "ViewOnlyAccess", with a custom policy to add gradual permissions where needed.
Ergo, one SCE experiment would be to attach that policy to a role and confirm that it gets removed automatically.
Another experiment would be deactivating any KMS keys which are created that allow IAM permission in the resource policy.
Finally, a policy that takes action when an S3 bucket is created not using a
CMK key.
With these controls in place, and regularly verified by SCE tests, users who should not be able to, would not be able to access the data in the first place, preventing the breach from ever occurring. With such a negligible cost to do SCE there no reason why more companies aren’t doing it, especially considering the ROI value when facing possible million or billion dollar fines.
To learn more about SCE and see some real experiments in action, join cloud security experts Ankit Mehta and Nick Gilbert CISSP for the Florida AWS Security Users Meetup on 9/13. Chaos Security Engineering Demo
About the author: Nick Gilbert is a Cloud Security Expert, working in the financial field, and part of the AWS Community Builders Program.
Oldest comments (0)