Comprehensive Server Hardening Checklist for Windows and Azure Environments

Step 1: Initial Assessment and Baseline Establishment

Before implementing any hardening measures, it is crucial to understand your current security posture and define a secure baseline. This step involves identifying existing vulnerabilities, documenting current configurations, and establishing a benchmark against industry-recognized standards to measure improvement.

While this step primarily involves planning and documentation, you can use PowerShell to inventory installed roles and features, which helps in identifying unnecessary components for later removal.

Get-WindowsFeature | Where-Object {$_.Installed -eq $true} | Select-Object Name,DisplayName | Format-Table -AutoSize

Get-WindowsFeature: Retrieves information about Windows roles and features installed or available.

Where-Object {$_.Installed -eq $true}: Filters the results to show only features that are currently installed.

Select-Object Name,DisplayName: Selects the internal name and user-friendly display name of the features.

Format-Table -AutoSize: Displays the output in a formatted table, automatically adjusting column widths.

Portal alternative: In Windows Server Manager, navigate to 'Manage' > 'Remove Roles and Features' to see an interactive list of installed components.

Expected result: A clear inventory of installed Windows features, which can then be compared against a defined secure baseline, such as those provided by CIS Benchmarks for Microsoft Windows Server. This baseline will guide subsequent hardening efforts.

Step 2: Operating System Hardening

Reducing the attack surface of your Windows Server operating system is foundational. This involves disabling unnecessary services, securing critical configurations, and enabling advanced protective features to prevent exploitation.

Disable Unnecessary Services and Features

Every running service or installed feature represents a potential entry point for attackers. Follow the principle of least functionality by removing or disabling anything not explicitly required for the server's role.

# Remove unnecessary Windows Features (example: graphical shell for server core)
Remove-WindowsFeature Server-Gui-Shell -Restart

# Disable a specific service
Set-Service -Name "Fax" -StartupType Disabled
Stop-Service -Name "Fax"

Remove-WindowsFeature: Uninstalls specified Windows roles or features.

-Restart: Initiates a restart if required to complete the feature removal.

Set-Service: Modifies the properties of a service.

-Name "Fax": Specifies the service to modify by its name.

-StartupType Disabled: Configures the service to not start automatically.

Stop-Service -Name "Fax": Stops the running instance of the specified service.

Portal alternative: Use Server Manager > 'Manage' > 'Remove Roles and Features' to remove features. For services, open 'services.msc', right-click a service, go to 'Properties', and set 'Startup type' to 'Disabled'.

Expected result: A lean server environment with only essential roles and services running, significantly reducing the potential attack surface.

Implement Windows Defender Application Control (WDAC)

WDAC enforces code integrity policies, allowing only approved applications to run. This is a powerful whitelisting mechanism that prevents unauthorized executables, scripts, and DLLs from running, even if an attacker gains a foothold.

# Create a new WDAC policy based on installed applications
New-CIPolicy -FilePath ".\WDAC_Policy.xml" -Level Publisher -UserPEs -ScanPath C:\

# Set policy options (e.g., Audit Mode first, then Enforcement)
Set-RuleOption -FilePath ".\WDAC_Policy.xml" -Option 3 # Audit Mode
Set-RuleOption -FilePath ".\WDAC_Policy.xml" -Option 9 # Unsigned SystemDrives

# Convert the XML policy to binary format
ConvertFrom-CIPolicy -FilePath ".\WDAC_Policy.xml" -BinaryFilePath ".\WDAC_Policy.bin"

# Deploy the policy (requires reboot)
Copy-Item ".\WDAC_Policy.bin" C:\Windows\System32\CodeIntegrity\CiPolicies\Active\{GUID}.cip
# The GUID can be generated randomly or derived from the policy ID

New-CIPolicy: Generates a new code integrity policy XML file.

-FilePath: Specifies the output path for the XML policy file.

-Level Publisher: Creates rules based on the publisher certificate of applications (stronger than Hash or FileName).

-UserPEs: Includes rules for executables used by users.

-ScanPath C:\: Scans the specified path to identify applications to include in the policy.

Set-RuleOption: Modifies rule options within a WDAC policy.

-Option 3: Sets the policy to Audit Mode, logging violations without blocking execution.

