Minor Security Settings

3.2.1 Security Options

Security settings outline many very specific options which can improve a system’s security by protecting against a specific threat.

To edit security settings, select Start | Settings | Control Panel. Double-click

―Administrative Tools,‖ and select ―Local Security Policy‖. In the window that appears, expand Local Policies, and click Security Options. To make changes, double-click one of the settings in the right pane, make the appropriate changes, and click OK to save the settings.

If the workstation is not a member of a domain, the change will become effective immediately, even though it won’t show up in the Local Security Policy editor until it is closed. If the workstation belongs to a domain, local changes will only become effective domain policy does not override the settings.

3.2.1.1 Accounts: Administrator account status

Description: Each Windows installation creates an ―Administrator‖ account which has the highest access to the system. The account has highest level access and can bypass most security controls local to the machine; it is comparable to the ―root‖ account in Unix. Many system maintenance features require use of the Administrator account.

However, in some environments, the existence of this account can present a security risk. By setting the ―Administrator Account Status‖ to disabled, the account becomes

unavailable.

Regardless of this setting, the administrator account remains enabled when booting in ―safe mode.‖

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Accounts: Administrator account status" setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Accounts: Administrator account status" setting in the ―Database Setting‖ column to disabled.

3.2.1.2 Accounts: Guest account status

Description: The Guest account can provide some regulation to unauthenticated users. Disabling this account will prevent unknown users being authenticated as Guests. This default installation disables this account, and it should remain disabled. is disabled by default, and should remain so.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Accounts: Guest account status" setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Accounts: Guest account status" setting in the ―Database Setting‖ column to disabled.

3.2.1.3 Accounts: Limit local account use of blank passwords to console logon only

Description: Windows divides computer logons into two main types: console or local logons and remote logons. In a console logon, the user physically logs on to the device with the attached keyboard. Remote logons are performed across the network using various protocols such as RPC, telnet, FTP and remote desktop.

When this setting is enabled, the computer refuses remote logons if the user attempts to use a blank password, even if the blank password is valid for that account. This setting should be enabled even though passwords should never be left blank.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Accounts: Guest account status" setting.

Options‖. Now set the "Accounts: Guest account status" setting in the ―Database Setting‖ column to ―Enabled‖.

3.2.1.4 Accounts: Rename administrator account

Description: See 3.2.1.1. Often disabling the Administrator account is not practical. However, simply knowing the name of an account on a machine can be valuable

information to an attacker. In an attempt to hide the account, best practices recommend renaming the account to something unique for your implementation.

If the account is renamed, anonymous Security Identifier (SID) / Name translation should also be disabled (3.1.1). This prevents an attacker from locating the renamed account by its SID.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Accounts: Rename administrator account" setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Accounts: Rename administrator account" setting in the ―Database Setting‖ column to ―InNoWayTheAdminAccount‖.

3.2.1.5 Accounts: Rename guest account

Description: See 3.2.1.2. Similar to the Administrator account, the Guest account should be renamed even if it is disabled. The operating system places additional safeguards on the Guest account, and it is less of a target than the Administrator account, but it still deserves significant attention warrant changing the account name.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Accounts: Rename guest account" setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Accounts: Rename guest account" setting in the ―Database Setting‖ column to ―NotTheGuestAccount‖.

3.2.1.6 Audit: Audit the access of global system objects

Description: Global system objects typically only provide interesting audit information to developers. Some examples of these kernel objects include mutexes, semaphores and DOS devices. Normal system operation does not require auditing to this level of detail. ―Audit Object Access (2.2.1.5)‖ must be enabled before this setting will generate log entries.

Caution: Enabling this setting may generate an excessive amount of log entries. Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Audit: Audit the access of global system objects" setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Audit: Audit the access of global system objects" setting in the ―Database Setting‖ column to ―Enabled‖.

3.2.1.7 Audit: Audit the use of Backup and Restore privilege

Description: When enabled, this setting will generate a log entry for every object which is backed up or restored using the ―Backup or Restore‖ user right. During normal

operations, this will generate a large amount of event entries, and is typically not required just stay on top of what users have backup and restore rights and restrict it to only

necessary users.

―Audit Privilege Use (2.2.1.7)‖ must be enabled before this setting will generate log entries.

Caution: Enabling this setting may generate an excessive amount of log entries. Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Audit: Audit the use of Backup and Restore Privilege" setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Audit: Audit the use of Backup and Restore Privilege" setting in the ―Database Setting‖ column to ―Enabled‖.

3.2.1.8 Audit: Shut down system immediately if unable to log security audits

Description: See Event Log Settings 2.2.4. A system administrator may choose not to overwrite events when the event log is full. Assuming that logs are sized appropriately, routinely backed up and cleared, this could indicate a security incident. In the specialized security environment, the inability to log events may be just cause to halt the server. If the server is unable to log events and this setting is enabled, a ―STOP: C0000244 {Audit Failed}‖ error occurs. To recover, a member of the Administrators group must log on to the computer and manually clear the event log or change this setting. This enables the administrator to archive the log entries for analysis to see why the log was full.

Security Log Retention Method must be set to ―Do Not Overwrite Events‖ or ―Overwrite Events by Days‖ for this setting to be effective.

Recommendation Level: 1

Options‖. Now view the "Audit: shut down system immediately if unable to log security audits" setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Audit: shut down system immediately if unable to log security audits" setting in the ―Database Setting‖ column to ―Enabled‖.

3.2.1.9 Devices: Allow undock without having to log on

Description: Can’t a laptop always be undocked simply by lifting it off the dock? Surprisingly, the answer is no. Some laptop docking stations have a hardware eject button that can actually be locked by software on the laptop. Setting this option to disabled provides greater security; however, without proper training a user may

