AccessibilitySkip to Top NavigationSkip to Main ContentHome  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 20. Windows Security Policy

10.8.20  Windows Security Policy

10.8.20.1  (03-28-2008)
Purpose

  1. This Internal Revenue Manual (IRM) establishes the minimum security controls and guidance for the use of Windows workstations and servers within the IRS in order to:

    1. Protect the critical infrastructure and assets of the IRS against attacks that exploit Windows workstation and/or servers,

    2. Prevent unauthorized access to IRS workstations and servers,

    3. Enable Windows platforms and servers that meet the security requirements of this policy and support the business needs of the organization.

10.8.20.1.1  (03-28-2008)
Overview

  1. This IRM lays the foundation to implement and manage secure Windows platforms and servers within the IRS.

  2. While the Microsoft Windows operating systems have been a mainstay at many agencies including the IRS and can provide many benefits, these operating systems can also pose significant risks to the critical infrastructure and assets of the IRS if not properly implemented and secured. As new technologies are developed, they become a major source of new vulnerabilities for which security solutions must be developed and implemented.

  3. This IRM establishes a comprehensive policy to implement the minimum security controls to safeguard Windows workstation and servers within the IRS organization.

  4. The Federal Desktop Core Configuration (FDCC) establishes the standard configuration settings for Windows XP. Therefore, it is unacceptable to alter the configuration settings to be more or less restrictive than those defined in this IRM.

    1. Any exception(s) from the requirement stated above, shall be based on business justification, risk assessment, and DAA acceptance of risk. All exceptions shall be documented in the System Security Plan (SSP).

  5. For servers, it is acceptable to configure settings to be more restrictive than those defined in this IRM. This includes but is not limited to:

    1. Setting file/registry permissions to a subset of IRM required setting;

    2. Setting User Rights to a subset of the IRM required setting;

    3. Setting Local Security options and registry keys to a setting documented by the vendor to be more secure than the IRM required setting; and

    4. Disabling additional system services, with the exception of certain services, which increase the system security.

  6. Settings in this IRM, which are listed as "Not Defined " can be set to any operating system available option; however, each setting should be configured to the most secure option that allows for system functionality.

10.8.20.1.2  (03-28-2008)
Scope

  1. This IRM applies to workstations (to include Laptops) and servers utilizing the Microsoft Windows XP Workstation, 2000 Server and Server 2003 operating systems, that store, process, or transmit SBU data or connect to an IRS network or system.

  2. This IRM is binding on all IRS personnel, contractors, and visitors that enter IRS facilities or that have access to IRS information and information systems.

  3. Organizations shall augment the specific security controls in this policy to increase the security levels for a specific Windows platform or server if approved by the responsible Designated Accrediting Authority (DAA).

  4. The following items have been assumed to be out of scope of this IRM:

    1. Windows versions no longer supported by the IRS.

    2. Applications now supported by other IRMs including, but not limited to:
      (i) Database applications, see IRM 10.8.4,Relational Database Management Systems Security Configurations.
      (ii) Wireless applications, see IRM 10.8.40,Wireless Security Policy.
      (iii) Web server applications, see IRM 10.8.42,Web Application/Web Server Security Policy.