-Option 9: Allows unsigned boot/system files to load, useful for compatibility (can be removed for stricter policies).

ConvertFrom-CIPolicy: Converts the XML policy into a binary format required for deployment.

Copy-Item: Copies the binary policy to the system directory for activation.

Portal alternative: WDAC is primarily managed via PowerShell or Group Policy. There is no direct GUI for policy creation and deployment without third-party tools.

Expected result: A server where only explicitly approved applications can execute, dramatically limiting the impact of malware and unauthorized software. Start in Audit Mode to identify legitimate applications before enforcing.

Harden Transport Layer Security (TLS) Settings

Ensuring secure communication protocols by disabling outdated and vulnerable TLS/SSL versions is critical for protecting data in transit. Microsoft recommends disabling SSL 3.0, TLS 1.0, and TLS 1.1 in favor of TLS 1.2 and TLS 1.3 (where available and supported).

# Disable SSL 3.0 client and server
$ssl30Path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0"
New-Item -Path "$ssl30Path\Client" -ErrorAction SilentlyContinue | Out-Null
New-Item -Path "$ssl30Path\Server" -ErrorAction SilentlyContinue | Out-Null
New-ItemProperty -Path "$ssl30Path\Client" -Name "Enabled" -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$ssl30Path\Client" -Name "DisabledByDefault" -Value 1 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$ssl30Path\Server" -Name "Enabled" -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$ssl30Path\Server" -Name "DisabledByDefault" -Value 1 -PropertyType DWORD -Force | Out-Null

# Disable TLS 1.0 client and server
$tls10Path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0"
New-Item -Path "$tls10Path\Client" -ErrorAction SilentlyContinue | Out-Null
New-Item -Path "$tls10Path\Server" -ErrorAction SilentlyContinue | Out-Null
New-ItemProperty -Path "$tls10Path\Client" -Name "Enabled" -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls10Path\Client" -Name "DisabledByDefault" -Value 1 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls10Path\Server" -Name "Enabled" -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls10Path\Server" -Name "DisabledByDefault" -Value 1 -PropertyType DWORD -Force | Out-Null

# Disable TLS 1.1 client and server (if not needed for legacy apps)
$tls11Path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1"
New-Item -Path "$tls11Path\Client" -ErrorAction SilentlyContinue | Out-Null
New-Item -Path "$tls11Path\Server" -ErrorAction SilentlyContinue | Out-Null
New-ItemProperty -Path "$tls11Path\Client" -Name "Enabled" -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls11Path\Client" -Name "DisabledByDefault" -Value 1 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls11Path\Server" -Name "Enabled" -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls11Path\Server" -Name "DisabledByDefault" -Value 1 -PropertyType DWORD -Force | Out-Null

# Enable TLS 1.2 client and server (often enabled by default but ensure it)
$tls12Path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2"
New-Item -Path "$tls12Path\Client" -ErrorAction SilentlyContinue | Out-Null
New-Item -Path "$tls12Path\Server" -ErrorAction SilentlyContinue | Out-Null
New-ItemProperty -Path "$tls12Path\Client" -Name "Enabled" -Value 1 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls12Path\Client" -Name "DisabledByDefault" -Value 0 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls12Path\Server" -Name "Enabled" -Value 1 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path "$tls12Path\Server" -Name "DisabledByDefault" -Value 0 -PropertyType DWORD -Force | Out-Null

New-Item: Creates a new registry key.

New-ItemProperty: Creates a new registry property within a key.

-Path: Specifies the registry key path.

-Name "Enabled": Creates or modifies the 'Enabled' DWORD value.

-Value 0: Sets the value to 0, disabling the protocol.

-Value 1: Sets the value to 1, enabling the protocol.

-PropertyType DWORD: Specifies the data type of the registry value.

-Force: Overwrites the value if it already exists.

-ErrorAction SilentlyContinue: Suppresses errors if the key already exists.

Portal alternative: This is primarily a registry-based configuration. While you can use `regedit.exe`, managing these settings via Group Policy Objects (GPOs) is the recommended centralized method.

Expected result: All network communications originating from or terminating at the server use modern, secure TLS versions, protecting against eavesdropping and tampering.

Step 3: Network Security Implementation

