The objective of this lab is to gain hands-on experience as a SOC Analyst by building a cloud-based environment in Azure. I deployed a vulnerable VM as a honeynet, set up logging and monitoring with Log Analytics and Azure Sentinel, and then applied NIST security controls to harden the environment. The goal was to compare security metrics before and after hardening to see how effective those controls actually are.
| Tool | Purpose |
|---|---|
| Microsoft Azure | Cloud platform hosting the entire lab |
| Azure Sentinel | SIEM — threat detection, alert rules, and incident management |
| Log Analytics Workspace | Central hub for ingesting and querying logs |
| Microsoft Defender for Cloud | Cloud security monitoring and alerts |
| Azure Active Directory | Identity and access management |
| SSMS (SQL Server Management Studio) | Managing the SQL database on the Windows VM |
| SQL Server Evaluation | Database running on the honeynet to attract attackers |
| KQL (Kusto Query Language) | Writing queries to analyze log data |
| NIST 800-53 | Security controls framework used to harden the environment |
| Incident Response Playbook | Structured response process for handling incidents |
- Setting up and managing cloud environments in Azure
- Deploying and running a honeynet with live traffic
- Windows and Linux server administration
- Log management and analysis (AAD, Management Plane, Data Plane)
- Using Azure Sentinel for threat detection and incident management
- Writing KQL queries to investigate security events
- Implementing NIST 800-53 security controls and hardening an environment
- Comparing security metrics to measure the impact of hardening
In this lab, I created two virtual machines — one running Windows and the other running Linux. I set up a honeynet with live traffic, intentionally making the Windows VM vulnerable by disabling its firewalls and creating a SQL database inside it. The idea was to attract attackers to target both the SQL database and the Windows machine itself. The Linux machine serves as an additional logging point so I could capture data from potential attackers.
All of this is hosted in Azure. The arrows in the diagram below point to the Log Analytics Workspace, where logs from AAD/Tenant Logs, Management Plane Logs, and Data Plane Logs are all being ingested. From there, I configured Azure Sentinel to reference the Log Analytics Workspace, which let me create attack maps and incidents based on the collected data.
To wrap up the lab, I compared metrics from the unsecured environment over 24 hours against a secured environment 24 hours after implementing NIST 800-53 security controls.
These are the metrics I captured over a 24-hour period with the environment completely open and unsecured.
| Metric | Count |
|---|---|
| Start Time | 8/19/2024 20:24:06 |
| Stop Time | 8/20/2024 20:24:06 |
| Security Events (Windows VMs) | 19,284 |
| Syslog (Linux VMs) | 7,862 |
| SecurityAlert (Microsoft Defender for Cloud) | 8 |
| SecurityIncident (Sentinel Incidents) | 234 |
| NSG Inbound Malicious Flows Allowed | 268 |
These maps show where the attacks were coming from while the environment was left open.
I configured 14 different rules in Microsoft Sentinel to trigger alerts and generate incidents.
One of the incidents I found was a successful brute force attack on my Windows VM originating from Iran.
After applying NIST 800-53 security controls and hardening the system, I captured metrics for another 24 hours. All map queries came back with no results — there were zero instances of malicious activity detected after hardening.
| Metric | Count |
|---|---|
| Start Time | 8/24/2024 21:27:55 |
| Stop Time | 8/25/2024 21:27:55 |
| Security Events (Windows VMs) | 9,538 |
| Syslog (Linux VMs) | 1 |
| SecurityAlert (Microsoft Defender for Cloud) | 0 |
| SecurityIncident (Sentinel Incidents) | 0 |
| NSG Inbound Malicious Flows Allowed | 0 |
| Metric | Change After Securing |
|---|---|
| Security Events (Windows VMs) | -50.54% |
| Syslog (Linux VMs) | -99.99% |
| SecurityAlert (Microsoft Defender for Cloud) | -100% |
| SecurityIncident (Sentinel Incidents) | -100% |
| NSG Inbound Malicious Flows Allowed | -100% |
The results speak for themselves. After applying security controls, malicious traffic dropped to zero across the board — no alerts, no incidents, and no malicious flows allowed through the NSGs. Windows security events were cut in half, and Linux syslog entries dropped from nearly 8,000 down to 1.
Justin IT Professional
Last Updated: August 2024