A Terraform-built AWS security lab that deploys Wazuh SIEM, Linux and Windows endpoints, custom detection rules, attack simulations, incident-response playbooks, and an AI analyst workflow for alert triage and anomaly detection.

This repository is designed as a portfolio-grade SOC engineering project: it shows cloud infrastructure, detection engineering, purple-team validation, response documentation, and AI-assisted analysis working together in one reproducible lab.

• Highlights
• Architecture
• Quick Start
• Validation Evidence
• Detection Engineering
• Attack Simulation
• AI Alert Analyst
• Incident Response
• Project Structure
• Cost and Cleanup

graph TB
    Analyst[SOC Analyst] --> Dashboard[Wazuh Dashboard]
    Analyst --> AI[AI Alert Analyst]

    subgraph AWS[AWS Cloud]
        subgraph Public[Public Subnet]
            Wazuh[Wazuh Server\nManager + Indexer + Dashboard]
        end
        subgraph Private[Private Subnet]
            Linux[Linux Endpoint\nUbuntu + Wazuh Agent]
            Windows[Windows Endpoint\nWindows Server + Wazuh Agent]
        end
    end

    CloudTrail[CloudTrail Management Events] --> S3[S3 Audit Log Bucket]
    S3 -->|Native aws-s3 module| Wazuh
    Linux -->|Logs and telemetry| Wazuh
    Windows -->|Logs and telemetry| Wazuh
    Wazuh -->|Detected alerts via hook| AI
    AI -->|Anomaly queries when needed| Wazuh
    Wazuh --> Dashboard
    AI --> Playbooks[IR Playbooks + Recommendations]

Detailed diagrams live in docs/diagrams/.

• AWS account and credentials configured for the target account.
• Terraform >= 1.0.
• Existing AWS EC2 key pair.
• Matching local private key for Terraform SSH provisioners.
• Your current public IP in CIDR form, for example 203.0.113.10/32.

git clone https://github.com/trewwwsec/tf-aws-soc.git
cd tf-aws-soc/terraform
cp terraform.tfvars.example terraform.tfvars

Edit terraform.tfvars:

aws_region = "us-east-1"
environment = "lab"
project_name = "cloud-soc"

allowed_ssh_cidr = ["YOUR.PUBLIC.IP.HERE/32"]
ssh_key_name = "cloud-soc-key"
ssh_private_key_path = "~/.ssh/cloud-soc-key.pem"

wazuh_instance_type = "t3.medium"
endpoint_instance_type = "t3.micro"
enable_macos_endpoint = false

# Free-tier-conscious AWS API audit ingestion
enable_cloudtrail_wazuh_ingestion = true
cloudtrail_log_retention_days = 14
cloudtrail_multi_region = false

terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform apply tfplan

Wazuh bootstrap usually takes 5–10 minutes after the EC2 instance starts. The Terraform rule provisioner waits before connecting, but if your public IP changes mid-deploy, update allowed_ssh_cidr and rerun terraform apply.

CloudTrail management events are enabled by default and delivered to a dedicated encrypted S3 bucket. Wazuh reads those objects with its native AWS aws-s3 module using the Wazuh EC2 instance role, so no static AWS keys are stored on the server. CloudTrail data events, GuardDuty, VPC Flow Logs, Security Hub, and AWS Config are intentionally not enabled by this PR to keep the default lab cost-conscious.

SOCFortress note: the upstream SOCFortress rule installer can prompt for confirmation. If Terraform blocks at that step, complete the installer manually over SSH or adjust the provisioner to run it non-interactively before using this in unattended CI.

terraform output wazuh_server_public_ip
terraform output wazuh_dashboard_url

# Retrieve dashboard credentials from the Wazuh server
cd ..
./scripts/get-wazuh-info.sh
./scripts/get-wazuh-info.sh --all

# On the Wazuh server
sudo systemctl is-active wazuh-manager wazuh-indexer wazuh-dashboard
sudo /var/ossec/bin/agent_control -l
sudo ls -lh /var/ossec/etc/rules/local_rules.xml /var/ossec/etc/rules/macos_rules.xml
sudo tail -n 200 /var/ossec/logs/ossec.log | grep -Ei 'fatal|error' || true

Expected baseline:

• Wazuh manager, indexer, and dashboard are active.
• Server, Linux endpoint, and Windows endpoint are registered in Wazuh.
• Custom rule files exist and are readable by Wazuh.
• No recent fatal rule-load errors.

Latest lab validation performed in AWS:

Screenshots from a prior live demo are available in docs/APT-SIMULATION-DEMO.md.

SOCFortress community rules add broader Wazuh detection content during deployment. The exact community rule count can change upstream, so custom rules are the stable project-owned detection set.

<rule id="200001" level="10" frequency="5" timeframe="120">
  <if_matched_sid>5551</if_matched_sid>
  <same_source_ip />
  <description>SSH brute force attack detected - 5+ failures in 2 minutes</description>
  <mitre>
    <id>T1110</id>
  </mitre>
  <group>authentication_failures,brute_force,MITRE_T1110,PCI_DSS_10.2.4</group>
</rule>

Read the rules directly:

• wazuh/custom_rules/local_rules.xml
• wazuh/custom_rules/macos_rules.xml
• docs/MITRE_COVERAGE.md
• detections/README.md