Building robust network defenses in Azure and on-premises is crucial for controlling traffic flow, segmenting infrastructure, and preventing unauthorized access. This section emphasizes a Zero Trust approach to network security.

Logically Segment Virtual Networks and Subnets (Azure)

Segmenting your Azure virtual networks (VNets) into smaller subnets based on security zones or application tiers prevents lateral movement in the event of a compromise. Microsoft recommends avoiding overly small subnets to ensure flexibility for growth, using CIDR-based principles.

# Create a new Azure Virtual Network with a broad address space
New-AzVirtualNetwork -ResourceGroupName "myResourceGroup" -Name "myVNet" -Location "East US" -AddressPrefix "10.0.0.0/16"

# Add subnets for different tiers
$vnet = Get-AzVirtualNetwork -ResourceGroupName "myResourceGroup" -Name "myVNet"
Add-AzVirtualNetworkSubnetConfig -Name "WebSubnet" -AddressPrefix "10.0.1.0/24" -VirtualNetwork $vnet
Add-AzVirtualNetworkSubnetConfig -Name "AppSubnet" -AddressPrefix "10.0.2.0/24" -VirtualNetwork $vnet
Add-AzVirtualNetworkSubnetConfig -Name "DbSubnet" -AddressPrefix "10.0.3.0/24" -VirtualNetwork $vnet
$vnet | Set-AzVirtualNetwork

New-AzVirtualNetwork: Creates a new virtual network in Azure.

-ResourceGroupName: Specifies the Azure resource group for the VNet.

-Name: Assigns a name to the virtual network.

-Location: Specifies the Azure region for the VNet.

-AddressPrefix "10.0.0.0/16": Defines the overall IP address space for the VNet.

Add-AzVirtualNetworkSubnetConfig: Adds a subnet configuration to a virtual network object.

-Name "WebSubnet": Names the new subnet.

-AddressPrefix "10.0.1.0/24": Defines the CIDR block for the subnet.

-VirtualNetwork $vnet: Specifies the virtual network object to which the subnet is added.

$vnet | Set-AzVirtualNetwork: Updates the virtual network in Azure with the new subnet configurations.

Portal alternative: Navigate to 'Virtual networks', select your VNet, then 'Subnets' > '+ Subnet' to add new subnets.

Expected result: A well-structured virtual network with logically isolated subnets, facilitating granular control over traffic flow between different application components.

Implement Network Security Groups (NSGs) with Application Security Groups (ASGs)

Network Security Groups provide stateful packet inspection at the subnet or NIC level. Combined with Application Security Groups, NSGs allow you to define granular allow/deny rules based on application workloads rather than individual IP addresses, simplifying management and enhancing security. Avoid broad allow rules (e.g., 0.0.0.0/0) which are often exploited.

# Create a new Network Security Group
New-AzNetworkSecurityGroup -Name "WebNSG" -ResourceGroupName "myResourceGroup" -Location "East US"

# Add an inbound rule to allow HTTP/HTTPS to the Web tier
Add-AzNetworkSecurityRuleConfig -Name "AllowWebTraffic" `
    -NetworkSecurityGroup (Get-AzNetworkSecurityGroup -Name "WebNSG" -ResourceGroupName "myResourceGroup") `
    -Access Allow -Protocol Tcp -Direction Inbound -Priority 100 `
    -SourceAddressPrefix Internet -SourcePortRange "*" `
    -DestinationAddressPrefix "*" -DestinationPortRange "80,443"

# Create an Application Security Group for web servers
New-AzApplicationSecurityGroup -Name "WebServersASG" -ResourceGroupName "myResourceGroup" -Location "East US"

# Associate a VM's NIC with the ASG
$nic = Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -Name "myWebVMNic"
Set-AzNetworkInterfaceIpConfig -Name $nic.IpConfigurations[0].Name -NetworkInterface $nic `
    -ApplicationSecurityGroup (Get-AzApplicationSecurityGroup -Name "WebServersASG" -ResourceGroupName "myResourceGroup")

# Link NSG to a subnet
$vnet = Get-AzVirtualNetwork -ResourceGroupName "myResourceGroup" -Name "myVNet"
$webSubnet = Get-AzVirtualNetworkSubnetConfig -Name "WebSubnet" -VirtualNetwork $vnet
Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name $webSubnet.Name -AddressPrefix $webSubnet.AddressPrefix `
    -NetworkSecurityGroup (Get-AzNetworkSecurityGroup -Name "WebNSG" -ResourceGroupName "myResourceGroup")
