Highlights from AWS re:Inforce 2022

At the recent AWS security conference, several themes emerged from leadership talks, product launches, and workshop topics, all driven by customer experiences securing systems at scale in AWS. I strive to understand these emerging themes, along with security fundamentals, to apply them within the context of customer environments. My highlighted themes this year are:

• increased focus on securing team collaboration
• improved support for managing access at scale
• tighter integration of detection and response
• improved capability of centralized AWS-native firewalls

Securing Team Collaboration

Use of collaboration tools has sharply increased with more people working from home than ever, so naturally organizations are increasing their focus on the security of these tools and their communication channels. Amazon has long offered the functional but unpopular collaboration service Chime, but is investing in an alternative with a foundational focus on security.

AWS Wickr, now available in preview, provides end-to-end encrypted messaging, file transfer, screen sharing, voice and video conferencing along with administrative controls for governance and compliance.

Despite being in preview, Wickr has been used for years by security-focused teams prior to acquisition by AWS last year. Ideally, though, secure collaboration tools would see widespread adoption so even those not primarily concerned with security would benefit. If AWS Wickr manages to provide enough feature parity with competitors without compromising its secure foundations, it could be a significant contender in this market.

Managing Access At Scale

As environments have become increasingly complex, managing least-privilege access has been a persistent challenge. Segmenting workloads and environments into separate AWS accounts has been established as best practice for several years now, but the tools to provide least-privilege cross-account access have struggled to keep up.

Since its launch, AWS Single Sign-On (SSO) has been my preferred mechanism for user access, replacing IAM users altogether. AWS SSO has now rebranded as IAM Identity Center, which may be initially confusing for some, but will hopefully steer newer users in the right direction as administrators look to the IAM service for, you guessed it, Identity and Access Management. I hope this will further encourage teams to replace the long-lived access credentials of IAM users with the temporary credentials vended by IAM Identity Center. Additionally, Identity Center now supports permissions boundaries and customer-managed IAM policies, which will help tailor access to the specific accounts in which they apply. In particular, these features will help separate people from data, even the people who are administering the environment.

Support for Attribute-Based Access Control (ABAC) continues to grow, as AWS Lambda now supports authorization based on tags. ABAC intends to improve permissions management at scale by making permissions contingent on the tags applied to identities and resources. This can simplify permissions policies and reduce the need to update policies when new identities and resources are created. However, this approach is currently only supported by select services, limiting its potential for widespread adoption. AWS appears to be continuing to improve support for ABAC for common services, bringing this approach closer to being a viable option, but I still recommend caution in adopting ABAC. It should be considered an addition to role-based access, not a replacement, and you should carefully consider all the permutations of the involved tags to make sure access is not inadvertently provided.

Integrating Detection and Response

Detection and response are generally considered two separate functions, but really they are only valuable together, and AWS continues to strive towards integrating their services.

Amazon GuardDuty has long provided threat detection for EC2 workloads, but deeper investigation was left to users. With Malware Protection enabled, GuardDuty will automatically scan suspicious EC2 workloads to provide more actionable findings, down to the file level, and integrate them into AWS Security Hub. GuardDuty’s malware protection is not intended to replace more robust solutions for cloud workload or endpoint protection (CWP/EPP), as it doesn’t scan proactively, track system behaviors, or attempt to remediate threats. However, it provides coverage where no endpoint protection is installed and may find malware that is designed to evade agent-based detection.

For users of Elastic Kubernetes Service (EKS), AWS added support for both threat detection and automated investigation. Amazon GuardDuty support for EKS provides threat detection findings based on user and application activity, and Amazon Detective will help users investigate these security findings by building profiles on entities to provide the context required to effectively respond to a finding, identify the root cause, assess impact, and respond.

In addition to this automated investigation support, AWS is trying to enable customers to build their own investigation capabilities. The AWS Customer Incident Response Team (CIRT) opened their playbooks, open sourced a tool to enable logs, and open sourced a tool to simulate common security events to support response exercises. Unfortunately, AWS lacks native services for full-featured Security Information and Event Management (SIEM) and Security Orchestration Automation and Response (SOAR). AWS provides some options by combining existing services, like using Athena to query logs stored in S3 and building response runbooks using SageMaker to query CloudTrail Lake, but none intend to compete head-on with full-featured solutions offered by third-party vendors.

Centrally Managing AWS-native Firewalls

A variety of re:Inforce sessions highlighted the maturity of AWS Network Firewall and Route 53 DNS Firewall, as AWS strives to give enterprise customers AWS-native services for centralized network protection.

AWS Network Firewall

Route 53 DNS Firewall

AWS Network Firewall inspects traffic at the network and application layers, and now supports a centralized deployment model, AWS managed threat signatures, and VPC prefix lists.

Its primary limitation when compared to third-party options is deep packet inspection of SSL/TLS encrypted traffic, which is on the roadmap. Although AWS Network Firewall has broad coverage of HTTP, TCP/UDP, and IP traffic, it does not inspect DNS queries which may be used by bad actors to evade detection when sending data out of a network. This can be done by Route 53 DNS Firewall, however, which allows you to filter DNS queries using AWS managed and custom domain lists. Together, AWS is striving to provide comprehensive network protection without requiring customers to look to third-party vendors.

Conclusion

These incremental improvements further enable us to secure workloads in the cloud, and it’s our job to do so without blocking development and delivery of business value.

CJ Moses, Amazon Chief Security Officer, succinctly stated this approach as, “Make the secure path the path of least resistance.”

I accept this mantra and depart AWS re:Inforce 2022 with a renewed commitment to it.