Audit and Encryption
In the first article I introduced some general AWS terminology and ranted at length about identity, this article will follow roughly the same pattern, although for this I’m going to rant about auditing just what the Computer Users — Untrained are up to (aka: spy on _everything_) and the topic dearest to my black heart, encryption!
CloudTrail
As discussed in part one, major Cloud Service Providers tend to be built around REST API’s — where everything is effectively a webpage but intended for machines not humans, its not as fast as some other approaches but has massive benefits in allowing different systems to be able to talk to each other without worrying about whats behind the ‘other’ API. One of the main reasons for Amazon’s dramatic transformation from a bookseller to one of the biggest IT players on the planet with a speed of innovation and change that is off the charts and Jeff Bezos a multi-gazillionare is because early on he grasped this concept and enforced it ruthlessly (I’ve heard rumours he hired a former US Army Ranger to handle ‘enforcement’)
Because we are dealing with HTTP requests, much like when you access a website, a logfile is written to saying what you (or your IP address) accessed or looked at (yes, on those sites as well…) and Amazon does the same with even more enrichment as they know the identity you’ve configured as well through their Audit control plane, Cloudtrail.
Cloudtrail can even record data events, such as who has accessed a specific file in S3, which can be handy should someone mess up and put the wrong file in the wrong place, like perhaps putting your customer database or ultra top secret stealth plane tech in a public bucket.
“But Ben” I hear you cry “Surely I can disable CloudTrail”. Well that’s true, but first you need to have the rights to disable it, which ideally a normal user (the most likely to be compromised) is unlikely to have, as long as the roles for the accounts have been setup correctly.
Assuming the scenario is that user X has the rights to alter CloudTrail trails, or the root account itself has been compromised, how then can we detect that this is the case?
Amazon have a nice solution whereby you integrate with CloudWatch Events (part of the system monitoring suite built into AWS), that will issue an alert and change the monitoring back to what is expected — I like this approach, but misses one important thing, its just another step for J Random Hacker to disarm first before they proceed to have their nefarious way with the account.
My own approach is to have the CloudTrail trails written to a S3 Bucket in another account intended solely for securities use using cross account access, have them ingested into a monitoring system and put similar alerting in place, I also like to add in a Canary, something that is always happening, usually very discretely, that breaks the policies the account operates under, trying to launch an EC2 instance in a different region for example, or create an S3 bucket — essentially something that should always fail, with a known set of parameters that can be filtered on and then monitor the negatives.
This will now force an attacker to compromise two separate accounts in order to have any extended activity within the target account, otherwise perform a smash and grab, given the horizon for this smash and grab can be as low as 20 minutes (15 minutes for the log to be written, upper bound, 2–3 minutes for ingestion and 2–3 minutes for the alert to be responded to), they would either know exactly what they are after, or have to grab anything and everything.
The recorded events themselves are JSON documents, although Amazon provide you with means to analyse them, they can be easily integrated with a huge number of 3rd party products if you already have tooling in place.
Key Management Service (KMS)
KMS is the cornerstone of AWS encryption, being the backend for all managed services and a key integration technology for wider use. It doesn’t in of itself encrypt & store data directly (although this can be done for items <4K in size), but rather uses a technique called envelope encryption to provide ‘data keys’ for encryption that are constantly being rotated (changed to minimise the scope of them being compromised) and a Customer Master Key (CMK) that handles the decryption and is the long term key.
For the cryptonerds (aka me)
ciphertext = Encrypt(dataKey, message)
encryptionKey = Encrypt(CMK, dataKey)
Envelope = (encryptionKey, ciphertext)
This means only people with access to the CMK can decrypt the message, with the dataKey being a single use, effectively OTP-like key, but this is complex and nerdy, this is what it looks like.
When creating a resource, select the key to use, its encrypted at rest going forward — HUZZAH, big compliance hole filled!
And yes, Amazon DO NOT have access to your CMK, in fact they almost violently do not want it, your data security is your problem, they will just give you tools to help you secure it.
Historically KMS was built on ‘Hardened Server Appliances’ (basically PC’s), however in the last few years (shout out to Project Baldr), there has been a shift towards ASIC based dedicated hardware that has met FIPS-140–2 requirements (which is a VERY BIG THING)
In addition to the default keys Amazon provide (which they are moving away from), they give you the option of creating your own keys using their source material — or if you don’t trust them, and some organisations for ‘reasons’ do not, you can generate your own cryptographic material from your own entropy sources (which I hope are Hardware Security Modules) and import for usage within AWS.
One of the very nice features in use (and yes this is something I have been bit by, and indeed inflicted on others), is that keys cannot be deleted immediately, but rather become unable to be used to encrypt data any further and are only deleted after a ‘grace period’ of 30 days or more.
All of this means
An observation though (which has come up), there is no way of exporting a data key, and even if there was, there is definitely no mechanism to import it back into Amazon — this might sound odd, but some organisations have requirements for storing all encryption keys, and this needs to be addressed upfront.
Up Next
I am painfully aware that this article has been in the works for almost 6 months for ‘reasons’, hopefully the next one up will be in significantly less time (maybe only 3 months!) where I will go through AWS Config and the brand new(ish) Security Hub.