$vnet | Set-AzVirtualNetwork

New-AzNetworkSecurityGroup: Creates an NSG.

Add-AzNetworkSecurityRuleConfig: Defines a new security rule within an NSG.

-Access Allow: Specifies that traffic matching the rule should be allowed.

-Protocol Tcp: Specifies the TCP protocol.

-Direction Inbound: Applies the rule to incoming traffic.

-SourceAddressPrefix Internet: Allows traffic from any external IP address.

-DestinationPortRange "80,443": Specifies destination ports for HTTP and HTTPS.

New-AzApplicationSecurityGroup: Creates an ASG, which is a logical grouping of network interfaces.

Set-AzNetworkInterfaceIpConfig: Associates a VM's network interface IP configuration with an ASG.

Set-AzVirtualNetworkSubnetConfig: Links an NSG to a specific subnet.

Portal alternative: Navigate to 'Network security groups', '+ Create', then add inbound/outbound rules. For ASGs, go to 'Application security groups', '+ Create', then associate them with VM network interfaces under the VM's 'Networking' settings.

Expected result: Fine-grained network access controls protecting subnets and specific application tiers, reducing lateral movement risks and preventing unauthorized external access.

Enable Virtual Network Flow Logs (Azure)

Virtual Network Flow Logs (a feature of Azure Network Watcher) provide comprehensive visibility into network traffic patterns, replacing NSG flow logs for broader monitoring coverage. This is essential for auditing, security analysis, and troubleshooting connectivity issues.

# Ensure Network Watcher is enabled in the region
Get-AzNetworkWatcher -Location "East US" | Out-Null
if (-not $_) {
    New-AzNetworkWatcher -Name "NetworkWatcher_EastUS" -ResourceGroupName "NetworkWatcherRG" -Location "East US"
}

# Create a storage account for flow logs
$storageAccount = New-AzStorageAccount -ResourceGroupName "myResourceGroup" -Name "flowlogstorage" -Location "East US" -SkuName Standard_LRS

# Enable VNet flow logs for a specific Virtual Network
$vnet = Get-AzVirtualNetwork -ResourceGroupName "myResourceGroup" -Name "myVNet"
az network watcher flow-log create --resource-group "myResourceGroup" --location "East US" `
    --name "myVNetFlowLog" --network-watcher-name "NetworkWatcher_EastUS" `
    --vnet $vnet.Id --storage-account $storageAccount.Id `
    --enabled true --retention-days 30 --format JSON --version 2

Get-AzNetworkWatcher / New-AzNetworkWatcher: Ensures Azure Network Watcher is active in the desired region.

New-AzStorageAccount: Creates an Azure Storage Account to store the flow log data.

az network watcher flow-log create: Azure CLI command to enable flow logs on a virtual network.

--vnet $vnet.Id: Specifies the ID of the virtual network to monitor.

--storage-account $storageAccount.Id: Specifies the storage account where logs will be stored.

--enabled true: Activates the flow logging.

--retention-days 30: Sets the log retention period to 30 days.

--format JSON --version 2: Specifies the output format and version for the logs.

Portal alternative: Navigate to 'Network Watcher', select 'Flow logs', '+ Create', then choose the Virtual Network and storage account.

Expected result: Detailed records of all network traffic flowing through your virtual network, enabling security analysis, anomaly detection, and compliance auditing.

Step 4: Privileged Access Management (PAM)

Minimizing the risk associated with elevated credentials is a cornerstone of server hardening. Implementing Just Enough Administration (JEA) and leveraging credential protection mechanisms like Credential Guard significantly reduces the attack surface for privilege escalation and credential theft.

Implement Just Enough Administration (JEA)

JEA allows administrators to delegate specific administrative tasks without granting full administrative privileges. This principle of least privilege ensures that users can perform only the tasks they need, reducing the impact of compromised accounts.

# Create a new JEA session configuration file
New-PSSessionConfigurationFile -Path ".\WebAdmin.pssc" -SessionType RestrictedRemoteServer -LanguageMode ConstrainedLanguage `
    -RunAsVirtualAccount -ScriptsToProcess @(".\WebAdminFunctions.ps1") -RoleDefinitions @{
        'Domain\WebAdmins' = @{
            RoleCapabilities = 'WebManagement' # Define a custom role capability
        }
    }

