Stage IV - Secure Cloud Configuration

Current network topology (via Network Watcher) before securing the environment

Implementing Security Controls

The MDC Security Score for the environment before hardening the environment:

Recommendations:

Enabling Regulatory Compliance (NIST 800-53) in MDC

Adding NIST 800-53: Security and Privacy Controls for Information Systems and Organizations to Microsoft Defender for Cloud. Full Publication.

To add NIST 800-53, from the MDC home page click Regulatory Compliance from the left blade > Manage compliance policies

Select the environment scope you want to add the regulations to, I'm adding at the subscription level.

Security Policies > Toogle NIST 800-53 Rev 5

It takes some time for the policy to add, after several hours it should appear in your MDC, under Regulatory Compliance

Implementing NIST 800-53 SC-7 Boundary Protection

Overview of System and Communications Protection, Section 7: Boundary Protection in MDC

Currently, our storage account, key vault and virtual machines are on the public internet - and that's bad. To fix this we're going to apply a network security group to the environment at the subnet level. We're also going to enable private endpoints and firewalls on the storage account and the key vault to disable access from the public internet and make them accessible only from the (new) subnet.

Enable Firewall on Azure Key Vault

AKV > Networking > Firewalls and virtual networks > Disable public access > Apply

Enable Private Endpoint on Azure Key Vault

AKV > Networking > Private endpoint connections > Create

Make sure the endpoint is in the same region as the other resources

Enable Firewall on Azure Storage Account

Storage Account > Networking > Firewalls and virtual networks > Public network access > Disabled > Save

Check endpoint creation in Windows VM

Resolves to private IP

Enable Private Endpoint on Azure Storage Account

Storage Account > Networking > Private endpoint connections > Private endpoint

Check endpoint creation in Windows VM

Resolves to private IP. You can see both AKV and SA are on the same network as the Windows VM.

Update Network Security Group Configuration

Create a network security group and attach to our subnet. It won't have any rules, but it satisfies the NIST 800-53 requirement to have a NSG attached to our subnet.

To attach to our subnet, Virtual Networks > Select Network > Subnets > Select Subnet > Select NSG > Save

Update VM NSGs

Update the VM NSGs to remove rules exposing them to the public internet and add a rule only allowing traffic from your IP address(es)

windows-vm-nsg

linux-vm-nsg

Turn on Windows VM Firewall

This may be redundant given the NSG change, but just in case.

I also applied available updates to the VM.

Architecture After Hardening / Security Controls

Attack Maps After Hardening / Security Controls

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

NSG Allowed Malicious Inbound Flows

Linux SSH Authentication Failures

Windows RDP/SMB Authentication Failures

MS SQL Server Authentication Failures

Metrics After Hardening

To collect the metrics for the secured environment, Network Security Groups were hardened by blocking ALL traffic (with the exception of my workstation), and built-in firewalls enabled. Azure Key Vault and Storage Container were protected by disabling access to public endpoints and replacing them with private endpoints.

The following table shows the measurements taken after applying the security controls the environment and observing for another 24 hours:
Start Time: 1/26/2024 19:10:14
Stop Time: 1/27/2024 19:10:14

Impact of Security Controls

MDC Security Score after Hardening

Since this was a lab, I did not address every recommendation in Microsoft Defender for Cloud, but just a a few under SC-7 as a proof of concept. The MDC Security Score for the environment after hardening the environment: