Tributary Logo

03 December 2023

AWS ReInvent and PreInvent security recap

A recap of the releases from around Re:Invent!

Dakota Riley
Dakota Riley Principal Security Engineer LinkedIn

Keeping up with the sheer number of releases that come out of both Re:Invent and Pre:Invent is almost an impossible task, as well as trying to find the ones relevant to you. I compiled all security-relevant AWS announcements and tried to highlight the ones I found the most interesting. Happy reading!

Categories

Generative AI

Natural Language Querying for Everyone!

Several existing security-relevant AWS services received support for querying via Natural Language Processing. I think this is an awesome use case for security, as it makes querying of logs accessible for more individuals. I see this being compelling for personas like Security Operations Center (SOC) analysts or even governance, risk, and compliance (GRC) professionals who know what they are looking for but may not want to fight with SQL or Cloudwatch Logs queries.

Release of Amazon Q

While not entirely security related, Amazon released Amazon Q, a generative AI-powered assistant that is trained specifically on your company’s data. I have yet to take it for a spin. The interesting part from a security perspective is that the service claims to “understand and respect your existing governance identities, roles, and permissions and use this information to personalize its interactions.” My mind jumps to what we have seen with OpenAI Custom GPTs, and individuals being able to convince them to dump their knowledge file or do other unintended things. A pretty impressive feat if Amazon has managed to tackle this problem safely.

AI Guardrails!

Amazon Bedrock, a service for building generative AI applications, hit general availability back in September. Now we get a service to protect these workloads in Guardrails for Amazon Bedrock. It supports denied topics and content filters out of the box, with PII redaction planned in the future.

Links:

Logging and Threat Detection

GuardDuty Runtime Expands to ECS, ECS Fargate, and EC2

Earlier this year, AWS released GuardDuty Runtime support for Elastic Kubernetes Service (EKS) workloads. GuardDuty runtime provides 30+ detections for potentially malicious activity in your containers — think stuff like popping a reverse shell, cryptomining, or process injection as examples. AWS expanding this to EC2, ECS, and ECS Fargate workloads is a welcome addition and gives AWS an EDR-like play for EC2 workloads. The new runtime capability requires an agent that is either deployed to the EC2 Instance, ECS Cluster, or as a sidecar container for Fargate workloads.

Amazon Inspector Now Supports Agentless Scanning

AWS has finally followed in the steps of some of the larger cloud-native application protection platform (CNAPP) players by adding an agentless vulnerability scanning capability to AWS Inspector. This capability relies on snapshotting the EBS Volume of the EC2 Instance in question. In a perfect world, everyone would use the golden AMI (or not use EC2 at all) with their vulnerability management agent of choice baked in, but that doesn’t always match reality. Having the ability to ensure we have coverage regardless of having the inspector agent installed is a nice touch.

General Logging Improvements Across Services

Several smaller improvements made it across the finish line for logging capability. S3 Server Access logs now support automatic date-based partitioning, which will make the lives of those attempting to do useful things with them in services like Athena easier.

Prior to this Re:Invent, read-only events (e.g. secretsmanger:ListSecrets) could not be accessed from Cloudtail to Eventbridge. This is no longer the case, and opens more use cases for time-sensitive security detections. I also appreciate AWS eliminating edge cases and one-offs across their services to make it easier to build on without discovering things like CloudTrail not exposing read-only events to EventBridge.

Finally, SQS gets support for data plane logging, joining S3 and Lambda. Any managed service that processes data should offer this option, and doing so allows customers to better secure their side of the shared responsibility model. SQS data event logging is managed via CloudTrail.

Links:

Identity and Access

IAM Policy and Preventative Controls Enhancements

There were a few notable IAM policy releases. The two most relevant being new condition key support for enforcing particular security and access policies upon creation of new Elastic Load Balancers, as well as support for enforcing that only AWS services (such as AWS Cloudtrail) from your organization can take actions on your behalf via the aws:SourceOrgID condition keys. Pre-Invent also brought us the ability to outright block public AMIs, much like the existing control for S3.

Data Service Access control Improvements

Several of the AWS data services saw improvements to access controls within the services themselves, separate from AWS IAM.

S3 Access Grants aim to provide an option for granular access control to large-scale S3 datasets, whereas Bucket Policies or S3 Access Points wouldn’t provide a scalable approach.

Redshift saw several access control improvements, including metadata security, row-level security, and fine-grained access control to nested objects. LakeFormation also added a capability for granular access control on nested objects. I am very much sensing a theme with all of these large data access releases!

EKS Pod Identity

EKS currently has IAM Roles for Service Accounts (IRSA), which provides a capability to associate IAM roles with Kubernetes workloads. This relied on a properly configured trust policy (using sts:AssumeRoleForWebIdentity) and applying annotations to the Kubernetes Service Account to associate it with the Role. EKS Pod Identity aims to simplify this process by allowing you to manage the identities and associations via the AWS Control plane, as well as eliminating the need for an OpenID Connect (OIDC) provider and trust.

