Conversational Security engineering across your aws cloud infrastructure

Conversational Security Engineering Across Your AWS Cloud Infrastructure

Speakers: Saransh Rana, Staff Security Engineer, Grid

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=zQbtGmkpsKk

Overview

In this insightful talk from Cloud Village, Saransh Rana, a Staff Security Engineer at Grid, introduces the AWS Security MCP Server, a novel approach to conversational security engineering designed to streamline and enhance security operations within complex AWS environments. The core premise of the talk revolves around transforming traditional, command-line-intensive security tasks into intuitive, natural language conversations with an intelligent application. This innovation addresses the growing challenges faced by security teams, particularly in large-scale cloud infrastructures, where manual investigation, fragmented tooling, and a lack of unified visibility often lead to delayed incident response and incomplete security postures.

Rana demonstrates how the MCP Server empowers security professionals to perform sophisticated cross-account security operations, threat hunting, and report generation using Large Language Models (LLMs). By abstracting away the complexities of AWS CLI commands, API calls, and disparate log sources, the server allows engineers to ask direct questions like "Show me attack paths from this public EC2 instance" or "Generate a threat modeling report for a payment microservice." This shift from "command lines to conversations" is presented not just as a convenience but as an essential evolution for accelerating security investigations, prioritizing findings, and gaining comprehensive visibility across an organization's entire AWS footprint.

The significance of this work is particularly pronounced for organizations operating at scale, such as Grid, a payment platform processing over $80 billion annually, making it a prime target for adversaries. Rana highlights how the MCP Server was born out of real-world problems encountered by his team, emphasizing the existential need for efficient and effective security management. The tool's ability to correlate multiple log sources, perform LLM-powered threat hunting, and generate actionable reports, all while maintaining a read-only security posture, positions it as a powerful asset for modern cloud security operations teams striving for faster detection, response, and overall improved security resilience.

Background

▶ Watch: Introduction and welcome to the workshop (0:00)

The genesis of the AWS Security MCP Server stems directly from the acute challenges Saransh Rana and his team at Grid faced in managing security for a high-value, large-scale AWS infrastructure. Grid, as a trusted payment platform in India with over 13 million active users and processing billions in transactions, is a critical target for attackers. This scale makes security paramount, yet traditional methods often fall short, leading to significant operational overhead and visibility gaps.

Rana articulated several recurring problem statements from his CISO and managers that underscore the need for a more efficient solution:

• Inventory Discovery: Identifying all resources owned by a specific team across a sprawling AWS infrastructure (e.g., "Can you share all resources owned by our QA team?"). This typically involves running 20+ CLI commands, navigating multiple AWS accounts and browsers, writing complex Python or Bash scripts, and often yielding incomplete or inaccurate results (sometimes as low as 70% accuracy).
• Attack Surface Mapping: Understanding the attack surface of a critical microservice, such as a payment service. This often requires connecting with service owners who may lack historical context ("I joined six months back and don't know the architecture"), or with SRE/DevOps engineers who defer to service owners, leading to a frustrating cycle of information gathering.
• Incident Response & Threat Hunting: Responding to sophisticated alerts, such as a DNS over HTTPS activity from a suspicious IP address. Such investigations can involve 50+ CLI commands, 25+ browser tabs, and over two hours of hunting to pinpoint the source. Furthermore, correlating data across various log sources (Athena, Elastic) and crafting precise queries using LLMs is often hindered by a lack of understanding of table schemas, data partitioning, and column structures.
• Blast Radius Analysis: Determining the potential impact if a critical microservice, like a card tokenization service, is compromised. This necessitates deep dives into IAM permissions and mapping out complex interdependencies, often relying on assumptions rather than concrete data.

The overarching theme was a reliance on manual, time-consuming processes involving extensive use of the CLI (Command Line Interface), fragmented log analysis, and a significant amount of "fiddling" between different tools and information sources. Rana emphasized that while learning the CLI is crucial for foundational understanding, experienced security professionals (7+ years) require quicker results and consolidated insights, especially when responding to CISO requests or critical incidents. This "conversations, not command lines" philosophy became the driving force behind the development of the AWS Security MCP Server, aiming to replace arduous manual tasks with direct, intelligent queries.

Key Findings

▶ Watch: Talk agenda: Why conversational security engineering? (3:20)

The AWS Security MCP Server represents a significant contribution to modern cloud security operations by offering a unified, conversational interface for managing AWS security. Its key findings and contributions can be summarized as follows:

