The Magic Behind Automated Security Response on AWS

Transcript

1. The Magic Behind Sena Yakut, 2026 Automated Security Response on AWS
2. About Me! Cloud Security Architect, CyberWhiz Sena Yakut All links about me
3. 3:00 AM Your system is under attack. No one is watching. …until it's too late. Imagine this…
4. The real problem. Too many alerts. No real attention. Manual response. Dependent on humans. Too slow to react. Attackers move faster. We already have the tools. But they don’t work together.
5. Alerts don’t stop attacks. Actions do.
6. Alerts don’t stop attacks. Actions do.
7. Alerts don’t stop attacks. Actions do.
8. So what if we could automate actions? It depends on your architecture. But once you decide… you don’t have to decide again. Build once. Respond forever. Services Cost Third–party tools Compliance Risk appetite
9. What is the solution? – Be Flexible Detect → Trigger → Actions –> Notify Third-party service security finding → Isolate EC2 instance Security Hub finding → Create ticket + notify WAF suspicious IP → Add IP to block list Custom app alert → Trigger internal response Central Event Hub Lambda logic → Severity check → Resource type check → Allowlist / context
10. What is the solution? – Orchestrate Everything Detect → Trigger → Orchestrate Too many possible actions. → Send email → Execute Systems Manager runbook → Block IP (WAF / Security Group) → Disable IAM credentials Too many decisions. → Which team owns this? → What is the severity? → Auto remediation or manual approval? → Is this a false positive? Too much complexity. → Different services, different formats → Multiple teams involved → No single source of truth → Hard to scale consistently AWS Step Functions Define decisions. Not just actions.
11. Let’s Start Simple Logs generate lists of IP addresses → Each IP should be checked automatically → Malicious IPs should trigger an incident → Safe IPs should be recorded → The process should run without manual effort → Results should be consistent and repeatable
12. From Simple to Real-World Flow GuardDuty generates alerts across different resources → Production environments could require approval. → Teams should be notified automatically. → Quarantine actions should run without delay. → Different teams should receive different tickets. → Responses should be consistent and repeatable.
13. 1. Detection GuardDuty detects suspicious EC2 activity → Possible command & control traffic 2. Trigger EventBridge captures the finding → Sends it to Step Functions 3. Decision Is it critical? Is it allowlisted? Is it production? From Simple to Real-World Flow
14. 4. Action Automated response is executed → Create EBS snapshot (forensics) → Quarantine EC2 instance 5. Response Parallel actions are triggered → Create incident ticket → Generate AI summary → Notify teams (SNS) From Simple to Real-World Flow
15. All executed in seconds. No human delay.
16. No human delay. No missed alerts.
17. Attackers move fast. Now you do too.
18. THANK YOU