My Top Re:Inforce 2025 sessions

May 8, 2025 by Meg Ashby

My top sessions from the Re:Inforce 2025 Catalog

AWS conferences are known for their incredibly jam-packed days, and with the multitude of sessions going on at once, there is no way you could see even 5% of the sessions! AWS has published several guides based on job function, but if you’re working for a startup / SMB like myself, you’ll find you identify with multiple of these guides. Below, I’m sharing the sessions I’m most interested in attending at Re:Inforce 2025 as a Cloud Security Engineer for a startup.

Some criteria I use when deciding which sessions to prioritize include content, session level, and session type. In regards to session content, I tend to lean away from sessions that read extremely AI heavy. At this point I’m more interested in using AI to aid in exploratory situations or automate tedious investigations, but not leaning much further into AI usage, so any sessions around advanced AI use-cases are not of interest to me. I touch a bit of every domain in my job function, so my recommendations include sessions from a variety of session tracks.

In terms of session level, I swear by the rule of only attending 300 or 400 level sessions, with a strong bias towards 400 level sessions. From past experience at Re:Invent & Re:Inforce my general rule of thumb is if the session is about AWS services or use cases I have worked directly with in production, I try to stick to 400 level session if at all possible, If it’s a service or use case I’ve used lightly or only heard of in AWS certification exams etc, I am open to 300 level sessions. I find the 200-level sessions aren’t appropriate for active builders in AWS, and generally the same depth of content is covered in AWS-published blog posts.

Lastly, in terms of session type, I typically stay away from Breakout sessions simply because they are often posted to Youtube after the conference is over. Additionally, I also stay away from prioritizing Lightning talks as they are often too short to get to the level of detail I want out of sessions. However, if there is a lighting talk conveniently located to another session of interest or I have some time to kill, I often will attend these lighting talks at the conferences, I just don’t prioritize them in pre-conference planning. Lastly, I tend to deprioritize workshops because I simply get too tired at conferences to enjoy sitting in a chair for 2 hours. Don’t get me wrong, I think these workshops have fantastic content, I cannot last for 2 hours on conference venue coffee. With all that said, here are 5 sessions I’m most interested in, along with a few additional bonus sessions I recommend from past conferences:

TDR451: Automate incident response for Amazon EC2 and Amazon EKS

Gone are the days where we're hosting applications directly on EC2s, and the legacy runbacks of isolating EC2 instances and preserving memory don’t hold up in EKS-land. I’m hoping this session can give some pre-built solutions for incident response on isolating and examining specific EKS workloads / pods as it’s been high on my wish list, but difficult to prioritize and scope due to the intricacies of Kubernetes workloads and architecture.

IAM333: From static to dynamic: Modernizing AWS access management

As I’ve grown in my cloud security career I’ve realized there are 3 certainties in life: death, taxes, and product engineers requesting bespoke temporary cloud permissions to “debug X”. We’ve explored other AWS-native solutions before to solve these problems (AWS TEAM, Temporary Elevated Access Broker) but couldn’t get to place that balanced security to our standards and flexibility in defining policies the product engineers need. I’m hoping this session goes beyond what is presented in the TEAM code samples, from the description I’d say it's 50/50 one way or the other.

NIS431: Cloud network defense: Advanced visibility and analysis on AWS

In late 2023 and into 2024 we overhauled our cloud networking strategy, and this included adding AWS Network Firewall for egress traffic. We’re at the point now where we have logging for monitoring for Network Firewall unexpectedly dropping traffic, but haven’t invested as much for exploratory analysis. In the last year or so, we’ve also been modernizing our AWS multi-account structure, but these projects haven’t yet converged. I’d be eager to attend if this session includes managing network defense in a multi-account set-up.

SEC352: Agentic AI for security: Building intelligent egress traffic controls