10.8.20.1.3  (03-28-2008)
IRM Section Topics

  1. This IRM contains information on the following subjects:

    1. Purpose

    2. General Policy

    3. Management Controls

    4. Operational Controls

    5. Technical Controls

    6. Backup and Recovery Configuration Settings ( Exhibit 10.8.20-1)

    7. Account Policies ( Exhibit 10.8.20-2)

    8. User Password Settings ( Exhibit 10.8.20-3 )

    9. Security Options ( Exhibit 10.8.20-4)

    10. User Rights ( Exhibit 10.8.20-5)

    11. Program Files Folder Permissions ( Exhibit 10.8.20-6)

    12. System Directory (C:\/Winnt\/System32) File and Folder Permissions ( Exhibit 10.8.20-7)

    13. System Drive (C:) File and Folder Permissions ( Exhibit 10.8.20-8)

    14. System Root (C:\/Winnt) File and Folder Permissions ( Exhibit 10.8.20-9)

    15. Server User Home Directories File and Folder Permissions ( Exhibit 10.8.20-10)

    16. Other Drives, Files and Folders File and Folder Permissions ( Exhibit 10.8.20-11)

    17. Group Policy Setting ( Exhibit 10.8.20-12 )

    18. Registry Permissions ( Exhibit 10.8.20-13 )

    19. Registry Configurations ( Exhibit 10.8.20-14 )

    20. DHCP Server Settings ( Exhibit 10.8.20-15 )

    21. Allowable Exceptions for an Active Directory Domain Controller ( Exhibit 10.8.20-16)

    22. Windows Explorer Settings ( Exhibit 10.8.20-17 )

    23. Internet Explorer Configuration Table ( Exhibit 10.8.20-18)

    24. Internet Explorer Zones Configuration Tables ( Exhibit 10.8.20-19)

    25. RDP-TCP (Terminal Services) Configuration Table ( Exhibit 10.8.20-20)

    26. Audit Policy ( Exhibit 10.8.20-21)

    27. Event Log ( Exhibit 10.8.20-22)

    28. System Services ( Exhibit 10.8.20-23)

    29. Common Windows Ports and Descriptions ( Exhibit 10.8.20-24)

    30. Temporary IIS/SQL Settings ( Exhibit 10.8.20-25 )

    31. WINS Server Security Settings ( Exhibit 10.8.20-26 )

    32. Exchange Server Security Settings ( Exhibit 10.8.20-27)

    33. Virtual Machine System Services ( Exhibit 10.8.20-28)

    34. Enterprise Disk Encryption (EDE) Base Servers ( Exhibit 10.8.20-29)

    35. Server Proxy Configuration ( Exhibit 10.8.20-30 )

    36. Internet Explorer Exception Settings for Symantec, Blackberry and Altiris ( Exhibit 10.8.20-31)

    37. Glossary ( Exhibit 10.8.20-32)

    38. References ( Exhibit 10.8.20-33)

    39. IRM 10.8.20 FDCC Deviations ( Exhibit 10.8.20-34 )

10.8.20.1.4  (03-28-2008)
Authority

  1. IRM 10.8.1, Information Technology (IT) Security, Policy, and Guidance, establishes the security program and the policy framework for the IRS.

  2. The requirements and guidance identified in this IRM for Windows workstations and servers shall comply with the following IRMs including, but not limited to:

    1. IRM 10.8.1,IT Security Policy and Guidance

    2. IRM 10.8.3,Audit Logging Security Standards

    3. IRM 10.8.4,Relational Database Management Systems Security Configurations

    4. IRM 10.8.40,Wireless Security Policy

    5. IRM 10.8.42,Web Application/Web Server Security Policy

    6. IRM 10.8.50,Service-wide Security Patch Management

  3. In the event there is a discrepancy between this policy and IRM 10.8.1, IRM 10.8.1 has precedence, unless the security controls/requirements in this policy are more restrictive.

10.8.20.2  (03-28-2008)
General Policy

  1. Product-specific configuration requirements are described in the Exhibits of this IRM and shall be implemented in accordance with the general requirements stated in this IRM.

  2. Windows workstations and servers that are integrated or connected to IRS networks shall be considered part of those networks and comply with IRM 10.8.1.

  3. Workstations and Servers utilizing the Microsoft Windows XP, 2000 Server and Server 2003 operating systems that store, process, or transmit SBU data or connect to an IRS network or system shall obtain Certification and Accreditation (C&A) in accordance with IRM 10.8.1, TD P 85-01, and National Institute of Standards and Technology (NIST) Special Publication (SP) 800-37.

  4. Organizations shall augment the specific security controls in this policy to increase the security levels for a specific Windows platform or server if approved by the responsible DAA.

  5. This IRM shall be regularly evaluated and updated in accordance with IRM 10.8.1.