# Register the JEA endpoint
Register-PSSessionConfiguration -Path ".\WebAdmin.pssc" -Name "WebAdminEndpoint" -Force

New-PSSessionConfigurationFile: Creates a new JEA configuration file.

-Path: Specifies the path for the `.pssc` file.

-SessionType RestrictedRemoteServer: Creates a restricted PowerShell session.

-LanguageMode ConstrainedLanguage: Limits the cmdlets and .NET types that can be used within the session.

-RunAsVirtualAccount: Configures the session to run under a temporary virtual account, preventing credential reuse.

-ScriptsToProcess: Specifies a script file containing functions that define the allowed tasks.

-RoleDefinitions: Defines roles and their associated capabilities (what tasks they can perform).

Register-PSSessionConfiguration: Registers the JEA configuration as a new PowerShell endpoint.

Portal alternative: JEA is a PowerShell-first feature. While some aspects can be configured via Group Policy (e.g., firewall rules for WinRM), the core configuration is done through PowerShell scripts and files.

Expected result: Delegated administrative tasks can be performed by non-privileged accounts through a controlled PowerShell endpoint, significantly limiting the potential for privilege escalation.

Protect Credentials with Credential Guard

Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. This helps prevent NTLM hash and Kerberos ticket theft (Pass-the-Hash, Pass-the-Ticket attacks).

# Enable Virtualization-Based Security and Credential Guard via Registry
# Requires UEFI, Secure Boot, and virtualization features enabled in firmware.
# This should ideally be deployed via Group Policy for managed environments.

# For VBS (Virtualization-Based Security)
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DeviceGuard /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DeviceGuard /v RequirePlatformSecureBoot /t REG_DWORD /d 1 /f

# For Credential Guard
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DeviceGuard\Scenarios\CredentialGuard /v Enabled /t REG_DWORD /d 1 /f

# Verify Credential Guard status after reboot
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object -ExpandProperty SecurityServicesRunning

reg add: Command-line tool to add or modify registry entries.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DeviceGuard: Path for Device Guard settings.

EnableVirtualizationBasedSecurity: Enables the core VBS platform.

RequirePlatformSecureBoot: Enforces Secure Boot requirement for VBS.

\Scenarios\CredentialGuard /v Enabled /t REG_DWORD /d 1: Enables Credential Guard specifically.

Get-CimInstance: Retrieves information from a CIM (Common Information Model) class.

Win32_DeviceGuard: CIM class providing Device Guard status.

SecurityServicesRunning: Property indicating which security services (like Credential Guard) are active.

Portal alternative: Credential Guard is best configured through Group Policy (Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security). Verify through System Information (msinfo32.exe) under 'Virtualization-based security Services Running'.

Expected result: Protection of derived domain credentials within a secure, isolated environment, making them significantly harder for attackers to steal even if the OS kernel is compromised.

Step 5: Application and Data Protection

Safeguarding applications and sensitive data involves implementing advanced application control policies, ensuring secure communication protocols, and robust data encryption. This builds upon OS hardening to protect the assets running on the server.

Enforce Application Control (Re-emphasized)

While discussed in OS hardening, it's vital to reiterate WDAC's role in protecting applications specifically. Beyond system files, WDAC prevents the execution of unauthorized applications, scripts, and plugins, which are common vectors for malware and data exfiltration.