This session suggestion may be an indication I’ve spent long enough looking at the session catalog and have accidentally inhaled some of the AI fumes. However, following on from the session recommendation above, I’ve been considering how we can augment our Network Firewall infrastructure for a while. However, as a small team, we haven’t been able to prioritize or explore dynamic rule generation due to internal constraints. So I’m interested to see if any tactics presented in this session spark ideas on how we can incorporate AI to improve our own set-up.

DAP331: Architecting a secrets management strategy that scales

Honestly, I’ve never given much thought to what else can be done with secrets in AWS past using Secrets Manager and integrating Secrets Manager resources into EKS clusters using External Secrets Operator. However, the description of this session caught my attention, maybe I’m missing out on some opportunities to improve our secrets posture. That’s one aspect I love about attending conference sessions - being introduced to completely new ideas, tools, and patterns.

IAM431: A deep dive on IAM policy evaluation

In 2024 (previously titled “The life of an IAM policy"), the waitlist queue for this session was LONG and many were turned away at the door!. This session gave a unique peek-behind-the-curtain for how requests to AWS services are authenticated and authorized and how AWS thinks about security and blast radius in their internal operations. Will this session be the one you describe to your boss to convince them this conference was worth attending? No. However, this was one of the most interesting AWS talks I’ve ever attended, so for the lore I highly recommend it. Shout out to Scott Piper on the Cloud Security Forum slack group for originally recommending this!

IAM351: Data perimeter challenge

In 2024 this session was previously named “Data Perimeter in Action”, however I support the rename because some of the scenarios posed were certainly challenges. What I loved about this session is that it incorporates hands-on learning in a smaller-scale session, giving the perfect mix of engagement and low-time commitment you need when your energy is running low at the end of long conference days. I really appreciated how the examples build on each other and get into the weeds of complex scenarios involving multiple data perimeter controls. Bonus points if this session will be lead by Tatyana Yatskevich - last year their delivery of the content was incredible!

Customizing Config Remediation Notifications with Amazon Q Developer

March 29, 2025 by Meg Ashby

Optimizing Slack-based triage for AWS Config Remediation

To continuously enforce AWS security standards, security engineers often implement AWS Config auto-remediations via Systems Manager Automation (SSM) documents for managing several categories of cloud misconfigurations. Although this solution is widely known and used (see: AWS Config remediation docs), our security team found it difficult to monitor the auto-remediations done by Config, specifically due to the logging provided from CloudTrail when remediations occurred.

{
  "detail": {
    "eventName": ["StartAutomationExecution"],
    "eventSource": ["ssm.amazonaws.com"],
    "userIdentity.invokedBy": ["config.amazonaws.com"]
  },
  "source": ["aws.ssm"]
}
              

And the results from this query were sent to an SNS topic and later to Amazon Q Developer (FKA AWS Chatbot) to forward to our on-call security team via Slack using the below architecture:

However, the alerts sent to Slack left much to be desired, as can be seen in an example Slack message we received:

We found these Slack alerts lacking due to two issues:

1. The results of the CloudWatch query to watch for AWS Config remediations included information about the SSM document Config invoked, however the parameters passed to the SSM document were obscured and replaced with text HIDDEN_DUE_TO_SECURITY_REASONS

   For example, below is a sample event of Config invoking the AWS-DisableIncomingSSHOnPort22 SSM Document as part of an auto-remediation.

   
   {
     "eventVersion": "1.08",
     "userIdentity": {
         "type": "AssumedRole",
         "principalId": "<<redacted>>:AwsConfigRemediation",
         "arn": "arn:aws:sts::<<redacted>>:assumed-role/AWSServiceRoleForConfigRemediation/AwsConfigRemediation",
         "accountId": "<<redacted>>",
         "accessKeyId": "ASIA......",
         "sessionContext": {
             "sessionIssuer": {
                 "type": "Role",
                 "principalId": "<<redacted>>",
                 "arn": "arn:aws:iam::<<redacted>>:role/aws-service-role/remediation.config.amazonaws.com/AWSServiceRoleForConfigRemediation",
                 "accountId": "<<redacted>>",
                 "userName": "AWSServiceRoleForConfigRemediation"
             },
             "webIdFederationData": {},
             "attributes": {
                 "creationDate": "2025-01-14T21:26:26Z",
                 "mfaAuthenticated": "false"
             }
         },
         "invokedBy": "config.amazonaws.com"
     },
     "eventTime": "2025-01-14T21:26:26Z",
     "eventSource": "ssm.amazonaws.com",
     "eventName": "StartAutomationExecution",
     "awsRegion": "us-east-1",
     "sourceIPAddress": "config.amazonaws.com",
     "userAgent": "config.amazonaws.com",
     "requestParameters": {
         "documentName": "AWS-DisableIncomingSSHOnPort22",
         "documentVersion": "1",
         "parameters": {
             "AutomationAssumeRole": [
                 "HIDDEN_DUE_TO_SECURITY_REASONS"
             ],
             "SecurityGroupIds": [
                 "HIDDEN_DUE_TO_SECURITY_REASONS"
             ]
         }
     },
     "responseElements": {
         "automationExecutionId": "eda2ec0c-c778-4d2b-a59d-aad5b52d5e9a"
     },
     "requestID": "eda2ec0c-c778-4d2b-a59d-aad5b52d5e9a",
     "eventID": "6e2f6630-f439-439d-93ee-841aba72182c",
     "readOnly": false,
     "eventType": "AwsApiCall",
     "managementEvent": true,
     "recipientAccountId": "<<redacted>>",
     "eventCategory": "Management"
   }
                           

   Since we use Config auto-remediations on various types of cloud resources and to perform various actions, there was no way to determine the necessary information of what resources were updated, what the actions were, or even what account the changes occurred in. Due to this, the severity of the alert couldn’t be determined, so each Config remediation notification had to be treated as high-priority.

2. Secondly, Amazon Q Developer did not support manipulation of AWS Events, so although some desired fields were available in the original CloudWatch events (such as recipientAccountId) we were unable to modify the message sent to Slack to include these fields.

Due to these limitations, our on-call engineers were doing many manual CloudWatch Insights queries to map the original Config remediation event based on the actions taken by the SSM document to determine the impact of the changes made by Config. As our on-call team grew with various levels of familiarity with AWS and our AWS footprint expanded, it became difficult to manage and disseminate these CloudWatch Insights queries across different AWS regions and accounts. Additionally, this led to responder fatigue as on-call engineers had to leave Slack and navigate AWS in order to complete their analysis.

To solve this problem, we introduced an AWS Lambda function to act as an interceptor between the SNS topic, which received events from CloudWatch, and the Amazon Q Developer integration. Additionally, we utilized the new Amazon Q Developer custom notifications feature to construct bespoke Slack notifications which contain all the relevant information for triage:

The Lambda utilizes SSM Parameter Store to hold a mapping between the SSM document Config invoked and the CloudWatch Insights queries on-call engineers previously ran manually. With this new information and the ability to customize fields through Amazon Q Developer, we send our on-call engineers messages with all the information they need to quickly triage the event without ever leaving Slack.

In detail, when a Config remediation occurs, the original unaltered event is sent to Slack through Amazon Q Developer. At the same time, the lambda invokes a CloudWatch Logs query to determine the full details of the event. However, CloudWatch Logs data may be several minutes delayed from the original CloudTrail event. Because of this, when the CloudWatch Logs query completes, a follow-up message is sent to Amazon Q Developer in the thread of the original Slack message.

In Slack, these enriched messages look like:

With this improvement, the time it takes to triage Config remediation events went from several minutes, down to seconds. Additionally, by incorporating all the necessary information for triage into Slack, on-call engineers can determine if an investigation needs to be launched directly from their mobile devices, especially important for off-hours alerts!

I have provided sample Terraform & Python GitHub Repo for you to use as reference or incorporate into your work streams!