IAM Access Analyzer and Action Last Accessed Info Continue to Expand Service Support

Both IAM Access Analyzer’s policy generation feature and Service/Action last accessed info are not new features. They have often been held back by a lack of service/action support. The policy generation capability from CloudTrail added support for 200 additional services. I see this as a nice feature for dev teams who may not be as comfortable with the IAM Policy language.

I think the compelling feature for security teams here is the continued expansion of more action-level “last accessed” information. Previously, the Last Accessed panel provided only if an Identity has used a particular service, as opposed to a particular API within that service (think knowing that a role uses the DynamoDB Service vs. knowing that a role only uses the dynamodb:UpdateTable API. Initial action-level support was very small, which is why I am excited to see this expanded to more services.

Custom policy checks are also interesting. Access Analyzer provides a new CheckAccessNotGranted API that allows you to utilize Access Analyzer to evaluate a policy for permitted actions. I would love to see support added to the API for resource and condition key evaluation in the future.

Links:

Network Security

ALB mTLS Support

AWS Application Load Balancers (ALBs) now support authentication via Mutual TLS (mTLS). You can either configure the ALB to pass through the certificate chain to the backend and validate in your application, or have the ALB itself handle validation. It also supports certificate revocation checks. I think this is especially interesting for anyone working on any zero trust initiative in their organization.

Network Firewall Egress TLS Inspection Support Region Rollout

For those of us who are required to implement strict network security controls like TLS inspection, having an AWS-managed option is always nice. Egress TLS inspection was released for AWS Network Firewall in the Tel Aviv and Europe regions. Hopefully, we will see a quick rollout to other AWS regions.

Links:

Governance, Risk, and Compliance

Audit Manager Generative AI Framework

This appears to be an out of box framework to evaluate the security posture of Amazon Bedrock usage. It is a custom framework that claims to have 34 fully automated controls and 18 partially automated controls pertaining to the usage of Amazon Bedrock. I haven’t been able to actually take this for a spin, but happy to see compliance automation for even bleeding-edge services like this.

New Checks and Resource Types Across Config, SecurityHub, Resource Explorer, and Trusted Advisor

There were also several smaller announcements pertaining to additional resource support for Config, Config Advanced Query, and Resource Explorer. If you use any of these services, they are definitely worth a glance to see what was missing. AWS Trusted Advisor added a large amount of new checks, which you can now retrieve via their new API.

Links:

Otherwise Interesting

Cool Features for Security Builders: Batch Secrets Retrieval, Step Functions HTTPS Endpoints and Testing Improvements, and More!

If you find yourself building security automation on AWS, you might have utilized AWS Step Functions in the past. My co-worker Dustin Whited wrote an awesome blog about this! Step Functions now supports HTTPS endpoint integrations, meaning you can integrate with any third-party service that exposes a webhook without using a Lambda step! They also announced the TestState API, which allows you to test individual states. My biggest hesitation with utilizing this for complex logic/workflows was difficulty in testing. I’m very happy to see improvements to this.

If you have Lambdas utilizing more than one secret in Secrets Manager, you can now retrieve those with a single API call using the BatchGetSecretValue API. Seems nice for limiting additional latency. Those who monitor usage of sensitive APIs in their organization may want to add this one to their list, however.

For those in the DevSecOps world, Amazon Inspector now natively supports integrating with CI/CD pipelines to preform vulnerability scans. You can either utilize a premade plugin (Jenkins and TeamCity to start), or integrate any other CI provider by utilizing the Amazon Inspector SBOMGen tool to generate an SBOM to be fed to the new Amazon Inspector Scan API. This poses a good opportunity for teams already using Inspector to eliminate duplicative tooling just for CI scans.

Finally, AWS Control Tower released APIs for creating and managing landing zones. I have mixed feelings about this, as I perceived the strength of Control Tower to be for an easy-to-use, click-ops-based approach to standing up a Landing Zone. I personally prefer to manage my organizations using tools like Terraform or OrgFormation using an Infrastructure-as-Code first approach, but I understand that approach is not for everyone. I took a look at the CreateLandingZone API, and that API requires a manifest specifying the configurations of the landing zone.

Links:

Conclusion

I am very thankful to have the opportunity to attend Re:Invent in person. Even being there, in the process of putting together these recaps, I always find something interesting I somehow missed out on. Hoping this recap does the same for you! And if you’re looking for help navigating security or compliance in the cloud, give us a shout! Happy building!

If you have any questions, or would like to discuss this topic in more detail, feel free to contact us and we would be happy to schedule some time to chat about how Aquia can help you and your organization.

Categories

AWS Security