10.8.20.2.1  (03-28-2008)
Roles and Responsibilities

  1. IRM 10.8.2, Information Technology Security Roles and Responsibilities, defines IRS-wide roles and responsibilities related to IRS information and computer security, and is the authoritative source for such information.

  2. The supplemental requirements provided below are specific to the implementation of IRS Windows servers and workstations, security requirements. Refer to IRM 10.8.2 for additional information regarding organizational and individual responsibilities related to information and computer security.

10.8.20.2.1.1  (03-28-2008)
Information System Owner

  1. The Information System Owner is the agency official responsible for the overall procurement, development, integration, modification, and operation and maintenance of the information system. At the IRS, the Information System Owner is the Business and Functional Unit Owner.

  2. In accordance with IRM 10.8.2, the Information System Owner shall ensure that Windows servers and workstations are properly configured and managed in accordance with the requirements of this IRM.

  3. In addition, the Information System Owner shall have the following responsibilities:

    1. Work with System Administrators (SA) to ensure proper configuration of Windows based operating systems in accordance with this IRM.

    2. Advise the Security Specialist of any technical, operational, or security problems and recommend solutions.

  4. The Business and Functional Unit Owner shall not have System Administrator privileges.

10.8.20.2.1.2  (03-28-2008)
System Administrator (SA)

  1. In accordance with IRM 10.8.2, SAs shall configure windows operating systems within the documented security standards of this IRM.

  2. System administrators shall install and manage servers and workstations software.

10.8.20.2.1.3  (03-28-2008)
Information System Security Officer (ISSO)

  1. The ISSO shall be responsible for coordinating activities that facilitate ensuring the confidentiality, integrity, and availability of assigned IRS systems as defined in IRM 10.8.2.

  2. The ISSO shall provide the necessary coordination to ensure that compliance plans for bringing existing windows operating systems are developed and communicated to IRS management.

10.8.20.2.1.4  (03-28-2008)
Security Specialist (SecSpec)

  1. The Security Specialist (SecSpec) also known as the Security Admins Group is responsible for reviewing all activity of administrators and responsible for administration of IT equipment.

  2. The SecSpec shall be responsible for ensuring that SAs and others having daily operational responsibilities for IRS Windows servers and workstations comply with the security requirements of this IRM. The SecSpec is not expected to personally implement the requirements but shall ensure that others do so. All SecSpec responsibilities identified in this IRM shall be in addition to the SecSpec responsibilities defined in IRM 10.8.2.

  3. The SecSpec shall report IRM non-compliance issues initially to Information System Owner and SAs for resolution, and escalate non-compliance reporting to IRS management officials as necessary to bring systems into compliance with this IRM.

  4. The SecSpec shall not have operating System Administrator privileges.

10.8.20.2.2  (03-28-2008)
Windows Roles and User Groups

  1. All windows specific roles/groups are defined in the Windows Roles and User Groups section of this IRM. See IRM 10.8.20.5.2.1.

10.8.20.3  (03-28-2008)
Management Controls

  1. The IRS shall implement management security controls to mitigate risk of IT applications and electronic information loss in order to protect the organization's mission. See IRM 10.8.1 for general information and computer security management control requirements.

  2. Additional management controls specific to Windows Security Configurations are provided below in the following areas:

    1. Risk Assessment

    2. System and Services Acquisition

    3. Certification, Accreditation, and Security Assessments

    4. Network Security

    5. Continuing Security