1. Unified Cross-Account Security Operations: The server acts as a central hub, enabling security engineers to perform operations across an entire AWS organization, regardless of the number of accounts. It consolidates visibility, eliminating the need to log into multiple consoles or run commands against individual accounts. This is crucial for large enterprises with hundreds or thousands of AWS accounts.
2. LLM-Powered Threat Hunting and Investigation: By integrating with Large Language Models (LLMs), the MCP Server allows users to pose security queries in natural language. The LLM interprets these queries, selects the appropriate security tools, crafts necessary parameters, and executes the operations. This drastically reduces the time and expertise required to formulate complex queries for diverse log sources like CloudTrail and VPC Flow Logs.
3. Smart Filtering System: A critical component of the MCP Server is its intelligent filtering mechanism. This system helps maintain the token size and content length for LLM clients, ensuring efficient processing. More importantly, it specifically targets and extracts security-related metadata, filtering out irrelevant information from verbose AWS API responses. This allows security engineers to quickly identify pertinent details, such as IAM roles assumable by external accounts or specific security group configurations.
4. Read-Only Security Audit Posture: The entire MCP Server operates strictly on a security audit IM policy. This means it is designed for read-only access, preventing any create, update, or delete operations within the AWS environment. This fundamental design choice ensures that the tool itself does not introduce new attack vectors or misconfigurations, making it safe for broad deployment and use by security teams primarily focused on monitoring, analysis, and investigation.
5. Correlation of Multiple Log Sources: The server can ingest and correlate data from various AWS security services and log sources into a single, cohesive view. This eliminates the manual effort of stitching together information from GuardDuty, Security Hub, IAM Access Analyzer, CloudTrail, and VPC Flow Logs, enabling a more holistic understanding of security events and potential attack paths.
6. Extensibility to AI Agents: The architecture is designed to be extensible, allowing for the creation of specialized AI agents. These agents can be tailored to perform specific, repetitive security tasks, such as daily vulnerability scans for subdomain takeovers or continuous monitoring for critical misconfigurations, further automating and scaling security operations.
7. Rapid Report Generation: Beyond raw data, the MCP Server can generate detailed, actionable reports, including executive summaries, potential attack vectors, and prioritized action items. This capability significantly accelerates the reporting process for CISOs and management, transforming raw security findings into strategic intelligence in minutes rather than days.

In essence, the AWS Security MCP Server transforms reactive, manual, and fragmented security operations into a proactive, intelligent, and unified conversational experience, dramatically improving the efficiency and effectiveness of cloud security teams.

Technical Deep Dive

▶ Watch: Problem: Discovering team-owned AWS resources (4:00)

The AWS Security MCP Server is engineered with a multi-layered architecture designed for robust, cross-account, and LLM-driven AWS security operations. The core components and their interactions are critical to understanding its capabilities.

Architecture Overview

The MCP Server's architecture is broken down into three primary layers, orchestrated by an MCP client (e.g., Cloud Desktop, Cursor Pro, or other LLM-integrated IDEs):

1. MCP Client Interaction: The process begins when a user inputs a natural language query into an MCP client. The client's inherent LLM capabilities are responsible for interpreting the query, reasoning about the required action, and selecting the appropriate "tool" to invoke on the MCP Server. For instance, a query like "What are the running EC2 instances in my AWS account?" is translated into an operation targeting EC2 security operations with a specific list instances tool and relevant parameters (e.g., running instances). Crucially, the client also adds a session context to specify the target AWS account (e.g., production, dev, stage).

1. Service Layer: This is the initial layer within the MCP Server that receives the request from the client. Its primary responsibilities include:

• AWS Service Identification: Determining which AWS service the request targets (e.g., EC2, S3, IAM, GuardDuty). The server supports over 20+ AWS services, including major ones like EC2, S3, IAM, GuardDuty, and Security Hub.
• Operation Mapping: Identifying the specific operation to perform within that service (e.g., list instances for EC2).
• Parameter Extraction: Extracting necessary parameters for the operation.
• Account Context: Utilizing the session context to determine the target AWS account for the operation.

1. Registry Layer: Acting as a central hub, the registry layer manages and validates the availability of various "raw tools" that perform specific AWS security operations.

• Tool Registration: Smaller, specialized tools (e.g., to find public S3 buckets or IAM roles assumable by specific principals) are registered here.
• Validation and Availability: It checks if the invoked tool is valid, present in the registry, and operational. This layer ensures that the request is routed to a functional tool.

1. Tool Layer (Raw AWS Tool Layer): This is where the actual AWS API calls are made. It houses the granular, purpose-built tools for security operations.

