Why was this project created? (Practical perspective)
In GRC, it is easy to become a theorist. Standards can be memorized, but without understanding how data really flows across systems, audits become superficial. This project was created to answer practical questions:
- How SIEM implementation actually looks from an operational perspective.
- What data is truly collected and how it translates into risk.
- What delivers measurable security value versus what remains documentation-only good practice.
Technical setup: Proxmox and implementation reality
Wazuh was deployed as a virtual machine in a Proxmox environment. The setup immediately exposed a practical challenge.
Implementation view: Wazuh as a VM in Proxmox.
Minimum requirements used in this LAB
This implementation used an initial configuration based on the visible lab setup. It is a practical reference point for a small lab, not a universal production baseline.
- 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 import. It clearly shows the difference between a theoretical setup and a real implementation: there is no simple "Next" button, only architecture understanding.
The monitored environment included:
- 2 x Windows endpoints (different versions)
- 1 x Linux (Debian VM as a service host)
Network segmentation (VLAN) was applied to separate monitored traffic. This required explicit firewall rules: agents needed access to the server without opening unnecessary network exposure.
Endpoint visibility as a foundation of asset control.
What did the system actually reveal?
- Vulnerabilities: Even in a small controlled environment, the platform identified multiple vulnerabilities, including high and critical findings.
- Updates: The common belief that a "fully updated" system is always safe proved inaccurate. Some issues come from dependencies, libraries, and configurations not fully covered by routine updates.
- Visibility: The status clearly showed which assets maintained reporting continuity and which required intervention to restore observability.
Actual vulnerability exposure as a starting point for risk analysis.
ISO/IEC 27001 and ISO/IEC 27002 perspective: practical implications
Through this project, controls from the updated standards became practical rather than theoretical references:
- ISO/IEC 27001:2022: defines ISMS requirements and organizational accountability for control effectiveness.
- ISO/IEC 27002:2022: clarifies implementation practices and operational maintenance of controls.
- 8.15 (Logging): Data volume without curation becomes noise. Selection discipline matters for incident reconstruction and storage sustainability.
- 8.16 (Monitoring activities): Monitoring without business context becomes dashboard activity rather than decision support.
- 8.8 (Management of technical vulnerabilities): Practical SIEM visibility materially reduces time to remediate.
Key takeaway: monitoring is not only about collecting data. It is about decisions: what is accepted risk and what requires immediate action.
Audit "Aha": vulnerability management
Hands-on implementation helped refine audit questions to assess process effectiveness, not only tool presence.
- Prioritization criteria: Which formal criteria (CVSS, business context, asset exposure) drive remediation order, and where are those criteria approved?
- Effectiveness evidence: Which metrics confirm process performance (for example SLA adherence, exposure reduction trend, and closure rate)?
- Exception handling: How is action taken when a vulnerability cannot be remediated within the required timeline: who accepts the risk and which temporary safeguards are implemented?
- Closure and oversight: How is formal vulnerability closure performed and who provides final approval?
File Integrity Monitoring (FIM)
Monitoring of configuration file changes was tested (for example `/etc/` on Linux and selected Windows Registry branches).
The practical conclusion is direct: the mechanism detects changes reliably, but without clear scoping of what is monitored and why, alert fatigue appears quickly after routine updates.
Comparative Summary: LAB and business
| Aspect | Home Lab (Practical workshop) | Organization (Enterprise) |
|---|---|---|
| Goal | Understand technology and implementation mechanics. | Manage risk and preserve business continuity. |
| Scale | Small (selected operating systems and VMs). | Large (complex infrastructure, multiple platforms, including OT and cloud). |
| Compliance | In a small lab, full control depth may be disproportionate to risk but still valuable for learning. | In organizations, this supports key Statement of Applicability controls and active vulnerability reduction. |
| Response | Optional and educational. | Critical due to continuity, risk ownership, and compliance obligations. |
Summary
SIEM implementation in a small laboratory setup may be disproportionate to the environment risk profile, but it provides a high-value result: authentic understanding of defensive mechanisms.
From an audit and security perspective, the core point is not whether tooling exists, but whether signals are interpreted correctly and translated into concrete actions.
Recommendations (based on recognized practices)
- Connect SIEM to risk ownership: each critical rule and alert should have an assigned risk owner and a defined response timeline (ISO/IEC 27001:2022, NIST CSF 2.0).
- Define a minimum security KPI set: MTTD, MTTR, percentage of critical vulnerabilities resolved within SLA, and month-to-month exposure trend.
- Run periodic control effectiveness reviews: quarterly review of logging quality, detection rules, and false positive rates (ISO/IEC 27002:2022).
- Apply process-based vulnerability management: identification, analysis, prioritization, remediation or mitigation, verification, and formal closure aligned with NIST SP 800-40r4 and ISO/IEC 27002:2022 control 8.8.
- Build resilience, not only compliance: integrate monitoring with risk management, continuity planning, and recurring 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.
Q&A: Most common questions
What is a vulnerability?
A vulnerability is a weakness in a system, application, configuration, or process that can be exploited to compromise confidentiality, integrity, or availability. A vulnerability alone is not an incident, but it increases risk exposure.
What is the difference between ISO/IEC 27001 and ISO/IEC 27002?
ISO/IEC 27001 defines requirements for an Information Security Management System (ISMS) and is certifiable. ISO/IEC 27002 is a good-practice guide explaining how to implement and maintain security controls.
What does VM mean in a security context?
In security, VM commonly means Vulnerability Management. It is a continuous process that includes identification, assessment, prioritization, mitigation, and verification.
What does VM mean in a virtualization context?
In infrastructure, VM means Virtual Machine, an isolated environment running on a hypervisor. Each VM behaves like an independent operating system with logical resources (CPU, RAM, storage, network), which supports segmentation, testing, and controlled deployments.
How are vulnerabilities classified?
A common high-level scale is Low, Medium, High, and Critical. Many teams also use CVSS (Common Vulnerability Scoring System), which scores software and hardware weaknesses from 0.0 to 10.0. Mature organizations combine technical scoring (CVSS) with business context, asset exposure, exploit availability, and remediation SLA.