[Cloud Honeynet / SOC]

In this project, I built a mini honeynet in Azure and ingested log sources from various resources into a Log Analytics workspace, which is then used by Microsoft Sentinel to build attack maps, trigger alerts, and create incidents. I measured some security metrics in the insecure environment for 24 hours, apply some security controls to harden the environment, measure metrics for another 24 hours, then show the results below. The metrics we will show are:

• SecurityEvent (Windows Event Logs)
• Syslog (Linux Event Logs)
• SecurityAlert (Log Analytics Alerts Triggered)
• SecurityIncident (Incidents created by Sentinel)
• AzureNetworkAnalytics_CL (Malicious Flows allowed into our honeynet)

[Architecture Diagram]

[Architecture Diagram]

The architecture and tools implemented in the mini honeynet in Azure consist of the following:

• Virtual Network (VNet)
• Network Security Group (NSG)
• Virtual Machines (2 windows, 1 linux)
• Log Analytics Workspace w/ Kusto Query Language
• Azure Key Vault
• Azure Storage Account
• Microsoft Sentinel (SIEM)
• Windows Defender for Cloud
• Azure PrivateLink
• NIST SP 800-53
• NIST SP 800-61

For the "BEFORE" metrics, all resources were originally deployed, exposed to the internet. The Virtual Machines had both their Network Security Groups and built-in firewalls wide open, and all other resources are deployed with public endpoints visible to the Internet; aka, no use for Private Endpoints.

For the "AFTER" metrics, Network Security Groups were hardened by blocking ALL traffic with the exception of my admin workstation, and all other resources were protected by their built-in firewalls as well as Private Endpoint

![NSG Allowed Inbound Malicious Flows]
![Linux Syslog Auth Failures]
![Windows RDP/SMB Auth Failures]

The following table shows the metrics we measured in our insecure environment for 24 hours: Start Time 2024-03-31 17:56:39 Stop Time 2024-04-01 17:56:39

All map queries actually returned no results due to no instances of malicious activity for the 24 hour period after hardening.

The following table shows the metrics we measured in our environment for another 24 hours, but after we have applied security controls: Start Time 2024-04-02 18:26:28 Stop Time 2024-04-03 18:26:28

• SecurityEvent: 73.42% Reduction
• Syslog: 99.98% Reduction
• SecurityAlert: 100% Reduction
• SecurityIncident: 100% Reduction
• AzureNetworkAnalytics_CL: N/A

To effectively manage high-priority incidents, I followed the guidelines of NIST 800-61 (Revision 2) and applied the security measures outlined in NIST SP 800-53 (Revision 5). The strategy included:

• Preparatory steps involved setting up a log analytics workspace, configuring Azure Sentinel, and creating alerts for detecting incidents. Implementing security measures from NIST SP 800-53 (Revision 5) was key to establishing a secure and resilient framework.
• Upon the occurrence of incidents, I evaluated their severity by categorizing them and then conducted in-depth investigations into the logs to separate false alarms from genuine threats. This process was informed by the incident response protocols in NIST 800-61 (Revision 2), which helped in understanding the extent of the impact.
• For a more efficient response to incidents, I utilized an incident response playbook that was in line with NIST 800-61 (Revision 2), ensuring detailed documentation of the incident specifics. This was supported by the appropriate application of security controls from NIST SP 800-53 (Revision 5) during the incident handling activities.
• After resolving each incident, I carried out detailed documentation of the findings, actions taken, and analyses conducted. The conclusion of this process included specifying the resolution and any required subsequent actions, all while adhering to the security controls specified in NIST SP 800-53 (Revision 5).

In this project, a mini honeynet was constructed in Microsoft Azure and log sources were integrated into a Log Analytics workspace. Microsoft Sentinel was employed to trigger alerts and create incidents based on the ingested logs. Additionally, metrics were measured in the insecure environment before security controls were applied, and then again after implementing security measures. It is noteworthy that the number of security events and incidents were drastically reduced after the security controls were applied, demonstrating their effectiveness.

It is worth noting that if the resources within the network were heavily utilized by regular users, it is likely that more security events and alerts may have been generated within the 24-hour period following the implementation of the security controls.