The attack-simulation/ toolkit provides controlled purple-team activity for validating Wazuh detections in the lab.

Run only inside an isolated lab you own or are authorized to test:

cd attack-simulation
./run-all-linux.sh

Verify alerts on Wazuh:

sudo grep 'Rule: 200' /var/ossec/logs/alerts/alerts.log | tail -30
sudo grep -o '"id":"200[0-9]*"' /var/ossec/logs/alerts/alerts.json | sort | uniq -c | sort -rn

More detail: attack-simulation/README.md, attack-simulation/QUICK-REFERENCE.md, and docs/APT-SIMULATION-DEMO.md.

The ai-analyst/ service adds AI-assisted SOC workflows on top of Wazuh alerts.

Key capabilities:

• Hook-first alert ingestion: Wazuh can send detected alerts to the Alert Analyzer instead of requiring the analyzer to poll Wazuh for alert triage.
• Wazuh API access for anomaly detection: anomaly detection can still query Wazuh for event windows and baselines.
• FastAPI server: exposes alert intake, feedback, webhook, and analysis endpoints.
• RAG playbook mapping: chunks and retrieves relevant incident-response playbook sections.
• Provider support: OpenAI, Anthropic, and local Ollama-compatible workflows.
• Operational feedback: stores analyst feedback and supports webhook notifications.

Quick start:

cd ai-analyst
uv run --with-requirements requirements.txt python src/analyze_alert.py --demo
uv run --with-requirements requirements.txt python src/detect_anomalies.py --demo
uv run --with-requirements requirements.txt uvicorn src.api_server:app --host 0.0.0.0 --port 8000

Regression tests:

uv run --with-requirements ai-analyst/requirements.txt python -m pytest ai-analyst/tests -q

More detail: ai-analyst/README.md and ai-analyst/RAG.md.

Incident-response content follows a NIST-style lifecycle:

Preparation → Detection & Analysis → Containment → Eradication → Recovery → Post-Incident

Evidence collection helper:

./incident-response/tools/collect-evidence.sh <hostname> <incident-id>

See incident-response/README.md and incident-response/templates/incident-report-template.md.

tf-aws-soc/
├── terraform/                  # AWS infrastructure as code
│   ├── provider.tf             # Terraform and AWS provider configuration
│   ├── vpc.tf                  # VPC, subnets, route tables, NAT Gateway
│   ├── cloudtrail_wazuh.tf     # CloudTrail S3 bucket and trail for Wazuh ingestion
│   ├── ec2.tf                  # Wazuh and endpoint EC2 instances
│   ├── security_groups.tf      # Wazuh, Linux, and Windows security groups
│   ├── iam.tf                  # EC2 IAM roles and instance profiles
│   ├── outputs.tf              # Dashboard, IP, and SSH outputs
│   └── user_data/              # Wazuh and agent bootstrap scripts
├── wazuh/custom_rules/         # Project-owned Wazuh rules
├── attack-simulation/          # Purple-team validation scripts
├── detections/                 # Detection documentation and test helpers
├── incident-response/          # Playbooks, templates, and evidence tooling
├── ai-analyst/                 # AI analysis, anomaly detection, and API server
├── docs/                       # Diagrams, demo evidence, and coverage docs
└── scripts/                    # Utility scripts

Approximate always-on lab cost in us-east-1 with default instance sizes:

Destroy resources when testing is complete:

cd terraform
terraform destroy
terraform state list

terraform state list should be empty after a successful teardown.

• docs/README.md — documentation overview.
• docs/diagrams/ — architecture and workflow diagrams.
• docs/MITRE_COVERAGE.md — MITRE ATT&CK coverage.
• docs/AI_API_ACTIVE_RESPONSE.md — AI API and active-response notes.
• detections/README.md — detection deployment guide.
• attack-simulation/README.md — attack simulation framework.
• incident-response/README.md — IR framework.
• ai-analyst/README.md — AI analyst details.

• AWS networking and compute security.
• Terraform infrastructure as code.
• Wazuh SIEM deployment and tuning.
• MITRE ATT&CK-aligned detection engineering.
• Linux, Windows, and macOS security telemetry.
• Purple-team simulation and detection validation.
• Incident-response playbook development.
• Python/FastAPI AI analyst service design.
• LLM-assisted triage, RAG retrieval, and anomaly detection.

Useful contribution areas:

• Make the SOCFortress provisioner fully non-interactive.
• Add CI checks for Terraform validation and documentation drift.
• Expand Windows simulation automation.
• Add more Wazuh API-backed live anomaly tests.
• Add multi-region or high-availability Terraform variants.

Development basics:

git checkout -b feature/your-change
python3 scripts/validate_docs.py
uv run --with-requirements ai-analyst/requirements.txt python -m pytest ai-analyst/tests -q
git push origin feature/your-change

This project is licensed under the MIT License. See LICENSE.

• Wazuh for open-source security monitoring.
• MITRE ATT&CK for adversary behavior mapping.
• SOCFortress for community Wazuh rule content.
• Atomic Red Team for attack simulation inspiration.
• Terraform for infrastructure as code.

Built for hands-on cloud SOC engineering, detection validation, and AI-assisted security operations.