10.8.20.3.1  (03-28-2008)
Risk Assessment

  1. Risk assessments of Windows computers shall be conducted using this guide along with the Security Checklists provided in the exhibits. Deficiencies in conformance to the Security Checklists shall be documented in risk assessment reports and brought to the attention of the system’s DAA.

  2. Microsoft Windows machines shall not be used if they are not compliant with the security compliance levels/thresholds established by Cybersecurity. See IRM 10.8.1, Risk Assessment Section.

  3. Microsoft Windows machines shall not be used if they contain high risk items, regardless of the compliance level of the windows machine. The list of high risk items are identified/listed below:

    1. Ensure proper password complexity requirements.

    2. Ensure password not stored using reversible encryption.

    3. Ensure disk partitions use NTFS.

    4. Ensure proper service pack level.

    5. Ensure anonymous users not being allowed to enumerate accounts in the SAM database.

    6. Not permit anonymous access to SAM accounts and shares.

    7. Ensure automatic administrator logon is not enabled.

    8. Require at least 128 bit encryption for the operating system and browser.

    9. Enable Restrict anonymous access to Named Pipes and Shares.

    10. Have approved and current AntiVirus software installed with current definitions.

    11. Ensure AntiVirus software is running and has proper startup state.

    12. Ensure no unsupported operating systems are in use.

    13. Ensure default SNMP Public and Private strings do not exit.

    14. Ensure Everyone permissions do not apply to anonymous users.

    15. Ensure Hummingbird Application is not installed on Servers.

    16. Ensure the following Hummingbird Components are not installed on Workstations:
      (a) Trivial FTP Daemon
      (b) Telnet Daemon
      (c) FTP Daemon

    17. Ensure the following services are either not installed or disabled:
      (a) Trivial FTP Daemon (TFTP)
      (b) FTP Publishing service
      (c) Telnet service
      (d) Server for NFS service
      (e) Remote Shell service
      (f) Bluetooth Support service
      (g) Wireless Zero Configuration service

10.8.20.3.2  (03-28-2008)
System and Services Acquisition

  1. Software products covered by this IRM shall be acquired, accounted for, and inventoried in accordance with IRM 10.8.1.

  2. Software products covered by this IRM shall adhere to IRS Enterprise Life Cycle (ELC) requirements, in accordance with IRM 10.8.1.

10.8.20.3.3  (03-28-2008)
Certification, Accreditation, and Security Assessments

  1. All Microsoft Windows machines shall obtain C&A in accordance with IRM 10.8.1.

  2. Only authorized Microsoft Windows software that is certified and accredited shall be used within the organization.

  3. Microsoft Windows machines shall not be used until they are in proper compliance as defined in System and Services Acquisition, above. See IRM 10.8.20.3.2.

10.8.20.3.4  (03-28-2008)
Network Security

  1. All computers connected to the IRS LAN shall reside in an approved Domain, except for public web servers. Please refer to IRM 10.8.42, Web Application/Web Server Security for additional guidance.

  2. The number of accounts with administrative privileges that exist on a Workstation or Member server shall be kept to the minimal possible.

  3. The System Administrator shall ensure Internet Protocol version 6 (IPv6) is not used.

  4. Due to the security risks associated with rogue implementations of IPv6, only organizations that have received approval from Cybersecurity, the IPv6 Transition Office, and the system's Designated Accrediting Authority (DAA) are authorized to utilize IPv6 on IRS development and production networks.

10.8.20.3.5  (03-28-2008)
Continuing Security

  1. All Microsoft Windows computers shall be kept current with the latest security patches and updates. Microsoft publishes monthly security updates which shall be downloaded, tested and applied, if applicable, in a timely manner. Microsoft's site should also be monitored for critical patches that might come out of cycle. Patches are only to be applied by authorized personnel. See the IRM 10.8.50,Service-wide Security Patch Management for complete guidance.

  2. The availability of resources (e.g., free disk space, processor usage, server password errors, etc.) shall be monitored.

