#
#
# (C) 2014 Tenable Network Security, Inc.
#
# This script is released under the Tenable Subscription License and
# may not be used from within scripts released under another license
# without authorization from Tenable Network Security, Inc.
#
# See the following licenses for details:
#
# http://static.tenable.com/prod_docs/Nessus_5_SLA_and_Subscription_Agreement.pdf
# http://static.tenable.com/prod_docs/Subscription_Agreement.pdf
#
# @PROFESSIONALFEED@
# $Revision: 1.2 $
# $Date: 2014/05/15 14:10:48 $
#
# Description : This .audit is designed to query the Windows 7 OS
# as defined in the CIS Microsoft Windows 7 Benchmark v2.1.0 - 12-03-2013
#
#
#Safeguards Windows 7 Audit obÌåÓý v1.2a 4-28-2015
#
type : REGISTRY_SETTING
description :"1.1.1.2.1 Set 'Turn off Autoplay'"
info :"Set 'Turn off Autoplay' to 'Enabled:All drives' (Scored)
Autoplay starts to read from a drive as soon as you insert media in the drive, which causes
the setup file for programs or audio media to start immediately. An attacker could use this
feature to launch a program to damage the computer or data on the computer. You can
enable the Turn off Autoplay setting to disable the Autoplay feature. Autoplay is disabled
by default on some removable drive types, such as floppy disk and network drives, but not
on CD-ROM drives. Note You cannot use this policy setting to enable Autoplay on computer
drives in which it is disabled by default, such as floppy disk and network drives.
*Rationale*
An attacker could use this feature to launch a program to damage a client computer or data
on the computer."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to All drives.
Computer Configuration\Administrative Templates\Windows Components\AutoPlay
Policies\Turn off Autoplay
Impact-Users will have to manually launch setup or installation programs that are provided on
removable media.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9528-1,PCI-3.0|2.2.4,800-53|CM-7,Level|1S,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
reg_item : "NoDriveTypeAutoRun"
value_data : 255
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.3.1.1 Set 'Maximum Log Size' - Application"
info :"Set 'Maximum Log Size (KB)' to 'Enabled:32768' (Scored)
This policy requires Windows Vista or later versions of Windows. This policy setting
specifies the maximum size of the log file in kilobytes. If you enable this policy setting, you
can configure the maximum log file size to be between 1 megabyte (1024 kilobytes) and 2
terabytes (2147483647 kilobytes) in kilobyte increments. If you disable or do not
configure this policy setting, the maximum size of the log file maximum size will be set to
the local configuration value. This value can be changed by the local administrator using
the log properties dialog and it defaults to 20 megabytes. For backwards compatibility the
same setting can also be configured at
Computer Configuration\Windows Settings\Security
Settings\Event Log, if set at both locations this one will take precedence.
*Rationale*
If events are not recorded it may be difficult or impossible to determine the root cause of
system problems or the unauthorized activities of malicious users"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to 32768.
Computer Configuration\Administrative Templates\Windows Components\Event Log
Service\Application\Maximum Log Size (KB)
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 Operations Manager (MOM) 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.
Default Value-20480 KB"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9603-2,800-53|AU-2,PCI|10.7,800-53|AU-2,SANS-CSC|14"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\EventLog\Application"
reg_item : "MaxSize"
value_data : [32768..MAX]
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.3.1.2 Set 'Retain old events' - Application"
info :"Set 'Retain old events' to 'Disabled' (Scored)
This policy setting controls Event Log behavior when the log file reaches its maximum size.
Old events may or may not be retained according to the Backup log automatically when full
policy setting.
*Rationale*
If new events are not recorded it may be difficult or impossible to determine the root cause
of system problems or the unauthorized activities of malicious users"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\Windows Components\Event Log
Service\Application\Retain old events
Impact-When this policy setting is enabled and a log file reaches its maximum size, new events are
not written to the log and are lost. When this policy setting is disabled and a log file reaches
its maximum size, new events overwrite old events.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S,CCE|CCE-10136-0,PCI|10.7,800-53|AU-2,SANS-CSC|14"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\EventLog\Application"
reg_item : "Retention"
value_data : 0
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.3.2.1 Set 'Retain old events' - Security"
info :"Set 'Retain old events' to 'Disabled' (Scored)
This policy setting controls Event Log behavior when the log file reaches its maximum size.
Old events may or may not be retained according to the Backup log automatically when full
policy setting.
*Rationale*
If new events are not recorded it may be difficult or impossible to determine the root cause
of system problems or the unauthorized activities of malicious users"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\Windows Components\Event Log
Service\Security\Retain old events
Impact-When this policy setting is enabled and a log file reaches its maximum size, new events are
not written to the log and are lost. When this policy setting is disabled and a log file reaches
its maximum size, new events overwrite old events.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S,PCI|10.7,CCE|CCE-9500-0,PCI|10.7,800-53|AU-2,SANS-CSC|14"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\EventLog\Security"
reg_item : "Retention"
value_data : 0
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.3.2.2 Set 'Maximum Log Size' - Security"
info :"Set 'Maximum Log Size (KB)' to 'Enabled:81920' (Scored)
This policy requires Windows Vista or later versions of Windows. This policy setting
specifies the maximum size of the log file in kilobytes. If you enable this policy setting, you
can configure the maximum log file size to be between 1 megabyte (1024 kilobytes) and 2
terabytes (2147483647 kilobytes) in kilobyte increments. If you disable or do not
configure this policy setting, the maximum size of the log file maximum size will be set to
the local configuration value. This value can be changed by the local administrator using
the log properties dialog and it defaults to 20 megabytes. For backwards compatibility the
same setting can also be configured at
Computer Configuration\Windows Settings\Security
Settings\Event Log, if set at both locations this one will take precedence.
*Rationale*
If you significantly increase the number of objects to audit in your organization, there is a
risk that the Security log will reach its capacity and force the computer to shut down if you
enabled the Audit: Shut down system immediately if unable to log security audits setting. If such a shutdown occurs, the computer will be unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit- Shut down system immediately if unable to log security audits setting that is described in Chapter 5, 'Security Options,' and increase the Security log size. Alternatively, you can configure automatic log rotation as described in the Microsoft Knowledge Base article 'The event log stops logging events before reaching the maximum log size' at http://support.microsoft.com/default.aspx?kbid=312571."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to 81920.
Computer Configuration\Administrative Templates\Windows Components\Event Log
Service\Security\Maximum Log Size (KB)
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 Operations Manager (MOM) 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.
Default Value-20480 KB"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S,PCI|10.7,800-53|AU-2,SANS-CSC|14"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\EventLog\Security"
reg_item : "MaxSize"
value_data : [81920..MAX]
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.3.3.1 Set 'Maximum Log Size' - System"
info :"Set 'Maximum Log Size (KB)' to 'Enabled:32768' (Scored)
This policy requires Windows Vista or later versions of Windows. This policy setting
specifies the maximum size of the log file in kilobytes. If you enable this policy setting, you
can configure the maximum log file size to be between 1 megabyte (1024 kilobytes) and 2
terabytes (2147483647 kilobytes) in kilobyte increments. If you disable or do not
configure this policy setting, the maximum size of the log file maximum size will be set to
the local configuration value. This value can be changed by the local administrator using
the log properties dialog and it defaults to 20 megabytes. For backwards compatibility the
same setting can also be configured at
Computer Configuration\Windows Settings\Security
Settings\Event Log, if set at both locations this one will take precedence.
*Rationale*
If events are not recorded it may be difficult or impossible to determine the root cause of
system problems or the unauthorized activities of malicious users"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to 32768.
Computer Configuration\Administrative Templates\Windows Components\Event Log
Service\System\Maximum Log Size (KB)
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 Operations Manager (MOM) 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.
Default Value-20480 KB"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-10156-8,Level|1S,PCI|10.7,800-53|AU-2,SANS-CSC|14"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\EventLog\System"
reg_item : "MaxSize"
value_data : [32768..MAX]
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.3.3.2 Set 'Retain old events' - System"
info :"Set 'Retain old events' to 'Disabled' (Scored)
This policy setting controls Event Log behavior when the log file reaches its maximum size.
Old events may or may not be retained according to the Backup log automatically when full
policy setting.
*Rationale*
If new events are not recorded it may be difficult or impossible to determine the root cause
of system problems or the unauthorized activities of malicious users"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\Windows Components\Event Log
Service\System\Retain old events
Impact-When this policy setting is enabled and a log file reaches its maximum size, new events are
not written to the log and are lost. When this policy setting is disabled and a log file reaches
its maximum size, new events overwrite old events.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S,CCE|CCE-10064-4,PCI|10.7,800-53|AU-2,SANS-CSC|14"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\EventLog\System"
reg_item : "Retention"
value_data : 0
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.4.1 Set 'Allow Remote Shell Access'"
info :"Set 'Allow Remote Shell Access' to 'Enabled' (Scored)
This policy setting allows you to manage configuration of remote access to all supported
shells to execute scripts and commands.
*Rationale*
Any feature is a potential avenue of attack, those that enable inbound network connections
are particularly risky. Only enable the use of the Windows Remote Shell on trusted
networks and when feasible employ additional controls such as IPsec."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\Windows Components\Windows Remote
Shell\Allow Remote Shell Access
Impact-If you enable this policy setting, remote access is allowed to all supported shells to execute
scripts and commands. If you disable or do not configure this policy setting, remote access
is not allowed to all supported shells to execute scripts and commands.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-3,CCE|CCE-10077-6,800-53|AC-1,Level|1S,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\WinRM\Service\WinRS"
reg_item : "AllowRemoteShellAccess"
value_data : 1
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.5.1 Set 'Turn off Data Execution Prevention'"
info :"Set 'Turn off Data Execution Prevention for Explorer' to 'Disabled' (Scored)
Disabling data execution prevention can allow certain legacy plug-in applications to
function without terminating Explorer.
*Rationale*
Data execution prevention helps reduce the risk of certain classes of attacks by blocking the
execution of code stored where the system only expects data to be stored."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\Windows Components\Windows
Explorer\Turn off Data Execution Prevention for Explorer
Impact-Date execution prevent can cause certain plug-in applications for Windows Explorer to fail.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9918-4,PCI-3.0|2.2.4,Level|1S,800-53|CM-3"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\Explorer"
reg_item : "NoDataExecutionPrevention"
value_data : 0
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.6.1 Set 'Configure Automatic Updates' - NoAutoUpdate"
info :"Set 'Configure Automatic Updates' to 'Enabled:3 - Auto download and notify for install' (Scored) - NoAutoUpdate
This policy setting specifies whether computers in your environment will receive security
updates from Windows Update or WSUS. If you configure this policy setting to Enabled, the
operating system will recognize when a network connection is available and then use the
network connection to search Windows Update or your designated intranet site for
updates that apply to them. After you configure this policy setting to Enabled, select one of
the following three options in the Configure Automatic Updates Properties dialog box to
specify how the service will work- . Notify before downloading any updates and notify
again before installing them. . Download the updates automatically and notify when they
are ready to be installed. (Default setting) . Automatically download updates and install
them on the schedule specified below. If you disable this policy setting, you will need to
download and manually install any available updates from Windows Update.
*Rationale*
Although each version of Windows is thoroughly tested before release, it is possible that
problems will be discovered after the products are shipped. The Configure Automatic
Updates setting can help you ensure that the computers in your environment will always
have the most recent critical operating system updates and service packs installed."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to 3 - Auto download and notify for install.
Computer Configuration\Administrative Templates\Windows Components\Windows
Update\Configure Automatic Updates
Impact-Critical operating system updates and service packs will automatically download and
install at 3-00 A.M. daily.
Default Value-Download the updates automatically and notify when they are ready to be installed"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SI-2,PCI-3.0|2.2.4,Level|1S,800-53|CM-3,CCE|CCE-9403-7"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU"
reg_item : "NoAutoUpdate"
value_data : 0
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.6.1 Set 'Configure Automatic Updates' - AUOptions"
info :"Set 'Configure Automatic Updates' to 'Enabled:3 - Auto download and notify for install' (Scored) - AUOptions
This policy setting specifies whether computers in your environment will receive security
updates from Windows Update or WSUS. If you configure this policy setting to Enabled, the
operating system will recognize when a network connection is available and then use the
network connection to search Windows Update or your designated intranet site for
updates that apply to them. After you configure this policy setting to Enabled, select one of
the following three options in the Configure Automatic Updates Properties dialog box to
specify how the service will work- . Notify before downloading any updates and notify
again before installing them. . Download the updates automatically and notify when they
are ready to be installed. (Default setting) . Automatically download updates and install
them on the schedule specified below. If you disable this policy setting, you will need to
download and manually install any available updates from Windows Update.
*Rationale*
Although each version of Windows is thoroughly tested before release, it is possible that
problems will be discovered after the products are shipped. The Configure Automatic
Updates setting can help you ensure that the computers in your environment will always
have the most recent critical operating system updates and service packs installed."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to 3 - Auto download and notify for install.
Computer Configuration\Administrative Templates\Windows Components\Windows
Update\Configure Automatic Updates
Impact-Critical operating system updates and service packs will automatically download and
install at 3-00 A.M. daily.
Default Value-Download the updates automatically and notify when they are ready to be installed"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SI-2,PCI-3.0|2.2.4,Level|1S,800-53|CM-3,CCE|CCE-9403-7"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU"
reg_item : "AUOptions"
value_data : 3
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.6.2 Set 'Reschedule Automatic Updates' - RescheduleWaitTimeEnabled"
info :"Set 'Reschedule Automatic Updates scheduled installations' to 'Enabled:1' (Scored)-RescheduleWaitTimeEnabled
This policy setting determines the amount of time before previously scheduled Automatic
Update installations will proceed after system startup. If you configure this policy setting to
Enabled, a previously scheduled installation will begin after a specified number of minutes
when you next start the computer. If you configure this policy setting to Disabled or Not
configured, previously scheduled installations will occur during the next regularly
scheduled installation time. Note- This policy setting only works when Automatic Updates
is configured to perform scheduled update installations. If the Configure Automatic
Updates setting is Disabled, the Reschedule Automatic Updates scheduled installations
setting has no effect. You can enable the latter two settings to ensure that previously
missed installations will be scheduled to install each time the computer restarts.
*Rationale*
If Automatic Updates is not forced to wait a few minutes after a restart, computers in your
environment might not have enough time to completely start all of their applications and
services. If you specify enough time after a restart, new update installations should not
conflict with the computer's startup procedures."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to 1.
Computer Configuration\Administrative Templates\Windows Components\Windows
Update\Reschedule Automatic Updates scheduled installations
Impact-Automatic Updates will not start until 10 minutes after the computer restarts.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SI-2,CCE|CCE-10205-3,PCI-3.0|2.2.4,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU"
reg_item : "RescheduleWaitTimeEnabled"
value_data : 1
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.6.2 Set 'Reschedule Automatic Updates' - RescheduleWaitTime"
info :"Set 'Reschedule Automatic Updates scheduled installations' to 'Enabled:1' (Scored)-RescheduleWaitTime
This policy setting determines the amount of time before previously scheduled Automatic
Update installations will proceed after system startup. If you configure this policy setting to
Enabled, a previously scheduled installation will begin after a specified number of minutes
when you next start the computer. If you configure this policy setting to Disabled or Not
configured, previously scheduled installations will occur during the next regularly
scheduled installation time. Note- This policy setting only works when Automatic Updates
is configured to perform scheduled update installations. If the Configure Automatic
Updates setting is Disabled, the Reschedule Automatic Updates scheduled installations
setting has no effect. You can enable the latter two settings to ensure that previously
missed installations will be scheduled to install each time the computer restarts.
*Rationale*
If Automatic Updates is not forced to wait a few minutes after a restart, computers in your
environment might not have enough time to completely start all of their applications and
services. If you specify enough time after a restart, new update installations should not
conflict with the computer's startup procedures."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to 1.
Computer Configuration\Administrative Templates\Windows Components\Windows
Update\Reschedule Automatic Updates scheduled installations
Impact-Automatic Updates will not start until 10 minutes after the computer restarts.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SI-2,CCE|CCE-10205-3,PCI-3.0|2.2.4,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU"
reg_item : "RescheduleWaitTime"
value_data : 1
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.6.3 Set 'No auto- restart'"
info :"Set 'No auto- restart with logged on users for scheduled automatic updates installations' to 'Disabled' (Scored)
This policy setting specifies that Automatic Updates will wait for computers to be restarted
by the users who are logged on to them to complete a scheduled installation. If you enable
the No auto-restart for scheduled Automatic Updates installations setting, Automatic
Updates does not restart computers automatically during scheduled installations. Instead,
Automatic Updates notifies users to restart their computers to complete the installations.
You should note that Automatic Updates will not be able to detect future updates until
restarts occur on the affected computers. If you disable or do not configure this setting,
Automatic Updates will notify users that their computers will automatically restart in 5
minutes to complete the installations. The possible values for the No auto-restart for
scheduled Automatic Updates installations setting are- . Enabled . Disabled . Not Configured
Note- This setting applies only when you configure Automatic Updates to perform
scheduled update installations. If you configure the Configure Automatic Updates setting to
Disabled, this setting has no effect.
*Rationale*
Sometimes updates require updated computers to be restarted to complete an installation.
If the computer cannot restart automatically, then the most recent update will not
completely install and no new updates will download to the computer until it is restarted."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\Windows Components\Windows Update\No
auto-restart with logged on users for scheduled automatic updates installations
Impact-If you enable this policy setting, the operating systems on the servers in your environment
will restart themselves automatically. For critical servers this could lead to a temporary
denial of service (DoS) condition.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9672-7,800-53|IA-2,PCI-3.0|2.2.4,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU"
reg_item : "NoAutoRebootWithLoggedOnUsers"
value_data : 0
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.6.4 Set 'Do not display'"
info :"Set 'Do not display 'Install Updates and Shut Down' option in Shut Down Windows dialog box' to 'Disabled' (Scored)
This policy setting allows you to manage whether the Install Updates and Shut Down
option is displayed in the Shut Down Windows dialog box. This policy setting works in
conjunction with the following Do not adjust default option to ‘Install Updates and Shut
Down' in Shut Down Windows Dialog box setting.
*Rationale*
Updates are important for maintaining the ongoing security of a computer, therefore this
setting should not be enabled."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\Windows Components\Windows Update\Do
not display 'Install Updates and Shut Down' option in Shut Down Windows dialog box
Impact-If you disable this policy setting, the Install Updates and Shut Down option will display in
the Shut Down Windows dialog box if updates are available when the user selects the Shut
Down option in the Start menu.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SI-2,PCI-3.0|2.2.4,CCE|CCE-9464-9,Level|1S,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU"
reg_item : "NoAUShutdownOption"
value_data : 0
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.6.5 Set 'Do not adjust default option'"
info :"Set 'Do not adjust default option to 'Install Updates and Shut Down' in Shut Down Windows dialog box' to 'Disabled' (Scored)
This policy setting allows you to manage whether the 'Install Updates and Shut Down'
option is allowed to be the default choice in the Shut Down Windows dialog. Note that this
policy setting has no impact if the
Computer Configuration\Administrative
Templates\Windows Components\Windows Update\Do not display 'Install Updates and
Shut Down' option in Shut Down Windows dialog box policy setting is enabled.
*Rationale*
Updates are important for maintaining the ongoing security of a computer, therefore this
setting should not be enabled."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\Windows Components\Windows Update\Do
not adjust default option to 'Install Updates and Shut Down' in Shut Down Windows
dialog box
Impact-If you enable this policy setting, the user's last shut down choice (Hibernate, Restart, etc.) is
the default option in the Shut Down Windows dialog box, regardless of whether the 'Install
Updates and Shut Down' option is available in the 'What do you want the computer to do?'
list. If you disable or do not configure this policy setting, the 'Install Updates and Shut
Down' option will be the default option in the Shut Down Windows dialog box if updates
are available for installation at the time the user selects the Shut Down option in the Start
menu.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S, CCE|CCE-9733-7"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU"
reg_item : "NoAUAsDefaultShutdownOption"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.7.1 Set 'Enumerate administrator accounts'"
info :"Set 'Enumerate administrator accounts on elevation' to 'Disabled' (Scored)
By default, all administrator accounts are displayed when you attempt to elevate a running
application.
*Rationale*
Users could see the list of administrator accounts, making it slightly easier for a malicious
user who has logged onto a console session to try to crack the passwords of those accounts."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\Windows Components\Credential User
Interface\Enumerate administrator accounts on elevation
Impact-If you enable this policy setting, all local administrator accounts on the machine will be
displayed so the user can choose one and enter the correct password. If you disable this
policy setting, users will be required to always type in a username and password to elevate.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9938-2,800-53|AC-3,800-53|AC-2,PCI-3.0|2.2.4,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\CredUI"
reg_item : "EnumerateAdministrators"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.8.1.1.1 Set 'Always prompt for password upon connection'"
info :"Set 'Always prompt for password upon connection' to 'Enabled' (Scored)
This policy setting specifies whether Terminal 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 Terminal Services, even if they already provided
the password in the Remote Desktop Connection client. By default, Terminal Services
allows users to automatically log on if they enter a password in the Remote Desktop
Connection client. Note If you do not configure this policy setting, the local computer
administrator can use the Terminal Services Configuration tool to either allow or prevent
passwords from being automatically sent.
*Rationale*
Users have the option to store both their username and password when they create a new
Remote Desktop connection shortcut. If the server that runs Terminal Services allows users
who have used this feature to log on to the server but not enter their password, then it is
possible that an attacker who has gained physical access to the user's computer could
connect to a Terminal Server through the Remote Desktop connection shortcut, even
though they may not know the user's password."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop
Services\Remote Desktop Session Host\Security\Always prompt for password upon
connection
Impact-Users will always have to enter their password when they establish new Terminal Server
sessions.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"SANS-CSC|16,Level|1S,CCE|CCE-10103-0,CSF|DE.CM-1,800-53|IA-2,PCI-3.0|2.2.4,CSF|PR.AC-1,800-53|AC-1"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
reg_item : "fPromptForPassword"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.8.1.1.2 Set 'Set client connection'"
info :"Set 'Set client connection encryption level' to 'Enabled:High Level' (Scored)
This policy setting specifies whether the computer that is about to host the remote
connection will enforce an encryption level for all data sent between it and the client
computer for the remote session.
*Rationale*
If Terminal Server client connections are allowed that use low level encryption, it is more
likely that an attacker will be able to decrypt any captured Terminal Services network
traffic."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to High Level.
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop
Services\Remote Desktop Session Host\Security\Set client connection encryption level
Impact-Clients that do not support 128-bit encryption will be unable to establish Terminal Server
sessions.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-9,Level|1S,CCE|CCE-9764-2,PCI-3.0|2.2.4"
value_type : POLICY_DWORD
value_data : 3
reg_key : "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
reg_item : "MinEncryptionLevel"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.8.1.2.1 Set 'Do not allow drive redirection'"
info :"Set 'Do not allow drive redirection' to 'Enabled' (Scored)
This policy setting prevents users from sharing the local drives on their client computers to
Terminal Servers that they access. Mapped drives appear in the session folder tree in
Windows Explorer in the following format- \\TSClient\$ If local drives are
shared they are left vulnerable to intruders who want to exploit the data that is stored on
them.
*Rationale*
Data could be forwarded from the user's Terminal Server session to the user's local
computer without any direct user interaction."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop
Services\Remote Desktop Session Host\Device and Resource Redirection\Do not allow
drive redirection
Impact-Drive redirection will not be possible.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9518-2,CSF|PR.IP-1,Level|1S,SANS-CSC|3,PCI-3.0|2.2.4,800-53|CM-6"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
reg_item : "fDisableCdm"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.1.8.2.1 Set 'Do not allow passwords to be saved'"
info :"Set 'Do not allow passwords to be saved' to 'Enabled' (Scored)
This policy setting helps prevent Terminal Services clients from saving passwords on a
computer. Note If this policy setting was previously configured as Disabled or Not
configured, any previously saved passwords will be deleted the first time a Terminal
Services client disconnects from any server.
*Rationale*
An attacker with physical access to the computer may be able to break the protection
guarding saved passwords. An attacker who compromises a user's account and connects to
their computer could use saved passwords to gain access to additional hosts."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop
Services\Remote Desktop Connection Client\Do not allow passwords to be saved
Impact-If you enable this policy setting, the password saving checkbox is disabled for Terminal
Services clients and users will not be able to save passwords.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"SANS-CSC|16,800-53|IA-5,CCE|CCE-10090-9,Level|1S,CSF|DE.CM-1,800-53|IA-2,CSF|PR.AC-1"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
reg_item : "DisablePasswordSaving"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.1.1.1 Set 'Allow Standby States (S1- S3) When Sleeping (Plugged In)'"
info :"Set 'Allow Standby States (S1- S3) When Sleeping (Plugged In)' to 'Disabled' (Scored)
Dictates whether or not Windows is allowed to use standby states when sleeping the
computer. When this policy is enabled, Windows may use standby states to sleep the
computer. If this policy is disabled, the only sleep state a computer may enter is hibernate.
*Rationale*
System sleep states (S1-S3) keep power to the RAM which may contain secrets, such as the
BitLocker volume encryption key. An attacker finding a computer in sleep states (S1-S3)
could directly attack the memory of the computer and gain access to the secrets through
techniques such as RAM reminisce and direct memory access (DMA)."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\System\Power Management\Sleep
Settings\Allow Standby States (S1-S3) When Sleeping (Plugged In)
Impact-Users will not be able to use Sleep (S3) which resumes faster than Hibernation (S4).
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S, CCE|CCE-9126-4"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Power\PowerSettings\abfc2519-3608-4c2a-94ea-171b0ed546ab"
reg_item : "ACSettingIndex"
value_data : "0"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.1.1.2 Set 'Require a Password When a Computer Wakes (On Battery)'"
info :"Set 'Require a Password When a Computer Wakes (On Battery)' to 'Enabled' (Scored)
Specifies whether or not the user is prompted for a password when the system resumes
from sleep.
*Rationale*
Enabling this setting ensures that anyone who wakes an unattended computer from sleep
state will have to provide logon credentials before they can access the system."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Power Management\Sleep
Settings\Require a Password When a Computer Wakes (On Battery)
Impact-If you enable this policy, or if it is not configured, the user is prompted for a password
when the system resumes from sleep. If you disable this policy, the user is not prompted
for a password when the system resumes from sleep.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|IA-5,Level|1S,CCE|CCE-9829-3,PCI-3.0|2.2.4"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Power\PowerSettings\0e796bdb-100d-47d6-a2d5-f7d2daa51f51"
reg_item : "DCSettingIndex"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.1.1.3 Set 'Allow Standby States (S1- S3) When Sleeping (On Battery)'"
info :"Set 'Allow Standby States (S1- S3) When Sleeping (On Battery)' to 'Disabled' (Scored)
Dictates whether or not Windows is allowed to use standby states when sleeping the
computer. When this policy is enabled, Windows may use standby states to sleep the
computer. If this policy is disabled, the only sleep state a computer may enter is hibernate.
*Rationale*
System sleep states (S1-S3) keep power to the RAM which may contain secrets, such as the
BitLocker volume encryption key. An attacker finding a computer in sleep states (S1-S3)
could directly attack the memory of the computer and gain access to the secrets through
techniques such as RAM reminisce and direct memory access (DMA)."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\System\Power Management\Sleep
Settings\Allow Standby States (S1-S3) When Sleeping (On Battery)
Impact-Users will not be able to use Sleep (S3) which resumes faster than Hibernation (S4).
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S,CCE|CCE-8844-3"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Power\PowerSettings\abfc2519-3608-4c2a-94ea-171b0ed546ab"
reg_item : "DCSettingIndex"
value_data : "0"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.1.1.4 Set 'Require a Password When a Computer Wakes (Plugged In)'"
info :"Set 'Require a Password When a Computer Wakes (Plugged In)' to 'Enabled' (Scored)
Specifies whether or not the user is prompted for a password when the system resumes
from sleep.
*Rationale*
Enabling this setting ensures that anyone who wakes an unattended computer from sleep
state will have to provide logon credentials before they can access the system."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Power Management\Sleep
Settings\Require a Password When a Computer Wakes (Plugged In)
Impact-If you enable this policy, or if it is not configured, the user is prompted for a password
when the system resumes from sleep. If you disable this policy, the user is not prompted
for a password when the system resumes from sleep.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|IA-5,Level|1S,CCE|CCE-9670-1,PCI-3.0|2.2.4"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Power\PowerSettings\0e796bdb-100d-47d6-a2d5-f7d2daa51f51"
reg_item : "ACSettingIndex"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.2.1.1 Set 'Turn off Internet download for Web publishing and online ordering wizards'"
info :"Set 'Turn off Internet download for Web publishing and online ordering wizards' to 'Enabled' (Scored)
This policy setting controls whether Windows will download a list of providers for the Web
publishing and online ordering wizards.
*Rationale*
Although the risk is minimal, enabling this setting will reduce the possibility of a user
unknowingly downloading malicious content through this feature."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Internet Communication
Management\Internet Communication settings\Turn off Internet download for Web
publishing and online ordering wizards
Impact-If this policy setting is enabled, Windows is prevented from downloading providers; only
the service providers cached in the local registry will display.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9674-3,Level|1S,PCI-3.0|2.2.4,800-53|CM-3"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
reg_item : "NoWebServices"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.2.1.2 Set 'Turn off Windows Update'"
info :"Set 'Turn off Windows Update device driver searching' to 'Enabled' (Scored)
This policy setting specifies whether Windows will search Windows Update for device
drivers when no local drivers for a device are present. Note See also Turn off Windows
Update device driver search prompt in Administrative Templates/System, which governs
whether an administrator is prompted before Windows Update is searched for device
drivers if a driver is not found locally.
*Rationale*
If users are able to download and install device drivers there is a small chance that they
will install a driver that reduces system stability. There is an even smaller possibility that
they will install a driver that includes malicious code. These risks are very low because
Microsoft requires vendors to test drivers extensively before they can be published on
Windows Update."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Internet Communication
Management\Internet Communication settings\Turn off Windows Update device driver
searching
Impact-Users will not be able to download new or updated device drivers from Windows Update.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SI-2,Level|1S,PCI-3.0|2.2.4,CCE|CCE-10093-3"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\DriverSearching"
reg_item : "DontSearchWindowsUpdate"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.2.1.3 Set 'Turn off the 'Publish to Web'"
info :"Set 'Turn off the 'Publish to Web' task for files and folders' to 'Enabled' (Scored)
This policy setting specifies whether the tasks Publish this file to the Web, Publish this
folder to the Web, and Publish the selected items to the Web are available from obÌåÓý and
Folder Tasks in Windows folders.
*Rationale*
Users may publish confidential or sensitive information to a public service outside of the
control of the organization."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Internet Communication
Management\Internet Communication settings\Turn off the 'Publish to Web' task for
files and folders
Impact-The Web Publishing wizard is used to download a list of providers and allow users to
publish content to the Web.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9643-8,CSF|PR.IP-1,Level|1S,SANS-CSC|3,PCI-3.0|2.2.4,800-53|CM-6"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
reg_item : "NoPublishingWizard"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.2.1.4 Set 'Turn off the Windows Messenger'"
info :"Set 'Turn off the Windows Messenger Customer Experience Improvement Program' to 'Enabled' (Scored)
This policy setting specifies whether Windows Messenger can collect anonymous
information about how the Windows Messenger software and service is used.
*Rationale*
Large enterprise environments may not want to have information collected from managed
client computers."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Internet Communication
Management\Internet Communication settings\Turn off the Windows Messenger Customer
Experience Improvement Program
Impact-Microsoft uses information collected through the Customer Experience Improvement
Program to detect software flaws so that they can be corrected more quickly, enabling this
setting will reduce the amount of data Microsoft is able to gather for this purpose.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9559-6,CSF|PR.IP-1,Level|1S,SANS-CSC|3,PCI-3.0|2.2.4,800-53|CM-6,800-53|CM-7"
value_type : POLICY_DWORD
value_data : 2
reg_key : "HKLM\Software\Policies\Microsoft\Messenger\Client"
reg_item : "CEIP"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.2.1.5 Set 'Turn off Search Companion'"
info :"Set 'Turn off Search Companion content file updates' to 'Enabled' (Scored)
This policy setting specifies whether Search Companion should automatically download
content updates during local and Internet searches.
*Rationale*
There is a small risk that users will unknowingly reveal sensitive information because of
the topics they are searching for. This risk is very low because even if this setting is enabled
users still must submit search queries to the desired search engine in order to perform
searches."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Internet Communication
Management\Internet Communication settings\Turn off Search Companion content file
updates
Impact-Internet searches will still send the search text and information about the search to
Microsoft and the chosen search provider. If you select Classic Search, the Search
Companion feature will be unavailable. You can select Classic Search by clicking Start,
Search, Change Preferences, and then Change Internet Search Behavior.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S,CCE|CCE-10140-2,PCI-3.0|2.2.4,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\SearchCompanion"
reg_item : "DisableContentobÌåÓýUpdates"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.2.1.6 Set 'Turn off downloading of print drivers over HTTP'"
info :"Set 'Turn off downloading of print drivers over HTTP' to 'Enabled' (Scored)
This policy setting controls whether the computer can download print driver packages
over HTTP. To set up HTTP printing, printer drivers that are not available in the standard
operating system installation might need to be downloaded over HTTP.
*Rationale*
Users might download drivers that include malicious code."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Internet Communication
Management\Internet Communication settings\Turn off downloading of print drivers over
HTTP
Impact-This policy setting does not prevent the client computer from printing to printers on the
intranet or the Internet over HTTP. It only prohibits drivers that are not already installed
locally from downloading.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.IP-1,Level|1S,SANS-CSC|3,CCE|CCE-9195-9,PCI-3.0|2.2.4,800-53|CM-6,800-53|CM-3"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\Software\Policies\Microsoft\Windows NT\Printers"
reg_item : "DisableWebPnPDownload"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.2.1.7 Set 'Turn off printing over HTTP'"
info :"Set 'Turn off printing over HTTP' to 'Enabled' (Scored)
This policy setting allows you to disable the client computer's ability to print over HTTP,
which allows the computer to print to printers on the intranet as well as the Internet.
*Rationale*
Information that is transmitted over HTTP through this capability is not protected and can
be intercepted by malicious users. For this reason, it is not often used in enterprise
environments."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Internet Communication
Management\Internet Communication settings\Turn off printing over HTTP
Impact-If you enable this policy setting, the client computer will not be able to print to Internet
printers over HTTP. This policy setting affects the client side of Internet printing only.
Regardless of how it is configured, a computer could act as an Internet Printing server and
make its shared printers available through HTTP.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.IP-1,Level|1S,SANS-CSC|3,CCE|CCE-10061-0,PCI-3.0|2.2.4,800-53|CM-6,800-53|CM-3"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\Software\Policies\Microsoft\Windows NT\Printers"
reg_item : "DisableHTTPPrinting"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.3.1 Set 'Restrictions for Unauthenticated RPC clients'"
info :"Set 'Restrictions for Unauthenticated RPC clients' to 'Enabled:Authenticated' (Scored)
This policy setting configures the RPC Runtime on an RPC server to restrict
unauthenticated RPC clients from connecting to the RPC server. A client will be considered
an authenticated client if it uses a named pipe to communicate with the server or if it uses
RPC Security. RPC interfaces that have specifically asked to be accessible by
unauthenticated clients may be exempt from this restriction, depending on the selected
value for this policy.
*Rationale*
Unauthenticated RPC communication can create a security vulnerability."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to Authenticated.
Computer Configuration\Administrative Templates\System\Remote Procedure
Call\Restrictions for Unauthenticated RPC clients
Impact-RPC applications that do not authenticate unsolicited inbound connection requests may not
work properly when this configuration is applied. Ensure you test applications before you
deploy this policy setting throughout your environment. Although the Authenticated value
for this policy setting is not completely secure, it can be useful for providing application
compatibility in your environment.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S,CCE|CCE-9396-3,PCI-3.0|2.2.4,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows NT\Rpc"
reg_item : "RestrictRemoteClients"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.3.2 Set 'RPC Endpoint Mapper'"
info :"Set 'RPC Endpoint Mapper Client Authentication' to 'Enabled' (Scored)
If you enable this policy setting, client computers that communicate with this computer are
forced to provide authentication before RPC communication can be established. By default,
RPC clients do not use authentication to communicate with the RPC Server Endpoint
Mapper Service when they request the endpoint of a server.
*Rationale*
Anonymous access to RPC services could result in accidental disclosure of information to
unauthenticated users."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
Computer Configuration\Administrative Templates\System\Remote Procedure Call\RPC
Endpoint Mapper Client Authentication
Impact-RPC clients will be forced to authenticate before they can begin communicating with the
desired RPC service, this means that anonymous access will not be available and RPC
clients that do not support authentication will fail.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-10181-6,CSF|PR.IP-1,Level|1S,SANS-CSC|3,800-53|IA-2,PCI-3.0|2.2.4,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows NT\Rpc"
reg_item : "EnableAuthEpResolution"
value_data : 1
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.4.1 Set 'Solicited Remote Assistance'"
info :"Set 'Solicited Remote Assistance' to 'Disabled' (Scored)
This policy setting determines whether remote assistance may be solicited from computers
running Windows operating systems in your environment. You can enable this policy
setting to allow users to solicit remote assistance from IT expert administrators. If the
Solicited Remote Assistance setting is enabled, the following options are available- . Allow
helpers to remotely control the computer . Allow helpers to only view the computer Also,
the following options are available to configure the amount of time that a user help request
remains valid- . Maximum ticket time (value)- . Maximum ticket time (units)- hours,
minutes or days When a ticket (help request) expires, the user must send another request
before an expert can connect to the computer. If you disable the Solicited Remote
Assistance setting, users cannot send help requests and the expert cannot connect to their
computers. If the Solicited Remote Assistance setting is not configured, users can configure
solicited remote assistance through the Control Panel. The following settings are enabled
by default in the Control Panel- Solicited Remote Assistance, Buddy support, and Remote
control. The value for the Maximum ticket time is set to 30 days. If this policy setting is
disabled, no one will be able to access Windows Vista client computers across the network.
*Rationale*
There is slight risk that a rogue administrator will gain access to another user's desktop
session, however, they cannot connect to a user's computer unannounced or control it
without permission from the user. When an expert tries to connect, the user can still
choose to deny the connection or give the expert view-only privileges. The user must
explicitly click the Yes button to allow the expert to remotely control the workstation."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\System\Remote Assistance\Solicited
Remote Assistance
Impact-If you enable this policy, users on this computer can use e-mail or file transfer to ask
someone for help. Also, users can use instant messaging programs to allow connections to
this computer, and you can configure additional Remote Assistance settings. If you disable
this policy, users on this computer cannot use e-mail or file transfer to ask someone for
help. Also, users cannot use instant messaging programs to allow connections to this
computer. If you don't configure this policy, users can enable or disable Solicited (Ask for)
Remote Assistance themselves in System Properties in Control Panel. Users can also
configure Remote Assistance settings. If you enable this policy setting, you have two ways
to allow helpers to provide Remote Assistance- 'Allow helpers to only view the computer'
or 'Allow helpers to remotely control the computer.' The 'Maximum ticket time' setting
sets a limit on the amount of time that a Remote Assistance invitation created by using e-
mail or file transfer can remain open. The 'Select the method for sending e-mail
invitations' setting specifies which e-mail standard to use to send Remote Assistance
invitations. Depending on your e-mail program, you can use either the Mailto standard (the
invitation recipient connects through an Internet link) or the SMAPI (Simple MAPI)
standard (the invitation is attached to your e-mail message). This setting is not available in
Windows Vista since SMAPI is the only method supported. If you enable this policy you
should also enable appropriate firewall exceptions to allow Remote Assistance
communications.
Default Value-Not configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.IP-1,Level|1S,SANS-CSC|3,CCE|CCE-9506-7,PCI-3.0|2.2.4,800-53|CM-6"
value_type : POLICY_DWORD
value_data : 0
reg_key : "HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services"
reg_item : "fAllowToGetHelp"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.4.2 Set 'Offer Remote Assistance' to 'Disabled' (Scored)"
info :"This policy setting determines whether a support person or an IT expert administrator can
offer remote assistance to computers in your environment if a user does not explicitly
request assistance first through a channel, such as e-mail, or Instant Messenger. Note The
expert cannot connect to the computer unannounced or control it without permission from
the user. When the expert tries to connect, the user can still choose to deny the connection
or give the expert view-only privileges. The user must explicitly click the Yes button to
allow the expert to remotely control the workstation after the Offer Remote Assistance
setting is configured to Enabled. If this policy setting is enabled the following options are
available- . Allow helpers to only view the computer . Allow helpers to remotely control the
computer When you configure this policy setting, you can also specify a list of users or user
groups known as helpers who may offer remote assistance. To configure the list of helpers
1. In the Offer Remote Assistance setting configuration window, click Show. A new window
will open in which you can enter helper names. 2. Add each user or group to the Helper list
in one of the following formats- . \ . \ If this policy setting is disabled or not configured, users and or groups will not be
able to offer unsolicited remote assistance to computer users in your environment.
*Rationale*
A user might be tricked and accept an unsolicited Remote Assistance offer from a malicious
user."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
Computer Configuration\Administrative Templates\System\Remote Assistance\Offer Remote
Assistance
Impact-Help desk and support personnel will not be able to proactively offer assistance, although
they can still respond to user assistance requests.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.IP-1,Level|1S,SANS-CSC|3,PCI-3.0|2.2.4,800-53|AC-1,CCE|CCE-9960-6,800-53|CM-6"
value_type : POLICY_DWORD
value_data : 0
reg_key : "HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services"
reg_item : "fAllowUnsolicited"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.5.1 Set 'Registry policy processing' to 'Enabled'"
info :"Set 'Do not apply during periodic background processing' to 'False' (Scored)
If this policy setting is enabled, the following options are available-
. Do not apply during periodic background processing.
. Process even if the Group Policy objects have not changed.
*Rationale*
You can enable this setting and then select the Process even if the Group Policy objects
have not changed option to ensure that the policies will be reprocessed even if none have
been changed. This way, any unauthorized changes that might have been configured locally
are forced to match the domain based Group Policy settings again."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Administrative Templates\System\Group Policy-Do not apply
during periodic background processing
Impact-Group Policies will be reapplied every time they are refreshed, which could have a slight
impact on performance.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|CM-2,CSF|PR.IP-1,Level|1S,SANS-CSC|3,PCI-3.0|2.2.4,CCE|CCE-9361-7,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\Group Policy\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}"
reg_item : "NoBackgroundPolicy"
value_data : 0
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.5.2 Set 'Do not apply during periodic background processing'"
info :"Set 'Do not apply during periodic background processing' to 'False' (Scored)
If this policy setting is enabled, the following options are available-
. Do not apply during periodic background processing.
. Process even if the Group Policy objects have not changed.
*Rationale*
You can enable this setting and then select the Process even if the Group Policy objects
have not changed option to ensure that the policies will be reprocessed even if none have
been changed. This way, any unauthorized changes that might have been configured locally
are forced to match the domain based Group Policy settings again."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Administrative Templates\System\Group Policy-Do not apply
during periodic background processing
Impact-Group Policies will be reapplied every time they are refreshed, which could have a slight
impact on performance.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|CM-2,CSF|PR.IP-1,Level|1S,SANS-CSC|3,PCI-3.0|2.2.4,CCE|CCE-9361-7,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\Group Policy\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}"
reg_item : "NoBackgroundPolicy"
value_data : 0
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.1.2.5.3 Set 'Process even if the Group Policy objects have not changed'"
info :"Set 'Process even if the Group Policy objects have not changed' to 'True' (Scored)
If this policy setting is enabled, the following options are available-
. Do not apply during periodic background processing.
. Process even if the Group Policy objects have not changed.
*Rationale*
You can enable this setting and then select the Process even if the Group Policy objects
have not changed option to ensure that the policies will be reprocessed even if none have
been changed. This way, any unauthorized changes that might have been configured locally
are forced to match the domain based Group Policy settings again."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Administrative Templates\System\Group Policy-Process even if
the Group Policy objects have not changed
Impact-Group Policies will be reapplied every time they are refreshed, which could have a slight
impact on performance.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|CM-2,CSF|PR.IP-1,Level|1S,SANS-CSC|3,PCI-3.0|2.2.4,CCE|CCE-9361-7,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\Windows\Group Policy\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}"
reg_item : "NoGPOListChanges"
value_data : 0
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.2 Set 'User Account Control: Detect application installations and prompt for elevation'"
info :"Set 'User Account Control: Detect application installations and prompt for elevation' to 'Enabled' (Scored)
This policy setting controls the behavior of application installation detection for the
computer. The options are- . Enabled- (Default for home) When an application installation
package is detected that requires elevation of privilege, the user is prompted to enter an
administrative user name and password. If the user enters valid credentials, the operation
continues with the applicable privilege. . Disabled- (Default for enterprise) Application
installation packages are not detected and prompted for elevation. Enterprises that are
running standard user desktops and use delegated installation technologies such as Group
Policy Software Installation or Systems Management Server (SMS) should disable this
policy setting. In this case, installer detection is unnecessary.
*Rationale*
Some malicious software will attempt to install itself after being given permission to run.
For example, malicious software with a trusted application shell. The user may have given
permission for the program to run because the program is trusted, but if they are then
prompted for installation of an unknown component this provides another way of trapping
the software before it can do damage"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Detect application installations and prompt for
elevation
Impact-Users will need to provide administrative passwords to be able to install programs.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-3,800-53|AC-6,CCE|CCE-9616-4,Level|1S,PCI|7.1.1"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "EnableInstallerDetection"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.4 Set 'Devices: Allowed to format'"
info :"Set 'Devices: Allowed to format and eject removable media' to 'Administrators and Interactive Users' (Scored)
This policy setting determines who is allowed to format and eject removable media. You
can use this policy setting to prevent unauthorized users from removing data on one
computer to access it on another computer on which they have local administrator
privileges.
*Rationale*
Users may be able to move data on removable disks to a different computer where they
have administrative privileges. The user could then take ownership of any file, grant
themselves full control, and view or modify any file. The fact that most removable storage
devices will eject media by pressing a mechanical button diminishes the advantage of this
policy setting."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 2.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Devices- Allowed to format and eject removable media
Impact-Only Administrators will be able to format and eject removable media. If users are in the
habit of using removable media for file transfers and storage, they will need to be informed
of the change in policy.
Default Value-Not defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"SANS-CSC|16,800-53|AC-3,800-53|SC-5,CCE|CCE-8868-2,CSF|PR.IP-1,Level|1S,800-53|CM-7,CSF|PR.DS-4,CSF|PR.AC-4,CSF|DE.CM-1,CSF|PR.AC-1,CSF|PR.PT-3,800-53|CM-6"
reg_type : REG_SZ_DECIMAL
value_type : POLICY_DWORD
reg_key : "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
reg_item : "Allocatedasd"
value_data : 2
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.7 Set 'Microsoft network client: Digitally sign communications (if server agrees)'"
info :"Set 'Microsoft network client: Digitally sign communications (if server agrees)' to 'Enabled' (Scored)
This policy setting determines whether the SMB client will attempt to negotiate SMB packet
signing. The implementation of digital signing in Windows based networks helps to prevent
sessions from being hijacked. If you enable this policy setting, the Microsoft network client
will use signing only if the server with which it communicates accepts digitally signed
communication. Microsoft recommends to enable The Microsoft network client- Digitally
sign communications (if server agrees) setting. Note Enabling this policy setting on SMB
clients on your network makes them fully effective for packet signing with all clients and
servers in your environment.
*Rationale*
Session hijacking uses tools that allow attackers who have access to the same network as
the client or server to interrupt, end, or steal a session in progress. Attackers can
potentially intercept and modify unsigned SMB packets and then modify the traffic and
forward it so that the server might perform undesirable actions. Alternatively, the attacker
could pose as the server or client after legitimate authentication and gain unauthorized
access to data. SMB is the resource sharing protocol that is supported by many Windows
operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures
authenticate both users and the servers that host the data. If either side fails the
authentication process, data transmission will not take place."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft network client- Digitally sign communications (if server agrees)
Impact-The Windows 2000 Server, Windows 2000 Professional, Windows Server 2003, Windows
XP Professional and Windows Vista implementations of the SMB file and print sharing
protocol support mutual authentication, which prevents session hijacking attacks and
supports message authentication to prevent man-in-the-middle attacks. SMB signing
provides this authentication by placing a digital signature into each SMB, which is then
verified by both the client and the server. Implementation of SMB signing may negatively
affect performance, because each packet needs to be signed and verified. If these settings
are enabled on a server that is performing multiple roles, such as a small business server
that is serving as a domain controller, file server, print server, and application server
performance may be substantially slowed. Additionally, if you configure computers to
ignore all unsigned SMB communications, older applications and operating systems will
not be able to connect. However, if you completely disable all SMB signing, computers will
be vulnerable to session hijacking attacks. When SMB signing policies are enabled on
domain controllers running Windows Server 2003 and member computers running
Windows Vista SP1 or Windows Server 2008 group policy processing will fail. A hotfix is
available from Microsoft that resolves this issue; see Microsoft Knowledgebase Article
950876 for more details- http-//support.microsoft.com/default.aspx/kb/950876/.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-3,PCI|4.1,800-53|SC-8,CCE|CCE-9344-3,800-53|CM-7,Level|1S,PCI-3.0|2.2.4,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters"
reg_item : "EnableSecuritySignature"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.8 Set 'MSS: (ScreenSaverGracePeriod)"
info :"Set 'MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires (0 recommended)' to '0' (Scored)
The registry value entry ScreenSaverGracePeriod was added to the template file in the
HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\ Windows
NT\CurrentVersion\Winlogon\ registry key. The entry appears as MSS-
(ScreenSaverGracePeriod) The time in seconds before the screen saver grace period
expires (0 recommended) in the SCE. Windows includes a grace period between when the
screen saver is launched and when the console is actually locked automatically when
screen saver locking is enabled. This setting is configured to 0 seconds for both of the
environments that are discussed in this guide.
*Rationale*
The default grace period that is allowed for user movement before the screen saver lock
takes effect is five seconds. If you leave the default grace period configuration, your
computer is vulnerable to a potential attack from someone who could approach the console
and attempt to log on to the computer before the lock takes effect. An entry to the registry
can be made to adjust the length of the grace period."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\MSS- (ScreenSaverGracePeriod) The time in seconds before the screen saver
grace period expires (0 recommended)
Impact-Users will have to enter their passwords to resume their console sessions as soon as the
screen saver activates.
Default Value-5 seconds"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-3,800-53|CM-7,Level|1S,CCE|CCE-8591-0,PCI-3.0|2.2.4,800-53|AC-1,800-53|CM-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
reg_item : "ScreenSaverGracePeriod"
value_data : "0"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.10 Set 'Network access: Sharing and security model for local accounts'"
info :"Set 'Network access: Sharing and security model for local accounts' to 'Classic - local users authenticate as themselves' (Scored)
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.
*Rationale*
With the Guest only model, any user who can authenticate to your computer over the
network does so with guest privileges, which probably means that they will not have write
access to shared resources on that computer. Although this restriction does increase
security, it makes it more difficult for authorized users to access shared resources on those
computers because ACLs on those resources must include access control entries (ACEs) for
the Guest account. With the Classic model, local accounts should be password protected.
Otherwise, if Guest access is enabled, anyone can use those user accounts to access shared
system resources."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network access- Sharing and security model for local accounts
Impact-None. This is the default configuration.
Default Value-Classic - local users authenticate as themselves"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9503-4,800-53|CM-7,Level|1S,800-53|IA-2,PCI-3.0|2.2.4"
value_type : POLICY_DWORD
reg_key : "HKLM\System\CurrentControlSet\Control\Lsa"
reg_item : "ForceGuest"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.11 Set 'Minimum session security for NTLM SSP based (including secure RPC) clients'"
info :"Set 'Network security: Minimum session security for NTLM SSP based (including secure RPC) clients' to 'Require NTLMv2 session security,Require 128- bit encryption' (Scored)
This policy setting determines which behaviors are allowed 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
possible values for the Network security- Minimum session security for NTLM SSP based
(including secure RPC) clients setting are- . Require message confidentiality. This option is
only available in Windows XP and Windows Server 2003, the connection will fail if
encryption is not negotiated. Encryption converts data into a form that is not readable until
decrypted. . Require message integrity. This option is only available in Windows XP and
Windows Server 2003, the connection will fail if message integrity is not negotiated. The
integrity of a message can be assessed through message signing. Message signing proves
that the message has not been tampered with; it attaches a cryptographic signature that
identifies the sender and is a numeric representation of the contents of the message. .
Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not
negotiated. . Require NTLMv2 session security. The connection will fail if the NTLMv2
protocol is not negotiated. . Not Defined.
*Rationale*
You can enable all of the options for this policy setting to help protect network traffic that
uses the NTLM Security Support Provider (NTLM SSP) from being exposed or tampered
with by an attacker who has gained access to the same network. In other words, these
options help protect against man-in-the-middle attacks."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 537395200.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network security- Minimum session security for NTLM SSP based (including
secure RPC) clients
Impact-Client applications that are enforcing these settings will be unable to communicate with
older servers that do not support them. This setting could impact Windows Clustering
when applied to servers running Windows Server 2003, see 'How to apply more restrictive
security settings on a Windows Server 2003-based cluster server' at
http-//support.microsoft.com/default.aspx?scid=kb;en-us;891597 and 'You receive an
'Error 0x8007042b' error message when you add or join a node to a cluster if you use
NTLM version 2 in Windows Server 2003' at http-//support.microsoft.com/kb/890761/
for more information on possible issues and how to resolve them.
Default Value-Require 128-bit encryption"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-9534-9,800-53|AC-3,800-53|SC-5,CSF|PR.IP-1,Level|1S,800-53|CM-7,CSF|PR.DS-4,SANS-CSC|3,CSF|DE.CM-1,CSF|PR.AC-4,CSF|PR.PT-3,800-53|CM-6,PCI-3.0|8.2.1"
value_type : POLICY_DWORD
value_data : 537395200
reg_key : "HKLM\System\CurrentControlSet\Control\Lsa\MSV1_0"
reg_item : "NTLMMinClientSec"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.12 Set 'Accounts: Limit local account use'"
info :"Set 'Accounts: Limit local account use of blank passwords to console logon only' to 'Enabled' (Scored)
This policy setting determines whether local accounts that are not password protected can
be used to log on from locations other than the physical computer console. If you enable
this policy setting, local accounts that have blank passwords will not be able to log on to the
network from remote client computers. Such accounts will only be able to log on at the
keyboard of the computer.
*Rationale*
Blank passwords are a serious threat to computer security and should be forbidden
through both organizational policy and suitable technical measures. In fact, the default
settings for Active Directory® domains require complex passwords of at least seven
characters. However, if users with the ability to create new accounts bypass your domain-
based password policies, they could create accounts with blank passwords. For example, a
user could build a stand-alone computer, create one or more accounts with blank
passwords, and then join the computer to the domain. The local accounts with blank
passwords would still function. Anyone who knows the name of one of these unprotected
accounts could then use it to log on."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Accounts- Limit local account use of blank passwords to console logon only
Impact-None. This is the default configuration.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"SANS-CSC|16,800-53|AC-3,800-53|SC-5,CSF|PR.IP-1,Level|1S,800-53|CM-7,CSF|PR.DS-4,CCE|CCE-9418-5,CSF|PR.AC-4,CSF|DE.CM-1,CSF|PR.AC-1,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6"
reg_type : REG_DWORD
value_type : POLICY_DWORD
reg_key : "HKLM\System\CurrentControlSet\Control\Lsa"
reg_item : "LimitBlankPasswordUse"
value_data : 1
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.13 Set 'Domain member: Require strong'"
info :"Set 'Domain member: Require strong (Windows 2000 or later) session key' to 'Enabled' (Scored)
When this policy setting is enabled, a secure channel can only be established with domain
controllers that are capable of encrypting secure channel data with a strong (128-bit)
session key. To enable this policy setting, all domain controllers in the domain must be able
to encrypt secure channel data with a strong key, which means all domain controllers must
be running Microsoft Windows 2000 or later. If communication to non-Windows
2000based domains is required, it is recommended that you disable this policy setting.
*Rationale*
Session keys that are used to establish secure channel communications between domain
controllers and member computers are much stronger in Windows 2000 than they were in
previous Microsoft operating systems. Whenever possible, you should take advantage of
these stronger session keys to help protect secure channel communications from attacks
that attempt to hijack network sessions and eavesdropping. (Eavesdropping is a form of
hacking in which network data is read or altered in transit. The data can be modified to
hide or change the sender, or be redirected.)"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Domain member- Require strong (Windows 2000 or later) session key
Impact-Computers that have this policy setting enabled will not be able to join Windows NT 4.0
domains, and trusts between Active Directory domains and Windows NT-style domains
may not work properly. Also, computers that do not support this policy setting will not be
able to join domains in which the domain controllers have this policy setting enabled.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-2,CCE|CCE-9387-2,CSF|PR.IP-1,Level|1S,SANS-CSC|3,PCI-3.0|2.2.4,800-53|CM-6"
reg_type : REG_DWORD
value_type : POLICY_DWORD
reg_key : "HKLM\System\CurrentControlSet\Services\Netlogon\Parameters"
reg_item : "requirestrongkey"
value_data : 1
reg_option : CAN_NOT_BE_NULL
type : CHECK_ACCOUNT
description :"1.2.1.1.1.16 Set 'Accounts: Administrator account status'"
info :"Set 'Accounts: Administrator account status' to 'Disabled' (Scored)
This policy setting enables or disables the Administrator account during normal operation.
When a computer is booted into safe mode, the Administrator account is always enabled,
regardless of how this setting is configured. Note that this setting will have no impact when
applied to the domain controller organizational unit via group policy because domain
controllers have no local account database. It can be configured at the domain level via
group policy, similar to account lockout and password policy settings.
*Rationale*
In some organizations, it can be a daunting management challenge to maintain a regular
schedule for periodic password changes for local accounts. Therefore, you may want to
disable the built-in Administrator account instead of relying on regular password changes
to protect it from attack. Another reason to disable this built-in account is that it cannot be
locked out no matter how many failed logons it accrues, which makes it a prime target for
brute force attacks that attempt to guess passwords. Also, this account has a well-known
security identifier (SID) and there are third-party tools that allow authentication by using
the SID rather than the account name. This capability means that even if you rename the
Administrator account, an attacker could launch a brute force attack by using the SID to log
on."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Accounts- Administrator account status
Impact-
Maintenance issues can arise under certain circumstances if you disable the Administrator
account. For example, if the secure channel between a member computer and the domain
controller fails in a domain environment for any reason and there is no other local
Administrator account, you must restart in safe mode to fix the problem that broke the
secure channel. If the current Administrator password does not meet the password
requirements, you will not be able to re-enable the Administrator account after it is
disabled. If this situation occurs, another member of the Administrators group must set the
password on the Administrator account with the Local Users and Groups tool.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"SANS-CSC|12,800-53|AC-3,800-53|AC-6,800-53|SC-5,CSF|PR.IP-1,Level|1S,800-53|CM-7,CSF|PR.DS-4,CCE|CCE-9199-1,CSF|DE.CM-1,CSF|PR.AC-4,CSF|PR.PT-3,800-53|CM-6,PCI|2.1"
value_type : POLICY_SET
value_data : "Disabled"
account_type : ADMINISTRATOR_ACCOUNT
type : REGISTRY_SETTING
description :"1.2.1.1.1.17 IPv4 Set 'MSS: (DisableIPSourceRouting)"
info :"IPv4 Set 'MSS: (DisableIPSourceRouting) IP source routing protection level (protects against packet spoofing)' to 'Highest protection, source routing is completely disabled' (Scored)
The registry value entry DisableIPSourceRouting was added to the template file in the
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ registry
key. The entry appears as MSS- (DisableIPSourceRouting) IP source routing protection
level (protects against packet spoofing) in the SCE. IP source routing is a mechanism that
allows the sender to determine the IP route that a datagram should take through the
network. It is recommended to configure this setting to Not Defined for enterprise
environments and to Highest Protection for high security environments to completely
disable source routing.
*Rationale*
An attacker could use source routed packets to obscure their identity and location. Source
routing allows a computer that sends a packet to specify the route that the packet takes."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 2.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\MSS- (DisableIPSourceRouting) IP source routing protection level (protects
against packet spoofing)
Impact-If you configure this value to 2, all incoming source routed packets will be dropped.
Default Value-Not Defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|AC-3,800-53|SC-5,CSF|PR.IP-1,Level|1S,800-53|CM-7,CSF|PR.DS-4,SANS-CSC|3,CSF|DE.CM-1,CSF|PR.AC-4,PCI-3.0|2.2.4,CCE|CCE-9496-1,CSF|PR.PT-3,800-53|CM-6"
reg_type : REG_DWORD
value_type : POLICY_DWORD
value_data : 2
reg_key : "HKLM\System\CurrentControlSet\Services\Tcpip\Parameters"
reg_item : "DisableIPSourceRouting"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.20 Set 'Network access: Let Everyone permissions apply to anonymous users'"
info :"Set 'Network access: Let Everyone permissions apply to anonymous users' to 'Disabled' (Scored)
This policy setting determines what additional permissions are assigned for anonymous
connections to the computer. If you enable this policy setting, anonymous Windows users
are allowed to perform certain activities, such as enumerate the names of domain accounts
and network shares. An unauthorized user could anonymously list account names and
shared resources and use the information to guess passwords or perform social
engineering attacks.
*Rationale*
An unauthorized user could anonymously list account names and shared resources and use
the information to attempt to guess passwords, perform social engineering attacks, or
launch DoS attacks."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network access- Let Everyone permissions apply to anonymous users
Impact-None. This is the default configuration.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,CCE|CCE-8936-7,CSF|PR.AC-1,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.DS-4,800-53|AC-2,CSF|DE.CM-1,CSF|PR.AC-4,800-53|IA-2"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\SYSTEM\CurrentControlSet\Control\Lsa"
reg_item : "EveryoneIncludesAnonymous"
value_data : "Disabled"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.21 Set 'Microsoft network server: Disconnect clients when logon hours expire'"
info :"Set 'Microsoft network server: Disconnect clients when logon hours expire' to 'Enabled' (Scored)
This policy setting determines whether to disconnect users who are connected to the local
computer outside their user account's valid logon hours. It affects the SMB component. If
you enable this policy setting, client sessions with the SMB service will be forcibly
disconnected when the client's logon hours expire. If you disable this policy setting,
established client sessions will be maintained after the client's logon hours expire. If you
enable this policy setting you should also enable Network security- Force logoff when logon
hours expire. If your organization configures logon hours for users, it makes sense to
enable this policy setting.
*Rationale*
If your organization configures logon hours for users, then it makes sense to enable this
policy setting. Otherwise, users who should not have access to network resources outside
of their logon hours may actually be able to continue to use those resources with sessions
that were established during allowed hours."
solution :"
To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft network server- Disconnect clients when logon hours expire
Impact-If logon hours are not used in your organization, this policy setting will have no impact. If
logon hours are used, existing user sessions will be forcibly terminated when their logon
hours expire.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-1,800-53|SC-5,CCE|CCE-9358-3,CSF|PR.IP-1,800-53|CM-7,CSF|PR.AC-1,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1NS,CSF|PR.DS-4,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item : "enableforcedlogoff"
reg_option : CAN_BE_NULL
type : ANONYMOUS_SID_SETTING
description :"1.2.1.1.1.22 Set 'Network access: Allow anonymous SID/Name translation'"
info :"Set 'Network access: Allow anonymous SID/Name translation' to 'Disabled' (Scored)
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.
Disable this policy setting to prevent unauthenticated users from obtaining user names that
are associated with their respective SIDs.
*Rationale*
If this policy setting is enabled, a user with local access could use the well-known
Administrator's SID to learn the real name of the built-in Administrator account, even if it
has been renamed. That person could then use the account name to initiate a password
guessing attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to False.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network access- Allow anonymous SID/Name translation
Impact-Disabled is the default configuration for this policy setting on member computers;
therefore it will have no impact on them. The default configuration for domain controllers
is Enabled. If you disable this policy setting on domain controllers, legacy computers may
be unable to communicate with Windows Server 2003based domains. For example, the
following computers may not work- . Windows NT 4.0based Remote Access Service servers.
. Microsoft SQL Servers that run on Windows NT 3.xbased or Windows NT 4.0based
computers. . Remote Access Service or Microsoft SQL servers that run on Windows
2000based computers and are located in Windows NT 3.x domains or Windows NT 4.0
domains.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CCE|CCE-9531-5,CSF|PR.IP-1,800-53|CM-7,CSF|PR.AC-1,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : POLICY_SET
value_data : "disabled"
type : REGISTRY_SETTING
description :"1.2.1.1.1.23 Set 'User Account Control: Admin Approval'"
info :"Set 'User Account Control: Admin Approval Mode for the Built- in Administrator account' to 'Enabled' (Scored)
This policy setting controls the behavior of Admin Approval Mode for the built-in
Administrator account. The options are- . Enabled- The built-in Administrator account uses
Admin Approval Mode. By default, any operation that requires elevation of privilege will
prompt the user to approve the operation. . Disabled- (Default) The built-in Administrator
account runs all applications with full administrative privilege.
*Rationale*
One of the risks that the User Account Control feature introduced with Windows Vista is
trying to mitigate is that of malicious software running under elevated credentials without
the user or administrator being aware of its activity. An attack vector for these programs
was to discover the password of the account named 'Administrator' because that user
account was created for all installations of Windows. To address this risk, in Windows Vista
the built-in Administrator account is disabled. In a default installation of a new computer,
accounts with administrative control over the computer are initially set up in one of two
ways- . If the computer is not joined to a domain, the first user account you create has the
equivalent permissions as a local administrator. . If the computer is joined to a domain, no
local administrator accounts are created. The Enterprise or Domain Administrator must log
on to the computer and create one if a local administrator account is warranted. Once
Windows Vista is installed, the built-in Administrator account may be enabled, but we
strongly recommend that this account remain disabled."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Admin Approval Mode for the Built-in Administrator
account
Impact-Users that log on using the local Administrator account will be prompted for consent
whenever a program requests an elevation in privilege.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|7.1.1,Level|1S,800-53|AC-2,800-53|IA-2,CCE|CCE-8811-2"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "FilterAdministratorToken"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.24 Set 'Microsoft network server: Digitally sign communications (if client agrees)'"
info :"Set 'Microsoft network server: Digitally sign communications (if client agrees)' to 'Enabled' (Scored)
This policy setting determines if the server side SMB service is able to sign SMB packets if it
is requested to do so by a client that attempts to establish a connection. If no signing
request comes from the client, a connection will be allowed without a signature if the
Microsoft network server- Digitally sign communications (always) setting is not enabled.
Note Enable this policy setting on SMB clients on your network to make them fully effective
for packet signing with all clients and servers in your environment.
*Rationale*
Session hijacking uses tools that allow attackers who have access to the same network as
the client or server to interrupt, end, or steal a session in progress. Attackers can
potentially intercept and modify unsigned SMB packets and then modify the traffic and
forward it so that the server might perform undesirable actions. Alternatively, the attacker
could pose as the server or client after legitimate authentication and gain unauthorized
access to data. SMB is the resource sharing protocol that is supported by many Windows
operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures
authenticate both users and the servers that host the data. If either side fails the
authentication process, data transmission will not take place."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft network server- Digitally sign communications (if client agrees)
Impact-The Windows 2000 Server, Windows 2000 Professional, Windows Server 2003, Windows
XP Professional and Windows Vista implementations of the SMB file and print sharing
protocol support mutual authentication, which prevents session hijacking attacks and
supports message authentication to prevent man-in-the-middle attacks. SMB signing
provides this authentication by placing a digital signature into each SMB, which is then
verified by both the client and the server. Implementation of SMB signing may negatively
affect performance, because each packet needs to be signed and verified. If these settings
are enabled on a server that is performing multiple roles, such as a small business server
that is serving as a domain controller, file server, print server, and application server
performance may be substantially slowed. Additionally, if you configure computers to
ignore all unsigned SMB communications, older applications and operating systems will
not be able to connect. However, if you completely disable all SMB signing, computers will
be vulnerable to session hijacking attacks. When SMB signing policies are enabled on
domain controllers running Windows Server 2003 and member computers running
Windows Vista SP1 or Windows Server 2008 group policy processing will fail. A hotfix is
available from Microsoft that resolves this issue; see Microsoft Knowledgebase Article
950876 for more details- http-//support.microsoft.com/default.aspx/kb/950876/.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,PCI|4.1,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4,CCE|CCE-8825-2"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item : "enablesecuritysignature"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.25 Set 'MSS: (DisableIPSourceRouting IPv6)"
info :"Set 'MSS: (DisableIPSourceRouting IPv6) IP source routing protection level (protects against packet spoofing)' to 'Highest protection, source routing is completely disabled' (Scored)
This entry appears as MSS- (DisableIPSourceRouting) IPv6 source routing protection level
(protects against packet spoofing) in the SCE. IP source routing is a mechanism that allows
the sender to determine the IP route that a datagram should follow through the network.
*Rationale*
An attacker could use source routed packets to obscure their identity and location. Source
routing allows a computer that sends a packet to specify the route that the packet takes."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 2.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\MSS- (DisableIPSourceRouting IPv6) IP source routing protection level
(protects against packet spoofing)
Impact-If you configure this value to 2, all incoming source routed packets will be dropped.
Default Value-Not Defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CCE|CCE-8655-3,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
reg_type : REG_DWORD
value_type : POLICY_DWORD
value_data : 2
reg_key : "HKLM\System\CurrentControlSet\Services\Tcpip6\Parameters"
reg_item : "DisableIPSourceRouting"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.27 Set 'MSS: (AutoAdminLogon)"
info :"Set 'MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended)' to 'Disabled' (Scored)
The registry value entry AutoAdminLogon was added to the template file in the
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\
registry key. The entry appears as MSS- (AutoAdminLogon) Enable Automatic Logon (not
recommended) in the Security Configuration Editor. This setting is separate from the
Welcome screen feature in Windows XP and Windows Vista; if that feature is disabled, this
setting is not disabled. If you configure a computer for automatic logon, anyone who can
physically gain access to the computer can also gain access to everything that is on the
computer, including any network or networks to which the computer is connected. Also, if
you enable automatic logon, the password is stored in the registry in plaintext, and the
specific registry key that stores this value is remotely readable by the Authenticated Users
group. For additional information, see the Knowledge Base article 315231, How to turn on
automatic logon in Windows XP.
*Rationale*
If you configure a computer for automatic logon, anyone who can physically gain access to
the computer can also gain access to everything that is on the computer, including any
network or networks that the computer is connected to. Also, if you enable automatic
logon, the password is stored in the registry in plaintext. The specific registry key that
stores this setting is remotely readable by the Authenticated Users group. As a result, this
entry is appropriate only if the computer is physically secured and if you ensure that
untrusted users cannot remotely see the registry."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\MSS- (AutoAdminLogon) Enable Automatic Logon (not recommended)
Impact-None. By default this entry is not enabled.
Default Value-Not Defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,CCE|CCE-9342-7,PCI-3.0|2.2.4,CSF|PR.AC-1,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|PR.AC-4,CSF|DE.CM-1,800-53|IA-2"
value_type : POLICY_DWORD
value_data : 0
reg_key : "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
reg_item : "AutoAdminLogon"
reg_option : CAN_NOT_BE_NULL
type : CHECK_ACCOUNT
description :"1.2.1.1.1.28 Set 'Accounts: Guest account status'"
info :"Set 'Accounts: Guest account status' to 'Disabled' (Scored)
This policy setting determines whether the Guest account is enabled or disabled. The Guest
account allows unauthenticated network users to gain access to the system. Note that this
setting will have no impact when applied to the domain controller organizational unit via
group policy because domain controllers have no local account database. It can be
configured at the domain level via group policy, similar to account lockout and password
policy settings.
*Rationale*
The default Guest account allows unauthenticated network users to log on as Guest with no
password. These unauthorized users could access any resources that are accessible to the
Guest account over the network. This capability means that any network shares with
permissions that allow access to the Guest account, the Guests group, or the Everyone
group will be accessible over the network, which could lead to the exposure or corruption
of data."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Accounts- Guest account status
Impact-All network users will need to authenticate before they can access shared resources. If you
disable the Guest account and the Network Access- Sharing and Security Model option is set
to Guest Only, network logons, such as those performed by the Microsoft Network Server
(SMB Service), will fail. This policy setting should have little impact on most organizations
because it is the default setting in Microsoft Windows® 2000, Windows XP, and Windows
Server 2003.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|DE.CM-3,800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,CSF|PR.AC-1,800-53|CM-6,CSF|PR.PT-3,SANS-CSC|16,800-53|AC-3,Level|1S,800-53|AC-2,CSF|DE.CM-1,CSF|DE.AE-1,800-53|IA-4,CCE|CCE-8714-8,PCI|2.1"
value_type : POLICY_SET
account_type : GUEST_ACCOUNT
value_data : "Disabled"
type : REGISTRY_SETTING
description :"1.2.1.1.1.29 Set 'Microsoft network server: Digitally sign communications (always)'"
info :"Set 'Microsoft network server: Digitally sign communications (always)' to 'Enabled' (Scored)
This policy setting determines if the server side SMB service is required to perform SMB
packet signing. Enable this policy setting in a mixed environment to prevent downstream
clients from using the workstation as a network server.
*Rationale*
Session hijacking uses tools that allow attackers who have access to the same network as
the client or server to interrupt, end, or steal a session in progress. Attackers can
potentially intercept and modify unsigned SMB packets and then modify the traffic and
forward it so that the server might perform undesirable actions. Alternatively, the attacker
could pose as the server or client after legitimate authentication and gain unauthorized
access to data. SMB is the resource sharing protocol that is supported by many Windows
operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures
authenticate both users and the servers that host the data. If either side fails the
authentication process, data transmission will not take place."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft network server- Digitally sign communications (always)
Impact-The Windows 2000 Server, Windows 2000 Professional, Windows Server 2003, Windows
XP Professional and Windows Vista implementations of the SMB file and print sharing
protocol support mutual authentication, which prevents session hijacking attacks and
supports message authentication to prevent man-in-the-middle attacks. SMB signing
provides this authentication by placing a digital signature into each SMB, which is then
verified by both the client and the server. Implementation of SMB signing may negatively
affect performance, because each packet needs to be signed and verified. If these settings
are enabled on a server that is performing multiple roles, such as a small business server
that is serving as a domain controller, file server, print server, and application server
performance may be substantially slowed. Additionally, if you configure computers to
ignore all unsigned SMB communications, older applications and operating systems will
not be able to connect. However, if you completely disable all SMB signing, computers will
be vulnerable to session hijacking attacks. When SMB signing policies are enabled on
domain controllers running Windows Server 2003 and member computers running
Windows Vista SP1 or Windows Server 2008 group policy processing will fail. A hotfix is
available from Microsoft that resolves this issue; see Microsoft Knowledgebase Article
950876 for more details- http-//support.microsoft.com/default.aspx/kb/950876/.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,800-53|SC-8,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,PCI|4.1,800-53|SC-9,Level|1S,CSF|PR.DS-4,CCE|CCE-9040-7,CSF|DE.CM-1,CSF|PR.AC-4"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item : "RequireSecuritySignature"
value_data : "Enabled"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.30 Set 'Microsoft network client: Digitally sign communications (always)'"
info :"Set 'Microsoft network client: Digitally sign communications (always)' to 'Enabled' (Scored)
This policy setting determines whether packet signing is required by the SMB client
component. If you enable this policy setting, the Microsoft network client computer cannot
communicate with a Microsoft network server unless that server agrees to sign SMB
packets. In mixed environments with legacy client computers, set this option to Disabled
because these computers will not be able to authenticate or gain access to domain
controllers. However, you can use this policy setting in Windows 2000 or later
environments. Note When Windows Vista based computers have this policy setting enabled
and they connect to file or print shares on remote servers, it is important that the setting is
synchronized with its companion setting, Microsoft network server- Digitally sign
communications (always), on those servers. For more information about these settings, see
the Microsoft network client and server- Digitally sign communications (four related
settings) section in Chapter 5 of the Threats and Countermeasures guide.
*Rationale*
Session hijacking uses tools that allow attackers who have access to the same network as
the client or server to interrupt, end, or steal a session in progress. Attackers can
potentially intercept and modify unsigned SMB packets and then modify the traffic and
forward it so that the server might perform undesirable actions. Alternatively, the attacker
could pose as the server or client after legitimate authentication and gain unauthorized
access to data. SMB is the resource sharing protocol that is supported by many Windows
operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures
authenticate both users and the servers that host the data. If either side fails the
authentication process, data transmission will not take place."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft network client- Digitally sign communications (always)
Impact-The Windows 2000 Server, Windows 2000 Professional, Windows Server 2003, Windows
XP Professional and Windows Vista implementations of the SMB file and print sharing
protocol support mutual authentication, which prevents session hijacking attacks and
supports message authentication to prevent man-in-the-middle attacks. SMB signing
provides this authentication by placing a digital signature into each SMB, which is then
verified by both the client and the server. Implementation of SMB signing may negatively
affect performance, because each packet needs to be signed and verified. If these settings
are enabled on a server that is performing multiple roles, such as a small business server
that is serving as a domain controller, file server, print server, and application server
performance may be substantially slowed. Additionally, if you configure computers to
ignore all unsigned SMB communications, older applications and operating systems will
not be able to connect. However, if you completely disable all SMB signing, computers will
be vulnerable to session hijacking attacks. When SMB signing policies are enabled on
domain controllers running Windows Server 2003 and member computers running
Windows Vista SP1 or Windows Server 2008 group policy processing will fail. A hotfix is
available from Microsoft that resolves this issue; see Microsoft Knowledgebase Article
950876 for more details- http-//support.microsoft.com/default.aspx/kb/950876/.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-5,800-53|SC-8,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,PCI|4.1,CCE|CCE-9327-8,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters"
reg_item : "RequireSecuritySignature"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.32 Set 'Network access: Restrict anonymous access to Named Pipes and Shares'"
info :"Set 'Network access: Restrict anonymous access to Named Pipes and Shares' to 'Enabled' (Scored)
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 HKLM\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. Null sessions are a weakness that can
be exploited through shares (including the default shares) on computers in your
environment.
*Rationale*
Null sessions are a weakness that can be exploited through shares (including the default
shares) on computers in your environment."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network access- Restrict anonymous access to Named Pipes and Shares
Impact-You can enable this policy setting to restrict null session access for unauthenticated users
to all server pipes and shared folders except those that are listed in the NullSessionPipes
and NullSessionShares entries. 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- . COMNAPSNA session access .
COMNODESNA session access . SQL\QUERYSQL instance access . SPOOLSSSpooler service .
LLSRPCLicense Logging service . NetlogonNet Logon service . LsarpcLSA access .
SamrRemote access to SAM objects . browserComputer 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.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|CM-7,PCI-3.0|2.2.4,Level|1S,CCE|CCE-9540-6"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item : "restrictnullsessaccess"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.36 Set 'Domain member: Maximum machine account password age'"
info :"Set 'Domain member: Maximum machine account password age' to '30' (Scored)
This policy setting determines the maximum allowable age for a computer account
password. By default, domain members automatically change their domain passwords
every 30 days. If you increase this interval significantly or set it to 0 so that the computers
no longer change their passwords, an attacker would have more time to undertake a brute
force attack against one of the computer accounts.
*Rationale*
In Active Directory based domains, each computer has an account and password just like
every user. By default, the domain members automatically change their domain password
every 30 days. If you increase this interval significantly, or set it to 0 so that the computers
no longer change their passwords, an attacker will have more time to undertake a brute
force attack to guess the password of one or more computer accounts."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 30.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Domain member- Maximum machine account password age
Impact-None. This is the default configuration.
Default Value-30 days"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|IA-5,CCE|CCE-9123-1,800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,CSF|PR.AC-1,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,PCI|8.5,Level|1S,CSF|PR.DS-4,CSF|PR.AC-4,CSF|DE.CM-1,PCI-3.0|8.5"
reg_type : REG_DWORD
value_type : POLICY_DWORD
reg_key : "HKLM\System\CurrentControlSet\Services\Netlogon\Parameters"
reg_item : "MaximumPasswordAge"
value_data : [1..30]
type : REGISTRY_SETTING
description :"1.2.1.1.1.37 Set 'User Account Control: Only elevate executables that are signed and validated'"
info :"Set 'User Account Control: Only elevate executables that are signed and validated' to 'Disabled' (Scored)
This policy setting enforces public key infrastructure (PKI) signature checks for any
interactive applications that request elevation of privilege. Enterprise administrators can
control which applications are allowed to run by adding certificates to the Trusted
Publishers certificate store on local computers. The options are- . Enabled- Enforces the PKI
certification path validation for a given executable file before it is permitted to run. .
Disabled- (Default) Does not enforce PKI certification path validation before a given
executable file is permitted to run.
*Rationale*
Intellectual property, personally identifiable information, and other confidential data are
normally manipulated by applications on the computer and require elevated credentials to
get access to the information. Users and administrators inherently trust applications used
with these information sources and provide their credentials. If one of these applications is
replaced by a rogue application that appears identical to the trusted application the
confidential data could be compromised and the user's administrative credentials would
also be compromised."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Only elevate executables that are signed and validated
Impact-Enabling this setting requires that you have a PKI infrastructure and that your Enterprise
administrators have populated the Trusted Root Store with the certificates for the allowed
applications. Some older applications are not signed and will not be able to be used in an
environment that is hardened with this setting. You should carefully test your applications
in a pre-production environment before implementing this setting. For information about
the steps required to test application compatibility, make application compatibility fixes,
and sign installer packages to prepare your organization for deployment of Windows Vista
User Account Control, see Understanding and Configuring User Account Control in
Windows Vista (http-//go.microsoft.com/fwlink/?LinkID=79026). Control over the
applications that are installed on the desktops and the hardware that is able to join your
domain should provide similar protection from the vulnerability addressed by this setting.
Additionally, the level of protection provided by this setting is not an assurance that all
rogue applications will be found
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-6,CCE|CCE-9021-7,800-53|AC-3,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "ValidateAdminCodeSignatures"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.39 Set 'Devices: Prevent users from installing printer drivers'"
info :"Set 'Devices: Prevent users from installing printer drivers' to 'Enabled' (Scored)
It is feasible for an attacker to disguise a Trojan horse program as a printer driver. The
program may appear to users as if they must use it to print, but such a program could
unleash malicious code on your computer network. To reduce the possibility of such an
event, only administrators should be allowed to install printer drivers. However, because
laptops are mobile devices, laptop users may occasionally need to install a printer driver
from a remote source to continue their work. Therefore, this policy setting should be
disabled for laptop users, but always enabled for desktop users.
*Rationale*
It may be appropriate in some organizations to allow users to install printer drivers on
their own workstations. However, you should allow only Administrators, not users, to do so
on servers, because printer driver installation on a server may unintentionally cause the
computer to become less stable. A malicious user could install inappropriate printer
drivers in a deliberate attempt to damage the computer, or a user might accidentally install
malicious software that masquerades as a printer driver."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Devices- Prevent users from installing printer drivers
Impact-Only users with Administrative, Power User, or Server Operator privileges will be able to
install printers on the servers. If this policy setting is enabled but the driver for a network
printer already exists on the local computer, users can still add the network printer.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,CSF|PR.AC-1,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.DS-4,CCE|CCE-9026-6,CSF|PR.AC-4,CSF|DE.CM-1"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\SYSTEM\CurrentControlSet\Control\Print\Providers\LanMan Print Services\Servers"
reg_item : "AddPrinterDrivers"
value_data : "Enabled"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.40 Set 'Strengthen default permissions of internal system objects (e.g. Symbolic Links)'"
info :"Set 'System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)' to 'Enabled' (Scored)
This policy setting determines the strength of the default discretionary access control list
(DACL) for objects. The setting helps secure objects that can be located and shared among
processes and its default configuration strengthens the DACL, because it allows users who
are not administrators to read shared objects but does not allow them to modify any that
they did not create.
*Rationale*
This setting determines the strength of the default DACL for objects. Windows Server 2003
maintains a global list of shared computer resources so that objects can be located and
shared among processes. Each type of object is created with a default DACL that specifies
who can access the objects and with what permissions. If you enable this setting, the
default DACL is strengthened because non-administrator users are allowed to read shared
objects but not modify shared objects that they did not create."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\System objects- Strengthen default permissions of internal system objects
(e.g. Symbolic Links)
Impact-None. This is the default configuration.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.AC-1,PCI-3.0|2.2.4,800-53|CM-6,SANS-CSC|16,Level|1S,CCE|CCE-9191-8,CSF|DE.CM-1"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager"
reg_item : "ProtectionMode"
value_data : "Enabled"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.42 Set 'Network access: Do not allow anonymous enumeration of SAM accounts'"
info :"Set 'Network access: Do not allow anonymous enumeration of SAM accounts' to 'Enabled' (Scored)
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 cannot enumerate domain account user names on the
workstations in your environment. This policy setting also allows additional restrictions on
anonymous connections.
*Rationale*
An unauthorized user could anonymously list account names and use the information to
perform social engineering attacks or attempt to guess passwords. (Social engineering
attacks try to deceive users in some way to obtain passwords or some form of security
information.)"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network access- Do not allow anonymous enumeration of SAM accounts
Impact-It will be impossible to establish trusts with Windows NT 4.0based 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.
Default Value:Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,CSF|PR.AC-1,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.DS-4,CCE|CCE-9249-41,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Control\Lsa"
reg_item : "RestrictAnonymousSAM"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.44 Set 'Audit: Force audit policy'"
info :"Set 'Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings' to 'Enabled' (Scored)
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."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\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-The individual audit policy subcategories that are available in Windows Vista are not
exposed in the interface of Group Policy tools. Administrators can deploy a custom audit
policy that applies detailed security auditing settings to Windows Vista-based client
computers in a Windows Server 2003 domain or in a Windows 2000 domain. If after
enabling this setting, you attempt to modify an auditing setting by using Group Policy, the
Group Policy auditing setting will be ignored in favor of the custom policy setting. To
modify auditing settings by using Group Policy, you must first disable this key. 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.
Default Value-Not defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,PCI|10.2,Level|1S,CCE|CCE-9432-6"
value_type : POLICY_DWORD
reg_key : "HKLM\System\CurrentControlSet\Control\Lsa"
reg_item : "scenoapplylegacyauditpolicy"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.47 Set 'Network security: Do not store LAN Manager hash value on next password change'"
info :"Set 'Network security: Do not store LAN Manager hash value on next password change' to 'Enabled' (Scored)
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.
Note Older operating systems and some third-party applications may fail when this policy
setting is enabled. Also you will need to change the password on all accounts after you
enable this setting.
*Rationale*
The SAM file can be targeted by attackers who seek access to username and password
hashes. Such attacks use special tools to crack passwords, which can then be used to
impersonate users and gain access to resources on your network. These types of attacks
will not be prevented if you enable this policy setting, but it will be much more difficult for
these types of attacks to succeed."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network security- Do not store LAN Manager hash value on next password change
Impact-Earlier operating systems such as Windows 95, Windows 98, and Windows ME as well as
some third-party applications will fail.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,CSF|PR.PT-3,800-53|CM-6,PCI-3.0|8.2.1,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4,CCE|CCE-8937-5"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Control\Lsa"
reg_item : "NoLMHash"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.48 Set 'User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop'"
info :"Set 'User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop' to 'Disabled' (Scored)
This policy setting controls whether User Interface Accessibility (UIAccess or UIA)
programs can automatically disable the secure desktop for elevation prompts used by a
standard user. . Enabled- UIA programs, including Windows Remote Assistance,
automatically disable the secure desktop for elevation prompts. If you do not disable the
User Account Control- Switch to the secure desktop when prompting for elevation policy
setting, the prompts appear on the interactive user's desktop instead of the secure desktop.
. Disabled- (Default) The secure desktop can be disabled only by the user of the interactive
desktop or by disabling the User Account Control- Switch to the secure desktop when
prompting for elevation policy setting.
*Rationale*
One of the risks that the UAC feature introduced with Windows Vista is trying to mitigate is
that of malicious software running under elevated credentials without the user or
administrator being aware of its activity. This setting allows the administrator to perform
operations that require elevated privileges while connected via Remote Assistance. This
increases security in that organizations can use UAC even when end user support is
provided remotely. However, it also reduces security by adding the risk that an
administrator might allow an unprivileged user to share elevated privileges for an
application that the administrator needs to use during the Remote Desktop session."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Allow UIAccess applications to prompt for elevation
without using the secure desktop
Impact-If you enable this setting, ('User Account Control- Allow UIAccess applications to prompt
for elevation without using the secure desktop), requests for elevation are automatically
sent to the interactive desktop (not the secure desktop) and also appear on the remote
administrator's view of the desktop during a Windows Remote Assistance session, and the
remote administrator is able to provide the appropriate credentials for elevation. This
setting does not change the behavior of the UAC elevation prompt for administrators.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-6,PCI|7.1.1,PCI|7.1.3,CCE|CCE-9301-3,PCI|7.1.2,PCI|7.2.1,PCI|7.2.2,800-53|AC-3,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "EnableUIADesktopToggle"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.49 Set 'Domain member: Digitally sign secure channel data (when possible)'"
info :"Set 'Domain member: Digitally sign secure channel data (when possible)' to 'Enabled' (Scored)
This policy setting determines whether a domain member should attempt to negotiate
whether all secure channel traffic that it initiates must be digitally signed. Digital signatures
protect the traffic from being modified by anyone who captures the data as it traverses the
network. Microsoft recommends to configure the Domain member- Digitally sign secure
channel data (when possible) setting to Enabled.
*Rationale*
When a computer joins a domain, a computer account is created. After it joins the domain,
the computer uses the password for that account to create a secure channel with the
domain controller for its domain every time that it restarts. Requests that are sent on the
secure channel are authenticated - and sensitive information such as passwords are
encrypted - but the channel is not integrity-checked, and not all information is encrypted. If
a computer is configured to always encrypt or sign secure channel data but the domain
controller cannot sign or encrypt any portion of the secure channel data, the computer and
domain controller cannot establish a secure channel. If the computer is configured to
encrypt or sign secure channel data when possible, a secure channel can be established, but
the level of encryption and signing is negotiated."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Domain member- Digitally sign secure channel data (when possible)
Impact-Digital encryption and signing of the secure channel is a good idea where it is supported.
The secure channel protects domain credentials as they are sent to the domain controller.
However, only Windows NT 4.0 with Service Pack 6a (SP6a) and subsequent versions of
the Windows operating system support digital encryption and signing of the secure
channel. Windows 98 Second Edition clients do not support it unless they have the Dsclient
installed. Therefore, you cannot enable the Domain member- Digitally encrypt or sign
secure channel data (always) setting on domain controllers that support Windows 98
clients as members of the domain. Potential impacts can include the following- . The ability
to create or delete trust relationships with clients running versions of Windows earlier
than Windows NT 4.0 with SP6a will be disabled. . Logons from clients running versions of
Windows earlier than Windows NT 4.0 with SP6a will be disabled. . The ability to
authenticate other domains' users from a domain controller running a version of Windows
earlier than Windows NT 4.0 with SP6a in a trusted domain will be disabled. You can
enable this policy setting after you eliminate all Windows 9x clients from the domain and
upgrade all Windows NT 4.0 servers and domain controllers from trusted/trusting
domains to Windows NT 4.0 with SP6a. You can enable the other two policy settings,
Domain member- Digitally encrypt secure channel data (when possible) and Domain
member- Digitally encrypt sign channel data (when possible), on all computers in the
domain that support them and clients running versions of Windows earlier than Windows
NT 4.0 with SP6a and applications that run on these versions of Windows will not be
affected.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-2,800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,CCE|CCE-9375-7,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Services\Netlogon\Parameters"
reg_item : "signsecurechannel"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.50 Set 'User Account Control: Switch to the secure desktop when prompting for elevation'"
info :"Set 'User Account Control: Switch to the secure desktop when prompting for elevation' to 'Enabled' (Scored)
This policy setting controls whether the elevation request prompt is displayed on the
interactive user's desktop or the secure desktop. The options are- . Enabled- (Default) All
elevation requests go to the secure desktop regardless of prompt behavior policy settings
for administrators and standard users. . Disabled- All elevation requests go to the
interactive user's desktop. Prompt behavior policy settings for administrators and
standard users are used.
*Rationale*
Elevation prompt dialog boxes can be spoofed, causing users to disclose their passwords to
malicious software."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Switch to the secure desktop when prompting for
elevation
Impact-None. This is the default configuration.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-6,CCE|CCE-9395-5,PCI|7.1.1,800-53|AC-3,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "PromptOnSecureDesktop"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.51 Set 'Domain member: Disable machine account password changes'"
info :"Set 'Domain member: Disable machine account password changes' to 'Disabled' (Scored)
This policy setting determines whether a domain member can periodically change its
computer account password. If you enable this policy setting, the domain member will be
prevented from changing its computer account password. If you disable this policy setting,
the domain member can change its computer account password as specified by the Domain
Member- Maximum machine account password age setting, which by default is every 30
days. Computers that cannot automatically change their account passwords are potentially
vulnerable, because an attacker might be able to determine the password for the system's
domain account.
*Rationale*
The default configuration for Windows Server 2003based computers that belong to a
domain is that they are automatically required to change the passwords for their accounts
every 30 days. If you disable this policy setting, computers that run Windows Server 2003
will retain the same passwords as their computer accounts. Computers that are no longer
able to automatically change their account password are at risk from an attacker who could
determine the password for the computer's domain account."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Domain member- Disable machine account password changes
Impact-None. This is the default configuration.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|IA-5,CCE|CCE-9295-7,PCI-3.0|2.2.4,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\System\CurrentControlSet\Services\Netlogon\Parameters"
reg_item : "disablepasswordchange"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.52 Set 'User Account Control: Behavior of the elevation prompt for standard users'"
info :"Set 'User Account Control: Behavior of the elevation prompt for standard users' to 'Automatically deny elevation requests' (Scored)
This policy setting controls the behavior of the elevation prompt for standard users. The
options are- . Prompt for credentials- When an operation requires elevation of privilege, the
user is prompted to enter an administrative user name and password. If the user enters
valid credentials, the operation continues with the applicable privilege. . Automatically
deny elevation requests- When an operation requires elevation of privilege, a configurable
access denied error message is displayed. An enterprise that is running desktops as
standard user may choose this setting to reduce help desk calls. . Prompt for credentials on
the secure desktop- (Default) When an operation requires elevation of privilege, the user is
prompted on the secure desktop to enter a different user name and password. If the user
enters valid credentials, the operation continues with the applicable privilege. Note that
this option was introduced in Windows 7 and it is not applicable to computers running
Windows Vista or Windows Server 2008.
*Rationale*
One of the risks that the User Account Control feature introduced with Windows Vista is
trying to mitigate is that of malicious programs running under elevated credentials without
the user or administrator being aware of their activity. This setting raises awareness to the
user that a program requires the use of elevated privilege operations and requires that the
user be able to supply administrative credentials in order for the program to run."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Behavior of the elevation prompt for standard users
Impact-Users will need to provide administrative passwords to be able to run programs with
elevated privileges. This could cause an increased load on IT staff while the programs that
are impacted are identified and standard operating procedures are modified to support
least privilege operations.
Default Value-Prompt for credentials"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-8813-8,PCI|7.1.1,Level|1S,800-53|AC-2,800-53|IA-2"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "ConsentPromptBehaviorUser"
value_data : "3"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.54 Set 'Recovery console: Allow automatic administrative logon'"
info :"Set 'Recovery console: Allow automatic administrative logon' to 'Disabled' (Scored)
The recovery console is a command-line environment that is used to recover from system
problems. If you enable this policy setting, the administrator account is automatically
logged on to the recovery console when it is invoked during startup.
*Rationale*
The Recovery Console can be very useful when you need to troubleshoot and repair
computers that do not start. However, it is dangerous to allow automatic logon to the
console. Anyone could walk up to the server, disconnect the power to shut it down, restart
it, select Recover Console from the Restart menu, and then assume full control of the
server."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Recovery console- Allow automatic administrative logon
Impact-Users will have to enter a user name and password to access the Recovery Console.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-8807-0,800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,CSF|PR.DS-4,SANS-CSC|15,CSF|DE.CM-1,CSF|PR.AC-4,800-53|IA-2,800-53|AC-1"
value_type : POLICY_DWORD
value_data : 0
reg_key : "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Setup\RecoveryConsole"
reg_item : "securitylevel"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.55 Set 'Domain member: Digitally encrypt or sign secure channel data (always)'"
info :"Set 'Domain member: Digitally encrypt or sign secure channel data (always)' to 'Enabled' (Scored)
This policy setting determines whether all secure channel traffic that is initiated by the
domain member must be signed or encrypted. If a system is set to always encrypt or sign
secure channel data, it cannot establish a secure channel with a domain controller that is
not capable of signing or encrypting all secure channel traffic, because all secure channel
data must be signed and encrypted. Microsoft recommends to configure the Domain
member- Digitally encrypt or sign secure channel data (always) setting to Enabled.
*Rationale*
When a computer joins a domain, a computer account is created. After it joins the domain,
the computer uses the password for that account to create a secure channel with the
domain controller for its domain every time that it restarts. Requests that are sent on the
secure channel are authenticated - and sensitive information such as passwords are
encrypted - but the channel is not integrity-checked, and not all information is encrypted. If
a computer is configured to always encrypt or sign secure channel data but the domain
controller cannot sign or encrypt any portion of the secure channel data, the computer and
domain controller cannot establish a secure channel. If the computer is configured to
encrypt or sign secure channel data when possible, a secure channel can be established, but
the level of encryption and signing is negotiated."
solution :"
To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Domain member- Digitally encrypt or sign secure channel data (always)
Impact-Digital encryption and signing of the secure channel is a good idea where it is supported.
The secure channel protects domain credentials as they are sent to the domain controller.
However, only Windows NT 4.0 with Service Pack 6a (SP6a) and subsequent versions of
the Windows operating system support digital encryption and signing of the secure
channel. Windows 98 Second Edition clients do not support it unless they have the Dsclient
installed. Therefore, you cannot enable the Domain member- Digitally encrypt or sign
secure channel data (always) setting on domain controllers that support Windows 98
clients as members of the domain. Potential impacts can include the following- . The ability
to create or delete trust relationships with clients running versions of Windows earlier
than Windows NT 4.0 with SP6a will be disabled. . Logons from clients running versions of
Windows earlier than Windows NT 4.0 with SP6a will be disabled. . The ability to
authenticate other domains' users from a domain controller running a version of Windows
earlier than Windows NT 4.0 with SP6a in a trusted domain will be disabled. You can
enable this policy setting after you eliminate all Windows 9x clients from the domain and
upgrade all Windows NT 4.0 servers and domain controllers from trusted/trusting
domains to Windows NT 4.0 with SP6a. You can enable the other two policy settings,
Domain member- Digitally encrypt secure channel data (when possible) and Domain
member- Digitally encrypt sign channel data (when possible), on all computers in the
domain that support them and clients running versions of Windows earlier than Windows
NT 4.0 with SP6a and applications that run on these versions of Windows will not be
affected. Digital encryption and signing of the secure channel is a good idea where it is
supported. The secure channel protects domain credentials as they are sent to the domain
controller. However, only Windows NT 4.0 with Service Pack 6a (SP6a) and subsequent
versions of the Windows operating system support digital encryption and signing of the
secure channel. Windows 98 Second Edition clients do not support it unless they have the
Dsclient installed. Therefore, you cannot enable the Domain member- Digitally encrypt or
sign secure channel data (always) setting on domain controllers that support Windows 98
clients as members of the domain. Potential impacts can include the following- . The ability
to create or delete trust relationships with clients running versions of Windows earlier
than Windows NT 4.0 with SP6a will be disabled. . Logons from clients running versions of
Windows earlier than Windows NT 4.0 with SP6a will be disabled. . The ability to
authenticate other domains' users from a domain controller running a version of Windows
earlier than Windows NT 4.0 with SP6a in a trusted domain will be disabled. You can
enable this policy setting after you eliminate all Windows 9x clients from the domain and
upgrade all Windows NT 4.0 servers and domain controllers from trusted/trusting
domains to Windows NT 4.0 with SP6a. You can enable the other two policy settings,
Domain member- Digitally encrypt secure channel data (when possible) and Domain
member- Digitally encrypt sign channel data (when possible), on all computers in the
domain that support them and clients running versions of Windows earlier than Windows
NT 4.0 with SP6a and applications that run on these versions of Windows will not be
affected.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-2,CSF|PR.IP-1,CSF|PR.DS-1,CCE|CCE-8974-8,SANS-CSC|3,CSF|PR.DS-2,800-53|CM-6,PCI-3.0|8.2.1,CSF|PR.DS-5,800-53|SC-9,Level|1S,SANS-CSC|17,CSF|PR.AC-3"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Services\Netlogon\Parameters"
reg_item : "requiresignorseal"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.56 Set 'Domain member: Digitally encrypt secure channel data (when possible)'"
info :"Set 'Domain member: Digitally encrypt secure channel data (when possible)' to 'Enabled' (Scored)
This policy setting determines whether a domain member should attempt to negotiate
encryption for all secure channel traffic that it initiates. If you enable this policy setting, the
domain member will request encryption of all secure channel traffic. If you disable this
policy setting, the domain member will be prevented from negotiating secure channel
encryption. Microsoft recommends to configure the Domain member- Digitally encrypt
secure channel data (when possible) setting to Enabled.
*Rationale*
When a Windows Server 2003, Windows XP, Windows 2000, or Windows NT computer
joins a domain, a computer account is created. After it joins the domain, the computer uses
the password for that account to create a secure channel with the domain controller for its
domain every time that it restarts. Requests that are sent on the secure channel are
authenticated - and sensitive information such as passwords are encrypted - but the
channel is not integrity-checked, and not all information is encrypted. If a computer is
configured to always encrypt or sign secure channel data but the domain controller cannot
sign or encrypt any portion of the secure channel data, the computer and domain controller
cannot establish a secure channel. If the computer is configured to encrypt or sign secure
channel data when possible, a secure channel can be established, but the level of
encryption and signing is negotiated."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Domain member- Digitally encrypt secure channel data (when possible)
Impact-Digital encryption and signing of the secure channel is a good idea where it is supported.
The secure channel protects domain credentials as they are sent to the domain controller.
However, only Windows NT 4.0 Service Pack 6a (SP6a) and subsequent versions of the
Windows operating system support digital encryption and signing of the secure channel.
Windows 98 Second Edition clients do not support it unless they have the Dsclient
installed. Therefore, you cannot enable the Domain member- Digitally encrypt or sign
secure channel data (always) setting on domain controllers that support Windows 98
clients as members of the domain. Potential impacts can include the following-
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-2,CSF|PR.IP-1,CSF|PR.DS-1,SANS-CSC|3,CSF|PR.DS-2,800-53|CM-6,PCI-3.0|8.2.1,CSF|PR.DS-5,CCE|CCE-9251-0,800-53|SC-9,Level|1S,SANS-CSC|17,CSF|PR.AC-3"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\System\CurrentControlSet\Services\Netlogon\Parameters"
reg_item : "SealSecureChannel"
value_data : "enabled"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.59 Set 'MSS: (SafeDllSearchMode)"
info :"Set 'MSS: (SafeDllSearchMode) Enable Safe DLL search mode (recommended)' to 'Enabled' (Scored)
The registry value entry SafeDllSearchMode was added to the template file in the
HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\Session Manager\ registry
key. The entry appears as MSS- (SafeDllSearchMode) Enable Safe DLL search mode
(recommended) in the SCE. The DLL search order can be configured to search for DLLs that
are requested by running processes in one of two ways- . Search folders specified in the
system path first, and then search the current working folder. . Search current working
folder first, and then search the folders specified in the system path. When enabled, the
registry value is set to 1. With a setting of 1, the system first searches the folders that are
specified in the system path and then searches the current working folder. When disabled
the registry value is set to 0 and the system first searches the current working folder and
then searches the folders that are specified in the system path.
*Rationale*
If a user unknowingly executes hostile code that was packaged with additional files that
include modified versions of system DLLs, the hostile code could load its own versions of
those DLLs and potentially increase the type and degree of damage the code can render."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\MSS- (SafeDllSearchMode) Enable Safe DLL search mode (recommended)
Impact-Applications will be forced to search for DLLs in the system path first. For applications that
require unique versions of these DLLs that are included with the application, this entry
could cause performance or stability problems.
Default Value-Not Defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,800-53|AC-4,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,CCE|CCE-9348-4,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager"
reg_item : "SafeDllSearchMode"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.61 Set 'Network security: LAN Manager authentication level'"
info :"Set 'Network security: LAN Manager authentication level' to 'Send NTLMv2 response only. Refuse LM & NTLM' (Scored)
LAN Manager (LM) is a family of early Microsoft client/server software that allows users to
link personal computers together on a single network. Network capabilities include
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 possible values for the Network security- LAN
Manager authentication level setting are- . Send LM & NTLM responses . Send LM & NTLM and
use NTLMv2 session security if negotiated . Send NTLM responses only . Send NTLMv2
responses only . Send NTLMv2 responses only\refuse LM . Send NTLMv2 responses
only\refuse LM & NTLM . Not Defined The Network security- LAN Manager authentication
level setting determines which challenge/response authentication protocol is used for
network logons. This choice affects the authentication protocol level that clients use, the
session security level that the computers negotiate, and the authentication level that
servers accept as follows- . Send LM & NTLM responses. Clients use LM and NTLM
authentication and never use NTLMv2 session security. Domain controllers accept LM,
NTLM, and NTLMv2 authentication. . Send LM & NTLM use NTLMv2 session security if
negotiated. Clients use LM and NTLM authentication and use NTLMv2 session security if
the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. .
Send NTLM response only. Clients use NTLM authentication only and use NTLMv2 session
security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2
authentication. . Send NTLMv2 response only. Clients use NTLMv2 authentication only and
use NTLMv2 session security if the server supports it. Domain controllers accept LM,
NTLM, and NTLMv2 authentication. . Send NTLMv2 response only\refuse LM. Clients use
NTLMv2 authentication only and use NTLMv2 session security if the server supports it.
Domain controllers refuse LM (accept only NTLM and NTLMv2 authentication). . Send
NTLMv2 response only\refuse LM & NTLM. 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). These settings correspond to the levels
discussed in other Microsoft documents as follows- . Level 0 Send LM and NTLM response;
never use NTLMv2 session security. Clients use LM and NTLM authentication, and never
use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2
authentication. . Level 1 Use NTLMv2 session security if negotiated. Clients use LM and
NTLM authentication, and use NTLMv2 session security if the server supports it. Domain
controllers accept LM, NTLM, and NTLMv2 authentication. . Level 2 Send NTLM response
only. Clients use only NTLM authentication, and use NTLMv2 session security if the server
supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication. . Level 3
Send NTLMv2 response only. Clients use NTLMv2 authentication, and use NTLMv2 session
security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2
authentication. . Level 4 Domain controllers refuse LM responses. Clients use NTLM
authentication, and use NTLMv2 session security if the server supports it. Domain
controllers refuse LM authentication, that is, they accept NTLM and NTLMv2. . Level 5
Domain controllers refuse LM and NTLM responses (accept only NTLMv2). Clients use
NTLMv2 authentication, use and NTLMv2 session security if the server supports it. Domain
controllers refuse NTLM and LM authentication (they accept only NTLMv2).
*Rationale*
In Windows Vista, this setting is undefined. However, in Windows 2000, Windows Server
2003, and Windows XP clients are configured by default to send LM and NTLM
authentication responses (Windows 95-based and Windows 98-based clients only send
LM). The default setting on servers allows all clients to authenticate with servers and use
their resources. However, this means that LM responses - the weakest form of
authentication response - are sent over the network, and it is potentially possible for
attackers to sniff that traffic to more easily reproduce the user's password. The Windows
95, Windows 98, and Windows NT operating systems cannot use the Kerberos version 5
protocol for authentication. For this reason, in a Windows Server 2003 domain, these
computers authenticate by default with both the LM and NTLM protocols for network
authentication. You can enforce a more secure authentication protocol for Windows 95,
Windows 98, and Windows NT by using NTLMv2. For the logon process, NTLMv2 uses a
secure channel to protect the authentication process. Even if you use NTLMv2 for earlier
clients and servers, Windows-based clients and servers that are members of the domain
will use the Kerberos authentication protocol to authenticate with Windows Server 2003
domain controllers."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 5.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network security- LAN Manager authentication level
Impact-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. Note- For information about
a hotfix to ensure that this setting works in networks that include Windows NT 4.0-based
computers along with Windows 2000, Windows XP, and Windows Server 2003-based
computers, see article 305379, Authentication Problems in Windows 2000 with NTLM 2
Levels Above 2 in a Windows NT 4.0 Domain, in the Microsoft Knowledge Base
(http-//go.microsoft.com/fwlink/?LinkId=100907).
Default Value-Send NTLMv2 response only"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,CSF|PR.PT-3,800-53|CM-6,PCI-3.0|8.2.1,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4,CCE|CCE-8806-2"
reg_type : REG_DWORD
value_type : POLICY_DWORD
reg_key : "HKLM\SYSTEM\CurrentControlSet\Control\Lsa"
reg_item : "lmcompatibilitylevel"
value_data : 5
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.62 Set 'Network access: Do not allow anonymous enumeration of SAM accounts and shares'"
info :"Set 'Network access: Do not allow anonymous enumeration of SAM accounts and shares' to 'Enabled' (Scored)
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 workstations in
your environment. The Network access- Do not allow anonymous enumeration of SAM
accounts and shares setting is configured to Enabled for the two environments that are
discussed in this guide.
*Rationale*
An unauthorized user could anonymously list account names and shared resources and use
the information to attempt to guess passwords or perform social engineering attacks."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\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 grant access to users of another domain across a one-way trust
because administrators in the trusting domain will be unable to enumerate lists of accounts
in the other domain. 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.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,CSF|PR.AC-1,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|PR.AC-4,CSF|DE.CM-1,CCE|CCE-9156-1"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\SYSTEM\CurrentControlSet\Control\Lsa"
reg_item : "RestrictAnonymous"
value_data : "enabled"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.63 Set 'Network access: Remotely accessible registry paths and sub- paths'"
info :"Set 'Network access: Remotely accessible registry paths and sub- paths' to 'System\CurrentControlSet\Control\Print\Printers System\CurrentControlSet\Services\Eventlog Software\Microsoft\OLAP Server Software\Microsoft\Windows NT\CurrentVersion\Print Sof (Scored)
This policy setting determines which registry paths and sub-paths will be accessible when
an application or process references the WinReg key to determine access permissions.
Note- In Windows XP this setting is called Network access- Remotely accessible registry
paths, the setting with that same name in Windows Vista, Windows Server 2008, and
Windows Server 2003 does not exist in Windows XP. Note- When you configure this setting
you specify a list of one or more objects. The delimiter used when entering the list is a line
feed or carriage return, that is, type the first object on the list, press the Enter button, type
the next object, press Enter again, etc. The setting value is stored as a comma-delimited list
in group policy security templates. It is also rendered as a comma-delimited list in Group
Policy Editor's display pane and the Resultant Set of Policy console. It is recorded in the
registry as a line-feed delimited list in a REG_MULTI_SZ value.
*Rationale*
The registry contains sensitive computer configuration information that could be used by
an attacker to facilitate unauthorized activities. The fact that the default ACLs assigned
throughout the registry are fairly restrictive and help to protect the registry from access by
unauthorized users reduces the risk of such an attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to System\CurrentControlSet\Control\Print\Printers
System\CurrentControlSet\Services\Eventlog
Software\Microsoft\OLAP Server
Software\Microsoft\Windows NT\CurrentVersion\Print
Software\Microsoft\Windows
NT\CurrentVersion\Windows
System\CurrentControlSet\Control\ContentIndex
System\CurrentControlSet\Control\Terminal Server
System\CurrentControlSet\Control\Terminal Server\UserConfig
System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration
Software\Microsoft\Windows NT\CurrentVersion\Perflib
System\CurrentControlSet\Services\SysmonLog.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network access- Remotely accessible registry paths and sub-paths
Impact-Remote management tools such as the Microsoft Baseline Security Analyzer and Microsoft
Systems Management Server require remote access to the registry to properly monitor and
manage those computers. If you remove the default registry paths from the list of
accessible ones, such remote management tools could fail. Note- If you want to allow
remote access, you must also enable the Remote Registry service.
Default Value-System\CurrentControlSet\Control\Print\Printers,System\CurrentControlSet\Services\Eventlog,Software\Microsoft\OLAP Server,Software\Microsoft\Windows
NT\CurrentVersion\Print,Software\Microsoft\Windows
NT\CurrentVersion\Windows,System\CurrentControlSet\Control\ContentIndex,System\CurrentControlSet\Control\Terminal Server,System\CurrentControlSet\Control\Terminal
Server\UserConfig,System\CurrentControlSet\Control\Terminal
Server\DefaultUserConfiguration,Software\Microsoft\Windows
NT\CurrentVersion\Perflib,System\CurrentControlSet\Services\SysmonLog"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,CCE|CCE-9386-4,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_MULTI_TEXT
reg_key : "HKLM\System\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths"
reg_item : "Machine"
value_data : "System\CurrentControlSet\Control\Print\Printers" && "System\CurrentControlSet\Services\Eventlog" && "Software\Microsoft\OLAP Server" && "Software\Microsoft\Windows NT\CurrentVersion\Print" && "Software\Microsoft\Windows NT\CurrentVersion\Windows" && "System\CurrentControlSet\Control\ContentIndex" && "System\CurrentControlSet\Control\Terminal Server" && "System\CurrentControlSet\Control\Terminal Server\UserConfig" && "System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration" && "Software\Microsoft\Windows NT\CurrentVersion\Perflib" && "System\CurrentControlSet\Services\SysmonLog"
type : REGISTRY_SETTING
description :"1.2.1.1.1.64 Set 'Microsoft network client: Send unencrypted password to third- party SMB servers'"
info :"Set 'Microsoft network client: Send unencrypted password to third- party SMB servers' to 'Disabled' (Scored)
Disable this policy setting to prevent the SMB redirector from sending plaintext passwords
during authentication to third-party SMB servers that do not support password encryption.
It is recommended that you disable this policy setting unless there is a strong business case
to enable it. If this policy setting is enabled, unencrypted passwords will be allowed across
the network.
*Rationale*
If you enable this policy setting, the server can transmit passwords in plaintext across the
network to other computers that offer SMB services. These other computers may not use
any of the SMB security mechanisms that are included with Windows Server 2003."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft network client- Send unencrypted password to third-party SMB servers
Impact-Some very old applications and operating systems such as MS-DOS, Windows for
Workgroups 3.11, and Windows 95a may not be able to communicate with the servers in
your organization by means of the SMB protocol.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,800-53|SC-8,CSF|PR.IP-1,800-53|CM-7,CSF|PR.DS-1,CSF|PR.DS-2,CSF|PR.PT-3,800-53|CM-6,PCI-3.0|8.2.1,CCE|CCE-9265-0,CSF|PR.DS-5,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4,SANS-CSC|17,CSF|PR.AC-3"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters"
reg_item : "EnablePlainTextPassword"
value_data : "Disabled"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.65 Set 'Shutdown: Clear virtual memory pagefile'"
info :"Set 'Shutdown: Clear virtual memory pagefile' to 'Disabled' (Scored)
This policy setting determines whether the virtual memory pagefile is cleared when the
system is shut down. When this policy setting is enabled, the system pagefile is cleared
each time that the system shuts down properly. If you enable this security setting, the
hibernation file (Hiberfil.sys) is zeroed out when hibernation is disabled on a portable
computer system. It will take longer to shut down and restart the computer, and will be
especially noticeable on computers with large paging files.
*Rationale*
Important information that is kept in real memory may be written periodically to the page
file to help Windows Server 2003 handle multitasking functions. An attacker who has
physical access to a server that has been shut down could view the contents of the paging
file. The attacker could move the system volume into a different computer and then analyze
the contents of the paging file. Although this process is time consuming, it could expose
data that is cached from random access memory (RAM) to the paging file. Caution An
attacker who has physical access to the server could bypass this countermeasure by simply
unplugging the server from its power source."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Shutdown- Clear virtual memory pagefile
Impact-It will take longer to shut down and restart the server, especially on servers with large
paging files. For a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this policy
setting could increase the shutdown process by 20 to 30 minutes, or more. For some
organizations, this downtime violates their internal service level agreements. Therefore,
use caution before you implement this countermeasure in your environment.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4,CCE|CCE-9222-1"
reg_type : REG_DWORD
value_type : POLICY_DWORD
reg_key : "HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management"
reg_item : "ClearPageobÌåÓýAtShutdown"
value_data : 0
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.69 'Number of previous logons to cache (in case domain controller is not available)'"
info :"Set 'Interactive logon: Number of previous logons to cache (in case domain controller is not available)' to '2' (Scored)
This policy setting determines whether a user can log on to a Windows domain using
cached account information. Logon information for domain accounts can be cached locally
to allow users to log on even if a domain controller cannot be contacted. This policy setting
determines the number of unique users for whom logon information is cached locally. If
this value is set to 0, the logon cache feature is disabled. An attacker who is able to access
the file system of the server could locate this cached information and use a brute force
attack to determine user passwords.
*Rationale*
The number that is assigned to this policy setting indicates the number of users whose
logon information the servers will cache locally. If the number is set to 10, then the server
caches logon information for 10 users. When an eleventh user logs on to the computer, the
server overwrites the oldest cached logon session. Users who access the server console will
have their logon credentials cached on that server. An attacker who is able to access the file
system of the server could locate this cached information and use a brute force attack to
attempt to determine user passwords. To mitigate this type of attack, Windows encrypts
the information and obscures its physical location."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 2.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Interactive logon- Number of previous logons to cache (in case domain
controller is not available)
Impact-Users will be unable to log on to any computers if there is no domain controller available to
authenticate them. Organizations may want to configure this value to 2 for end-user
computers, especially for mobile users. A configuration value of 2 means that the user's
logon information will still be in the cache, even if a member of the IT department has
recently logged on to their computer to perform system maintenance. This method allows
users to log on to their computers when they are not connected to the organization's
network.
Default Value-10 logons"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,CSF|PR.AC-1,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|PR.AC-4,CSF|DE.CM-1,CCE|CCE-8487-1"
reg_type : REG_DWORD
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
reg_item : "CachedLogonsCount"
value_data : 2
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.70 Set 'Interactive logon: Do not display last user name'"
info :"Set 'Interactive logon: Do not display last user name' to 'Enabled' (Scored)
This policy setting determines whether the account name of the last user to log on to the
client computers in your organization will be displayed in each computer's respective
Windows logon screen. Enable this policy setting to prevent intruders from collecting
account names visually from the screens of desktop or laptop computers in your
organization.
*Rationale*
An attacker with access to the console (for example, someone with physical access or
someone who is able to connect to the server through Terminal Services) could view the
name of the last user who logged on to the server. The attacker could then try to guess the
password, use a dictionary, or use a brute-force attack to try and log on."
solution :"
To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Interactive logon- Do not display last user name
Impact-Users will not see their user name or domain name when unlocking their computer, they
will have to enter that information.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.IP-1,SANS-CSC|3,CSF|PR.AC-1,PCI-3.0|2.2.4,800-53|CM-6,SANS-CSC|16,800-53|AC-9,800-53|AC-3,Level|1S,800-53|AC-2,CSF|PR.AC-4,CSF|DE.CM-1,CCE|CCE-9449-0"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system"
reg_item : "DontDisplayLastUserName"
value_data : "Enabled"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.72 'Minimum session security for NTLM SSP based (including secure RPC) servers'"
info :"Set 'Network security: Minimum session security for NTLM SSP based (including secure RPC) servers' to 'Require NTLMv2 session security,Require 128- bit encryption' (Scored)
This policy setting determines which behaviors are allowed 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
possible values for the Network security- Minimum session security for NTLM SSP based
(including secure RPC) servers setting are- . Require message confidentiality. This option is
only available in Windows XP and Windows Server 2003, the connection will fail if
encryption is not negotiated. Encryption converts data into a form that is not readable until
decrypted. . Require message integrity. This option is only available in Windows XP and
Windows Server 2003, the connection will fail if message integrity is not negotiated. The
integrity of a message can be assessed through message signing. Message signing proves
that the message has not been tampered with; it attaches a cryptographic signature that
identifies the sender and is a numeric representation of the contents of the message. .
Require 128-bit encryption. The connection will fail if strong encryption (128-bit) is not
negotiated. . Require NTLMv2 session security. The connection will fail if the NTLMv2
protocol is not negotiated. . Not Defined.
*Rationale*
You can enable all of the options for this policy setting to help protect network traffic that
uses the NTLM Security Support Provider (NTLM SSP) from being exposed or tampered
with by an attacker who has gained access to the same network. That is, these options help
protect against man-in-the-middle attacks."
solution :"
To implement the recommended configuration state, set the following Group Policy setting
to 537395200.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network security- Minimum session security for NTLM SSP based (including
secure RPC) servers
Impact-Server applications that are enforcing these settings will be unable to communicate with
older servers that do not support them. This setting could impact Windows Clustering
when applied to servers running Windows Server 2003, see 'How to apply more restrictive
security settings on a Windows Server 2003-based cluster server' at
http-//support.microsoft.com/default.aspx?scid=kb;en-us;891597 and 'You receive an
'Error 0x8007042b' error message when you add or join a node to a cluster if you use
NTLM version 2 in Windows Server 2003' at http-//support.microsoft.com/kb/890761/
for more information on possible issues and how to resolve them.
Default Value-Require 128-bit encryption"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,CCE|CCE-9736-0,CSF|PR.PT-3,800-53|CM-6,PCI-3.0|8.2.1,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_DWORD
value_data : 537395200
reg_key : "HKLM\System\CurrentControlSet\Control\Lsa\MSV1_0"
reg_item : "NTLMMinServerSec"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.73 Set 'MSS: (WarningLevel)"
info :"Set 'MSS: (WarningLevel) Percentage threshold for the security event log at which the system will generate a warning' to '90' (Scored)
The registry value entry WarningLevel was added to the template file in the
HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\Eventlog\Security\
registry key. The entry appears as MSS- (WarningLevel) Percentage threshold for the
security event log at which the system will generate a warning in the SCE. This setting can
generate a security audit in the Security event log when the log reaches a user-defined
threshold. Note If log settings are configured to Overwrite events as needed or Overwrite
events older than x days, this event will not be generated.
*Rationale*
If the Security log reaches 90 percent of its capacity and the computer has not been
configured to overwrite events as needed, more recent events will not be written to the log.
If the log reaches its capacity and the computer has been configured to shut down when it
can no longer record events to the Security log, the computer will shut down and will no
longer be available to provide network services."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 90.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\MSS- (WarningLevel) Percentage threshold for the security event log at which
the system will generate a warning
Impact-This setting will generate an audit event when the Security log reaches the 90 percent-full
threshold unless the log is configured to overwrite events as needed.
Default Value-Not Defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.PT-1,800-53|AC-4,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|14,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,PCI|10.7,CSF|PR.DS-4,CCE|CCE-9501-8,800-53|AU-9,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_DWORD
value_data : [MIN..90]
reg_key : "HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security"
reg_item : "WarningLevel"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.74 UAC - Virtualize file and registry write failures to per- user locations' "
info :"Set 'User Account Control: Virtualize file and registry write failures to per- user locations' to 'Enabled' (Scored)
This policy setting controls whether application write failures are redirected to defined
registry and file system locations. This policy setting mitigates applications that run as
administrator and write run-time application data to %ProgramobÌåÓýs%, %Windir%,
%Windir%\system32, or HKLM\Software. The options are- . Enabled- (Default) Application
write failures are redirected at run time to defined user locations for both the file system
and registry. . Disabled- Applications that write data to protected locations fail.
*Rationale*
This setting reduces vulnerabilities by ensuring that legacy applications only write data to
permitted locations."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Virtualize file and registry write failures to per-user
locations
Impact-None. This is the default configuration.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-6,PCI|7.1.1,800-53|AC-3,CCE|CCE-8817-9,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "EnableVirtualization"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.75 Set 'Interactive logon: Require Domain Controller authentication to unlock workstation'"
info :"Set 'Interactive logon: Require Domain Controller authentication to unlock workstation' to 'Enabled' (Scored)
Logon information is required to unlock a locked computer. For domain accounts, the
Interactive logon- Require Domain Controller authentication to unlock workstation setting
determines whether it is necessary to contact a domain controller to unlock a computer. If
you enable this setting, a domain controller must authenticate the domain account that is
being used to unlock the computer. If you disable this setting, logon information
confirmation with a domain controller is not required for a user to unlock the computer.
However, if you configure the Interactive logon- Number of previous logons to cache (in
case domain controller is not available) setting to a value that is greater than zero, then the
user's cached credentials will be used to unlock the computer. Note- This setting applies to
Windows 2000 computers, but it is not available through the Security Configuration
Manager tools on these computers.
*Rationale*
By default, the computer caches in memory the credentials of any users who are
authenticated locally. The computer uses these cached credentials to authenticate anyone
who attempts to unlock the console. When cached credentials are used, any changes that
have recently been made to the account - such as user rights assignments, account lockout,
or the account being disabled - are not considered or applied after the account is
authenticated. User privileges are not updated, and (more importantly) disabled accounts
are still able to unlock the console of the computer."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Interactive logon- Require Domain Controller authentication to unlock
workstation
Impact-
When the console on a computer is locked, either by a user or automatically by a screen
saver time-out, the console can only be unlocked if the user is able to re-authenticate to the
domain controller. If no domain controller is available, then users cannot unlock their
workstations. If you configure the Interactive logon- Number of previous logons to cache
(in case domain controller is not available) setting to 0, users whose domain controllers are
unavailable (such as mobile or remote users) will not be able to log on.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-8818-7,800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
reg_type : REG_DWORD
value_type : POLICY_SET
reg_key : "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
reg_item : "ForceUnlockLogon"
value_data : "Enabled"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.76 Set 'Audit: Shut down system'"
info :"Set 'Audit: Shut down system immediately if unable to log security audits' to 'Disabled' (Scored)
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. Therefore, this policy setting is configured to Not Defined for both of the environments that are discussed in this chapter."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Audit- Shut down system immediately if unable to log security audits
Impact-If you enable this policy setting, 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.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.PT-1,CSF|PR.IP-1,CCE|CCE-9463-1,800-53|CM-7,SANS-CSC|14,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,800-53|AU-5,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_SET
reg_key : "HKLM\System\CurrentControlSet\Control\Lsa"
reg_item : "crashonauditfail"
value_data : "Disabled"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.79 Set 'User Account Control: Only elevate UIAccess applications that are installed in secure locations'"
info :"Set 'User Account Control: Only elevate UIAccess applications that are installed in secure locations' to 'Enabled' (Scored)
This policy setting controls whether applications that request to run with a User Interface
Accessibility (UIAccess) integrity level must reside in a secure location in the file system.
Secure locations are limited to the following- - …\Program obÌåÓýs\, including subfolders -
…\Windows\system32\ - …\Program obÌåÓýs (x86)\, including subfolders for 64-bit
versions of Windows Note- Windows enforces a public key infrastructure (PKI) signature
check on any interactive application that requests to run with a UIAccess integrity level
regardless of the state of this security setting. The options are- . Enabled- (Default) If an
application resides in a secure location in the file system, it runs only with UIAccess
integrity. . Disabled- An application runs with UIAccess integrity even if it does not reside in
a secure location in the file system.
*Rationale*
UIAccess Integrity allows an application to bypass User Interface Privilege Isolation (UIPI)
restrictions when an application is elevated in privilege from a standard user to an
administrator. This is required to support accessibility features such as screen readers that
are transmitting user interfaces to alternative forms. A process that is started with
UIAccess rights has the following abilities- . To set the foreground window. . To drive any
application window using SendInput function. . To use read input for all integrity levels
using low-level hooks, raw input, GetKeyState, GetAsyncKeyState, and GetKeyboardInput. .
To set journal hooks. . To uses AttachThreadInput to attach a thread to a higher integrity
input queue."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Only elevate UIAccess applications that are installed in
secure locations
Impact-If the application that requests UIAccess meets the UIAccess setting requirements,
Windows Vista starts the application with the ability to bypass most of the UIPI
restrictions. If the application does not meet the security restrictions, the application will
be started without UIAccess rights and can interact only with applications at the same or
lower privilege level.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-6,PCI|7.1.1,CCE|CCE-9801-2,800-53|AC-3,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "EnableSecureUIAPaths"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.80 Set 'User Account Control: Run all administrators in Admin Approval Mode'"
info :"Set 'User Account Control: Run all administrators in Admin Approval Mode' to 'Enabled' (Scored)
This policy setting controls the behavior of all User Account Control (UAC) policy settings
for the computer. If you change this policy setting, you must restart your computer. The
options are- . Enabled- (Default) Admin Approval Mode is enabled. This policy must be
enabled and related UAC policy settings must also be set appropriately to allow the built-in
Administrator account and all other users who are members of the Administrators group to
run in Admin Approval Mode. . Disabled- Admin Approval Mode and all related UAC policy
settings are disabled. Note- If this policy setting is disabled, the Security Center notifies you
that the overall security of the operating system has been reduced.
*Rationale*
This is the setting that turns on or off UAC. If this setting is disabled, UAC will not be used
and any security benefits and risk mitigations that are dependent on UAC will not be
present on the system."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Run all administrators in Admin Approval Mode
Impact-Users and administrators will need to learn to work with UAC prompts and adjust their
work habits to use least privilege operations.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-6,PCI|7.1.1,CCE|CCE-9189-2,800-53|AC-3,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "EnableLUA"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.81 Set 'Network security: LDAP client signing requirements'"
info :"Set 'Network security: LDAP client signing requirements' to 'Negotiate signing' (Scored)
This policy setting determines the level of data signing that is requested on behalf of clients
that issue LDAP BIND requests, as follows- . None. The LDAP BIND request is issued with
the caller-specified options. . Negotiate signing. If Transport Layer Security/Secure Sockets
Layer (TLS/SSL) has not been started, the LDAP BIND request is initiated with the LDAP
data signing option set in addition to the caller-specified options. If TLS/SSL has been
started, the LDAP BIND request is initiated with the caller-specified options. . Require
signature. This level is the same as Negotiate signing. However, if the LDAP server's
intermediate saslBindInProgress response does not indicate that LDAP traffic signing is
required, the caller is told that the LDAP BIND command request failed. Note- This policy
setting does not have any impact on ldap_simple_bind or 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 possible values for the
Network security- LDAP client signing requirements setting are- . None . Negotiate signing .
Require signature . Not Defined
*Rationale*
Unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder
captures the packets between the client and server, modifies them, and then forwards them
to the server. For an LDAP server, this susceptibility means that an attacker could cause a
server to make decisions that are based on false or altered data from the LDAP queries. To
lower this risk in your network, you can implement strong physical security measures to
protect the network infrastructure. Also, you can make all types of man-in-the-middle
attacks extremely difficult if you require digital signatures on all network packets by means
of IPsec authentication headers."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network security- LDAP client signing requirements
Impact-If you configure the server to require LDAP signatures 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.
Default Value-Negotiate signing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,CSF|PR.PT-3,800-53|CM-6,PCI-3.0|8.2.1,800-53|AC-3,Level|1S,CSF|PR.DS-4,CCE|CCE-9768-3,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Services\LDAP"
reg_item : "LDAPClientIntegrity"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.82 Set 'Microsoft network server: Amount of idle time required before suspending session'"
info :"Set 'Microsoft network server: Amount of idle time required before suspending session' to '15' (Scored)
This policy setting allows you to specify the amount of continuous idle time that must pass
in an SMB session before the session is suspended because of inactivity. Administrators can
use this policy setting to control when a computer suspends an inactive SMB session. If
client activity resumes, the session is automatically reestablished. A value of 0 will
disconnect an idle session as quickly as possible. The maximum value is 99999, which is
208 days; in effect, this value disables the setting.
*Rationale*
Each SMB session consumes server resources, and numerous null sessions will slow the
server or possibly cause it to fail. An attacker could repeatedly establish SMB sessions until
the server's SMB services become slow or unresponsive."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 15.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Microsoft network server- Amount of idle time required before suspending
session
Impact-There will be little impact because SMB sessions will be re-established automatically if the
client resumes activity.
Default Value-15 minutes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"HIPAA|164.312(a)(2)(iii),CSF|PR.IP-1,800-53|CM-7,PCI-3.0|8.1.8,CSF|PR.AC-1,CSF|PR.PT-3,800-53|CM-6,CCE|CCE-9406-0,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,800-53|AC-1"
reg_type : REG_DWORD
value_type : POLICY_DWORD
reg_key : "HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters"
reg_item : "AutoDisconnect"
value_data : [1..15]
type : REGISTRY_SETTING
description :"1.2.1.1.1.83 Set 'System objects: Require case insensitivity for non- Windows subsystems'"
info :"Set 'System objects: Require case insensitivity for non- Windows subsystems' to 'Enabled' (Scored)
This policy setting determines whether case insensitivity is enforced for all subsystems.
The Microsoft Win32® subsystem is case insensitive. However, the kernel supports case
sensitivity for other subsystems, such as the Portable Operating System Interface for UNIX
(POSIX). Because Windows is case insensitive (but the POSIX subsystem will support case
sensitivity), failure to enforce this policy setting makes it possible for a user of the POSIX
subsystem to create a file with the same name as another file by using mixed case to label
it. Such a situation can block access to these files by another user who uses typical Win32
tools, because only one of the files will be available.
*Rationale*
Because Windows is case-insensitive but the POSIX subsystem will support case sensitivity,
failure to enable this policy setting would make it possible for a user of that subsystem to
create a file with the same name as another file but with a different mix of upper and lower
case letters. Such a situation could potentially confuse users when they try to access such
files from normal Win32 tools because only one of the files will be available."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\System objects- Require case insensitivity for non-Windows subsystems
Impact-All subsystems will be forced to observe case insensitivity. This configuration may confuse
users who are familiar with any UNIX-based operating systems that is case-sensitive.
Default Value-Enabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|SC-5,CSF|PR.IP-1,CCE|CCE-9319-5,800-53|CM-7,SANS-CSC|3,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,CSF|PR.DS-4,CSF|DE.CM-1,CSF|PR.AC-4"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKLM\System\CurrentControlSet\Control\Session Manager\Kernel"
reg_item : "ObCaseInsensitive"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.87 Set 'Interactive logon: Prompt user to change password before expiration'"
info :"Set 'Interactive logon: Prompt user to change password before expiration' to '14' (Scored)
This policy setting determines how far in advance users are warned that their password
will expire. It is recommended that you configure this policy setting to 14 days to
sufficiently warn users when their passwords will expire.
*Rationale*
It is recommended that user passwords be configured to expire periodically. Users will
need to be warned that their passwords are going to expire, or they may inadvertently be
locked out of the computer when their passwords expire. This condition could lead to
confusion for users who access the network locally, or make it impossible for users to
access your organization's network through dial-up or virtual private network (VPN)
connections."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 14.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Interactive logon- Prompt user to change password before expiration
Impact-Users will see a dialog box prompt to change their password each time that they log on to
the domain when their password is configured to expire in 14 or fewer days.
Default Value-14 days"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|IA-5,CSF|PR.IP-1,800-53|CM-7,CSF|PR.AC-1,CSF|PR.PT-3,800-53|CM-6,SANS-CSC|16,800-53|AC-3,PCI|8.5,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,PCI-3.0|8.5,CCE|CCE-9307-0"
value_type : POLICY_DWORD
value_data : 14
reg_key : "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon"
reg_item : "passwordexpirywarning"
type : REGISTRY_SETTING
description :"1.2.1.1.1.88 Set 'Network access: Shares that can be accessed anonymously'"
info :"Set 'Network access: Shares that can be accessed anonymously' to '' (Scored)
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. Note- It can be very
dangerous to add other shares to this Group Policy setting. Any network user can access
any shares that are listed, which could exposure or corrupt sensitive data. Note- When you
configure this setting you specify a list of one or more objects. The delimiter used when
entering the list is a line feed or carriage return, that is, type the first object on the list,
press the Enter button, type the next object, press Enter again, etc. The setting value is
stored as a comma-delimited list in group policy security templates. It is also rendered as a
comma-delimited list in Group Policy Editor's display pane and the Resultant Set of Policy
console. It is recorded in the registry as a line-feed delimited list in a REG_MULTI_SZ value.
*Rationale*
It is very dangerous to enable this setting. Any shares that are listed can be accessed by any
network user, which could lead to the exposure or corruption of sensitive data."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to .
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Network access- Shares that can be accessed anonymously
Impact-There should be little impact because this is the default configuration. Only authenticated
users will have access to shared resources on the server.
Default Value-Not defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.IP-1,800-53|CM-7,SANS-CSC|3,CCE|CCE-9196-7,PCI-3.0|2.2.4,CSF|PR.PT-3,800-53|CM-6,800-53|AC-3,Level|1S,CSF|PR.AC-4,800-53|IA-2"
value_type : POLICY_MULTI_TEXT
value_data : ""
reg_key : "HKLM\System\CurrentControlSet\Services\LanManServer\Parameters"
reg_item : "NullSessionShares"
type : REGISTRY_SETTING
description :"1.2.1.1.1.89 Set 'User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode'"
info :"Set 'User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode' to 'Prompt for credentials' (Scored)
This policy setting controls the behavior of the elevation prompt for administrators. The
options are- . Elevate without prompting- Allows privileged accounts to perform an
operation that requires elevation without requiring consent or credentials. Note- Use this
option only in the most constrained environments. . Prompt for credentials on the secure
desktop- When an operation requires elevation of privilege, the user is prompted on the
secure desktop to enter a privileged user name and password. If the user enters valid
credentials, the operation continues with the user's highest available privilege. . Prompt for
consent on the secure desktop- When an operation requires elevation of privilege, the user
is prompted on the secure desktop to select either Permit or Deny. If the user selects
Permit, the operation continues with the user's highest available privilege. . Prompt for
credentials- When an operation requires elevation of privilege, the user is prompted to
enter an administrative user name and password. If the user enters valid credentials, the
operation continues with the applicable privilege. . Prompt for consent- When an operation
requires elevation of privilege, the user is prompted to select either Permit or Deny. If the
user selects Permit, the operation continues with the user's highest available privilege. .
Prompt for consent for non-Windows binaries- (Default) When an operation for a non-
Microsoft application requires elevation of privilege, the user is prompted on the secure
desktop to select either Permit or Deny. If the user selects Permit, the operation continues
with the user's highest available privilege.
*Rationale*
One of the risks that the UAC feature introduced with Windows Vista is trying to mitigate is
that of malicious software running under elevated credentials without the user or
administrator being aware of its activity. This setting raises awareness to the administrator
of elevated privilege operations and permits the administrator to prevent a malicious
program from elevating its privilege when the program attempts to do so."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 3.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\User Account Control- Behavior of the elevation prompt for administrators in
Admin Approval Mode
Impact-This policy setting controls the behavior of the elevation prompt for administrators.
Default Value-Prompt for consent for non-Windows binaries"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-8958-1,PCI|7.1.1,Level|1S,800-53|AC-2,800-53|IA-2"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "ConsentPromptBehaviorAdmin"
value_data : "3"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.1.1.91 Set 'Interactive logon: Do not require CTRL+ALT+DEL'"
info :"Set 'Interactive logon: Do not require CTRL+ALT+DEL' to 'Disabled' (Scored)
This policy setting determines whether users must press CTRL+ALT+DEL before they log
on. If you enable this policy setting, users can log on without this key combination. If you
disable this policy setting, users must press CTRL+ALT+DEL before they log on to Windows
unless they use a smart card for Windows logon. A smart card is a tamper-proof device that
stores security information.
*Rationale*
Microsoft developed this feature to make it easier for users with certain types of physical
impairments to log on to computers that run Windows. If users are not required to press
CTRL+ALT+DEL, they are susceptible to attacks that attempt to intercept their passwords.
If CTRL+ALT+DEL is required before logon, user passwords are communicated by means of
a trusted path. An attacker could install a Trojan horse program that looks like the standard
Windows logon dialog box and capture the user's password. The attacker would then be
able to log on to the compromised account with whatever level of privilege that user has."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security
Options\Interactive logon- Do not require CTRL+ALT+DEL
Impact-Unless they use a smart card to log on, users will have to simultaneously press three keys
before the logon dialog box will display.
Default Value-Not defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-5,800-53|CM-7,CCE|CCE-9317-9,PCI-3.0|2.2.4,800-53|CM-6,800-53|AC-3,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System"
reg_item : "DisableCAD"
value_data : "0"
reg_option : CAN_NOT_BE_NULL
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.3 Set 'Allow log on locally' to 'Administrators, Users' (Scored)"
info :"This policy setting determines which users can interactively log on to computers in your
environment. Logons that are initiated by pressing the CTRL+ALT+DEL key sequence on
the client computer keyboard require this user right. Users who attempt to log on through
Terminal Services or IIS also require this user right. The Guest account is assigned this user
right by default. Although this account is disabled by default, it is recommended that you
enable this setting through Group Policy. However, this user right should generally be
restricted to the Administrators and Users groups. Assign this user right to the Backup
Operators group if your organization requires that they have this capability. When
configuring a user right in the SCM enter a comma delimited list of accounts. Accounts can
be either local or located in Active Directory, they can be groups, users, or computers.
*Rationale*
Any account with the Allow log on locally user right can log on at the console of the
computer. If you do not restrict this user right to legitimate users who need to be able to
log on to the console of the computer, unauthorized users could download and run
malicious software to elevate their privileges."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators, Users.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Allow log on locally
Impact-If you remove these default groups, you could limit the abilities of users who are assigned
to specific administrative roles in your environment. If you have installed optional
components such as ASP.NET or Internet Information Services, you may need to assign
Allow log on locally user right to additional accounts that are required by those
components. IIS requires that this user right be assigned to the IUSR_
account. You should confirm that delegated activities will not be adversely affected by any
changes that you make to the Allow log on locally user rights assignments.
Default Value-Guest, Administrators, Users, Backup Operators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-9345-0,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators" && "Users"
right_type : SeInteractiveLogonRight
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.4 Set 'Debug programs' to 'Administrators' (Scored)"
info :"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. Note Microsoft released several security updates in
October 2003 that used a version of Update.exe that required the administrator to have the
Debug programs user right. Administrators who did not have this user right were unable to
install these security updates until they reconfigured their user rights. This is not typical
behavior for operating system updates. For more information, see Knowledge Base article
830846- Windows Product Updates may stop responding or may use most or all the CPU
resources. When configuring a user right in the SCM enter a comma delimited list of
accounts. Accounts can be either local or located in Active Directory, they can be groups,
users, or computers.
*Rationale*
The Debug programs user right can be exploited to capture sensitive computer information
from system memory, or to access and modify kernel or application structures. Some attack
tools exploit this user right to extract hashed passwords and other private security
information, or to insert rootkit code. By default, the Debug programs user right is assigned
only to administrators, which helps to mitigate the risk from this vulnerability."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Debug programs
Impact-If you revoke this user right, no one will be able to debug programs. However, typical
circumstances rarely require this capability on production computers. If a problem arises
that requires an application to be debugged on a production server, you can move the
server to a different OU temporarily and assign the Debug programs user right to a
separate Group Policy for that OU. The service account that is used for the cluster service
needs the Debug programs privilege; if it does not have it, Windows Clustering will fail. For
additional information about how to configure Windows Clustering in conjunction with
computer hardening, see article 891597, How to apply more restrictive security settings on
a Windows Server 2003based cluster server, in the Microsoft Knowledge Base
(http-//go.microsoft.com/fwlink/?LinkId=100746). Tools that are used to manage
processes will be unable to affect processes that are not owned by the person who runs the
tools. For example, the Windows Server 2003 Resource Kit tool Kill.exe requires this user
right for administrators to terminate processes that they did not start. Also, some older
versions of Update.exe (which is used to install Windows product updates) require the
account that applies the update to have this user right. If you install one of the patches that
uses this version of Update.exe, the computer could become unresponsive. For more
information, see article 830846, Windows Product Updates may stop responding or may
use most or all the CPU resources, in the Microsoft Knowledge Base
(http-//go.microsoft.com/fwlink/?LinkId=100747).
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,CCE|CCE-8583-7"
value_type : USER_RIGHT
value_data : "Administrators"
right_type : SeDebugPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.5 Set 'Change the system time'"
info :"Set 'Change the system time' to 'LOCAL SERVICE, Administrators' (Scored)
This policy setting determines which users and groups can change the time and date on the
internal clock of the computers in your environment. Users who are assigned this user right
can affect the appearance of event logs. When a computer's time setting is changed, logged
events reflect the new time, not the actual time that the events occurred. When configuring
a user right in the SCM enter a comma delimited list of accounts. Accounts can be either
local or located in Active Directory, they can be groups, users, or computers. Note-
Discrepancies between the time on the local computer and on the domain controllers in
your environment may cause problems for the Kerberos authentication protocol, which
could make it impossible for users to log on to the domain or obtain authorization to access
domain resources after they are logged on. Also, problems will occur when Group Policy is
applied to client computers if the system time is not synchronized with the domain
controllers.
*Rationale*
Users who can change the time on a computer could cause several problems. For example,
time stamps on event log entries could be made inaccurate, time stamps on files and folders
that are created or modified could be incorrect, and computers that belong to a domain
may not be able to authenticate themselves or users who try to log on to the domain from
them. Also, because the Kerberos authentication protocol requires that the requestor and
authenticator have their clocks synchronized within an administrator-defined skew period,
an attacker who changes a computer's time may cause that computer to be unable to obtain
or grant Kerberos tickets. The risk from these types of events is mitigated on most domain
controllers, member servers, and end-user computers because the Windows Time service
automatically synchronizes time with domain controllers in the following ways- . All client
desktop computers and member servers use the authenticating domain controller as their
inbound time partner. . All domain controllers in a domain nominate the primary domain
controller (PDC) emulator operations master as their inbound time partner. . All PDC
emulator operations masters follow the hierarchy of domains in the selection of their
inbound time partner. . The PDC emulator operations master at the root of the domain is
authoritative for the organization. Therefore it is recommended that you configure this
computer to synchronize with a reliable external time server. This vulnerability becomes
much more serious if an attacker is able to change the system time and then stop the
Windows Time service or reconfigure it to synchronize with a time server that is not
accurate."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to LOCAL SERVICE, Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Change the system time
Impact-
There should be no impact, because time synchronization for most organizations should be
fully automated for all computers that belong to the domain. Computers that do not belong
to the domain should be configured to synchronize with an external source.
Default Value-LOCAL SERVICE, Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-8,CSF|PR.IP-1,800-53|CM-7,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,CSF|PR.PT-3,PCI|7.2.1,CCE|CCE-8612-4,SANS-CSC|16,PCI|7.2.2,Level|1S,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators" && "LOCAL SERVICE"
right_type : SeSystemTimePrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.6 Set 'Increase scheduling priority'"
info :"Set 'Increase scheduling priority' to 'Administrators' (Scored)
This policy setting determines whether users can increase the base priority class of a
process. (It is not a privileged operation to increase relative priority within a priority
class.) This user right is not required by administrative tools that are supplied with the
operating system but might be required by software development tools. When configuring
a user right in the SCM enter a comma delimited list of accounts. Accounts can be either
local or located in Active Directory, they can be groups, users, or computers.
*Rationale*
A user who is assigned this user right could increase the scheduling priority of a process to
Real-Time, which would leave little processing time for all other processes and could lead
to a DoS condition."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Increase scheduling priority
Impact-None. This is the default configuration.
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,CCE|CCE-8999-5,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators"
right_type : SeIncreaseBasePriorityPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.7 Set 'Bypass traverse checking'"
info :"Set 'Bypass traverse checking' to 'Users, NETWORK SERVICE, LOCAL SERVICE, Administrators' (Scored)
This policy setting allows users who do not have the Traverse Folder access permission to
pass through folders when they browse an object path in the NTFS file system or the
registry. This user right does not allow users to list the contents of a folder. When
configuring a user right in the SCM enter a comma delimited list of accounts. Accounts can
be either local or located in Active Directory, they can be groups, users, or computers.
*Rationale*
The default configuration for the Bypass traverse checking setting is to allow all users,
including the Everyone group, to bypass traverse checking. Permissions to files and folders
are controlled though appropriate configuration of file system access control lists (ACLs),
as the ability to traverse the folder does not provide any read or write permissions to the
user. The only scenario in which the default configuration could lead to a mishap would be
if the administrator who configures permissions does not understand how this policy
setting works. For example, the administrator might expect that users who are unable to
access a folder will be unable to access the contents of any child folders. Such a situation is
unlikely, and therefore this vulnerability presents little risk."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Users, NETWORK SERVICE, LOCAL SERVICE, Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Bypass traverse checking
Impact-The Windows operating systems, as well as many applications, were designed with the
expectation that anyone who can legitimately access the computer will have this user right.
Therefore, we recommend that you thoroughly test any changes to assignments of the
Bypass traverse checking user right before you make such changes to production systems.
In particular, IIS requires this user right to be assigned to the Network Service, Local
Service, IIS_WPG, IUSR_, and IWAM_ accounts. (It must
also be assigned to the ASPNET account through its membership in the Users group.) We
recommend that you leave this policy setting at its default configuration.
Default Value-Everyone, Administrators, Users, Backup Operators, Local Service, Network Service"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,PCI|7.2.1,800-53|CM-6,PCI|7.2.2,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,CCE|CCE-8414-5"
value_type : USER_RIGHT
value_data : "Administrators" && "Users" && "Local Service" && "Network Service"
right_type : SeChangeNotifyPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.8 Set 'Remove computer from docking station'"
info :"Set 'Remove computer from docking station' to 'Administrators, Users' (Scored)
This policy setting allows the user of a portable computer to click Eject PC on the Start
menu to undock the computer. When configuring a user right in the SCM enter a comma
delimited list of accounts. Accounts can be either local or located in Active Directory, they
can be groups, users, or computers.
*Rationale*
Anyone who has the Remove computer from docking station user right can log on and then
remove a portable computer from its docking station. If this setting is not defined, it has the
same effect as if everyone was granted this right. However, the value of implementing this
countermeasure is reduced by the following factors- . If attackers can restart the computer,
they could remove it from the docking station after the BIOS starts but before the operating
system starts. . This setting does not affect servers, because they typically are not installed
in docking stations. . An attacker could steal the computer and the docking station together."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators, Users.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Remove computer from docking station
Impact-By default, only members of the local Administrator group are granted this right. Other
user accounts must be explicitly granted the right as necessary. If your organization's users
are not members of the local Administrators groups on their portable computers, they will
be unable to remove their own portable computers from their docking stations without
shutting them down first. Therefore, you may want to assign the Remove computer from
docking station privilege to the local Users group for portable computers.
Default Value-Administrators, Users"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|7.1.3,PCI|7.1.2,PCI|7.2.1,PCI|7.2.2,800-53|PE-3,Level|1S,CCE|CCE-9326-0"
value_type : USER_RIGHT
value_data : "Administrators" && "Users"
right_type : SeUndockPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.9 Set 'Change the time zone'"
info :"Set 'Change the time zone' to 'LOCAL SERVICE, Administrators, Users' (Scored)
This setting determines which users can change the time zone of the computer. This ability
holds no great danger for the computer and may be useful for mobile workers. When
configuring a user right in the SCM enter a comma delimited list of accounts. Accounts can
be either local or located in Active Directory, they can be groups, users, or computers.
*Rationale*
Changing the time zone represents little vulnerability because the system time is not
affected. This setting merely enables users to display their preferred time zone while being
synchronized with domain controllers in different time zones."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to LOCAL SERVICE, Administrators, Users.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Change the time zone
Impact-None. This is the default configuration.
Default Value-LOCAL SERVICE, Administrators, Users"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-8,800-53|CM-7,CCE|CCE-8423-6,Level|1S"
value_type : USER_RIGHT
value_data : "Administrators" && "Users" && "LOCAL SERVICE"
right_type : SeTimeZonePrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.10 Set 'Take ownership of files or other objects'"
info :"Set 'Take ownership of files or other objects' to 'Administrators' (Scored)
This policy setting allows users to take ownership of files, folders, registry keys, processes,
or threads. This user right bypasses any permissions that are in place to protect objects to
give ownership to the specified user. When configuring a user right in the SCM enter a
comma delimited list of accounts. Accounts can be either local or located in Active
Directory, they can be groups, users, or computers.
*Rationale*
Any users with the Take ownership of files or other objects user right can take control of
any object, regardless of the permissions on that object, and then make any changes they
wish to that object. Such changes could result in exposure of data, corruption of data, or a
DoS condition."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Take ownership of files or other objects
Impact-None. This is the default configuration.
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-9309-6,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators"
right_type : SeTakeOwnershipPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.13 Set 'Replace a process level token'"
info :"Set 'Replace a process level token' to 'Local Service, Network Service' (Scored)
This policy setting allows one process or service to start another service or process with a
different security access token, which can be used to modify the security access token of
that sub-process and result in the escalation of privileges. When configuring a user right in
the SCM enter a comma delimited list of accounts. Accounts can be either local or located in
Active Directory, they can be groups, users, or computers.
*Rationale*
User with the Replace a process level token privilege are able to start processes as other
users whose credentials they know. They could use this method to hide their unauthorized
actions on the computer. (On Windows 2000-based computers, use of the Replace a
process level token user right also requires the user to have the Adjust memory quotas for
a process user right that is discussed earlier in this section.)"
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Local Service, Network Service.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Replace a process level token
Impact-On most computers, this is the default configuration and there will be no negative impact.
However, if you have installed optional components such as ASP.NET or IIS, you may need
to assign the Replace a process level token privilege to additional accounts. For example,
IIS requires that the Service, Network Service, and IWAM_ accounts be
explicitly granted this user right.
Default Value-LOCAL SERVICE, NETWORK SERVICE"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|CM-7,CCE|CCE-8732-0,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "LOCAL SERVICE" && "NETWORK SERVICE"
right_type : SeAssignPrimaryTokenPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.14 Set 'Modify firmware environment values'"
info :"Set 'Modify firmware environment values' to 'Administrators' (Scored)
This policy setting allows users to configure the system-wide environment variables that
affect hardware configuration. This information is typically stored in the Last Known Good
Configuration. Modification of these values and could lead to a hardware failure that would
result in a denial of service condition. When configuring a user right in the SCM enter a
comma delimited list of accounts. Accounts can be either local or located in Active
Directory, they can be groups, users, or computers.
*Rationale*
Anyone who is assigned the Modify firmware environment values user right could
configure the settings of a hardware component to cause it to fail, which could lead to data
corruption or a DoS condition."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Modify firmware environment values
Impact-None. This is the default configuration.
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,CCE|CCE-9417-7,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,800-53|CM-3"
value_type : USER_RIGHT
right_type : SeSystemEnvironmentPrivilege
value_data : "Administrators"
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.17 Set 'Create a pagefile' to 'Administrators' (Scored)"
info :"This policy setting allows users to change the size of the pagefile. By making the pagefile
extremely large or extremely small, an attacker could easily affect the performance of a
compromised computer. When configuring a user right in the SCM enter a comma
delimited list of accounts. Accounts can be either local or located in Active Directory, they
can be groups, users, or computers.
*Rationale*
Users who can change the page file size could make it extremely small or move the file to a
highly fragmented storage volume, which could cause reduced computer performance."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Create a pagefile
Impact-None. This is the default configuration.
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CCE|CCE-9185-0,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators"
right_type : SeCreatePagefilePrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.20 Set 'Adjust memory quotas for a process'"
info :"Set 'Adjust memory quotas for a process' to 'Administrators, Local Service, Network Service' (Scored)
This policy setting allows a user to adjust the maximum amount of memory that is available
to a process. The ability to adjust memory quotas is useful for system tuning, but it can be
abused. In the wrong hands, it could be used to launch a denial of service (DoS) attack.
When configuring a user right in the SCM enter a comma delimited list of accounts.
Accounts can be either local or located in Active Directory, they can be groups, users, or
computers.
*Rationale*
A user with the Adjust memory quotas for a process privilege can reduce the amount of
memory that is available to any process, which could cause business-critical network
applications to become slow or to fail. In the wrong hands, this privilege could be used to
start a denial of service (DoS) attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators, Local Service, Network Service.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Adjust memory quotas for a process
Impact-Organizations that have not restricted users to roles with limited privileges will find it
difficult to impose this countermeasure. Also, if you have installed optional components
such as ASP.NET or IIS, you may need to assign the Adjust memory quotas for a process
user right to additional accounts that are required by those components. IIS requires that
this privilege be explicitly assigned to the IWAM_, Network Service, and
Service accounts. Otherwise, this countermeasure should have no impact on most
computers. If this user right is necessary for a user account, it can be assigned to a local
computer account instead of a domain account.
Default Value-LOCAL SERVICE, NETWORK SERVICE, Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.AC-1,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,CCE|CCE-9068-8"
value_type : USER_RIGHT
value_data : "LOCAL SERVICE" && "NETWORK SERVICE" && "Administrators"
right_type : SeIncreaseQuotaPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.21 Set 'Generate security audits'"
info :"Set 'Generate security audits' to 'Local Service, Network Service' (Scored)
This policy setting determines which users or processes can generate audit records in the
Security log. When configuring a user right in the SCM enter a comma delimited list of
accounts. Accounts can be either local or located in Active Directory, they can be groups,
users, or computers.
*Rationale*
An attacker could use this capability to create a large number of audited events, which
would make it more difficult for a system administrator to locate any illicit activity. Also, if
the event log is configured to overwrite events as needed, any evidence of unauthorized
activities could be overwritten by a large number of unrelated events."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Local Service, Network Service.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Generate security audits
Impact-None. This is the default configuration.
Default Value-Local Service, Network Service"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|AU-2,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,CCE|CCE-9226-2,Level|1S,800-53|AU-9,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Local Service" && "Network Service"
right_type : SeAuditPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.22 Set 'Force shutdown from a remote system'"
info :"Set 'Force shutdown from a remote system' to 'Administrators' (Scored)
This policy setting allows users to shut down Windows Vista based computers from remote
locations on the network. Anyone who has been assigned this user right can cause a denial
of service (DoS) condition, which would make the computer unavailable to service user
requests. Therefore, it is recommended that only highly trusted administrators be assigned
this user right. When configuring a user right in the SCM enter a comma delimited list of
accounts. Accounts can be either local or located in Active Directory, they can be groups,
users, or computers.
*Rationale*
Any user who can shut down a computer could cause a DoS condition to occur. Therefore,
this user right should be tightly restricted."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Force shutdown from a remote system
Impact-If you remove the Force shutdown from a remote system user right from the Server
Operator group you could limit the abilities of users who are assigned to specific
administrative roles in your environment. You should confirm that delegated activities will
not be adversely affected.
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9336-9,PCI|7.1.3,PCI|7.1.2,PCI|7.2.1,PCI|7.2.2,Level|1S,800-53|AC-1"
value_type : USER_RIGHT
value_data : "Administrators"
right_type : SeRemoteShutdownPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.23 Set 'Deny access to this computer from the network'"
info :"Set 'Deny access to this computer from the network' to 'Guests' (Scored)
This policy setting prohibits users from connecting to a computer from across the network,
which would allow users to access and potentially modify data remotely. In high security
environments, there should be no need for remote users to access data on a computer.
Instead, file sharing should be accomplished through the use of network servers. When
configuring a user right in the SCM enter a comma delimited list of accounts. Accounts can
be either local or located in Active Directory, they can be groups, users, or computers.
*Rationale*
Users who can log on to the computer over the network can enumerate lists of account
names, group names, and shared resources. Users with permission to access shared folders
and files can connect over the network and possibly view or modify data."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Guests.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Deny access to this computer from the network
Impact-If you configure the Deny access to this computer from the network user right for other
groups, you could limit the abilities of users who are assigned to specific administrative
roles in your environment. You should verify that delegated tasks will not be negatively
affected.
Default Value-Guest"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-9244-5,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,800-53|IA-2"
value_type : USER_RIGHT
value_data : "Guests"
right_type : SeDenyNetworkLogonRight
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.24 Set 'Impersonate a client after authentication'"
info :"Set 'Impersonate a client after authentication' to 'Administrators, SERVICE, Local Service, Network Service' (Scored)
The policy setting allows programs that run on behalf of a user to impersonate that user (or
another specified account) so that they can act on behalf of the user. If this user right is
required for this kind of impersonation, an unauthorized user will not be able to convince a
client to connect - for example, by remote procedure call (RPC) or named pipes - to a
service that they have created to impersonate that client, which could elevate the
unauthorized user's permissions to administrative or system levels. Services that are
started by the Service Control Manager have the built-in Service group added by default to
their access tokens. COM servers that are started by the COM infrastructure and configured
to run under a specific account also have the Service group added to their access tokens. As
a result, these processes are assigned this user right when they are started. Also, a user can
impersonate an access token if any of the following conditions exist- . The access token that
is being impersonated is for this user. . The user, in this logon session, logged on to the
network with explicit credentials to create the access token. . The requested level is less
than Impersonate, such as Anonymous or Identify. An attacker with the Impersonate a
client after authentication user right could create a service, trick a client to make them
connect to the service, and then impersonate that client to elevate the attacker's level of
access to that of the client. When configuring a user right in the SCM enter a comma
delimited list of accounts. Accounts can be either local or located in Active Directory, they
can be groups, users, or computers.
*Rationale*
An attacker with the Impersonate a client after authentication user right could create a
service, trick a client to make them connect to the service, and then impersonate that client
to elevate the attacker's level of access to that of the client."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators, SERVICE, Local Service, Network Service.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Impersonate a client after authentication
Impact-In most cases this configuration will have no impact. If you have installed optional
components such as ASP.NET or IIS, you may need to assign the Impersonate a client after
authentication user right to additional accounts that are required by those components,
such as IUSR_, IIS_WPG, ASP.NET or IWAM_.
Default Value-Administrators, SERVICE, Local Service, Network Service"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-8467-3,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,PCI|7.2.1,800-53|CM-6,PCI|7.2.2,SANS-CSC|16,800-53|AC-3,Level|1S,800-53|AC-2,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators" && "SERVICE" && "LOCAL SERVICE" && "NETWORK SERVICE"
right_type : SeImpersonatePrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.25 Set 'Create global objects'"
info :"Set 'Create global objects' to 'Administrators, SERVICE, LOCAL SERVICE, NETWORK SERVICE' (Scored)
This policy setting determines whether users can create global objects that are available to
all sessions. Users can still create objects that are specific to their own session if they do not
have this user right. Users who can create global objects could affect processes that run
under other users' sessions. This capability could lead to a variety of problems, such as
application failure or data corruption. When configuring a user right in the SCM enter a
comma delimited list of accounts. Accounts can be either local or located in Active
Directory, they can be groups, users, or computers.
*Rationale*
Users who can create global objects could affect Windows services and processes that run
under other user or system accounts. This capability could lead to a variety of problems,
such as application failure, data corruption and elevation of privilege."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators, SERVICE, LOCAL SERVICE, NETWORK SERVICE.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Create global objects
Impact-None. This is the default configuration.
Default Value-Administrators, SERVICE, Local Service, Network Service"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"PCI|7.1.3,CCE|CCE-8431-9,PCI|7.1.2,CSF|PR.AC-1,PCI|7.2.1,800-53|CM-6,PCI|7.2.2,SANS-CSC|16,800-53|AC-3,Level|1NS,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators" && "SERVICE" && "Local Service" && "Network Service"
right_type : SeCreateGlobalPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.26 Set 'Perform volume maintenance tasks'"
info :"Set 'Perform volume maintenance tasks' to 'Administrators' (Scored)
This policy setting allows users to manage the system's volume or disk configuration,
which could allow a user to delete a volume and cause data loss as well as a denial-of-
service condition. When configuring a user right in the SCM enter a comma delimited list of
accounts. Accounts can be either local or located in Active Directory, they can be groups,
users, or computers.
*Rationale*
A user who is assigned the Perform volume maintenance tasks user right could delete a
volume, which could result in the loss of data or a DoS condition."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Perform volume maintenance tasks
Impact-None. This is the default configuration.
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|CP-9,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,CCE|CCE-8475-6"
value_type : USER_RIGHT
value_data : "Administrators"
right_type : SeManageVolumePrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.27 Set 'Lock pages in memory' to 'No One' (Scored)"
info :"This policy setting allows a process to keep data in physical memory, which prevents the
system from paging the data to virtual memory on disk. If this user right is assigned,
significant degradation of system performance can occur. When configuring a user right in
the SCM enter a comma delimited list of accounts. Accounts can be either local or located in
Active Directory, they can be groups, users, or computers.
*Rationale*
Users with the Lock pages in memory user right could assign physical memory to several
processes, which could leave little or no RAM for other processes and result in a DoS
condition."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No One.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Lock pages in memory
Impact-None. This is the default configuration.
Default Value-No one"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-9289-0,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,800-53|SI-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : ""
right_type : SeLockMemoryPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.28 Set 'Manage auditing and security log'"
info :"Set 'Manage auditing and security log' to 'Administrators' (Scored)
This policy setting determines which users can change the auditing options for files and
directories and clear the Security log. When configuring a user right in the SCM enter a
comma delimited list of accounts. Accounts can be either local or located in Active
Directory, they can be groups, users, or computers.
*Rationale*
The ability to manage the Security event log is a powerful user right and it should be closely
guarded. Anyone with this user right can clear the Security log to erase important evidence
of unauthorized activity."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Manage auditing and security log
Impact-None. This is the default configuration.
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|AU-2,CCE|CCE-9223-9,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators"
right_type : SeSecurityPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.29 Set 'Access Credential Manager..'"
info :"Set 'Access Credential Manager as a trusted caller' to 'No One' (Scored)
This security setting is used by Credential Manager during Backup and Restore. No
accounts should have this user right, as it is only assigned to Winlogon. Users' saved
credentials might be compromised if this user right is assigned to other entities. When
configuring a user right in the SCM enter a comma delimited list of accounts. Accounts can
be either local or located in Active Directory, they can be groups, users, or computers.
*Rationale*
If an account is given this right the user of the account may create an application that calls
into Credential Manager and is returned the credentials for another user."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No One.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Access Credential Manager as a trusted caller
Impact-None, this is the default configuration
Default Value-No One"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|7.1.2,CCE|CCE-9380-7,PCI|7.2.1,PCI|7.2.2,800-53|AC-3,Level|1S"
value_type : USER_RIGHT
value_data : ""
right_type : SeTrustedCredManAccessPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.31 Set 'Load and unload device drivers' to 'Administrators' (Scored)"
info :"This policy setting allows users to dynamically load a new device driver on a system. An
attacker could potentially use this capability to install malicious code that appears to be a
device driver. This user right is required for users to add local printers or printer drivers in
Windows Vista. When configuring a user right in the SCM enter a comma delimited list of
accounts. Accounts can be either local or located in Active Directory, they can be groups,
users, or computers.
*Rationale*
Device drivers run as highly privileged code. A user who has the Load and unload device
drivers user right could unintentionally install malicious code that masquerades as a device
driver. Administrators should exercise greater care and install only drivers with verified
digital signatures."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Load and unload device drivers
Impact-If you remove the Load and unload device drivers user right from the Print Operators
group or other accounts you could limit the abilities of users who are assigned to specific
administrative roles in your environment. You should ensure that delegated tasks will not
be negatively affected.
Default Value-Administrators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"800-53|CM-5,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,CCE|CCE-9135-5"
value_type : USER_RIGHT
value_data : "Administrators"
right_type : SeLoadDriverPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.32 Set 'Deny log on locally' to 'Guests' (Scored)"
info :"This security setting determines which users are prevented from logging on at the
computer. This policy setting supersedes the Allow log on locally policy setting if an
account is subject to both policies. Important- If you apply this security policy to the
Everyone group, no one will be able to log on locally. When configuring a user right in the
SCM enter a comma delimited list of accounts. Accounts can be either local or located in
Active Directory, they can be groups, users, or computers.
*Rationale*
Any account with the ability to log on locally could be used to log on at the console of the
computer. If this user right is not restricted to legitimate users who need to log on to the
console of the computer, unauthorized users might download and run malicious software
that elevates their privileges."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Guests.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Deny log on locally
Impact-If you assign the Deny log on locally user right to additional accounts, you could limit the
abilities of users who are assigned to specific roles in your environment. However, this user
right should explicitly be assigned to the ASPNET account on computers that run IIS 6.0.
You should confirm that delegated activities will not be adversely affected.
Default Value-Guest"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-9239-5,PCI|7.1.2,CSF|PR.AC-1,PCI|7.2.1,800-53|CM-6,PCI|7.2.2,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,800-53|IA-2"
value_type : USER_RIGHT
value_data : "Guests"
right_type : SeDenyInteractiveLogonRight
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.33 Set 'Access this computer from the network'"
info :"Set 'Access this computer from the network' to 'Users, Administrators' (Scored)
This policy setting allows other users on the network to connect to the computer and is
required by various network protocols that include Server Message Block (SMB)based
protocols, NetBIOS, Common Internet obÌåÓý System (CIFS), and Component Object Model
Plus (COM+). When configuring a user right in the SCM enter a comma delimited list of
accounts. Accounts can be either local or located in Active Directory, they can be groups,
users, or computers.
*Rationale*
Users who can connect from their computer to the network can access resources on target
computers for which they have permission. For example, the Access this computer from the
network user right is required for users to connect to shared printers and folders. If this
user right is assigned to the Everyone group, then anyone in the group will be able to read
the files in those shared folders. However, this situation is unlikely for new installations of
Windows Server® 2003 with Service Pack 1 (SP1), because the default share and NTFS
permissions in Windows Server 2003 do not include the Everyone group. This vulnerability
may have a higher level of risk for computers that you upgrade from Windows NT® 4.0 or
Windows 2000, because the default permissions for these operating systems are not as
restrictive as the default permissions in Windows Server 2003."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Users, Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Access this computer from the network
Impact-If you remove the Access this computer from the network user right on domain controllers
for all users, no one will be able to log on to the domain or use network resources. If you
remove this user right on member servers, users will not be able to connect to those
servers through the network. Successful negotiation of IPsec connections requires that the
initiating machine has this right, therefor it is recommended that it is assigned to the Users
group. If you have installed optional components such as ASP.NET or Internet Information
Services (IIS), you may need to assign this user right to additional accounts that are
required by those components. It is important to verify that authorized users are assigned
this user right for the computers they need to access the network.
Default Value-Everyone, Administrators, Users, Backup Operators"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-9253-6,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,PCI|7.2.1,800-53|CM-6,PCI|7.2.2,SANS-CSC|16,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Users" && "Administrators"
right_type : SeNetworkLogonRight
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.34 Set 'Deny log on as a batch job' to 'Guests' (Scored)"
info :"This policy setting determines which accounts will not be able to log on to the computer as
a batch job. A batch job is not a batch (.bat) file, but rather a batch-queue facility. Accounts
that use the Task Scheduler to schedule jobs need this user right. The Deny log on as a
batch job user right overrides the Log on as a batch job user right, which could be used to
allow accounts to schedule jobs that consume excessive system resources. Such an
occurrence could cause a DoS condition. Failure to assign this user right to the
recommended accounts can be a security risk. When configuring a user right in the SCM
enter a comma delimited list of accounts. Accounts can be either local or located in Active
Directory, they can be groups, users, or computers.
*Rationale*
Accounts that have the Deny log on as a batch job user right could be used to schedule jobs
that could consume excessive computer resources and cause a DoS condition."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Guests.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Deny log on as a batch job
Impact-If you assign the Deny log on as a batch job user right to other accounts, you could deny
users who are assigned to specific administrative roles the ability to perform their required
job activities. You should confirm that delegated tasks will not be affected adversely. For
example, if you assign this user right to the IWAM_ account, the MSM
Management Point will fail. On a newly installed computer that runs Windows Server 2003
this account does not belong to the Guests group, but on a computer that was upgraded
from Windows 2000 this account is a member of the Guests group. Therefore, it is
important that you understand which accounts belong to any groups that you assign the
Deny log on as a batch job user right.
Default Value-No One"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.AC-1,800-53|CM-6,SANS-CSC|16,800-53|AC-3,Level|1S,CCE|CCE-9212-2,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Guests"
right_type : SeDenyBatchLogonRight
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.35 Set 'Act as part of the operating system' to 'No One' (Scored)"
info :"This policy setting allows a process to assume the identity of any user and thus gain access
to the resources that the user is authorized to access. When configuring a user right in the
SCM enter a comma delimited list of accounts. Accounts can be either local or located in
Active Directory, they can be groups, users, or computers.
*Rationale*
The Act as part of the operating system user right is extremely powerful. Anyone with this
user right can take complete control of the computer and erase evidence of their activities."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No One.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Act as part of the operating system
Impact-There should be little or no impact because the Act as part of the operating system user
right is rarely needed by any accounts other than the Local System account.
Default Value-No one"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"PCI|7.1.2,CSF|PR.AC-1,CCE|CCE-9407-8,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1,800-53|IA-2,800-53|AC-1"
value_type : USER_RIGHT
value_data : ""
right_type : SeTcbPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.37 Set 'Enable computer and user accounts to be trusted for delegation'"
info :"Set 'Enable computer and user accounts to be trusted for delegation' to 'No One' (Scored)
This policy setting allows users to change the Trusted for Delegation setting on a computer
object in Active Directory. Abuse of this privilege could allow unauthorized users to
impersonate other users on the network. When configuring a user right in the SCM enter a
comma delimited list of accounts. Accounts can be either local or located in Active
Directory, they can be groups, users, or computers.
*Rationale*
Misuse of the Enable computer and user accounts to be trusted for delegation user right
could allow unauthorized users to impersonate other users on the network. An attacker
could exploit this privilege to gain access to network resources and make it difficult to
determine what has happened after a security incident."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No One.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Enable computer and user accounts to be trusted for delegation
Impact-None. This is the default configuration.
Default Value-No One"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"PCI|7.1.2,CSF|PR.AC-1,PCI|7.2.1,800-53|CM-6,PCI|7.2.2,SANS-CSC|16,800-53|AC-3,CCE|CCE-8930-0,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : ""
right_type : SeEnableDelegationPrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.38 Set 'Profile system performance'"
info :"Set 'Profile system performance' to 'NT SERVICE\WdiServiceHost,Administrators' (Scored)
This policy setting allows users to use tools to view the performance of different system
processes, which could be abused to allow attackers to determine a system's active
processes and provide insight into the potential attack surface of the computer. When
configuring a user right in the SCM enter a comma delimited list of accounts. Accounts can
be either local or located in Active Directory, they can be groups, users, or computers.
*Rationale*
The Profile system performance user right poses a moderate vulnerability. Attackers with
this user right could monitor a computer's performance to help identify critical processes
that they might wish to attack directly. Attackers may also be able to determine what
processes are active on the computer so that they could identify countermeasures that they
may need to avoid, such as antivirus software or an intrusion detection system."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to NT SERVICE\WdiServiceHost,Administrators.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Profile system performance
Impact-None. This is the default configuration.
Default Value-Administrators,NT SERVICE\WdiServiceHost"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CCE|CCE-9419-3,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
value_data : "Administrators" && "WdiServiceHost"
right_type : SeSystemProfilePrivilege
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.39 Set 'Shut down the system'"
info :"Set 'Shut down the system' to 'Administrators, Users' (Scored)
This policy setting determines which users who are logged on locally to the computers in
your environment can shut down the operating system with the Shut Down command.
Misuse of this user right can result in a denial of service condition. When configuring a user
right in the SCM enter a comma delimited list of accounts. Accounts can be either local or
located in Active Directory, they can be groups, users, or computers.
*Rationale*
The ability to shut down domain controllers should be limited to a very small number of
trusted administrators. Although the Shut down the system user right requires the ability
to log on to the server, you should be very careful about which accounts and groups you
allow to shut down a domain controller. When a domain controller is shut down, it is no
longer available to process logons, serve Group Policy, and answer Lightweight Directory
Access Protocol (LDAP) queries. If you shut down domain controllers that possess Flexible
SingleMaster Operations (FSMO) roles, you can disable key domain functionality, such as
processing logons for new passwords - the Primary Domain Controller (PDC) Emulator
role."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators, Users.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Shut down the system
Impact-The impact of removing these default groups from the Shut down the system user right
could limit the delegated abilities of assigned roles in your environment. You should
confirm that delegated activities will not be adversely affected.
Default Value-Administrators, Backup Operators, Users"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference :"CSF|PR.IP-1,800-53|CM-7,CCE|CCE-9014-2,PCI|7.1.3,PCI|7.1.2,CSF|PR.AC-1,CSF|PR.PT-3,800-53|CM-6,PCI|7.2.1,SANS-CSC|16,PCI|7.2.2,800-53|AC-3,Level|1S,CSF|PR.AC-4,CSF|DE.CM-1"
value_type : USER_RIGHT
right_type : SeShutdownPrivilege
value_data : "Users" && "Administrators"
type : USER_RIGHTS_POLICY
description :"1.2.1.1.2.40 Set 'Increase a process working set'"
info :"Set 'Increase a process working set' to 'Administrators, Local Service' (Scored)
This privilege determines which user accounts can increase or decrease the size of a
process's working set. The working set of a process is the set of memory pages currently
visible to the process in physical RAM memory. These pages are resident and available for
an application to use without triggering a page fault. The minimum and maximum working
set sizes affect the virtual memory paging behavior of a process. When configuring a user
right in the SCM enter a comma delimited list of accounts. Accounts can be either local or
located in Active Directory, they can be groups, users, or computers.
*Rationale*
This right is granted to all users by default. However, increasing the working set size for a
process decreases the amount of physical memory available to the rest of the system. It
would be possible for malicious code to increase the process working set to a level that
could severely degrade system performance and potentially cause a denial of service."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Administrators, Local Service.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Increase a process working set
Impact-Users will be unable to increase the working set for their processes, which could degrade
performance.
Default Value-Users"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|7.1.2,PCI|7.2.1,800-53|CM-6,PCI|7.2.2,800-53|AC-3,CCE|CCE-9048-0,Level|1S"
value_type : USER_RIGHT
right_type : SeIncreaseWorkingSetPrivilege
value_data : "Local Service" && "Administrators"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.1.1 Set 'Audit Policy: System: System Integrity'"
info :"Set 'Audit Policy: System: System Integrity' to 'Success and Failure' (Scored)
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. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit- Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures in order to fill the Security log and force the computer to shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an attacker can overwrite part or all of their activity by generating large numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\System\Audit Policy- System- 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.
Default Value-Success and Failure"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,PCI|10.2,CCE|CCE-9520-8,Level|1S"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "System Integrity"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.1.2 Set 'Audit Policy: System: Security System Extension'"
info :"Set 'Audit Policy: System: Security System Extension' to 'Success and Failure' (Scored)
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. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures in order to fill the Security log and force the computer to shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an attacker can overwrite part or all of their activity by generating large numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\System\Audit Policy- System- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,PCI|10.2,CCE|CCE-9863-2,Level|1S"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "Security System Extension"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.1.3 Set 'Audit Policy: System: Security State Change'"
info :"Set 'Audit Policy: System: Security State Change' to 'Success and Failure' (Scored)
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 auditable activity might not have been recorded. Refer
to the Microsoft Knowledgebase article Description of security events in Windows Vista
and in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures in order to fill the Security log and force the computer to shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an attacker can overwrite part or all of their activity by generating large numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\System\Audit Policy- System- 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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,PCI|10.2,Level|1S,CCE|CCE-9850-9"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "Security State Change"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.1.4 Set 'Audit Policy: System: IPsec Driver'"
info :"Set 'Audit Policy: System: IPsec Driver' to 'Success and Failure' (Scored)
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. Refer to
the Microsoft Knowledgebase article Description of security events in Windows Vista and
in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in the Security Options section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures in order to fill the Security log and force the computer to shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an attacker can overwrite part or all of their activity by generating large numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\System\Audit Policy- System- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,PCI|10.2,Level|1S,CCE|CCE-9925-9"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "IPsec Driver"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.1.5 Set 'Audit Policy: System: Other System Events'"
info :"Set 'Audit Policy: System: Other System Events' to 'No Auditing' (Scored)
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. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in the Security Options
section of Group Policy is enabled, an attacker could generate millions of failure events such as logon failures in order
to fill the Security log and force the computer to shut down, creating a Denial of Service. If security logs are allowed to
be overwritten, an attacker can overwrite part or all of their activity by generating large numbers of events so that the
evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\System\Audit Policy- System- 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.
Default Value-Success and Failure"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9586-9,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Other System Events"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.1 Set 'Audit Policy: Object Access: Handle Manipulation'"
info :"Set 'Audit Policy: Object Access: Handle Manipulation' to 'No Auditing' (Scored)
This subcategory reports when a handle to an object is opened or closed. Only objects with
SACLs cause these events to be generated, and only if the attempted handle operation
matches the SACL. Handle Manipulation events are only generated for object types where
the corresponding Object Access subcategory is enabled, for example obÌåÓý System or
Registry. Events for this subcategory include- 4656- A handle to an object was requested.
4658- The handle to an object was closed. 4690- An attempt was made to duplicate a
handle to an object. Refer to the Microsoft Knowledgebase article Description of security
events in Windows Vista and in Windows Server 2008 for the most recent information
about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in the
Security Options section of Group Policy is enabled, an attacker could generate millions of failure events
such as logon failures in order to fill the Security log and force the computer to shut down, creating a
Denial of Service. If security logs are allowed to be overwritten, an attacker can overwrite part or all of
their activity by generating large numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- Handle
Manipulation
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-9789-9"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Handle Manipulation"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.2 Set 'Audit Policy: Object Access: Other Object Access Events'"
info :"Set 'Audit Policy: Object Access: Other Object Access Events' to 'No Auditing' (Scored)
This subcategory reports other object access-related events such as Task Scheduler jobs
and COM+ objects. Events for this subcategory include- 4671- An application attempted to
access a blocked ordinal through the TBS. 4691- Indirect access to an object was requested.
4698- A scheduled task was created. 4699 - A scheduled task was deleted. 4700 - A
scheduled task was enabled. 4701- A scheduled task was disabled. 4702 - A scheduled task
was updated. 5888- An object in the COM+ Catalog was modified. 5889- An object was
deleted from the COM+ Catalog. 5890- An object was added to the COM+ Catalog. Refer to
the Microsoft Knowledgebase article Description of security events in Windows Vista and
in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an attacker
can overwrite part or all of their activity by generating large numbers of events so that the evidence
of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9455-7,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Other Object Access Events"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.3 Set 'Audit Policy: Object Access: obÌåÓý Share'"
info :"Set 'Audit Policy: Object Access: obÌåÓý Share' to 'No Auditing' (Scored)
This subcategory reports when a file share is accessed. By itself, this policy setting will not
cause auditing of any events. It determines whether to audit the event of a user who
accesses a file share object that has a specified system access control list (SACL), effectively
enabling auditing to take place. A SACL is comprised of access control entries (ACEs). Each
ACE contains three pieces of information- . The security principal (user, computer, or
group) to be audited. . The specific access type to be audited, called an access mask. . A flag
to indicate whether to audit failed access events, successful access events, or both. If you
configure the Audit object access setting to Success, an audit entry is generated each time
that a user successfully accesses an object with a specified SACL. If you configure this policy
setting to Failure, an audit entry is generated each time that a user fails in an attempt to
access an object with a specified SACL. Organizations should define only the actions they
want enabled when they configure SACLs. For example, you might want to enable the Write
and Append Data auditing setting on executable files to track when they are changed or
replaced, because computer viruses, worms, and Trojan horses typically target executable
files. Similarly, you might want to track when sensitive documents are accessed or changed.
Events for this subcategory include- 5140- A network share object was accessed. Refer to
the Microsoft Knowledgebase article Description of security events in Windows Vista and
in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in the
Security Options section of Group Policy is enabled, an attacker could generate millions of failure
events such as logon failures in order to fill the Security log and force the computer to shut down,
creating a Denial of Service. If security logs are allowed to be overwritten, an attacker can overwrite
part or all of their activity by generating large numbers of events so that the evidence of their
intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- obÌåÓý 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9376-5,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "obÌåÓý Share"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.4 Set 'Audit Policy: Object Access: obÌåÓý System'"
info :"Set 'Audit Policy: Object Access: obÌåÓý System' to 'No Auditing' (Scored)
This subcategory reports when file system objects are accessed. Only file system objects
with SACLs cause audit events to be generated, and only when they are accessed in a
manner matching their SACL. By itself, this policy setting will not cause auditing of any
events. It determines whether to audit the event of a user who accesses a file system object
that has a specified system access control list (SACL), effectively enabling auditing to take
place. A SACL is comprised of access control entries (ACEs). Each ACE contains three pieces
of information- . The security principal (user, computer, or group) to be audited. . The
specific access type to be audited, called an access mask. . A flag to indicate whether to
audit failed access events, successful access events, or both. If you configure the Audit
object access setting to Success, an audit entry is generated each time that a user
successfully accesses an object with a specified SACL. If you configure this policy setting to
Failure, an audit entry is generated each time that a user fails in an attempt to access an
object with a specified SACL. Organizations should define only the actions they want
enabled when they configure SACLs. For example, you might want to enable the Write and
Append Data auditing setting on executable files to track when they are changed or
replaced, because computer viruses, worms, and Trojan horses typically target executable
files. Similarly, you might want to track when sensitive documents are accessed or changed.
Events for this subcategory include- 4664- An attempt was made to create a hard link.
4985- The state of a transaction has changed. 5051- A file was virtualized. Refer to the
Microsoft Knowledgebase article Description of security events in Windows Vista and in
Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an attacker
can overwrite part or all of their activity by generating large numbers of events so that the
evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- obÌåÓý System
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,CCE|CCE-9217-1,PCI|10.2.4,PCI|10.3.3,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3,PCI|10.2.1"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "obÌåÓý System"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.5 Set 'Audit Policy: Object Access: SAM'"
info :"Set 'Audit Policy: Object Access: SAM' to 'No Auditing' (Scored)
This subcategory reports when SAM objects are accessed. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an
attacker can overwrite part or all of their activity by generating large numbers of events so
that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- SAM
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9856-6,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "SAM"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.6 Set 'Audit Policy: Object Access: Kernel Object'"
info :"Set 'Audit Policy: Object Access: Kernel Object' to 'No Auditing' (Scored)
This subcategory reports when kernel objects such as processes and mutexes are accessed.
Only kernel objects with SACLs cause audit events to be generated, and only when they are
accessed in a manner matching their SACL. Typically kernel objects are only given SACLs if
the AuditBaseObjects or AuditBaseDirectories auditing options are enabled. Refer to the
Microsoft Knowledgebase article Description of security events in Windows Vista and in
Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an attacker
can overwrite part or all of their activity by generating large numbers of events so that the
evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- Kernel Object
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9803-8,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Kernel Object"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.7 Set 'Audit Policy: Object Access: Filtering Platform Packet Drop'"
info :"Set 'Audit Policy: Object Access: Filtering Platform Packet Drop' to 'No Auditing' (Scored)
This subcategory reports when packets are dropped by Windows Filtering Platform (WFP).
These events can be very high in volume. Events for this subcategory include- 5152- The
Windows Filtering Platform blocked a packet. 5153- A more restrictive Windows Filtering
Platform filter has blocked a packet. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an
attacker can overwrite part or all of their activity by generating large numbers of events so
that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- Filtering
Platform Packet Drop
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-9133-0"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Filtering Platform Packet Drop"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.8 Set 'Audit Policy: Object Access: Registry'"
info :"Set 'Audit Policy: Object Access: Registry' to 'No Auditing' (Scored)
This subcategory reports when registry objects are accessed. Only registry objects with
SACLs cause audit events to be generated, and only when they are accessed in a manner
matching their SACL. By itself, this policy setting will not cause auditing of any events. It
determines whether to audit the event of a user who accesses a registry object that has a
specified system access control list (SACL), effectively enabling auditing to take place. A
SACL is comprised of access control entries (ACEs). Each ACE contains three pieces of
information- . The security principal (user, computer, or group) to be audited. . The specific
access type to be audited, called an access mask. . A flag to indicate whether to audit failed
access events, successful access events, or both. If you configure the Audit object access
setting to Success, an audit entry is generated each time that a user successfully accesses an
object with a specified SACL. If you configure this policy setting to Failure, an audit entry is
generated each time that a user fails in an attempt to access an object with a specified SACL.
Organizations should define only the actions they want enabled when they configure
SACLs. For example, you might want to enable the Write and Append Data auditing setting
on executable files to track when they are changed or replaced, because computer viruses,
worms, and Trojan horses typically target executable files. Similarly, you might want to
track when sensitive documents are accessed or changed. Events for this subcategory
include- 4657 - A registry value was modified. 5039- A registry key was virtualized. Refer to
the Microsoft Knowledgebase article Description of security events in Windows Vista and
in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an
attacker can overwrite part or all of their activity by generating large numbers of events so that
the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- Registry
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,CCE|CCE-9737-8,PCI|10.2.4,PCI|10.3.3,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3,PCI|10.2.1"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Registry"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.9 Set 'Audit Policy: Object Access: Certification Services'"
info :"Set 'Audit Policy: Object Access: Certification Services' to 'No Auditing' (Scored)
This subcategory reports when Certification Services operations are performed. Events for
this subcategory include- 4868- The certificate manager denied a pending certificate
request. 4869- Certificate Services received a resubmitted certificate request. 4870-
Certificate Services revoked a certificate. 4871- Certificate Services received a request to
publish the certificate revocation list (CRL). 4872- Certificate Services published the
certificate revocation list (CRL). 4873- A certificate request extension changed. 4874- One
or more certificate request attributes changed. 4875- Certificate Services received a
request to shut down. 4876- Certificate Services backup started. 4877- Certificate Services
backup completed. 4878- Certificate Services restore started. 4879- Certificate Services
restore completed. 4880- Certificate Services started. 4881- Certificate Services stopped.
4882 - The security permissions for Certificate Services changed. 4883- Certificate Services
retrieved an archived key. 4884- Certificate Services imported a certificate into its
database. 4885- The audit filter for Certificate Services changed. 4886- Certificate Services
received a certificate request. 4887- Certificate Services approved a certificate request and
issued a certificate. 4888- Certificate Services denied a certificate request. 4889- Certificate
Services set the status of a certificate request to pending. 4890- The certificate manager
settings for Certificate Services changed. 4891- A configuration entry changed in Certificate
Services. 4892- A property of Certificate Services changed. 4893- Certificate Services
archived a key. 4894- Certificate Services imported and archived a key. 4895- Certificate
Services published the CA certificate to Active Directory Domain Services. 4896- One or
more rows have been deleted from the certificate database. 4897- Role separation enabled-
4898- Certificate Services loaded a template. 4899- A Certificate Services template was
updated. 4900- Certificate Services template security was updated. 5120- OCSP Responder
Service Started. 5121- OCSP Responder Service Stopped. 5122- A Configuration entry
changed in the OCSP Responder Service. 5123- A configuration entry changed in the OCSP
Responder Service. 5124- A security setting was updated on OCSP Responder Service.
5125- A request was submitted to OCSP Responder Service. 5126- Signing Certificate was
automatically updated by the OCSP Responder Service. 5127- The OCSP Revocation
Provider successfully updated the revocation information. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an
attacker can overwrite part or all of their activity by generating large numbers of events so that
the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- Certification
Services
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9460-7,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Certification Services"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.10 Set 'Audit Policy: Object Access: Application Generated'"
info :"Set 'Audit Policy: Object Access: Application Generated' to 'No Auditing' (Scored)
This subcategory reports when applications attempt to generate audit events by using the
Windows auditing application programming interfaces (APIs). Events for this subcategory
include- 4665- An attempt was made to create an application client context. 4666- An
application attempted an operation- 4667- An application client context was deleted. 4668-
An application was initialized. Refer to the Microsoft Knowledgebase article Description of
security events in Windows Vista and in Windows Server 2008 for the most recent
information about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an
attacker can overwrite part or all of their activity by generating large numbers of events so
that the evidence of their intrusion is overwritten."
solution :"
To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- Application
Generated
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-9816-0"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Application Generated"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.11 Set 'Audit Policy: Object Access: Detailed obÌåÓý Share'"
info :"1.2.1.2.1.2.11 Set 'Audit Policy: Object Access: Detailed obÌåÓý Share' to 'No Auditing' (Scored)
This policy setting allows you to audit attempts to access files and folders on a shared
folder. The Detailed obÌåÓý Share setting logs an event every time a file or folder is accessed,
whereas the obÌåÓý Share setting only records one event for any connection established
between a client and file share. Detailed obÌåÓý Share audit events include detailed
information about the permissions or other criteria used to grant or deny access. If you
configure this policy setting, an audit event is generated when an attempt is made to access
a file or folder on a share. The administrator can specify whether to audit only successes,
only failures, or both successes and failures. Note- There are no system access control lists
(SACLs) for shared folders. If this policy setting is enabled, access to all shared files and
folders on the system is audited. Volume- High on a file server or domain controller
because of SYSVOL network access required by Group Policy.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an
attacker can overwrite part or all of their activity by generating large numbers of events so
that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- Detailed obÌåÓý
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.
Default Value-No Auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9720-4,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Detailed obÌåÓý Share"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.2.12 Set 'Audit Policy: Object Access: Filtering Platform Connection'"
info :"1.2.1.2.1.2.12 Set 'Audit Policy: Object Access: Filtering Platform Connection' to 'No Auditing' (Scored)
This subcategory reports when connections are allowed or blocked by WFP. These events
can be high in volume. Events for this subcategory include- 5031- The Windows Firewall
Service blocked an application from accepting incoming connections on the network. 5154-
The Windows Filtering Platform has permitted an application or service to listen on a port
for incoming connections. 5155 - The Windows Filtering Platform has blocked an
application or service from listening on a port for incoming connections. 5156- The
Windows Filtering Platform has allowed a connection. 5157- The Windows Filtering
Platform has blocked a connection. 5158- The Windows Filtering Platform has permitted a
bind to a local port. 5159- The Windows Filtering Platform has blocked a bind to a local
port. Refer to the Microsoft Knowledgebase article Description of security events in
Windows Vista and in Windows Server 2008 for the most recent information about this
setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an
attacker can overwrite part or all of their activity by generating large numbers of events so
that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Object Access\Audit Policy- Object Access- Filtering
Platform Connection
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9728-7,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Filtering Platform Connection"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.1 Set 'Audit Policy: Logon- Logoff: Other Logon/Logoff Events'"
info :"Set 'Audit Policy: Logon- Logoff: Other Logon/Logoff Events' to 'No Auditing' (Scored)
This subcategory reports other logon/logoff-related events, such as Terminal 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. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate
millions of failure events such as logon failures in order to fill the Security log and force
the computer to shut down, creating a denial of service (DoS). If security logs are allowed to
be overwritten, an attacker can overwrite part or all of their activity by generating large
numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9622-2,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Other Logon/Logoff Events"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.2 Set 'Audit Policy: Logon- Logoff: Special Logon'"
info :"Set 'Audit Policy: Logon- Logoff: Special Logon' to 'Success' (Scored)
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. Refer to the Microsoft Knowledgebase article Description of security events in
Windows Vista and in Windows Server 2008 for the most recent information about this
setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a Denial of Service. If security logs are allowed to be overwritten, an
attacker can overwrite part or all of their activity by generating large numbers of events so
that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- 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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,PCI|10.2.4,CCE|CCE-9763-4,PCI|10.3.3,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3,PCI|10.2.1"
value_type : AUDIT_SET
value_data : "Success"
audit_policy_subcategory : "Special Logon"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.3 Set 'Audit Policy: Logon- Logoff: IPsec Main Mode'"
info :"Set 'Audit Policy: Logon- Logoff: IPsec Main Mode' to 'No Auditing' (Scored)
This subcategory reports the results of Internet Key Exchange (IKE) protocol and
Authenticated Internet Protocol (AuthIP) during Main Mode negotiations. Events for this
subcategory include- 4646- IKE DoS-prevention mode started. 4650- An IPsec Main Mode
security association was established. Extended Mode was not enabled. Certificate
authentication was not used. 4651- An IPsec Main Mode security association was
established. Extended Mode was not enabled. A certificate was used for authentication.
4652- An IPsec Main Mode negotiation failed. 4653- An IPsec Main Mode negotiation failed.
4655- An IPsec Main Mode security association ended. 4976- During Main Mode
negotiation, IPsec received an invalid negotiation packet. If this problem persists, it could
indicate a network issue or an attempt to modify or replay this negotiation. 5049- An IPsec
Security Association was deleted. 5453- An IPsec negotiation with a remote computer
failed because the IKE and AuthIP IPsec Keying Modules (IKEEXT) service is not started.
Refer to the Microsoft Knowledgebase article Description of security events in Windows
Vista and in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of
events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- IPsec Main Mode
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-8956-5"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "IPsec Main Mode"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.4 Set 'Audit Policy: Logon- Logoff: Account Lockout'"
info :"Set 'Audit Policy: Logon- Logoff: Account Lockout' to 'No Auditing' (Scored)
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.
Refer to the Microsoft Knowledgebase article Description of security events in Windows
Vista and in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- 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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-8853-4,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Account Lockout"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.5 Set 'Audit Policy: Logon- Logoff: IPsec Extended Mode'"
info :"Set 'Audit Policy: Logon- Logoff: IPsec Extended Mode' to 'No Auditing' (Scored)
This subcategory reports the results of AuthIP during Extended Mode negotiations. Events
for this subcategory include- 4978- During Extended Mode negotiation, IPsec received an
invalid negotiation packet. If this problem persists, it could indicate a network issue or an
attempt to modify or replay this negotiation. 4979- IPsec Main Mode and Extended Mode
security associations were established. 4980- IPsec Main Mode and Extended Mode
security associations were established. 4981- IPsec Main Mode and Extended Mode
security associations were established. 4982- IPsec Main Mode and Extended Mode
security associations were established. 4983- An IPsec Extended Mode negotiation failed.
The corresponding Main Mode security association has been deleted. 4984- An IPsec
Extended Mode negotiation failed. The corresponding Main Mode security association has
been deleted. Refer to the Microsoft Knowledgebase article Description of security events
in Windows Vista and in Windows Server 2008 for the most recent information about this
setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a denial of service (DoS). If security logs are allowed to be
overwritten, an attacker can overwrite part or all of their activity by generating large numbers
of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- IPsec Extended
Mode
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-9661-0"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "IPsec Extended Mode"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.6 Set 'Audit Policy: Logon- Logoff: IPsec Quick Mode'"
info :"Set 'Audit Policy: Logon- Logoff: IPsec Quick Mode' to 'No Auditing' (Scored)
This subcategory reports the results of IKE protocol and AuthIP during Quick Mode
negotiations. 4654- An IPsec Quick Mode negotiation failed. Events for this subcategory
include- 4977- During Quick Mode negotiation, IPsec received an invalid negotiation packet.
If this problem persists, it could indicate a network issue or an attempt to modify or replay
this negotiation. 5451- An IPsec Quick Mode security association was established. 5452- An
IPsec Quick Mode security association ended. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- IPsec Quick Mode
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-9632-1"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "IPsec Quick Mode"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.7 Set 'Audit Policy: Logon- Logoff: Logoff'"
info :"1.2.1.2.1.3.7 Set 'Audit Policy: Logon- Logoff: Logoff' to 'Success' (Scored)
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. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- 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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,CCE|CCE-8856-7,PCI|10.3.2,PCI|10.2.4,PCI|10.3.3,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3,PCI|10.2.1"
value_type : AUDIT_SET
value_data : "Success"
audit_policy_subcategory : "Logoff"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.8 Set 'Audit Policy: Logon- Logoff Network Policy Server'"
info :"1.2.1.2.1.3.8 Set 'Audit Policy: Logon- Logoff: Network Policy Server' to 'No Auditing' (Scored)
This subcategory reports events generated by RADIUS (IAS) and Network Access
Protection (NAP) user access requests. These requests can be Grant, Deny, Discard,
Quarantine, Lock, and Unlock. Auditing this setting will result in a medium or high volume
of records on NPS and IAS servers. Events for this subcategory include- Note All the events
in the Network Policy Server subcategory are available only in Windows Vista Service Pack
1 and in Windows Server 2008. 6272- Network Policy Server granted access to a user.
6273- Network Policy Server denied access to a user. 6274- Network Policy Server
discarded the request for a user. 6275- Network Policy Server discarded the accounting
request for a user. 6276- Network Policy Server quarantined a user. 6277- Network Policy
Server granted access to a user but put it on probation because the host did not meet the
defined health policy. 6278- Network Policy Server granted full access to a user because the
host met the defined health policy. 6279- Network Policy Server locked the user account
due to repeated failed authentication attempts. 6280- Network Policy Server unlocked the
user account. 8191- Network Policy Server unlocked the user account. Refer to the
Microsoft Knowledgebase article Description of security events in Windows Vista and in
Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a denial of service (DoS). If security logs are allowed
to be overwritten, an attacker can overwrite part or all of their activity by generating large
numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- Network Policy
Server
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9076-1,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Network Policy Server"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.3.9 Set 'Audit Policy: Logon- Logoff: Logon'"
info :"1.2.1.2.1.3.9 Set 'Audit Policy: Logon- Logoff: Logon' to 'Success and Failure' (Scored)
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. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Logon/Logoff\Audit Policy- Logon-Logoff- 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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,PCI|10.2.4,PCI|10.3.3,CCE|CCE-9683-4,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3,PCI|10.2.1"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "Logon"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.4.1 Set 'Audit Policy: DS Access: Directory Service Replication'"
info :"Set 'Audit Policy: DS Access: Directory Service Replication' to 'No Auditing' (Scored)
This subcategory reports when replication between two domain controllers begins and
ends. Events for this subcategory include- 4932- Synchronization of a replica of an Active
Directory naming context has begun. 4933- Synchronization of a replica of an Active
Directory naming context has ended. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be
overwritten, an attacker can overwrite part or all of their activity by generating large numbers
of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\DS Access\Audit Policy- DS Access- Directory Service
Replication
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9637-0,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Directory Service Replication"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.4.2 Set 'Audit Policy: DS Access: Detailed Directory Service Replication'"
info :"Set 'Audit Policy: DS Access: Detailed Directory Service Replication' to 'No Auditing' (Scored
This subcategory reports detailed information about the information replicating between
domain controllers. These events can be very high in volume. Events for this subcategory
include- 4928- An Active Directory replica source naming context was established. 4929 -
An Active Directory replica source naming context was removed. 4930 - An Active
Directory replica source naming context was modified. 4931 - An Active Directory replica
destination naming context was modified. 4934 - Attributes of an Active Directory object
were replicated. 4935 - Replication failure begins. 4936 - Replication failure ends. 4937 - A
lingering object was removed from a replica. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a denial of service (DoS). If security logs are allowed to be
overwritten, an attacker can overwrite part or all of their activity by generating large numbers
of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\DS Access\Audit Policy- DS Access- Detailed Directory
Service Replication
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9628-9,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Detailed Directory Service Replication"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.4.3 Set 'Audit Policy: DS Access: Directory Service Changes'"
info :"Set 'Audit Policy: DS Access: Directory Service Changes' to 'No Auditing' (Scored)
This subcategory reports changes to objects in Active Directory Domain Services (AD DS).
The types of changes that are reported are create, modify, move, and undelete operations
that are performed on an object. DS Change auditing, where appropriate, indicates the old
and new values of the changed properties of the objects that were changed. Only objects
with SACLs cause audit events to be generated, and only when they are accessed in a
manner that matches their SACL. Some objects and properties do not cause audit events to
be generated due to settings on the object class in the schema. This subcategory applies
only to domain controllers. Events for this subcategory include- 5136 - A directory service
object was modified. 5137 - A directory service object was created. 5138 - A directory
service object was undeleted. 5139 - A directory service object was moved. Note The
following event in the Directory Service Changes subcategory is available only in Windows
Vista Service Pack 1 and in Windows Server 2008. 5141- A directory service object was
deleted. Refer to the Microsoft Knowledgebase article Description of security events in
Windows Vista and in Windows Server 2008 for the most recent information about this
setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events so
that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\DS Access\Audit Policy- DS Access- Directory Service
Changes
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-9734-5"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Directory Service Changes"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.4.4 Set 'Audit Policy: DS Access'"
info :"Set 'Audit Policy: DS Access: Directory Service Access' to 'No Auditing' (Scored)
This subcategory reports when an AD DS object is accessed. Only objects with SACLs cause
audit events to be generated, and only when they are accessed in a manner that matches
their SACL. These events are similar to the directory service access events in previous
versions of Windows Server. This subcategory applies only to domain controllers. Events
for this subcategory include- 4662 - An operation was performed on an object. Refer to the
Microsoft Knowledgebase article Description of security events in Windows Vista and in
Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\DS Access\Audit Policy- DS Access- Directory Service
Access
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9765-9,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Directory Service Access"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.5.1 Set 'Audit Policy: Detailed Tracking: DPAPI Activity'"
info :"Set 'Audit Policy: Detailed Tracking: DPAPI Activity' to 'No Auditing' (Scored)
This subcategory reports encrypt or decrypt calls into the data protections application
interface (DPAPI). DPAPI is used to protect secret information such as stored password and
key information. Events for this subcategory include- 4692- Backup of data protection
master key was attempted. 4693- Recovery of data protection master key was attempted.
4694- Protection of auditable protected data was attempted. 4695- Unprotection of
auditable protected data was attempted. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Detailed Tracking\Audit Policy- Detailed Tracking- DPAPI
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9735-2,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "DPAPI Activity"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.5.2 Set 'Audit Policy: Detailed Tracking: Process Termination'"
info :"Set 'Audit Policy: Detailed Tracking: Process Termination' to 'No Auditing' (Scored)
This subcategory reports when a process terminates. Events for this subcategory include-
4689- A process has exited. Refer to the Microsoft Knowledgebase article Description of
security events in Windows Vista and in Windows Server 2008 for the most recent
information about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a denial of service (DoS). If security logs are allowed to
be overwritten, an attacker can overwrite part or all of their activity by generating large numbers
of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Detailed Tracking\Audit Policy- Detailed Tracking-
Process Termination
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-9227-0"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Process Termination"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.5.3 Set 'Audit Policy: Detailed Tracking: Process Creation'"
info :"Set 'Audit Policy: Detailed Tracking: Process Creation' to 'Success' (Scored)
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 the Microsoft Knowledgebase
article Description of security events in Windows Vista and in Windows Server 2008 for
the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a denial of service (DoS). If security logs are allowed to
be overwritten, an attacker can overwrite part or all of their activity by generating large
numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Detailed Tracking\Audit Policy- Detailed Tracking-
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,CCE|CCE-9562-0,PCI|10.3.3,PCI|10.3.5,PCI|10.2.7,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3"
value_type : AUDIT_SET
value_data : "Success"
audit_policy_subcategory : "Process Creation"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.5.4 Set 'Audit Policy: Detailed Tracking: RPC Events'"
info :"Set 'Audit Policy: Detailed Tracking: RPC Events' to 'No Auditing' (Scored)
This subcategory reports remote procedure call (RPC) connection events. Events for this
subcategory include- 5712- A Remote Procedure Call (RPC) was attempted. Refer to the
Microsoft Knowledgebase article Description of security events in Windows Vista and in
Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer to
shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Detailed Tracking\Audit Policy- Detailed Tracking- RPC
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9492-0,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "RPC Events"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.6.1 Set 'Audit Policy: Policy Change: MPSSVC Rule'"
info :"Set 'Audit Policy: Policy Change: MPSSVC Rule-Level Policy Change' to 'No Auditing' (Scored)
This subcategory reports changes in policy rules used by the Microsoft Protection Service
(MPSSVC.exe). This service is used by Windows Firewall and by Microsoft OneCare. 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- Refer
to the Microsoft Knowledgebase article Description of security events in Windows Vista
and in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate
millions of failure events such as logon failures in order to fill the Security log and force
the computer to shut down, creating a Denial of Service. If security logs are allowed to be
overwritten, an attacker can overwrite part or all of their activity by generating large
numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Policy Change\Audit Policy- Policy Change- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9153-8,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "MPSSVC Rule-Level Policy Change"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.6.2 Set 'Audit Policy: Policy Change: Filtering Platform Policy Change'"
info :"Set 'Audit Policy: Policy Change: Filtering Platform Policy Change' to 'No Auditing' (Scored)
This subcategory reports the addition and removal of objects from WFP, including startup
filters. These events can be very high in volume. Events for this subcategory include- 4709-
IPsec Services was started. 4710- IPsec Services was disabled. 4711- May contain any one
of the following- . PAStore Engine applied locally cached copy of Active Directory storage
IPsec policy on the computer. . PAStore Engine applied Active Directory storage IPsec
policy on the computer. . PAStore Engine applied local registry storage IPsec policy on the
computer. . PAStore Engine failed to apply locally cached copy of Active Directory storage
IPsec policy on the computer. . PAStore Engine failed to apply Active Directory storage
IPsec policy on the computer. . PAStore Engine failed to apply local registry storage IPsec
policy on the computer. . PAStore Engine failed to apply some rules of the active IPsec
policy on the computer. . PAStore Engine failed to load directory storage IPsec policy on the
computer. . PAStore Engine loaded directory storage IPsec policy on the computer. .
PAStore Engine failed to load local storage IPsec policy on the computer. . PAStore Engine
loaded local storage IPsec policy on the computer. . PAStore Engine polled for changes to
the active IPsec policy and detected no changes. 4712- IPsec Services encountered a
potentially serious failure. 5040- A change has been made to IPsec settings. An
Authentication Set was added. 5041- A change has been made to IPsec settings. An
Authentication Set was modified. 5042- A change has been made to IPsec settings. An
Authentication Set was deleted. 5043- A change has been made to IPsec settings. A
Connection Security Rule was added. 5044- A change has been made to IPsec settings. A
Connection Security Rule was modified. 5045- A change has been made to IPsec settings. A
Connection Security Rule was deleted. 5046- A change has been made to IPsec settings. A
Crypto Set was added. 5047- A change has been made to IPsec settings. A Crypto Set was
modified. 5048- A change has been made to IPsec settings. A Crypto Set was deleted. 5440-
The following callout was present when the Windows Filtering Platform Base Filtering
Engine started. 5441- The following filter was present when the Windows Filtering
Platform Base Filtering Engine started. 5442- The following provider was present when the
Windows Filtering Platform Base Filtering Engine started. 5443- The following provider
context was present when the Windows Filtering Platform Base Filtering Engine started.
5444 - The following sub-layer was present when the Windows Filtering Platform Base
Filtering Engine started. 5446- A Windows Filtering Platform callout has been changed.
5448- A Windows Filtering Platform provider has been changed. 5449- A Windows
Filtering Platform provider context has been changed. 5450- A Windows Filtering Platform
sub-layer has been changed. 5456- PAStore Engine applied Active Directory storage IPsec
policy on the computer. 5457- PAStore Engine failed to apply Active Directory storage IPsec
policy on the computer. 5458 - PAStore Engine applied locally cached copy of Active
Directory storage IPsec policy on the computer. 5459- PAStore Engine failed to apply
locally cached copy of Active Directory storage IPsec policy on the computer. 5460- PAStore
Engine applied local registry storage IPsec policy on the computer. 5461- PAStore Engine
failed to apply local registry storage IPsec policy on the computer. 5462- PAStore Engine
failed to apply some rules of the active IPsec policy on the computer. Use the IP Security
Monitor snap-in to diagnose the problem. 5463- PAStore Engine polled for changes to the
active IPsec policy and detected no changes. 5464- PAStore Engine polled for changes to the
active IPsec policy, detected changes, and applied them to IPsec Services. 5465- PAStore
Engine received a control for forced reloading of IPsec policy and processed the control
successfully. 5466- PAStore Engine polled for changes to the Active Directory IPsec policy,
determined that Active Directory cannot be reached, and will use the cached copy of the
Active Directory IPsec policy instead. Any changes made to the Active Directory IPsec
policy since the last poll could not be applied. 5467- PAStore Engine polled for changes to
the Active Directory IPsec policy, determined that Active Directory can be reached, and
found no changes to the policy. The cached copy of the Active Directory IPsec policy is no
longer being used. 5468- PAStore Engine polled for changes to the Active Directory IPsec
policy, determined that Active Directory can be reached, found changes to the policy, and
applied those changes. The cached copy of the Active Directory IPsec policy is no longer
being used. 5471- PAStore Engine loaded local storage IPsec policy on the computer. 5472-
PAStore Engine failed to load local storage IPsec policy on the computer. 5473- PAStore
Engine loaded directory storage IPsec policy on the computer. 5474- PAStore Engine failed
to load directory storage IPsec policy on the computer. 5477- PAStore Engine failed to add
quick mode filter. Refer to the Microsoft Knowledgebase article Description of security
events in Windows Vista and in Windows Server 2008 for the most recent information
about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a Denial of Service. If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of
events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Policy Change\Audit Policy- Policy Change- Filtering
Platform 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,Level|1S,CCE|CCE-9902-8"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Filtering Platform Policy Change"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.6.3 Set 'Audit Policy: Policy Change: Authorization Policy Change'"
info :"Set 'Audit Policy: Policy Change: Authorization Policy Change' to 'No Auditing' (Scored)
This subcategory reports changes in authorization policy including permissions (DACL)
changes. 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. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits
setting in the Security Options section of Group Policy is enabled, an attacker could
generate millions of failure events such as logon failures in order to fill the Security log
and force the computer to shut down, creating a Denial of Service. If security logs are allowed
to be overwritten, an attacker can overwrite part or all of their activity by generating large
numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Policy Change\Audit Policy- Policy Change- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9633-9,800-53|AU-2,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Authorization Policy Change"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.6.4 Set 'Audit Policy: Policy Change: Audit Policy Change'"
info :"Set 'Audit Policy: Policy Change: Audit Policy Change' to 'Success and Failure' (Scored)
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. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a Denial of Service. If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Policy Change\Audit Policy- Policy Change- 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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,PCI|10.2.3,PCI|10.3.3,PCI|10.3.5,Level|1S,PCI|10.3.6,CCE|CCE-10021-4,PCI|10.3.1,PCI|10.3"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "Audit Policy Change"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.6.5 Set 'Audit Policy: Policy Change: Other Policy Change Events'"
info :"Set 'Audit Policy: Policy Change: Other Policy Change Events' to 'No Auditing' (Scored)
This subcategory reports other types of security policy changes such as configuration of the
Trusted Platform Module (TPM) or cryptographic providers. Events for this subcategory
include- 4909- The local policy settings for the TBS were changed. 4910- The group policy
settings for the TBS were changed. 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. 5447- A Windows Filtering Platform filter has been changed. 6144- Security
policy in the group policy objects has been applied successfully. 6145- One or more errors
occurred while processing security policy in the group policy objects. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a Denial of Service. If security logs are allowed to be
overwritten, an attacker can overwrite part or all of their activity by generating large
numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Policy Change\Audit Policy- Policy Change- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9596-8,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Other Policy Change Events"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.6.6 Set 'Audit Policy: Policy Change: Authentication Policy Change'"
info :"Set 'Audit Policy: Policy Change: Authentication Policy Change' to 'Success' (Scored)
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. Refer to the Microsoft Knowledgebase article Description of security
events in Windows Vista and in Windows Server 2008 for the most recent information
about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits
setting in the Security Options section of Group Policy is enabled, an attacker could
generate millions of failure events such as logon failures in order to fill the Security
log and force the computer to shut down, creating a Denial of Service. If security logs are
allowed to be overwritten, an attacker can overwrite part or all of their activity by generating
large numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Policy Change\Audit Policy- Policy Change- 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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,PCI|10.2,Level|1S,CCE|CCE-9976-2"
value_type : AUDIT_SET
value_data : "Success"
audit_policy_subcategory : "Authentication Policy Change"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.7.1 Set 'Audit Policy: Account Management: Distribution Group Management'"
info :"Set 'Audit Policy: Account Management: Distribution Group Management' to 'No Auditing' (Scored)
This subcategory reports each event of distribution group management, such as when a
distribution group is created, changed, or deleted or when a member is added to or
removed from a distribution group. If you enable this Audit policy setting, administrators
can track events to detect malicious, accidental, and authorized creation of group accounts.
Events for this subcategory include- 4744- A security-disabled local group was created.
4745- A security-disabled local group was changed. 4746- A member was added to a
security-disabled local group. 4747- A member was removed from a security-disabled local
group. 4748- A security-disabled local group was deleted. 4749- A security-disabled global
group was created. 4750- A security-disabled global group was changed. 4751- A member
was added to a security-disabled global group. 4752- A member was removed from a
security-disabled global group. 4753- A security-disabled global group was deleted. 4759- A
security-disabled universal group was created. 4760- A security-disabled universal group
was changed. 4761- A member was added to a security-disabled universal group. 4762- A
member was removed from a security-disabled universal group. 4763- A security-disabled
universal group was deleted. Refer to the Microsoft Knowledgebase article Description of
security events in Windows Vista and in Windows Server 2008 for the most recent
information about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a denial of service (DoS). If security logs are allowed to
be overwritten, an attacker can overwrite part or all of their activity by generating large
numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Management\Audit Policy- Account Management-
Distribution 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,CCE|CCE-9644-6,PCI|10.3.3,PCI|10.2.2,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Distribution Group Management"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.7.2 Set 'Audit Policy: Account Management: Computer Account Management'"
info :"Set 'Audit Policy: Account Management: Computer Account Management' to 'Success' (Scored)
This subcategory reports each event of computer account management, such as when a
computer account is created, changed, deleted, renamed, disabled, or enabled. Events for
this subcategory include- 4741- A computer account was created. 4742- A computer
account was changed. 4743- A computer account was deleted. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits
setting in the Security Options section of Group Policy is enabled, an attacker could
generate millions of failure events such as logon failures in order to fill the Security
log and force the computer to shut down, creating a denial of service (DoS). If security
logs are allowed to be overwritten, an attacker can overwrite part or all of their activity
by generating large numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Management\Audit Policy- Account Management-
Computer 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,PCI|10.3.3,PCI|10.2.2,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,CCE|CCE-9498-7,PCI|10.3"
value_type : AUDIT_SET
value_data : "Success"
audit_policy_subcategory : "Computer Account Management"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.7.3 Set 'Audit Policy: Account Management: User Account Management'"
info :"Set 'Audit Policy: Account Management: User Account Management' to 'Success and Failure' (Scored)
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. Refer to the Microsoft Knowledgebase article Description of
security events in Windows Vista and in Windows Server 2008 for the most recent
information about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Management\Audit Policy- Account Management- 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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,PCI|10.3.3,PCI|10.2.2,PCI|10.3.5,CCE|CCE-9542-2,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "User Account Management"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.7.4 Set 'Audit Policy: Account Management: Security Group Management'"
info :"Set 'Audit Policy: Account Management: Security Group Management' to 'Success and Failure' (Scored)
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. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Management\Audit Policy- Account Management-
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.
Default Value-Success"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,CCE|CCE-9692-5,PCI|10.3.3,PCI|10.2.2,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "Security Group Management"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.7.5 Set 'Audit Policy: Account Management: Other Account Management Events'"
info :"Set 'Audit Policy: Account Management: Other Account Management Events' to 'Success and Failure' (Scored)
This subcategory reports other account management events. Events for this subcategory
include- 4782- The password hash an account was accessed. 4793- The Password Policy
Checking API was called. Refer to the Microsoft Knowledgebase article Description of
security events in Windows Vista and in Windows Server 2008 for the most recent
information about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in the
Security Options section of Group Policy is enabled, an attacker could generate millions of failure
events such as logon failures in order to fill the Security log and force the computer to shut down,
creating a denial of service (DoS). If security logs are allowed to be overwritten, an attacker
can overwrite part or all of their activity by generating large numbers of events so that the
evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Management\Audit Policy- Account Management-
Other Account Management 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,PCI|10.3.3,PCI|10.2.2,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3,CCE|CCE-9657-8"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "Other Account Management Events"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.7.6 Set 'Audit Policy: Account Management: Application Group Management'"
info :"Set 'Audit Policy: Account Management: Application Group Management' to 'No Auditing' (Scored)
This subcategory reports each event of application group management on a computer, such
as when an application group is created, changed, or deleted or when a member is added to
or removed from an application group. If you enable this Audit policy setting,
administrators can track events to detect malicious, accidental, and authorized creation of
application group accounts. Events for this subcategory include- 4783- A basic application
group was created. 4784- A basic application group was changed. 4785- A member was
added to a basic application group. 4786- A member was removed from a basic application
group. 4787- A non-member was added to a basic application group. 4788- A non-member
was removed from a basic application group. 4789- A basic application group was deleted.
4790- An LDAP query group was created. 4791- A basic application group was changed.
4792- An LDAP query group was deleted. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events so
that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Management\Audit Policy- Account Management-
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-8822-9,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Application Group Management"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.8.1 Set 'Audit Policy: Account Logon: Kerberos Authentication Service'"
info :"Set 'Audit Policy: Account Logon: Kerberos Authentication Service' to 'No Auditing' (Scored)
This subcategory reports events generated by the Kerberos Authentication Server. These
events occur on the computer that is authoritative for the credentials. Events for this
subcategory include- 4768- A Kerberos authentication ticket (TGT) was requested. 4771-
Kerberos pre-authentication failed. 4772- A Kerberos authentication ticket request failed.
Refer to the Microsoft Knowledgebase article Description of security events in Windows
Vista and in Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Logon\Audit Policy- Account Logon- Kerberos
Authentication Service
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9258-5,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Kerberos Authentication Service"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.8.2 Set 'Audit Policy: Account Logon: Other Account Logon Events'"
info :"Set 'Audit Policy: Account Logon: Other Account Logon Events' to 'No Auditing' (Scored)
This subcategory reports the events that occur in response to credentials submitted for a
user account logon request that do not relate to credential validation or Kerberos tickets.
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. Refer to the Microsoft Knowledgebase article Description
of security events in Windows Vista and in Windows Server 2008 for the most recent
information about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting in
the Security Options section of Group Policy is enabled, an attacker could generate millions of
failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a denial of service (DoS). If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Logon\Audit Policy- Account Logon- Other Account
Logon 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9808-7,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Other Account Logon Events"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.8.3 Set 'Audit Policy: Account Logon: Kerberos Service Ticket Operations'"
info :"Set 'Audit Policy: Account Logon: Kerberos Service Ticket Operations' to 'No Auditing' (Scored)
This subcategory reports generated by Kerberos ticket request processes on the domain
controller that is authoritative for the domain account. Events for this subcategory include-
4769- A Kerberos service ticket was requested. 4770- A Kerberos service ticket was
renewed. 4773- A Kerberos service ticket request failed. Refer to the Microsoft
Knowledgebase article Description of security events in Windows Vista and in Windows
Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a denial of service (DoS). If security logs are allowed to
be overwritten, an attacker can overwrite part or all of their activity by generating large
numbers of events so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Logon\Audit Policy- Account Logon- Kerberos
Service Ticket Operations
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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9148-8,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Kerberos Service Ticket Operations"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.8.4 Set 'Audit Policy: Account Logon: Credential Validation'"
info :"Set 'Audit Policy: Account Logon: Credential Validation' to 'Success and Failure' (Scored)
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. Refer to the
Microsoft Knowledgebase article Description of security events in Windows Vista and in
Windows Server 2008 for the most recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a Denial of Service. If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Account Logon\Audit Policy- Account Logon- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,PCI|10.2.4,CCE|CCE-9725-3,PCI|10.3.3,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3,PCI|10.2.1"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "Credential Validation"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.9.1 Set 'Audit Policy: Privilege Use: Other Privilege Use Events'"
info :"Set 'Audit Policy: Privilege Use: Other Privilege Use Events' to 'No Auditing' (Scored)
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, and 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. Refer to the Microsoft Knowledgebase article Description
of security events in Windows Vista and in Windows Server 2008 for the most recent
information about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a Denial of Service. If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Privilege Use\Audit Policy- Privilege Use- Other
Privilege Use 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.
Default Value-No Auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9988-7,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Other Privilege Use Events"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.9.2 Set 'Audit Policy: Privilege Use: Non Sensitive Privilege Use'"
info :"Set 'Audit Policy: Privilege Use: Non Sensitive Privilege Use' to 'No Auditing' (Scored)
This subcategory reports when a user account or service uses a non-sensitive privilege. A
non-sensitive privilege includes the following user rights- Access Credential Manager as a
trusted caller, Access this computer from the network, Add workstations to domain, Adjust
memory quotas for a process, Allow log on locally, Allow log on through Terminal Services,
Bypass traverse checking, Change the system time, Create a pagefile, Create global objects,
Create permanent shared objects, Create symbolic links, Deny access this computer from
the network, Deny log on as a batch job, Deny log on as a service, Deny log on locally, Deny
log on through Terminal Services, Force shutdown from a remote system, Increase a
process working set, Increase scheduling priority, Lock pages in memory, Log on as a batch
job, Log on as a service, Modify an object label, Perform volume maintenance tasks, Profile
single process, Profile system performance, Remove computer from docking station, Shut
down the system, and Synchronize directory service data. Auditing this subcategory will
create a very 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. Refer to the Microsoft Knowledgebase article
Description of security events in Windows Vista and in Windows Server 2008 for the most
recent information about this setting-
http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the computer
to shut down, creating a Denial of Service. If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to No Auditing.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Privilege Use\Audit Policy- Privilege Use- Non 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AU-2,CCE|CCE-9190-0,Level|1S"
value_type : AUDIT_SET
value_data : "No Auditing"||"Success"||"Failure"||"Success, Failure"
audit_policy_subcategory : "Non Sensitive Privilege Use"
type : AUDIT_POLICY_SUBCATEGORY
description :"1.2.1.2.1.9.3 Set 'Audit Policy: Privilege Use: Sensitive Privilege Use'"
info :"Set 'Audit Policy: Privilege Use: Sensitive Privilege Use' to 'Success and Failure' (Scored)
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, and 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. Refer to the Microsoft Knowledgebase article Description
of security events in Windows Vista and in Windows Server 2008 for the most recent
information about this setting- http-//support.microsoft.com/default.aspx/kb/947226.
*Rationale*
If audit settings are not configured, it can be difficult or impossible to determine what
occurred during a security incident. However, if audit settings are configured so that events
are generated for all activities the Security log will be filled with data and hard to use. Also,
you can use a large amount of data storage as well as adversely affect overall computer
performance if you configure audit settings for a large number of objects. If failure auditing
is used and the Audit: Shut down system immediately if unable to log security audits setting
in the Security Options section of Group Policy is enabled, an attacker could generate millions
of failure events such as logon failures in order to fill the Security log and force the
computer to shut down, creating a Denial of Service. If security logs are allowed to be overwritten,
an attacker can overwrite part or all of their activity by generating large numbers of events
so that the evidence of their intrusion is overwritten."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Success and Failure.
Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy
Configuration\Audit Policies\Privilege Use\Audit Policy- Privilege Use- 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.
Default Value-No auditing"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|10.3.4,800-53|AU-2,PCI|10.3.2,CCE|CCE-9878-0,PCI|10.3.3,PCI|10.2.2,PCI|10.3.5,Level|1S,PCI|10.3.6,PCI|10.3.1,PCI|10.3"
value_type : AUDIT_SET
value_data : "Success, Failure"
audit_policy_subcategory : "Sensitive Privilege Use"
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.1.1 FW: Private: Allow unicast response"
info :"Set 'Windows Firewall: Private: Allow unicast response' to 'No' (Scored)
This option is useful if you need to control whether this computer receives unicast
responses to its outgoing multicast or broadcast messages.
*Rationale*
An attacker could respond to broadcast or multicast message with malicious payloads."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Private Profile\Windows Firewall- Private- Allow unicast response
Impact-
If you enable this setting and this computer sends multicast or broadcast messages to other
computers, Windows Firewall with Advanced Security waits as long as three seconds for
unicast responses from the other computers and then blocks all later responses. If you
disable this setting and this computer sends a multicast or broadcast message to other
computers, Windows Firewall with Advanced Security blocks the unicast responses sent by
those other computers.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-5,PCI|1.2.1,800-53|SC-7,Level|1S,CCE|CCE-9522-4"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PrivateProfile"
reg_item : "DisableUnicastResponsesToMulticastBroadcast"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.1.2 FW: Private: Outbound connections"
info :"Set 'Windows Firewall: Private: Outbound connections' to 'Allow (default)' (Scored)
This setting determines the behavior for outbound connections that do not match an
outbound firewall rule. The default behavior is to allow connections unless there are
firewall rules that block the connection. Important If you set Outbound connections to
Block and then deploy the firewall policy by using a GPO, computers that receive the GPO
settings cannot receive subsequent Group Policy updates unless you create and deploy an
outbound rule that enables Group Policy to work. Predefined rules for Core Networking
include outbound rules that enable Group Policy to work. Ensure that these outbound rules
are active, and thoroughly test firewall profiles before deploying.
*Rationale*
Some people believe that it is prudent to block all outbound connections except those
specifically approved by the user or administrator. Microsoft disagrees with this opinion,
blocking outbound connections by default will force users to deal with a large number of
dialog boxes prompting them to authorize or block applications such as their web browser
or instant messaging software. Additionally, blocking outbound traffic has little value
because if an attacker has compromised the system they can reconfigure the firewall
anyway."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Private Profile\Windows Firewall- Private- Outbound connections
Impact-None, this is the default configuration.
Default Value-Allow"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-8870-8,800-53|SC-7,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PrivateProfile"
reg_item : "DefaultOutboundAction"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.1.3 FW: Private: Display a notification"
info :"Set 'Windows Firewall: Private: Display a notification' to 'Yes' (Scored)
Select this option to have Windows Firewall with Advanced Security display notifications to
the user when a program is blocked from receiving inbound connections.
Note When the Apply local firewall rules setting is configured to No. It is recommended to
also configuring the Display a notification setting to No. Otherwise, users will continue to
receive messages that ask if they want to unblock a restricted inbound connection, but the
user's response will be ignored.
*Rationale*
Some organizations may prefer to avoid alarming users when firewall rules block certain
types of network activity. However, notifications can be helpful when troubleshooting
network issues involving the firewall."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Private Profile\Windows Firewall- Private- Display a notification
Impact-If you configure this policy setting to Yes, Windows Firewall will display these notifications.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-8884-9,PCI|1.2.1,800-53|CM-6,Level|1S,800-53|CM-3"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PrivateProfile"
reg_item : "DisableNotifications"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.1.4 FW: Private: Firewall state'"
info :"Set 'Windows Firewall: Private: Firewall state' to 'On (recommended)' (Scored)
Select On (recommended) to have Windows Firewall with Advanced Security use the
settings for this profile to filter network traffic. If you select Off, Windows Firewall with
Advanced Security will not use any of the firewall rules or connection security rules for this
profile.
*Rationale*
If the firewall is turned off all traffic will be able to access the system and an attacker may
be more easily able to remotely exploit a weakness in a network service."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Private Profile\Windows Firewall- Private- Firewall state
Impact-None, this is the default configuration.
Default Value-On"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-4,PCI|1.2.1,Level|1S,CCE|CCE-9739-4"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PrivateProfile"
reg_item : "EnableFirewall"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.1.5 FW: Private: Apply local firewall rules'"
info :"Set 'Windows Firewall: Private: Apply local firewall rules' to 'Yes (default)' (Scored)
This setting controls whether local administrators are allowed to create local firewall rules
that apply together with firewall rules configured by Group Policy.
*Rationale*
Users with administrative privileges might create firewall rules that expose the system to
remote attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Private Profile\Windows Firewall- Private- Apply local firewall rules
Impact-If you configure this setting to No, administrators can still create firewall rules, but the
rules will not be applied. This setting is available only when configuring the policy through
Group Policy.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-4,PCI|1.2.1,Level|1S,CCE|CCE-9663-6"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PrivateProfile"
reg_item : "AllowLocalPolicyMerge"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.1.6 FW: Private: Apply local connection security rules'"
info :"Set 'Windows Firewall: Private: Apply local connection security rules' to 'Yes (default)' (Scored)
This setting controls whether local administrators are allowed to create connection
security rules that apply together with connection security rules configured by Group
Policy.
*Rationale*
Users with administrative privileges might create firewall rules that expose the system to
remote attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Private Profile\Windows Firewall- Private- Apply local connection security
rules
Impact-If you configure this setting to No, administrators can still create firewall rules, but the
rules will not be applied. This setting is available only when configuring the policy through
Group Policy.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-4,CCE|CCE-9712-1,PCI|1.2.1,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PrivateProfile"
reg_item : "AllowLocalIPsecPolicyMerge"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.1.7 FW: Private: Inbound connections'"
info :"Set 'Windows Firewall: Private: Inbound connections' to 'Block (default)' (Scored)
This setting determines the behavior for inbound connections that do not match an
inbound firewall rule. The default behavior is to block connections unless there are firewall
rules to allow the connection.
*Rationale*
If the firewall allows all traffic to access the system then an attacker may be more easily
able to remotely exploit a weakness in a network service."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to Block (default).
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Private Profile\Windows Firewall- Private- Inbound connections
Impact-None, this is the default configuration.
Default Value-Block"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9694-1,800-53|AC-4,PCI|1.2.1,800-53|SC-7,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PrivateProfile"
reg_item : "DefaultInboundAction"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.2.1 FW: Public: Apply local connection security rules'"
info :"Set 'Windows Firewall: Public: Apply local connection security rules' to 'No' (Scored)
This setting controls whether local administrators are allowed to create connection
security rules that apply together with connection security rules configured by Group
Policy.
*Rationale*
Users with administrative privileges might create firewall rules that expose the system to
remote attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Public Profile\Windows Firewall- Public- Apply local connection security
rules
Impact-If you configure this setting to No, administrators can still create firewall rules, but the
rules will not be applied. This setting is available only when configuring the policy through
Group Policy.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9817-8,PCI|1.2.1,800-53|CM-6,800-53|SC-7,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PublicProfile"
reg_item : "AllowLocalIPsecPolicyMerge"
value_data : "0"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.2.2 FW: Public: Inbound connections'"
info :"Set 'Windows Firewall: Public: Inbound connections' to 'Block (default)' (Scored)
This setting determines the behavior for inbound connections that do not match an
inbound firewall rule. The default behavior is to block connections unless there are firewall
rules to allow the connection.
*Rationale*
If the firewall allows all traffic to access the system then an attacker may be more easily
able to remotely exploit a weakness in a network service."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to Block (default).
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Public Profile\Windows Firewall- Public- Inbound connections
Impact-None, this is the default configuration.
Default Value-Block"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-4,CCE|CCE-9007-6,PCI|1.2.1,800-53|SC-7,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PublicProfile"
reg_item : "DefaultInboundAction"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.2.3 FW: Public: Display a notification'"
info :"Set 'Windows Firewall: Public: Display a notification' to 'No' (Scored)
Select this option to have Windows Firewall with Advanced Security display notifications to
the user when a program is blocked from receiving inbound connections. Note When the
Apply local firewall rules setting is configured to No. It is recommended to also configuring
the Display a notification setting to No. Otherwise, users will continue to receive messages
that ask if they want to unblock a restricted inbound connection, but the user's response
will be ignored.
*Rationale*
Some organizations may prefer to avoid alarming users when firewall rules block certain
types of network activity. However, notifications can be helpful when troubleshooting
network issues involving the firewall."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Public Profile\Windows Firewall- Public- Display a notification
Impact-If you configure this policy setting to Yes, Windows Firewall will display these notifications.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|1.2.1,800-53|CM-6,Level|1S,CCE|CCE-9742-8,800-53|CM-3"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PublicProfile"
reg_item : "DisableNotifications"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.2.4 FW: Public: Firewall state'"
info :"Set 'Windows Firewall: Public: Firewall state' to 'On (recommended)' (Scored)
Select On (recommended) to have Windows Firewall with Advanced Security use the
settings for this profile to filter network traffic. If you select Off, Windows Firewall with
Advanced Security will not use any of the firewall rules or connection security rules for this
profile.
*Rationale*
If the firewall is turned off all traffic will be able to access the system and an attacker may
be more easily able to remotely exploit a weakness in a network service."
solution :"
To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Public Profile\Windows Firewall- Public- Firewall state
Impact-None, this is the default configuration.
Default Value-On"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|1.2.1,CCE|CCE-9593-5,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PublicProfile"
reg_item : "EnableFirewall"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.2.5 FW: Public: Apply local firewall rules'"
info :"Set 'Windows Firewall: Public: Apply local firewall rules' to 'Yes (default)' (Scored)
This setting controls whether local administrators are allowed to create local firewall rules
that apply together with firewall rules configured by Group Policy.
*Rationale*
Users with administrative privileges might create firewall rules that expose the system to
remote attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Public Profile\Windows Firewall- Public- Apply local firewall rules
Impact-If you configure this setting to No, administrators can still create firewall rules, but the
rules will not be applied. This setting is available only when configuring the policy through
Group Policy.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-4,PCI|1.2.1,CCE|CCE-9786-5,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PublicProfile"
reg_item : "AllowLocalPolicyMerge"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.2.6 FW: Public: Allow unicast response'"
info :"Set 'Windows Firewall: Public: Allow unicast response' to 'No' (Scored)
This option is useful if you need to control whether this computer receives unicast
responses to its outgoing multicast or broadcast messages.
*Rationale*
An attacker could respond to broadcast or multicast message with malicious payloads."
solution :"
To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Public Profile\Windows Firewall- Public- Allow unicast response
Impact-If you enable this setting and this computer sends multicast or broadcast messages to other
computers, Windows Firewall with Advanced Security waits as long as three seconds for
unicast responses from the other computers and then blocks all later responses. If you
disable this setting and this computer sends a multicast or broadcast message to other
computers, Windows Firewall with Advanced Security blocks the unicast responses sent by
those other computers.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-5,PCI|1.2.1,800-53|SC-7,CCE|CCE-9773-3,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PublicProfile"
reg_item : "DisableUnicastResponsesToMulticastBroadcast"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.2.7 FW: Public: Outbound connections'"
info :"Set 'Windows Firewall: Public: Outbound connections' to 'Allow (default)' (Scored)
This setting determines the behavior for outbound connections that do not match an
outbound firewall rule. The default behavior is to allow connections unless there are
firewall rules that block the connection. Important If you set Outbound connections to
Block and then deploy the firewall policy by using a GPO, computers that receive the GPO
settings cannot receive subsequent Group Policy updates unless you create and deploy an
outbound rule that enables Group Policy to work. Predefined rules for Core Networking
include outbound rules that enable Group Policy to work. Ensure that these outbound rules
are active, and thoroughly test firewall profiles before deploying.
*Rationale*
Some people believe that it is prudent to block all outbound connections except those
specifically approved by the user or administrator. Microsoft disagrees with this opinion,
blocking outbound connections by default will force users to deal with a large number of
dialog boxes prompting them to authorize or block applications such as their web browser
or instant messaging software. Additionally, blocking outbound traffic has little value
because if an attacker has compromised the system they can reconfigure the firewall
anyway."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Public Profile\Windows Firewall- Public- Outbound connections
Impact-None, this is the default configuration.
Default Value-Allow"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-7,Level|1S,CCE|CCE-9588-5"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\PublicProfile"
reg_item : "DefaultOutboundAction"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.3.1 FW: Domain: Outbound connections'"
info :"Set 'Windows Firewall: Domain: Outbound connections' to 'Allow (default)' (Scored)
This setting determines the behavior for outbound connections that do not match an
outbound firewall rule. In Windows Vista, the default behavior is to allow connections
unless there are firewall rules that block the connection.
*Rationale*
Some people believe that it is prudent to block all outbound connections except those
specifically approved by the user or administrator. Microsoft disagrees with this opinion,
blocking outbound connections by default will force users to deal with a large number of
dialog boxes prompting them to authorize or block applications such as their web browser
or instant messaging software. Additionally, blocking outbound traffic has little value
because if an attacker has compromised the system they can reconfigure the firewall
anyway."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Domain Profile\Windows Firewall- Domain- Outbound connections
Impact-None, this is the default configuration.
Default Value-Allow"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-7,CCE|CCE-9509-1,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile"
reg_item : "DefaultOutboundAction"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.3.2 FW: Domain: Apply local firewall rules'"
info :"Set 'Windows Firewall: Domain: Apply local firewall rules' to 'Yes (default)' (Scored)
This setting controls whether local administrators are allowed to create local firewall rules
that apply together with firewall rules configured by Group Policy.
*Rationale*
Users with administrative privileges might create firewall rules that expose the system to
remote attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Domain Profile\Windows Firewall- Domain- Apply local firewall rules
Impact-If you configure this setting to No, administrators can still create firewall rules, but the
rules will not be applied. This setting is available only when configuring the policy through
Group Policy.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-4,PCI|1.2.1,Level|1S,CCE|CCE-9686-7"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile"
reg_item : "AllowLocalPolicyMerge"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.3.3 FW: Domain: Firewall state'"
info :"Set 'Windows Firewall: Domain: Firewall state' to 'On (recommended)' (Scored)
Select On (recommended) to have Windows Firewall with Advanced Security use the
settings for this profile to filter network traffic. If you select Off, Windows Firewall with
Advanced Security will not use any of the firewall rules or connection security rules for this
profile.
*Rationale*
If the firewall is turned off all traffic will be able to access the system and an attacker may
be more easily able to remotely exploit a weakness in a network service."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Domain Profile\Windows Firewall- Domain- Firewall state
Impact-None, this is the default configuration.
Default Value-On"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-4,PCI|1.2.1,CCE|CCE-9465-6,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile"
reg_item : "EnableFirewall"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.3.4 FW: Domain: Display a notification'"
info :"Set 'Windows Firewall: Domain: Display a notification' to 'Yes' (Scored)
Select this option to have Windows Firewall with Advanced Security display notifications to
the user when a program is blocked from receiving inbound connections.
Note When the Apply local firewall rules setting is configured to No. It is recommended to
also configuring the Display a notification setting to No. Otherwise, users will continue to
receive messages that ask if they want to unblock a restricted inbound connection, but the
user's response will be ignored.
*Rationale*
Some organizations may prefer to avoid alarming users when firewall rules block certain
types of network activity. However, notifications can be helpful when troubleshooting
network issues involving the firewall."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Domain Profile\Windows Firewall- Domain- Display a notification
Impact-
If you configure this policy setting to Yes, Windows Firewall will display these notifications.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9774-1,PCI|1.2.1,800-53|CM-6,Level|1S,800-53|CM-3"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile"
reg_item : "DisableNotifications"
value_data : "0"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.3.5 FW: Domain: Inbound connections'"
info :"Set 'Windows Firewall: Domain: Inbound connections' to 'Block (default)' (Scored)
This setting determines the behavior for inbound connections that do not match an
inbound firewall rule. The default behavior is to block connections unless there are firewall
rules to allow the connection.
*Rationale*
If the firewall allows all traffic to access the system then an attacker may be more easily
able to remotely exploit a weakness in a network service."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to Block (default).
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Domain Profile\Windows Firewall- Domain- Inbound connections
Impact-None, this is the default configuration.
Default Value-Block"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-4,CCE|CCE-9620-6,PCI|1.2.1,800-53|SC-7,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile"
reg_item : "DefaultInboundAction"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.3.6 FW: Domain: Apply local connection security rules'"
info :"Set 'Windows Firewall: Domain: Apply local connection security rules' to 'Yes (default)' (Scored)
This setting controls whether local administrators are allowed to create connection
security rules that apply together with connection security rules configured by Group
Policy.
*Rationale*
Users with administrative privileges might create firewall rules that expose the system to
remote attack."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Domain Profile\Windows Firewall- Domain- Apply local connection security
rules
Impact-If you configure this setting to No, administrators can still create firewall rules, but the
rules will not be applied. This setting is available only when configuring the policy through
Group Policy.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI|1.2.1,800-53|CM-6,800-53|SC-7,Level|1S,CCE|CCE-9329-4"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile"
reg_item : "AllowLocalIPsecPolicyMerge"
value_data : "1"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"1.2.1.3.1.1.3.7 FW: Domain: Allow unicast response'"
info :"Set 'Windows Firewall: Domain: Allow unicast response' to 'No' (Scored)
This option is useful if you need to control whether this computer receives unicast
responses to its outgoing multicast or broadcast messages.
*Rationale*
An attacker could respond to broadcast or multicast message with malicious payloads."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\Windows Settings\Security Settings\Windows Firewall with
Advanced Security\Windows Firewall with Advanced Security\Windows Firewall
Properties\Domain Profile\Windows Firewall- Domain- Allow unicast response
Impact-If you enable this setting and this computer sends multicast or broadcast messages to other
computers, Windows Firewall with Advanced Security waits as long as three seconds for
unicast responses from the other computers and then blocks all later responses. If you
disable this setting and this computer sends a multicast or broadcast message to other
computers, Windows Firewall with Advanced Security blocks the unicast responses sent by
those other computers.
Default Value-Yes"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|SC-5,CCE|CCE-9069-6,PCI|1.2.1,800-53|SC-7,Level|1S"
value_type : POLICY_DWORD
reg_key : "HKLM\Software\Policies\Microsoft\WindowsFirewall\DomainProfile"
reg_item : "DisableUnicastResponsesToMulticastBroadcast"
value_data : "1"
reg_option : CAN_NOT_BE_NULL
type : LOCKOUT_POLICY
description :"1.2.1.4.1.1 Set 'Account lockout duration'"
info :"Set 'Account lockout duration' to '120 or greater' (Scored)
This policy setting determines the length of time that must pass before a locked account is
unlocked and a user can try to log on again. The setting does this by specifying the number
of minutes a locked out account will remain unavailable. If the value for this policy setting
is configured to 0, locked out accounts will remain locked out until an administrator
manually unlocks them.
Although it might seem like a good idea to configure the value for this policy setting to a
high value, such a configuration will likely increase the number of calls that the help desk
receives to unlock accounts locked by mistake. Users should be aware of the length of time
a lock remains in place, so that they realize they only need to call the help desk if they have
an extremely urgent need to regain access to their computer.
*Rationale*
A denial of service (DoS) condition can be created if an attacker abuses the Account lockout
threshold and repeatedly attempts to log on with a specific account. Once you configure the
Account lockout threshold setting, the account will be locked out after the specified number
of failed attempts. If you configure the Account lockout duration setting to 0, then the
account will remain locked out until an administrator unlocks it manually."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 0.
Computer Configuration\Windows Settings\Security Settings\Account Policies\Account
Lockout Policy\Account lockout duration
Impact-Although it may seem like a good idea to configure this policy setting to never
automatically unlock an account, such a configuration can increase the number of requests
that your organization's help desk receives to unlock accounts that were locked by mistake.
Default Value-Not defined"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|AC-7,CCE|CCE-9308-8,Level|1S"
value_type : TIME_MINUTE
value_data : [120..MAX]
lockout_policy : LOCKOUT_DURATION
type : LOCKOUT_POLICY
description :"1.2.1.4.1.2 Set 'Account lockout threshold'"
info :"Set 'Account lockout threshold' to '3' or fewer (Scored)
This policy setting determines the number of failed logon attempts before a lock occurs.
Authorized users can lock themselves out of an account by mistyping their password or by
remembering it incorrectly, or by changing their password on one computer while logged
on to another computer. The computer with the incorrect password will continuously try to
authenticate the user, and because the password it uses to authenticate is incorrect, a lock
occurs. To avoid accidental lockout of authorized users, set the account lockout threshold
to a high number. The default value for this policy setting is 0 invalid logon attempts, which
disables the account lockout feature.
Because it is possible for an attacker to use this lockout state as a denial of service (DoS) by
triggering a lockout on a large number of accounts, your organization should determine
whether to use this policy setting based on identified threats and the risks you want to
mitigate. There are two options to consider for this policy setting.
. Configure the value for Account lockout threshold to 0 to ensure that accounts will not be
locked out. This setting value will prevent a DoS attack that attempts to lock out accounts in
your organization. It will also reduce help desk calls, because users will not be able to lock
themselves out of their accounts accidentally. However, this setting value will not prevent a
brute force attack. The following defenses should also be considered-
. A password policy that forces all users to have complex passwords made up of 8 or more
characters.
. A robust auditing mechanism, which will alert administrators when a series of account
lockouts occurs in the environment. For example, the auditing solution should monitor for
security event 539, which is a logon failure. This event identifies that there was a lock on
the account at the time of the logon attempt.
The second option is-
. Configure the value for Account lockout threshold to a value that provides users with the
ability to mistype their password several times, but locks out the account if a brute force
password attack occurs. This configuration will prevent accidental account lockouts and
reduce help desk calls, but will not prevent a DoS attack.
*Rationale*
Password attacks can use automated methods to try millions of password combinations for
any user account. The effectiveness of such attacks can be almost eliminated if you limit the
number of failed logons that can be performed.
However, a DoS attack could be performed on a domain that has an account lockout
threshold configured. An attacker could programmatically attempt a series of password
attacks against all users in the organization. If the number of attempts is greater than the
account lockout threshold, the attacker might be able to lock out every account."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 3.
Computer Configuration\Windows Settings\Security Settings\Account Policies\Account
Lockout Policy\Account lockout threshold
Impact-If this policy setting is enabled, a locked-out account will not be usable until it is reset by an
administrator or until the account lockout duration expires. This setting will likely generate
a number of additional help desk calls. In fact, locked accounts cause the greatest number
of calls to the help desk in many organizations.
If you enforce this setting an attacker could cause a denial of service condition by
deliberately generating failed logons for multiple user, therefore you should also configure
the Account Lockout Duration to a relatively low value such as 15 minutes.
If you configure the Account Lockout Threshold to 0, there is a possibility that an attacker's
attempt to discover passwords with a brute force password attack might go undetected if a
robust audit mechanism is not in place.
Default Value-0 invalid logon attempts"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI-3.0|8.1.6,CCE|CCE-9136-3,Level|1S,800-53|AC-1"
value_type : POLICY_DWORD
value_data : [1..3]
lockout_policy : LOCKOUT_THRESHOLD
type : LOCKOUT_POLICY
description :"1.2.1.4.1.3 Set 'Reset account lockout counter after' to '120' or greater"
info :"Set 'Reset account lockout counter after' to '120' or greater (Scored)
This policy setting determines the length of time before the Account lockout threshold
resets to zero. The default value for this policy setting is Not Defined. If the Account lockout
threshold is defined, this reset time must be less than or equal to the value for the Account
lockout duration setting.
If you leave this policy setting at its default value or configure the value to an interval that
is too long, your environment could be vulnerable to a DoS attack. An attacker could
maliciously perform a number of failed logon attempts on all users in the organization,
which will lock out their accounts. If no policy were determined to reset the account
lockout, it would be a manual task for administrators. Conversely, if a reasonable time
value is configured for this policy setting, users would be locked out for a set period until
all of the accounts are unlocked automatically.
*Rationale*
Users can accidentally lock themselves out of their accounts if they mistype their password
multiple times. To reduce the chance of such accidental lockouts, the Reset account lockout
counter after setting determines the number of minutes that must elapse before the
counter that tracks failed logon attempts and triggers lockouts is reset to 0."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 15.
Computer Configuration\Windows Settings\Security Settings\Account Policies\Account
Lockout Policy\Reset account lockout counter after
Impact-If you do not configure this policy setting or if the value is configured to an interval that is
too long, a DoS attack could occur. An attacker could maliciously attempt to log on to each
user's account numerous times and lock out their accounts as described in the preceding
paragraphs. If you do not configure the Reset account lockout counter after setting,
administrators would have to manually unlock all accounts. If you configure this policy
setting to a reasonable value the users would be locked out for some period, after which
their accounts would unlock automatically. Be sure that you notify users of the values used
for this policy setting so that they will wait for the lockout timer to expire before they call
the help desk about their inability to log on.
Default Value-0"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-9400-3,800-53|AC-7,Level|1S,PCI-3.0|8.5"
value_type : TIME_MINUTE
value_data : [120..MAX]
lockout_policy : LOCKOUT_RESET
type : PASSWORD_POLICY
description :"1.2.1.4.2.1 Set 'Store passwords using reversible encryption'"
info :"Set 'Store passwords using reversible encryption' to 'Disabled' (Scored)
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.
*Rationale*
Enabling this policy setting allows the operating system to store passwords in a weaker
format that is much more susceptible to compromise and weakens your system security."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to False.
Computer Configuration\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.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|IA-5,CCE|CCE-9260-1,PCI-3.0|8.2.1,Level|1S,800-53|AU-9"
value_type : POLICY_SET
value_data : "Disabled"
password_policy : REVERSIBLE_ENCRYPTION
type : PASSWORD_POLICY
description :"1.2.1.4.2.2 Set 'Minimum password length'"
info :"Set 'Minimum password length' to '14' (Scored)
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 pass phrase is a better term than
password. In Microsoft Windows 2000 or later, pass phrases can be quite long and can
include spaces. Therefore, a phrase such as I want to drink a $5 milkshake is a valid pass
phrase; 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, ensure that the value for the Minimum password length
setting is configured to 8 characters. This policy setting is long enough to provide adequate
security. In high security environments, configure the value to 12 characters.
*Rationale*
Types of password attacks include dictionary attacks (which attempt to use common words
and phrases) and brute force attacks (which try every possible combination of characters).
Also, attackers sometimes try to obtain the account database so they can use tools to
discover the accounts and passwords."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 8.
Computer Configuration\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 pass
phrases, 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.
Default Value-0 characters"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|IA-5,PCI-3.0|8.2.3,CCE|CCE-9357-5,Level|1S"
value_type : POLICY_DWORD
value_data : [14..MAX]
password_policy : MINIMUM_PASSWORD_LENGTH
type : PASSWORD_POLICY
description :"1.2.1.4.2.4 Set 'Enforce password history'"
info :"Set 'Enforce password history' to '24' (Scored)
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.
*Rationale*
The longer a user uses the same password, the greater the chance that an attacker can
determine the password through brute force attacks. Also, any accounts that may have
been compromised will remain exploitable for as long as the password is left unchanged. If
password changes are required but password reuse is not prevented, or if users continually
reuse a small number of passwords, the effectiveness of a good password policy is greatly
reduced. If you specify a low number for this policy setting, users will be able to use the
same small number of passwords repeatedly. If you do not also configure the Minimum
password age setting, users might repeatedly change their passwords until they can reuse
their original password."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 24.
Computer Configuration\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.
Default Value-24 passwords remembered"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|IA-5,800-53|CM-6,PCI-3.0|8.2.5,CCE|CCE-8912-8,Level|1S"
value_type : POLICY_DWORD
value_data : [24..MAX]
password_policy : ENFORCE_PASSWORD_HISTORY
type : PASSWORD_POLICY
description :"1.2.1.4.2.5 Set 'Minimum password age'"
info :"Set 'Minimum password age' to '1' or greater (Scored)
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.
*Rationale*
Users may have favorite passwords that they like to use because they are easy to
remember and they believe that their password choice is secure from compromise.
Unfortunately, passwords are compromised and if an attacker is targeting a specific
individual user account, with foreknowledge of data about that user, reuse of old
passwords can cause a security breach. To address password reuse a combination of
security settings is required. Using this policy setting with the Enforce password history
setting prevents the easy reuse of old passwords. For example, if you configure the Enforce
password history setting to ensure that users cannot reuse any of their last 12 passwords,
they could change their password 13 times in a few minutes and reuse the password they
started with, unless you also configure the Minimum password age setting to a number that
is greater than 0. You must configure this policy setting to a number that is greater than 0
for the Enforce password history setting to be effective."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to 1.
Computer Configuration\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.
Default Value-0 days"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|IA-5,Level|1S,CCE|CCE-9330-2,PCI-3.0|8.5"
value_type : TIME_DAY
value_data : [1..MAX]
password_policy : MINIMUM_PASSWORD_AGE
type : PASSWORD_POLICY
description :"1.2.1.4.2.6 Set 'Password must meet complexity requirements'"
info :"Set 'Password must meet complexity requirements' to 'Enabled' (Scored)
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 four 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.
*Rationale*
Passwords that contain only alphanumeric characters are extremely easy to discover with
several publicly available tools."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to True.
Computer Configuration\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 01280159 range. (ALT characters
outside of this range can represent standard alphanumeric characters that would not add
additional complexity to the password.)
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "Level|1S, CCE|CCE-9370-82 User Configuration"
value_type : POLICY_SET
value_data : "Enabled"
password_policy : COMPLEXITY_REQUIREMENTS
type : REGISTRY_SETTING
description :"2.1.1.1.1 Set 'Hide mechanisms to remove zone information'"
info :"Set 'Hide mechanisms to remove zone information' to 'Enabled' (Scored)
This policy setting allows you to manage whether users can manually remove the zone
information from saved file attachments. Typically, users can either click the Unblock
button in the file's Property sheet or select a check box in the Security Warning dialog. If
the zone information is removed, users can open potentially dangerous file attachments
that Windows has prevented users from opening. When the Hide mechanisms to remove
zone information setting is enabled, Windows hides the check box and Unblock button.
When this policy setting is disabled, Windows displays the check box and the Unblock
button. Because dangerous attachments are often downloaded from untrusted Internet
Explorer zones such as the Internet zone, it is recommended that you configure this policy
setting to Enabled to help ensure that as much security information as possible is retained
with each file. Note To configure whether files are saved with zone information, see the Do
not preserve zone information in file attachments setting.
*Rationale*
A user might remove information that indicates a file came from an untrustworthy location."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
User Configuration\Administrative Templates\Windows Components\Attachment Manager\Hide
mechanisms to remove zone information
Impact-Users who have a legitimate need to remove zone information from files will not be able to
do so.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI-3.0|2.2.4,800-53|CM-6,CCE|CCE-9684-2,Level|1S"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments"
reg_item : "HideZoneInfoOnProperties"
reg_ignore_hku_users : "S-1-5-18,S-1-5-19,S-1-5-20"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"2.1.1.1.2 Set 'Do not preserve zone information in file attachments'"
info :"Set 'Do not preserve zone information in file attachments' to 'Disabled' (Scored)
This policy setting allows you to manage whether Windows marks file attachments from
Internet Explorer or Microsoft Outlook® Express with information about their zone of
origin (such as restricted, Internet, intranet, or local). This policy setting requires that files
be downloaded to NTFS disk partitions to function correctly. If zone information is not
preserved, Windows cannot make proper risk assessments based on the zone where the
attachment came from. If the Do not preserve zone information in file attachments setting
is enabled, file attachments are not marked with their zone information. If this policy
setting is disabled, Windows is forced to store file attachments with their zone information.
Because dangerous attachments are often downloaded from untrusted Internet Explorer
zones such as the Internet zone, it is recommended that you configure this policy setting to
Disabled to help ensure that as much security information as possible is preserved with
each file.
*Rationale*
A file that is downloaded from a computer in the Internet or Restricted Sites zone may be
moved to a location that makes it appear safe, like an intranet file share, and executed by an
unsuspecting user."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Disabled.
User Configuration\Administrative Templates\Windows Components\Attachment Manager\Do
not preserve zone information in file attachments
Impact-None, this is the default configuration.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-10166-7,PCI-3.0|2.2.4,800-53|CM-6,Level|1S"
value_type : POLICY_DWORD
value_data : 2
reg_key : "HKU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments"
reg_item : "SaveZoneInformation"
reg_ignore_hku_users : "S-1-5-18,S-1-5-19,S-1-5-20"
reg_option : CAN_BE_NULL
type : REGISTRY_SETTING
description :"2.1.1.1.3 Set 'Notify antivirus programs when opening attachments'"
info :"Set 'Notify antivirus programs when opening attachments' to 'Enabled' (Scored)
Antivirus programs are mandatory in many environments and provide a strong defense
against attack. The Notify antivirus programs when opening attachments setting allows you
to manage how registered antivirus programs are notified. When enabled, this policy
setting configures Windows to call the registered antivirus program and have it scan file
attachments when they are opened by users. If the antivirus scan fails, the attachments are
blocked from being opened. If this policy setting is disabled, Windows does not call the
registered antivirus program when file attachments are opened. To help ensure that virus
scanners examine every file before it is opened, it is recommended that this policy setting
be configured to Enabled in all environments. Note An updated antivirus program must be
installed for this policy setting to function properly.
*Rationale*
Antivirus programs that do not perform on-access checks may not be able to scan
downloaded files."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
User Configuration\Administrative Templates\Windows Components\Attachment
Manager\Notify antivirus programs when opening attachments
Impact-When the Notify antivirus programs when opening attachments setting is Enabled, every
downloaded file or e-mail attachment that the user opens will be scanned.
Default Value-Disabled"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-10076-8,800-53|SI-3,Level|1S,PCI|5.1.1,PCI|5.1"
value_type : POLICY_DWORD
value_data : 3
reg_key : "HKU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments"
reg_item : "ScanWithAntiVirus"
reg_ignore_hku_users : "S-1-5-18,S-1-5-19,S-1-5-20"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"2.1.2.1.1 Set 'Enable screen saver'"
info :"Set 'Enable screen saver' to 'Enabled' (Scored)
This policy setting allows you to manage whether or not screen savers run. If the Screen
Saver setting is disabled screen savers do not run and the screen saver section of the
Screen Saver tab in Display in Control Panel is disabled. If this setting is enabled a screen
saver will run if the following two conditions are met- first, that a valid screen saver is
specified on the client via the Screen Saver Executable Name group policy setting or
Control Panel on the client. Second, the screensaver timeout is set to a value greater than
zero via the Screen Saver Timeout group policy setting or Control Panel on the client.
*Rationale*
If a user forgets to lock their computer when they walk away it’s possible that a passerby
will hijack it."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
User Configuration\Administrative Templates\Control Panel\Personalization\Enable
screen saver
Impact-
The screen saver will automatically activate when the computer has been unattended for
the amount of time specified by the Screen Saver timeout setting. The impact should be
minimal since the screen saver is enabled by default.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "CCE|CCE-10051-1,800-53|CM-7,PCI-3.0|2.2.4,800-53|CM-6,800-53|AC-3,Level|1S,800-53|AC-1"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKU\Software\Policies\Microsoft\Windows\Control Panel\Desktop"
reg_item : "ScreenSaveActive"
reg_ignore_hku_users : "S-1-5-18,S-1-5-19,S-1-5-20"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"2.1.2.1.2 Set 'Screen saver timeout'"
info :"Set 'Screen saver timeout' to 'Enabled:900' or lower (Scored)
If the Screen Saver Timeout setting is enabled, then the screen saver will be launched when
the specified amount of time has passed since the last user action. Valid values range from
1 to 89,400 seconds (24 hours). The setting has no effect if the wait time is set to zero or no
screen saver has been specified.
*Rationale*
If a user forgets to lock their computer when they walk away it’s possible that a passerby
will hijack it."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to 900.
User Configuration\Administrative Templates\Control Panel\Personalization\Screen saver
timeout
Impact-The screen saver will automatically activate when the computer has been unattended for
the amount of time specified. The impact should be minimal since the screen saver is
enabled by default.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI-3.0|2.2.4,CCE|CCE-10148-5,Level|1S,800-53|AC-1"
value_type : POLICY_DWORD
value_data : [MIN..900]
reg_key : "HKU\Software\Policies\Microsoft\Windows\Control Panel\Desktop"
reg_item : "ScreenSaveTimeOut"
reg_ignore_hku_users : "S-1-5-18,S-1-5-19,S-1-5-20"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"2.1.2.1.3 Set 'Password protect the screen saver'"
info :"Set 'Password protect the screen saver' to 'Enabled' (Scored)
If the Password protect the screen saver setting is enabled, then all screen savers are
password protected, if it is disabled then password protection cannot be set on any screen
saver.
*Rationale*
If a user forgets to lock their computer when they walk away it’s possible that a passerby
will hijack it."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled.
User Configuration\Administrative Templates\Control Panel\Personalization\Password
protect the screen saver
Impact-Users will have to provide their logon credentials when they want to access their locked
desktop session.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "800-53|IA-5,PCI-3.0|2.2.4,800-53|CM-6,Level|1S,CCE|CCE-9730-3,800-53|AC-1"
value_type : POLICY_DWORD
value_data : 1
reg_key : "HKU\Software\Policies\Microsoft\Windows\Control Panel\Desktop"
reg_item : "ScreenSaverIsSecure"
reg_ignore_hku_users : "S-1-5-18,S-1-5-19,S-1-5-20"
reg_option : CAN_NOT_BE_NULL
type : REGISTRY_SETTING
description :"2.1.2.1.4 Set 'Force specific screen saver'"
info :"Set 'Force specific screen saver' to 'Enabled:scrnsave.scr' (Scored)
This policy setting allows you to manage whether or not screen savers run. If the Screen
Saver setting is disabled screen savers do not run and the screen saver section of the
Screen Saver tab in Display in Control Panel is disabled. If this setting is enabled a screen
saver will run if the following two conditions are met- first, that a valid screen saver is
specified on the client via the Screen Saver Executable Name group policy setting or
Control Panel on the client. Second, the screensaver timeout is set to a value greater than
zero via the Screen Saver Timeout group policy setting or Control Panel on the client.
*Rationale*
If a user forgets to lock their computer when they walk away it’s possible that a passerby
will hijack it."
solution :"To implement the recommended configuration state, set the following Group Policy setting
to Enabled. Then set the available option to scrnsave.scr.
User Configuration\Administrative Templates\Control Panel\Personalization\Force
specific screen saver
Impact-The screen saver will automatically activate when the computer has been unattended for
the amount of time specified by the Screen Saver timeout setting.
Default Value-Not Configured"
see_also :"https://benchmarks.cisecurity.org/tools2/windows/CIS_Microsoft_Windows_7_Benchmark_v2.1.0.pdf"
#reference : "PCI-3.0|2.2.4,CCE|CCE-9958-0,Level|1S,800-53|AC-1"
value_type : POLICY_TEXT
value_data : "SCRNSAVE.SCR"
reg_key : "HKU\Software\Policies\Microsoft\Windows\Control Panel\Desktop"
reg_item : "SCRNSAVE.EXE"
reg_ignore_hku_users : "S-1-5-18,S-1-5-19,S-1-5-20"