~/nabeel
Back to projects

Jul 2026 — Present

Cloud Security Automation Framework

A modular, event-driven SOAR platform for AWS that detects and remediates high-risk security events in under a second, aligned to MITRE ATT&CK.

Cloud Security Automation Framework preview

Problem & context

Cloud security teams can detect risky changes — an open S3 bucket, a loosened IAM policy, an unusual network rule — faster than they can respond to them. The gap between detection and containment is where damage happens, and manual response doesn't scale across a growing AWS footprint.

Built as a personal cloud-security project to explore SOAR (Security Orchestration, Automation and Response) patterns hands-on: how a detection turns into a scoped, reversible, auditable action without a human in the loop for the first response.

Constraints

  • Response actions must be deterministic and reversible — no destructive default actions
  • Sub-second containment for the highest-severity event classes
  • Full audit trail of every automated action, forwarded to Splunk for SIEM visibility
  • Infrastructure had to be reproducible, not hand-clicked in the AWS console

Trade-offs

  • Speed vs. blast radius: playbooks default to narrow, scoped actions (revert a single policy change) rather than broad lockdowns, trading some containment breadth for lower risk of a false-positive outage.
  • Event-driven vs. polling: chose an event-driven architecture over periodic scanning, which cut detection latency significantly but pushed more complexity into idempotent event handling.
  • Terraform-managed infra added upfront overhead versus clicking through the console, but made the whole environment reproducible and testable end-to-end.

Architecture

 AWS Event (CloudTrail / EventBridge)


 ┌─────────────────┐      ┌──────────────────┐
 │  Detection Layer │─────▶│ Orchestration     │
 │  (MITRE mapping) │      │ Engine (Python)   │
 └─────────────────┘      └────────┬─────────┘

                     ┌───────────────┼───────────────┐
                     ▼               ▼               ▼
              Storage playbook  Identity playbook  Network playbook
                     │               │               │
                     └───────────────┴───────────────┘

                          Structured telemetry → Splunk

Each playbook is a self-contained, testable unit: it receives a normalized event, decides on a scoped remediation, executes it, and emits a structured record of what it did — regardless of which AWS service triggered the original event.

Infrastructure as code

The SOAR platform’s own security infrastructure — the roles, queues, and functions that make automated response possible — is provisioned with Terraform. That made it possible to spin up a full, isolated test environment, run the adversary simulation framework against it, and tear it down cleanly, rather than validating changes against a hand-configured environment that could drift from what’s actually deployed.

Results

  • Automated, deterministic containment of high-risk AWS events in under one second
  • Playbooks cover storage, identity, and network security event classes
  • Structured incident telemetry forwarded to Splunk Enterprise for full audit visibility
  • Validated end-to-end via an automated adversary simulation framework

Lessons learned

The hardest part wasn't detection — it was designing playbooks that were safe to run automatically. Idempotency and reversibility ended up mattering more than raw response speed, because a fast wrong action is worse than a slightly slower correct one.

Talk about a similar project