physically damage the hardware. This setting has no effect unless the server is running on a laptop.

Beware of the syntax for this option: Disabled means a user must log in to the laptop and request to undock it; Enabled means the laptop can be unlocked at any time

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Devices: Allow undock without having to log on " setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Devices: Allow undock without having to log on" setting in the ―Database Setting‖ column to ―Disabled‖.

3.2.1.10 DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax.

Description: This setting determines which users or groups can access DCOM applications remotely or locally. Use this to limit attack surface by only setting the minimum set of users run DCOM applications.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax " setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the " DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax " setting in the ―Database Setting‖ column to the ―Distributed COM Users‖ group.

3.2.1.11 DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax.

Description: This setting determines which users or groups can launch DCOM applications remotely or locally. Use this to limit attack surface by only setting the minimum set of users run DCOM applications.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax " setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the " DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax " setting in the ―Database Setting‖ column to the ―Distributed COM Users‖ group.

3.2.1.12 Devices: Allowed to format and eject removable media

Description: This setting governs the type of users which have authority to remove NTFS formatted media from the computer. The available choices (listed from most to least restrictive) are Administrators, Administrators and Power Users, or Administrators and Interactive Users.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Devices: Allowed to format and eject removable media‖ setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Devices: Allowed to format and eject removable media‖ setting in the ―Database Setting‖ column to ―Administrators‖.

3.2.1.13 Devices: Prevent users from installing printer drivers

Description: Users typically need the ability to install and configure their own printers. However, printer driver installation loads code directly into the privileged space of the operating system kernel. The malicious user could choose to install an invalid or Trojan Horse (think back to Troy) print driver to gain control on the system.

Preventing users from installing printer drivers may lead to unwanted support calls. If users must be given the right to install printer drivers, consider requiring that the driver be digitally signed before it can be installed (see 3.2.1.16).

Beware of the syntax for this option: Enabled means the users will not be able to install printer drivers and may prevent proper setup of printers; Disabled allows the user to fully manage their own printers.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Devices: Prevent users from installing printer drivers‖ setting in the ―Database Setting‖ column to ―Enabled‖.

3.2.1.14 Devices: Restrict CD-ROM access to locally logged-on user only

Description: With sufficient privileges, users can create network shares from any folder on a Windows 2003 computer. This extends to sharing a CD-ROM drive externally. This setting would restrict use of the shared CD-ROM drive to the local interactive logon. Since different CDs can be inserted, the user may forget or be unaware that the information on the CD becomes remotely accessible. Also, unlike typical file shares, access control lists can not be placed on files and directories to control access and auditing.

Generally, users and processes should not need to remotely access a workstation CD- ROM drive; however, enabling this setting could cause problems with some software installation packages. When users install software from a CD-ROM drive, and the installation package uses the Microsoft Installer (.msi packages), the Windows Installer service actually performs the installation. The install will fail, since the service account is not actually the locally logged-on user. If this setting is enabled, such software

installation will not be able to proceed, because of this restriction. The setting must be changed long enough to install the software, or the package must be copied to a local or network drive for the installation procedure to succeed.

Beware of the syntax for this option: Enabled means users will not be able to access CD- ROM shares. Disabled allows access to shared CD-ROMs (share-level access

permissions still apply).

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Devices: Restrict CD-ROM access to locally logged-on user only‖ setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Devices: Restrict CD-ROM access to locally logged-on user only‖ setting in the ―Database Setting‖ column to ―Enabled‖.

3.2.1.15 Devices: Restrict floppy access to locally logged-on user only

Description: Similar to a CD-ROM drive (3.2.1.14 above), the floppy drive can be shared to network users. Again, the user may not remember that the information on all inserted floppies becomes exposed.

Beware of the syntax for this option: Enabled means users will not be able to access shared floppy drives. Disabled allows access to shared floppy drives, but share-level access permissions still apply.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Devices: Restrict floppy access to locally logged-on user only‖ setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Devices: Restrict floppy access to locally logged-on user only‖ setting in the ―Database Setting‖ column to ―Enabled‖.

3.2.1.16 Devices: Unsigned driver installation behavior

Description: Drivers interact with the kernel and hardware at a low level; improper drivers can open the system to low level hardware and kernel problems. Additionally, trojaned drivers can open the system to compromise. Microsoft generally ships drivers with a digital signature, expressing that Microsoft itself has certified the drivers through their Windows Hardware Quality Lab. Unfortunately, not all drivers (even from

Microsoft) have digital signatures.

Options for this setting are ―Silently succeed,‖ ―Warn but allow installation,‖ and ―Do not allow installation.‖ The user should be notified if drivers are not signed; however, some end-user training may be required. The ―Silently succeed‖ option may be required in managed environments where unattended software installations are commonplace.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Devices: Unsigned driver installation behavior‖ setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now set the "Devices: Unsigned driver installation behavior‖ setting in the ―Database Setting‖ column to ―Do not allow installation‖.

3.2.1.17 Domain controller: Allow server operators to schedule tasks

Description: When enabled, server operators can add tasks using the AT command. By default, AT runs under the local system account, which has administrative rights on the machine. When this setting is disabled, server operators can still schedule tasks with the task scheduler; however, these tasks will run under their domain credentials and not under the local system account.

This setting has no effect on computers other than Domain Controllers.

Recommendation Level: 1

Audit: Expand "Security Configuration and Analysis" in the Console Root of the Microsoft Management Console. Then expand "Local Policies" and click on ―Security Options‖. Now view the "Domain controller: Allow server operators to schedule tasks‖ setting.

Remediation: Expand "Security Configuration and Analysis" in the Console Root of the