Serverless Security Alert Response Pipeline

I built SSARP as an automated first responder for cloud security incidents. It monitors AWS for suspicious activity, evaluates the severity of any threats, and instantly quarantines compromised accounts or roles to stop an attack from spreading. Security teams monitor the entire process from a live dashboard.

• Automates triage: Ingests alerts from AWS Security Hub and evaluates their severity instantly without manual review.
• Contains threats automatically: Attaches a "deny all" policy to compromised resources the moment a critical threat is confirmed.
• Prevents self-lockout: Uses strict guardrails and allowlists so the automated system never accidentally locks out administrators.
• Provides safe simulations: Includes a built-in sandbox engine so recruiters and teams can run simulated attacks and watch the pipeline respond without touching production data.

When AWS detects a security event (like someone trying to escalate their privileges), it routes the alert into a queue. A series of automated workers (AWS Lambda functions) pick up the alert and analyze it.

If the worker determines the event is critical, it triggers a quarantine sequence. The system double-checks that the target isn't a protected administrator. Once cleared, it directly alters the compromised identity's permissions to block all actions. Finally, it logs the entire incident to a database, which instantly updates the web dashboard.

Manual incident response is too slow for cloud environments where attackers can move laterally in minutes. SSARP cuts containment time from hours to seconds, stopping the bleeding instantly while giving human engineers the time they need to investigate properly.

View the code on GitHub ?

The system relies on event-driven orchestration to handle alerts asynchronously. EventBridge captures findings and pushes them to an SQS queue. A dispatcher Lambda reads the queue and triggers an AWS Step Functions state machine. Inside the state machine, Python Lambdas handle enrichment, severity evaluation, and quarantine execution. A Next.js frontend discovers resources via SSM Parameter Store and queries DynamoDB for the audit trail.

1. Event Ingestion: Security Hub alerts trigger an EventBridge rule, which buffers the payload in an SQS queue to handle sudden bursts of alerts.
2. State Machine Execution: A dispatcher Lambda pulls from SQS and starts a Step Functions workflow.
3. Evaluation: The Enrichment Lambda extracts resource IDs and metadata. The Severity Check Lambda evaluates the risk.
4. Quarantine: If critical, the Quarantine Lambda checks a protected role allowlist. If the role is not protected, the script uses boto3 to attach an inline AutomatedQuarantine-DenyAll IAM policy directly to the compromised role.
5. Audit: The result is written to DynamoDB. The Next.js dashboard reads this table to display live state.

The infrastructure uses a hybrid approach to Infrastructure as Code (IaC).

• Foundation Layer: Critical boundaries (IAM execution roles, SNS topics) are defined in raw CloudFormation YAML for easy security auditing.
• Application Layer: Dynamic resources (Step Functions, SQS, DynamoDB, Lambdas) are defined using AWS CDK (TypeScript). The CDK uses CfnInclude to merge the YAML foundation.
• CI/CD: AWS CodePipeline provides GitOps-driven deployment. Every push to the main branch triggers a full synthesis and CloudFormation deployment.

• Chose SQS buffering before Step Functions over direct EventBridge triggers because high-volume alert spikes could exceed Step Functions rate limits - the tradeoff was a few milliseconds of added latency for guaranteed delivery.
• Chose a hybrid IaC model (YAML + CDK) over pure CDK because security teams prefer auditing raw CloudFormation for IAM roles - the tradeoff was managing two different file types during deployment.
• Chose dynamic SSM parameter discovery over environment variables because AWS generates random IDs for resources during deployment - the tradeoff was requiring the Next.js frontend to query SSM at runtime to find the database.

• Target Scope: The current quarantine logic only targets IAM roles. It does not yet automatically isolate compromised EC2 instances or revoke active sessions.