SIEM, NIS2 & ISO: Implementation Practice

SIEM in Practice: The Gap Between Monitoring and NIS2 Requirements

This case study documents the practical implementation of Wazuh SIEM in a Proxmox test environment. The goal was to bridge GRC theory with operational reality – to check what SIEM really delivers in terms of monitoring, vulnerability detection, and practical risk data.

Why This Project Matters (Practical Perspective)

In GRC, it is easy to meet formal requirements: policies, procedures, audit records.
It is much harder to build real incident detection capability.

This project was created to verify in practice:

• whether monitoring actually enables incident identification,
• which data has real value for risk analysis,
• where compliance ends and operational security begins.

SIEM in the Context of NIS2 and UKSC – Where Is the Real Gap?

The NIS2 directive and national regulations require not only the implementation of security policies, but real capability to:

• detect incidents,
• respond,
• report events.

In practice, sector reports regularly show that there is still a gap between meeting formal requirements and operational readiness. Most often, this concerns areas such as:

• central log analysis,
• event correlation,
• real-time incident visibility.

In this context, SIEM ceases to be just a technical tool – it becomes a component of building real operational capability.

Technical Details: Proxmox and Implementation Reality

Wazuh was implemented as a virtual machine in a Proxmox environment. Right from the start, a challenge appeared that teaches humility towards technology.

Implementation details: Wazuh as a VM in Proxmox.

Minimum Requirements Adopted in This Test Environment

This implementation used a starting configuration based on the resources visible in the environment screenshot. It is a practical reference point for a test environment, not a universal minimum for every production deployment.

• CPU: 4 vCPU
• RAM: 4 GiB
• Disk: approx. 40 GiB (39.08 GiB)
• SWAP: 512 MiB
• System: Debian (container/VM in Proxmox)

Wazuh is delivered in OVA format, which is not natively supported by Proxmox. This required manual disk conversion and CLI (Command Line Interface) import. This perfectly illustrates the difference between a "theoretical" and a real implementation – there is no "Next" button here, only architecture understanding.

The monitored environment included:

• 2 x Windows (different versions)
• 1 x Linux (Debian VM as a service server)

Network segmentation (VLAN) was applied to separate monitored traffic. This required configuring appropriate firewall rules – agents must have access to the server, but without opening unnecessary "doors" in the network.

Endpoint visibility – the foundation of asset control.

What Did the System Actually Show?

• Vulnerabilities: Even in a small, controlled environment, the system revealed many vulnerabilities, including high and critical ones.
• Updates: It was confirmed that a "fully updated system" is a myth. Some vulnerabilities result from dependencies, libraries, and configurations not always covered by the standard system update process.
• Visibility: It is clear which assets maintain reporting continuity and which require intervention to restore full observability (agent status).

Actual vulnerability exposure – this is where risk analysis begins.

Reality Check: Why Logs Alone Are Not Security

• logs ≠ security
• monitoring ≠ detection
• detection ≠ response
• response ≠ risk management

Only the combination of these elements provides real value.

ISO/IEC 27001 and ISO/IEC 27002 Perspective – Practical Implications

Thanks to this project, controls from the new version of the standard became more than just numbers:

• ISO/IEC 27001:2022: defines ISMS system requirements and organizational responsibility for the effectiveness of safeguards.
• ISO/IEC 27002:2022: clarifies implementation practices and how to implement and maintain controls.
• 8.15 (Logging): Excess data is noise. Selection is key – what we log to be able to reconstruct an incident without filling up disks.
• 8.16 (Monitoring activities): Without business context, monitoring is just blinking indicators. You need to know what is "normal."
• 8.8 (Management of technical vulnerabilities): Real SIEM visibility drastically shortens time-to-remediate.

The most important conclusion: monitoring is not about collecting data, but about making decisions based on risk context and response capability.

Auditor's "Aha!": Vulnerability Management

Experience from the project allowed audit questions to be refined so that they assess process effectiveness, not just the presence of a tool.

• Prioritization criteria: What formal criteria (CVSS, business context, asset exposure) determine the order of actions and where are they approved?
• Evidence of effectiveness: What metrics confirm process effectiveness (e.g., SLA adherence, exposure reduction trend, percentage of closed actions)?
• Exception management: What is the procedure when a vulnerability cannot be remediated within the required timeframe: who accepts the risk and what temporary safeguards are implemented?
• Closure and oversight: What does formal vulnerability closure look like and who approves it?

File Integrity Monitoring (FIM)

I tested monitoring of configuration file changes (e.g., in the `/etc/` folder on Linux and key branches of the Windows Registry).

The conclusion? The tool works brutally effectively – it will detect every change, but if you do not define what and why you are monitoring, you will drown in alerts after every system update.

My Test Environment vs. Reality

Summary

Implementing SIEM, even in a test environment, shows one key thing:
the difference between declared and actual security level.

In practice, it is not about whether the system exists, but:
whether the organization can detect events, interpret them, and take appropriate action.

This is the area that most often reveals the biggest gap between compliance and operational reality.

In practice, it is worth asking one question:
do we see incidents, or are we just collecting data?

Recommendations (Based on Recognized Practices)

• Link SIEM to risk: every critical rule and alert should have an assigned risk owner and a defined response time (ISO/IEC 27001:2022, NIST CSF 2.0).
• Establish a minimum set of security KPIs: mean time to detect (MTTD), mean time to respond (MTTR), percentage of critical vulnerabilities closed within SLA, and month-to-month exposure trend.
• Periodic control effectiveness reviews: quarterly review of logging quality, detection rules, and false positives (ISO/IEC 27002:2022).
• Process-based vulnerability management: identification, analysis, prioritization, remediation or mitigation, verification, and formal closure – in line with NIST SP 800-40r4 and ISO/IEC 27002:2022 control 8.8.
• Build organizational resilience, not just compliance: combine monitoring with risk management, business continuity planning, and periodic control effectiveness reviews, according to current NIST and ENISA guidance.

Sources and Reference Documents

• ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements.
• ISO/IEC 27002:2022 - Information security, cybersecurity and privacy protection - Information security controls.
• NIST Cybersecurity Framework (CSF) 2.0.
• NIST SP 800-40r4 - Guide to Enterprise Patch Management Planning.
• NIST SP 800-61 - Computer Security Incident Handling Guide (methodological reference).
• ENISA guidance and good practices for incident response and vulnerability management.
• ENISA Threat Landscape (latest editions) – overview of threat trends and security practice maturity.
• Verizon Data Breach Investigations Report (DBIR, latest editions) – analysis of real incidents and attack patterns.
• Mandiant M-Trends (latest editions) – operational observations on incident detection and response.