🪟 Windows 11 Hardening

Vendors that have demonstrated a commitment to Secure by Design and Secure by Default principles and practices, including secure programming practices and either memory-safe programming languages or less preferably memory-safe programming practices, are used for operating systems.

The latest release, or the previous release, of operating systems are used.

Where supported, 64-bit versions of operating systems are used.

SOEs are used for workstations and servers.

SOEs provided by third parties are scanned for malicious code and configurations.

SOEs are reviewed and updated at least annually.

Approved configurations for operating systems are developed, implemented and maintained.

Operating systems are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.

Default user accounts or credentials for operating systems, including for any pre-configured user accounts, are changed, disabled or removed during initial setup.

Unneeded user accounts, components, services and functionality of operating systems are disabled or removed.

Automatic execution features for removable media are disabled.

Internet Explorer 11 is disabled or removed.

.NET Framework 3.5 (includes .NET 2.0 and 3.0) is disabled or removed.

Operating system exploit protection functionality is enabled.

Early Launch Antimalware, Secure Boot, Trusted Boot and Measured Boot functionality is enabled.

Unprivileged users are prevented from bypassing, disabling or modifying security functionality of operating systems.

Unprivileged users are prevented from running script execution engines, including: - Windows Script Host (cscript.exe and wscript.exe) - PowerShell (powershell.exe, powershell_ise.exe and pwsh.exe) - Command Prompt (cmd.exe) - Windows Management Instrumentation (wmic.exe) - Microsoft Hypertext Markup Language (HTML) Application Host (mshta.exe).

Unprivileged users do not have the ability to install unapproved applications.

Unprivileged users do not have the ability to uninstall or disable approved applications.

Application control is implemented on workstations.

Application control is implemented on internet-facing servers.

Application control is implemented on non-internet-facing servers.

Application control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients.

Application control is applied to all locations other than user profiles and temporary folders used by operating systems, web browsers and email clients.

Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.

Application control restricts the execution of drivers to an organisation-approved set.

Application control is implemented using cryptographic hash rules, publisher certificate rules or path rules.

When implementing application control using publisher certificate rules, publisher names and product names are used.

When implementing application control using path rules, only approved users can modify approved files and write to approved folders.

When implementing application control using path rules, only approved users can change file system permissions for approved files and folders.

Microsoft’s recommended application blocklist is implemented.

Microsoft’s vulnerable driver blocklist is implemented.

Application control rulesets are validated on an annual or more frequent basis.

All users (with the exception of local administrator accounts and break glass accounts) cannot disable, bypass or be exempted from application control.

Allowed and blocked application control events are centrally logged.

Command line process creation events are centrally logged.

Windows PowerShell 2.0 is disabled or removed.

PowerShell is configured to use Constrained Language Mode.

PowerShell module logging, script block logging and transcription events are centrally logged.

PowerShell script block logs are protected by Protected Event Logging functionality.

A HIPS or EDR solution is implemented on workstations.

A HIPS or EDR solution is implemented on critical servers and high-value servers.

A software firewall is implemented on workstations and servers to restrict inbound and outbound network connections to an organisation-approved set of applications and services.

An antivirus application is implemented on workstations and servers with: - signature-based detection functionality enabled and set to a high level - heuristic-based detection functionality enabled and set to a high level - reputation rating functionality enabled - ransomware protection functionality enabled - detection signatures configured to update on at least a daily basis - regular scanning configured for all fixed disks and removable media.

If there is no business requirement for reading from removable media and devices, such functionality is disabled via the use of a device access control application or by disabling external communication interfaces.

If there is no business requirement for writing to removable media and devices, such functionality is disabled via the use of a device access control application or by disabling external communication interfaces.

External communication interfaces that allow DMA are disabled.

Security-relevant events for Apple macOS operating systems are centrally logged.

Security-relevant events for Linux operating systems are centrally logged.

Security-relevant events for Microsoft Windows operating systems are centrally logged.

Vendors that have demonstrated a commitment to Secure by Design and Secure by Default principles and practices, including secure programming practices and either memory-safe programming languages or less preferably memory-safe programming practices, are used for user applications.

The latest release of office productivity suites, web browsers and their extensions, email clients, PDF applications, and security products are used.

Approved configurations for user applications are developed, implemented and maintained.

Default user accounts or credentials for user applications, including for any pre-configured user accounts, are changed, disabled or removed during initial setup.

Unneeded components, services and functionality of office productivity suites, web browsers, email clients, PDF applications and security products are disabled or removed.

Add-ons, extensions and plug-ins for office productivity suites, web browsers, email clients, PDF applications and security products are restricted to an organisation-approved set.