10.8.20.4  (03-28-2008)
Operational Controls

  1. The IRS shall implement operational security controls, which are primarily implemented and executed by personnel for each information system. See IRM 10.8.1 for general information and computer security operational control requirements.

  2. Operational controls often require technical or specialized expertise and rely on management activities as well as technical controls.

  3. Additional operational controls specific to Windows Security Configurations are provided below in the following areas:

    1. Contingency Planning

    2. Configuration Management (CM)

    3. Updates, Patching and Hotfixes

    4. Defining Functional Roles

10.8.20.4.1  (03-28-2008)
Contingency Planning

  1. Recovery operations to restore systems shall be reflected in the Information Technology Contingency Plan (ITCP) and incorporated into recovery operational procedures, and shall be tested and validated in accordance with IRM 10.8.1.

10.8.20.4.1.1  (03-28-2008)
Disaster Recovery

  1. The Business and Functional Unit Owner shall ensure that disaster recovery plans include actions to continue processing in the event of unplanned events. Successful recovery, whether from hard disk crashes, power failures, or unintentional/intentional actions, depends upon the following critical components below.

  2. The Business and Functional Unit Owner shall determine whether Windows operating systems or Windows system restoration shall be performed via imaging, installation scripts, restoration from backup tape or emergency repair disks.

10.8.20.4.1.1.1  (03-28-2008)
Emergency Repair Disk / Automated System Recovery

  1. The Emergency Repair Disk (ERD) for Windows 2000 and Automated System Recovery (ASR) tool for Windows XP and Windows 2003 is a critical part of the recovery process, helping administrators to recover the Windows configurations from a normally unrecoverable state. The ERD/ASR contains system recovery information about the computer.

  2. The ERD/ASR assists in recovery by:

    1. Repairing bad registry data;

    2. Restoring corrupted or missing files on the system partition;

    3. Replacing a corrupt kernel, the core of the Windows operating system.

  3. The ERD/ASR is not a complete solution for full recovery of the system. A backup utility shall be used in conjunction with the ERD/ASR to fully recover from a disaster, since the ERD/ASR:

    1. Does not contain a full backup of the registry;

    2. Cannot fully restore the system partition information;

    3. Cannot repair unmountable partitions except for the system partition (normally C:\/); and

    4. Does not replace a damaged NTFS boot sector.

  4. A system shall be restored using the bootable operating system installation CD-ROM or bootable setup disks, if the ERD/ASR is not bootable.

  5. Once a system has been restored, the latest approved service pack and latest security patches shall be reinstalled to ensure correct file systems exist on the system.

  6. Periodic updates of the ERD/ASR shall be part of the standard operating procedures.

10.8.20.4.1.1.2  (03-28-2008)
System Backup

  1. To protect both the operating system and data, the Business and Functional Unit Owner shall ensure that regular server backups occur on a consistent basis and that backups are verified to be in working order. Various strategies are included in documentation for the Service-wide mandatory Windows backup/restore utility.

  2. At a minimum, Veritas (Backup Exec) Version 8.0 or higher, is required for backup purposes.

  3. Disk mirroring/duplexing and RAID (Redundant Array of Inexpensive Disks) systems are viable alternatives for server fault tolerance, but do not replace backups.

  4. Backup tapes shall be stored either remotely (at a backup site) or off-premise, per the Business and Functional Unit Owners, disaster recovery plan. The preferred method is remote backup routines from another IRS site. Since the current version of the COTS backup software does not encrypt data, proper protection and handling shall be afforded to the backup media.

  5. Workstation backups are the responsibility of the user, unless modified by local policy. To accomplish backups of workstations, workstations shall be configured, allowing authenticated users read, write, execute (RWX) access to the backup file to allow Encrypting File System (EFS) files to be backed up in an encrypted format.

  6. The criteria for users performing their own EFS backup is that the backup file created shall be stored in a password-protected folder that only the user has access too. This mechanism will prevent unauthorized users from restoring the backup files of other users or gaining access to any non-encrypted data that may have been backed up.

    • See Exhibit 10.8.20-1, Backup and Recovery Configuration Settings are contained therein.

