mondoo-windows-security.mql.yaml

# Copyright (c) Mondoo, Inc.
# SPDX-License-Identifier: BUSL-1.1
policies:
  - uid: mondoo-windows-security
    name: Windows Security
    version: 2.3.2
    license: BUSL-1.1
    tags:
      mondoo.com/category: security
      mondoo.com/platform: windows
    authors:
      - name: Mondoo, Inc
        email: hello@mondoo.com
    docs:
      desc: |-
        ## Overview

        This policy provides prescriptive guidance for establishing a secure configuration posture for Microsoft Windows. This guide was tested against Microsoft Windows 10 Release 20H2 Enterprise.

        ## Local scan

        Local scan refer to scans of files and operating systems where cnspec is installed.

        To scan the `localhost` against this policy:

        ```bash
        cnspec scan local
        ```

        ## Remote scan

        Remote scans use cnspec providers to retrieve on-demand scan results without having to install any agents.

        For a complete list of providers run:

        ```bash
        cnspec scan --help
        ```

        ### Prerequisites

        Remote scans of windows hosts suitable authentication method such as winRM enabled or SSH keys.

        ### Scan a remote Windows (SSH authentication)

        ```bash
        cnspec scan ssh <user>@<IP_ADDRESS> -i /path/to/ssh_key
        ```

        ## Join the community!

        Our goal is to build policies that are simple to deploy, accurate, and actionable.

        If you have any suggestions for how to improve this policy, or if you need support, [join the community](https://github.com/orgs/mondoohq/discussions) in GitHub Discussions.
    groups:
      - title: Core
        filters: |
          asset.family.contains('windows')
        checks:
          - uid: mondoo-windows-security-always-prompt-for-password-upon-connection-is-set-to-enabled
          - uid: mondoo-windows-security-apply-uac-restrictions-to-local-accounts-on-network-logons-is-set-to-enabled
          - uid: mondoo-windows-security-audit-account-lockout-is-set-to-include-failure
          - uid: mondoo-windows-security-audit-application-group-management-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-audit-policy-change-is-set-to-include-success
          - uid: mondoo-windows-security-audit-authentication-policy-change-is-set-to-include-success
          - uid: mondoo-windows-security-audit-authorization-policy-change-is-set-to-include-success
          - uid: mondoo-windows-security-audit-credential-validation-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-detailed-file-share-is-set-to-include-failure
          - uid: mondoo-windows-security-audit-file-share-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-force-audit-policy-subcategory-settings-windows-vista-or-later-to-override
          - uid: mondoo-windows-security-audit-group-membership-is-set-to-include-success
          - uid: mondoo-windows-security-audit-ipsec-driver-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-logoff-is-set-to-include-success
          - uid: mondoo-windows-security-audit-logon-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-mpssvc-rule-level-policy-change-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-other-logonlogoff-events-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-other-object-access-events-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-other-policy-change-events-is-set-to-include-failure
          - uid: mondoo-windows-security-audit-other-system-events-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-pnp-activity-is-set-to-include-success
          - uid: mondoo-windows-security-audit-process-creation-is-set-to-include-success
          - uid: mondoo-windows-security-audit-removable-storage-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-security-group-management-is-set-to-include-success
          - uid: mondoo-windows-security-audit-security-state-change-is-set-to-include-success
          - uid: mondoo-windows-security-audit-security-system-extension-is-set-to-include-success
          - uid: mondoo-windows-security-audit-sensitive-privilege-use-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-shut-down-system-immediately-if-unable-to-log-security-audits
          - uid: mondoo-windows-security-audit-special-logon-is-set-to-include-success
          - uid: mondoo-windows-security-audit-system-integrity-is-set-to-success-and-failure
          - uid: mondoo-windows-security-audit-user-account-management-is-set-to-success-and-failure
          - uid: mondoo-windows-security-configure-smb-v1-client-driver-is-set-to-enabled-disable-driver-recommended
          - uid: mondoo-windows-security-configure-smb-v1-server-is-set-to-disabled
          - uid: mondoo-windows-security-do-not-allow-com-port-redirection-is-set-to-enabled
          - uid: mondoo-windows-security-do-not-allow-drive-redirection-is-set-to-enabled
          - uid: mondoo-windows-security-do-not-allow-lpt-port-redirection-is-set-to-enabled
          - uid: mondoo-windows-security-do-not-allow-passwords-to-be-saved-is-set-to-enabled
          - uid: mondoo-windows-security-do-not-allow-supported-plug-and-play-device-redirection-is-set-to-enabled
          - uid: mondoo-windows-security-do-not-delete-temp-folders-upon-exit-is-set-to-disabled
          - uid: mondoo-windows-security-enable-structured-exception-handling-overwrite-protection-sehop-is-set-to-enabled
          - uid: mondoo-windows-security-enforce-password-history-is-set-to-24-or-more-passwords
          - uid: mondoo-windows-security-maximum-password-age-is-set-to-365-or-fewer-days-but-not-0
          - uid: mondoo-windows-security-minimum-password-age-is-set-to-1-or-more-days
          - uid: mondoo-windows-security-minimum-password-length-is-set-to-14-or-more-characters
          - uid: mondoo-windows-security-netbt-nodetype-configuration-is-set-to-enabled-p-node-recommended
          - uid: mondoo-windows-security-network-access-allow-anonymous-sidname-translation-is-set-to-disabled
          - uid: mondoo-windows-security-network-access-do-not-allow-anonymous-enumeration-of-sam-accounts
          - uid: mondoo-windows-security-network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares
          - uid: mondoo-windows-security-network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-auth
          - uid: mondoo-windows-security-network-access-let-everyone-permissions-apply-to-anonymous-users-is-set-to-disabled
          - uid: mondoo-windows-security-network-access-named-pipes-that-can-be-accessed-anonymously-is-set-to-none
          - uid: mondoo-windows-security-network-access-restrict-anonymous-access-to-named-pipes-and-shares
          - uid: mondoo-windows-security-network-access-restrict-clients-allowed-to-make-remote-calls-to-sam
          - uid: mondoo-windows-security-network-access-shares-that-can-be-accessed-anonymously-is-set-to-none
          - uid: mondoo-windows-security-network-access-sharing-and-security-model-for-local-accounts-is-set-to-classic
          - uid: mondoo-windows-security-network-security-allow-local-system-to-use-computer-identity-for-ntlm
          - uid: mondoo-windows-security-network-security-allow-localsystem-null-session-fallback-is-set-to-disabled
          - uid: mondoo-windows-security-network-security-allow-pku2u-authentication-requests-is-set-to-disabled
          - uid: mondoo-windows-security-network-security-configure-encryption-types-allowed-for-kerberos-is-set-to-aes12
          - uid: mondoo-windows-security-network-security-do-not-store-lan-manager-hash-value-on-next-password-change
          - uid: mondoo-windows-security-network-security-lan-manager-authentication-level-is-set-to-send-ntlmv2-response
          - uid: mondoo-windows-security-network-security-ldap-client-signing-requirements-is-set-to-negotiate-signing
          - uid: mondoo-windows-security-network-security-minimum-session-security-for-ntlm-ssp-based-servers-is-set-to-ntlmv2
          - uid: mondoo-windows-security-network-security-minimum-session-security-for-ntlm-ssp-clients-is-set-to-ntlmv2
          - uid: mondoo-windows-security-password-must-meet-complexity-requirements-is-set-to-enabled
          - uid: mondoo-windows-security-relax-minimum-password-length-limits-is-set-to-enabled
          - uid: mondoo-windows-security-require-secure-rpc-communication-is-set-to-enabled
          - uid: mondoo-windows-security-require-use-of-specific-security-layer-for-remote-rdp-connections-is-set-to
          - uid: mondoo-windows-security-require-user-authentication-for-remote-connections-by-using-network-level-a
          - uid: mondoo-windows-security-set-client-connection-encryption-level-is-set-to-enabled-high-level
          - uid: mondoo-windows-security-set-time-limit-for-active-but-idle-remote-desktop-services-sessions-is-set
          - uid: mondoo-windows-security-set-time-limit-for-disconnected-sessions-is-set-to-enabled-1-minute
          - uid: mondoo-windows-security-store-passwords-using-reversible-encryption-is-set-to-disabled
          - uid: mondoo-windows-security-turn-off-multicast-name-resolution-is-set-to-enabled
          - uid: mondoo-windows-security-wdigest-authentication-is-set-to-disabled
          - uid: mondoo-windows-security-additional-LSA-protection
      - title: Logging
        filters: |
          asset.family.contains('windows')
        checks:
          - uid: mondoo-windows-security-application-control-event-log-behavior-when-the-log-file-reaches-its-maximum
          - uid: mondoo-windows-security-application-specify-the-maximum-log-file-size-kb-is-set-to-enabled-32768
          - uid: mondoo-windows-security-security-control-event-log-behavior-when-the-log-file-reaches-its-maximum-size
          - uid: mondoo-windows-security-security-specify-the-maximum-log-file-size-kb-is-set-to-enabled-196608
          - uid: mondoo-windows-security-setup-control-event-log-behavior-when-the-log-file-reaches-its-maximum-size
          - uid: mondoo-windows-security-setup-specify-the-maximum-log-file-size-kb-is-set-to-enabled-32768
          - uid: mondoo-windows-security-system-control-event-log-behavior-when-the-log-file-reaches-its-maximum-size
          - uid: mondoo-windows-security-system-specify-the-maximum-log-file-size-kb-is-set-to-enabled-32768
      - title: User Rights
        filters: |
          asset.family.contains('windows')
        checks:
          - uid: mondoo-windows-security-2.2.19-l1-ensure-debug-programs-is-empty
queries:
  - uid: mondoo-windows-security-2.2.19-l1-ensure-debug-programs-is-empty
    title: Ensure 'Debug programs' is set to ''
    impact: 100
    mql: |
      secpol.privilegerights['SeDebugPrivilege'] == empty
    docs:
      desc: |
        This policy setting determines which user accounts will have the right to attach a debugger to any process or to the kernel, which provides complete access to sensitive and critical operating system components. Developers who are debugging their own applications do not need to be assigned this user right; however, developers who are debugging new system components will need it.

        The recommended state for this setting is empty.

        > Note: This user right is considered a "sensitive privilege" for the purposes of auditing.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to "":

            ```
            Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Debug programs
            ```
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $Temp = [System.Environment]::GetEnvironmentVariable('TEMP','Machine')
            secedit /export /cfg $Temp\secpol-export.cfg
            (gc $Temp\secpol-export.cfg) -replace("SeDebugPrivilege = \S+", "SeDebugPrivilege = ") | Out-File $Temp\secpol-import.cfg
            secedit /import /db $Temp\secpol-db.sdb /cfg $Temp\secpol-import.cfg
            secedit /configure /db $Temp\secpol-db.sdb
            gpupdate /force
            Remove-Item -Path $Temp\secpol-export.cfg -Force
            Remove-Item -Path $Temp\secpol-import.cfg -Force
            Remove-Item -Path $Temp\secpol-db.sdb -Force
            ```
  - uid: mondoo-windows-security-additional-LSA-protection
    title: Ensure additional LSA protection is enabled
    impact: 100
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'RunAsPPL' ).value == 1
    docs:
      desc: |
        Local Security Authority (LSA) protection is a security feature in Microsoft Windows operating systems that helps to prevent credential theft and other types of attacks that can compromise system security.

        The LSA is responsible for enforcing security policies and managing various security-related tasks, such as authentication and authorization, on a local system. It stores sensitive information such as passwords, user account information, and security tokens.

        LSA protection enhances the security of these sensitive information by restricting access to the LSA subsystem to authorized processes only. It prevents malicious software from accessing or manipulating the LSA, thereby reducing the risk of credential theft and other types of attacks.

        LSA protection is implemented through the use of several techniques such as code integrity checks, access controls, and system call filtering. These techniques work together to prevent unauthorized access and ensure that only trusted processes can interact with the LSA subsystem.

        Overall, LSA protection is an important security feature that helps to secure Windows systems and protect against various types of attacks that can compromise system security.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            Enable LSA protection via GPO:

              - Open the Group Policy Management Console (GPMC).
              - Create a new GPO that is linked at the domain level or that is linked to the organizational unit that contains your computer accounts. Or you can select a GPO that is already deployed.
              - Right-click the GPO, and then select Edit to open the Group Policy Management Editor.
              - Expand Computer Configuration, expand Preferences, and then expand Windows Settings.
              - Right-click Registry, point to New, and then select Registry Item. The New Registry Properties dialog box appears.
              - In the Hive list, select HKEY_LOCAL_MACHINE.
              - In the Key Path list, browse to SYSTEM\CurrentControlSet\Control\Lsa.
              - In the Value name box, type RunAsPPL.
              - In the Value type box, select the REG_DWORD.
              - In the Value data box, type 00000001.
              - Select OK.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'RunAsPPL'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-always-prompt-for-password-upon-connection-is-set-to-enabled
    title: Ensure 'Always prompt for password upon connection' is set to 'Enabled'
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'fPromptForPassword' ).value == 1
    docs:
      desc: |-
        This policy setting specifies whether Remote Desktop Services always prompts the client computer for a password upon connection. You can use this policy setting to enforce a password prompt for users who log on to Remote Desktop Services, even if they already provided the password in the Remote Desktop Connection client.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Security\\Always prompt for password upon connection
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In the Microsoft Windows Vista Administrative Templates, this setting was named _Always prompt client for password upon connection_, but it was renamed starting with the Windows Server 2008 (non-R2) Administrative Templates.

            **Impact:**

            Users cannot automatically log on to Remote Desktop Services by supplying their passwords in the Remote Desktop Connection client. They will be prompted for a password to log on.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'fPromptForPassword'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-application-control-event-log-behavior-when-the-log-file-reaches-its-maximum
    title: 'Ensure ''Application: Control Event Log behavior when the log file reaches its maximum size'' is set to ''Disabled'''
    impact: 30
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\EventLog\Application', name: 'Retention' ).value == '0'
    docs:
      desc: |-
        This policy setting controls Event Log behavior when the log file reaches its maximum size.

        The recommended state for this setting is: `Disabled`.

        **Note:**
        Old events may or may not be retained according to the _Backup log automatically when full_
        policy setting.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Event Log Service\\Application\\Control Event Log behavior when the log file reaches its maximum size
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `EventLog.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was initially named _Retain old events_, but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Policies\Microsoft\Windows\EventLog\Application'
            $Name         = 'Retention'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-application-specify-the-maximum-log-file-size-kb-is-set-to-enabled-32768
    title: 'Ensure ''Application: Specify the maximum log file size (KB)'' is set to ''Enabled: 32,768 or greater'''
    impact: 50
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\EventLog\Application', name: 'MaxSize' ).value >= 32768
    docs:
      desc: |-
        This policy setting specifies the maximum size of the log file in kilobytes. The maximum log file size can be configured between 1 megabyte (1,024 kilobytes) and 4 terabytes (4,194,240 kilobytes) in kilobyte increments.

        The recommended state for this setting is: `Enabled: 32,768 or greater`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: 32,768 or greater`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Event Log Service\\Application\\Specify the maximum log file size (KB)
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `EventLog.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was initially named _Maximum Log Size (KB)_, but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            When event logs fill to capacity, they will stop recording information unless the retention method for each is set so that the computer will overwrite the oldest entries with the most recent ones. To mitigate the risk of loss of recent data, you can configure the retention method so that older events are overwritten as needed.

            The consequence of this configuration is that older events will be removed from the logs. Attackers can take advantage of such a configuration, because they can generate a large number of extraneous events to overwrite any evidence of their attack. These risks can be somewhat reduced if you automate the archival and backup of event log data.

            Ideally, all specifically monitored events should be sent to a server that uses Microsoft System Center Operations Manager (SCOM) or some other automated monitoring tool. Such a configuration is particularly important because an attacker who successfully compromises a server could clear the Security log. If all events are sent to a monitoring server, then you will be able to gather forensic information about the attacker's activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Policies\Microsoft\Windows\EventLog\Application'
            $Name         = 'MaxSize'
            $Value        = '32768'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-apply-uac-restrictions-to-local-accounts-on-network-logons-is-set-to-enabled
    title: Ensure 'Apply UAC restrictions to local accounts on network logons' is set to 'Enabled'
    impact: 90
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System', name: 'LocalAccountTokenFilterPolicy' ).value == 0
    docs:
      desc: |-
        This setting controls whether local accounts can be used for remote administration via network logon (e.g., NET USE, connecting to C$, etc.). Local accounts are at high risk for credential theft when the same account and password is configured on multiple systems. Enabling this policy significantly reduces that risk.

        **Enabled:**
        Applies UAC token-filtering to local accounts on network logons. Membership in powerful group such as Administrators is disabled and powerful privileges are removed from the resulting access token. This configures the `LocalAccountTokenFilterPolicy` registry value to `0`. This is the default behavior for Windows.

        **Disabled:**
        Allows local accounts to have full administrative rights when authenticating via network logon, by configuring the `LocalAccountTokenFilterPolicy` registry value to `1`.

        For more information about local accounts and credential theft, review the " [Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques](https://www.microsoft.com/en-us/download/details.aspx?id=36036)
        " documents.

        For more information about `LocalAccountTokenFilterPolicy`, see Microsoft Knowledge Base article 951016: [Description of User Account Control and remote restrictions in Windows Vista](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction).

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\MS Security Guide\\Apply UAC restrictions to local accounts on network logons
            ```

            **Note:**
            This Group Policy path does not exist by default. An additional Group Policy template ( `SecGuide.admx/adml` ) is required - it is available from Microsoft at
            [this link](https://techcommunity.microsoft.com/t5/Microsoft-Security-Baselines/Security-baseline-FINAL-for-Windows-10-v1903-and-Windows-Server/ba-p/701084).

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
            $Name         = 'LocalAccountTokenFilterPolicy'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-audit-account-lockout-is-set-to-include-failure
    title: Ensure 'Audit Account Lockout' is set to include 'Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure1
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess1
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9217-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9217-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolFailure || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure1)
    docs:
      desc: |-
        This subcategory reports when a user's account is locked out as a result of too many failed logon attempts. Events for this subcategory include:

        - 4625: An account failed to log on.

        The recommended state for this setting is to include: `Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Logon/Logoff\\Audit Account Lockout
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9217-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-application-group-management-is-set-to-success-and-failure
    title: Ensure 'Audit Application Group Management' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure2
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess2
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure1
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9239-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9239-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure2)
    docs:
      desc: |-
        This policy setting allows you to audit events generated by changes to application groups such as the following:

        - Application group is created, changed, or deleted.
        - Member is added or removed from an application group.

        Application groups are utilized by Windows Authorization Manager, which is a flexible framework created by Microsoft for integrating role-based access control (RBAC) into applications. More information on Windows Authorization Manager is available at [MSDN - Windows Authorization Manager](https://msdn.microsoft.com/en-us/library/bb897401.aspx).

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Account Management\\Audit Application Group Management
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9239-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-audit-policy-change-is-set-to-include-success
    title: Ensure 'Audit Audit Policy Change' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: auditpolAuditPolicyChange
        title: A list of Windows audit policy names depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Richtlinienänderungen überwachen";
            case _ == "nl-BE": "Beleidswijzigingen controleren";
            case _ == "it-IT": "Modifica del criterio di controllo";
            default: "Audit Policy Change";
          }
      - uid: mondooWindowsSecurityAuditpolSuccessFailure3
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess3
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure2
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE922F-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE922F-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess3 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure3)
    docs:
      desc: |-
        This subcategory reports changes in audit policy including SACL changes. Events for this subcategory include:

        - 4715: The audit policy (SACL) on an object was changed.
        - 4719: System audit policy was changed.
        - 4902: The Per-user audit policy table was created.
        - 4904: An attempt was made to register a security event source.
        - 4905: An attempt was made to unregister a security event source.
        - 4906: The CrashOnAuditFail value has changed.
        - 4907: Auditing settings on object were changed.
        - 4908: Special Groups Logon table modified.
        - 4912: Per User Audit Policy was changed.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Policy Change\\Audit Audit Policy Change
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE922F-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-authentication-policy-change-is-set-to-include-success
    title: Ensure 'Audit Authentication Policy Change' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure4
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess4
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure3
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9230-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9230-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess4 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure4)
    docs:
      desc: |-
        This subcategory reports changes in authentication policy. Events for this subcategory include:

        - 4706: A new trust was created to a domain.
        - 4707: A trust to a domain was removed.
        - 4713: Kerberos policy was changed.
        - 4716: Trusted domain information was modified.
        - 4717: System security access was granted to an account.
        - 4718: System security access was removed from an account.
        - 4739: Domain Policy was changed.
        - 4864: A namespace collision was detected.
        - 4865: A trusted forest information entry was added.
        - 4866: A trusted forest information entry was removed.
        - 4867: A trusted forest information entry was modified.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Policy Change\\Audit Authentication Policy Change
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9230-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-authorization-policy-change-is-set-to-include-success
    title: Ensure 'Audit Authorization Policy Change' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure5
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess5
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure4
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9231-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9231-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess5 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure5)
    docs:
      desc: |-
        This subcategory reports changes in authorization policy. Events for this subcategory include:

        - 4704: A user right was assigned.
        - 4705: A user right was removed.
        - 4706: A new trust was created to a domain.
        - 4707: A trust to a domain was removed.
        - 4714: Encrypted data recovery policy was changed.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Policy Change\\Audit Authorization Policy Change
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9231-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-credential-validation-is-set-to-success-and-failure
    title: Ensure 'Audit Credential Validation' is set to 'Success and Failure'
    impact: 30
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure6
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess6
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure5
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE923F-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE923F-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure6)
    docs:
      desc: |-
        This subcategory reports the results of validation tests on credentials submitted for a user account logon request. These events occur on the computer that is authoritative for the credentials. For domain accounts, the Domain Controller is authoritative, whereas for local accounts, the local computer is authoritative. In domain environments, most of the Account Logon events occur in the Security log of the Domain Controllers that are authoritative for the domain accounts. However, these events can occur on other computers in the organization when local accounts are used to log on. Events for this subcategory include:

        - 4774: An account was mapped for logon.
        - 4775: An account could not be mapped for logon.
        - 4776: The Domain Controller attempted to validate the credentials for an account.
        - 4777: The Domain Controller failed to validate the credentials for an account.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Account Logon\\Audit Credential Validation
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE923F-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-detailed-file-share-is-set-to-include-failure
    title: Ensure 'Audit Detailed File Share' is set to include 'Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure7
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess7
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure6
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9244-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9244-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolFailure6 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure7)
    docs:
      desc: |-
        This subcategory allows you to audit attempts to access files and folders on a shared folder. Events for this subcategory include:

        - 5145: network share object was checked to see whether client can be granted desired access.

        The recommended state for this setting is to include: `Failure`
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Object Access\\Audit Detailed File Share
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9244-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-file-share-is-set-to-success-and-failure
    title: Ensure 'Audit File Share' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure8
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess8
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure7
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9224-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9224-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure8)
    docs:
      desc: |-
        This policy setting allows you to audit attempts to access a shared folder.

        The recommended state for this setting is: `Success and Failure`.

        **Note:**
        There are no system access control lists (SACLs) for shared folders. If this policy setting is enabled, access to all shared folders on the system is audited.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Object Access\\Audit File Share
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9224-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-force-audit-policy-subcategory-settings-windows-vista-or-later-to-override
    title: 'Ensure ''Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings'' is set to ''Enabled'''
    impact: 30
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'SCENoApplyLegacyAuditPolicy' ).value == 1
    docs:
      desc: |-
        This policy setting allows administrators to enable the more precise auditing capabilities present in Windows Vista.

        The Audit Policy settings available in Windows Server 2003 Active Directory do not yet contain settings for managing the new auditing subcategories. To properly apply the auditing policies prescribed in this baseline, the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings setting needs to be configured to Enabled.

        The recommended state for this setting is: `Enabled`.

        **Important:**
        Be very cautious about audit settings that can generate a large volume of traffic. For example, if you enable either success or failure auditing for all of the Privilege Use subcategories, the high volume of audit events generated can make it difficult to find other types of entries in the Security log. Such a configuration could also have a significant impact on system performance.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
            ```

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'SCENoApplyLegacyAuditPolicy'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-audit-group-membership-is-set-to-include-success
    title: Ensure 'Audit Group Membership' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure9
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess9
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure8
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9249-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9249-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess9 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure9)
    docs:
      desc: |-
        This policy allows you to audit the group membership information in the user's logon token. Events in this subcategory are generated on the computer on which a logon session is created. For an interactive logon, the security audit event is generated on the computer that the user logged on to. For a network logon, such as accessing a shared folder on the network, the security audit event is generated on the computer hosting the resource.

        The recommended state for this setting is to include: `Success`.

        **Note:**
        A Windows 10, Server 2016 or newer OS is required to access and set this value in Group Policy.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Logon/Logoff\\Audit Group Membership
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9249-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-ipsec-driver-is-set-to-success-and-failure
    title: Ensure 'Audit IPsec Driver' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure10
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess10
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure9
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9213-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9213-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure10)
    docs:
      desc: |-
        This subcategory reports on the activities of the Internet Protocol security (IPsec) driver. Events for this subcategory include:

        - 4960: IPsec dropped an inbound packet that failed an integrity check. If this problem persists, it could indicate a network issue or that packets are being modified in transit to this computer. Verify that the packets sent from the remote computer are the same as those received by this computer. This error might also indicate interoperability problems with other IPsec implementations.
        - 4961: IPsec dropped an inbound packet that failed a replay check. If this problem persists, it could indicate a replay attack against this computer.
        - 4962: IPsec dropped an inbound packet that failed a replay check. The inbound packet had too low a sequence number to ensure it was not a replay.
        - 4963: IPsec dropped an inbound clear text packet that should have been secured. This is usually due to the remote computer changing its IPsec policy without informing this computer. This could also be a spoofing attack attempt.
        - 4965: IPsec received a packet from a remote computer with an incorrect Security Parameter Index (SPI). This is usually caused by malfunctioning hardware that is corrupting packets. If these errors persist, verify that the packets sent from the remote computer are the same as those received by this computer. This error may also indicate interoperability problems with other IPsec implementations. In that case, if connectivity is not impeded, then these events can be ignored.
        - 5478: IPsec Services has started successfully.
        - 5479: IPsec Services has been shut down successfully. The shutdown of IPsec Services can put the computer at greater risk of network attack or expose the computer to potential security risks.
        - 5480: IPsec Services failed to get the complete list of network interfaces on the computer. This poses a potential security risk because some of the network interfaces may not get the protection provided by the applied IPsec filters. Use the IP Security Monitor snap-in to diagnose the problem.
        - 5483: IPsec Services failed to initialize RPC server. IPsec Services could not be started.
        - 5484: IPsec Services has experienced a critical failure and has been shut down. The shutdown of IPsec Services can put the computer at greater risk of network attack or expose the computer to potential security risks.
        - 5485: IPsec Services failed to process some IPsec filters on a plug-and-play event for network interfaces. This poses a potential security risk because some of the network interfaces may not get the protection provided by the applied IPsec filters. Use the IP Security Monitor snap-in to diagnose the problem.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\System\\Audit IPsec Driver
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9213-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-logoff-is-set-to-include-success
    title: Ensure 'Audit Logoff' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure11
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess11
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure10
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9216-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9216-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess11 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure11)
    docs:
      desc: |-
        This subcategory reports when a user logs off from the system. These events occur on the accessed computer. For interactive logons, the generation of these events occurs on the computer that is logged on to. If a network logon takes place to access a share, these events generate on the computer that hosts the accessed resource. If you configure this setting to No auditing, it is difficult or impossible to determine which user has accessed or attempted to access organization computers. Events for this subcategory include:

        - 4634: An account was logged off.
        - 4647: User initiated logoff.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Logon/Logoff\\Audit Logoff
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9216-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-logon-is-set-to-success-and-failure
    title: Ensure 'Audit Logon' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure12
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess12
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure11
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9215-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9215-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure12)
    docs:
      desc: |-
        This subcategory reports when a user attempts to log on to the system. These events occur on the accessed computer. For interactive logons, the generation of these events occurs on the computer that is logged on to. If a network logon takes place to access a share, these events generate on the computer that hosts the accessed resource. If you configure this setting to No auditing, it is difficult or impossible to determine which user has accessed or attempted to access organization computers. Events for this subcategory include:

        - 4624: An account was successfully logged on.
        - 4625: An account failed to log on.
        - 4648: A logon was attempted using explicit credentials.
        - 4675: SIDs were filtered.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Logon/Logoff\\Audit Logon
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9215-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-mpssvc-rule-level-policy-change-is-set-to-success-and-failure
    title: Ensure 'Audit MPSSVC Rule-Level Policy Change' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure13
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess13
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure12
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9232-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9232-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure13)
    docs:
      desc: |-
        This subcategory determines whether the operating system generates audit events when changes are made to policy rules for the Microsoft Protection Service (MPSSVC.exe). Events for this subcategory include:

        - 4944: The following policy was active when the Windows Firewall started.
        - 4945: A rule was listed when the Windows Firewall started.
        - 4946: A change has been made to Windows Firewall exception list. A rule was added.
        - 4947: A change has been made to Windows Firewall exception list. A rule was modified.
        - 4948: A change has been made to Windows Firewall exception list. A rule was deleted.
        - 4949: Windows Firewall settings were restored to the default values.
        - 4950: A Windows Firewall setting has changed.
        - 4951: A rule has been ignored because its major version number was not recognized by Windows Firewall.
        - 4952: Parts of a rule have been ignored because its minor version number was not recognized by Windows Firewall. The other parts of the rule will be enforced.
        - 4953: A rule has been ignored by Windows Firewall because it could not parse the rule.
        - 4954: Windows Firewall Group Policy settings have changed. The new settings have been applied.
        - 4956: Windows Firewall has changed the active profile.
        - 4957: Windows Firewall did not apply the following rule.
        - 4958: Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer.


        The recommended state for this setting is : `Success and Failure`
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Policy Change\\Audit MPSSVC Rule-Level Policy Change
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9232-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-other-logonlogoff-events-is-set-to-success-and-failure
    title: Ensure 'Audit Other Logon/Logoff Events' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure14
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess14
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure13
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE921C-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE921C-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure14)
    docs:
      desc: |-
        This subcategory reports other logon/logoff-related events, such as Remote Desktop Services session disconnects and reconnects, using RunAs to run processes under a different account, and locking and unlocking a workstation. Events for this subcategory include:

        - 4649: A replay attack was detected.
        - 4778: A session was reconnected to a Window Station.
        - 4779: A session was disconnected from a Window Station.
        - 4800: The workstation was locked.
        - 4801: The workstation was unlocked.
        - 4802: The screen saver was invoked.
        - 4803: The screen saver was dismissed.
        - 5378: The requested credentials delegation was disallowed by policy.
        - 5632: A request was made to authenticate to a wireless network.
        - 5633: A request was made to authenticate to a wired network.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Logon/Logoff\\Audit Other Logon/Logoff Events
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE921C-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-other-object-access-events-is-set-to-success-and-failure
    title: Ensure 'Audit Other Object Access Events' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure15
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess15
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure14
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9227-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9227-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure15)
    docs:
      desc: |-
        This policy setting allows you to audit events generated by the management of task scheduler jobs or COM+ objects.

        For scheduler jobs, the following are audited:

        - Job created.
        - Job deleted.
        - Job enabled.
        - Job disabled.
        - Job updated.

        For COM+ objects, the following are audited:

        - Catalog object added.
        - Catalog object updated.
        - Catalog object deleted.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Object Access\\Audit Other Object Access Events
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9227-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-other-policy-change-events-is-set-to-include-failure
    title: Ensure 'Audit Other Policy Change Events' is set to include 'Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure16
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess16
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure15
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9234-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9234-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolFailure15)
    docs:
      desc: |-
        This subcategory contains events about EFS Data Recovery Agent policy changes, changes in Windows Filtering Platform filter, status on Security policy settings updates for local Group Policy settings, Central Access Policy changes, and detailed troubleshooting events for Cryptographic Next Generation (CNG) operations.

        - 5063: A cryptographic provider operation was attempted.
        - 5064: A cryptographic context operation was attempted.
        - 5065: A cryptographic context modification was attempted.
        - 5066: A cryptographic function operation was attempted.
        - 5067: A cryptographic function modification was attempted.
        - 5068: A cryptographic function provider operation was attempted.
        - 5069: A cryptographic function property operation was attempted.
        - 5070: A cryptographic function property modification was attempted.
        - 6145: One or more errors occurred while processing security policy in the Group Policy Objects.

        The recommended state for this setting is to include: `Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Policy Change\\Audit Other Policy Change Events
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9234-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-other-system-events-is-set-to-success-and-failure
    title: Ensure 'Audit Other System Events' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure16
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess17
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure16
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9214-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9214-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure16)
    docs:
      desc: |-
        This subcategory reports on other system events. Events for this subcategory include:

        - 5024 : The Windows Firewall Service has started successfully.
        - 5025 : The Windows Firewall Service has been stopped.
        - 5027 : The Windows Firewall Service was unable to retrieve the security policy from the local storage. The service will continue enforcing the current policy.
        - 5028 : The Windows Firewall Service was unable to parse the new security policy. The service will continue with currently enforced policy.
        - 5029: The Windows Firewall Service failed to initialize the driver. The service will continue to enforce the current policy.
        - 5030: The Windows Firewall Service failed to start.
        - 5032: Windows Firewall was unable to notify the user that it blocked an application from accepting incoming connections on the network.
        - 5033 : The Windows Firewall Driver has started successfully.
        - 5034 : The Windows Firewall Driver has been stopped.
        - 5035 : The Windows Firewall Driver failed to start.
        - 5037 : The Windows Firewall Driver detected critical runtime error. Terminating.
        - 5058: Key file operation.
        - 5059: Key migration operation.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\System\\Audit Other System Events
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9214-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-pnp-activity-is-set-to-include-success
    title: Ensure 'Audit PNP Activity' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure17
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess18
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure17
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9248-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9248-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess18 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure17)
    docs:
      desc: |-
        This policy setting allows you to audit when plug and play detects an external device.

        The recommended state for this setting is to include: `Success`.

        **Note:**
        A Windows 10, Server 2016 or newer OS is required to access and set this value in Group Policy.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Detailed Tracking\\Audit PNP Activity
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9248-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-process-creation-is-set-to-include-success
    title: Ensure 'Audit Process Creation' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure18
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess19
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure18
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE922B-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE922B-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess19 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure18)
    docs:
      desc: |-
        This subcategory reports the creation of a process and the name of the program or user that created it. Events for this subcategory include:

        - 4688: A new process has been created.
        - 4696: A primary token was assigned to process.

        Refer to Microsoft Knowledge Base article 947226: [Description of security events in Windows Vista and in Windows Server 2008](https://support.microsoft.com/en-us/kb/947226)
        for the most recent information about this setting.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Detailed Tracking\\Audit Process Creation
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE922B-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-removable-storage-is-set-to-success-and-failure
    title: Ensure 'Audit Removable Storage' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure19
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess20
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure19
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9245-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9245-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure19)
    docs:
      desc: |-
        This policy setting allows you to audit user attempts to access file system objects on a removable storage device. A security audit event is generated only for all objects for all types of access requested. If you configure this policy setting, an audit event is generated each time an account accesses a file system object on a removable storage. Success audits record successful attempts and Failure audits record unsuccessful attempts. If you do not configure this policy setting, no audit event is generated when an account accesses a file system object on a removable storage.

        The recommended state for this setting is: `Success and Failure`.

        **Note:**
        A Windows 8.0, Server 2012 (non-R2) or newer OS is required to access and set this value in Group Policy.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Object Access\\Audit Removable Storage
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9245-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-security-group-management-is-set-to-include-success
    title: Ensure 'Audit Security Group Management' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure20
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess21
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure20
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9237-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9237-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess21 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure20)
    docs:
      desc: |-
        This subcategory reports each event of security group management, such as when a security group is created, changed, or deleted or when a member is added to or removed from a security group. If you enable this Audit policy setting, administrators can track events to detect malicious, accidental, and authorized creation of security group accounts. Events for this subcategory include:

        - 4727: A security-enabled global group was created.
        - 4728: A member was added to a security-enabled global group.
        - 4729: A member was removed from a security-enabled global group.
        - 4730: A security-enabled global group was deleted.
        - 4731: A security-enabled local group was created.
        - 4732: A member was added to a security-enabled local group.
        - 4733: A member was removed from a security-enabled local group.
        - 4734: A security-enabled local group was deleted.
        - 4735: A security-enabled local group was changed.
        - 4737: A security-enabled global group was changed.
        - 4754: A security-enabled universal group was created.
        - 4755: A security-enabled universal group was changed.
        - 4756: A member was added to a security-enabled universal group.
        - 4757: A member was removed from a security-enabled universal group.
        - 4758: A security-enabled universal group was deleted.
        - 4764: A group's type was changed.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success:`

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Account Management\\Audit Security Group Management
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9237-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-security-state-change-is-set-to-include-success
    title: Ensure 'Audit Security State Change' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure21
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess22
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure21
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9210-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9210-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess22 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure21)
    docs:
      desc: |-
        This subcategory reports changes in security state of the system, such as when the security subsystem starts and stops. Events for this subcategory include:

        - 4608: Windows is starting up.
        - 4609: Windows is shutting down.
        - 4616: The system time was changed.
        - 4621: Administrator recovered system from CrashOnAuditFail. Users who are not administrators will now be allowed to log on. Some audit-able activity might not have been recorded.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\System\\Audit Security State Change
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9210-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-security-system-extension-is-set-to-include-success
    title: Ensure 'Audit Security System Extension' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure22
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess23
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure22
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9211-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9211-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess23 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure22)
    docs:
      desc: |-
        This subcategory reports the loading of extension code such as authentication packages by the security subsystem. Events for this subcategory include:

        - 4610: An authentication package has been loaded by the Local Security Authority.
        - 4611: A trusted logon process has been registered with the Local Security Authority.
        - 4614: A notification package has been loaded by the Security Account Manager.
        - 4622: A security package has been loaded by the Local Security Authority.
        - 4697: A service was installed in the system.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\System\\Audit Security System Extension
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9211-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-sensitive-privilege-use-is-set-to-success-and-failure
    title: Ensure 'Audit Sensitive Privilege Use' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure23
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess24
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure23
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9228-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9228-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure23)
    docs:
      desc: |-
        This subcategory reports when a user account or service uses a sensitive privilege. A sensitive privilege includes the following user rights:

        - Act as part of the operating system
        - Back up files and directories
        - Create a token object
        - Debug programs
        - Enable computer and user accounts to be trusted for delegation
        - Generate security audits
        - Impersonate a client after authentication
        - Load and unload device drivers
        - Manage auditing and security log
        - Modify firmware environment values
        - Replace a process-level token
        - Restore files and directories
        - Take ownership of files or other objects

        Auditing this subcategory will create a high volume of events. Events for this subcategory include:

        - 4672: Special privileges assigned to new logon.
        - 4673: A privileged service was called.
        - 4674: An operation was attempted on a privileged object.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Privilege Use\\Audit Sensitive Privilege Use
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9228-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-shut-down-system-immediately-if-unable-to-log-security-audits
    title: 'Ensure ''Audit: Shut down system immediately if unable to log security audits'' is set to ''Disabled'''
    impact: 30
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA', name: 'CrashOnAuditFail' ).value == 0
    docs:
      desc: |-
        This policy setting determines whether the system shuts down if it is unable to log Security events. It is a requirement for Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log them. Microsoft has chosen to meet this requirement by halting the system and displaying a stop message if the auditing system experiences a failure. When this policy setting is enabled, the system will be shut down if a security audit cannot be logged for any reason.

        If the Audit: Shut down system immediately if unable to log security audits setting is enabled, unplanned system failures can occur. The administrative burden can be significant, especially if you also configure the Retention method for the Security log to Do not overwrite events (clear log manually). This configuration causes a repudiation threat (a backup operator could deny that they backed up or restored data) to become a denial of service (DoS) vulnerability, because a server could be forced to shut down if it is overwhelmed with logon events and other security events that are written to the Security log. Also, because the shutdown is not graceful, it is possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system guarantees its integrity when an ungraceful computer shutdown occurs, it cannot guarantee that every data file for every application will still be in a usable form when the computer restarts.

        The recommended state for this setting is: `Disabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Audit: Shut down system immediately if unable to log security audits
            ```

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\LSA'
            $Name         = 'CrashOnAuditFail'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-audit-special-logon-is-set-to-include-success
    title: Ensure 'Audit Special Logon' is set to include 'Success'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure24
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess25
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure24
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE921B-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE921B-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccess25 || inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure24)
    docs:
      desc: |-
        This subcategory reports when a special logon is used. A special logon is a logon that has administrator-equivalent privileges and can be used to elevate a process to a higher level. Events for this subcategory include:

        - 4964 : Special groups have been assigned to a new logon.

        The recommended state for this setting is to include: `Success`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to include `Success`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Logon/Logoff\\Audit Special Logon
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE921B-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-system-integrity-is-set-to-success-and-failure
    title: Ensure 'Audit System Integrity' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure25
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess26
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure25
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9212-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9212-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure25)
    docs:
      desc: |-
        This subcategory reports on violations of integrity of the security subsystem. Events for this subcategory include:

        - 4612 : Internal resources allocated for the queuing of audit messages have been exhausted, leading to the loss of some audits.
        - 4615 : Invalid use of LPC port.
        - 4618 : A monitored security event pattern has occurred.
        - 4816 : RPC detected an integrity violation while decrypting an incoming message.
        - 5038 : Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.
        - 5056: A cryptographic self test was performed.
        - 5057: A cryptographic primitive operation failed.
        - 5060: Verification operation failed.
        - 5061: Cryptographic operation.
        - 5062: A kernel-mode cryptographic self test was performed.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure:`

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\System\\Audit System Integrity
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9212-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-audit-user-account-management-is-set-to-success-and-failure
    title: Ensure 'Audit User Account Management' is set to 'Success and Failure'
    impact: 40
    filters: |
      asset.platform == "windows"
    props:
      - uid: mondooWindowsSecurityAuditpolSuccessFailure26
        title: Returns 'Success and Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg und Fehler";
            case _ == "it-IT": "Esito positivo e negativo";
            default: "Success and Failure";
          }
      - uid: mondooWindowsSecurityAuditpolSuccess27
        title: Returns 'Success' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Erfolg";
            case _ == "it-IT": "Operazione riuscita";
            default: "Success";
          }
      - uid: mondooWindowsSecurityAuditpolFailure26
        title: Returns 'Failure' depending on the operating system language
        mql: |
          switch(windows.computerInfo['OsLocale']) {
            case _ == "de-DE": "Fehler";
            case _ == "it-IT": "Errore";
            default: "Failure";
          }
    mql: |
      auditpol.where(subcategoryguid == "0CCE9235-69AE-11D9-BED3-505054503030").list != []
      auditpol.where(subcategoryguid == "0CCE9235-69AE-11D9-BED3-505054503030").all(inclusionsetting == props.mondooWindowsSecurityAuditpolSuccessFailure26)
    docs:
      desc: |-
        This subcategory reports each event of user account management, such as when a user account is created, changed, or deleted; a user account is renamed, disabled, or enabled; or a password is set or changed. If you enable this Audit policy setting, administrators can track events to detect malicious, accidental, and authorized creation of user accounts. Events for this subcategory include:

        - 4720: A user account was created.
        - 4722: A user account was enabled.
        - 4723: An attempt was made to change an account's password.
        - 4724: An attempt was made to reset an account's password.
        - 4725: A user account was disabled.
        - 4726: A user account was deleted.
        - 4738: A user account was changed.
        - 4740: A user account was locked out.
        - 4765: SID History was added to an account.
        - 4766: An attempt to add SID History to an account failed.
        - 4767: A user account was unlocked.
        - 4780: The ACL was set on accounts which are members of administrators groups.
        - 4781: The name of an account was changed:
        - 4794: An attempt was made to set the Directory Services Restore Mode.
        - 5376: Credential Manager credentials were backed up.
        - 5377: Credential Manager credentials were restored from a backup.

        The recommended state for this setting is: `Success and Failure`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Success and Failure`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Advanced Audit Policy Configuration\\Audit Policies\\Account Management\\Audit User Account Management
            ```

            **Impact:**

            If no audit settings are configured, or if audit settings are too lax on the computers in your organization, security incidents might not be detected or not enough evidence will be available for network forensic analysis after security incidents occur. However, if audit settings are too severe, critically important entries in the Security log may be obscured by all of the meaningless entries and computer performance and the available amount of data storage may be seriously affected. Companies that operate in certain regulated industries may have legal obligations to log certain events or activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            Auditpol /set /subcategory:"{0CCE9235-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable
            ```
  - uid: mondoo-windows-security-configure-smb-v1-client-driver-is-set-to-enabled-disable-driver-recommended
    title: 'Ensure ''Configure SMB v1 client driver'' is set to ''Enabled: Disable driver (recommended)'''
    impact: 100
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\mrxsmb10', name: 'Start' ).value == 4
    docs:
      desc: |-
        This setting configures the start type for the Server Message Block version 1 (SMBv1) client driver service ( `MRxSmb10` ), which is recommended to be disabled.

        The recommended state for this setting is: `Enabled: Disable driver (recommended)`.

        **Note:**
        Do not, _under any circumstances_, configure this overall setting as `Disabled`, as doing so will delete the underlying registry entry altogether, which will cause serious problems.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: Disable driver (recommended)`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\MS Security Guide\\Configure SMB v1 client driver
            ```

            **Note:**
            This Group Policy path does not exist by default. An additional Group Policy template ( `SecGuide.admx/adml` ) is required - it is available from Microsoft at [this link](https://techcommunity.microsoft.com/t5/Microsoft-Security-Baselines/Security-baseline-FINAL-for-Windows-10-v1903-and-Windows-Server/ba-p/701084)

            **Impact:**

            Some legacy OSes (e.g. Windows XP, Server 2003 or older), applications and appliances may no longer be able to communicate with the system once SMBv1 is disabled. We recommend careful testing be performed to determine the impact prior to configuring this as a widespread control, and where possible, remediate any incompatibilities found with the vendor of the incompatible system. Microsoft is also maintaining a thorough (although not comprehensive) list of known SMBv1 incompatibilities at this link: [SMB1 Product Clearinghouse \| Storage at Microsoft](https://blogs.technet.microsoft.com/filecab/2017/06/01/smb1-product-clearinghouse/)
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\mrxsmb10'
            $Name         = 'Start'
            $Value        = '4'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-configure-smb-v1-server-is-set-to-disabled
    title: Ensure 'Configure SMB v1 server' is set to 'Disabled'
    impact: 100
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters', name: 'SMB1' ).value == 0
    docs:
      desc: |-
        This setting configures the server-side processing of the Server Message Block version 1 (SMBv1) protocol.

        The recommended state for this setting is: `Disabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\MS Security Guide\\Configure SMB v1 server
            ```

            **Note:**
            This Group Policy path does not exist by default. An additional Group Policy template ( `SecGuide.admx/adml` ) is required - it is available from Microsoft at [this link](https://techcommunity.microsoft.com/t5/Microsoft-Security-Baselines/Security-baseline-FINAL-for-Windows-10-v1903-and-Windows-Server/ba-p/701084)

            **Impact:**

            Some legacy OSes (e.g. Windows XP, Server 2003 or older), applications and appliances may no longer be able to communicate with the system once SMBv1 is disabled. We recommend careful testing be performed to determine the impact prior to configuring this as a widespread control, and where possible, remediate any incompatibilities found with the vendor of the incompatible system. Microsoft is also maintaining a thorough (although not comprehensive) list of known SMBv1 incompatibilities at this link: [SMB1 Product Clearinghouse \| Storage at Microsoft](https://blogs.technet.microsoft.com/filecab/2017/06/01/smb1-product-clearinghouse/)
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters'
            $Name         = 'SMB1'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-do-not-allow-com-port-redirection-is-set-to-enabled
    title: Ensure 'Do not allow COM port redirection' is set to 'Enabled'
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'fDisableCcm' ).value == 1
    docs:
      desc: |-
        This policy setting specifies whether to prevent the redirection of data to client COM ports from the remote computer in a Remote Desktop Services session.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Device and Resource Redirection\\Do not allow COM port redirection
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            Users in a Remote Desktop Services session will not be able to redirect server data to local (client) COM ports.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'fDisableCcm'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-do-not-allow-drive-redirection-is-set-to-enabled
    title: Ensure 'Do not allow drive redirection' is set to 'Enabled'
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'fDisableCdm' ).value == 1
    docs:
      desc: |-
        This policy setting prevents users from sharing the local drives on their client computers to Remote Desktop Servers that they access. Mapped drives appear in the session folder tree in Windows Explorer in the following format:

        `\\\TSClient\\<driveletter>$`

        If local drives are shared they are left vulnerable to intruders who want to exploit the data that is stored on them.

        The recommended state for this setting is: `Enabled`
        .
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Device and Resource Redirection\\Do not allow drive redirection
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            Drive redirection will not be possible. In most situations, traditional network drive mapping to file shares (including administrative shares) performed manually by the connected user will serve as a capable substitute to still allow file transfers when needed.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'fDisableCdm'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-do-not-allow-lpt-port-redirection-is-set-to-enabled
    title: Ensure 'Do not allow LPT port redirection' is set to 'Enabled'
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'fDisableLPT' ).value == 1
    docs:
      desc: |-
        This policy setting specifies whether to prevent the redirection of data to client LPT ports during a Remote Desktop Services session.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Device and Resource Redirection\\Do not allow LPT port redirection
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            Users in a Remote Desktop Services session will not be able to redirect server data to local (client) LPT ports.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'fDisableLPT'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-do-not-allow-passwords-to-be-saved-is-set-to-enabled
    title: Ensure 'Do not allow passwords to be saved' is set to 'Enabled'
    impact: 100
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'DisablePasswordSaving' ).value == 1
    docs:
      desc: |-
        This policy setting helps prevent Remote Desktop clients from saving passwords on a computer.

        The recommended state for this setting is: `Enabled`.

        **Note:**
        If this policy setting was previously configured as Disabled or Not configured, any previously saved passwords will be deleted the first time a Remote Desktop client disconnects from any server.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Connection Client\\Do not allow passwords to be saved
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            The password saving checkbox will be disabled for Remote Desktop clients and users will not be able to save passwords.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'DisablePasswordSaving'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-do-not-allow-supported-plug-and-play-device-redirection-is-set-to-enabled
    title: Ensure 'Do not allow supported Plug and Play device redirection' is set to 'Enabled'
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'fDisablePNPRedir' ).value == 1
    docs:
      desc: |-
        This policy setting allows you to control the redirection of supported Plug and Play devices, such as Windows Portable Devices, to the remote computer in a Remote Desktop Services session.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Device and Resource Redirection\\Do not allow supported Plug and Play device redirection
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            Users in a Remote Desktop Services session will not be able to redirect their supported (local client) Plug and Play devices to the remote computer.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'fDisablePNPRedir'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-do-not-delete-temp-folders-upon-exit-is-set-to-disabled
    title: Ensure 'Do not delete temp folders upon exit' is set to 'Disabled'
    impact: 50
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'DeleteTempDirsOnExit' ).value == 1
    docs:
      desc: |-
        This policy setting specifies whether Remote Desktop Services retains a user's per-session temporary folders at logoff.

        The recommended state for this setting is: `Disabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Temporary Folders\\Do not delete temp folders upon exit
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was named _Do not delete temp folder upon exit_, but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'DeleteTempDirsOnExit'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-enable-structured-exception-handling-overwrite-protection-sehop-is-set-to-enabled
    title: Ensure 'Enable Structured Exception Handling Overwrite Protection (SEHOP)' is set to 'Enabled'
    impact: 100
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel', name: 'DisableExceptionChainValidation' ).value == 0
    docs:
      desc: |-
        Windows includes support for Structured Exception Handling Overwrite Protection (SEHOP). We recommend enabling this feature to improve the security profile of the computer.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\MS Security Guide\\Enable Structured Exception Handling Overwrite Protection (SEHOP)
            ```

            **Note:**
            This Group Policy path does not exist by default. An additional Group Policy template ( `SecGuide.admx/adml` ) is required - it is available from Microsoft at [this link](https://techcommunity.microsoft.com/t5/Microsoft-Security-Baselines/Security-baseline-FINAL-for-Windows-10-v1903-and-Windows-Server/ba-p/701084)

            More information is available at [How to enable Structured Exception Handling Overwrite Protection (SEHOP) in Windows operating systems](https://support.microsoft.com/en-us/help/956607/how-to-enable-structured-exception-handling-overwrite-protection-sehop)

            **Impact:**

            After you enable SEHOP, existing versions of Cygwin, Skype, and Armadillo-protected applications may not work correctly.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\kernel'
            $Name         = 'DisableExceptionChainValidation'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-enforce-password-history-is-set-to-24-or-more-passwords
    title: Ensure 'Enforce password history' is set to '24 or more password(s)'
    impact: 80
    mql: |
      secpol.systemaccess['PasswordHistorySize'] >= 24
    docs:
      desc: |-
        This policy setting determines the number of renewed, unique passwords that have to be associated with a user account before you can reuse an old password. The value for this policy setting must be between 0 and 24 passwords. The default value for Windows Vista is 0 passwords, but the default setting in a domain is 24 passwords. To maintain the effectiveness of this policy setting, use the Minimum password age setting to prevent users from repeatedly changing their password.

        The recommended state for this setting is: `24 or more password(s)`.

        **Note:**
        Password Policy settings (section 1.1) and Account Lockout Policy settings (section 1.2) must be applied via the **Default Domain Policy**
        GPO in order to be globally in effect on **domain**
        user accounts as their default behavior. If these settings are configured in another GPO, they will only affect **local**
        user accounts on the computers that receive the GPO. However, custom exceptions to the default password policy and account lockout policy rules for specific domain users and/or groups can be defined using Password Settings Objects (PSOs), which are completely separate from Group Policy and most easily configured using Active Directory Administrative Center.

        **Note #2:**
        As of the publication of this benchmark, Microsoft currently has a maximum limit of 24 saved passwords. For more information, please visit [Enforce password history (Windows 10) - Windows security \| Microsoft Docs](https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enforce-password-history#:~:text=The%20Enforce%20password%20history%20policy,a%20long%20period%20of%20time.)
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `24 or more password(s)`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\Enforce password history
            ```

            **Impact:**

            The major impact of this configuration is that users must create a new password every time they are required to change their old one. If users are required to change their passwords to new unique values, there is an increased risk of users who write their passwords somewhere so that they do not forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization but make them easier to guess. Also, an excessively low value for the Minimum password age setting will likely increase administrative overhead, because users who forget their passwords might ask the help desk to reset them frequently.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $Temp = [System.Environment]::GetEnvironmentVariable('TEMP','Machine')
            secedit /export /cfg $Temp\secpol-export.cfg
            (gc $Temp\secpol-export.cfg) -replace("PasswordHistorySize = \d+", "PasswordHistorySize = 24") | Out-File $Temp\secpol-import.cfg
            secedit /import /db $Temp\secpol-db.sdb /cfg $Temp\secpol-import.cfg
            secedit /configure /db $Temp\secpol-db.sdb
            gpupdate /force
            Remove-Item -Path $Temp\secpol-export.cfg -Force
            Remove-Item -Path $Temp\secpol-import.cfg -Force
            Remove-Item -Path $Temp\secpol-db.sdb -Force
            ```
  - uid: mondoo-windows-security-maximum-password-age-is-set-to-365-or-fewer-days-but-not-0
    title: Ensure 'Maximum password age' is set to '365 or fewer days, but not 0'
    impact: 60
    mql: |
      secpol.systemaccess['MaximumPasswordAge'] <= 365
      secpol.systemaccess['MaximumPasswordAge'] > 0
    docs:
      desc: |-
        This policy setting defines how long a user can use their password before it expires.

        Values for this policy setting range from 0 to 999 days. If you set the value to 0, the password will never expire.

        Because attackers can crack passwords, the more frequently you change the password the less opportunity an attacker has to use a cracked password. However, the lower this value is set, the higher the potential for an increase in calls to help desk support due to users having to change their password or forgetting which password is current.

        The recommended state for this setting is `365 or fewer days, but not 0`.

        **Note:**
        Password Policy settings (section 1.1) and Account Lockout Policy settings (section 1.2) must be applied via the **Default Domain Policy**
        GPO in order to be globally in effect on **domain**
        user accounts as their default behavior. If these settings are configured in another GPO, they will only affect **local**
        user accounts on the computers that receive the GPO. However, custom exceptions to the default password policy and account lockout policy rules for specific domain users and/or groups can be defined using Password Settings Objects (PSOs), which are completely separate from Group Policy and most easily configured using Active Directory Administrative Center.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `365 or fewer days, but not 0`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\Maximum password age
            ```

            **Impact:**

            If the Maximum password age setting is too low, users are required to change their passwords very often. Such a configuration can reduce security in the organization, because users might write their passwords in an insecure location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $Temp = [System.Environment]::GetEnvironmentVariable('TEMP','Machine')
            secedit /export /cfg $Temp\secpol-export.cfg
            (gc $Temp\secpol-export.cfg) -replace("MaximumPasswordAge = \d+", "MaximumPasswordAge = 365") | Out-File $Temp\secpol-import.cfg
            secedit /import /db $Temp\secpol-db.sdb /cfg $Temp\secpol-import.cfg
            secedit /configure /db $Temp\secpol-db.sdb
            gpupdate /force
            Remove-Item -Path $Temp\secpol-export.cfg -Force
            Remove-Item -Path $Temp\secpol-import.cfg -Force
            Remove-Item -Path $Temp\secpol-db.sdb -Force
            ```
  - uid: mondoo-windows-security-minimum-password-age-is-set-to-1-or-more-days
    title: Ensure 'Minimum password age' is set to '1 or more day(s)'
    impact: 60
    mql: |
      secpol.systemaccess['MinimumPasswordAge'] >= 1
    docs:
      desc: |-
        This policy setting determines the number of days that you must use a password before you can change it. The range of values for this policy setting is between 1 and 999 days. (You may also set the value to 0 to allow immediate password changes.) The default value for this setting is 0 days.

        The recommended state for this setting is: `1 or more day(s))`.

        **Note:**
        Password Policy settings (section 1.1) and Account Lockout Policy settings (section 1.2) must be applied via the **Default Domain Policy**

        GPO in order to be globally in effect on **domain**
        user accounts as their default behavior. If these settings are configured in another GPO, they will only affect **local**
        user accounts on the computers that receive the GPO. However, custom exceptions to the default password policy and account lockout policy rules for specific domain users and/or groups can be defined using Password Settings Objects (PSOs), which are completely separate from Group Policy and most easily configured using Active Directory Administrative Center.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `1 or more day(s)`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\Minimum password age
            ```

            **Impact:**

            If an administrator sets a password for a user but wants that user to change the password when the user first logs on, the administrator must select the User must change password at next logon check box, or the user will not be able to change the password until the next day.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $Temp = [System.Environment]::GetEnvironmentVariable('TEMP','Machine')
            secedit /export /cfg $Temp\secpol-export.cfg
            (gc $Temp\secpol-export.cfg) -replace("MinimumPasswordAge = \d+", "MinimumPasswordAge = 1") | Out-File $Temp\secpol-import.cfg
            secedit /import /db $Temp\secpol-db.sdb /cfg $Temp\secpol-import.cfg
            secedit /configure /db $Temp\secpol-db.sdb
            gpupdate /force
            Remove-Item -Path $Temp\secpol-export.cfg -Force
            Remove-Item -Path $Temp\secpol-import.cfg -Force
            Remove-Item -Path $Temp\secpol-db.sdb -Force
            ```
  - uid: mondoo-windows-security-minimum-password-length-is-set-to-14-or-more-characters
    title: Ensure 'Minimum password length' is set to '14 or more character(s)'
    impact: 100
    filters: asset.family.contains('windows')
    props:
      - uid: mondooWindowsSecurityMinimumPasswordLength
        title: Define the minimum password length
        mql: |
          14
    mql: |
      secpol.systemaccess['MinimumPasswordLength'] >= props.mondooWindowsSecurityMinimumPasswordLength
    docs:
      desc: |-
        This policy setting determines the least number of characters that make up a password for a user account. There are many different theories about how to determine the best password length for an organization, but perhaps "passphrase" is a better term than "password." In Microsoft Windows 2000 and newer, passphrases can be quite long and can include spaces. Therefore, a phrase such as "I want to drink a $5 milkshake" is a valid passphrase; it is a considerably stronger password than an 8 or 10 character string of random numbers and letters, and yet is easier to remember. Users must be educated about the proper selection and maintenance of passwords, especially with regard to password length. In enterprise environments, the ideal value for the Minimum password length setting is 14 characters, however you should adjust this value to meet your organization's business requirements.

        The recommended state for this setting is: `14 or more character(s)`.

        **Note:**
        In Windows Server 2016 and older versions of Windows Server, the GUI of the Local Security Policy (LSP), Local Group Policy Editor (LGPE) and Group Policy Management Editor (GPME) would not let you set this value higher than 14 characters. However, starting with Windows Server 2019, Microsoft changed the GUI to allow up to a 20 character minimum password length.

        **Note #2:**
        Password Policy settings (section 1.1) and Account Lockout Policy settings (section 1.2) must be applied via the **Default Domain Policy**
        GPO in order to be globally in effect on **domain**
        user accounts as their default behavior. If these settings are configured in another GPO, they will only affect **local**
        user accounts on the computers that receive the GPO. However, custom exceptions to the default password policy and account lockout policy rules for specific domain users and/or groups can be defined using Password Settings Objects (PSOs), which are completely separate from Group Policy and most easily configured using Active Directory Administrative Center.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `14 or more character(s)`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\Minimum password length
            ```

            **Impact:**

            Requirements for extremely long passwords can actually decrease the security of an organization, because users might leave the information in an insecure location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of help desk calls. If your organization has issues with forgotten passwords due to password length requirements, consider teaching your users about passphrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover.

            **Note:**
            Older versions of Windows such as Windows 98 and Windows NT 4.0 do not support passwords that are longer than 14 characters. Computers that run these older operating systems are unable to authenticate with computers or domains that use accounts that require long passwords.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $Temp = [System.Environment]::GetEnvironmentVariable('TEMP','Machine')
            secedit /export /cfg $Temp\secpol-export.cfg
            (gc $Temp\secpol-export.cfg) -replace("MinimumPasswordLength = \d+", "MinimumPasswordLength = 14") | Out-File $Temp\secpol-import.cfg
            secedit /import /db $Temp\secpol-db.sdb /cfg $Temp\secpol-import.cfg
            secedit /configure /db $Temp\secpol-db.sdb
            gpupdate /force
            Remove-Item -Path $Temp\secpol-export.cfg -Force
            Remove-Item -Path $Temp\secpol-import.cfg -Force
            Remove-Item -Path $Temp\secpol-db.sdb -Force
            ```
  - uid: mondoo-windows-security-netbt-nodetype-configuration-is-set-to-enabled-p-node-recommended
    title: 'Ensure ''NetBT NodeType configuration'' is set to ''Enabled: P-node (recommended)'''
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters', name: 'NodeType' ).value == 2
    docs:
      desc: |-
        This setting determines which method NetBIOS over TCP/IP (NetBT) uses to register and resolve names. The available methods are:

        - The B-node (broadcast) method only uses broadcasts.
        - The P-node (point-to-point) method only uses name queries to a name server (WINS).
        - The M-node (mixed) method broadcasts first, then queries a name server (WINS) if broadcast failed.
        - The H-node (hybrid) method queries a name server (WINS) first, then broadcasts if the query failed.

        The recommended state for this setting is: `Enabled: P-node (recommended)`
        (point-to-point).

        **Note:**
        Resolution through LMHOSTS or DNS follows these methods. If the `NodeType` registry value is present, it overrides any `DhcpNodeType`
        registry value. If neither `NodeType` nor `DhcpNodeType` is present, the computer uses B-node (broadcast) if there are no WINS servers
        configured for the network, or H-node (hybrid) if there is at least one WINS server configured.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: P-node (recommended)`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\MS Security Guide\\NetBT NodeType configuration
            ```

            **Note:**
            This change does not take effect until the computer has been restarted.

            **Note #2:**
            This Group Policy path does not exist by default. An additional Group Policy template ( `SecGuide.admx/adml` ) is required - it is available from Microsoft at [this link](https://techcommunity.microsoft.com/t5/Microsoft-Security-Baselines/Security-baseline-FINAL-for-Windows-10-v1903-and-Windows-Server/ba-p/701084). Please note that this setting is **only**
            available in the _Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903_
            (or newer) release of `SecGuide.admx/adml`, so if you previously downloaded this template, you may need to update it from a newer Microsoft baseline to get this new _NetBT NodeType configuration_
            setting.

            **Impact:**

            NetBIOS name resolution queries will require a defined and available WINS server for external NetBIOS name resolution. If a WINS server is not defined or not reachable, and the desired hostname is not defined in the local cache, local LMHOSTS or HOSTS files, NetBIOS name resolution will fail.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters'
            $Name         = 'NodeType'
            $Value        = '2'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-access-allow-anonymous-sidname-translation-is-set-to-disabled
    title: 'Ensure ''Network access: Allow anonymous SID/Name translation'' is set to ''Disabled'''
    impact: 80
    mql: |
      secpol.systemaccess['LSAAnonymousNameLookup'] == 0
    docs:
      desc: |-
        This policy setting determines whether an anonymous user can request security identifier (SID) attributes for another user, or use a SID to obtain its corresponding user name.

        The recommended state for this setting is: `Disabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Allow anonymous SID/Name translation
            ```

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $Temp = [System.Environment]::GetEnvironmentVariable('TEMP','Machine')
            secedit /export /cfg $Temp\secpol-export.cfg
            (gc $Temp\secpol-export.cfg) -replace("LSAAnonymousNameLookup = \d+", "LSAAnonymousNameLookup = 0") | Out-File $Temp\secpol-import.cfg
            secedit /import /db $Temp\secpol-db.sdb /cfg $Temp\secpol-import.cfg
            secedit /configure /db $Temp\secpol-db.sdb
            gpupdate /force
            Remove-Item -Path $Temp\secpol-export.cfg -Force
            Remove-Item -Path $Temp\secpol-import.cfg -Force
            Remove-Item -Path $Temp\secpol-db.sdb -Force
            ```
  - uid: mondoo-windows-security-network-access-do-not-allow-anonymous-enumeration-of-sam-accounts
    title: 'Ensure ''Network access: Do not allow anonymous enumeration of SAM accounts'' is set to ''Enabled'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'RestrictAnonymousSAM' ).value == 1
    docs:
      desc: |-
        This policy setting controls the ability of anonymous users to enumerate the accounts in the Security Accounts Manager (SAM). If you enable this policy setting, users with anonymous connections will not be able to enumerate domain account user names on the systems in your environment. This policy setting also allows additional restrictions on anonymous connections.

        The recommended state for this setting is: `Enabled`.

        **Note:**
        This policy has no effect on Domain Controllers.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Do not allow anonymous enumeration of SAM accounts
            ```

            **Impact:**

            None - this is the default behavior. It will be impossible to establish trusts with Windows NT 4.0-based domains. Also, client computers that run older versions of the Windows operating system such as Windows NT 3.51 and Windows 95 will experience problems when they try to use resources on the server.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'RestrictAnonymousSAM'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares
    title: 'Ensure ''Network access: Do not allow anonymous enumeration of SAM accounts and shares'' is set to ''Enabled'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'RestrictAnonymous' ).value == 1
    docs:
      desc: |-
        This policy setting controls the ability of anonymous users to enumerate SAM accounts as well as shares. If you enable this policy setting, anonymous users will not be able to enumerate domain account user names and network share names on the systems in your environment.

        The recommended state for this setting is: `Enabled`.

        **Note:**
        This policy has no effect on Domain Controllers.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Do not allow anonymous enumeration of SAM accounts and shares
            ```

            **Impact:**

            It will be impossible to establish trusts with Windows NT 4.0-based domains. Also, client computers that run older versions of the Windows operating system such as Windows NT 3.51 and Windows 95 will experience problems when they try to use resources on the server. Users who access file and print servers anonymously will be unable to list the shared network resources on those servers; the users will have to authenticate before they can view the lists of shared folders and printers. However, even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, `ANONYMOUS LOGON`.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'RestrictAnonymous'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-auth
    title: 'Ensure ''Network access: Do not allow storage of passwords and credentials for network authentication'' is set to ''Enabled'''
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'DisableDomainCreds' ).value == 1
    docs:
      desc: |-
        This policy setting determines whether Credential Manager (formerly called Stored User Names and Passwords) saves passwords or credentials for later use when it gains domain authentication.

        The recommended state for this setting is: `Enabled`.

        **Note:**
        Changes to this setting will not take effect until Windows is restarted.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Do not allow storage of passwords and credentials for network authentication
            ```

            **Impact:**

            Credential Manager will not store passwords and credentials on the computer. Users will be forced to enter passwords whenever they log on to their Passport account or other network resources that aren't accessible to their domain account. Testing has shown that clients running Windows Vista or Windows Server 2008 will be unable to connect to Distributed File System (DFS) shares in untrusted domains. Enabling this setting also makes it impossible to specify alternate credentials for scheduled tasks, this can cause a variety of problems. For example, some third party backup products will no longer work. This policy setting should have no impact on users who access network resources that are configured to allow access with their Active Directory-based domain account.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'DisableDomainCreds'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-access-let-everyone-permissions-apply-to-anonymous-users-is-set-to-disabled
    title: 'Ensure ''Network access: Let Everyone permissions apply to anonymous users'' is set to ''Disabled'''
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'EveryoneIncludesAnonymous' ).value == 0
    docs:
      desc: |-
        This policy setting determines what additional permissions are assigned for anonymous connections to the computer.

        The recommended state for this setting is: `Disabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Let Everyone permissions apply to anonymous users
            ```

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'EveryoneIncludesAnonymous'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-access-named-pipes-that-can-be-accessed-anonymously-is-set-to-none
    title: 'Ensure ''Network access: Named Pipes that can be accessed anonymously'' is set to ''None'''
    impact: 100
    variants:
      - uid: mondoo-windows-security-network-access-named-pipes-that-can-be-accessed-anonymously-is-set-to-none-dc
      - uid: mondoo-windows-security-network-access-named-pipes-that-can-be-accessed-anonymously-is-set-to-none-ms
    docs:
      desc: |-
        This policy setting determines which communication sessions, or pipes, will have attributes and permissions that allow anonymous access.

        The recommended state for this setting is: `<blank>` (i.e. None).
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `<blank>` (i.e. None):

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Named Pipes that can be accessed anonymously
            ```

            **Impact:**

            This configuration will disable null session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes will no longer function.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters'
            $Name         = 'NullSessionPipes'
            $Value        = ''

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType MultiString -Force
            ```
  - uid: mondoo-windows-security-network-access-restrict-anonymous-access-to-named-pipes-and-shares
    title: 'Ensure ''Network access: Restrict anonymous access to Named Pipes and Shares'' is set to ''Enabled'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters', name: 'RestrictNullSessAccess' ).value == 1
    docs:
      desc: |-
        When enabled, this policy setting restricts anonymous access to only those shares and pipes that are named in the `Network access: Named pipes that can be accessed anonymously`and `Network access: Shares that can be accessed anonymously`
        settings. This policy setting controls null session access to shares on your computers by adding `RestrictNullSessAccess`
        with the value `1` in the

        `HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\LanManServer\\Parameters`

        registry key. This registry value toggles null session shares on or off to control whether the server service restricts unauthenticated clients' access to named resources.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Restrict anonymous access to Named Pipes and Shares
            ```

            **Impact:**

            None - this is the default behavior. If you choose to enable this setting and are supporting Windows NT 4.0 domains, you should check if any of the named pipes are required to maintain trust relationships between the domains, and then add the pipe to the **Network access: Named pipes that can be accessed anonymously**
            list:

            - COMNAP: SNA session access
            - COMNODE: SNA session access
            - SQL\\QUERY: SQL instance access
            - SPOOLSS: Spooler service
            - LLSRPC: License Logging service
            - NETLOGON: Net Logon service
            - LSARPC: LSA access
            - SAMR: Remote access to SAM objects
            - BROWSER: Computer Browser service

            Previous to the release of Windows Server 2003 with Service Pack 1 (SP1) these named pipes were allowed anonymous access by default, but with the increased hardening in Windows Server 2003 with SP1 these pipes must be explicitly added if needed.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters'
            $Name         = 'RestrictNullSessAccess'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-access-restrict-clients-allowed-to-make-remote-calls-to-sam
    title: 'Ensure ''Network access: Restrict clients allowed to make remote calls to SAM'' is set to ''Administrators: Remote Access: Allow'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa', name: 'restrictremotesam' ).value == 'O:BAG:BAD:(A;;RC;;;BA)'
    docs:
      desc: |-
        This policy setting allows you to restrict remote RPC connections to SAM.

        The recommended state for this setting is: `Administrators: Remote Access: Allow`.

        **Note:**
        A Windows 10 R1607, Server 2016 or newer OS is required to access and set this value in Group Policy.

        **Note #2:**
        If your organization is using Azure Advanced Threat Protection (APT), the service account, “AATP Service” will need to be added to the recommendation configuration. For more information on adding the “AATP Service” account please see [Configure SAM-R to enable lateral movement path detection in Microsoft Defender for Identity \| Microsoft Docs](https://learn.microsoft.com/en-us/defender-for-identity/install-step8-samr).
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Administrators: Remote Access: Allow`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Restrict clients allowed to make remote calls to SAM
            ```

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'
            $Name         = 'restrictremotesam'
            $Value        = 'O:BAG:BAD:(A;;RC;;;BA)'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType String -Force
            ```
  - uid: mondoo-windows-security-network-access-shares-that-can-be-accessed-anonymously-is-set-to-none
    title: 'Ensure ''Network access: Shares that can be accessed anonymously'' is set to ''None'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters', name: 'NullSessionShares' ).value == ""
    docs:
      desc: |-
        This policy setting determines which network shares can be accessed by anonymous users. The default configuration for this policy setting has little effect because all users have to be authenticated before they can access shared resources on the server.

        The recommended state for this setting is: `<blank>` (i.e. None).
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `<blank>` (i.e. None):

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Shares that can be accessed anonymously
            ```

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters'
            $Name         = 'NullSessionShares'
            $Value        = ''

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType MultiString -Force
            ```
  - uid: mondoo-windows-security-network-access-sharing-and-security-model-for-local-accounts-is-set-to-classic
    title: 'Ensure ''Network access: Sharing and security model for local accounts'' is set to ''Classic - local users authenticate as themselves'''
    impact: 30
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'ForceGuest' ).value == 0
    docs:
      desc: |-
        This policy setting determines how network logons that use local accounts are authenticated. The Classic option allows precise control over access to resources, including the ability to assign different types of access to different users for the same resource. The Guest only option allows you to treat all users equally. In this context, all users authenticate as Guest only to receive the same access level to a given resource.

        The recommended state for this setting is: `Classic - local users authenticate as themselves`.

        **Note:**
        This setting does not affect interactive logons that are performed remotely by using such services as Telnet or Remote Desktop Services (formerly called Terminal Services).
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Classic - local users authenticate as themselves`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Sharing and security model for local accounts
            ```

            **Impact:**

            None - this is the default configuration for domain-joined computers.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'ForceGuest'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-allow-local-system-to-use-computer-identity-for-ntlm
    title: 'Ensure ''Network security: Allow Local System to use computer identity for NTLM'' is set to ''Enabled'''
    impact: 30
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'UseMachineId' ).value == 1
    docs:
      desc: |-
        This policy setting determines whether Local System services that use Negotiate when reverting to NTLM authentication can use the computer identity. This policy is supported on at least Windows 7 or Windows Server 2008 R2.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network security: Allow Local System to use computer identity for NTLM
            ```

            **Impact:**

            Services running as Local System that use Negotiate when reverting to NTLM authentication will use the computer identity. This might cause some authentication requests between Windows operating systems to fail and log an error.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'UseMachineId'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-allow-localsystem-null-session-fallback-is-set-to-disabled
    title: 'Ensure ''Network security: Allow LocalSystem NULL session fallback'' is set to ''Disabled'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0', name: 'AllowNullSessionFallback' ).value == 0
    docs:
      desc: |-
        This policy setting determines whether NTLM is allowed to fall back to a NULL session when used with LocalSystem.

        The recommended state for this setting is: `Disabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network security: Allow LocalSystem NULL session fallback
            ```

            **Impact:**

            None - this is the default behavior. Any applications that require NULL sessions for LocalSystem will not work as designed.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0'
            $Name         = 'AllowNullSessionFallback'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-allow-pku2u-authentication-requests-is-set-to-disabled
    title: 'Ensure ''Network Security: Allow PKU2U authentication requests to this computer to use online identities'' is set to ''Disabled'''
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\pku2u', name: 'AllowOnlineID' ).value == 0
    docs:
      desc: |-
        This setting determines if online identities are able to authenticate to this computer.

        The Public Key Cryptography Based User-to-User (PKU2U) protocol introduced in Windows 7 and Windows Server 2008 R2 is implemented as a security support provider (SSP). The SSP enables peer-to-peer authentication, particularly through the Windows 7 media and file sharing feature called HomeGroup, which permits sharing between computers that are not members of a domain.

        With PKU2U, a new extension was introduced to the Negotiate authentication package, `Spnego.dll`. In previous versions of Windows, Negotiate decided whether to use Kerberos or NTLM for authentication. The extension SSP for Negotiate, `Negoexts.dll`, which is treated as an authentication protocol by Windows, supports Microsoft SSPs including PKU2U.

        When computers are configured to accept authentication requests by using online IDs, `Negoexts.dll`
        calls the PKU2U SSP on the computer that is used to log on. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer computers. When validated on the peer computer, the certificate within the metadata is sent to the logon peer for validation and associates the user's certificate to a security token and the logon process completes.

        The recommended state for this setting is: `Disabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network Security: Allow PKU2U authentication requests to this computer to use online identities
            ```

            **Impact:**

            None - this is the default configuration for domain-joined computers.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa\pku2u'
            $Name         = 'AllowOnlineID'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-configure-encryption-types-allowed-for-kerberos-is-set-to-aes12
    title: 'Ensure ''Network security: Configure encryption types allowed for Kerberos'' is set to ''AES128_HMAC_SHA1, AES256_HMAC_SHA1, Future encryption types'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters', name: 'SupportedEncryptionTypes' ).value == 2147483640
    docs:
      desc: |-
        This policy setting allows you to set the encryption types that Kerberos is allowed to use.

        The recommended state for this setting is: `AES128_HMAC_SHA1, AES256_HMAC_SHA1, Future encryption types`.

        **Note:**
        Some legacy applications and OSes may still require `RC4_HMAC_MD5`
        \- we recommend you test in your environment and verify whether you can safely remove it.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `AES128_HMAC_SHA1, AES256_HMAC_SHA1, Future encryption types`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network security: Configure encryption types allowed for Kerberos
            ```

            **Impact:**

            If not selected, the encryption type will not be allowed. This setting may affect compatibility with client computers or services and applications. Multiple selections are permitted.

            **Note:**
            Some legacy applications and OSes may still require `RC4_HMAC_MD5`
            \- we recommend you test in your environment and verify whether you can safely remove it.

            **Note #2:**
            Windows Vista and below allow DES for Kerberos by default, but later OS versions do not.

            **Note #3:**
            Some prerequisites might need to be met on Domain Controllers to support Kerberos AES 128 and 256 bit encryption types, as well as enabling support for Kerberos AES 128 and 256 bit on user accounts (in account options) for this recommendation to work correctly.

            **Note #4:**
            If your organization uses Azure Files, please note that Microsoft did not introduce AES 256 Kerberos encryption support for it until AD DS authentication module v0.2.2. Please see this link for more information:

            [Azure Files on-premises AD DS Authentication support for AES 256 Kerberos encryption \| Microsoft Docs](https://learn.microsoftcom/en-us/azure/storage/files/storage-troubleshoot-windows-file-connection-problems#azure-files-on-premises-ad-ds-authentication-support-for-aes-256-kerberos-encryption)
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters'
            $Name         = 'SupportedEncryptionTypes'
            $Value        = '2147483640'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-do-not-store-lan-manager-hash-value-on-next-password-change
    title: 'Ensure ''Network security: Do not store LAN Manager hash value on next password change'' is set to ''Enabled'''
    impact: 100
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'NoLMHash' ).value == 1
    docs:
      desc: |-
        This policy setting determines whether the LAN Manager (LM) hash value for the new password is stored when the password is changed. The LM hash is relatively weak and prone to attack compared to the cryptographically stronger Microsoft Windows NT hash. Since LM hashes are stored on the local computer in the security database, passwords can then be easily compromised if the database is attacked.

        **Note:**
        Older operating systems and some third-party applications may fail when this policy setting is enabled. Also, note that the password will need to be changed on all accounts after you enable this setting to gain the proper benefit.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network security: Do not store LAN Manager hash value on next password change
            ```

            **Impact:**

            None - this is the default behavior. Earlier operating systems such as Windows 95, Windows 98, and Windows ME as well as some third-party applications will fail.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'NoLMHash'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-lan-manager-authentication-level-is-set-to-send-ntlmv2-response
    title: 'Ensure ''Network security: LAN Manager authentication level'' is set to ''Send NTLMv2 response only. Refuse LM&NTLM'''
    impact: 100
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa', name: 'LmCompatibilityLevel' ).value == 5
    docs:
      desc: |-
        LAN Manager (LM) was a family of early Microsoft client/server software (predating Windows NT) that allowed users to link personal computers together on a single network. LM network capabilities included transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory will use LM, NTLM, or NTLMv2. LAN Manager authentication includes the LM, NTLM, and NTLM version 2 (NTLMv2) variants, and is the protocol that is used to authenticate all Windows clients when they perform the following operations:

        - Join a domain
        - Authenticate between Active Directory forests
        - Authenticate to down-level domains
        - Authenticate to computers that do not run Windows 2000, Windows Server 2003, or Windows XP
        - Authenticate to computers that are not in the domain

        The Network security: LAN Manager authentication level setting determines which challenge/response authentication protocol is used for network logons. This choice affects the level of authentication protocol used by clients, the level of session security negotiated, and the level of authentication accepted by servers.

        The recommended state for this setting is: `Send NTLMv2 response only. Refuse LM & NTLM`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to: `Send NTLMv2 response only. Refuse LM & NTLM`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network security: LAN Manager authentication level
            ```

            **Impact:**

            Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; Domain Controllers refuse LM and NTLM (accept only NTLMv2 authentication). Clients that do not support NTLMv2 authentication will not be able to authenticate in the domain and access domain resources by using LM and NTLM.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa'
            $Name         = 'LmCompatibilityLevel'
            $Value        = '5'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-ldap-client-signing-requirements-is-set-to-negotiate-signing
    title: 'Ensure ''Network security: LDAP client signing requirements'' is set to ''Negotiate signing'' or higher'
    impact: 40
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP', name: 'LDAPClientIntegrity' ).value >= 1
    docs:
      desc: |-
        This policy setting determines the level of data signing that is requested on behalf of clients that issue LDAP BIND requests.

        **Note:**
        This policy setting does not have any impact on LDAP simple bind ( `ldap_simple_bind`) or LDAP simple bind through SSL ( `ldap_simple_bind_s`).
        No Microsoft LDAP clients that are included with Windows XP Professional use `ldap_simple_bind`or `ldap_simple_bind_s` to communicate with a Domain Controller.

        The recommended state for this setting is: `Negotiate signing`. Configuring this setting to `Require signing` also conforms to the benchmark.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Negotiate signing` (configuring to `Require signing`
            also conforms to the benchmark):

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network security: LDAP client signing requirements
            ```

            **Impact:**

            None - this is the default behavior. However, if you choose instead to configure the server to _require_LDAP signatures then you must also configure the client.
            If you do not configure the client it will not be able to communicate with the server, which could cause many features to fail, including user authentication,
            Group Policy, and logon scripts, because the caller will be told that the LDAP BIND command request failed.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Services\LDAP'
            $Name         = 'LDAPClientIntegrity'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-minimum-session-security-for-ntlm-ssp-based-servers-is-set-to-ntlmv2
    title: 'Ensure ''Network security: Minimum session security for NTLM SSP based (including secure RPC) servers'' is set to ''Require NTLMv2 session security, Require 128-bit encryption'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0', name: 'NTLMMinServerSec' ).value == 537395200
    docs:
      desc: |-
        This policy setting determines which behaviors are allowed by servers for applications using the NTLM Security Support Provider (SSP). The SSP Interface (SSPI) is used by applications that need authentication services. The setting does not modify how the authentication sequence works but instead require certain behaviors in applications that use the SSPI.

        The recommended state for this setting is: `Require NTLMv2 session security, Require 128-bit encryption`.

        **Note:**
        These values are dependent on the _Network security: LAN Manager Authentication Level_
        (Rule 2.3.11.7) security setting value.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Require NTLMv2 session security, Require 128-bit encryption`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network security: Minimum session security for NTLM SSP based (including secure RPC) servers
            ```

            **Impact:**

            NTLM connections will fail if NTLMv2 protocol and strong encryption (128-bit) are not **both**
            negotiated. Server applications that are enforcing these settings will be unable to communicate with older servers that do not support them.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0'
            $Name         = 'NTLMMinServerSec'
            $Value        = '537395200'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-security-minimum-session-security-for-ntlm-ssp-clients-is-set-to-ntlmv2
    title: 'Ensure ''Network security: Minimum session security for NTLM SSP based (including secure RPC) clients'' is set to ''Require NTLMv2 session security, Require 128-bit encryption'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0', name: 'NTLMMinClientSec' ).value == 537395200
    docs:
      desc: |-
        This policy setting determines which behaviors are allowed by clients for applications using the NTLM Security Support Provider (SSP). The SSP Interface (SSPI) is used by applications that need authentication services. The setting does not modify how the authentication sequence works but instead require certain behaviors in applications that use the SSPI.

        The recommended state for this setting is: `Require NTLMv2 session security, Require 128-bit encryption`.

        **Note:**
        These values are dependent on the _Network security: LAN Manager Authentication Level_
        (Rule 2.3.11.7) security setting value.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Require NTLMv2 session security, Require 128-bit encryption`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network security: Minimum session security for NTLM SSP based (including secure RPC) clients
            ```

            **Impact:**

            NTLM connections will fail if NTLMv2 protocol and strong encryption (128-bit) are not **both**
            negotiated. Client applications that are enforcing these settings will be unable to communicate with older servers that do not support them.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0'
            $Name         = 'NTLMMinClientSec'
            $Value        = '537395200'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-password-must-meet-complexity-requirements-is-set-to-enabled
    title: Ensure 'Password must meet complexity requirements' is set to 'Enabled'
    impact: 100
    mql: |
      secpol.systemaccess['PasswordComplexity'] == 1
    docs:
      desc: |-
        This policy setting checks all new passwords to ensure that they meet basic requirements for strong passwords.

        When this policy is enabled, passwords must meet the following minimum requirements:

        - Not contain the user's account name or parts of the user's full name that exceed two consecutive characters
        - Be at least six characters in length
        - Contain characters from three of the following categories:
        - English uppercase characters (A through Z)
        - English lowercase characters (a through z)
        - Base 10 digits (0 through 9)
        - Non-alphabetic characters (for example, !, $, #, %)
        - A catch-all category of any Unicode character that does not fall under the previous four categories. This fifth category can be regionally specific.


        Each additional character in a password increases its complexity exponentially. For instance, a seven-character, all lower-case alphabetic password would have 267 (approximately 8 x 109 or 8 billion) possible combinations. At 1,000,000 attempts per second (a capability of many password-cracking utilities), it would only take 133 minutes to crack. A seven-character alphabetic password with case sensitivity has 527 combinations. A seven-character case-sensitive alphanumeric password without punctuation has 627 combinations. An eight-character password has 268 (or 2 x 1011) possible combinations. Although this might seem to be a large number, at 1,000,000 attempts per second it would take only 59 hours to try all possible passwords. Remember, these times will significantly increase for passwords that use ALT characters and other special keyboard characters such as "!" or "@". Proper use of the password settings can help make it difficult to mount a brute force attack.

        The recommended state for this setting is: `Enabled`.

        **Note:**
        Password Policy settings (section 1.1) and Account Lockout Policy settings (section 1.2) must be applied via the **Default Domain Policy**
        GPO in order to be globally in effect on **domain**
        user accounts as their default behavior. If these settings are configured in another GPO, they will only affect **local**
        user accounts on the computers that receive the GPO. However, custom exceptions to the default password policy and account lockout policy rules for specific domain users and/or groups can be defined using Password Settings Objects (PSOs), which are completely separate from Group Policy and most easily configured using Active Directory Administrative Center.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\Password must meet complexity requirements
            ```

            **Impact:**

            If the default password complexity configuration is retained, additional help desk calls for locked-out accounts could occur because users might not be accustomed to passwords that contain non-alphabetic characters. However, all users should be able to comply with the complexity requirement with minimal difficulty.

            If your organization has more stringent security requirements, you can create a custom version of the Passfilt.dll file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might require the use of non-upper row characters. (Upper row characters are those that require you to hold down the SHIFT key and press any of the digits between 1 and 0.) A custom password filter might also perform a dictionary check to verify that the proposed password does not contain common dictionary words or fragments.

            Also, the use of ALT key character combinations can greatly enhance the complexity of a password. However, such stringent password requirements can result in unhappy users and an extremely busy help desk. Alternatively, your organization could consider a requirement for all administrator passwords to use ALT characters in the 0128 - 0159 range. (ALT characters outside of this range can represent standard alphanumeric characters that would not add additional complexity to the password.)
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $Temp = [System.Environment]::GetEnvironmentVariable('TEMP','Machine')
            secedit /export /cfg $Temp\secpol-export.cfg
            (gc $Temp\secpol-export.cfg) -replace("PasswordComplexity = \d+", "PasswordComplexity = 1") | Out-File $Temp\secpol-import.cfg
            secedit /import /db $Temp\secpol-db.sdb /cfg $Temp\secpol-import.cfg
            secedit /configure /db $Temp\secpol-db.sdb
            gpupdate /force
            Remove-Item -Path $Temp\secpol-export.cfg -Force
            Remove-Item -Path $Temp\secpol-import.cfg -Force
            Remove-Item -Path $Temp\secpol-db.sdb -Force
            ```
  - uid: mondoo-windows-security-relax-minimum-password-length-limits-is-set-to-enabled
    title: Ensure 'Relax minimum password length limits' is set to 'Enabled'
    impact: 60
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SAM', name: 'RelaxMinimumPasswordLengthLimits' ).value == 1
    docs:
      desc: |-
        This policy setting determines whether the minimum password length setting can be increased beyond the legacy limit of 14 characters. For more information please see the following [Microsoft Security Blog](https://techcommunity.microsoft.com/t5/microsoft-security-baselines/security-baseline-draft-windows-10-and-windows-server-version/ba-p/1419213).

        The recommended state for this setting is: `Enabled`.

        **Note:**
        This setting only affects _local_
        accounts on the computer. Domain accounts are only affected by settings on the Domain Controllers, because that is where domain accounts are stored.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\Relax minimum password length limits
            ```

            **Note:**
            This setting is only available within the built-in OS security template of Windows 10 Release 2004 (or newer), and is not available via older versions of the OS, or via downloadable Administrative Templates (ADMX/ADML). Therefore, you _must_
            use a Windows 10 Release 2004 computer (or newer) to view or edit this setting with the Group Policy Management Console (GPMC) or Group Policy Management Editor (GPME).

            **Impact:**

            The _Minimum password length_
            setting may be configured higher than 14 characters.

            If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of help desk calls. If your organization has issues with forgotten passwords due to password length requirements, consider teaching your users about passphrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\System\CurrentControlSet\Control\SAM'
            $Name         = 'RelaxMinimumPasswordLengthLimits'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-require-secure-rpc-communication-is-set-to-enabled
    title: Ensure 'Require secure RPC communication' is set to 'Enabled'
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services', name: 'fEncryptRPCTraffic' ).value == 1
    docs:
      desc: |-
        This policy setting allows you to specify whether Remote Desktop Services requires secure Remote Procedure Call (RPC) communication with all clients or allows unsecured communication.

        You can use this policy setting to strengthen the security of RPC communication with clients by allowing only authenticated and encrypted requests.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Security\\Require secure RPC communication
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            Remote Desktop Services accepts requests from RPC clients that support secure requests, and does not allow unsecured communication with untrusted clients.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'fEncryptRPCTraffic'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-require-use-of-specific-security-layer-for-remote-rdp-connections-is-set-to
    title: 'Ensure ''Require use of specific security layer for remote (RDP) connections'' is set to ''Enabled: SSL'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'SecurityLayer' ).value == 2
    docs:
      desc: |-
        This policy setting specifies whether to require the use of a specific security layer to secure communications between clients and RD Session Host servers during Remote Desktop Protocol (RDP) connections.

        The recommended state for this setting is: `Enabled: SSL`.

        **Note:**
        In spite of this setting being labeled _SSL_, it is actually enforcing Transport Layer Security (TLS) version 1.0, not the older (and less secure) SSL protocol.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: SSL`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Security\\Require use of specific security layer for remote (RDP) connections
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            TLS 1.0 will be required to authenticate to the RD Session Host server. If TLS is not supported, the connection fails.

            **Note:**
            By default, this setting will use a self-signed certificate for RDP connections. If your organization has established the use of a Public Key Infrastructure (PKI) for SSL/TLS encryption, then we recommend that you also configure the _Server authentication certificate template_setting to instruct RDP to use a certificate from your PKI instead of a self-signed one. Note that the certificate template used for this purpose must have “Client Authentication” configured as an Intended Purpose. Note also that a valid, non-expired certificate using the specified template must already be installed on the workstation for it to work.

            **Note #2:**
            Some third party two-factor authentication solutions (e.g. RSA Authentication Agent) can be negatively affected by this setting, as the SSL/TLS security layer will expect the user's Windows password upon initial connection attempt (before the RDP logon screen), and once successfully authenticated, pass the credential along to that Windows session on the RDP host (to complete the login). If a two-factor agent is present and expecting a different credential at the RDP logon screen, this initial connection may result in a failed logon attempt, and also effectively cause a “double logon” requirement for each and every new RDP session.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'SecurityLayer'
            $Value        = '2'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-require-user-authentication-for-remote-connections-by-using-network-level-a
    title: Ensure 'Require user authentication for remote connections by using Network Level Authentication' is set to 'Enabled'
    impact: 100
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'UserAuthentication' ).value == 1
    docs:
      desc: |-
        This policy setting allows you to specify whether to require user authentication for remote connections to the RD Session Host server by using Network Level Authentication.

        The recommended state for this setting is: `Enabled`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Security\\Require user authentication for remote connections by using Network Level Authentication
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In the Microsoft Windows Vista Administrative Templates, this setting was initially named _Require user authentication using RDP 6.0 for remote connections_, but it was renamed starting with the Windows Server 2008 (non-R2) Administrative Templates.

            **Impact:**

            Only client computers that support Network Level Authentication can connect to the RD Session Host server.

            **Note:**
            Some third party two-factor authentication solutions (e.g. RSA Authentication Agent) can be negatively affected by this setting, as Network Level Authentication will expect the user's Windows password upon initial connection attempt (before the RDP logon screen), and once successfully authenticated, pass the credential along to that Windows session on the RDP host (to complete the login). If a two-factor agent is present and expecting a different credential at the RDP logon screen, this initial connection may result in a failed logon attempt, and also effectively cause a “double logon” requirement for each and every new RDP session.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'UserAuthentication'
            $Value        = '1'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-security-control-event-log-behavior-when-the-log-file-reaches-its-maximum-size
    title: 'Ensure ''Security: Control Event Log behavior when the log file reaches its maximum size'' is set to ''Disabled'''
    impact: 30
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\EventLog\Security', name: 'Retention' ).value == '0'
    docs:
      desc: |-
        This policy setting controls Event Log behavior when the log file reaches its maximum size.

        The recommended state for this setting is: `Disabled`.

        **Note:**
        Old events may or may not be retained according to the _Backup log automatically when full_
        policy setting.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Event Log Service\\Security\\Control Event Log behavior when the log file reaches its maximum size
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `EventLog.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was initially named _Retain old events_
            , but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Policies\Microsoft\Windows\EventLog\Security'
            $Name         = 'Retention'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-security-specify-the-maximum-log-file-size-kb-is-set-to-enabled-196608
    title: 'Ensure ''Security: Specify the maximum log file size (KB)'' is set to ''Enabled: 196,608 or greater'''
    impact: 50
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\EventLog\Security', name: 'MaxSize' ).value >= 196608
    docs:
      desc: |-
        This policy setting specifies the maximum size of the log file in kilobytes. The maximum log file size can be configured between 1 megabyte (1,024 kilobytes) and 4 terabytes (4,194,240 kilobytes) in kilobyte increments.

        The recommended state for this setting is: `Enabled: 196,608 or greater`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: 196,608 or greater`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Event Log Service\\Security\\Specify the maximum log file size (KB)
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `EventLog.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was initially named _Maximum Log Size (KB)_, but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            When event logs fill to capacity, they will stop recording information unless the retention method for each is set so that the computer will overwrite the oldest entries with the most recent ones. To mitigate the risk of loss of recent data, you can configure the retention method so that older events are overwritten as needed.

            The consequence of this configuration is that older events will be removed from the logs. Attackers can take advantage of such a configuration, because they can generate a large number of extraneous events to overwrite any evidence of their attack. These risks can be somewhat reduced if you automate the archival and backup of event log data.

            Ideally, all specifically monitored events should be sent to a server that uses Microsoft System Center Operations Manager (SCOM) or some other automated monitoring tool. Such a configuration is particularly important because an attacker who successfully compromises a server could clear the Security log. If all events are sent to a monitoring server, then you will be able to gather forensic information about the attacker's activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Policies\Microsoft\Windows\EventLog\Security'
            $Name         = 'MaxSize'
            $Value        = '196608'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-set-client-connection-encryption-level-is-set-to-enabled-high-level
    title: 'Ensure ''Set client connection encryption level'' is set to ''Enabled: High Level'''
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'MinEncryptionLevel' ).value == 3
    docs:
      desc: |-
        This policy setting specifies whether to require the use of a specific encryption level to secure communications between client computers and RD Session Host servers during Remote Desktop Protocol (RDP) connections. This policy only applies when you are using native RDP encryption. However, native RDP encryption (as opposed to SSL encryption) is not recommended. This policy does not apply to SSL encryption.

        The recommended state for this setting is: `Enabled: High Level`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: High Level`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Security\\Set client connection encryption level
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'MinEncryptionLevel'
            $Value        = '3'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-set-time-limit-for-active-but-idle-remote-desktop-services-sessions-is-set
    title: 'Ensure ''Set time limit for active but idle Remote Desktop Services sessions'' is set to ''Enabled: 15 minutes or less, but not Never (0)'''
    impact: 60
    filters: asset.family.contains('windows')
    props:
      - uid: mondooWindowsSecurityMaxIdleTime
        title: Define the maximum idle time of the Remote Desktop Services sessions in milliseconds
        mql: |
          900000
    mql: |
      registrykey.property(path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'MaxIdleTime').value <= props.mondooWindowsSecurityMaxIdleTime
      registrykey.property(path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'MaxIdleTime').value != 0
    docs:
      desc: |-
        This policy setting allows you to specify the maximum amount of time that an active Remote Desktop Services session can be idle (without user input) before it is automatically disconnected.

        The recommended state for this setting is: `Enabled: 15 minutes or less, but not Never (0)`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled:``15 minutes or less, but not Never (0)`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Session Time Limits\\Set time limit for active but idle Remote Desktop Services sessions
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was named _Set time limit for active but idle Terminal Services sessions_, but it was renamed starting with the Windows 7 & Server 2008 R2 Administrative Templates.

            **Impact:**

            Remote Desktop Services will automatically disconnect active but idle sessions after 15 minutes (or the specified amount of time). The user receives a warning two minutes before the session disconnects, which allows the user to press a key or move the mouse to keep the session active. Note that idle session time limits do not apply to console sessions.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'MaxIdleTime'
            $Value        = '900000'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-set-time-limit-for-disconnected-sessions-is-set-to-enabled-1-minute
    title: 'Ensure ''Set time limit for disconnected sessions'' is set to ''Enabled: 1 minute'''
    impact: 50
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services', name: 'MaxDisconnectionTime' ).value == 60000
    docs:
      desc: |-
        This policy setting allows you to configure a time limit for disconnected Remote Desktop Services sessions.

        The recommended state for this setting is: `Enabled: 1 minute`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: 1 minute`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Remote Desktop Services\\Remote Desktop Session Host\\Session Time Limits\\Set time limit for disconnected sessions
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `TerminalServer.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Impact:**

            Disconnected Remote Desktop sessions are deleted from the server after 1 minute. Note that disconnected session time limits do not apply to console sessions.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
            $Name         = 'MaxDisconnectionTime'
            $Value        = '60000'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-setup-control-event-log-behavior-when-the-log-file-reaches-its-maximum-size
    title: 'Ensure ''Setup: Control Event Log behavior when the log file reaches its maximum size'' is set to ''Disabled'''
    impact: 30
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\EventLog\Setup', name: 'Retention' ).value == '0'
    docs:
      desc: |-
        This policy setting controls Event Log behavior when the log file reaches its maximum size.

        The recommended state for this setting is: `Disabled`.

        **Note:**
        Old events may or may not be retained according to the _Backup log automatically when full_
        policy setting.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Event Log Service\\Setup\\Control Event Log behavior when the log file reaches its maximum size
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `EventLog.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was initially named _Retain old events_, but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Policies\Microsoft\Windows\EventLog\Setup'
            $Name         = 'Retention'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-setup-specify-the-maximum-log-file-size-kb-is-set-to-enabled-32768
    title: 'Ensure ''Setup: Specify the maximum log file size (KB)'' is set to ''Enabled: 32,768 or greater'''
    impact: 50
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\EventLog\Setup', name: 'MaxSize' ).value >= 32768
    docs:
      desc: |-
        This policy setting specifies the maximum size of the log file in kilobytes. The maximum log file size can be configured between 1 megabyte (1,024 kilobytes) and 4 terabytes (4,194,240 kilobytes) in kilobyte increments.

        The recommended state for this setting is: `Enabled: 32,768 or greater`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: 32,768 or greater`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Event Log Service\\Setup\\Specify the maximum log file size (KB)
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `EventLog.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was initially named _Maximum Log Size (KB)_, but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            When event logs fill to capacity, they will stop recording information unless the retention method for each is set so that the computer will overwrite the oldest entries with the most recent ones. To mitigate the risk of loss of recent data, you can configure the retention method so that older events are overwritten as needed.

            The consequence of this configuration is that older events will be removed from the logs. Attackers can take advantage of such a configuration, because they can generate a large number of extraneous events to overwrite any evidence of their attack. These risks can be somewhat reduced if you automate the archival and backup of event log data.

            Ideally, all specifically monitored events should be sent to a server that uses Microsoft System Center Operations Manager (SCOM) or some other automated monitoring tool. Such a configuration is particularly important because an attacker who successfully compromises a server could clear the Security log. If all events are sent to a monitoring server, then you will be able to gather forensic information about the attacker's activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Policies\Microsoft\Windows\EventLog\Setup'
            $Name         = 'MaxSize'
            $Value        = '32768'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-store-passwords-using-reversible-encryption-is-set-to-disabled
    title: Ensure 'Store passwords using reversible encryption' is set to 'Disabled'
    impact: 100
    mql: |
      secpol.systemaccess['ClearTextPassword'] == 0
    docs:
      desc: |-
        This policy setting determines whether the operating system stores passwords in a way that uses reversible encryption, which provides support for application protocols that require knowledge of the user's password for authentication purposes. Passwords that are stored with reversible encryption are essentially the same as plaintext versions of the passwords.

        The recommended state for this setting is: `Disabled`.

        **Note:**
        Password Policy settings (section 1.1) and Account Lockout Policy settings (section 1.2) must be applied via the **Default Domain Policy**
        GPO in order to be globally in effect on **domain**
        user accounts as their default behavior. If these settings are configured in another GPO, they will only affect **local**
        user accounts on the computers that receive the GPO. However, custom exceptions to the default password policy and account lockout policy rules for specific domain users and/or groups can be defined using Password Settings Objects (PSOs), which are completely separate from Group Policy and most easily configured using Active Directory Administrative Center.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Account Policies\\Password Policy\\Store passwords using reversible encryption
            ```

            **Impact:**

            If your organization uses either the CHAP authentication protocol through remote access or IAS services or Digest Authentication in IIS, you must configure this policy setting to Enabled. This setting is extremely dangerous to apply through Group Policy on a user-by-user basis, because it requires the appropriate user account object to be opened in Active Directory Users and Computers.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $Temp = [System.Environment]::GetEnvironmentVariable('TEMP','Machine')
            secedit /export /cfg $Temp\secpol-export.cfg
            (gc $Temp\secpol-export.cfg) -replace("ClearTextPassword = \d+", "ClearTextPassword = 0") | Out-File $Temp\secpol-import.cfg
            secedit /import /db $Temp\secpol-db.sdb /cfg $Temp\secpol-import.cfg
            secedit /configure /db $Temp\secpol-db.sdb
            gpupdate /force
            Remove-Item -Path $Temp\secpol-export.cfg -Force
            Remove-Item -Path $Temp\secpol-import.cfg -Force
            Remove-Item -Path $Temp\secpol-db.sdb -Force
            ```
  - uid: mondoo-windows-security-system-control-event-log-behavior-when-the-log-file-reaches-its-maximum-size
    title: 'Ensure ''System: Control Event Log behavior when the log file reaches its maximum size'' is set to ''Disabled'''
    impact: 30
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\EventLog\System', name: 'Retention' ).value == '0'
    docs:
      desc: |-
        This policy setting controls Event Log behavior when the log file reaches its maximum size.

        The recommended state for this setting is: `Disabled`.

        **Note:**
        Old events may or may not be retained according to the _Backup log automatically when full_
        policy setting.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Event Log Service\\System\\Control Event Log behavior when the log file reaches its maximum size
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `EventLog.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was initially named _Retain old events_, but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            None - this is the default behavior.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Policies\Microsoft\Windows\EventLog\System'
            $Name         = 'Retention'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-system-specify-the-maximum-log-file-size-kb-is-set-to-enabled-32768
    title: 'Ensure ''System: Specify the maximum log file size (KB)'' is set to ''Enabled: 32,768 or greater'''
    impact: 50
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\EventLog\System', name: 'MaxSize' ).value >= 32768
    docs:
      desc: |-
        This policy setting specifies the maximum size of the log file in kilobytes. The maximum log file size can be configured between 1 megabyte (1,024 kilobytes) and 4 terabytes (4,194,240 kilobytes) in kilobyte increments.

        The recommended state for this setting is: `Enabled: 32,768 or greater`.
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled: 32,768 or greater`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Windows Components\\Event Log Service\\System\\Specify the maximum log file size (KB)
            ```

            **Note:**
            This Group Policy path is provided by the Group Policy template `EventLog.admx/adml`
            that is included with all versions of the Microsoft Windows Administrative Templates.

            **Note #2:**
            In older Microsoft Windows Administrative Templates, this setting was initially named _Maximum Log Size (KB)_, but it was renamed starting with the Windows 8.0 & Server 2012 (non-R2) Administrative Templates.

            **Impact:**

            When event logs fill to capacity, they will stop recording information unless the retention method for each is set so that the computer will overwrite the oldest entries with the most recent ones. To mitigate the risk of loss of recent data, you can configure the retention method so that older events are overwritten as needed.

            The consequence of this configuration is that older events will be removed from the logs. Attackers can take advantage of such a configuration, because they can generate a large number of extraneous events to overwrite any evidence of their attack. These risks can be somewhat reduced if you automate the archival and backup of event log data.

            Ideally, all specifically monitored events should be sent to a server that uses Microsoft System Center Operations Manager (SCOM) or some other automated monitoring tool. Such a configuration is particularly important because an attacker who successfully compromises a server could clear the Security log. If all events are sent to a monitoring server, then you will be able to gather forensic information about the attacker's activities.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\Software\Policies\Microsoft\Windows\EventLog\System'
            $Name         = 'MaxSize'
            $Value        = '32768'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-turn-off-multicast-name-resolution-is-set-to-enabled
    title: Ensure 'Turn off multicast name resolution' is set to 'Enabled'
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient', name: 'EnableMulticast' ).value == 0
    docs:
      desc: |-
        LLMNR is a secondary name resolution protocol. With LLMNR, queries are sent using multicast over a local network link on a single subnet from a client computer to another client computer on the same subnet that also has LLMNR enabled. LLMNR does not require a DNS server or DNS client configuration, and provides name resolution in scenarios in which conventional DNS name resolution is not possible.

        The recommended state for this setting is: `Enabled`
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Enabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\Network\\DNS Client\\Turn off multicast name resolution
            ```

            **Note:**
            This Group Policy path may not exist by default. It is provided by the Group Policy template `DnsClient.admx/adml`
            that is included with the Microsoft Windows 8.0 & Server 2012 (non-R2) Administrative Templates (or newer).

            **Impact:**

            In the event DNS is unavailable a system will be unable to request it from other systems on the same subnet.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient'
            $Name         = 'EnableMulticast'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-wdigest-authentication-is-set-to-disabled
    title: Ensure 'WDigest Authentication' is set to 'Disabled'
    impact: 80
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest', name: 'UseLogonCredential' ).value == 0
    docs:
      desc: |-
        When WDigest authentication is enabled, Lsass.exe retains a copy of the user's plaintext password in memory, where it can be at risk of theft. If this setting is not configured, WDigest authentication is disabled in Windows 8.1 and in Windows Server 2012 R2; it is enabled by default in earlier versions of Windows and Windows Server.

        For more information about local accounts and credential theft, review the " [Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques](https://www.microsoft.com/en-us/download/details.aspx?id=36036)" documents.

        For more information about `UseLogonCredential`, see Microsoft Knowledge Base article 2871997: [Microsoft Security Advisory Update to improve credentials protection and management May 13, 2014](https://support.microsoft.com/en-us/topic/microsoft-security-advisory-update-to-improve-credentials-protection-and-management-may-13-2014-93434251-04ac-b7f3-52aa-9f951c14b649)

        The recommended state for this setting is: `Disabled`
      remediation:
        - id: default
          desc: |-
            #### Group Policy Approach

            To establish the recommended configuration via GP, set the following UI path to `Disabled`:

            ```
            Computer Configuration\\Policies\\Administrative Templates\\MS Security Guide\\WDigest Authentication (disabling may require KB2871997)
            ```

            **Note:**
            This Group Policy path does not exist by default. An additional Group Policy template ( `SecGuide.admx/adml` ) is required - it is available from Microsoft at [this link](https://blogs.technet.microsoft.com/secguide/2018/11/20/security-baseline-final-for-windows-10-v1809-and-windows-server-2019/)

            **Impact:**

            None - this is also the default configuration for Windows 8.1 and newer.
        - id: powershell
          desc: |
            #### PowerShell Approach

            To establish the recommended configuration via PowerShell, run the following commands:

            ```powershell
            $RegistryPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest'
            $Name         = 'UseLogonCredential'
            $Value        = '0'

            # Create the key if it does not exist
            If (-NOT (Test-Path $RegistryPath)) {
                New-Item -Path $RegistryPath -Force | Out-Null
            }

            # Now set the value
            New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
            ```
  - uid: mondoo-windows-security-network-access-named-pipes-that-can-be-accessed-anonymously-is-set-to-none-dc
    filters: |
      windows.computerInfo.OsProductType == 2
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters', name: 'NullSessionPipes' ).value.downcase == /lsarpc|netlogon|samr/
  - uid: mondoo-windows-security-network-access-named-pipes-that-can-be-accessed-anonymously-is-set-to-none-ms
    filters: |
      windows.computerInfo.OsProductType != 2
    mql: |
      registrykey.property( path: 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters', name: 'NullSessionPipes' ).value == ""