I’ve been busy studying for the AWS Certified Solutions Architect certification so it’s been a couple of weeks since my last blog. There are no study guides or sample exams for this so I’ll put together my notes here. Plonk me in your twitter, RSS or email subscriptions if you’re interested. And I crashed my scooter… And then Bluehost crashed my server. It’s been eventful.

We’ve got to Part 7 in this series and not mentioned the S word: Security!

Talk to your AWS representative and they will swear until they’re blue in the face that their services are as secure as an on-premises solution (or even better). They’ll quote security standards such as SAS 70 (replaced by SSAE 16 SOC 2), ISO 27001/27002, PCI-DSS and CSA. And it’s all true… sort of. For the elements of infrastructure AWS look after (physical security and virtualisation layers) I’m confident they do a great job. But the problems with Security in AWS have less to do with Amazon and more to do with the nature of “cloud disruption”.

Security product development and Enterprise security models have developed around the “rings of trust model” shown below. Security products are typically located at, and built for the periphery and enterprise security is typically like a castle (big outside walls to keep the bad guys out but once they get in they can do pretty much whatever). There are some great papers at The Jericho Forum about this phenomenon and its implications (They call it ‘deperimeterization‘! Thanks guys… that’ll make it easy to explain to my boss)

Rings of Trust

With cloud computing you have multiple sets of these “rings” possibly in different clouds, and you may not control all the “rings”! For example, you don’t have full control of the network “ring” in AWS. Security practices around protection of data at rest, data in transit, global identity management and ubiquitous data classification must be considered for all cloud-based platforms. How much will this cost to implement?

The Information Security industry is playing catch-up. There are interesting developments in Security-as-a-Service (eg. Imperva), federated identity management, dedicated VPNs etc., but other problems are hard to solve. How do you manage DLP, log management (hint: data transfer costs can kill you) and encryption (urgh key management!) in a cloud environment without limiting or removing the advantages of using cloud services in the first place?

There is an inherent security problem in the AWS operating model too. To efficiently utilise infrastructure customer workloads run shared on physical servers. The hypervisor boundary that separates AWS customers must be secured. Hypervisor exploits do exist! There’s also the problem of the “noisy neighbour” that can impact the availability your platform. Amazon provides a solution to this. You can purchase a dedicated instance that runs on hardware dedicated to a single customer but you’ll pay 30-50% more.

Another school of thought is that security can be “managed” contractually but this has problems.

  1. AWS is a retail provider of IT infrastructure that makes money by providing a standard platform. Writing different contracts with different provisions for different customers costs money, to them and ultimately you.
  2. Amazon quite plainly states that they run a shared responsibility when it comes to security. Companies can and do install insecure software and configure API access insecurely.
  3. You cannot outsource your reputation. If there is a security breach your name will be in the newspapers – and even worse the blogosphere – not your providers.

That’s my brief-ish brain dump on security issues relating to AWS. Your thoughts? What have I missed? Or overstated? Or understated?