Microsoft Office is blocked from creating child processes.

Microsoft Office is blocked from creating executable content.

Microsoft Office is blocked from injecting code into other processes.

Microsoft Office is configured to prevent activation of Object Linking and Embedding packages.

Office productivity suites are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.

Office productivity suite security settings cannot be changed by users.

Web browsers do not process Java from the internet.

Web browsers do not process web advertisements from the internet.

Web browsers are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.

Web browser security settings cannot be changed by users.

PDF applications are blocked from creating child processes.

PDF applications are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.

PDF application security settings cannot be changed by users.

Microsoft’s attack surface reduction rules are implemented.

Email client security settings cannot be changed by users.

Security product security settings cannot be changed by users.

Microsoft Office macros are disabled for users that do not have a demonstrated business requirement.

Microsoft Office macros in files originating from the internet are blocked.

Microsoft Office macro antivirus scanning is enabled.

Microsoft Office macros are blocked from making Win32 API calls.

Only Microsoft Office macros running from within a sandboxed environment, a Trusted Location or that are digitally signed by a trusted publisher are allowed to execute.

Microsoft Office macros are checked to ensure they are free of malicious code before being digitally signed or placed within Trusted Locations.

Only privileged users responsible for checking that Microsoft Office macros are free of malicious code can write to and modify content within Trusted Locations.

Microsoft Office macros digitally signed by an untrusted publisher cannot be enabled via the Message Bar or Backstage View.

Microsoft Office macros digitally signed by signatures other than V3 signatures cannot be enabled via the Message Bar or Backstage View.

Microsoft Office’s list of trusted publishers is validated on an annual or more frequent basis.

Microsoft Office macro security settings cannot be changed by users.

Vendors that have demonstrated a commitment to Secure by Design and Secure by Default principles and practices, including secure programming practices and either memory-safe programming languages or less preferably memory-safe programming practices, are used for server applications.

The latest release of internet-facing server applications are used.

Approved configurations for server applications are developed, implemented and maintained.

Server applications are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.

Default user accounts or credentials for server applications, including for any pre-configured user accounts, are changed, disabled or removed during initial setup.

Unneeded user accounts, components, services and functionality of server applications are disabled or removed.

All temporary installation files and logs created during server application installation processes are removed after server applications have been installed.

Server applications are configured to run as a separate user account with the minimum privileges needed to perform their functions.

The user accounts under which server applications run have limited access to their underlying server’s file system.

Microsoft AD DS domain controllers, Microsoft AD CS CA servers, Microsoft AD FS servers and Microsoft Entra Connect servers are only used for their designed role and no other applications or services are installed, unless they are security related.

Access to Microsoft AD DS domain controllers, Microsoft AD CS CA servers, Microsoft AD FS servers and Microsoft Entra Connect servers is limited to privileged users that require access.

Backups of Microsoft AD DS domain controllers, Microsoft AD CS CA servers, Microsoft AD FS servers and Microsoft Entra Connect servers are encrypted, stored securely and only accessible to backup administrator accounts.

Security-relevant events for Microsoft AD DS domain controllers, Microsoft AD CS CA servers, Microsoft AD FS servers and Microsoft Entra Connect servers are centrally logged.

Microsoft AD DS domain controllers are administered using dedicated domain administrator user accounts that are not used to administer other systems.

Lightweight Directory Access Protocol signing is enabled on Microsoft AD DS domain controllers.

The Print Spooler service is disabled on Microsoft AD DS domain controllers.

Passwords are not stored in Group Policy Preferences.

Passwords are prevented from being stored in Group Policy Preferences.

SID Filtering is enabled for domain and forest trusts.

Only service accounts and computer accounts are configured with Service Principal Names (SPNs).

The number of service accounts configured with an SPN is minimised.

Service accounts configured with an SPN do not have DCSync permissions.

Service accounts configured with an SPN use the Advanced Encryption Standard for encryption.

Duplicate SPNs do not exist within the domain.

User accounts are provisioned with the minimum privileges required.

User accounts with DCSync permissions are reviewed at least annually, and those without an ongoing requirement for the permissions have them removed.

Privileged user accounts are configured as sensitive and cannot be delegated.

Computer accounts are not configured for unconstrained delegation.

User accounts require Kerberos pre-authentication.

User accounts are not configured with password never expires or password not required.

The UserPassword attribute for user accounts is not used.

The sIDHistory attribute for user accounts is not used.

User accounts are checked at least weekly for the presence of the sIDHistory attribute.

Account properties accessible by unprivileged users are not used to store passwords.

User account passwords do not use reversible encryption.

Unprivileged user accounts cannot add machines to the domain.

Dedicated privileged service accounts are used to add machines to the domain.