• AWS SDK API Calls: Tools in this layer utilize the AWS SDK (Software Development Kit), specifically Boto3 for Python, to make direct API calls to AWS services.
• Second-Order Formatting and Filtering: A key feature of this layer is its smart filtering system. AWS API responses, particularly for large-scale operations (e.g., 5,000 EC2 instances), can be massive JSON objects. The tool layer performs a "second-order filtering" to extract only security-relevant metadata. For an EC2 instance, this might include the IM instance profile, attached security groups, instance ID, creation date, and SSH key pair, rather than the entire verbose response. This reduces the data volume, manages the LLM's token size, and focuses on actionable security information.

Cross-Account Access Mechanism

One of the most critical features of the MCP Server is its ability to perform unified operations across multiple AWS accounts within an organization. This is achieved through a secure and efficient mechanism:

1. Credential Understanding: Upon startup, the MCP Server first identifies the credentials it's operating with. This could be local environment variables, an EC2 instance metadata service (utilizing IMDSv1 or IMDSv2), or an ECS task metadata service.
2. AWS Organizations Integration: Before starting, the server attempts to perform a list organization operation. If the provided credentials have access to AWS Organizations, it enumerates all available AWS accounts within the organization. This provides the comprehensive list of target accounts.
3. Parallel Role Assumption: For each discovered AWS account, the MCP Server attempts to assume a role (e.g., SecurityAuditRole) in parallel. This role assumption generates temporary, valid credentials for each account. The server is designed to assume roles with a security audit IM policy, ensuring read-only access.
4. Boto3 Session Object Map: To manage these temporary credentials securely and efficiently, the server creates a session object map. Instead of exposing raw STS (Security Token Service) credentials back to the MCP client (a potential security risk, as highlighted by past incidents like the GitHub MCP server exposing private repository info), it stores Boto3 session objects. Each session object is linked to an account ID and name.
5. Session Context for Client Requests: When the MCP client sends a request, it includes the session context (e.g., targeting the production account). The LLM is intelligent enough to understand this context and instruct the MCP Server to use the appropriate pre-assumed Boto3 session from its map. This ensures that the end-user or client never directly handles sensitive STS credentials, enhancing security.

Deployment Strategy

Saransh Rana outlined a recommended deployment strategy for the MCP Server:

• Private Hosted Zone: Deploy the MCP Server within a private hosted zone on Route 53.
• Internal Load Balancer: Configure an internal load balancer to front the server.
• AWS ECS Service: Run the MCP Server as an AWS ECS (Elastic Container Service) service (or potentially on EKS (Elastic Kubernetes Service) pods). A single, long-running task is sufficient.
• IAM Role for Cross-Account Access: The ECS task (or EKS pod) assumes an IAM role that has permissions to assume roles across the entire AWS organization, enabling the cross-account functionality.

This architecture ensures that the MCP Server is centrally managed, scalable, and secure, providing a powerful platform for conversational security engineering.

Demo / Proof of Concept

▶ Watch: Problem: Understanding microservice attack surface (5:00)

Saransh Rana showcased several compelling demonstrations of the AWS Security MCP Server's capabilities, illustrating its power in real-world security scenarios.

1. User Behavior Analytics (UEBA) for a Compromised User

This demo addressed a critical incident: an IAM session role generating suspicious API calls, including access denied errors. The goal was to perform UEBA (User Behavior Analytics) for a specific user, user test, on July 25th across multiple AWS accounts.

• Prompt: The LLM was given a detailed prompt, including the username, date, target AWS accounts, and even Athena configuration with sample queries to guide its understanding of the CloudTrail schema.
• Process:

1. The MCP Server first identified three connected AWS accounts, including a "CV security account" with a valid session.
2. It then utilized sequential thinking (a strategy for LLMs to plan tasks) to understand the CloudTrail table schema and craft appropriate Athena queries.
3. A validation query with a LIMIT 5 was run to confirm schema correctness and query functionality.
4. Finally, the LLM executed a full Athena query with a LIMIT 500 to retrieve comprehensive CloudTrail data for the specified user and date.

• Findings & Report: The server generated a detailed report highlighting:
• Mixed behavioral patterns: Indicating anomalous activity.
• Extensive cross-account access attempts.
• 62 authentication events, many of which were failures.
• Multiple assume role calls.
• A crucial observation: the user initially utilized an SSO role and then pivoted to a task role, a sophisticated attack technique.
• Identification of IP addresses and user agents involved.
• Temporal analysis showing initial activity bursts, access denied errors, console attempts, and a primary operation period.
• Legitimacy Check: The LLM then went a step further, comparing the observed activities against the expected behavior of a deployed tool (simulating a scenario where a detection team investigates a new tool). It successfully identified legitimate activities but also flagged suspicious ones, such as web console attempts (when the tool should operate programmatically) and the use of different session names. This highlights the LLM's ability to formulate and validate hypotheses.