10.8.20.4.1.2  (03-28-2008)
Recovery Console Security Options

  1. Below is an explanation of the Windows specific Security Options dealing with the Recovery Console.

  2. Recovery console: Allow automatic administrative logon. The Recovery Console, provides a limited command-line access to an otherwise unbootable operating system. The console allows access to the NTFS file system, which does not natively allow access when the Windows operating system becomes unbootable. Other third-party applications have been developed to perform this action as well, but the Recovery Console is part of the Windows operating system. It can be installed from the Windows CD, and can also be run directly from the Windows installation CD.

  3. Recovery console: Allow floppy copy and access to all drives and all folders. By default, the Recovery Console only allows access to the root folder of each drive, and the operating system folder (typically C:\/Windows). The console also prevents the copying of files from the hard drive onto removable media.

    • See Exhibit 10.8.20-4,, Security Options. The Recovery Console Security Options are contained therein.

    • See Exhibit 10.8.20-32., Glossary under "Recovery Console" .

10.8.20.4.2  (03-28-2008)
Configuration Management (CM)

  1. The IRS shall establish and maintain baseline configurations and inventories of organizational information systems, establish and enforce security configuration settings for Information Technology (IT) products employed in organizational information systems, and monitor and control changes to the baseline configurations of organizational information systems throughout the respective system development life cycles; in accordance with IRM 10.8.1.

  2. In order to meet standards mandated by OMB and Treasury, FDCC and SCAP compliance is required. The standard installation, operation, maintenance, update, and/or patching of software shall not alter the configuration settings from the approved FDCC Windows desktop configuration. The information technology should also use the Windows Installer Service for the installation to the default "program files" directory and should be able to silently install and uninstall.

10.8.20.4.2.1  (03-28-2008)
Windows Architecture

  1. The Windows security architecture includes the following subsystem components:

    1. Security Identifiers (SIDs) - Users are identified by their unique SID, not their user name. The security subsystem generates a unique SID at the time the account is created. The generated SID is guaranteed to be unique-no other user in the system, or any other system, currently has or will have the same SID. SIDs are unique and cannot be reused. Windows generates a SID using a proprietary hashing function based on the current system time, the amount of execution time the current process has used in the user mode, and the computer name or domain name. The domain name is dependent on whether the account is created within the Computer Management MMC or AD Users and Computers. These three factors, used in conjunction with the hashing function, provide a SID that is virtually guaranteed to be unique.

    2. Access Control List (ACL) – Is a list of the sets of attributes associated with an object, and the users (or SIDs) who may exercise these attributes. The list of attributes and users is represented in a structure known as an Access Control Entry (ACE). Therefore, an ACL is a list of ACEs. Each ACE contains access or auditing permissions to an object for one user or group. Each object has a pair of ACLs associated with it:
      • A Discretionary ACL, representing rights which may be assigned; and
      • The System ACL which is set by the system security policies.

    3. Objects - Almost everything in the Windows Operating Systems are represented as objects. This includes memory devices, system processes, threads, and desktop windows. An object is a self-contained entity that contains its own data and the functions needed to manipulate that data. Objects contain data and information on whom or what processes can access that data/resource.

    4. Local Security Authority (LSA) - As the central component of the security subsystem, the LSA generates access tokens, manages security policies on the local computer, and facilitates user logon authentication. The LSA interacts with other parts of the security architecture, such as the SAM, to provide the overall secure system.

    5. Security Account Manager (SAM) - The SAM maintains a database of all local user and group account information (as well as domain user accounts when in Windows server mode). During the logon process, the SAM verifies and identifies users by comparing the authentication data, such as passwords, from its database to data entered by a user. It interacts with the LSA to validate users’ requests.

    6. Security Reference Monitor (SRM) - The SRM is the enforcer of the system and the primary element of the security subsystem. This component, fixed in kernel mode, prevents direct access to objects by any user or process that does not have the proper permissions.

    7. When a user wishes to access a named object, the SRM provides services to check whether the user has the right to access that object. It then provides information on success or failure, and generates any necessary audit messages to be logged by the LSA. Although SRM runs in kernel mode, it responds equally to both user and system authorization requests.

      • See Exhibit 10.8.20-32., Glossary. Definitions for Windows Subsystem Components are contained therein.

