SOC Tooling and the SIEM

A SIEM receives event data from multiple sources: syslog from network devices and servers, Windows Event Log forwarded via agents, cloud provider audit trails from AWS CloudTrail or Azure Monitor, web proxy logs, email gateway logs, and authentication records from identity providers. The first processing step is normalisation: mapping each source's proprietary field names and values to a common schema so that a failed logon from a Linux server and a failed logon from an Active Directory domain controller can be queried with the same search syntax.

Correlation rules define the detection logic. A simple rule might fire when the same source IP generates more than twenty failed SSH logons in sixty seconds against the same host. A more complex rule might correlate a failed logon burst, followed by a successful logon from the same source, followed by an outbound connection to an IP with a low reputation score, all within a fifteen-minute window, into a single high-confidence alert. Writing and maintaining those rules is detection engineering, and it requires ongoing tuning to balance sensitivity against false-positive rate.

Modern SIEM platforms also support user and entity behaviour analytics (UEBA), which builds statistical baselines for individual users and devices and alerts when behaviour deviates from the baseline. A user who downloads fifty megabytes of data every day represents no anomaly; the same user downloading ten gigabytes at 2 a.m. on a Sunday does. UEBA catches insider threats and compromised credentials that rule-based detection misses, but it requires weeks of baseline data before it produces useful output.

A SOAR platform sits between the SIEM and the analyst. When the SIEM fires an alert, the SOAR receives it via webhook or API and executes a playbook: a defined sequence of automated steps. For a phishing alert, the playbook might extract URLs and file hashes from the email, query a threat intelligence feed for each, check whether any recipient clicked a link, look up the sending domain's age and registration details, and assemble all results into a structured case before a human analyst sees it. The analyst then makes a containment decision on a pre-enriched case rather than starting the enrichment from scratch.

SOAR platforms also handle notification and escalation: paging the on-call analyst, opening a ticket in a service-desk system, or sending a Slack message to the IR channel. This removes the manual coordination step that delays response. In high-volume environments, SOAR can fully close low-severity alert types automatically once confidence thresholds are met, freeing analysts for cases that require judgment.

The value of a SOAR depends on the quality of its integrations. A SOAR that cannot reach the firewall API to block an IP, or cannot write to the ITSM system to create a ticket, is limited to enrichment only. Organisations deploying SOAR need to map their tool inventory before selecting a platform and verify that the necessary API connectors exist or can be built.

Endpoint Detection and Response tools deploy a lightweight agent on each managed host. The agent records a continuous stream of telemetry: every process that starts, the parent process that spawned it, the command-line arguments, every file written or deleted, every network connection established, and every registry key modified on Windows hosts. This telemetry is streamed to a central data store where it is indexed and retained, typically for thirty to ninety days.

During an investigation, an analyst can query the EDR platform across all endpoints simultaneously. A search for the hash of a malicious binary tells the analyst within seconds how many hosts have seen that file, when it first appeared, which process dropped it, and what network connections it made. This enterprise-wide query capability replaces the slow process of manually imaging and examining individual hosts.

EDR platforms also provide live response: a remote shell into a running endpoint that allows the analyst to examine running processes, extract files, collect volatile memory, or terminate a process, all without physically accessing the machine. This is particularly important in geographically distributed organisations where the affected endpoint may be in another country. The forensic readiness considerations for live response, including chain of custody for collected artefacts and the order of volatility, apply equally to EDR-based collection and to traditional forensic acquisition.

A Threat Intelligence Platform ingests indicators of compromise (IOCs) from multiple feeds: commercial providers such as Recorded Future or Mandiant, government-operated sharing groups such as the US Information Sharing and Analysis Centres (ISACs), the UK National Cyber Security Centre (NCSC) feeds, the EU ENISA annual threat reports, and community sources such as AlienVault OTX. Each indicator, an IP address, domain, file hash, URL, or email address, carries metadata: the feed that reported it, when it was first seen, when it was last confirmed active, and what threat actors or malware families it is associated with.

The TIP deduplicates indicators across feeds, applies a confidence score based on how many independent sources reported it and how recently, and exports the curated result to the SIEM as lookup tables or via STIX/TAXII. When a SIEM correlation rule fires, the alert is automatically enriched with any matching TIP data: if the destination IP of an outbound connection is in the TIP as a known command-and-control server for a specific ransomware family, that context appears in the alert immediately, reducing the time an analyst spends on initial triage.

TIPs also support strategic intelligence functions: tracking threat actor campaigns, mapping tactics to MITRE ATT&CK techniques, and informing detection rule development. An organisation that has visibility into which techniques a threat actor targeting its sector is currently using can prioritise the detection rules that cover those techniques. This is the link between strategic threat intelligence and operational detection engineering.

A case-management system (also called a ticketing or incident-tracking system) provides the persistent record of an incident from first alert to post-incident closure. In some organisations this is a general-purpose ITSM platform such as ServiceNow or Jira. In others it is a SOC-specific product such as TheHive, which is purpose-built for security case management with native integration points for SIEM alerts and SOAR actions. Purpose-built tools typically model incidents as collections of observables (IP addresses, hostnames, file hashes), tasks assigned to analysts, and a timeline of analyst actions.

The case record must capture: the initial alert that opened the case, every action the analyst took and when, every tool output that contributed to the investigation, the containment and eradication steps, and the final determination of root cause and scope. This record serves three purposes. First, it enables handover between analysts without information loss when a shift changes during an active incident. Second, it provides the material for the post-incident review and lessons-learned process. Third, for incidents that cross a legal or regulatory reporting threshold, the case record is the primary artefact supporting the required notification.

Regulatory reporting requirements vary by jurisdiction. In the European Union, the NIS2 Directive requires operators of essential services to notify the relevant computer security incident response team within 24 hours of becoming aware of a significant incident. In the United States, the SEC requires public companies to disclose material cybersecurity incidents within four business days of determining materiality. India's CERT-In rules under the Information Technology Act 2000 mandate reporting of specified incidents within six hours. The UK's ICO expects breach notification under UK GDPR within 72 hours. In each case, the case-management record is what makes those notifications accurate and defensible.

The tools work as a pipeline. The SIEM collects raw data from network, endpoint, cloud, and identity sources. EDR agents on endpoints contribute process and file telemetry that network logs cannot provide. The TIP enriches SIEM correlation rules with current indicator data. When a correlation rule fires, the alert passes to SOAR, which runs an automated playbook: enriching the alert with TIP lookups, querying the EDR for process context on the affected host, checking the user's recent authentication history from the identity provider, and opening a case in the case-management system with all those results pre-populated. The analyst receives a page and opens a case that already contains the first ten minutes of investigation work.

This integration reduces MTTD by ensuring that every relevant data source contributes to correlation, not just the sources the analyst happens to check manually. It reduces MTTR by removing the manual enrichment step from the analyst's workload and ensuring that containment actions such as host isolation or IP blocking can be triggered from the SOAR playbook without the analyst having to log into a separate console.

The integration also creates dependencies. If the SOAR cannot reach the EDR API, automated playbooks degrade to partial enrichment. If the TIP feed is stale, SIEM correlation misses new indicators. Organisations that rely heavily on automation must monitor the health of the integration layer itself as a SOC operational requirement. The scoping and confirming phase of an active investigation depends on the accuracy of the data these tools provide.