2. Subdomain Takeover and Elastic IP Takeover Vulnerability Identification

This demo simulated a bug bounty report regarding a potential subdomain takeover vulnerability.

• Task: Verify potential subdomain takeovers and identify domains vulnerable to elastic IP takeovers across AWS environments, providing a list of AWS accounts, public hosted zones, and vulnerable subdomains.
• Process: The MCP Server invoked Route 53 security operations and EC2 security operations. It found one hosted zone in the current account and a parent hosted zone in the production account. It then investigated IP addresses associated with these domains.
• Outcome: The task was completed in 4 minutes and 20 seconds, identifying accounts, parent hosted zones, child hosted zones, and specific domains vulnerable to elastic IP takeovers, even across multiple AWS accounts and child hosted zones, which is typically a very difficult manual task.

3. Prioritizing Security Findings from IAM Access Analyzer and Security Hub

This demo addressed an overwhelming number of alerts (20,000 alerts) from IAM Access Analyzer and Security Hub.

• Task: Create a detailed report on all external IAM Access Analyzer findings, including an executive summary, potential attack vectors, and prioritized action items. Perform similar analysis for Security Hub findings.
• Process: The MCP Server analyzed all AWS accounts, identified findings from both services, and utilized sequential thinking to plan its report generation.
• Outcome: It identified, for example, three public S3 buckets and two messaging queue trust relationships as potential supply chain attack vectors. It then generated a detailed, prioritized report (expected to be 500-800 words) with executive summaries and actionable insights.

4. Incident Response with CloudTrail and VPC Flow Logs

This was a multi-part demo demonstrating deep log analysis during an ongoing incident.

• Task 1: Chronological Timeline Report from CloudTrail: Create a timeline of an incident using CloudTrail data, an IOC (Indicator of Compromise), and a specific date.
• Process: The server searched CloudTrail logs for the IOC, using a next token rule to ensure complete data retrieval.
• Findings: It generated a detailed RCA (Root Cause Analysis) report, revealing:
• Attacker's advanced knowledge of AWS services and social engineering tactics (e.g., creating an EC2 instance named stage Jenkins deployer to blend in).
• Phase 1 (Access Denied): Attacker compromised an EC2 instance, attempted privilege escalation, found AWS Lambda access.
• Phase 2 (Privilege Escalation): Fetched environment credentials from the Lambda, pivoted.
• Phase 3 (Persistence): Created new EC2 instances (due to EC2 Full Access) within 1 minute, created public security groups.
• Phase 4 (Continued Operations): Ongoing movement, eventually switching identities to avoid detection. The LLM successfully mapped the entire attack timeline from SSRF (Server-Side Request Forgery) on a QA EC2 instance to IMDS (Instance Metadata Service) credential harvesting, Lambda enumeration, privilege escalation via hard-coded keys, persistence, and exfiltration.
• Task 2: VPC Flow Logs Analysis: Investigate VPC Flow Logs to understand network activity after the EC2 compromise.
• Process: Similar to CloudTrail, the server validated queries and searched for the IOC within VPC Flow Logs, performing second-order investigations on network traffic from the compromised EC2 instance.
• Findings: The report showed:
• ICMP probing and heavy bi-directional SSH connections.
• Network scanning (probing port 80, sending TCP SYN packets).
• Targeting multiple subnets and scanning ECS containers.
• Creation of three different EC2 instances with the same CI/CD-like name.
• Data exfiltration (e.g., 151 KB, though ideally much larger).
• The timeline showed the attack happened rapidly (e.g., 1-5 minutes for escalation/persistence), but the logs revealed extensive post-compromise activity.

These demos collectively demonstrated the MCP Server's ability to drastically reduce investigation time, provide deep insights from correlated logs, and generate actionable reports, all through a natural language interface.

Defensive Implications

▶ Watch: Problem: Responding to critical security alerts (e.g., DNS over HTTPS) (6:25)

The AWS Security MCP Server introduces several transformative implications for defensive security operations, fundamentally shifting how teams approach cloud security.

1. Accelerated Incident Response: The most immediate benefit is the dramatic reduction in incident response time. By replacing manual CLI commands, browser tab juggling, and complex query formulation with conversational prompts, security engineers can identify attacker entry points, activities, and lateral movement in minutes rather than hours or days. The demo showing a multi-stage attack timeline derived from CloudTrail and VPC Flow Logs in a short duration exemplifies this. This speed is critical for containing breaches and minimizing damage.

