Security Logging & Monitoring

SIEM stands for Security Information and Event Management – a technology category that centrally collects, normalises, correlates, and analyses security-relevant log data from across the entire IT infrastructure. A SIEM answers the question: what is happening in my environment right now – and does it indicate an attack? It combines two classic disciplines: Security Information Management (SIM, long-term archiving and compliance reporting) and Security Event Management (SEM, real-time correlation and alerting).

The core functions of a SIEM are log aggregation (bundling data from firewalls, endpoints, cloud, Active Directory, and applications into a central system), normalisation (converting different log formats into a unified schema), event correlation (linking events across multiple sources and time periods to detect complex attack patterns), alerting (triggering alarms on suspicious patterns), and compliance reporting (tamper-proof log archiving and audit evidence reports).

SIEM differs from pure log management: log management stores logs – SIEM analyses them actively. SIEM differs from SOAR (Security Orchestration, Automation and Response): SOAR responds automatically to alerts – SIEM detects them. In practice, SIEM and SOAR are frequently combined: the SIEM produces the alert, the SOAR automates the initial response. Modern platforms such as Microsoft Sentinel integrate both functions in a single product.

The average time between initial compromise and discovery of an attack is several weeks to months, according to the Mandiant M-Trends Report. During this time, attackers move through the network, escalate privileges, exfiltrate data, and establish persistence. The ransomware deployment, backdoor activation, or data publication is often the final step in a long attack process – one that could have been detected with security monitoring.

The foundation for detection is complete, structured logging. Without logs there is no detection; without central aggregation there is no correlation; without correlation rules there are no alerts. Most organisations have some form of logging – but it is decentralised, incomplete, inconsistently formatted, and no one reviews it systematically. This logging is not a security resource but a data graveyard.

In accompanying ISO 27001 audits and DORA reviews, a recurring finding is: many organisations can demonstrate that logs exist – but not that they are systematically evaluated. Auditors and external reviewers clearly distinguish between logging as a compliance checkbox and demonstrable detection capability. This distinction is audit-relevant.

Security monitoring starts with the question: what are the most critical attacks that could affect us – and which logs would make those attacks visible? This question is harder to answer than the technical implementation of a SIEM. We start with this question and build the monitoring from there.

A SIEM aggregates logs from various sources, normalises them into a unified format, correlates events across sources and time periods, and generates alerts on suspicious patterns. The choice of SIEM platform depends on your infrastructure, budget, and operating model: Microsoft Sentinel for Azure-centric environments, Splunk for powerful enterprise logging, Elastic Security as a cost-efficient open-source alternative, QRadar for complex hybrid environments.

The critical log sources for a Windows-centric enterprise environment are: Active Directory event logs (Security, System, Application), DNS queries, network flow data (NetFlow, sFlow), firewall and proxy logs, VPN authentications, EDR telemetry (Endpoint Detection & Response), cloud API logs (Azure Activity, AWS CloudTrail), and application logs for critical business systems. Each of these sources has specific challenges: volume, format, signal noise, and normalisation.

We size SIEM architectures realistically: what are the actual log volumes? Which sources deliver the highest security value? Where does hot storage pay off (for fast queries), where is cold storage sufficient (for compliance and forensics)? Oversized SIEM deployments fail on operational cost; undersized ones lose important events. We find the right balance for your profile.

Detection engineering is the discipline of developing effective detection rules that identify real attacks without generating alert fatigue through false positives. The MITRE ATT&CK framework provides the conceptual foundation: it catalogues known adversary tactics, techniques, and procedures (TTPs) and maps them by phase from Initial Access to Impact. For each technique – Kerberoasting, LSASS Credential Dumping, Scheduled Task Persistence, Staged Data Exfiltration – there are typical log signatures that can be detected.

We develop custom detection rules based on MITRE ATT&CK, calibrated to your specific infrastructure and threat landscape. A rule that works well in an organisation with 5,000 Windows clients may generate a flood of false positives in one with 50. We calibrate rules against your environment before they go to production.

For every alert rule we develop playbooks: what should be done when this alert fires? How is the alert validated? What additional indicators should be queried? Who is informed, and when? These playbooks can be executed manually or automated in SOAR platforms to minimise response time.

SIEM is no longer an optional add-on – for regulated organisations it is a compliance requirement. NIS2 Article 21 requires essential and important entities to have the capability for threat detection, incident response, and complete security logging. Without a central SIEM, neither the detection nor the evidencing capability towards supervisory authorities can be demonstrated. The 24-hour reporting deadline for significant security incidents presupposes that attacks are detected at all – which without SIEM often only happens weeks later.

ISO 27001:2022 addresses SIEM directly in Annex A.8.15 (Logging) and A.8.16 (Monitoring): logs of security-relevant events must be collected, stored, and regularly evaluated. Auditors expect not only that logs exist but that a documented process shows who evaluates which logs at what intervals, which rules trigger alerts, and how incidents are responded to. A SIEM delivers exactly this audit evidence. From our experience accompanying certification audits: auditors do not check whether a SIEM exists – they check whether the process behind it works.

DORA (Digital Operational Resilience Act) requires financial institutions to implement ICT risk management with anomaly detection capability and the technical ability to log and analyse security-relevant events across the entire ICT stack. For financial companies under BaFin supervision, demonstrable detection and response capability is not a voluntary measure but an audit-relevant requirement. We implement SIEM solutions that simultaneously meet NIS2, ISO 27001, and DORA requirements – with a consolidated reporting structure rather than three separate compliance documents.