Identity and Network Security Project - Wardenix

The problem

Identity is the new perimeter, and most organisations treat it like an afterthought. Conditional Access policies are either absent, too broad to be effective, or configured by clicking through a portal without any underlying threat model. Endpoints sit unmonitored. Network traffic is logged but not analysed. And when an incident does occur, the response is manual, slow, and inconsistent because no runbook exists and no automation has been built.

For security practitioners trying to build real skills in this space, the problem compounds. The tools that matter - Entra ID P2, Microsoft Sentinel, Defender XDR, Shuffle SOAR - require a live environment to learn properly. A lab that simulates nothing teaches nothing. Wardenix is a fully operational security environment: real identities, real attacks, real detections, and real automated response, built entirely from scratch by one engineer.

What Wardenix does

Wardenix provisions a simulated organisation on Microsoft Entra ID - 26 user accounts across departments, 11 dynamic groups, and a full Conditional Access policy set - and subjects it to real adversary emulation using Metasploit. A Windows endpoint (Tiny10, network-isolated) is enrolled in Entra ID and placed under attack. The network detection layer runs Wazuh (HIDS/EDR), Suricata (NIDS), and FreeRADIUS on a DigitalOcean droplet. All security telemetry flows into Microsoft Sentinel and a Grafana Cloud dashboard. When Wazuh fires an alert, an 8-node Shuffle SOAR workflow triggers automatically, triaging the alert with Gemini AI, executing the response runbook, and generating a crisis communications draft.

Architecture

Wardenix runs across four logical layers. The identity layer is a Microsoft Entra ID tenant (Wardenix.onmicrosoft.com) hosting a 26-account simulated organisation with Entra ID P2 features - Conditional Access, PIM, Identity Protection, and Identity Governance. The endpoint layer is a network-isolated Windows VM (Tiny10) enrolled in Entra and used as the adversary emulation target. The network layer runs on a DigitalOcean droplet - Wazuh as the HIDS/EDR agent and manager, Suricata as the network IDS, and FreeRADIUS for authentication. The response layer connects everything: Sentinel ingests Entra and Defender signals, the Python forwarder ships Wazuh alerts to Log Analytics, Grafana Cloud provides the operational dashboard, and Shuffle SOAR automates the response workflow end-to-end.

The Wazuh forwarder (infra/wazuh_to_sentinel.py) runs on a cron every 15 minutes, shipping alerts to Log Analytics via the HTTP Data Collector API. The Shuffle SOAR workflow "Wardenix Risky Sign-in Response" is an 8-node graph - it fires on a Wazuh alert, calls Gemini for triage, executes the response steps, and commits a crisis communications draft. It took 21 build iterations to reach a stable end-to-end run.

Security decisions made

• Threat model before any configuration. A full STRIDE and MITRE ATT&CK threat model was completed across identity, endpoint, network, and AI response domains before writing a single line of configuration. This is not standard practice in lab projects - it is standard practice in production environments, and the discipline matters.
• Conditional Access validated with What If, not assumed. Each of the six CA policies was tested using Entra's What If analysis tool before being enabled. CA-05 (MFA on risky sign-ins) required P2 Identity Protection - it was not enabled until that licence was confirmed active. The BreakGlass Admin account is excluded from all policies to prevent lockout.
• PIM over standing privilege. Privileged roles are not permanently assigned. Wardenix uses Entra PIM for just-in-time access - roles are activated on request, time-limited, and require justification. The alternative - permanent Global Admin assignment - is the single most common identity misconfiguration in real environments.
• Network isolation for the adversary emulation target. The Tiny10 endpoint (wardenix-lab) is network-isolated before Metasploit runs. An attack that escapes the target and reaches the management network is not a lab finding - it is a lab failure. Isolation is the control.
• Wazuh credentials stored at chmod 600, not hardcoded. After the Wazuh API password was reset via rbac.db werkzeug scrypt, credentials were stored in /etc/wazuh-sentinel.env with 600 permissions - readable only by root, not embedded in the forwarder script. Hardcoded credentials in scripts are how real breaches start.
• Shuffle SOAR OpenSearch bug documented, not hidden. During setup, Shuffle's UI was unreachable due to an OpenSearch admin authentication failure - a known upstream Docker bug where the OPENSEARCH_INITIAL_ADMIN_PASSWORD environment variable path prints success without actually writing the correct hash. The fix required generating a bcrypt hash via hash.sh, patching internal_users.yml directly inside the container, and pushing the corrected config via securityadmin.sh. The full resolution is documented in the GitHub project page because future engineers will hit this bug, and they deserve a documented fix.
• AI triage as a workflow node, not a decision-maker. Gemini is the triage node in the Shuffle SOAR workflow as it assesses the alert and produces a recommendation. The IR runbook and crisis comms template are the outputs. A human analyst reviews before any external communication goes out.