1. Enhanced Threat Hunting Capabilities: The LLM-powered threat hunting capabilities allow defenders to proactively search for anomalies and potential threats with greater efficiency. Instead of needing deep expertise in specific log schemas or query languages (like Athena), analysts can describe their hunting hypothesis in natural language. The system then translates this into precise queries across various log sources, enabling even less experienced team members to contribute to advanced threat hunting.

1. Improved Organizational Visibility and Attack Surface Management: The cross-account access and unified view provided by the MCP Server enable security teams to gain a comprehensive understanding of their entire AWS footprint. This is invaluable for identifying misconfigurations, unmanaged resources, and potential attack vectors (e.g., elastic IP takeovers, vulnerable subdomains, or overly permissive IAM roles) across hundreds or thousands of accounts. Defenders can quickly map out critical attack surfaces and prioritize remediation efforts, moving beyond the "20,000 alerts" problem.

1. Strategic Prioritization of Security Findings: The ability to generate detailed reports with executive summaries, potential attack vectors, and prioritized action items transforms raw security findings into actionable intelligence. This helps security teams, especially in organizations with limited resources, focus on the most critical vulnerabilities and threats. For instance, the system can correlate findings from IAM Access Analyzer and Security Hub to highlight true positives and critical risks, rather than overwhelming analysts with noise.

1. Secure and Controlled Operations: The fundamental design principle of read-only access via a security audit IM policy is a significant defensive advantage. It means the MCP Server itself cannot be used to introduce misconfigurations or perform unauthorized actions, making it a safe tool for broad adoption within security teams. This minimizes the risk associated with powerful automation tools.

1. Automation of Repetitive Security Tasks: The extensibility to AI agents suggests future possibilities for automating routine security tasks, such as daily checks for subdomain takeovers or continuous monitoring for specific compliance violations. This frees up security engineers to focus on more complex, strategic challenges.

1. Data Correlation and Hypothesis Validation: The server's ability to correlate multiple log sources (CloudTrail, VPC Flow Logs, GuardDuty, Security Hub) is crucial for validating attack hypotheses and building a complete picture of an incident. It helps connect the dots between seemingly disparate events, providing a robust foundation for Root Cause Analysis (RCA) and post-incident improvements.

In essence, the AWS Security MCP Server provides defenders with an intelligent assistant that amplifies their capabilities, accelerates their investigations, and provides clearer insights into their cloud security posture, ultimately strengthening their ability to protect their AWS environments.

Key Takeaways

• Conversational Interface for Cloud Security: The AWS Security MCP Server fundamentally shifts cloud security operations from complex CLI commands and fragmented tools to intuitive, natural language conversations with an LLM-powered application, drastically improving efficiency.
• Unified Cross-Account Visibility: It provides a single pane of glass for security operations across an entire AWS organization, enabling rapid discovery, analysis, and threat hunting across potentially thousands of accounts without manual context switching.
• Intelligent Log Correlation and Analysis: The server can correlate diverse AWS log sources like CloudTrail and VPC Flow Logs, using LLMs to interpret raw data, identify attack timelines, and generate detailed incident reports, even for complex multi-stage attacks.
• Read-Only by Design for Security: Operating strictly with a security audit IM policy, the MCP Server is designed for read-only access, ensuring it does not introduce new attack vectors or misconfigurations while performing powerful security investigations.
• Accelerated Incident Response and Threat Hunting: By automating query generation and data filtering, the tool significantly reduces the time required for incident response, blast radius analysis, and proactive threat hunting, transforming hours/days of work into minutes.
• Actionable Insights and Prioritization: It generates detailed reports, including executive summaries, attack vectors, and prioritized action items, helping security teams focus on critical findings and communicate effectively with management.

About the Speaker(s)

Saransh Rana is a Staff Security Engineer at Grid, where he leads the cloud security team. His work focuses on addressing real-world security challenges in large-scale cloud environments, as evidenced by the development of the AWS Security MCP Server. Beyond his role at Grid, Saransh is recognized as an AWS Community Builder in the security domain, actively contributing to the broader cloud security community. He has also made significant open-source contributions, including IMDS shift, a tool designed for seamlessly moving and migrating compute instances to IMDSv2, and dial, which focuses on detecting security misconfigurations through AWS EventBridge and Lambda functions. His expertise spans cloud security architecture, incident response, and leveraging advanced technologies like LLMs for security operations.