# If in Audit Mode, regularly check WDAC event logs (Event ID 3077/3078)
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'} | `
    Where-Object {$_.Id -eq 3077 -or $_.Id -eq 3078} | `
    Select-Object TimeCreated,Id,Message | Format-List

Get-WinEvent: Retrieves events from event logs.

-FilterHashtable: Filters events based on specified criteria.

LogName='Microsoft-Windows-CodeIntegrity/Operational': Specifies the Code Integrity operational log.

Where-Object {$_.Id -eq 3077 -or $_.Id -eq 3078}: Filters for WDAC enforcement (3077) or audit (3078) events.

Select-Object TimeCreated,Id,Message: Selects relevant event properties.

Format-List: Displays output in a list format.

Expected result: A secure execution environment where only trusted applications and their components can run, providing strong protection against malicious code.

Utilize Data Encryption

Encrypting data at rest is paramount for protecting sensitive information, even if an attacker gains physical access or bypasses other security controls. This includes operating system drives and data volumes.

Windows Server (BitLocker)

BitLocker Drive Encryption provides full-disk encryption for Windows Server operating systems and fixed/removable data drives.

# Enable BitLocker on the OS drive (C:)
# Requires a Trusted Platform Module (TPM) or a USB startup key.
Enable-BitLocker -MountPoint "C:" -EncryptionMethod Aes256 -UsedSpaceOnly -SkipHardwareTest -RecoveryKeyPath "C:\Recovery" -TpmProtector

Enable-BitLocker: Initiates BitLocker drive encryption.

-MountPoint "C:": Specifies the drive to encrypt.

-EncryptionMethod Aes256: Uses AES 256-bit encryption.

-UsedSpaceOnly: Encrypts only the used space on the drive (faster for new drives).

-SkipHardwareTest: Bypasses the BitLocker hardware test, which can sometimes fail in virtualized environments.

-RecoveryKeyPath: Specifies a path to save the recovery key.

-TpmProtector: Uses the TPM for protection. Other options include password or startup key.

Portal alternative: Open 'Control Panel' > 'System and Security' > 'BitLocker Drive Encryption' and follow the wizard.

Expected result: The operating system drive is encrypted, protecting data from unauthorized access if the server is offline or physically compromised.

Azure Virtual Machines (Azure Disk Encryption - ADE)

Azure Disk Encryption (ADE) helps encrypt the OS and data disks used by Azure Virtual Machines. ADE uses the industry-standard DM-Crypt feature of Linux or the BitLocker feature of Windows to provide volume encryption for the OS and data disks, with encryption keys stored in Azure Key Vault.

# Ensure Key Vault and Access Policy for Disk Encryption are configured
# Replace with your actual Key Vault details
$keyVaultName = "myDiskEncryptionKeyVault"
$resourceGroup = "myResourceGroup"
$location = "East US"
$vmName = "myAzureVM"

# Create a Key Vault (if it doesn't exist)
New-AzKeyVault -VaultName $keyVaultName -ResourceGroupName $resourceGroup -Location $location `
    -EnabledForDiskEncryption

# Grant the Azure AD application 'Azure Disk Encryption' permissions to Key Vault
# This is a specific App ID: 'a438ee15-a7b2-4d1d-878d-19cd747ad8f3'
Set-AzKeyVaultAccessPolicy -VaultName $keyVaultName -ServicePrincipalName 'a438ee15-a7b2-4d1d-878d-19cd747ad8f3' `
    -PermissionsToKeys all -PermissionsToSecrets all -BypassObjectIdValidation

# Get Key Vault details
$diskEncryptionKeyVault = Get-AzKeyVault -VaultName $keyVaultName -ResourceGroupName $resourceGroup

# Start disk encryption for the VM
Set-AzVMDiskEncryptionExtension -ResourceGroupName $resourceGroup -VMName $vmName `
    -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVault.VaultUri `
    -DiskEncryptionKeyVaultId $diskEncryptionKeyVault.ResourceId `
    -VolumeType All -SkipExchangeDisk -Force

New-AzKeyVault: Creates a new Azure Key Vault instance.

-EnabledForDiskEncryption: Configures the Key Vault to be used for disk encryption.

Set-AzKeyVaultAccessPolicy: Grants permissions to the specified service principal (Azure Disk Encryption application) within the Key Vault.

-ServicePrincipalName: Specifies the application ID of the Azure Disk Encryption service.

-PermissionsToKeys all -PermissionsToSecrets all: Grants necessary permissions for key management.

Set-AzVMDiskEncryptionExtension: Enables Azure Disk Encryption on an Azure VM.

-VolumeType All: Encrypts both OS and data disks.

-SkipExchangeDisk: Prevents the extension from trying to exchange disks during encryption, which is often not desired.