10.8.20.4.2.2  (03-28-2008)
Installation

  1. The latest available and tested version and Service Pack level of Windows 2000, 2003 and XP operating system shall be employed.

  2. All Microsoft Windows operating systems shall be configured using the standard IRS Workstation and Server configurations.

  3. Offices utilizing imaging or cloning software/support shall ensure that unique SIDs are generated for each system. To verify uniqueness for the process, the SID can be viewed in each system’s registry. To ensure uniqueness, the Microsoft Sysprep Tool shall be used. The MITS organization has created an unattended installation that shall be used for installing and setting up Windows Server 2003 systems.

  4. During installation the following BIOS options shall be set for all workstations and laptops:

    1. The CMOS (or BIOS) password shall be ENABLED if data sensitivity is of a high nature. This feature will prevent unauthorized users from booting systems with widely available utilities and bypassing NTFS security controls.

    2. The Multi-Boot option should be set to DISABLED.

    3. The CDROM and FLOPPY Boot shall be set to DISABLED.

    4. The ‘Fan always on while on AC Power’ shall be ENABLED.

    5. LAN/WAN Switching shall be set to DISABLED.

  5. The New Technology File System (NTFS) shall be installed on all systems in order to implement the Windows security architecture; No FAT or FAT32 partitions are permitted.

  6. Computer games shall not be installed on any Microsoft Windows operating systems. Default Windows games shall be unchecked during installation.

  7. The Microsoft Security Configuration Tool Set allows files to be created, which can then be applied to install the security configurations onto the workstations and/or member servers. The IRS has copies of .INF files, which will be used to apply security, as recommended by the IRS.

  8. While all details of the security configuration shall be provided in this document, automated tools shall be used to apply and validate security to ensure the consistency of application and validation of these settings.

  9. Security tools shall be provided for use by the SecSpec (and other authorized users when appropriate) to enable analysts to work with the administrators to validate the configuration of the systems and networks. See IRM 10.8.2, IT Security Roles and Responsibilities, for more information.

10.8.20.4.2.3  (03-28-2008)
General Configuration

  1. The following are the general configuration requirements for the Windows environment.

10.8.20.4.2.3.1  (03-28-2008)
System Date and Time

  1. The Windows operating systems system date and time are critical to the integrity of event log recordings.

  2. The time zone shall be either manually set during system setup (since unattended installations have shown to provide unpredictable results) or verified as accurate in a post-implementation review.

  3. The SA shall ensure that all Windows operating systems domains shall utilize a time synchronization process to ensure each server and workstation system time is synchronized, through network resources, or with an approved external official atomic clock (e.g., utilize a border router for synchronizing with the Naval Observatory clock or synchronize to www.time.nist.gov).

  4. If users work off site for extended periods, these users may be placed in a domain group, allowing additional permissions to change time. The risk of time differences will be mitigated with time synchronization, which will take place at the next domain logon.

10.8.20.4.2.3.2  (03-28-2008)
Hibernation and Power Management

  1. Hibernation allows a user to close a laptop, while still remaining in an active session, to transport the system from one point to another.

  2. Hibernation shall not be used unless the system is physically within control of the person assigned to that laptop.

  3. Hibernation shall not be used on servers.

  4. When Windows server systems are used as monitors, in computer rooms, the power management shall be configured to allow monitor to operate.

  5. Power management may be used if the power management settings do not hinder operational processes. Monitors should be turned off during non-working hours and when the machines are not in use.

  6. For desktops, the monitors should be turned off during non-working hours when the machines are not in use.