User accounts with unconstrained delegation are reviewed at least annually, and those without an SPN or demonstrated business requirement are removed.

Computer accounts that are not Microsoft AD DS domain controllers are not trusted for delegation to services.

The Domain Computers security group does not have write or modify permissions to any Microsoft Active Directory objects.

Privileged user accounts are members of the Protected Users security group.

The number of user accounts that are members of the Domain Admins, Enterprise Admins or other highly-privileged security groups is minimised.

Service accounts are not members of the Domain Admins, Enterprise Admins or other highly-privileged security groups.

Computer accounts are not members of the Domain Admins, Enterprise Admins or other highly-privileged security groups.

The Domain Computers security group is not a member of any privileged or highly-privileged security groups.

When a user account is disabled, it is removed from all security group memberships.

The Pre-Windows 2000 Compatible Access security group does not contain user accounts.

Strong mapping between certificates and users is enforced.

The EDITF_ATTRIBUTESUBJECTALTNAME2 flag is removed from Microsoft AD CS CA configurations.

The CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is removed from certificate templates.

Unprivileged user accounts do not have write access to certificate templates.

Extended Key Usages that enable user authentication are removed.

CA Certificate Manager approval is required for certificate templates that allow a Subject Alternative Name to be supplied.

Microsoft AD FS servers are administered using a dedicated service account that is not used to administer other systems.

Soft matching between Microsoft AD DS and Microsoft Entra ID is disabled following initial synchronisation activities.

Hard match takeover is disabled for Microsoft Entra Connect servers.

Privileged user accounts are not synchronised between Microsoft AD DS and Microsoft Entra ID.

Security-relevant events for server applications on internet-facing servers are centrally logged.

Security-relevant events for server applications on non-internet-facing servers are centrally logged.

Users are authenticated before they are granted access to a system and its resources.

Authentication methods susceptible to replay attacks are disabled.

LAN Manager and NT LAN Manager authentication methods are disabled.

Multi-factor authentication is used to authenticate users to their organisation’s online services that process, store or communicate their organisation’s sensitive data.

Multi-factor authentication is used to authenticate users to third-party online services that process, store or communicate their organisation’s sensitive data.

Multi-factor authentication (where available) is used to authenticate users to third-party online services that process, store or communicate their organisation’s non-sensitive data.

Multi-factor authentication is used to authenticate users to their organisation’s online customer services that process, store or communicate their organisation’s sensitive customer data.

Multi-factor authentication is used to authenticate users to third-party online customer services that process, store or communicate their organisation’s sensitive customer data.

Multi-factor authentication is used to authenticate customers to online customer services that process, store or communicate sensitive customer data.

When multi-factor authentication is used to authenticate users or customers to online services or online customer services, all other authentication protocols that do not support multi-factor authentication are disabled.

Multi-factor authentication is used to authenticate privileged users of systems.

Multi-factor authentication is used to authenticate unprivileged users of systems.

Multi-factor authentication is used to authenticate users of data repositories.

Multi-factor authentication uses either: something users have and something users know, or something users have that is unlocked by something users know or are.

Multi-factor authentication used for authenticating users of online services is phishing-resistant.

Multi-factor authentication used for authenticating customers of online customer services provides a phishing-resistant option.

Multi-factor authentication used for authenticating customers of online customer services is phishing-resistant.

Multi-factor authentication used for authenticating users of systems is phishing-resistant.

Multi-factor authentication used for authenticating users of data repositories is phishing-resistant.

Memorised secrets used for multi-factor authentication on non-classified, OFFICIAL: Sensitive and PROTECTED systems are a minimum of 6 characters.

Memorised secrets used for multi-factor authentication on SECRET systems are a minimum of 8 characters.

Memorised secrets used for multi-factor authentication on TOP SECRET systems are a minimum of 10 characters.

When phishing-resistant multi-factor authentication is used by user accounts, other non-phishing-resistant multi-factor authentication options are disabled for such user accounts.

When multi-factor authentication is used to authenticate users to online services, online customer services, systems or data repositories – that process, store or communicate their organisation’s sensitive data or sensitive customer data – users are prevented from self-enrolling into multi-factor authentication from untrustworthy devices.

Successful and unsuccessful multi-factor authentication events are centrally logged.

When systems cannot support multi-factor authentication, single-factor authentication using passphrases is implemented instead.

Passphrases used for single-factor authentication on non-classified, OFFICIAL: Sensitive and PROTECTED systems are at least 4 random words with a total minimum length of 15 characters.

Passphrases used for single-factor authentication on SECRET systems are at least 5 random words with a total minimum length of 17 characters.

