Skip to content
ZK
ZAIN KHALIL KHAN
PORTFOLIO
All articles

Field journal

How I Built Aegis SOC Analyst: Turning Noisy Telemetry Into Actionable Incidents

The architecture, detection logic, and product decisions behind my SOC platform, from normalizing five telemetry sources to generating evidence-grounded incident narratives.

August 27, 20264 min
ProjectsSOCSIEMDetection EngineeringAI

The problem I wanted to solve

Security teams rarely suffer from a lack of alerts. They suffer from too many disconnected alerts. A firewall may show a suspicious connection, Active Directory may show an unusual login, and an endpoint tool may flag a process, but the analyst still has to decide whether those events belong to the same story. I built Aegis SOC Analyst because I wanted to explore that gap between collecting data and understanding an incident. The goal was not to create another dashboard full of red badges. It was to build a system that could normalize evidence, connect related activity, and explain why an analyst should care.

A common event language

The first major decision was to create one event schema for firewall, cloud, Active Directory, Linux, and EDR telemetry. Each source describes time, identity, host, action, and outcome differently. I mapped those fields into a consistent structure while preserving the original event for investigation. That tradeoff mattered. Aggressive normalization makes queries easier, but it can erase details that later prove important. Keeping both the normalized record and source context gave the platform a clean analytical layer without sacrificing evidence.

From rules to incidents

I mapped detection logic to MITRE ATT&CK so alerts had a shared vocabulary. A single match became an alert, but related alerts could be grouped into a scored incident based on identity, host, time, and technique. The scoring model was intentionally explainable. An analyst should be able to see which signals raised severity instead of trusting an unexplained number. The AI layer came last. It uses the correlated evidence to write an attack narrative, severity rationale, and containment suggestions. It does not replace the underlying detections or invent facts outside the incident record.

What I learned

The hardest part of a SOC product is not the interface or the language model. It is data quality. Timestamps drift, identities appear in multiple formats, and incomplete events create false confidence. Building Aegis taught me to treat normalization, provenance, and transparent scoring as core security features. My next focus would be measuring detection coverage and false-positive rates with repeatable attack simulations. A convincing demo is useful, but a trustworthy security system needs evidence that it behaves well when the data is messy.