Building a SOC (2/4): From Logs to Response – The Anatomy of a Modern SOC

Predrag Puharic
Oct 17
2 min read

What a SOC really is – more than just technology

A Security Operations Centre (SOC) is not merely a room full of screens — it’s a function that unites technology, processes, and people to detect and neutralise threats before they cause damage. A well-designed SOC provides centralised visibility, correlates logs from multiple sources, and enables fast and coordinated response.

It usually consists of three functional layers:

Data collection and correlation – gathering logs from servers, network devices, endpoints, and apps.
Analysis and detection – identifying anomalies and correlating events.
Response and escalation – isolating, mitigating, reporting, and learning.

Core roles in a SOC

An effective SOC defines its roles clearly:

Tier 1 Analyst: monitors alerts and filters false positives.
Tier 2 Analyst: deeper investigation and correlation.
Incident Responder: coordinates containment and remediation.
Threat Hunter: proactively seeks undetected threats.
SOC Lead / Manager: oversees operations and metrics.

CSEC perspective: in smaller or academic environments, multiple roles are often combined — making process discipline and automation crucial to efficiency.

Technical layers of a modern SOC

Log collection & normalisation Use a SIEM such as Wazuh, which integrates servers, endpoints, and sensors.
Analytics & visualisation Solutions like ELK Stack (Elasticsearch, Logstash, Kibana) provide searchable and visual insights.
Incident management Platforms like TheHive (with Cortex automation) structure and streamline incident handling.
Threat intelligence integration MISP enables correlation of local events with global Indicators of Compromise (IoCs).
Network & endpoint monitoring Tools such as Zeek, Suricata, and Velociraptor offer visibility into network and endpoint behaviour.

The process: from detection to learning

Every SOC should follow a clear incident lifecycle:

Detection → rules and correlations
Analysis → validation and classification
Response → containment and mitigation
Recovery → systems return to normal
Learning → document and adjust rules

Each phase should be measurable through key metrics like MTTD (Mean Time to Detect) and MTTR (Mean Time to Respond).

The CSEC context

CSEC already operates core components of a regional SOC:

DecoyNet honeypot network for passive attack detection.
ShadowServer data for BiH for vulnerability visibility.
CSEC CVE Tracker for vulnerability correlation.

Integrating these into an open-source SOC stack could form a functional SOC model for Bosnia and Herzegovina, tailored to academia, civil society, and SMEs.

Conclusion: structure before software

A SOC is not built by installing tools — it’s built by defining structure, roles, and workflows. In the next post, we’ll introduce a practical open-source SOC blueprint, showing how to combine free tools into a cohesive and operational system.