This past week AWS hosted re:Inforce, their first security conference, in Boston. I’ll recap the content of the conference in a moment, but first I’ll comment on everything else.

The conference was well-run, as should be expected as AWS has run 7 re:Invent conferences (the main AWS conference), many Summits, and countless minor events. re:Invent has over 40,000 attendees, and this first re:Inforce I heard had over 12,000 attendees, taking up the entire Boston Convention Center. Tickets were $1,100. Discount codes were frequently available, but this is still priced around the mid-range for security conferences. The biggest cost for many though were the hotels which exceeded $300/night, even when registered months in advance.

Having Boston as a venue was a welcome change from Las Vegas (where re:Invent is held). It was announced AWS will have another re:Inforce next year, but in Houston, so I assume this conference will travel to new cities each year.

My best advice for those planning on attending next year: The keynote was live-streamed and the talks appear on youtube within days, so your time is best spent meeting people outside of the talks and attending the chalk talks and workshops that aren’t recorded, as you can just watch the talks later (and at a faster speed!).

The announcements

The timing of the announcements was odd, with many things announced the night before the conference, or in the days after, so the keynote was rather dull. I’ll include all these announcements here.

• Security Hub now GA: This service centralizes security related alerts (from GuardDuty, AWS Config, and more) across accounts, and provides a UI for viewing these. The biggest limitation of this service is it does not centralize alerts across regions, only across accounts, so until that is fixed I wouldn’t consider using it. This service had been available since re:Invent in November, but with GA we finally get pricing information for it (it had been free until now), and it is a good deal, with their example price for a small account at $1/mo. Once this service gets multi-region support (if it ever does), I still don’t think I’d use it, as there are better ways of centralizing alerts. I believe a business is either mature enough to have better capabilities, such as StreamAlert or Splunk, or they are young enough that they would be better off centralizing all alerts (security and operations) to SSM OpsCenter.
• Control Tower now GA: This service is the successor to Landing Zones. It helps you create new accounts and establish a security baseline for AWS accounts. This cannot be used if you already use AWS Organizations or if you previously used Landing Zone. Configuration is limited and it is only available in 4 regions. I heard someone explain that GA for AWS now means “Good. Almost.” Unless you are brand new to AWS, you can’t use this at all.
• Service quotas service: This is a much needed service, as AWS has a number of limits that you often don’t know about until you bump into them. Once you bump into them, you would then have to file support tickets to increase the limits and you have no APIs for knowing what your current limits are (did you bump a limit up to 10? 100? How close are you to running into it again?). It currently doesn’t appear to show utilization (ie. how close you are to the limits), but that should come soon as the UI elements exist to display that, and when it does you’ll be able to have CloudWatch Alarms for when you get close to the limits.
• VPC traffic mirroring: This new capability allows you to mirror the traffic of an ENI and send it to another ENI. Whereas VPC Flow Logs give you only IP address and ports, this gives you full packet capture, including filtering abilities and the ability to specify how much of the packets you want to mirror. It uses VXLAN encapsulation, which means traffic arrives to the mirror on UDP port 4879. You can also send traffic to a Network Load Balancer, so seemingly to support this feature, it was also announced that NLBs can now do UDP load balancing. The limitations of this are that it does count against the bandwidth limits for an instance, and this can only be applied on a per ENI basis, meaning you can’t mirror all the traffic for a VPC, and you can’t mirror traffic for resources that don’t use ENIs, such as public Lambdas. This capability has taken so long to come out that most people have figured out how to work around these issues using processes running on the hosts or using routing tables to NAT instances to monitor and block traffic. Additionally, with a lot of network traffic being encrypted, many have stopped being interested in full packet capture. There are cases where this capability is needed, but this seems to have been a feature that was largely added to please legacy vendors.
• EC2 connect: This provides a way to get SSH keys for EC2s, which allows for key management, short-lived keys, and an additional audit trail. A somewhat similar service is SSM Session Manager, but that can’t be used for all of the situations that people use SSH for. If you have to SSH to servers and can’t use SSM Session Manager, you should use this. This accomplishes something similar to what Netflix BLESS does.
• Security Incident Response Whitepaper: Personally, I’m not finding AWS’s whitepapers to provide specific enough guidance to be actionable, but your milage may vary.
• VPC traffic encryption: More recent EC2 families are now encrypting their traffic within VPCs, even when in the same data centers. It was only in May that AWS started encrypting traffic between data centers, so it is good to see AWS not only finally catching up with best practices last month, but now going beyond them.

Best talks

Of the talks I’ve watched so far, these are my favorite:

• Encrypting Everything with AWS (SEP402) by Colm MacCárthaigh: This provides some background on what is happening with encryption on AWS. Keep in mind that there are only 6 AWS services that encrypt data at-rest by default (DynamoDB, Glacier, Snowball, Storage Gateway, Workdocs, and Workmail) so encryption usage still has a long way to go on AWS.
• Scale Permissions Management in AWS w/ Attribute-Based Access Control (SDD350) by Brigid Johnson: This talk is largely about using tags on resources and principals as a way to control access in IAM policies. Keep in mind that this strategy has limitations currently because not all resources support tags, and of those that do, not all support tagging on creation, which is a requirement for this strategy. This is likely going to be an important strategy in the future, but the tooling for understanding and creating these types of policies does not exist yet, and they are hard to reason about manually, as evidenced by the recent SageMaker managed IAM policy incident (link).

The need for an independent conference

I think AWS is a great platform, but re:Inforce is controlled by AWS to ensure AWS is presented in the best possible light. Limitations and caveats are glossed over. Complex things are incorrectly described as easy and simple, so no mentions are made of gotchas and what to watch out for. Deviations from a single happy path use case at times are unsupported, but this is not disclosed.

Despite being a security conference, no security researchers were allowed to present. There was no discussion of what the security problems are that would warrant having a security conference in the first place. I view myself as more aligned with defenders than attackers, but you have to discuss what the threats are you’re defending against. You have to explain why something is a best practice. You have to discuss the limitations of things.

For these reasons, myself and others are planning a conference alongside next year’s re:Inforce that will be focused on AWS security. We are in very early planning and don’t even have a name yet for this new conference, but keep an eye out, and please reach out if you’d be interested in sponsoring!