Microsoft Security Baselines

Microsoft Security Baselines are pre-configured groups of settings that represent the recommended security configuration for Microsoft products and services. They are essentially a set of security rules and best practices that Microsoft's security teams have developed based on real-world threat intelligence and industry standards such as CIS (Center for Internet Security) benchmarks and NIST (National Institute of Standards and Technology) guidelines. These baselines are designed to help organizations quickly achieve a secure state without having to research each individual security setting.

The primary purpose of security baselines is to reduce the attack surface by enforcing a consistent, minimum security posture across all devices and services in an organization. Without baselines, administrators would need to manually configure hundreds of security settings, which is error-prone and time-consuming. Baselines also provide a benchmark for compliance monitoring—tools like Microsoft Defender for Cloud and Microsoft Intune can compare current configurations against the baseline and report deviations.

Security baselines are essentially a collection of Group Policy Objects (GPOs) or configuration profiles that contain specific security settings. For Windows, these settings include password policies, account lockout policies, audit policies, user rights assignments, security options, and Windows Defender Firewall rules. For Azure, baselines include settings for Azure Policy definitions that enforce compliance on Azure resources. For Microsoft 365, baselines include conditional access policies, identity protection settings, and device compliance policies.

When a baseline is applied, it modifies the underlying registry keys, security templates, or policy settings. For example, the 'Microsoft 365 Security Baseline' includes a conditional access policy that requires multi-factor authentication (MFA) for all users. When this baseline is deployed via Intune or Azure AD Conditional Access, it creates a policy that enforces MFA. Devices and users are then evaluated against this policy, and non-compliant entities are blocked or prompted for additional verification.

- Windows Security Baselines: These are provided as GPO backups that can be imported into Group Policy Management Console. They include settings like: - Account Policies: Minimum password length (default 14 characters), password history (24 remembered), maximum password age (90 days). - Lockout Policy: Account lockout threshold (5 invalid attempts), lockout duration (15 minutes), reset lockout counter after (15 minutes). - Audit Policy: Audit logon events (Success and Failure), audit account logon events (Success and Failure). - Windows Defender Firewall: Inbound connections blocked by default, outbound allowed.

- Azure Security Baselines: These are implemented via Azure Policy. For example, the 'Azure Security Benchmark' includes policies like: - Enable MFA for privileged accounts: Policy definition ID /providers/Microsoft.Authorization/policyDefinitions/e0e698fd-8b1a-4f5d-9e5d-9f9e9e9e9e9e. - Require encryption for storage accounts: Policy definition ID /providers/Microsoft.Authorization/policyDefinitions/404c3081-a854-4457-ae30-26a93ef643f9.

- Microsoft 365 Security Baselines: These are pre-built conditional access policies in Azure AD. For example: - Baseline policy: Require MFA for admins: This policy targets all users with admin roles and requires MFA. - Baseline policy: Block legacy authentication: This policy blocks authentication protocols that do not support MFA.

For Windows, you can apply a security baseline using the LGPO.exe tool or via Group Policy:

# Import a security baseline GPO backup
LGPO.exe /s C:\Baselines\Windows10-2004-SecurityBaseline.inf

To verify that a baseline is applied, you can use the secedit command:

secedit /analyze /db C:\temp\secbaseline.sdb /cfg C:\Baselines\Windows10-2004-SecurityBaseline.inf /log C:\temp\seclog.txt

For Azure, you can assign a baseline policy via Azure Policy:

# Assign the Azure Security Benchmark initiative
az policy assignment create --name "AzureSecurityBenchmark" --policy-set-definition "/providers/Microsoft.Authorization/policySetDefinitions/1f3afdf9-d0c9-4c3d-847f-89da613e70a8" --scope "/subscriptions/{subscriptionId}"

To verify compliance, use:

az policy state list --resource "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}"

For Microsoft 365, you enable baseline policies through the Azure AD portal or PowerShell:

# Enable MFA baseline policy
$policy = Get-AzureADMSConditionalAccessPolicy | Where-Object {$_.DisplayName -eq "Baseline policy: Require MFA for admins"}
$policy.State = "enabled"
Set-AzureADMSConditionalAccessPolicy -Id $policy.Id

Security baselines are closely tied to compliance and management tools:

While baselines provide a strong starting point, organizations should customize them to balance security and usability. For example, a baseline may require MFA for all users, but an organization with legacy systems may need to exempt service accounts. Baselines should be tested in a pilot group before broad deployment. Microsoft recommends using the 'Security Compliance Toolkit' to customize and test baselines.

Baselines are versioned. For example, the Windows 10 Security Baseline has versions for each feature update (1809, 1903, 2004, etc.). Microsoft releases new baselines when major security threats emerge or when new features are added. Administrators should regularly review and update baselines to maintain security.

A large enterprise with 10,000 Windows 10 devices needs to enforce a consistent security posture. Without baselines, each device may have different password policies, firewall rules, and audit settings. The IT team downloads the Windows 10 Security Baseline from the Microsoft Security Compliance Toolkit. They customize it to allow a longer password history (30) and exempt a legacy application that requires port 3389 (RDP) inbound. They deploy the baseline via Group Policy to a pilot OU of 100 devices. After two weeks, they review compliance using the Security Compliance Toolkit's Policy Analyzer and find that 10 devices have non-compliant settings due to local administrators overriding policies. They use Group Policy to enforce settings with 'No Override' and redeploy. After the pilot, they roll out to all devices. The secure score in Microsoft Defender for Cloud improves from 60% to 85%. Common issues include performance impact from enabled audit policies (log volume increases) and user complaints about stricter password requirements. The team mitigates by increasing log storage and communicating changes.

A financial services company must comply with PCI DSS. They enable the 'Azure Security Benchmark' baseline in Defender for Cloud. This baseline includes policies like 'Enable MFA for privileged accounts' and 'Require encryption for storage accounts'. Initially, the secure score is 40% because many resources lack encryption and MFA is not enforced. The team assigns the built-in policy initiative to their subscription. Within 24 hours, non-compliant resources are flagged. For storage accounts without encryption, Azure Policy automatically enables encryption via the 'deployIfNotExists' effect. For MFA, they create a conditional access policy. After remediation, the secure score rises to 90%. However, a developer complains that a test storage account cannot be accessed because encryption was forced. The team creates an exemption for that resource. This scenario shows the need for careful testing and exceptions.

A mid-sized organization wants to enforce MFA for all administrators. They enable the 'Baseline policy: Require MFA for admins' in Azure AD Conditional Access. This policy applies to all users with admin roles (Global Admin, Exchange Admin, etc.). The policy works by blocking sign-ins that do not satisfy MFA. After enabling, some admins report that they cannot access the admin portal from non-compliant devices. The team realizes that the baseline policy does not allow exceptions for trusted IPs. They decide to create a custom conditional access policy instead of using the baseline, which allows them to exclude the corporate network. This highlights that baselines are a starting point and may need customization.