AWS re:Invent Notes: FSV301 — Security Anti-Patterns: Mistakes to Avoid

Before you read any further, I want to make it clear once again, that these are my notes from the AWS re:Invent sessions I’m attending.  I certainly want these to be helpful and informative, I hope they fuel your desire to learn more about AWS, I just don’t want you to take them “as gospel truth”….

This session was delivered by Kurt Gray (Solutions Architect, Global Financial Services, AWS) and Jonathan Baulch (Director of Architecture, Fidelity Investments) and dealt with (4) types of Security Anti-Patterns:

• Account Structure
• Network Design
• InfoSec Auditing
• Software Delivery

When deploying AWS architectures, AWS engineers had developed a lot of “tribal knowledge” in regards to what worked and what didn’t work when configuring security for those architectures.  This session discussed the common “anti-patterns” listed above and security best practices to resolve them.

First, anti-pattern was defined as “a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.”  The problem was organizations were not taking advantage of new capabilities because they stuck in old ways of thinking.  To illustrate the point they were trying to make, they showed a picture of a horse pulling a car.

The risks associated with security anti-patterns are the following:

• Lack of Security Ops Agility
  • slow threat assessment
  • can’t patch fast enough
  • reactive security posture
• Lack of business agility
  • slow to onboard new customers
  • hard to practice true DevOps
  • Rogue IT
  • Can’t stay ahead of business “disruptors”

The  Four Common Security Anti-Patterns

Account Structure

When dealing with corporate AWS accounts, your AWS root account should not point to a specific person.  If MFA is configured (as it should be) on the root account, if it’s tied to somebody’s phone, if that person leaves the organization, so does your control of that AWS account.  Kurt said it was “hard” for AWS to assign a new root user to an AWS account….

Here are some of the recommend best practices in regards to the Account Structure anti-pattern:

• The root email/account should be a team distribution list
• The root MFA should be a hardware device in an office safe
• The account information should include a company street address and phone number
• Nobody should login using the AWS root account
• Additionally, limit “blast radius” using a multi-account strategy by assigning an AWS account per business team/department.  This creates clear and logical security boundaries.  If using a multi-account approach, create a “cloud team” that has access to everything and limit access to this team account.

Network Design

• Anti-Pattern #1 – using trusted IP access lists without client authentication.  The basic point is that in and of itself, routing should not be the primary security method as it does not identify end-users, it does not provide defense in depth, and it is not highly scalable.  The following were given as best practices:
  • Implement AuthN and AuthZ (Authentication and Authorization) by using native AWS services such as API Gateway, AWS Shield, AWS Lambda, and AWS CloudTrail as these services are highly scalable, auditable, and provide defense in depth.
• Anti-Pattern #2 – Network Egress Backhauling.  There have been instances when AWS customers have routed internet traffic from their VPC to and then out of the corporate datacenter in order to pass through traffic inspection proxies.   This type of setup requires direct connects on all VPCs, it forces a hybrid architecture, it is not highly scalable, and increases latency.  The following were given as best practices:
  • “Use the cloud to secure the cloud.”  In this scenario, a separate VPC is created which contain Restricted Proxy Instances and is peered with the “production” VPC.  I suggest reading more about Controlling VPC Egress here….

Auditing

• Anti-Pattern #1 – Security Questionnaires.  Using questionnaires to perform security audits, at best, will provide a somewhat accurate point-in-time snapshot, but they are not typically based on any standards and have no independent verification.  As a best practice:
  • Use attestations, such as SOC 2, PCI DSS, and HIPPA, instead of questionnaires that provide standardized controls and third-party verification compliance.  Formulate a security baseline using “commonalities” contained within the standard security attestations.  A poor picture from the slide deck may help to display the point:

• Anti-Pattern #2 – Manual auditing.  Internal audits can be time consuming and may not happen as often as they should, if at all.
  • The best practice, automate auditing using existing AWS services such as CloudWatch + Alarms, AWS Inspector, AWS Trusted Advisor and other tools such as Cloud Conformity, Cloud Custodian, and/or cfn-nag.
• Anti-Pattern #3 – Not using AWS native, managed services.  The best practice of course:
  • Use as many native AWS services as you can.  This ensure consistency and compliance and it reduces your operational burden of security “proof” as using AWS services pushes more security responsibility to AWS.

Software Delivery

• Anti-Pattern – “Over the wall software delivery”.  In many organizations, teams responsible for the development, testing, and deployment of software may not act as cohesively as an organization may desire.  When teams are fragmented, this can lead to infrequent patches and confusion.
  • The first best practice is to build an interdisciplinary team that consists of members from all departments involved in software development and deployment.
  • Best practice #2 – this team would be able to build a framework to ensure end-to-end auditing, testing, and proper change control.

Below are a few more screenshots that my be helpful in regards to application development with security in mind.

A typical deployment process

An ideal software development team

The ideal software development process