Building a Homelab Security Monitoring Platform

Project date: 2026-08-26 Role: Architecture, implementation, validation and operation

A detection and investigation platform combining Wazuh, Microsoft 365 audit data, CrowdSec, MISP and a least-privilege SOC portal.

Environment and operating context

#

The homelab includes externally reachable services, Kubernetes workloads, personal endpoints and Microsoft 365 activity. Security-relevant evidence therefore existed across network logs, endpoint agents, cloud audit events and specialist platforms. The project created one operational model without pretending that every alert represented a confirmed incident.

Objective

#

The goal was to detect meaningful behaviours, retain evidence for investigation, support threat-intelligence lookup and expose a concise SOC view without introducing unapproved automated response.

Operational value and risk reduction

#

Before: Endpoint, cloud-audit, behavioural and threat-intelligence evidence existed in separate tools without one validation and presentation model.

After: Wazuh, CrowdSec, MISP and LIP provide an integrated detection and investigation path with nine tested local rules.

Risk reduced: High-value Microsoft 365 activities and disconnected endpoints are visible sooner, while least-privilege readers prevent the portal from becoming a response or administration channel.

Architectural decisions and alternatives

#

Wazuh alone

Provides SIEM and endpoint capability, but does not replace distributed behavioural enforcement or analyst threat-intelligence workflows.

CrowdSec alone

Strong for behavioural blocking, but not an endpoint and Microsoft 365 detection platform.

Automatic response from the portal

Could reduce response time, but creates unacceptable risk without approval, rollback and audit controls.

Selected design

Wazuh for endpoint and cloud detections, CrowdSec for shared behavioural decisions, MISP for analyst enrichment, and LIP as a read-only summary layer.

Technical challenges

#

Wazuh Manager and Indexer required separate access models. Microsoft 365 events needed local rule logic and reproducible tests. Internal certificates lacked the service DNS identities used by Kubernetes. Alert volume also required clear severity and evidence boundaries so that thousands of rule matches did not become thousands of claimed incidents.

Proposed solution

#

Wazuh Manager master and worker components collect and process data, while the Indexer stores searchable alerts and the Dashboard remains authoritative for detailed analysis. CrowdSec centralises behavioural decisions and supplies the Cloudflare Worker bouncer. MISP Core and Modules provide analyst-operated enrichment. LIP consumes bounded read-only summaries.

Detection engineering

#

The local catalogue contains one pipeline-validation rule and eight Microsoft 365 behavioural detections. Richard implemented and owns the catalogue. Some concepts were adapted from pinned SOCFortress material; others were developed locally with AI-assisted research. Every adopted rule was placed in the local rule-ID scheme and supported by documentation, positive fixtures, negative fixtures and expected-result files.

Fixtures use a mixture of sanitised event structures and synthetic validation data. This provides repeatable tests without publishing raw production events. Rule matches are described as evidence requiring investigation, not proof of malicious activity.

Security controls

#

• Separate read-only Wazuh Manager and Indexer identities
• Indexer search limited to alert indices
• All-index access tested and denied
• SOPS-encrypted connector credentials
• NetworkPolicy limited to Wazuh API and Indexer ports
• No active-response permissions in LIP
• MISP enrichment remains analyst-operated
• Source data and rule descriptions separated from analyst conclusions

Validation and measurable outcomes

#

The 4,312-alert figure is a dated observation, not a permanent KPI. Validation also confirmed that Wazuh Dashboard, Indexer, Manager master, Manager worker, CrowdSec LAPI, the Cloudflare bouncer and four MISP components were ready.

Outcome

#

Security monitoring now has an evidence-led workflow rather than a collection of unconnected dashboards. Endpoint state, Microsoft 365 detections, behavioural enforcement and threat-intelligence lookup are available through defined boundaries, while disruptive action stays in the authoritative platforms.

Skills demonstrated

#

• Wazuh deployment and RBAC
• OpenSearch index permissions
• Microsoft 365 audit ingestion
• Detection engineering and fixtures
• CrowdSec architecture
• MISP integration
• TLS troubleshooting
• SOC interface and triage design

Lessons learned

#

Detection ownership includes provenance and testing. Adapting an upstream concept is professional when the source is pinned, local behaviour is understood and both positive and negative cases are tested.

Current status and next steps

#

Operational. The platform remains detection and investigation focused. Automated response is deliberately excluded until narrow actions, human approval and audit controls are designed.

Explore the implementation

#

Browse the public security runbooks.

How it was done

#

1. Defined the evidence sources. Endpoint and host data were assigned to Wazuh, behavioural service activity to CrowdSec, Microsoft 365 activity to unified audit ingestion, and threat-intelligence lookup to MISP.
2. Deployed the Wazuh stack. Manager master and worker StatefulSets, the Indexer and Dashboard were installed and validated as separate but connected components.
3. Enrolled endpoints. Agents were added and monitored for active and disconnected state. The final evidence snapshot contained eight enrolled endpoints, seven active and one disconnected.
4. Connected Microsoft 365 telemetry. Protected credentials were supplied through SOPS-encrypted Secrets and audit events entered the Wazuh processing pipeline.
5. Built the detection catalogue. One pipeline-validation rule and eight operational Microsoft 365 detections were assigned local rule IDs. Some concepts were adapted from pinned SOCFortress material and others were developed locally with AI-assisted research.
6. Created repeatable tests. Positive fixtures, negative-operation fixtures, negative-result fixtures and expected-result files were added using a mixture of sanitised event structures and synthetic test data.
7. Deployed CrowdSec and MISP. CrowdSec LAPI centralised behavioural decisions for connected agents and bouncers. MISP Core and Modules were deployed for analyst-operated enrichment.
8. Created least-privilege portal identities. Separate Wazuh Manager and Indexer readers were limited to the data required by LIP. Unrelated Indexer catalogue access was tested and denied.
9. Restricted network access. Portal egress was limited to Wazuh Manager port 55000 and Indexer port 9200. No active-response permissions were provided.
10. Validated the live SOC view. The production API returned Wazuh 4.14.7, endpoint status, 4,312 alerts in the observed 24-hour window, ten recent alerts and nine custom-rule matches.

Evidence methodology

#

The figures in this case study were derived from reproducible source and runtime checks rather than estimates.

1. Endpoint and alert measurements came from the production Wazuh Manager and Indexer through the read-only SOC API.
2. Each custom rule has source, documentation, positive fixtures, negative fixtures and expected-result files in Git.
3. Least privilege was tested by allowing required Wazuh alert searches while denying unrelated all-index access.

Limitations and residual risks

#

• Alert volume is not equivalent to incident count.
• One endpoint was disconnected in the evidence snapshot and requires interpretation, not an automatic compromise conclusion.
• MISP enrichment remains analyst-operated.
• Some rule concepts originated upstream and are locally adapted rather than all being original from first principles.

Plain-English glossary

#

SIEM

A platform that collects, searches and correlates security event data.

Detection fixture

A controlled example event used to prove that a rule should or should not match.

LAPI

CrowdSec Local API, the central service that distributes decisions to connected components.

Independent validation

#

This was a self-directed engineering project rather than a client engagement. Credibility is established through deployed configuration, source history, successful builds, operational measurements, restoration tests and repeatable validation rather than a client testimonial.