10.8.20.4.2.3.3  (03-28-2008)
Laptop Configuration

  1. Although DHCP is utilized service-wide, operational experience has demonstrated the need to release IP numbers when employees are in differing IRS offices prior to IP release time frames. Unless DHCP properly releases the IP number, laptop users may be provided a shortcut to "ipconfig /release " executable.

  2. All laptop users shall use the EFS file encryption to ensure that sensitive files and data directories, are protected, when laptops are used in non-IRS areas. See the Encrypted File System (EFS) section of this IRM ( IRM 10.8.20.5.4.3.1.) for more information on file encryption.

  3. For specific guidance related to the protection of laptop computers, please refer to IRM 10.8.26, Laptop Computer Security Policy.

  4. The following BIOS options, in addition to those stated in the Installation section of this IRM ( see IRM 10.8.20.4.2.2), shall be set as follows for all IRS laptops:

    1. The following boot order shall be set:
      (1) Notebook Hard Drive (ENABLE),
      (2) Notebook Multibay (DISABLE),
      (3) Floppy Drive (DISABLE),
      (4) USB Super Disk (DISABLE),
      (5) USB CD-ROM (DISABLE),
      (6) USB Hard Disk (DISABLE),
      (7) Notebook Ethernet (DISABLE).

    2. The Infrared Port shall be DISABLED.

    3. Embedded WLAN Device Radio shall be set to DISABLED.

    4. Embedded Bluetooth Device Radio shall be set to DISABLED in the BIOS for each laptop in the field until further notice.

      Note:

      Bluetooth is currently DISABLED within the operating system. Once the Bluetooth technology is approved by IRS, the operating system will be altered according to regulations. Users are currently restricted from using this process and should conform to IRS regulations.

    5. Intel Execution shall set to DISABLED for all laptops.

10.8.20.4.2.3.4  (03-28-2008)
Recycle Bin

  1. Use of the Recycle Bin is authorized.

    1. There is one Recycle Bin per hard drive; not one per user.

    2. The Windows operating system has an invisible (i.e., hidden) directory called RECYCLER, which stores a copy of recently deleted files and is used to maintain a copy of data marked for deletion until it is permanently removed from the Recycle Bin. In a default configuration, the Windows virtual memory page file is not wiped clean during any type of system shutdown.

    3. Encrypted files using EFS, when deleted, are unencrypted in the Recycle Bin.

  2. When using the Recycle Bin, users are responsible for emptying it.

10.8.20.4.2.4  (03-28-2008)
Updates, Patching and Hotfixes

  1. Computing systems are vulnerable to attacks from external sources, when they do not have the most current versions of software security patches and Hotfixes applied to their computer systems.

  2. See IRM 10.8.50,Service-wide Security Patch Management for complete guidance on patches, hotfixes and updates.

10.8.20.4.2.5  (03-28-2008)
Defining Functional Role(s)

  1. Servers or workstations shall be configured to save information that identifies the functional role or roles that a server or workstation performs by using one of the two methods below. This allows automated compliance checking tools to review the computer based on defined settings for the functional role(s). If no user defined functional role is found, the server or workstation is assumed to be a baseline server/workstation with no specific roles.

  2. There are two acceptable methods to properly identify the functional role or roles for a server/workstation.
    GPO Naming Convention

    1. If a computer is part of an Active Directory Domain, the functional role can be set by placing the computer in an OU, which is linked to a GPO that includes a descriptive identifier for the functional role.

    2. The GPO Names shall include one or more of the following key words (exception (c) below). Note that the exact name does not have to follow any specific format, it only shall include one of the following keywords:
      (1) DHCP
      (2) Domain Controller
      (3) IIS
      (4) Member Server Baseline
      (5) Print
      (6) SQL
      (7) WINS
      (8) Exchange
      (9) Virtual Machine

      Note: