Home » Cloud Infrastructure » AWS Re:Inforce After Action Report

AWS Re:Inforce After Action Report

Two weeks ago I took a whirlwind trip to Boston to attend AWS Re:Inforce – the inaugural security focused AWS conference. Being the first of its kind, the AWS event planning team definitely has some kinks to iron out. Overall this two-day conference is just about right in duration, I got enough time to soak in new information from breakout sessions and to chat with vendors about solutions. 

Between the sessions I was able to attend, I tried to cover areas as wide as I could with a focus on new features and solutions. Here are few memorable takeaways:

AWS Re:Inforce June 25-26, 2019 | Boston, MA


  • During his keynote, AWS CISO Stephen Schmidt said DevSecOps should just be Ops where Dev and Sec are implied. I can’t agree more, especially the Sec part. If you have to explicitly call out security in either dev or ops (or both), you’ve missed the point. Security is/has-been/should always be a part of a development lifecycle. It’s not ad-hoc, it’s never “out-of-scope” (looking at you, product managers) and shouldn’t really needed to be explicitly called out as a function. 

Resource Tagging

  • I’ve long advocated for tagging discipline. Tags were first important for identification and automation, then they became more useful for billing and budgeting, and now they are even more important because security and compliance rules depend on tags to differentiate what rules to apply.

EBS Encryption

  • EBS encryption is now on by default and, no, it does not have performance overhead. In other words, you can still get the guaranteed IOPS you paid for with free encryption. Snapshots get encrypted, too. Using a data key, EBS encrypts a volume with AES-256, then encrypts the data key with your (account-default) customer master key (CMK), then it finally stores the encrypted data key on disk next to the volume.

Configuration Compliance and Security Remediation

  • AWS Config rule enforces configuration compliance by kicking off Lambdas to update resources that are out of compliance – I really like the idea of using Lambda as a way to apply security remediations. For example, automatically lock down a bucket ACL and notify admins when a public S3 bucket is provisioned. This is a brilliant way to do infrastructure compliance at scale. In the land of acquiring 9s, not only disaster recovery but also security remediation and forensics has to be automated. 
  • Automation itself was a highlight at Re:Inforce. Some of AWS’ own security related tools are shared on Github: awslabs/aws-security-automation.

Security Defense for Serverless/Containers

  • Lambda Layer is leveraged heavily by app layer security vendors to inject security defense code into Lambda functions. Security libraries injected as the first Layer  first establish a traffic/request baseline. Security Layer will then have the capability to drop a request or stop a Lambda function from responding when an abnormal traffic/request pattern arises. 
  • Similarly, one can add app-layer security to container daemon (i.e. dockerd) or as a sidecar to observe traffic patterns and stop traffic or even the container if necessary


  • IAM  is still a double-edged sword, as managed Roles/Policies can be, too. They’re extremely flexible, but the effort to create a balanced role/policy remains significant. A product gap perhaps?
  • Someone from AWS suggested implementing federated login from the get-go instead of building out IAM users. I see this being useful on a larger/enterprise implementation but not so much beneficial for start-ups / small deployments.

Protecting API End-Points

  • In addition to the Lambda Cognito authorizer my colleague Jeff posted the other day (AWS SAM API with Cognito), API Gateway Lambda authorizer is another great way of protection API end-points.

Asherah Project

  • GoDaddy just open-sourced their Asherah project – its goal is to provide a simplified interface to developers in order to manage encryption. Asherah’s components include a kay management service (supporting a multi-tier key hierarchy), a metastore to store lower tier keys, crypto policy (for key lifecycle rules), security memory (a secure unmanaged off-heap memory space against memory dumps), protected memory cache, and a user-managed data store. I’m particularly interested in watching how Asherah rotates keys at various tier as the projects matures/scales out.

TLS, Formerly Known as SSL

  • AWS Lab’s s2n is AWS’ own spin on TLS and it’s been implemented all over AWS internal traffic. Every TLS within AWS has forward secrecy through Diffie-Hellman. As far as AWS’ encryption stack goes, it’s a combination of physical network encryption, inter-region peering, VPC encryption and TLS to maximize anonymity and forward-secrecy.

Application Threat Modeling

  • In addition to aligning with AWS Well-Architected Framework, application threat modeling is something we haven’t done enough during our development lifecycle. As a new feature gets added to the code base, a potential risk or vulnerability could also be introduced. There should a light-weight risk analysis at the end of each dev cycle to review whether existing security posture has shifted.

System Manager Rather than SSH

  • There’s almost no point to uploading your public key to AWS anymore. SSH’ing into an EC2 is yesterday. Run System Manager (cue IAM permissions here) for shell level access instead. 

VPC Traffic Mirroring

  • Last but not the least, VPC Traffic Mirroring by using optical fiber tabs. With designated group of auto-scaled EC2s as consumers of the mirrored traffic, this feature opens up lots of potential for admins and security vendors who hit a dead end in AWS without deep packet inspection. Hope my old friends at Sourcefire/Cisco can put this feature to good use.



Scroll to Top