How to Build a Practical SOC Lab with Wazuh, Microsoft Sentinel and Azure Arc
A small, well-governed lab can give IT teams hands-on experience with endpoint telemetry, centralised logging, hybrid-cloud monitoring, alert engineering and incident investigation without exposing production systems.
A security operations centre is not created by licensing a SIEM. It is created when people can collect trustworthy telemetry, recognise suspicious patterns, investigate context, contain activity and communicate the result.
A practical SOC lab provides the controlled environment needed to build those capabilities. It can start with one Windows endpoint, one Linux server and one central monitoring platform, then grow into a hybrid environment using Microsoft Sentinel, Azure Monitor, Microsoft Defender for Cloud and Azure Arc.
The design should remain simple enough to operate, isolated enough to be safe and observable enough to produce evidence.
Article contents
Define the SOC objectives before deploying tools
The smallest useful SOC lab should support five operational outcomes:
- Collect Windows and Linux logs
- Capture high-value endpoint telemetry
- Generate approved suspicious activity
- Create and tune alerts
- Investigate and document incidents
- Validate remediation
Do not begin by enabling every available connector. Start with a defined use case such as failed sign-ins, suspicious PowerShell, unauthorised group membership changes, unusual outbound connections or malware-like process behaviour.
Use a segmented reference architecture
The lab should separate administration, monitored targets, the SOC platform and attacker simulation systems.
Internet
|
[Lab Firewall/Router]
|
+-------------------+-------------------+
| | |
MGMT VLAN TARGET VLAN SOC VLAN
| | |
Admin workstation Windows Server Wazuh Server
Hypervisor console Windows 11 Log collector
Backups Ubuntu Server Analysis tools
|
Approved test activity
|
ATTACK VLAN
|
Kali Linux
Azure subscription
|
Log Analytics Workspace
Microsoft Sentinel
Defender for Cloud
Azure Arc-enabled lab servers
The attack segment should reach only designated targets. The management network should contain trusted administrative systems. The SOC network should receive telemetry but should not be exposed as an ordinary user network.
Build the telemetry pipeline deliberately
A useful SOC lab should collect enough data to reconstruct activity across identity, endpoint, network and cloud layers.
| Source | Telemetry | Primary use |
|---|---|---|
| Windows Security log | Sign-ins, account changes, group membership, policy events | Identity and privilege monitoring |
| Sysmon | Process creation, network connections, file and registry activity | Endpoint detection and investigation |
| PowerShell logs | Script blocks, module use and command execution | Suspicious administration and attack detection |
| Linux authentication logs | SSH access, privilege use and failed authentication | Linux account monitoring |
| Web-server logs | Requests, response codes, source IPs and paths | Application and access investigations |
| Firewall and DNS logs | Connections, blocks, destinations and name resolution | Network context and threat hunting |
| Azure activity and sign-in logs | Resource changes, role assignments and identity events | Cloud and identity governance |
Sysmon is particularly useful because it adds detailed Windows activity that standard event logs may not capture at the same depth. Send the resulting events to Wazuh, Microsoft Sentinel or both, depending on the exercise.
Divide responsibilities between Wazuh and Microsoft Sentinel
Wazuh
Use it for self-hosted endpoint agents, log collection, file-integrity monitoring, inventory, configuration assessment and lower-cost local exercises.
Microsoft Sentinel
Use it for Azure-native analytics, Kusto Query Language, cloud and hybrid ingestion, analytics rules, workbooks, automation and Defender integration.
Security Onion
Add it when packet capture and network security monitoring become core learning objectives and sufficient hardware is available.
Defender for Cloud
Use it for posture and workload-protection exercises across supported Azure and hybrid resources.
The platforms do not need to compete. Wazuh can provide an economical local monitoring foundation while Sentinel introduces cloud-native hunting, workbooks and Microsoft security integration.
Microsoft is moving Sentinel operations toward the Microsoft Defender portal, and Sentinel support in the Azure portal is scheduled to end after 31 March 2027. Build current exercises with that transition in mind.
Create realistic detections and investigation exercises
Start with scenarios that can be generated safely and explained clearly:
- Repeated failed sign-ins from one source
- Password spraying across several accounts
- Suspicious PowerShell execution
- Creation of a new service or scheduled task
- Unexpected local administrator membership
- Unusual outbound connections
- Port scanning against a designated target
- Modification of monitored files
Every exercise should produce:
- Detection query or rule
- Alert logic and threshold
- False-positive analysis
- Incident timeline
- Affected asset list
- Containment action
- Remediation recommendation
- ATT&CK mapping
An alert is not an answer. The analyst still needs to validate the sequence of events, affected assets, business context and potential impact.
Extend the lab with Azure Arc
Azure Arc-enabled servers allow selected non-Azure systems to be represented and managed as Azure resources. In a lab, this creates a practical bridge between on-premises virtual machines and cloud security services.
Suggested hybrid sequence
- Create a dedicated Azure resource group.
- Configure tags and a small monthly budget.
- Enable a Log Analytics workspace.
- Deploy Microsoft Sentinel.
- Connect one approved Windows or Linux lab server through Azure Arc.
- Enable only the required data collection rules.
- Validate events in Azure Monitor and Sentinel.
- Create one hybrid analytics rule and investigation workbook.
Do not connect malware-analysis machines, disposable attack systems or intentionally compromised hosts to a real production tenant.
Control cloud cost before deployment
- Create a dedicated lab resource group.
- Set a small monthly budget.
- Add alerts at 50%, 80% and 100%.
- Use low-cost VM sizes.
- Deallocate virtual machines after each exercise.
- Delete unused disks, public IP addresses and snapshots.
- Tag resources with
Environment=Lab. - Review cost daily during active training.
- Delete the full resource group when the project ends.
Apply governance and evidence standards
A professional lab should produce reviewable technical evidence, not only screenshots.
- Architecture diagram
- Data-flow diagram
- Build and rollback procedure
- Configuration exports
- Detection rules and queries
- Sanitised log samples
- Incident report
- Remediation and retest result
- Cost record
- Lessons learned
Do not publish credentials, access tokens, API keys, personal information, unredacted client data, tenant identifiers where inappropriate or dangerous exploit instructions against real systems.
The lab becomes valuable when another professional can review what was built, understand how it was tested and reproduce the result.
Build a practical SOC capability programme
Skunkworks can help organisations design segmented cyber labs, deploy Microsoft Sentinel and Azure Arc, integrate Windows and Linux telemetry, develop detection content and deliver practical SOC and cloud-security training.
Discuss a SOC lab programme
No comments:
Post a Comment