Home > AWS, Cloud, re:Invent > AWS re:Invent 2017: Security Anti-Patterns: Mistakes to Avoid – FSV301

AWS re:Invent 2017: Security Anti-Patterns: Mistakes to Avoid – FSV301

November 27th, 2017

FSV301 – Security Anti-Patterns: Mistakes to Avoid

Kurt Gray from AWS and Jonathan Baulch from Fidelity Investments

AWS has obviously spent a huge amount of effort building security into the very fabric of its cloud offerings. Enterprises still hesitant to use public cloud as they’re concerned about the security implications of AWS in my opinion are thinking old school. They are often taking the processes and procedures that they currently use on-prem and applying it to AWS rather than looking at all the new possibilities which are often more secure than they can do themselves.

AWS famously has touted the security split of “security OF the cloud” which is AWSs job and “security IN the cloud” which is the customer’s responsibility, however AWS has a huge number of tools to help with the IN part.

Kurt and Jonathan went through some of their learning about best practices and pitfalls. There are a number of governance patterns to avoid even though they may seem logical at first but may limit scale and throttle getting stuff done. This is all bundled under the banner of DevSecOps on a massive scale.

For best practices, they went through some things which they called “setting up key preventative and detective controls for implementing 360 degrees of security coverage” such as:

Account Management

  • Don’t have personally used AWS accounts with personal MFA and someone leaves with their personal phone
  • Have group contacts on all accounts, primary email is group distribution, Root MFA: hardware device in office safe
  • Contact info for office up to date
  • No one log into account root, Use IAM only
  • AWS Account overcrowding, one account with everything in it, initially seems obvious as its easier to manage. Increasingly becomes noisy, permissions get harder, lots of people to manage and work out responsibility, larger blast radius, ambiguous security boundaries
  • Have a multi-account strategy, AWS account per Biz Cap Dev Team. SIngle family homes.
  • Each Biz Cap Team is a separate object, like object orientated design use AWS service integrations.
  • Cloud Security team with controls and IAM roles across all accounts.

Network Design

  • Don’t trust IP address as primary method of identity, routing is not security dynamic IP whack-a-mole.
  • Implement authentication authorisation, design your web services to be publicly addressable, even if they’re not. Use API Gateway in front of EC2, Lambda, CLoud Trail as it gives you easier IAM & certificate  security. Share core services across teams/accounts
  • Don’t have network egress backhauling, basically routing traffic back through your enterprise and out again to public AWS services. Complex and not highly scalable. Rather use multiple VPCs, restrict proxy instances and use AWS external endpoints via an Exit VPC.

Infosec Auditing

  • Ask how your customers and partners audit you, it is often point in time and not continuous and tough to scale.
  • Use attestations instead of questionnaires which are standardised controls with 3rd party assurance.
  • Align with the standard controls.
    Avoid manual technical auditing which is how many companies audit themselves, its very inconsistent and typically reactive.
  • Have continuous auditing built with the idea of “security as code, use CloudWatch Logs + Alarms, Inspector for EC2, Macie for S3, Trusted Advisor, Config Rules, CLoud Confirmity, Cloud Custodian and many other 3rd party offerings.
  • Use AWS native managed services so you don’t have to reinvent all the security stuff yourself. This gives you consistency and compliance.
  • An example is RDS at-rest encryption and you can very easily write a script to check which databases are encrypted. Very simple, can be done with a Lambda function and a metric alarm. You can also use a Config rule to check.
  • S3 bucket controls, you can have preventative controls with a S3 bucket policy or have reactive controls with a Lambda function to automate S3 policy from a Cloud Watch alert for remediation and tell you and also fix the stuff you broke.
  • Good idea of also training for auditors. AWS has an Auditor Learning Path to help with the goal of DevSecOps.

Software Delivery.

  • Over the wall software delivery with siloed teams, Dev, QA and Ops are kept seperately with manual handoff processes. Security checks are only post-deployment.
  • Rather do better DevOps with smaller interdisciplinary delivery teams for better software deliver life cycle.
  • You can create a very good DevSecOps pipeline with CodePipeline.

Lambda for Ops

I was very happy to hear them talk about how Lambda can be used for compliance. With talk about how serverless will remove Ops. I have recently been speaking at VMUGs about serverless and mentioning a great use case using serverless and Lambda to help with Ops, specifically security and compliance. Lambda functions can fire off to enforce your business compliance rules by limiting access to S3 buckets for example so even if someone does inadvertently open up an S3 bucket to where it shouldn’t be it can be automatically resolved in an event driven way.  Lambda can also be used to generate compliance reports, for use internally or even to pass to regulators. Enforcing security by policy and then being able to report on that easily perhaps using Lamdba is very useful and a giant cost saving on how its often currently done. As all things AWS can be done via code: we may have done Infrastructure as Code, how about Security as Code, Compliance as Code or Governance as Code. Can you code all your security requirement and have policies that automatically apply them? I like Capital One’s idea of a “Cloud Custodian”.  I see auditors eyes light up and operators breath a sigh of releaf as its far easier to do security governance by automatically applied policy and remediation than the alternative.

Unfortunately I had to leave early as I needed to head across Vegas because size of conference.

Categories: AWS, Cloud, re:Invent Tags: , ,
Comments are closed.