-Force: Overwrites existing ADE configurations if any.

Portal alternative: Navigate to your Azure VM, select 'Disks' under 'Settings', then click 'Additional settings' and choose 'Encryption'. Configure the Key Vault and select 'Encrypt OS and data disks'.

Expected result: All VM disks (OS and data) are encrypted at rest, with keys securely managed in Azure Key Vault, protecting data even if the underlying storage is compromised.

Step 6: Monitoring, Auditing, and Threat Detection

Establishing comprehensive visibility into server activity, centralizing logs, and integrating with advanced threat intelligence systems are critical for rapid detection and response to security incidents. Effective monitoring is the eyes and ears of your security posture.

Centralize Logs and Configure Comprehensive Auditing

Collecting security-relevant events from all servers into a centralized Security Information and Event Management (SIEM) solution (like Azure Sentinel, Splunk, or Elastic Stack) is essential. Configure Windows Server to log critical security events.

# Configure audit policy for critical events (example: Account Logon, Object Access)
# For comprehensive auditing, refer to CIS Benchmarks for specific categories.
Auditpol /set /subcategory:"Logon" /success:enable /failure:enable
Auditpol /set /subcategory:"Logoff" /success:enable /failure:enable
Auditpol /set /subcategory:"File System" /success:enable /failure:enable
Auditpol /set /subcategory:"Kernel Object" /success:enable /failure:enable
Auditpol /set /subcategory:"Security State Change" /success:enable /failure:enable
Auditpol /set /subcategory:"Security System Extension" /success:enable /failure:enable
Auditpol /set /subcategory:"System Integrity" /success:enable /failure:enable

# Enable Windows Event Forwarding (requires collector setup)
# This command configures the client to forward events to a collector.
# The collector must be set up with `wecutil qc` and subscriptions.
wecutil ss "SubscriptionName" /cf:""

Auditpol /set: Configures audit policies for specific subcategories.

/subcategory:"Logon": Specifies the event subcategory.

/success:enable: Enables auditing for successful events.

/failure:enable: Enables auditing for failed events.

wecutil ss: Configures Windows Event Forwarding on the source server to send events to a collector.

/cf:"": Specifies the configuration file for the subscription.

Portal alternative: Audit policies are best managed via Group Policy Objects (GPOs). For event forwarding, use 'Event Viewer' > 'Subscriptions' on the collector, and 'Attach Task To This Event' for individual events.

Expected result: Detailed security events are generated on the server and forwarded to a centralized logging system, providing a complete audit trail for forensic analysis and threat hunting.

Integrate with Advanced Threat Detection Systems

Leverage modern Security Information and Event Management (SIEM) and Extended Detection and Response (XDR) solutions to analyze logs, detect anomalies, and respond to threats automatically. Microsoft Defender for Endpoint (MDE) and Azure Sentinel are prime examples.

# For Azure VMs, onboard to Azure Monitor and Log Analytics Workspace
# First, get your Log Analytics Workspace ID and shared key
$workspaceId = (Get-AzOperationalInsightsWorkspace -ResourceGroupName "myLogAnalyticsRG" -Name "myLogAnalyticsWorkspace").CustomerId
$sharedKey = (Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName "myLogAnalyticsRG" -Name "myLogAnalyticsWorkspace").PrimarySharedKey

# Install the Log Analytics Agent (MMA agent) on the VM
# For Windows:
Set-AzVMExtension -ResourceGroupName "myResourceGroup" -VMName "myAzureVM" -Name "MicrosoftMonitoringAgent" `
    -Publisher "Microsoft.EnterpriseCloud.Monitoring" -ExtensionType "MicrosoftMonitoringAgent" `
    -TypeHandlerVersion "1.0" -Location "East US" `
    -Settings @{"workspaceId" = $workspaceId} `
    -ProtectedSettings @{"workspaceKey" = $sharedKey}

Get-AzOperationalInsightsWorkspace: Retrieves details of an Azure Log Analytics Workspace.

Get-AzOperationalInsightsWorkspaceSharedKey: Retrieves the shared key for a Log Analytics Workspace.

Set-AzVMExtension: Installs or updates a VM extension on an Azure Virtual Machine.

-ExtensionType "MicrosoftMonitoringAgent": Specifies the Log Analytics Agent extension.

