Achieving agility with control in Financial Services on AWS

Alex Mags

Attended “Achieving agility with control in Financial Services on AWS” talk today at AWS Loft London 2015.

  • The usual AWS slide of company logos was there for “look how many companies use AWS, so it must be safe!”. This list wasn’t tailored to Financial Services (Tinder, really?).
  • There was a bit about Agility focusing on Continuous Integration (CI also known as automated testing) and Continuous Deployment (CD also known as automated deployment).  A mention of how the services AWS Code Commit and AWS Code Pipeline might be able to help financial companies with this, after they’re released of course.  On the topic of streamlining the release processes, here’s  pragmatic article about introducing Agile into larger Enterprises while accommodating the governance and control required in regulated industries.
  • The Control side of the talk was a bit light though.  AWS Config and AWS CloudWatch will help you track what API calls have been made and what changes have happened. So, retrospectively, you could see which AWS credential was used to change something.  Having an audit trail is great, and a requirement, but that that isn’t control.  You could look up in AWS CloudWatch which AWS Identity and Access Management (IAM) credential was used to exfiltrate sensitive data from an S3 bucket to an IP address abroad. You could even setup a notification via AWS Simple Notification Service (SNS) to get an email when people access S3 from an IP address that isn’t one managed by the company.  You can even trigger a AWS Lamda job to automatically write that letter from the CTO to the board explaining that a data breach has occurred.  But none of that will make Financial Services feel safer about moving out of their datacentres onto AWS.
  • There was a DevOps style “you don’t really want control, what you want to do is empower your developers to make changes in production”.  There was no information about how to empower development to bring up and tear down infrastructure on demand, without the risk of some rogue script trashing production.  Or how to give developers useful access to test environments and maybe just read-only access to production environments. “Separation of roles and responsibilities is a good idea” was mentioned, but not how to achieve this practically within AWS (where security is based on tags, but anyone can change the tags on anything).
  • When pressed about “how are financial companies managing to delegate access to development while maintaining a level of control” the presenter suggested giving development their own AWS account. 
  • Using the Principle of least privilege within an AWS account is not at all easy. I’ve yet to find a way to delegate developers full access to EC2 services (virtual machines, subnets, security groups etc) in a test environment without those rights leaking into production environments The AWS security policy attempts to mask API calls based on sometimes resource tags, sometimes subnet ID (which changes when you create new subnets), sometimes other exotic conditions. This seems to break down quickly since the ability to set tags (required to deploy a VM) is global. To get access to production you simply retag it as test and make your change.  I’m fairly new to AWS security policies, so I may well be missing something, but if security is complicated it’s also going to be difficult to maintain and difficult to convey to an auditor/regulator. What’s more likely is you’ll have your engineering team prepare tools and interfaces that manage AWS infrastructure on behalf of the developers. Instead of giving developers direct access to AWS Console and APIs, and then attempting to control what they can do within the console and API, your developers will use your in-house console and in-house API.  Or find a 3rd party tool that does this.  

AWS Loft session here http://awsloft.london/session/Presentation/2015-09-16/03-00/achieving-agility-control-fs-aws-606702.html