Tech stack

Layer	Tool	Why this, not the alternative
Identity platform	Microsoft Entra ID P2	P2 unlocks PIM, Identity Protection, and Identity Governance, the features that matter in enterprise security engineering
Endpoint	Tiny10 (Windows 10 lite)	Full Windows environment at a fraction of the resource footprint, runs cleanly on a lab VM
Adversary emulation	Metasploit	Industry-standard framework; produces realistic, documented attack patterns against a real Windows target
HIDS / EDR	Wazuh 4.14.6	Open-source, production-grade; integrates with Sentinel via Log Analytics forwarder
NIDS	Suricata 8.0.6	High-performance network IDS; rule-based, community-maintained signatures
Authentication	FreeRADIUS 3.2.5	Open-source RADIUS, covers network authentication without vendor lock-in
SOAR	Shuffle SOAR (Docker)	Open-source; runs on any VM; integrates with Wazuh, Gemini, and external APIs without enterprise licensing
SIEM	Microsoft Sentinel	Cloud-native SIEM; native Entra and Defender connectors; KQL query language for hunting
Log forwarder	Python (HTTP Data Collector API)	Custom script gives full control over what gets forwarded and how - no black-box agent
Dashboard	Grafana Cloud	Free tier; connects to Log Analytics; 8-panel operational view across identity and network telemetry
AI triage	Gemini API	Free tier adequate for SOAR workflow integration; used as an assist node, not a decision authority
Identity provisioning	Microsoft Graph API	Programmatic user and group creation of 26 accounts and 11 dynamic groups provisioned via code, not portal clicks
Secret scanning	Gitleaks (CI gate)	Catches credentials before they enter the repository - applied in Phase 1, kept active throughout

Real-world context and application

Wardenix is applicable to any organisation running Microsoft 365 or Azure workloads that needs to move from basic security defaults to a properly engineered identity security posture. Specific scenarios:

• A growing startup that has outgrown Microsoft's Security Defaults and needs a structured Conditional Access policy set with documented threat modelling behind each policy
• A security team building an in-house SOC that needs a reference architecture for connecting Entra, Defender, Sentinel, and a SOAR platform without enterprise consulting fees
• A security engineer preparing for SC-500, SC-200, or similar Microsoft security certifications who needs a real environment rather than sandboxed lab exercises

What I learned

The most important lesson came in Phase 6. Building Conditional Access policies in a portal is straightforward. Building them correctly - with a documented threat model, tested with What If analysis, validated against real sign-in logs, and structured so that a BreakGlass Admin can always recover access - is an engineering problem. The difference between the two is the difference between a policy that looks right and a policy that works right.

The Shuffle SOAR OpenSearch authentication bug cost significant time and produced a finding that is now better documented than the upstream issue itself. The root cause - a Docker environment variable bootstrap path that reports success without actually writing the correct hash - is a class of failure that appears frequently in containerised security tools. The fix process sharpened my ability to diagnose authentication failures at the credential storage layer, not just the application layer.

The Wazuh indexer OOM-killed itself in Phase 10 - fixed with a 512m heap cap and a 2GB swap file. The lesson: memory management for security tooling on small VMs is not optional configuration. It is a prerequisite for stable operation, and it belongs in the architecture document, not the troubleshooting log.

Phase 11 - the Shuffle SOAR workflow - took 21 build iterations to reach a stable end-to-end run. This is not unusual for SOAR development. Every iteration produced a clearer understanding of where the workflow could fail silently, and the final runbook reflects all 21 iterations of that learning. A workflow that has never failed is a workflow that has never been tested properly.

The overarching lesson: identity security, endpoint security, network detection, SIEM integration, and automated response are not separate disciplines. They are one pipeline. Building all of them - end to end, in one project - produces a quality of understanding that no individual certification or isolated lab exercise can replicate.