-Settings: Provides non-sensitive settings (like Workspace ID).

-ProtectedSettings: Provides sensitive settings (like Workspace Key).

Portal alternative: Navigate to your Azure VM, select 'Extensions + applications', '+ Add', and search for 'Log Analytics agent'. Provide the workspace details. For Microsoft Defender for Endpoint, onboard servers via the Microsoft 365 Defender portal.

Expected result: Server security events, performance data, and threat intelligence are fed into a centralized security platform, enabling proactive threat detection, automated responses, and compliance reporting.

Step 7: Regular Review and Maintenance

Server hardening is not a one-time task; it's an ongoing process. Continuous security requires adopting a proactive approach to patch management, regular configuration reviews, and periodic vulnerability assessments to adapt to the evolving threat landscape.

Implement Robust Patch Management

Keeping operating systems and applications fully patched against known vulnerabilities is arguably the most critical security control. Automate patching where feasible, but ensure thorough testing before widespread deployment.

# For Server Core (text-based interface)
sconfig

# To check for and install updates via PowerShell (requires PSWindowsUpdate module)
Install-Module -Name PSWindowsUpdate -Force
Get-WindowsUpdate
Install-WindowsUpdate -AcceptAll -AutoReboot

sconfig: Text-based tool for common server configuration tasks, including Windows Update settings, particularly useful for Server Core.

Install-Module PSWindowsUpdate: Installs the community-developed PowerShell module for managing Windows Updates.

Get-WindowsUpdate: Lists available Windows Updates using the PSWindowsUpdate module.

Install-WindowsUpdate -AcceptAll -AutoReboot: Installs all available updates and reboots the server if required.

Portal alternative: For Windows Server with GUI, use 'Settings' > 'Update & Security' > 'Windows Update'. For Azure VMs, use 'Update Management' in Azure Automation to centrally manage patching.

Expected result: Servers remain protected against the latest known vulnerabilities, reducing the window of opportunity for attackers to exploit unpatched systems.

Conduct Configuration Drift Management

Over time, server configurations can drift from their hardened baseline due to changes, troubleshooting, or human error. Use tools like PowerShell Desired State Configuration (DSC) or Azure Policy to enforce and audit configuration consistency.

# Example DSC Configuration to ensure a specific Windows Feature is installed
Configuration EnsureIIS {
    Node "localhost" {
        WindowsFeature IIS {
            Ensure = "Present"
            Name = "Web-Server"
        }
        # Further settings for IIS or other features can be added here
    }
}

# Compile and apply the DSC configuration
EnsureIIS
Start-DscConfiguration -Path .\EnsureIIS -Wait -Verbose

Configuration EnsureIIS { ... }: Defines a DSC configuration block.

Node "localhost": Specifies that the configuration applies to the local machine.

WindowsFeature IIS { ... }: A DSC resource block to manage the 'Web-Server' feature.

Ensure = "Present": Specifies that the feature should be installed.

EnsureIIS: Compiles the configuration into a MOF (Managed Object Format) document.

Start-DscConfiguration: Applies the compiled DSC configuration to the target node.

Portal alternative: Azure Policy can enforce configuration standards across Azure resources, including checking for specific OS settings (via Guest Configuration). For on-premises, Group Policy can also be used for some configuration enforcement.

Expected result: Server configurations are consistently maintained according to the defined secure baseline, preventing configuration drift from reintroducing vulnerabilities.

Perform Regular Vulnerability Assessments and Penetration Testing

Periodic vulnerability scans and penetration tests are essential to identify new weaknesses, validate the effectiveness of hardening measures, and simulate real-world attacks. These should be performed by independent security teams or trusted third-party vendors.

# While no direct command exists for running a "vulnerability assessment",
# you can use PowerShell to trigger external scanning tools or collect system info
# for an assessment report. Example for collecting installed software:
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName,DisplayVersion,InstallDate | Format-Table -AutoSize

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*: Retrieves details of installed software from the registry.

Select-Object DisplayName,DisplayVersion,InstallDate: Selects software name, version, and installation date.

Expected result: Continuous identification of vulnerabilities and validation of security controls, leading to ongoing improvements in the server's security posture and preparedness against new threats.