Passphrases used for single-factor authentication on TOP SECRET systems are at least 6 random words with a total minimum length of 20 characters.

Passphrases used for single-factor authentication are not a list of categorised words; do not form a real sentence in a natural language; and are not constructed from song lyrics, movies, literature or any other publicly available material.

Successful and unsuccessful single-factor authentication events are centrally logged.

Users provide sufficient evidence to verify their identity when requesting new credentials.

Credentials set for user accounts are randomly generated.

Credentials are provided to users via a secure communications channel or, if not possible, split into two parts with one part provided to users and the other part provided to supervisors.

Credentials provided to users are changed on first use.

Credentials, in the form of memorised secrets, are not reused by users across different systems.

Credentials for the built-in Administrator account in each domain are long, unique, unpredictable and managed.

Credentials for break glass accounts, local administrator accounts and service accounts are long, unique, unpredictable and managed.

Credentials for built-in Administrator accounts, break glass accounts, local administrator accounts and service accounts are a minimum of 30 characters.

Credentials for built-in Administrator accounts, break glass accounts, local administrator accounts and service accounts are randomly generated.

Service accounts are created as group Managed Service Accounts.

Credentials for user accounts are changed if: - they are compromised - they are suspected of being compromised - they are discovered stored on networks in the clear - they are discovered being transferred across networks in the clear - membership of a shared user account changes - they have not been changed in the past 12 months.

Credentials for computer accounts are changed if: - they are compromised - they are suspected of being compromised - they have not been changed in the past 30 days.

Credentials for the Kerberos Key Distribution Center’s service account (KRBTGT) are changed twice, allowing for replication to all Microsoft AD DS domain controllers in-between each change, if: - the domain has been directly compromised - the domain is suspected of being compromised - they have not been changed in the past 12 months.

Microsoft AD FS token-signing and encryption certificates are changed twice in quick succession if: - they are compromised - they are suspected of being compromised - they have not been changed in the past 12 months.

Credentials are obscured as they are entered into systems.

Credential hint functionality is not used for systems.

Physical credentials are kept separate from systems they are used to authenticate to, except for when performing authentication activities.

Credentials stored on systems are protected by a password manager; a hardware security module; or by salting, hashing and stretching them before storage within a database.

Private keys for Microsoft AD CS CA servers are protected by a hardware security module.

Memory integrity functionality is enabled.

Local Security Authority protection functionality is enabled.

Credential Guard functionality is enabled.

Remote Credential Guard functionality is enabled.

Cached credentials are limited to one previous logon.

Networks are scanned at least monthly to identify any credentials that are being stored in the clear.

User accounts, except for break glass accounts, are locked out after a maximum of five failed logon attempts.

On a daily basis, outside of business hours and after an appropriate period of inactivity, user sessions are terminated and workstations are restarted.

Services are configured with a session lock that: - activates after a maximum of 15 minutes of user inactivity, a maximum of 12 hours of overall session time or when manually activated by users - blocks access to all session content - requires users to re-authenticate using all authentication factors to unlock the session - denies users the ability to disable the session locking mechanism.

Systems are configured with a screen lock that: - activates after a maximum of 15 minutes of user inactivity, or when manually activated by users - conceals all content on the screen - ensures that the screen does not enter a power saving state before the screen lock is activated - requires users to re-authenticate using all authentication factors to unlock the system - denies users the ability to disable the screen locking mechanism.

Systems have a logon banner that reminds users of their security responsibilities when accessing the system and its resources.

When using a software-based isolation mechanism to share a physical server’s hardware, the isolation mechanism is from a vendor that has demonstrated a commitment to Secure by Design and Secure by Default principles and practices, including secure programming practices and either memory-safe programming languages or less preferably memory-safe programming practices.

When using a software-based isolation mechanism to share a physical server’s hardware, the configuration of the isolation mechanism is hardened by removing unneeded functionality and restricting access to the administrative interface used to manage the isolation mechanism.

When using a software-based isolation mechanism to share a physical server’s hardware, the underlying operating system is hardened.

When using a software-based isolation mechanism to share a physical server’s hardware, patches, updates or vendor mitigations for vulnerabilities are applied to the isolation mechanism and underlying operating system in a timely manner.

When using a software-based isolation mechanism to share a physical server’s hardware, the isolation mechanism or underlying operating system is replaced when it is no longer supported by a vendor.

When using a software-based isolation mechanism to share a physical server’s hardware, integrity monitoring and centralised event logging is performed for the isolation mechanism and underlying operating system.

When using a software-based isolation mechanism to share a physical server’s hardware for SECRET or TOP SECRET computing environments, the physical server and all computing environments are of the same classification and belong to the same security domain.