Security Automation & Detection Lab

The problem

Windows Security Events, Linux authentication logs, firewall records, and AWS telemetry all expose different fields and message formats. Binding detection logic directly to every raw source makes rules difficult to reuse and expands parser complexity as new sources are added.

The project separates collection and source-specific parsing from behavioral detection. Normalizers map source data into a shared SecurityEvent representation; the analyzer consumes those normalized events and produces standardized SecurityFinding objects.

Architecture

Windows Security Log → Get-SecurityEvents.ps1 ┐ Linux SSH logs → ssh_normalizer.py │ Linux UFW logs → ufw_normalizer.py │ AWS CloudTrail → cloudtrail_normalizer.py ├→ normalized SecurityEvent JSON AWS VPC Flow Logs → vpc_flowlog_normalizer.py ┘ ↓ SecurityEventAnalyzer ↓ SecurityFindings

The key design choice is semantic normalization. Authentication activity can be represented as SuccessfulAuthentication or FailedAuthentication, allowing a detector to operate on behavior instead of a Windows Event ID or an SSH message format.

Current detection coverage

5failed authentications in 5 minutes → High brute-force finding

4distinct blocked ports in 1 minute → Medium port-scan finding

24haccount creation → privileged group correlation window

Additional rules detect Windows account creation and group membership changes. Privileged group changes are severity-aware, and a correlated account-creation followed by privileged-group membership produces a Critical finding. The correlation can also enrich the result when a later successful logon and matching special-privilege assignment are observed.

Normalization example

A Windows collector maps Event IDs 4624 and 4625 to source-independent authentication event types. Fields that do not apply to a particular event remain nullable so the same model can represent different telemetry sources.

{
  "Timestamp": "2026-09-04T10:03:25.8449849-07:00",
  "EventId": 4624,
  "EventType": "SuccessfulAuthentication",
  "Computer": "COMP1",
  "TargetUser": "SYSTEM",
  "SourceIp": null,
  "LogonId": "0x3e7"
}

Detection evidence

The port-scan path normalizes network-block telemetry and evaluates unique destination ports in a sliding time window rather than simply counting repeated traffic.

Port Scan Detection
4 distinct blocked destination ports detected within a 1 minute window.

Severity: Medium
Source IP: 192.0.2.10
Destination IP: 198.51.100.20
Count: 4

Engineering takeaways

This project demonstrates separation of concerns between ingestion, normalization, detection, and presentation; extensibility through a central detection engine and rule contract; time-window correlation; source-independent event semantics; and testing through xUnit unit tests.