Figure 2-1. The Facets of Windows XP Security
The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.
NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), "Securing Agency Information Systems", as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.
This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.
Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.
This publication seeks to assist IT professionals in securing Windows XP workstations, XP mobile computers, and XP computers used by telecommuters within various environments. This guidance should only be applied throughout an enterprise by trained and competent system administrators. Although some of the guidance presented in this document may be applicable to multiple versions of Windows XP, the guidance is specifically intended for Windows XP Professional systems running Service Pack 2.
The guide provides detailed information about the security features of Windows XP, security configuration guidelines for popular applications, and security configuration guidelines for the Windows XP operating system. The guide documents the methods that IT professionals can use to implement each security setting recommended. The principal goal of the document is to recommend and explain tested, secure settings for Windows XP workstations with the objective of simplifying the administrative burden of improving the security of Windows XP systems in four types of environments: SOHO, enterprise, specialized security-limited functionality, and legacy. The proposed controls are consistent with the minimum security controls for an IT system as represented in the NIST SP 800-53 publication. This guide and its associated templates have been created in support of the NIST Security Configuration Checklists Program for IT Products.
This document has been created for IT professionals, particularly Windows XP system administrators and information security personnel. The document assumes that the reader has experience installing and administering Windows-based systems in domain or standalone configurations. The document discusses in technical detail various Windows XP security registry and application settings.
Throughout this guide, filenames, menu items, and options are indicated through bold text (e.g., Remember my password). The remainder of this document is organized into eight major sections, followed by seven appendices.
- Section 2 provides insight into the threats and security controls that are relevant for various environments, such as a large enterprise or a home office, and describes the need to document, implement, and test controls, as well as monitor and maintain systems on an ongoing basis.
- Section 3 presents an overview of the security components offered by Windows XP.
- Section 4 provides guidance on installing, backing up, and patching Windows XP systems.
- Section 5 discusses security policy configuration and how security templates can best be used.
- Section 6 provides an overview of the settings in the NIST security templates and explains how the settings can provide better security for systems.
- Section 7 discusses how to apply additional security settings not included in the NIST templates.
- Section 8 demonstrates securing popular office productivity tools, Web browsers, e-mail clients, personal firewalls, antivirus software, and spyware detection and removal utilities.
- Section 9 provides guidance to IT professionals on how to use the guide effectively to secure Windows XP systems.
- Appendix A contains lists of the Windows XP security settings modified by the NIST security templates.
- Appendix B maps the guide's security controls and template settings to the controls in NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems.
- Appendix C lists TCP and UDP ports that are commonly used on Windows XP systems.
- Appendix D lists tools that may be helpful in securing Windows XP systems, and Appendix E lists print and online resources that may be useful Windows XP security references.
- Appendix F lists acronyms used in this document.
- Appendix G contains the index for the document.
IT professionals should read the entire publication, including the appendices, before using the security templates or implementing any of the other recommendations or suggestions in the guide. Readers with limited Windows XP administration and security experience are cautioned not to apply the templates or recommendations to systems on their own. As described in Section 9, effective use of this publication involves extensive planning and testing.
In today's computing environment, the security of all computing resources, from network infrastructure devices to users' desktop computers, is essential. There are many threats to users' computers, ranging from remotely launched network service exploits to malware spread through e-mails, Web sites, and file downloads. Increasing the security of individual computers protects them from these threats and reduces the likelihood that a system will be compromised or that data will be disclosed to unauthorized parties. Effective and well-tested security configurations means that less time and money is spent eradicating malware, restoring systems from backups, and reinstalling operating systems and applications. In addition, having stronger host security increases network security (e.g., home, business, government, the Internet); for example, most distributed denial of service attacks against networks use large numbers of compromised hosts.
The goal of this guide is to provide security configuration guidance to the users and system administrators of Microsoft Windows XP systems. This advice can be adapted to any environment, from individual SOHO installations to large geographically diverse organizations. Although the guide is primarily targeted toward business environments and Windows XP Professional, some of the guidance is also appropriate for other XP versions, such as Windows XP Home, Windows XP Tablet PC Edition, and Windows XP Media Center Edition.3 This guide draws on a large body of vendor knowledge and government and security community experience gained over many years of securing computer systems.
This section of the guide is based largely on the steps proposed in NIST’s FISMA Implementation Project for achieving more secure information systems.4 Sections 2.1 and 2.2 address the need to categorize information and information systems. Each Windows XP system can be classified as having one of three roles; each system can also be classified according to the potential impact caused by security breaches. Section 2.3 describes threats and provides examples of security controls that can mitigate threats. Section 2.4 outlines the primary types of environments for information systems - SOHO, Enterprise, Specialized Security-Limited Functionality, and Legacy - and ties each environment to typical threat categories and security controls. Section 2.5 provides a brief overview of the implementation of the security controls and the importance of performing functionality and security testing. Finally, Section 2.6 discusses the need to monitor the security controls and maintain the system. Figure 2-1 shows the six facets to Windows XP security that are covered in Sections 2.1 through 2.6.
Figure 2-1. The Facets of Windows XP Security
Windows XP security should take into account the role that the system plays. For the purposes of this guide, Windows XP systems can be divided into three roles: inward-facing, outward-facing, and mobile.
Inward-Facing: An inward-facing XP system is typically a user workstation on the interior of a network that is not directly accessible from the Internet. Physical access is also generally limited in some manner (e.g., only employees have access to the work area). In many environments, inward-facing systems share a common hardware and software configuration because they are centrally deployed and managed (e.g., Microsoft domains, Novell networks). Because an inwardfacing system is usually in the same environment all the time (e.g., desktop on the corporate local area network [LAN]), the threats against the system do not change quickly. In general, inwardfacing systems are relatively easy to secure, compared to outward-facing and mobile systems.
Outward-Facing: An outward-facing XP system is one that is directly connected to the Internet. The classic example is a home computer that connects to the Internet through dial-up or broadband access. Such a system is susceptible to scans, probes, and attacks launched against it by remote attackers. It typically does not have the layers of protection that an inward-facing system typically has, such as network firewalls and intrusion detection systems. Outward-facing systems are often at high risk of compromise because they have relatively high security needs, yet are typically administered by users with little or no security knowledge. Also, threats against outward-facing systems may change quickly since anyone can attempt to attack them at any time.
Mobile: A system with a mobile role typically moves between a variety of environments and physical locations. For network connectivity, this system might use both traditional wired methods (e.g., Ethernet, dialup) and wireless methods (e.g., IEEE 802.11). The mobility of the system makes it more difficult to manage centrally. It also exposes the system to a wider variety of threat environments; for example, in a single day the system might be in a home environment, an office environment, a wireless network hotspot, and a hotel room. An additional threat is the loss or theft of the system. This could lead to loss of productivity at a minimum, but could also include the disclosure of confidential information or the possible opening of a back door into the organization if remote access is not properly secured.
This section discusses the most significant security features inherited from Windows 2000: Kerberos, smart card support, Internet Connection Sharing, Internet Protocol Security, and Encrypting File System. For each security feature, the section includes a brief description, an analysis of the security impact of each feature, and general recommendations for when the feature should or should not be used. It is outside the scope of this document to cover the features in great depth, so pointers to resources with additional information are provided as needed.
The classic model for information security defines three objectives of security: maintaining confidentiality, integrity, and availability. Confidentiality refers to protecting information from being accessed by unauthorized parties. Integrity refers to ensuring the authenticity of information—that information is not altered, and that the source of the information is genuine. Availability means that information is accessible by authorized users. Each objective addresses a different aspect of providing protection for information.
Determining how strongly a system needs to be protected is based largely on the type of information that the system processes and stores. For example, a system containing medical records probably needs much stronger protection than a computer only used for viewing publicly released documents. This is not to imply that the second system does not need protection; every system needs to be protected, but the level of protection may vary based on the value of the system and its data. To establish a standard for determining the security category of a system, NIST created Federal Information Processing Standards (FIPS) Publication (PUB) 199, Standards for Security Categorization of Federal Information and Information Systems.5 FIPS PUB 199 establishes three security categories-low, moderate, and high-based on the potential impact of a security breach involving a particular system. The FIPS PUB 199 definitions for each category are as follows:
The potential impact is LOW if the loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. A limited adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced; (ii) result in minor damage to organizational assets; (iii) result in minor financial loss; or (iv) result in minor harm to individuals.
The potential impact is MODERATE if the loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. A serious adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced; (ii) result in significant damage to organizational assets; (iii) result in significant financial loss; or (iv) result in significant harm to individuals that does not involve loss of life or serious life threatening injuries.
The potential impact is HIGH if the loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals. A severe or catastrophic adverse effect means that, for example, the loss of confidentiality, integrity, or availability might (i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions; (ii) result in major damage to organizational assets; (iii) result in major financial loss; or (iv) result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries.
Each system should be protected based on the potential impact to the system of a loss of confidentiality, integrity, or availability. Protection measures (otherwise known as security controls) tend to fall into two categories. First, security weaknesses in the system need to be resolved. For example, if a system has a known vulnerability that attackers could exploit, the system should be patched so that the vulnerability is removed or mitigated. Second, the system should offer only the required functionality to each authorized user, so that no one can use functions that are not necessary. This principle is known as least privilege. Limiting functionality and resolving security weaknesses have a common goal: give attackers as few opportunities as possible to breach a system.
Although each system should ideally be made as secure as possible, this is generally not feasible because the system needs to meet the functional requirements of the system’s users. Another common problem with security controls is that they often make systems less convenient or more difficult to use. When usability is an issue, many users will attempt to circumvent security controls; for example, if passwords must be long and complex, users may write them down. Balancing security, functionality, and usability is often a challenge. This guide attempts to strike a proper balance and make recommendations that provide a reasonably secure solution while offering the functionality and usability that users require.
Another fundamental principle endorsed by this guide is using multiple layers of security. For example, a host may be protected from external attack by several controls, including a network-based firewall, a host-based firewall, and OS patching. The motivation for having multiple layers is that if one layer fails or otherwise cannot counteract a certain threat, other layers might prevent the threat from successfully breaching the system. A combination of network-based and host-based controls is generally most effective at providing consistent protection for systems.
NIST SP 800-53, Recommended Security Controls for Federal Information Systems, proposes minimum baseline management, operational, and technical security controls for information systems.6 These controls are to be implemented based on the security categorizations proposed by FIPS 199, as described earlier in this section. This guidance should assist agencies in meeting baseline requirements for Windows XP Professional systems deployed in their environments.
To secure a system, it is essential first to define the threats that need to be mitigated. This knowledge of threats is also key to understanding the reasons the various configuration options have been chosen in this guide. Most threats against data and resources are possible because of mistakes—either bugs in operating system and application software that create exploitable vulnerabilities, or errors made by users and administrators. Threats may involve intentional actors (e.g., an attacker who wants to access credit cards on a system) or unintentional actors (e.g., an administrator who forgets to disable user accounts of a terminated employee). Threats can be local, such as a disgruntled employee, or remote, such as an attacker in another country. The following sections describe each major threat category, list possible controls, provide examples of threats, and summarize the potential impact of the threat. The list of threats is not exhaustive; it simply represents the major threat categories that were considered during the selection of the security controls as described in this guide. Organizations should conduct risk assessments to identify the specific threats against their systems and determine the effectiveness of existing security controls in counteracting the threats, then perform risk mitigation to decide what additional measures (if any) should be implemented.
This section has describes various types of local and remote threats that can negatively impact systems. The possible controls listed for the threats are primarily technical, as are the controls discussed throughout this document. However, it is important to further reduce the risks of operating a Windows XP system by also using management and operational controls. Examples of important operational controls are restricting physical access to a system; performing contingency planning;12 backing up the system, storing the backups in a safe and secure location, and testing the backups regularly; and monitoring Microsoft mailing lists for relevant security bulletins. Management controls could include developing policies regarding Windows XP system security and creating a plan for maintaining Windows XP systems. By selecting and implementing management, operational, and technical controls for Windows XP, organizations can better mitigate the threats that Windows XP systems may face.
Another reason to use multiple types of controls is to provide better security in situations where one or more controls are circumvented or otherwise violated. This may be done not only by attackers, but also by authorized users with no malicious intent. For example, taping a list of passwords to a monitor for convenience may nullify controls designed to prevent unauthorized local access to that system. Establishing a policy against writing down passwords (management control), educating users on the dangers of password exposure (operational control), and performing periodic physical audits to identify posted passwords (operational control) may all be helpful in reducing the risks posed by writing down
Local threats either require physical access to the system or logical access to the system (e.g., an authorized user account). Local threats are grouped into three categories: boot process, unauthorized local access, and privilege escalation.
- Threat: An unauthorized individual boots a computer from third-party media (e.g., removable drives, Universal Serial Bus [USB] token storage devices). This could permit the attacker to circumvent operating system (OS) security measures and gain unauthorized access to information.
- Examples:
- While traveling, an employee misplaces a laptop, and the party that acquires it tries to see what sensitive data it contains.
- A disgruntled employee boots a computer off third-party media to circumvent other security controls so the employee can access sensitive files (e.g., confidential data stored locally, local password file).
- Impact: Unauthorized parties could cause a loss of confidentiality, integrity, and availability.
- Possible Controls:
- Implement physical security measures (e.g., locked doors, badge access) to restrict access to equipment.
- Enable a strong and difficult-to-guess password for the Basic Input Output System (BIOS), and configure the BIOS to boot the system from the local hard drive only, assuming that the case containing the OS and data is physically secure. This will help protect the data unless the hard drive is removed from the computer.
- Secure local files via encryption to prevent access to data in the event the physical media is placed in another computer.
- Threat: An individual who is not permitted to access a system gains local access.
- Examples:
- A visitor to a company sits down at an unattended computer and logs in by guessing a weak password for a default user account.
- A former employee gains physical access to facilities and uses old credentials to log in and gain access to company resources.
- Impact: Because the unauthorized person is masquerading as an authorized user, this could cause a loss of confidentiality and integrity; if the user has administrative rights, this could also cause a loss of availability.
- Possible Controls:
- Require valid username and password authentication before allowing any access to system resources, and enable a password-protected screen saver. These actions help to prevent an attacker from walking up to a computer and immediately gaining access.
- Enable a logon banner containing a warning of the possible legal consequences of misuse.
- Implement a password policy to enforce stronger passwords, so that it is more difficult for an attacker to guess passwords.
- Do not use or reuse a single password across multiple accounts; for example, the password for a personal free e-mail account should not be the same as that used to gain access to the Windows XP host.
- Establish and enforce a checkout policy for departing employees that includes the immediate disabling of their user accounts.
- Physically secure removable storage devices and media, such as CD-ROMs, that contain valuable information. An individual who gains access to a workspace may find it easier to take removable media than attempt to get user-level access on a system.
- Threat: An authorized user with normal user-level rights escalates the account’s privileges to gain administrator-level access.
- Examples:
- A user takes advantage of a vulnerability in a service to gain administrator-level privileges and access another user’s files.
- A user guesses the password for an administrator-level account, gains full access to the system, and disables several security controls.
- Impact: Because the user is gaining full privileges on the system, this could cause a loss of confidentiality, integrity, and availability.
- Possible Controls:
- Restrict access to all administrator-level accounts and administrative tools, configuration files, and settings. Use strong, difficult-to-guess passwords for all administrator-level accounts. Do not use the domain administrator accounts from non-administrative client hosts. These actions will make it more difficult for users to escalate their privileges.
- Disable unused local services. Vulnerabilities in these services may permit users to escalate their privileges.
- Install application and OS updates (e.g., hotfixes, service packs, patches). These updates will resolve system vulnerabilities, reducing the number of attack vectors that can be used.
- Encrypt sensitive data. Even administrator-level access would not permit a user to access data in encrypted files.
Unlike local threats, remote threats do not require physical or logical access to the system. The categories of remote threats described in this section are network services, data disclosure, and malicious payloads.
- Threat: Remote attackers exploit vulnerable network services on a system. This includes gaining unauthorized access to services and data, and causing a denial of service (DoS) condition.
- Examples:
- A worm searches for systems with an unsecured service listening on a particular port, and then uses the service to gain full control of the system.
- An attacker gains access to a system through a service that did not require authentication.
- An attacker impersonates a user by taking advantage of a weak remote access protocol.
- Impact: Depending on the type of network service that is being exploited, this could cause a loss of confidentiality, integrity, and availability.
- Possible Controls:
- Disable unused services. This provides attackers with fewer chances to breach the system.
- Test and install application and OS updates (e.g., hotfixes, service packs, patches). These updates will resolve system software vulnerabilities, reducing the number of attack vectors that can be used.
- Require strong authentication before allowing access to the service. Implement a password policy to enforce stronger passwords that are harder to guess. Establish and enforce a checkout policy for departing employees that includes the immediate disabling of their user accounts. These actions help to ensure that only authorized users can access each service.
- Do not use weak remote access protocols and applications; instead, use only accepted, industry standard strong protocols (e.g., Internet Protocol Security [IPsec], Secure Shell [SSH], Transport Layer Security [TLS]) for accessing and maintaining systems remotely.
- Use firewalls or packet filters to restrict access to each service to the authorized hosts only. This prevents unauthorized hosts from gaining access to the services and also prevents worms from propagating from one host to other hosts on the network.
- Enable logon banners containing a warning of the possible legal consequences of misuse.
- Threat: A third party intercepts confidential data sent over a network.
- Examples:
- On a nonswitched network, a third party is running a network monitoring utility. When a legitimate user transmits a file in an insecure manner, the third party captures the file and accesses its data.
- An attacker intercepts usernames and passwords sent in plaintext over a local network segment.
- Impact: The interception of data could lead to a loss of confidentiality. If authentication data (e.g., passwords) are intercepted, it could cause a loss of confidentiality and integrity, and possibly a loss of availability, if the intercepted credentials have administrator-level privileges.
- Possible Controls:
- Use switched networks, which make it more difficult to sniff packets.
- Use a secure user identification and authentication system, such as NT LanManager version 2 (NTLMv2) or Kerberos. Section 3.2.1 contains a discussion of the choices that Windows XP provides.
- Encrypt network communications or application data through the use of various protocols (e.g., TLS, IPsec, SSH). This protects the data from being accessed by a third party.
- Threat: Malicious payloads such as viruses, worms, Trojan horses, and active content attack systems through many vectors. End users of the system may accidentally trigger malicious payloads.
- Examples:
- A user visits a Web site and downloads a free game that includes a Trojan horse. When the user installs the game on her computer, the Trojan horse is also installed, which compromises the system.
- A user with administrative-level privileges surfs the Web and accidentally visits a malicious Web site, which successfully infects the user’s system.
- A user installs and operates peer-to-peer (P2P) file sharing software to download music files, and the P2P software installs spyware programs onto the system.
- A user opens and executes a payload that was attached to a spam or spoofed message.
- Impact: Malware often gains full administrative-level privileges to the system, or inadvertently crashes the system. Malware may cause a loss of confidentiality, integrity, and availability.
- Possible Controls:
- Educate users on avoiding malware infections, and make them aware of local policy regarding the use of potential transmission methods such as instant messaging (IM) software and P2P file sharing services. Users who are familiar with the techniques for spreading malware should be less likely to infect their systems.
- Use antivirus software and spyware detection and removal utilities as an automated way of preventing most infections and detecting the infections that were not prevented.
- Use e-mail clients that support spam filtering—automatically detecting and quarantining messages that are known to be spam or have the same characteristics as typical spam.
- Do not install or use non-approved applications (e.g., P2P, IM) to connect to unknown servers. Educate users regarding the potential impact caused by the use of P2P, IM, and other untrusted software applications.
- Operate the system on a daily basis with a limited user account. Only use administrator-level accounts when needed for specific maintenance tasks. Many instances of malware cannot successfully infect a system unless the current user has administrative privileges.
- Configure server and client software such as e-mail servers and clients, Web proxy servers and clients, and productivity applications to reduce exposure to malware. For example, email servers and clients could be configured to block e-mail attachments with certain file extensions. This should help to reduce the likelihood of infections.
- Configure systems, particularly in specialized security-limited functionality environments, so that the default file associations prevent automatic execution of active content files (e.g., Java, JavaScript, ActiveX).
The section describes the types of environments in which a Windows XP host may be deployed - SOHO, enterprise, and custom - as described in the NIST Security Configuration Checklists Program for IT Products. The two typical custom environments for Windows XP are specialized security-limited functionality, which is for systems at high risk of attack or data exposure, with security taking precedence over functionality, and legacy, which is intended for situations in which the Windows XP system has special needs that do not fit into the other profiles, such as a requirement for backward compatibility with legacy applications or servers. Each environment description also summarizes the primary threats and controls that are typically part of the environment. In addition to documenting controls, every environment should have other various security-related documentation, such as acceptable use policies and security awareness materials, that affects configuration and usage of systems and applications. The last part of this section lists some common types of security-related documentation.
SOHO, sometimes called standalone, describes small, informal computer installations that are used for home or business purposes. SOHO encompasses a variety of small-scale environments and devices, ranging from laptops, mobile devices, and home computers, to telecommuting systems located on broadband networks, to small businesses and small branch offices of a company. Figure 2-2 shows a typical SOHO network architecture. Historically, SOHO environments are the least secured and most trusting. Generally, the individuals performing SOHO system administration are less knowledgeable about security. This often results in environments that are less secure than they need to be because the focus is generally on functionality and ease of use. A SOHO system might not use any security software (e.g., antivirus software, personal firewall). In some instances, there are no network-based controls such as firewalls, so SOHO systems may be directly exposed to external attacks. Therefore, SOHO environments are frequently targeted for exploitation—not necessarily to acquire information, but more commonly to be used for attacking other computers, or incidentally as collateral damage from the propagation of a worm.
Figure 2-2. Typical SOHO Network Architecture
Because the primary threats in SOHO environments are external, and SOHO computers generally have less restrictive security policies than enterprise or specialized security-limited functionality computers, they tend to be most vulnerable to attacks from remote threat categories. (Although remote threats are the primary concern for SOHO environments, it is still important to protect against other threats.) SOHO systems are typically threatened by attacks against network services and by malicious payloads (e.g., viruses, worms). These attacks are most likely to affect availability (e.g., crashing the system, consuming all network bandwidth, breaking functionality) but may also affect integrity (e.g., infecting data files) and confidentiality (e.g., providing remote access to sensitive data, e-mailing data files to others).
SOHO security is improving with the proliferation of small, inexpensive, hardware-based firewall routers that protect to some degree the SOHO machines behind them. The adoption of personal firewalls (e.g., BlackICE, ZoneAlarm, Windows Firewall) is also helping to better secure SOHO environments. Another key to SOHO security is strengthening the hosts on the SOHO network by patching vulnerabilities and altering settings to restrict unneeded functionality.
The enterprise environment, also known as a managed environment, is typically comprised of large organizational systems with defined, organized suites of hardware and software configurations, usually consisting of centrally managed workstations and servers protected from threats on the Internet with firewalls and other network security devices. Figure 2-3 shows a typical enterprise network architecture. Enterprise environments generally have a group dedicated to supporting users and providing security. The combination of structure and skilled staff allows better security practices to be implemented during initial system deployment and in ongoing support and maintenance. Enterprise installations typically use a domain model to effectively manage a variety of settings and allow the sharing of resources (e.g., file servers, printers). The enterprise can enable only the services needed for normal business operations, with other possible avenues of exploit removed or disabled. Authentication, account, and policy management can be administered centrally to maintain a consistent security posture across an organization.
The enterprise environment is more restrictive and provides less functionality than the SOHO environment. Managed environments typically have better control on the flow of various types of traffic, such as filtering traffic based on protocols and ports at the enterprise’s connections with external networks. Because of the supported and largely homogeneous nature of the enterprise environment, it is typically easier to use more functionally restrictive settings than it is in SOHO environments. Enterprise environments also tend to implement several layers of defense (e.g., firewalls, antivirus servers, intrusion detection systems, patch management systems, e-mail filtering), which provides greater protection for systems. In many enterprise environments, interoperability with legacy systems may not be a major requirement, further facilitating the use of more restrictive settings. In an enterprise environment, this guide should be used by advanced users and system administrators. The enterprise environment settings correspond to an enterprise security posture that will protect the information in a moderate risk environment.
In the enterprise environment, systems are typically susceptible to local and remote threats. In fact, threats often encompass all the categories of threats defined in Section 2.3. Local attacks, such as unauthorized usage of another user’s workstation, most often lead to a loss of confidentiality (e.g., unauthorized access to data) but may also lead to a loss of integrity (e.g., data modification) or availability (e.g., theft of a system). Remote threats may be posed not only by attackers outside the organization, but also by internal users who are attacking other internal systems across the organization’s network. Most security breaches caused by remote threats involve malicious payloads sent by external parties, such as viruses and worms acquired via e-mail or infected Web sites. Threats against network services tend to payloads and network service attacks are most likely to affect availability (e.g., crashing the system, consuming all network bandwidth, breaking functionality) but may also affect integrity (e.g., infecting data files) and confidentiality (e.g., providing remote access to sensitive data). Data disclosure threats tend to come from internal parties who are monitoring traffic on local networks, and they primarily affect confidentiality.
Figure 2-3. Typical Enterprise Network Architecture
A specialized security-limited functionality environment is any environment, networked or standalone, that is at high risk of attack or data exposure. Figure 2-4 shows examples of systems that are often found in specialized security-limited functionality environments, including outward-facing Web, e-mail, and DNS servers, and firewalls. Typically, providing sufficiently strong protection for these systems involves a significant reduction in system functionality. It assumes systems have limited or specialized functionality in a highly threatened environment such as an outward facing firewall or public Web server, or whose data content or mission purpose is of such value that aggressive trade-offs in favor of security outweigh the potential negative consequences to other useful system attributes such as legacy applications or interoperability with other systems. The specialized security-limited functionality environment encompasses computers that contain highly confidential information (e.g., personnel records, medical records, financial information) and perform vital organizational functions (e.g., accounting, payroll processing, air traffic control). These computers might be targeted by third parties for exploitation, but also might be targeted by trusted parties inside the organization.
A specialized security-limited functionality environment could be a subset of a SOHO or enterprise environment. For example, three desktops in an enterprise environment that hold confidential employee data could be thought of as a specialized security-limited functionality environment within an enterprise environment. In addition, a laptop used by a mobile worker might be a specialized security-limited functionality environment within a SOHO environment. A specialized security-limited functionality environment might also be a self-contained environment outside any other environment—for instance, a government security installation dealing in sensitive data.
Systems in specialized security-limited functionality environments face the same threats as systems in enterprise environments. Threats from both insiders and external parties are a concern. Because of the risks and possible consequences of a compromise in a specialized security-limited functionality environment, it usually has the most functionally restrictive and secure configuration. The suggested configuration is complex and provides the greatest protection at the expense of ease of use, functionality, and remote system management. In a specialized security-limited functionality environment, this guide is targeted at experienced security specialists and seasoned system administrators who understand the impact of implementing these strict requirements.
Figure 2-4. Examples of Specialized Security-Limited Functionality Systems
A legacy environment contains older systems or applications that use outdated communication mechanisms. This most often occurs when machines operating in a legacy environment need more open security settings so they can communicate to the appropriate resources. For example, a system may need to use services and applications that require insecure authentication mechanisms such as null user sessions or open pipes. Because of these special needs, the system does not fit into any of the standard environments; therefore, it should be classified as a legacy environment system. Legacy environments may exist within SOHO and enterprise environments, and in rare cases within specialized security-limited functionality environments as well. Depending on the situation, a legacy environment may face any combination of internal and external threats. The potential impact of the threats should be determined by considering the threats that the system faces (as described in the previous three sections) and then considering what additional risk the system has because of the legacy accommodations.
An organization typically has many documents related to the security of Windows XP systems. Foremost among the documents is a Windows XP security configuration guide that specifies how Windows XP systems should be configured and secured.14 As mentioned in Section 2.2, NIST SP 800-53 proposes management, operational, and technical security controls for systems, each of which should have associated documentation. In addition to documenting procedures for implementing and maintaining various controls, every environment should also have other security-related policies and documentation that affect the configuration, maintenance, and usage of systems and applications. Examples of such documents are as follows:
- Rules of behavior and acceptable use policy
- Configuration management policy, plan, and procedures
- Authorization to connect to the network
- IT contingency plans
- Security awareness and training for end users and administrators.
Implementing security controls can be a daunting task. As described in Section 2.2, many security controls have a negative impact on system functionality and usability. In some cases, a security control can even have a negative impact on other security controls. For example, installing a patch could inadvertently break another patch, or enabling a firewall could inadvertently block antivirus software from automatically updating its signatures or disrupt patch management software, remote management software and other security and maintenance-related utilities. Therefore, it is important to perform testing for all security controls to determine what impact they have on system security, functionality, and usability, and to take appropriate steps to address any significant issues.
As described in Section 5, NIST has compiled a set of security templates, as well as additional recommendations for security-related configuration changes. The controls proposed in this guide and the NIST Windows XP security templates are consistent with the FISMA controls, as discussed in Section 2.2. The NIST template for Specialized Security-Limited Functionality environments represents the consensus settings from CIS, DISA, Microsoft, NIST, NSA, and USAF; the other NIST templates are based on Microsoft’s templates and recommendations.
Although the guidance presented in this document has undergone considerable testing, every system is unique, so it is certainly possible for certain settings to cause unexpected problems. System administrators should perform their own testing, especially for the applications used by their organizations, to identify any functionality or usability problems before the guidance is deployed throughout organizations.15 It is also critical to confirm that the desired security settings have been implemented properly and are working as expected. See Section 4.4 for information on tools that can identify security-related misconfigurations and vulnerabilities on Windows XP systems.
Every system needs to be monitored and maintained on a regular basis so that security issues can be identified and mitigated promptly, reducing the likelihood of a security breach. However, no matter how carefully systems are monitored and maintained, incidents may still occur, so organizations should be prepared to respond to them.16 Depending on the environment, some preventative actions may be partially or fully automated. Guidance on performing various monitoring and maintenance activities is provided in subsequent sections of this document or other NIST publications. Recommended actions include the following:
- Subscribing to and monitoring various vulnerability notification mailing lists (e.g., Microsoft Security Notification Service)
- Acquiring and installing software updates (e.g., OS and application patches, antivirus signatures)
- Monitoring event logs to identify problems and suspicious activity
- Providing remote system administration and assistance
- Monitoring changes to OS and software settings
- Protecting and sanitizing media
- Responding promptly to suspected incidents
- Assessing the security posture of the system through vulnerability assessments
- Disabling unneeded user accounts and deleting accounts that have been disabled for some time
- Maintaining system, peripheral, and accessory hardware (periodically and as needed), and logging all hardware maintenance activities.
- Protect each system based on the potential impact to the system of a loss of confidentiality, integrity, or availability.
- Reduce the opportunities that attackers have to breach a system by resolving security weaknesses and limiting functionality according to the principle of least privilege.
- Select security controls that provide a reasonably secure solution while supporting the functionality and usability that users require.
- Use multiple layers of security so that if one layer fails or otherwise cannot counteract a certain threat, other layers might prevent the threat from successfully breaching the system.
- Conduct risk assessments to identify threats against systems and determine the effectiveness of existing security controls in counteracting the threats. Perform risk mitigation to decide what additional measures (if any) should be implemented.
- Document procedures for implementing and maintaining security controls. Maintain other security-related policies and documentation that affect the configuration, maintenance, and usage of systems and applications, such as acceptable use policy, configuration management policy, and IT contingency plans.
- Test all security controls, including the settings in the NIST security templates, to determine what impact they have on system security, functionality, and usability. Take appropriate steps to address any significant issues before applying the controls to production systems.
- Monitor and maintain systems on a regular basis so that security issues can be identified and mitigated promptly. Actions include acquiring and installing software updates, monitoring event logs, providing remote system administration and assistance, monitoring changes to OS and software settings, protecting and sanitizing media, responding promptly to suspected incidents, performing vulnerability assessments, disabling and deleting unused user accounts, and maintaining hardware.
This section presents an overview of the various security features offered by the Windows XP Professional operating system (OS). Many of the components have been inherited from Windows 2000, often with improvements and enhancements. Windows XP also includes several new security features. This guide provides general descriptions of most of these features, with pointers or links to more detailed information whenever possible.
Windows XP comes with several new security features. Each new security feature is briefly described below, and most also include a reference to a Microsoft Web page that contains more detailed information. This section also includes an analysis of the security impact of each feature and general recommendations for when the feature should or should not be used. The new security features in Windows XP are as follows:
Windows Firewall is a stateful personal firewall. When properly configured, it limits the access that other computers have to the Windows XP machine through the network. This significantly reduces the exposure of the machine to network-based attacks such as the Blaster worm.21 Windows Firewall can also be used to protect shares when a mobile computer is used outside its normal secure and trusted environment, or to protect access to network shares on an untrusted network. Domain administrators can disable the use of Windows Firewall through Group Policy, but this is generally not recommended unless it is interfering with required functionality or a third party firewall is already in use.22 Administrators can also use Group Policy to set any Windows Firewall configuration option. Windows Firewall can add another layer to a network security model in enterprise and specialized security-limited functionality environments, and it is sometimes the only layer of network defense in SOHO environments.
A network bridge allows two dissimilar networks (e.g., Ethernet and dialup, wireless, or token ring) to be joined without using expensive, dedicated hardware. The connection between the two networks is transparent, meaning that no network address translation occurs between the networks and the actual assigned addresses on each network are visible on the other network. While bridging does permit two networks to be joined with a minimal amount of work, it has serious security implications. If a personal firewall such as Windows Firewall is not enabled and configured correctly, the bridge will provide no network security protection to either of the networks that it connects, exposing them to attacks from each other. A network bridge can expose systems on multiple networks to additional threats, so NIST does not recommend implementing a bridge using a Windows XP computer unless it is specifically needed for a task, and risk assessment and mitigation have been performed.
RA provides a way to get remote technical support assistance when running into problems with a computer. RA sessions can be initiated through the Windows Messenger facility, e-mail requests, and via a Web e-mail service (filling out a form to request assistance). Unfortunately, if RA is configured improperly, unauthorized parties could use it to gain remote access to a system. Therefore, RA should be used only if experienced security administrators are available to configure it to strictly limit its usage, and if the network perimeter (e.g., firewall) is configured to prevent external parties from using RA to access internal machines. Otherwise, RA should be disabled.
The Remote Desktop feature allows a user to remotely access a Windows XP Professional system from another computer. This provides another method for remote attackers to attempt to gain access to the computer by guessing passwords for default accounts. In general, Remote Desktop should only be used if several other layers of security controls are in place, preventing the system from being directly exposed to attackers. Even then, administrators should carefully consider the business need for having remote access to the system and should think of possible alternatives that will not expose the system to attack.
When a wireless network interface card (NIC) is present, the computer will automatically attempt to join any wireless networks it detects in an established list of preferred networks. This allows a computer to easily roam from access point (AP) to access point without reconfiguration, which is beneficial. However, the system may reveal service set identifier (SSID) information for preferred and previously connected access points, which could be captured by an attacker and used to set up a rogue access point. Because Wireless Auto Configuration can be set to connect to any wireless network, a rogue access point could fool the computer into connecting to a hostile network, which could attack the computer or capture data from it. NIST recommends that systems not be set to attempt to connect to any wireless network automatically.
To provide a better solution for wireless security, an industry group called the Wi-Fi Alliance has created a product certification called Wi-Fi Protected Access (WPA). In Windows XP SP2, hosts with WPA-supporting wireless NICs can use the features provided by WPA, such as using Advanced Encryption Security (AES) for encrypting network communications. Section 7.8 provides recommendations for wireless security, including the use of WPA.
A change introduced in Windows XP SP2 that may impact some users is a restriction on raw sockets for the TCP/IP stack. Some security tools, such as network vulnerability scanners, use raw sockets to craft packets. Windows XP SP2 limits the number of incomplete outbound packets per second, which may break such security tools.
TO-DO
TO-DO
This section discusses the most significant security features inherited from Windows 2000: Kerberos, smart card support, Internet Connection Sharing, Internet Protocol Security, and Encrypting File System. For each security feature, the section includes a brief description, an analysis of the security impact of each feature, and general recommendations for when the feature should or should not be used. It is outside the scope of this document to cover the features in great depth, so pointers to resources with additional information are provided as needed.
In a domain, Windows XP Professional provides support for MIT Kerberos v.5 authentication, as defined in Internet Engineering Task Force (IETF) Request for Comment (RFC) 1510. The Kerberos protocol is composed of three subprotocols: Authentication Service (AS) Exchange, Ticket-Granting Service (TGS) Exchange, and Client/Server (CS) Exchange. The Kerberos v.5 standard can be used only in pure Windows domain environments.36 Windows domain members use Kerberos as the default network client/server authentication protocol, replacing the older and less secure NTLM and LanManager (LM) authentication methods. The older methods are still supported to allow legacy Windows clients to authenticate to a Windows domain environment. Windows XP Professional standalone workstations and members of NT domains do not use Kerberos to perform local authentication; they use the traditional NTLM. Because Kerberos provides stronger protection for logon credentials than older authentication methods, it should be used whenever possible. NIST recommends disabling LM and NTLM v1 in specialized security-limited functionality environments, and disabling LM in the other environments.
In the past, interactive logon meant an ability to authenticate a user to a network by using a form of a shared credential, such as a hashed password. Windows XP Professional supports public-key interactive logon by using a X.509 v.3 certificate stored on a smart card. (This can be used only to log on to domain accounts, not local accounts, unless third party software has replaced the built-in graphical identification and authentication [GINA].) Instead of a password, the user types a personal identification number (PIN) to the GINA, and the PIN authenticates the user to the card. This process is fully integrated with the Microsoft implementation of Kerberos. Smart card-based authentication is appropriate for specialized security-limited functionality environments in which strong authentication is required, and one-factor authentication (username and password) is insufficient. Smart cards provide two-factor authentication, because users must possess the physical smart card and must know the PIN. If smart cards or other types of authentication tokens are being used, the organization should have a policy and procedures in place to educate users on properly using tokens (e.g., not sharing them with other users) and protecting them (e.g., immediately reporting a lost or stolen token).
Internet Connection Sharing (ICS) allows a Windows XP system to share an Internet connection with other computers.37 ICS is most often used in SOHO environments (e.g., Internet connectivity provided by a modem on one system). ICS can provide Network Address Translation (NAT) services to the other systems, which essentially hides them from public view. In a corporate environment, domain administrators can prevent systems from using ICS through Group Policy. Portable Windows XP Professional systems do not need to be reconfigured to use ICS on a SOHO network and not use ICS on a corporate network; Group Policy takes care of it automatically. Generally, ICS should not be used on enterprise networks, but it is a solution for SOHO environments with limited connectivity. It is recommended to use a host-based firewall such as Windows Firewall on the host that is running ICS. Not only can the firewall provide protection for the ICS host, but it can also help to protect the systems behind the ICS from attacks by external parties.
Windows XP includes an implementation of the IETF Internet Protocol Security (IPsec) standard called Windows IP Security.38 It provides network-level support for confidentiality and integrity. Confidentiality is achieved by encrypting packets, which prevents unauthorized parties from gaining access to data as it passes over networks. Integrity is supported by calculating a hash for each packet based partially on a secret key shared by the sender and receiver, and sending the hash in the packet. The recipient will recalculate the hash, and if it matches the original hash, then the packet was not altered in transit. Windows IP Security also offers packet filtering capabilities, such as limiting traffic based on the source or destination IP address. Windows IP Security provides a solution for protecting data traversing public networks (e.g., the Internet) and for protecting sensitive data on private networks (e.g., an enterprise LAN). It is also commonly used to protect wireless network communications in enterprise and SOHO environments. Using Windows IP Security in conjunction with a personal firewall such as Windows Firewall can provide protection against network-based attacks by limiting both inbound and outbound packets.
The Encrypting File System (EFS) provides users a method to transparently encrypt or decrypt files and folders residing on an NTFS-formatted volume.39 In the original release of Windows XP, EFS could use either the Triple Data Encryption Standard (3DES) algorithm, which is a stronger variant of the Data Encryption Standard (DES), or the Extended Data Encryption Standard (DESX). Windows XP Service Pack 1 (SP1) added support for the Advanced Encryption Standard (AES) algorithm, and SP1 and SP2 systems use AES by default for EFS. This is a change from Windows 2000, which used DESX by default. In addition, EFS now maintains encryption persistence, which means that any file or folder that has been designated as encrypted will remain encrypted when moved to another NTFS-formatted filesystem. Another major change from Windows 2000 is that EFS-encrypted files can now be shared among multiple users over a network.40 However, files are still transmitted unencrypted across the network (except when Web Distributed Authoring and Versioning [WebDAV] is used, which will transmit encrypted files across networks), so users should transfer the files through a separate encrypting protocol, such as TLS or IPsec. EFS is best used to provide local encryption for files and is particularly useful for laptops and other systems at high risk of physical attack.
Windows NT and Windows 2000 provide support for the OS/2 and POSIX subsystems. However, Windows XP no longer includes these subsystems. POSIX support is now included in a seperate package as part of Microsoft Windows Interix 2.2. Refer to http://www.microsoft.com/windows2000/Interix for more information on Interix.
| POSIX Subsystem File Components |
The POSIX subsystem file components should not be present |
| Deleting POSIX Registry Keys |
This check verifies that the registry keys associated with the POSIX subsystem have been deleted. |
- Do not implement a network bridge using a Windows XP computer unless it is specifically needed for a task, and risk assessment and mitigation have been performed.
- Enable Remote Assistance only if it is configured so its usage is strictly limited and if the network perimeter is configured to prevent external parties from using it to access internal machines.
- Only use Remote Desktop if several other layers of security controls are in place, preventing the system from being directly exposed to attackers, and administrators have carefully considered the business need for remote access to the system and have not found a viable alternative that will not expose the system to attack.
- Do not configure Wireless Auto Configuration to attempt to connect to any wireless network automatically.
- Only allow users with a legitimate need to access a system remotely.
- Configure systems to store OS and application passwords only in environments in which there is a minimal physical threat or for passwords that have trivial value.
- Disable UPnP unless its dynamic updating feature is needed for compatibility with other devices, such as SOHO firewalls.
- Disable LM and NTLM v1 in specialized security-limited functionality environments.
- Use host-based firewalls on systems running ICS.
- As appropriate, use Windows IP Security to protect data traversing public networks and sensitive data on private networks.
This section of the guide contains advice on performing Windows XP installations, and backing up and patching Windows XP systems. It discusses the risks of installing a new system on a network and the factors to consider when partitioning Windows XP hard drives. It also describes various installation techniques and provides pointers to more information on performing them. Another important topic is the ability of Windows XP to back up and restore data and system configuration information. This section also discusses how to update existing systems through Microsoft Update and other means to ensure that they are running the latest service packs and hotfixes. Advice is also presented on identifying missing patches and security misconfigurations on systems.
Organizations should have sound configuration management policies that govern changes made to operating systems and applications, such as applying patches to an operating system or modifying application configuration settings to provide greater security. Configuration management policies should also address the initial installation of the operating system, the installation of each application, and the roles, responsibilities, and processes for performing and documenting system changes caused by upgrades, patches, and other methods of modification.
This guide assumes that a new Windows XP installation is being performed from scratch. If an administrator or user is upgrading an existing Windows installation, some of the advice in this guide may be inappropriate and could possibly cause problems. Because a machine is unsecured and very vulnerable to exploitation through the network during installation, it is recommended that all installations and initial patching be done with the computer not connected to any network. If a computer must be connected to a network, then it is recommended that the network be isolated and strongly protected (e.g., shielded by a firewall on a trusted network segment) to minimize exposure to any network attacks during installation.41 If possible, the latest service pack and critical hotfixes should be downloaded from Microsoft’s Web site, archived to read-only media, such as CD-ROMs, and kept physically secure.
One of the major decisions during installation is how to partition hard drives. The primary consideration is how large the disk drive is; for example, partitioning is not recommended for drives under 6 gigabytes (GB). For larger drives, the following factors should be considered:
- How large is the drive?
- How many physical drives does the machine have?
- If the system only has one drive, is there a desire to logically separate the OS and applications from data? An example of the benefit of this is that if the OS needs to be upgraded or reinstalled, the data can easily be preserved.
- What is the purpose of this computer? For example, if a computer will be used to share files within a workgroup, it may be useful to have a separate partition for the file share.
- Is there a need for redundancy (e.g., mirroring a data partition onto a second drive)?
Windows XP Professional provides a feature known as dynamic disks. On a dynamic disk, partition sizes can be changed as needed. For example, an administrator could create an OS and applications partition and a data partition on a large drive, leaving much of the drive space available for future allocation. As needed, the administrator can use the free space to create new partitions and to expand the existing partitions. This provides considerable flexibility for future growth. Users are cautioned that, as with any other new feature, dynamic disks should be tested before deploying them on production systems.
Another important consideration during installation is which type of filesystem to use for each partition. NIST recommends using NTFS for each partition unless there is a particular need to use another type of filesystem. Section 7.1 contains more information on NTFS and other filesystem options.
There are several ways to perform Windows XP installations. This section covers three primary methods: local installations, cloning through Sysprep, and the Remote Installation Services (RIS).
The local installation approach refers to traditional methods of installing Windows, such as using a Microsoft CD. This is effective only for installing a small number of computers at a time because it requires user attention throughout the installation. When installing Windows XP from a CD, follow the default steps, except for the following:
- For the Network Setting configuration, select Custom and disable all network clients, services, and protocols that are not required. Although this will help to limit the computer’s exposure to network-based attacks, consider the implications of disabling each service because this may inadvertently break required functionality (e.g., connecting to remote servers and printers). See Section 7.5 for more information on network clients, services, and protocols. Consider disabling the following services:
- Client for Microsoft Networks (most users will require this service)
- Client Service for NetWare
- File and Printer Sharing for Microsoft Networks
- QoS Packet Scheduler
- NWLink IPX/SPX/NetBIOS Compatible Transport Protocol
- If possible, assign an Internet Protocol (IP) address, default gateway, and domain name system (DNS) server.
- Even if the computer will be joining a domain, choose to be in only a workgroup, and change the workgroup name to something other than the default of WORKGROUP.
- Set all environment-specific settings, such as the time zone.
When the installation prompts for accounts to be added, only one account should be added initially. Other accounts can always been added later once the system is fully patched and configured. By default, the account created during the installation and the built-in Administrator account both belong to the Administrators group. After the initial post-installation boot, assign both accounts strong passwords. The next task is to install the latest service pack and hotfixes. Only after the machine has been brought up to current patch levels should it be connected to a regular network. Then, the networking configuration can be changed, such as joining the workstation to a domain, or assigning a workgroup to enable sharing of workgroup resources (e.g., shared directories, printers). Other services that were disabled during installation can be enabled if needed. It is also helpful to scan through the list of installed Windows components, determine which applications and utilities (e.g., Internet games) are not needed, and remove them.
Sysprep is a tool that permits an image from a single Windows XP computer installation, known as a gold system, to be cloned onto multiple systems in conjunction with a cloning software program such as Ghost or Disk Image. This technique reduces user involvement in the installation process to approximately 5 to 10 minutes at the start of the installation. The Sysprep approach has several benefits. Because the standard image can be created with a strong security configuration, Sysprep reduces the possibility of human error during the installation process. In addition, the Windows XP installation occurs more quickly with Sysprep. This is beneficial not only for building new systems, but also for reinstalling and reconfiguring the operating system and applications much more quickly when needed - for example, as a result of hardware failure or a virus infection. In preparing the “gold” image for Sysprep, the same guidelines used for a local installation should be used, with the addition of enabling any needed services and patching the system. It is also important to physically secure image media so that it is not inadvertently or purposely altered.
The Remote Installation Services (RIS) allow a computer to be booted from the network and then to automatically install an instance of Windows XP. RIS can be configured to perform either a completely automated and unattended installation with RISetup, or one that requires minimal user attendance (similar to the Sysprep tool) with RIPrep. Several hardware and software dependencies exist; therefore, Microsoft's documentation on the tool should be consulted for detailed instructions regarding how to configure this installation method.
The RIS method has the same advantages as Sysprep. RIS has the additional advantage of not needing the machine to be installed to have direct access to the physical install media (e.g., a CD-ROM). This can be ideal in a specialized security-limited functionality environment in which machines might not have CD-ROM drives. The primary disadvantage of RIS is that the machine must be connected to a network while it is being installed. This could open up a window of opportunity to exploit a security weakness before installation is completed.
To increase the availability of data in case of a system failure or data corruption caused by a power failure or other event, Windows XP has built-in capabilities to back up and restore data and systems. By default, users run the Backup or Restore Wizard, which automates most of the backup and restore processes. For example, during a backup the user is presented with several options, including backing up the current user’s files and settings, backing up all users’ files and settings, and backing up the whole system. This allows the user to back up data and systems without having to manually indicate which files and directories should be backed up, if the user’s files are where the backup program expects them to be. To run the Backup or Restore Wizard, perform the following steps:
- Open My Computer. Right-click on the drive that contains the data to be backed up, and select Properties.
- Click on the Tools tab. Click on the Backup Now… button. This launches the Backup or Restore Wizard.
When a backup is performed, the result is a .bkf file (Backup.bkf by default). If a full system backup is performed, the Automated System Recovery Wizard will prompt the user to insert a floppy disk, which will be turned into a recovery disk that can be used with the .bkf file to restore the system in case of failure.47 As the name indicates, the Backup or Restore Wizard can also be used to restore a backup from a .bkf file. It is very important to verify periodically that backups and restores can be performed successfully; backing up a system regularly may not be beneficial if the backups are corrupt or the wrong files are being backed up, for example. Organizations should have policies and procedures that address the entire backup and recovery process, as well as the protection and storage of backup media and recovery disks. Because backups may contain sensitive user data as well as system configuration and security information (e.g., passwords), backup media should be properly protected to prevent unauthorized access.
When the Backup or Restore Wizard is run, it presents an option to select Advanced Mode. This switches to the Backup Utility interface, which is not as user-friendly but provides greater customizability and more features. For example, the Backup Utility can be used to schedule backups. In general, system administrators are more likely to use the Backup Utility mode, while end users are more likely to use the Backup or Restore Wizard mode.
Besides the backup wizards and utilities provided by Windows XP, there are also various third-party utilities for backing up and restoring files and systems. It is important to verify that the third-party software can properly back up and restore Windows XP-specific resources, such as the Windows registry and EFS-encrypted files and folders. Windows XP’s built-in utilities also use a shadow copy backup technique when possible, which means that they essentially take a snapshot of the system and then perform a backup on that snapshot. This avoids problems with attempting to back up open files. Third-party backup utilities used on Windows XP systems should have good mechanisms for handling open files.
Host security - securing a given computer - has become increasingly important. As such, it is essential to keep a host up to current patch levels to eliminate known vulnerabilities and weaknesses. In conjunction with antivirus software and a personal firewall, patching goes a long way to securing a host against outside attacks and exploitation. Microsoft provides two mechanisms for distributing security updates: Automatic Updates and Microsoft Update. In smaller environments, either method may be sufficient for keeping systems current with patches. Other environments typically have a software change management control process or a patch management program that tests patches before deploying them; distribution may then occur through local Windows Update Services (WUS) or Windows Server Update Services (WSUS) servers, which provide approved security patches for use by the Automatic Updates feature. This section discusses Automatic Updates and Microsoft Update, as well as patch management considerations for managed environments. This section also defines the types of updates that Microsoft typically provides.
| Patches Up-To-Date |
Keep systems up to current patch levels to eliminate known vulnerabilities and weaknesses. |
As described later in this section, it is possible to configure Windows XP systems to download critical updates automatically. However, this still leaves other updates that can only be downloaded manually. Therefore, it is important for Windows XP system administrators to be notified of new updates that Microsoft releases. The Microsoft Security Notification Service is a mailing list that notifies subscribers of new security issues and the availability of all types of Microsoft updates.52 Microsoft security bulletins are also available online from the TechNet Security Resource Center.53 Individual bulletins are issued for each new vulnerability and are incorporated into monthly bulletins that list the vulnerabilities in order of potential severity (e.g., critical, important, moderate). Each bulletin provides guidance regarding under what circumstances the suggested mitigation strategy (e.g., patch) should be applied.
Microsoft releases updated code for Windows XP-related security issues through three mechanisms: hotfixes, security rollups, and service packs.
- A hotfix is a patch that fixes a specific problem. When a new vulnerability is discovered in Windows XP or a Microsoft application (e.g., Internet Explorer), Microsoft develops a hotfix that will resolve the problem. Hotfixes are released on an individual basis as needed. Hotfixes should be applied as soon as practical for vulnerabilities that are likely to be exploited. (Whenever possible, hotfixes should first be tested on a nonproduction system to ensure that they do not inadvertently break functionality or introduce a new security problem by breaking a previous hotfix.)
- A security rollup is a collection of several hotfixes. The security rollup makes the same changes to the system that would be performed if each hotfix were installed separately. However, it is easier to download and install a single security rollup than 10 hotfixes. Microsoft releases security rollups on occasion when merited. Security rollups are most useful for updating existing systems that have not been maintained and for patching new systems.
- A service pack (SP) is a major upgrade to the operating system that resolves dozens of functional and security problems and often introduces some new features or makes significant configuration changes to systems.54 Service packs incorporate previously released hotfixes, so once an SP has been applied to a system, there is no need to install the hotfixes that were included in the service pack. Service packs are released every year or two; for example, Windows XP was released in the fall of 2001, SP1 in the fall of 2002, and SP2 in the summer of 2004. Because SPs often make major changes to the operating system, organizations should test the SP thoroughly before deploying it in production. In SOHO environments, the best approach is to delay installation of the SP for at least a few weeks so that early adopters can identify any bugs or issues. However, if the SP provides a fix for a major security issue, and the fix is not available through hotfixes, it may be less risky to install the SP immediately than to let the system remain unpatched.
One facility that is available to patch systems with little to no user intervention is the Automatic Updates feature. When enabled, it will automatically check the Microsoft update servers for OS and Microsoft application updates, including service packs, security roll-ups, and hotfixes, as well as updated hardware drivers. Automatic Updates has a prioritization feature that ensures the most critical security updates are installed before less important updates.
Automatic Updates provides three configuration options to users:
- Notifies the user before downloading or installing any updates
- Downloads updates automatically but notifies the user before installing updates
- Downloads all updates and automatically installs them according to a specified schedule.
Generally, it is best to configure the system to download updates automatically, unless bandwidth usage is a concern. For example, downloading patches could adversely affect the functionality of a computer that is connected to the Internet on a slow link. In this case, it would be preferable for Automatic Updates to be configured to notify the user that new patches are available. The user should then make arrangements to download the patch at the next possible time when the computer is not needed for normal functionality. Choosing whether to install updates automatically or prompt the user is dependent upon the situation. If the user is likely to ignore the notifications, then it may be more effective to install the updates on a schedule. If the system is in use at unpredictable days and times, then it may be difficult to set a schedule that will not interfere with system usage. Another issue to consider is that many updates require the system to be rebooted before the update takes effect. Windows XP offers an Install updates and shutdown option as part of its Shut Down dialog box, which may be helpful in reminding users to launch the update installation process.
It is highly recommended that the Automatic Updates service be enabled to keep the OS and key Microsoft applications (e.g., Internet Explorer, Outlook Express) fully patched. To enable Automatic Updates, perform the following steps:
- Click the Start menu and select Control Panel.
- Double-click Automatic Updates.
- Choose the appropriate radio button (such as Download updates for me, but let me choose when to install them). Click OK.
Some organizations do not want the latest updates applied immediately to their Windows systems. For example, in a managed environment it may be undesirable for hotfixes to be deployed to production systems until they have been tested by Windows administrators and security administrators. In addition, in large environments, many systems may need to download the same hotfix simultaneously. This could cause a serious impact on network bandwidth. Organizations with such concerns often establish a local WUS or WSUS update server that contains approved updates. The Automatic Updates feature on Windows XP systems should then be configured to point to the local update server. Unfortunately, although WUS and WSUS provide a method for distributing Microsoft updates, they cannot be used to distribute third party software updates.
Users with local administrator privileges can also manually update their systems by visiting the Microsoft Update Web site. The Microsoft Update site will check the computer to determine what security and functionality updates are available and produce a list of updates. The user can then select which updates should be installed at this time, and tell Microsoft Update to perform the installations. To use Microsoft Update, perform the following steps:
- Run Internet Explorer.
- From the Tools menu, select Windows Update. If a prompt appears asking to install and run Windows Update, click Yes.
- If a prompt appears saying that a new version of the Windows Update or Microsoft Update software is available, click on Install Now or Download and Install Now to install the new version. Multiple updates may be needed. If prompted to do so, close Internet Explorer or reboot the computer so that the new version of the update software takes effect. (If a reboot is needed, restart these instructions at step 1 after the reboot completes.)
- Click on the Custom button to identify available updates.
- Microsoft Update checks for updates and lists the available updates. Depending on the service pack level of the computer, either Service Pack 2 or non-service pack updates should be displayed. Follow the appropriate step:
- Non-service pack updates are grouped by high priority updates, optional software updates, and optional hardware updates.
- Review the list of available updates, select the desired ones (or accept the default setting), then click Review and install updates. In some cases, one patch may need to be installed by itself; therefore, it may not be possible to install all desired patches at once.
- Confirm that the correct updates are listed, and click the Install Updates button to perform the installations. Review any licensing agreements that are displayed and click on the appropriate button for each.
- The download and installation process will begin. Depending on the number of updates and the network bandwidth available, it may take from a few minutes to a few hours to download and install the updates. When the installations are done, Microsoft Update should report which updates were successfully installed. It will also prompt the user to reboot the computer if any of the updates require a reboot to complete the installation. Click on OK to reboot immediately or Cancel to manually reboot the computer later.
- Service Pack 2 can be installed through Microsoft Update using the following steps:
- Click on Download and Install Now.
- Review the license agreement and click on the appropriate button.
- Service Pack 2 should be downloaded and installed. This may take considerable time, depending primarily on the size of the service pack and the type of Internet connectivity and bandwidth available. The Windows XP Service Pack 2 Setup Wizard may prompt the user at some point; click Next to continue.
- Once the installation has ended, a summary should be displayed that reports the installation was successful. Click Restart Now to reboot the computer.
- After the reboot, the Help protect your PC screen appears. The Automatic Updates setting is configured later in the instructions, so at this time, choose the Not right now option and click Next.
- The Security Center opens and displays the status of security programs. Since antivirus software and other security programs have not yet been installed on the computer, the current status is irrelevant. Close the Security Center.
- Repeat all of these steps until no more updates are available. Depending on which service pack was on the computer, and the number of additional updates that need to be applied, it may take several rounds of updating the computer and rebooting it to bring a new Windows XP installation completely up to date.
Because Windows Update requires local administrative privileges and is run manually, its use is generally not recommended within enterprise and specialized security-limited functionality environments. As described in Section 4.3.5, it is recommended that all updates be tested and verified before coordinated deployment, which the use of Microsoft Update could circumvent. Microsoft Update has additional complications in enterprise environments because it is typically unrealistic to run any application manually on every workstation in the enterprise on a regular basis, and individual users may not have the necessary local administrative rights.
Enterprise and specialized security-limited functionality environments, especially those that are considered managed environments, should have a patch management program that is responsible for acquiring, testing, and verifying each patch, then arranging for its distribution to systems throughout the organization. NIST SP 800-40 version 2, Creating a Patch and Vulnerability Management Program, provides in-depth advice on establishing patching processes and testing and applying patches. For each patch that is released, the patch management team should research the associated vulnerabilities and prioritize the patch appropriately. It is not uncommon for several patches to be released in a relatively short time, and typically one or two of the patches are much more important to the organization than the others. Each patch should be tested with system configurations that are representative of the organization’s systems. Once the team determines that the patch is suitable for deployment, the patch needs to be distributed through automated or manual means for installation on all appropriate systems. (There are several third-party applications available for patch management and distribution, which support many types of platforms and offer functionality that supports enterprise requirements.) Finally, the team needs to check systems periodically to confirm that the patch has been installed on each system, and to take actions to ensure that missing patches are applied.
Microsoft offers the following command-line tools that may be helpful in hotfix deployment, as follows:
- The qchain.exe tool allows multiple hotfixes to be installed at one time, instead of installing a hotfix, rebooting, then installing another hotfix.
- The qfecheck.exe tool can be used to track and verify installed hotfixes.
Host security is largely dependent upon staying up to date with security patches as well as identifying and remediating other security weaknesses. The Microsoft Baseline Security Analyzer (MBSA) is a utility that can scan the local computer and remote computers to identify security issues. MBSA must have local administrator-level access on each computer that it is scanning. MBSA offers both graphical user interface (GUI) and command-line interfaces. MBSA can identify which updates are missing from the operating system and common Microsoft applications (e.g., Internet Explorer, Media Player, Internet Information Services [IIS], Exchange Server, Structured Query Language [SQL] Server) on each system. For the operating system and a few applications (e.g., Internet Explorer, IIS, SQL Server, Office), it can also identify other security issues, such as insecure configurations and settings. MBSA only identifies the problems; it has no ability to change settings or download and install updates onto systems. The methods discussed in Section 4.3 should be used to download and apply patches.
Another popular free tool for checking the patch status of computers is HFNetChk, made by Shavlik. HFNetChk offers the same functionality as the command-line version of MBSA; it can scan systems and report which patches are present and absent for the operating system and various Microsoft applications. Shavlik also makes HFNetChkPro, a commercial utility that provides a GUI for administrators. Unlike MBSA, HFNetChkPro also provides a mechanism for distributing and installing patches that are identified as being missing from systems.
Individual systems can also monitor their own security state and alert users of potential problems. Windows XP offers the Windows Security Center, which is a service that can be configured to monitor the state of the system’s firewall (either Windows Firewall or a third-party firewall) and antivirus software, as well as the settings for Automatic Updates. Windows Security Center can generate alerts if the firewall, antivirus software, or Automatic Updates feature is not enabled, and also if certain major configuration settings are insecure, such as not setting antivirus software to perform real-time scanning, and not setting Automatic Updates to download and install updates automatically. Windows Security Center can monitor several types of third-party firewall and antivirus software. Windows Security Center is most helpful in SOHO environments, so that users can monitor the security state of their systems. In an enterprise environment, systems might be updated through methods other than Automatic Updates, and the status of systems' firewalls and antivirus software might already be monitored centrally.
- Use the recommendations presented in this guide only on new Windows XP systems, not systems upgraded from previous versions of Windows. For upgraded systems, some of the advice in this guide may be inappropriate and could possibly cause problems.
- Have sound configuration management policies that govern changes made to operating systems and applications, such as applying patches and modifying configuration settings.
- Until a new system has been fully installed and patched, either keep it disconnected from all networks, or connect it to an isolated, strongly protected network.
- Use NTFS for each hard drive partition unless there is a particular need to use another type of filesystem.
- Disable all network clients, services, and protocols that are not required.
- Assign strong passwords to the built-in administrator account and the user account created during installation.
- Keep systems up to current patch levels to eliminate known vulnerabilities and weaknesses.
- Use MBSA, HFNetChk, or other similar utilities on a regular basis to identify patch status issues.
This section lists questions that must be asked of the System Administrator or the Information Assurenace Officer (IAO) in an interview prior to the SRR.
| Physical security of the Automated Information Systems (AISs) does not meet requirements. |
Inadequate physical protection can undermine all other security precautions utilized to protect the system. This can jeopardize the confidentiality, availability, and integrity of the system. Physical security of the AIS is the first line protection of any system. Note: Critical servers should be located in rooms, or locked cabinets, that are accessible only to authorized systems personnel. User workstations containing sensitive data should be in access controlled areas. |
| Users with Administrative privilege are not documented or do not have separate accounts for administrative duties and normal operational tasks. |
Using a privileged account to perform routine functions makes the computer vulnerable to attack by any virus or Trojan Horse inadvertently introduced during a session that has been granted full privileges. The rule of least privilege should always be enforced. |
| Members of the Backup Operators group do not have separate accounts for backup duties and normal operational tasks. |
Backup Operators are able to read and write to any file in the system, regardless of the rights assigned to it. Backup and restore rights permit users to cirvumvent the file access restrictions present on NTFS disk drives for the purpose of backup and restore. Members of the Backup Operators group should have special logon accounts for performing their backup duties. |
| Shared user accounts are permitted on the system. |
This check verifies that all shared accounts on the system are documented and justified. Any shared account must be documented with the IAO as shared accounts do not provide individual accountability for system access and resource usage. Documentation should include the reason for the account, who has access to this account, and how the risk of using a shared account, which provides no individual identification and accountability is mitigated. Note: A shared account may be permitted for a help desk or site security personnel machine, if that machine is stand-alone and has no access to the network. |
| Access to the Windows Event Logs has not been restricted to an Auditors group. |
The Security Event Log contains information on security exceptions that occur on the system. This data is critical for identifying security vulnerabilities and intrusions. The Application and System logs can also contain information that is critical in assessing security events. Therefore, these logs must be protected from unauthorized access and modification. Only individuals who have auditing responsibilities (IAO, IAM, auditors, etc.) should be members of this group. The individual System Administrators responsible for maintaining this system can also be members of this group. Note: The administrator, who is responsible for an individual system, should be added to the local auditors group, since he needs the audit user right to perform his tasks. |
| There is no local policy for reviewing and archiving audit logs. |
To be of value, audit logs will be reviewed on a regular basis to identify security breaches and potential weaknesses in the security structure. |
| Emergency Repair Disk(s) (ERD) or System information backups are not created, updated, and protected according to DISA requirements. |
Recovery of a damaged or compromised system will be difficult without an up-to-date Emergency Repair Disk (ERD). An ERD also allows recovery of a damaged or corrupted system that cannot be rebooted. The ERD, when used in the recovery process, can restore the local systems user database to the version that existed when the ERD was previously made. In particular, if the ERD contained an administrator account without a password, then that exposed account may be attacked. As a valuable system resource, the ERD should be protected and stored in a physically secure location. |
| Mobile USB Disk devices and their data are not properly secured. |
Mobile USB Disk devices are designed to plug into the USB port on a Windows 2000/2003/XP machine. If the Plug and Play service is running, and the USB ports are not disabled, then the device is recognized and installed without intervention, and will appear as another removable drive in Windows Explorer. These devices are small and portable, and can be easily stolen. Physical protection of the device is essential. These devices are also easily concealable. Generally, Windows will immediately recognize that the USB device has been connected, and will activate it. An unauthorized individual could quickly attach the device, copy sensitive files, and disconnect it in a short period of time. |
| Microsoft Security Configuration Manager is not being used to configure platforms for Security compliance. |
The Microsoft Security Configuration Toolset that is integrated in Windows XP should be used to configure platforms for security compliance. The SCM allows system administrators to consolidate all security related system settings into a single configuration file. These settings can then be applied consistently to any number of Windows Machines. The SCM can use the same configuration file to check platforms for compliance with security policy. If an alternate method is used to configure a system (e.g. manually), that achieves the same configured result, then this is acceptable. Note: The DISA FSO Gold Disk for Windows XP can be used to configure a system to meet security requirements. |
| Unencrypted remote access is permitted to system services. |
This check applies to machines whose services are accessed remotely. (e.g. FTP, Telnet, etc.). When unencrypted access to system services is permitted, an intruder can intercept user identification and passwords that are being transmitted in clear text. This could give an intruder unlimited access to the network. |
This section provides an overview of the security settings that will be put into place by the NIST templates, as listed in Appendix A, as well as additional types of settings that can be added to the templates. The settings are divided into several categories: Account Policies, Local Policies, Event Log Policies, Restricted Groups, System Services, File Permissions, Registry Permissions, and Registry Values. For each category, this section describes at a high level the related security controls from the templates and how the controls can be used to improve the security of the system. This section does not cover all of the actual recommended parameters and values from the security templates.
In addition to educating users regarding the selection and use of good passwords, it is also important to set password parameters so that passwords are sufficiently strong. This reduces the likelihood of an attacker guessing or cracking passwords to gain unauthorized access to the system.86 As described in Section 3.2.1, NIST recommends the use of NTLM v2 or Kerberos instead of LM or NTLM v1 for authentication. Windows XP offers the same password parameters as Windows 2000. The following parameters are specified in the NIST templates:
| CCE-871 | Maximum Password Age |
This forces users to change their passwords regularly. The lower this value is set, the more likely users will be to choose poor passwords that are easier for them to remember (e.g., Mypasswd1, Mypasswd2, Mypasswd3). The higher this value is set, the more likely the password will be compromised and used by unauthorized parties. |
| CCE-324 | Minimum Password Age |
This setting requires users to wait for a certain number of days before changing their password again. The setting prevents a user from changing a password when it reaches the maximum age and then immediately changing it back to the previous password. Unfortunately, this setting also prevents users who inadvertently reveal a new password to others from changing it immediately without administrator intervention. |
| CCE-100 | Minimum Password Length |
This setting specifies the minimum length of a password in characters. The rationale behind this setting is that longer passwords are more difficult to guess and crack than shorter passwords. The downside is that longer passwords are often more difficult for users to remember. Organizations that want to set a relatively large minimum password length should encourage their users to use passphrases, which may be easier to remember than conventional passwords. |
| CCE-633 | Passwords Must Meet Complexity Requirements |
Like the Minimum Password Length setting, this setting makes it more difficult to guess or crack passwords. Enabling this setting implements complexity requirements including not having the user account name in the password and using a mixture of character types, including upper case and lower case letters, digits, and special characters such as punctuation marks. |
| CCE-60 | Enforce Password History |
This setting determines how many old passwords the system will remember for each account. Users will be prevented from reusing any of the old passwords. For example, if this is set to 24, then the system will not allow users to reuse any of their last 24 passwords. Old passwords may have been compromised, or an attacker may have taken a long time to crack encrypted passwords. Reusing an old password could inadvertently give attackers access to the system. |
| CCE-479 | Store Passwords Using Reversible Encryption for All Users in the Domain |
If this setting is enabled, passwords will be stored in a decryptible format, putting them at higher risk of compromise. This setting should be disabled unless it is needed to support a legacy authentication protocol, such as Challenge Handshake Authentication Protocol (CHAP). |
| Strong Password Filtering |
This check determines whether the site has implemented a password filter that enforces the DOD requirments. |
Attackers often attempt to gain access to user accounts by guessing passwords. Windows XP can be configured to lock out (disable) an account when too many failed login attempts occur for a single user account in a certain time period. The following account lockout parameters are set in the NIST templates:
One of the main challenges in setting account policies is balancing security, functionality, and usability. For example, locking out user accounts after only a few failed logon attempts in a long time period may make it more difficult to gain unauthorized access to accounts by guessing passwords, but may also sharply increase the number of calls to the help desk to unlock accounts accidentally locked by failed attempts from legitimate users. This could also cause more users to write down their passwords or choose easier-to-remember passwords. Organizations should carefully think out such issues before setting Windows XP account policies.
| CCE-658 | Account Lockout Threshold |
The threshold value specifies the maximum number of failed attempts that can occur before the account is locked out. |
| CCE-980 | Account Lockout Duration |
This value specifies how long the user account should be locked out. This is often set to a low but substantial value (e.g., 15 minutes), for two reasons. First, a legitimate user that is accidentally locked out only has to wait 15 minutes to regain access, instead of asking an administrator to unlock the account. Second, an attacker who is guessing passwords using brute force methods will only be able to try a small number of passwords at a time, then wait 15 minutes before trying any more. This greatly reduces the chances that the brute force attack will be successful. |
| CCE-733 | Reset Account Lockout Counter After |
This specifies the time period to be used with the lockout threshold value. For example, if the threshold is set to 10 attempts and the duration is set to 15 minutes, then if more than 10 failed login attempts occur with a single user account within a 15-minute period, the account will be disabled. |
Windows XP includes powerful system auditing capabilities. The purpose of auditing is to record certain types of actions to a log, so that system administrators can review the logs and detect unauthorized activity. Audit logs may also be helpful when investigating a security incident that has occurred. As shown in Table 6-1, system auditing is available for logon events, account management, directory service access, object access, policy change, privilege use, process tracking, and system events. Each audit policy category can be configured to record successful events, failed events, both successful and failed events, or neither. Section 7.3 describes how file auditing can be configured, as well as how the Event Viewer can be used to review log entries.
| CCE-315 | Audit Account Login Events |
Audits when a user logs on or off a remote computer from this workstation. |
| CCE-596 | Audit Account Management |
Audits when a user account or group is created, changed, or deleted; a user account is renamed, disabled, or enabled; a password is set or changed. |
| CCE-10 | Audit Directory Service Access |
Audits the event of a user accessing an active directory object that has its own System Access Control List (SACL) specified. This setting is not applicable to Windows XP systems. |
| CCE-429 | Audit Logon Events |
Audits users logging on, logging off, or making a network connection to the local computer. |
| CCE-812 | Audit Object Access |
Audits a user accessing an object (for example, a file, folder, registry key, or printer) that has its own SACL specified. Auditing of success or failure of system wide object access will create numerous log entries. Certain object access failures may be normal as a result of applications requesting all access types to objects, even though the application does not require all access types to function properly. Use object access auditing with caution. |
| CCE-966 | Audit Policy Change |
Audits every change to user rights assignment policies, audit policies, and trust policies. |
| CCE-874 | Audit Privilege Use |
Audits each instance of a user exercising a user right. This is likely to generate a very large number of events. |
| CCE-8 | Audit of Process Tracking |
Audits detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access. Enabling this setting will generate many events, so it should only be used when absolutely necessary. |
| CCE-149 | Audit System Events |
Audits when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log. |
The NIST security templates specify which groups (e.g., Administrators, Users) have certain user rights. The goal is for each group to have only the necessary rights, and for users to only belong to the necessary groups. This is the principle of least privilege, described previously in Section 2.2. Examples of user rights that can be specified are as follows:
- Accessing the system remotely and locally
- Performing backups
- Changing the time and date on the system
- Managing the logs
- Shutting down the system.
Verify that the user right '' has been granted appropriately.
| CCE-532 | Right To Access This Computer From The Network |
Verify that the user right 'Access This Computer From The Network' has been granted appropriately. |
| CCE-162 | Right To Act As Part Of The Operating System |
Verify that the user right 'Act As Part Of The Operating System' has been granted appropriately. |
| CCE-183 | Right To Add Workstations To Domain |
Verify that the user right 'Add Workstations To Domain' has been granted appropriately. |
| CCE-807 | Right To Adjust Memory Quotas For A Process |
Verify that the user right 'Adjust Memory Quotas For A Process' has been granted appropriately. |
| CCE-965 | Right To Log On Locally |
Verify that the user right 'Allow Log On Locally' has been granted appropriately. |
| CCE-883 | Right To Log On Through Terminal Services |
Verify that the user right 'Allow Log On Through Terminal Services' has been granted appropriately. |
| CCE-931 | Right To Back Up Files and Directories |
Verify that the user right 'Back Up Files and Directories' has been granted appropriately. |
| CCE-376 | Right To Bypass Traverse Checking |
Verify that the user right 'Bypass Traverse Checking' has been granted appropriately. |
| CCE-799 | Right To Change the System Time |
Verify that the user right 'Change the System Time' has been granted appropriately. |
| CCE-895 | Right To Create A Pagefile |
Verify that the user right 'Create A Pagefile' has been granted appropriately. |
| CCE-926 | Right To Create A Token Object |
Verify that the user right 'Create A Token Object' has been granted appropriately. |
| CCE-383 | Right To Create Global Objects |
Verify that the user right 'Create Global Objects' has been granted appropriately. |
| CCE-335 | Right To Create Permanent Shared Objects |
Verify that the user right 'Create Permanent Shared Objects' has been granted appropriately. |
| CCE-842 | Right To Debug Programs |
Verify that the user right 'Debug Programs' has been granted appropriately. |
| CCE-898 | Denied Access To This Computer From The Network |
Verify that the user right 'Deny Access To This Computer From The Network' has been granted appropriately. |
| CCE-165 | Denied Logon As A Batch Job |
Verify that the user right 'Deny Logon As A Batch Job' has been granted appropriately. |
| CCE-597 | Denied Logon As A Service |
Verify that the user right 'Deny Logon As A Service' has been granted appropriately. |
| CCE-64 | Denied Logon Locally |
Verify that the user right 'Deny Logon Locally' has been granted appropriately. |
| CCE-108 | Denied Logon Through Terminal Services |
Verify that the user right 'Deny Logon Through Terminal Services' has been granted appropriately. |
| CCE-15 | Computer and User Accounts Enabled To Be Trusted For Delegation |
Verify that the user right 'Enable Computer and User Accounts To Be Trusted For Delegation' has been granted appropriately. |
| CCE-754 | Right To Force Shutdown From A Remote System |
Verify that the user right 'Force Shutdown From A Remote System' has been granted appropriately. |
| CCE-939 | Right To Generate Security Audits |
Verify that the user right 'Generate Security Audits' has been granted appropriately. |
| CCE-304 | Impersonate a Client After Authentication |
Verify that the user right 'Impersonate a Client After Authentication' has been granted appropriately. |
| CCE-349 | Right To Increase Scheduling Priority |
Verify that the user right 'Increase Scheduling Priority' has been granted appropriately. |
| CCE-860 | Right To Load And Unload Device Drivers |
Verify that the user right 'Load And Unload Device Drivers' has been granted appropriately. |
| CCE-749 | Right To Lock Pages In Memory |
Verify that the user right 'Lock Pages In Memory' has been granted appropriately. |
| CCE-177 | Right To Log On As A Batch Job |
Verify that the user right 'Log On As A Batch Job' has been granted appropriately. |
| CCE-216 | Right To Log On As A Service |
Verify that the user right 'Log On As A Service' has been granted appropriately. |
| CCE-850 | Right To Manage Auditing And Security Log |
Verify that the user right 'Manage Auditing And Security Log' has been granted appropriately. |
| CCE-17 | Right To Modify Firmware Environment Values |
Verify that the user right 'Modify Firmware Environment Values' has been granted appropriately. |
| CCE-314 | Right To Perform Volume Maintenance Tasks |
Verify that the user right 'Perform Volume Maintenance Tasks' has been granted appropriately. |
| CCE-260 | Right To Profile Single Process |
Verify that the user right 'Profile Single Process' has been granted appropriately. |
| CCE-599 | Right To Profile System Performance |
Verify that the user right 'Profile System Performance' has been granted appropriately. |
| CCE-656 | Right To Remove Computer From Docking Station |
Verify that the user right 'Remove Computer From Docking Station' has been granted appropriately. |
| CCE-667 | Right To Replace A Process Level Token |
Verify that the user right 'Replace A Process Level Token' has been granted appropriately. |
| CCE-553 | Right To Restore Files And Directories |
Verify that the user right 'Restore Files And Directories' has been granted appropriately. |
| CCE-839 | Right To Shut Down The System |
Verify that the user right 'Shut Down The System' has been granted appropriately. |
| CCE-381 | Right To Synchronize Directory Service Data |
Verify that the user right 'Synchronize Directory Service Data' has been granted appropriately. |
| CCE-492 | Right To Take Ownership Of Files Or Other Objects |
Verify that the user right 'Take Ownership Of Files Or Other Objects' has been granted appropriately. |
Besides the Local Security Policy settings mentioned earlier in this section, additional settings called Security Options can be modified to achieve greater security than the default settings provide. The NIST templates specify values for dozens of such settings. Examples of the types of settings available are as follows:
- Limiting the use of blank passwords
- Renaming the default Administrator and Guest accounts
- Restricting remote access to floppy and CD-ROM drives
- Encrypting secure channel data in a domain
- Securing the interactive logon screen (e.g., not showing the previous user’s account name, displaying a warning banner, prompting users to change passwords before they expire)
- Restricting which types of network access may be performed
- Specifying which types of authentication may be used (e.g., NTLM v2).
The Security Options settings can also be accessed and adjusted manually by performing the following steps:
- From the Start menu, choose Control Panel.
- Select Administrative Tools, and then choose Local Security Policy.
- Expand Local Policies and select Security Options.
- The right pane lists the security option and indicates the current setting for each. Make any necessary changes by double-clicking on the appropriate security option, modifying the setting, and clicking OK to save the change.
| CCE-499 | Accounts: Administrator account status |
The Administrator account status is enabled to allow the administrator to perform configuration control of the system. |
| CCE-332 | Accounts: Guest account status |
A system faces an increased vulnerability threat if the built-in guest account is not disabled. This account is a known account that exists on all Windows systems and cannot be deleted. This account is initialized during the installation of the operating system with no password assigned. This account is a member of the Everyone user group and has all the rights and permissions associated with that group, which could subsequently provide access to system resources to anonymous users. Ensure the built-in guest account is disabled. |
| CCE-533 | Accounts: Limit local account use of blank passwords to console logon only |
In Windows XP Professional, accounts with null or blank passwords can only be used to log on at the physical system’s logon screen. This means that accounts with blank or null passwords cannot be used over networks or with the secondary logon service (RunAs). This feature prevents attackers and malware from gaining remote access through blank passwords. Section 6 contains information on other recommended password settings. |
| CCE-438 | Accounts: Rename administrator account |
The Administrator account is created by default when installing Windows XP. Associating the Administrator SID with a different name may thwart a potential hacker who is targeting the built-in Administrator account. |
| CCE-834 | Accounts: Rename guest account |
The Guest account is created by default when installing Windows XP, but is disabled. Associating the Guest SID with a different name may thwart a potential hacker who is targeting the built-in Guest account. |
| CCE-2 | Audit: Audit the access of global system objects |
Controls the ability to audit access of global systems objects. When this setting is enabled, system objects such as mutexes, events, semaphores, and DOS devices, are created with a default system access control list (SACL). |
| CCE-905 | Audit: Audit the use of Backup and Restore privilege |
Controls the ability to audit the use of all user privileges, including Backup and Restor. If this policy is disabled, certain user rights will not be audited even if "Audit privilege use" audit policy is enabled. |
| CCE-92 | Audit: Shut down system immediately if unable to log security audits |
If events cannot be written to the security log, the system is halted immediately. If the system halts as a result of a full log, an administrator must log ont the system and clear the log. |
| CCE-458 | DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax |
This check verifies that Windows Server 2003/XP, is configured to restrict DCOM access permissions. |
| CCE-740 | DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax |
This check verifies that Windows Server 2003/XP, is configured to restrict DCOM launch permissions. |
| CCE-186 | Devices: Allow undock without having to log on |
Since the removal of a computer should be controlled, users should have to log on before undocking the computer to ensure that they have the appropriate rights to undock the system. |
| CCE-919 | Devices: Allow only administrators to format and eject removable media |
Verifies that only the correct users are allowed to format and eject removable media> |
| CCE-402 | Devices: Prevent users from installing printer drivers |
This setting determines who is allowed to install a printer driver as part of adding a network printer. |
| CCE-565 | Devices: Restrict CD-ROM access to locally logged-on user only |
Removable media devices (CD-ROM) are readable by others on the network if they are not properly configured. A process can remain running in the background after a user logs off, thereby, permitting access to the media, while another user is logged on to the system. |
| CCE-463 | Devices: Restrict floppy access to locally logged-on user only |
Removable media devices (floppy disks) are readable by others on the network if they are not properly configured. A process can remain running in the background after a user logs off, thereby, permitting access to the media, while another user is logged on to the system. |
| CCE-413 | Devices: Unsigned driver installation behavior |
When an attempt is made to install a device driver (by means of the Windows XP device installer) that has not been certified by the Windows Hardware Quality Lab (WHQL), a warning should be issued, but the installation allowed to continue. |
| CCE-257 | Domain controller: Allow server operators to schedule tasks |
This setting determines if Server Operators are allowed to submit jobs using the AT schedule utility. |
| CCE-710 | Domain controller: LDAP server signing requirements |
Requires signing be negotiated before Lightweight Directory Access Protocol (LDAP) clients can bind with Active Directory LDAP server. |
| CCE-490 | Domain controller: Refuse machine account password changes |
Determines whether a domain controller will accept password requests for computer accounts. |
| CCE-549 | Domain member: Digitally encrypt or sign secure channel data (always) |
Domain member: Digitally encrypt or sign secure channel data (always). Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted or signed. If this policy is enabled, outgoing secure channel traffic should be encrypted. |
| CCE-161 | Domain member: Digitally encrypt secure channel data (when possible) |
Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but not all information is encrypted. If this policy is enabled, outgoing secure channel traffic should be encrypted. |
| CCE-918 | Domain member: Digitally sign secure channel data (when possible) |
Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted, but the channel is not integrity checked. If this policy is enabled, all outgoing secure channel traffic should be signed. |
| CCE-831 | Domain member: Disable machine account password changes |
Computer account passwords are changed automatically every seven days. Enabling this policy to disable automatic password changes can make the system more vulnerable to malicious access. Frequent password changes can be a significant safeguard for your system. If this policy is disabled, a new password for the computer account will be generated every week. |
| CCE-194 | Domain member: Maximum machine account password age |
This setting controls the maximum password age that a machine account may have. This setting should be set to no more that 7 days, ensuring that the machine changes its password monthly. |
| CCE-417 | Domain member: Require strong session key |
This setting controls the required strength of a session key. Session keys in Windows XP are stronger than those in NT and should be used whenever possible. |
| CCE-22 | Interactive logon: Display user information when the session is locked |
This setting determines wheter user information should be displayed when the session is locked. |
| CCE-65 | Interactive logon: Do not display last user name |
This setting determines whether the name of the last user to log on to the computer will be displayed in the Windows logon dialog box. |
| CCE-133 | Interactive logon: Do not require CTRL+ALT+DEL |
Disabling the Ctrl+Alt+Del security attention sequence can compromise system security. Because only Windows responds to the Ctrl+Alt+Del security sequence, you can be assured that any passwords you enter following that sequence are sent only to Windows. If you eliminate the sequence requirement, malicious programs can request and receive your Windows password. Disabling this sequence also suppresses a custom logon banner. |
| CCE-829 | Interactive logon: Message text for users attempting to log on |
Failure to display the logon banner prior to a logon attempt will negate legal proceedings resulting from unauthorized access to system resources. |
| CCE-23 | Interactive logon: Message title for users attempting to log on |
The logon banner should be titled with a warning label containing the name of the owning organization. |
| CCE-773 | Interactive logon: Number of previous logons cached (in case domain controller is not available) |
The default Windows XP configuration caches the last logon credentials for users who log on interactively to a system. This feature is provided for system availability reasons such as the users machine is disconnected from the network or domain controllers are not available. Even though the credential cache is well-protected, storing encrypted copies of users passwords on workstations do not always have the same physical protection required for domain controllers. If a workstation is attacked, the unauthorized individual may isolate the password to a domain user account using a password-cracking program, and gain access to the domain. |
| CCE-814 | Interactive logon: Prompt user to change password before expiration. |
This setting configures the system to display a warning to users telling them how many days are left before their password expires. By giving the user advanced warning, the user has time to construct a sufficiently strong password. |
| CCE-374 | Interactive logon: Require Domain Controller authentication to unlock workstation. |
This setting controls the behavior of the system when you attempt to unlock the workstation. If this setting is enabled, the system will pass the credentials to the domain controller (if in a domain) for authentication before allowing the system to be unlocked. |
| CCE-828 | Interactive logon: Require smart card |
This setting determines whether smart cards are required. |
| CCE-443 | Interactive logon: Smart card removal behavior |
When the smart card for a logged-on user is removed from the smart card reader, the workstation should be locked. |
| CCE-576 | Microsoft network client: Digitally sign communications (always) |
This check verifies that the client policy is set to always sign packets. |
| CCE-519 | Microsoft network client: Digitally sign communications (if server agrees) |
This check verifies that the client policy is set to sign packets if the server agrees. |
| CCE-228 | Microsoft network client: Send unencrypted password to third-party SMB servers |
Some non-Microsoft SMB servers only support unencrypted (plain text) password authentication. Sending plain text passwords across the network, when authenticating to an SMB server, reduces the overall security of the environment. Check with the Vendor of the SMB server to see if there is a way to support encrypted password authentication. |
| CCE-222 | Microsoft network server: Amount of idle time required before suspending session |
Administrators should use this setting to control when a computer disconnects an inactive SMB session. If client activity resumes, the session is automatically reestablished. |
| CCE-171 | Microsoft network server: Digitally sign communications (always) |
This check verifies that the server policy is set to always sign packets. |
| CCE-104 | Microsoft network server: Digitally sign communications (if client agrees) |
Microsoft network server: Digitally sign communications (if client agrees). This check verifies that the server policy is set to sign packets if the client agrees. |
| CCE-278 | Microsoft network server: Disconnect clients when logon hours expire |
Users should not be permitted to remain logged on to the network after they have exceeded their permitted logon hours. In many cases, this indicates that a user forgot to log off before leaving for the day. However, it may also indicate that a user is attempting unauthorized access at a time when the system may be less closely monitored. |
| CCE-953 | Network access: Allow anonymous SID-Name translation |
Determines if an anonymous user can request security identifier (SID) attributes for another user or use a SID to get the corresponding username. |
| CCE-318 | Network access: Do not allow anonymous enumeration of SAM accounts |
If this setting is disabled, it allows anonymous logon users (null session connections) to list all account names, thus providing a map of potential points to attack the system. |
| CCE-195 | Network access: Do not allow anonymous enumeration of SAM accounts and shares |
If this setting is disabled, it allows anonymous logon users (null session connections) to list all account names and enumerate all shared resources, thus providing a map of potential points to attack the system. |
| CCE-542 | Network access: Do not allow storage of credentials or .NET Passports for network authentication |
This setting controls the storage of authentication credentials or .NET passports on the local system. Such credentials should never be stored on the local machine as that may lead to account compromise. |
| CCE-18 | Network access: Let Everyone permissions apply to anonymous users |
This setting helps define the permissions that anonymous users have. If this setting is enabled then anonymous users have the same rights and permissions as the built-in Everyone group. Anonymous users should not have these permissions or rights. |
| CCE-136 | Network access: Named Pipes that can be accessed anonymously |
Network access: Named Pipes that can be accessed anonymously. Pipes are internal system communications processes. They are identified internally by ID numbers that vary between systems. To make access to these processes easier, these pipes are given names that do not vary between systems. This setting controls which of these pipes anonymous users may access. |
| CCE-189 | Network access: Remotely accessible registry paths |
Network access: Remotely accessible registry paths. This setting controls which registry paths are accessible from a remote computer. |
| CCE-638 | Network access: Restrict anonymous access to named pipes and shares |
This check determines whether anonymous access is restricted to named pipes and shares. |
| CCE-942 | Network access: Shares that can be accessed anonymously |
This setting controls which network shares may be accessed by an anonymous user. The default setting includes the shares, DFS$, and COMCFG. It is recommended that they be left as the default setting. |
| CCE-343 | Network access: Sharing and security model for local accounts |
Windows XP includes two network-sharing security models Classic and Guest only. It is recommended that the Classic mode be used. |
| CCE-233 | Network security: Do not store LAN Manager hash value on next password change |
This setting controls whether or not a LAN Manager hash of the password is stored in the SAM the next time the password is changed. The LAN Manager hash is a weak encryption algorithm and there are several tools available that use this hash to retrieve account passwords. |
| CCE-775 | Network security: Force logoff when logon hours expire |
This setting controls whether or not users are forced to log off when their allowed logon hours expire. If logon hours are set for users, then this should be enforced. |
| CCE-719 | Network security: LAN Manager authentication level |
The Kerberos v5 authentication protocol is the default for authentication of users who are logging on to domain accounts from computers that are running Windows. The Kerberos protocol is the protocol of choice in Windows systems, when there is a choice. The Windows NTLM protocol was the default for authentication in Microsoft Windows NT version 4.0. It is retained in Windows 2000 for compatibility with clients and servers that are running Windows NT version 4.0 and earlier. It is also used to authenticate logons to stand-alone computers that are running Windows 2000. |
| CCE-719 | Network security: LAN Manager authentication level |
The Kerberos v5 authentication protocol is the default for authentication of users who are logging on to domain accounts from computers that are running Windows. The Kerberos protocol is the protocol of choice in Windows systems, when there is a choice. The Windows NTLM protocol was the default for authentication in Microsoft Windows NT version 4.0. It is retained in Windows 2000 for compatibility with clients and servers that are running Windows NT version 4.0 and earlier. It is also used to authenticate logons to stand-alone computers that are running Windows 2000. |
| CCE-732 | Network security: LDAP client signing requirements |
This setting controls the signing requirements for LDAP clients. This setting should be set to Negotiate signing or Require signing depending on the environment and type of LDAP server in use. |
| CCE-674 | Network security: Minimum session security for NTLM SSP based (including secure RPC) clients |
Starting with Windows 2000 Microsoft has implemented a variety of security support providers for use with RPC sessions. In a homogenous Windows XP environment, all of the options should be enabled and testing should be performed in a heterogeneous environment to determine the maximum-security level that provides reliable functionality. |
| CCE-766 | Network security: Minimum session security for NTLM SSP based (including secure RPC) servers |
Starting with Windows 2000 Microsoft has implemented a variety of security support providers for use with RPC sessions. In a homogenous Windows XP environment, all of the options should be enabled and testing should be performed in a heterogeneous environment to determine the maximum-security level that provides reliable functionality. |
| CCE-410 | Recovery console: Allow automatic administrative logon |
If this option is enabled, the Recovery Console does not require you to provide a password and will automatically log on to the system, giving Administrator access to system files. By default, the Recovery Console requires you to provide the password for the Administrator account before accessing the system. |
| CCE-76 | Recovery console: Allow floppy copy and access to all drives and all folders |
Enabling this option enables the Recovery Console SET command, which allows you to set Recovery Console environment variables. This permits floppy copy and access to all drives and folders. It should be disabled. |
| CCE-224 | Shutdown: Allow system to be shut down without having to log on |
Displaying the shutdown button may allow individuals to shut down a system anonymously. Only authenticated users should be allowed to shut down the system. Preventing display of this button in the logon dialog box, ensures that individuals who shut down the system are authorized and tracked in the systems Security event log. |
| CCE-422 | Shutdown: Clear virtual memory pagefile |
Virtual memory support of Windows XP uses a system page file to swap blocks of memory not actively being used to disk. While Windows XP is running, this file is opened exclusively by the operating system, thus ensuring it is reasonably protected. However, the system page file should be wiped clean of all user data when the system shuts down. This ensures that sensitive information that may be in the page file is not available for retrieval by an anonymous user. |
| CCE-647 | System cryptography: Force strong key protection for user keys stored on the computer |
This setting determines whether the system forces strong key protection for user keys stored on the system. |
| CCE-55 | System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing |
This setting ensures that the system uses algorithms that are FIPS compliant for encryption, hashing, and signing. FIPS compliant algorithms meet specific standards established by the U.S. Government and should be the algorithms used for all OS encryption functions. |
| CCE-575 | System objects: Default owner for objects created by members of the Admnistrators group |
Either the object creator or the Administrators group owns objects created by members of the Administrators group. In order to ensure accurate auditing and proper accountability, the default owner should be the object creator. |
| CCE-300 | System objects: Require case insensitivity for non-Windows subsystems |
This setting controls the behavior of non-Windows subsystems when dealing with the case of arguments or commands. Case sensitivity could lead to the access of files or commands that should be restricted. To prevent this from happening, case insensitivity should be required. |
| CCE-508 | System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links) |
System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links). Windows systems maintains an internal list of shared system resources such as DOS device names, mutexes, and semaphores. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. If this policy is enabled, the default DACL is stronger, allowing non-admin users to read shared objects, but not modify shared objects that they did not create. |
| CCE-48 | System settings: Optional subsystems |
This check determines whether optional subsystems are allowed. |
| CCE-572 | System settings: Use certificate rules on Windows executables for software restriction policies |
This check determines whether certificate rules are used on Windows executables for software restriction policies. |
| CCE-283 | MSS: (AutoAdminLogon) Enable Automatic Logon Disabled |
If enabled, this setting will allow a user to directly log on to the system with administrator privileges when the machine is rebooted. This would give full access to any unauthorized individual who reboots the computer. By default this setting is not enabled. If this setting exists, it should be disabled. If this capability exists, the default password will also be present in the registry, and must be removed. |
| CCE-137 | MSS: (AutoReboot) Allow Windows to automatically restart after a system crash |
This check determines whether Windows is allowed to automatically restart after a system crash. |
| CCE-512 | MSS: (AutoShareWks) Enable administrative shares |
This check determines whether administrative shares are enabled. |
| CCE-564 | MSS: (DisableIPSourceRouting) IP source routing protection level |
This setting protects against packet spoofing. Set to 2 to completely disable source routing. |
| CCE-156 | MSS: (DisableSavePassword) Prevent the dial-up password from being saved |
This check determines whether the dial-up password is prevented from being saved. |
| CCE-897 | MSS: (EnableDeadGWDetect) Allow automatic detection of dead network gateways |
If this setting is enabled, it could lead to a denial of service. |
| CCE-150 | MSS: (EnableICMPRedirect) Allow ICMP redirects to override OSPF generated routes |
This check determines whether ICMP redirects are allowed to override OSPF generated routes. |
| CCE-139 | MSS: (Hidden) Hide Computer From the Browse List |
This setting is not recommended to be enabled, except for highly secure environments. |
| CCE-188 | MSS: (KeepAliveTime) How often keep-alive packets are sent in milliseconds |
This check verifies that the system is configured to control how often TCP attempts to verify that an idle connection is still intact by sending a keep-alive packet. |
| CCE-501 | MSS: (NoDefaultExempt) Enable NoDefaultExempt for IPSec Filtering |
Setting this to 1 removes exemptions for Kerberos and RSVP traffic, and keeps exemptions for multicast, broadcast, and ISAKMP. |
| CCE-44 | MSS: (NoDriveTypeAutoRun) Disable Autorun for all drives |
This check verifies that the system is configured to turn off the Autorun feature on all drives |
| CCE-817 | MSS: (NoNameReleaseOnDemand) Allow the computer to ignore NetBIOS name release requests except from WINS servers |
This check verifies that the system is configured to prevent release of its NetBIOS name when a name-release request is received. |
| CCE-511 | MSS: (NtfsDisable8dot3NameCreation) Enable the computer to stop generating 8.3 style filenames |
This check determines whether the system is allowed to generate 8.3 style filenames. |
| CCE-952 | MSS: (PerformRouterDiscovery) Allow IRDP to detect and configure DefaultGateway addresses |
This check verifies that the system is configured to disable the Internet Router Discovery Protocol (IDRP), which could lead to a denial of service. |
| CCE-271 | MSS: (SafeDllSearchMode) Enable Safe DLL search mode |
The default search behavior, when an application calls a function in a Dynamic Link Library (DLL), is to search the current directory followed by the directories contained in the systems path environment variable. An unauthorized DLL inserted into an applications working directory could allow malicious code to be run on the system. Creating the SafeDllSearchMode registry key and setting the appropriate value forces the system to search the %Systemroot% for the DLL before searching the current directory or the rest of the path. |
| CCE-830 | MSS: (ScreenSaverGracePeriod) The time in seconds before the screen saver grace period expires |
This check verifies that the system is configured to have password protection take effect immediately when the screen saver becomes active. |
| CCE-284 | MSS: (SynAttackProtect) Syn attack protection level |
This check verifies that the system is configured to protect against Syn attacks. The setting should be set to "Connections time out sooner if a SYN attack is detected." |
| CCE-577 | MSS: (TCPMaxConnectResponseRetransmissions) SYN-ACK retransmissions when a connection request is not acknowledged |
This check verifies that the system is configured to control the maximum number of times that TCP retransmits a SYN before aborting the attempt. |
| CCE-872 | MSS: (TCPMaxDataRetransmissions) How many times unacknowledged data is retransmitted |
This check verifies that the system is configured to control the maximum number of times that TCP retransmits unacknowledged data segments before aborting the attempt. |
| CCE-125 | MSS: (WarningLevel) percentage threshold for the security event log at which the system will generate a warning |
This check verifies that the system is configured to generate a warning when the Security Event Log has reached a defined threshold. If the system is configured to write to an audit server, or is configured to automatically archive full logs, then this check does not apply. |
Windows XP records information about significant events in three logs: the Application Log, the Security Log, and the System Log. The logs contain error messages, audit information, and other records of activity on the system. The logs can be used not only to identify suspicious and malicious behavior and investigate security incidents, but also to assist in troubleshooting system and application problems. Therefore, it is important to enable logging for all three types of logs. The NIST templates enable all three logs for all environments, and also specify the maximum log size. This is important because if the maximum log size is very low, the system will not have much room for storing information on system activity. Some organizations may have a logging policy and central log server, so the template settings may need to be adjusted so they comply with the policy.
| CCE-185 | Maximum Application Log Size |
Inadequate log size will cause the log to fill up quickly and require frequent clearing by administrative personnel. An exception is for NT workstations that do not share resources. The smaller size should allow sufficient audit information for supporting the investigation of suspicious events, but since it is overwritten, does not require administrator interaction for clearing the file. Microsoft recommends that the combined size of all the event logs (including DNS logs, Directory Services logs, and Replication logs on Servers or Domain Controllers) should not exceed 300 megabytes. Exceeding the recommended value can impact performance. |
| CCE-757 | Maximum Security Log Size |
Inadequate log size will cause the log to fill up quickly and require frequent clearing by administrative personnel. An exception is for NT workstations that do not share resources. The smaller size should allow sufficient audit information for supporting the investigation of suspicious events, but since it is overwritten, does not require administrator interaction for clearing the file. Microsoft recommends that the combined size of all the event logs (including DNS logs, Directory Services logs, and Replication logs on Servers or Domain Controllers) should not exceed 300 megabytes. Exceeding the recommended value can impact performance. |
| CCE-735 | Maximum System Log Size |
Inadequate log size will cause the log to fill up quickly and require frequent clearing by administrative personnel. An exception is for NT workstations that do not share resources. The smaller size should allow sufficient audit information for supporting the investigation of suspicious events, but since it is overwritten, does not require administrator interaction for clearing the file. Microsoft recommends that the combined size of all the event logs (including DNS logs, Directory Services logs, and Replication logs on Servers or Domain Controllers) should not exceed 300 megabytes. Exceeding the recommended value can impact performance. |
| CCE-299 | Prevent Local Guests Group From Accessing Application Log |
By default, the Windows XP event logs may be viewed over the network by an anonymous user. This method of access over the network is communicating through the Server service which has SYSTEM access to the actual log files. |
| CCE-462 | Prevent Local Guests Group From Accessing Security Log |
By default, the Windows XP event logs may be viewed over the network by an anonymous user. This method of access over the network is communicating through the Server service which has SYSTEM access to the actual log files. |
| CCE-726 | Prevent Local Guests Group From Accessing System Log |
By default, the Windows XP event logs may be viewed over the network by an anonymous user. This method of access over the network is communicating through the Server service which has SYSTEM access to the actual log files. |
| CCE-285 | Retention of Events in Application Log |
The application log should be configured to correctly handle itself when it reaches the maximum size. The log can be overwritten after a certain number of days, overwritten when it becomes full, or have to be cleared manually. |
| CCE-523 | Retention of Events in Security Log |
The security log should be configured to correctly handle itself when it reaches the maximum size. The log can be overwritten after a certain number of days, overwritten when it becomes full, or have to be cleared manually. |
| CCE-664 | Retention of Events in System Log |
The system log should be configured to correctly handle itself when it reaches the maximum size. The log can be overwritten after a certain number of days, overwritten when it becomes full, or have to be cleared manually. |
NIST recommends that all users be removed from the Remote Desktop Users group on all systems in all environments, except for those users that specifically need to belong to the group. This will reduce the possibility of someone gaining unauthorized access to the system through Remote Desktop. NIST also recommends restricting membership in the Power Users group because it is nearly equivalent in privileges to the Administrators group. Users should not use an account in the Power Users group to operate a system on a daily basis; such accounts should be treated as Administrators group accounts and used only when necessary. Whenever possible, users who need additional privileges, but not full administrativelevel access, should be granted the individual privileges needed instead of the range of privileges granted by Power Users group membership. By default, each NIST security template removes all users from the Remote Desktop Users and Power Users groups; the Specialized Security-Limited Functionality template also removes all users from the Backup Operators group.
| CCE-506 | Backup Operators Restricted Group |
The Restricted Groups option allows the administrator to manage membership of sensitive groups. The Backup Operators group is one such group. This group has been given significant privileges under Windows XP. |
| CCE-990 | Power Users Restricted Group |
The Restricted Groups option allows the administrator to manage membership of sensitive groups. The Power Users group is one such group. This group has been given significant privileges under Windows XP. |
| CCE-250 | Remote Desktop Users Restricted Group |
The Restricted Groups option allows the administrator to manage membership of sensitive groups. The Remote Desktop Users group is one such group. This group has been given significant privileges under Windows XP. |
Windows XP operates with many services that are started automatically when the system boots up. These services consume resources and may introduce vulnerabilities to the host. All unnecessary services should be disabled to reduce the number of attack vectors against the system. In managed environments, the Group Policy Object should be used to configure services on systems; in other environments, services can be shut off individually on each system. For both configuration methods, each service on a system can be configured with one of three startup types:
- Automatic. The service is started automatically. This means that the service is running whenever the system is up.
- Manual. The service is started only by the system when it is needed. In practice, many services that are reconfigured to Manual are not automatically started when needed; for example, if the Print Spooler is set to Manual, it will not be started when a user tries to print a document. Also, if a service is dependent on another service that has been set to Manual, the first service may incorrectly assume the second service is already running.90
- Disabled. The service cannot be started by the system.
NIST recommends that the following services be disabled in all environments unless there is a specific need that requires them to be enabled:
- Alerter91
- ClipBook
- FTP Publishing Service
- IIS Admin Service
- Messenger
- NetMeeting Remote Desktop Sharing
- Routing and Remote Access
- Simple Mail Transfer Protocol (SMTP)
- Simple Network Management Protocol (SNMP) Service
- Simple Network Management Protocol (SNMP) Trap
- Simple Service Discovery Protocol (SSDP) Discovery Service
- Telnet
- World Wide Web Publishing Services
Each of the NIST security templates disables all of these services. In addition, the NIST templates disable other services such as Computer Browser, Fax, Indexing Service, Remote Desktop Help Session Manager, Task Scheduler, Terminal Services, and Universal Plug and Play Device Host only for certain environments. It may be challenging, particularly in enterprise environments, to determine which services can be disabled safely. Certain services may be needed only for particular applications. The strategy that best supports functionality is to test each service that appears to be unneeded by setting it to Disabled startup mode and testing all applications. Appendix A includes a list of built-in services that the NIST templates disable.
To change the startup mode for a particular service, perform the following steps:
- Click the Start menu and choose Control Panel.
- Select Administrative Tools and then select Services.
- Click the Standard tab view located at the bottom of the window.
- Double-click the service name (e.g., ClipBook).
- If the service should be set to Manual or Disabled, click the Stop button if the service is started.
- Set the Startup type to Automatic, Manual, or Disabled and click OK.
- Exit the Computer Management tool.
To disable the Universal Plug and Play feature, follow the steps above for both the SSDP Discovery Service and the Universal Plug and Play (UPnP) Device Host service. The procedure for disabling the Remote Assistance and Remote Desktop features is different than disabling other services. Although these features are helpful for support, they also expose the computer to network-based attacks. As such, unless an organizational requirement exists to have them enabled, perform the following steps to disable them:
- Right-click My Computer and select Properties.
- Select the Remote tab and uncheck the Allow Remote Assistance invitations to be sent from this computer and Allow users to connect remotely to this computer boxes. Click OK.
| CCE-487 | Alerter Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-954 | ClipBook Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-294 | Computer Browser Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-78 | Fax Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-712 | FTP Publishing Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-311 | IIS Admin Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-738 | Indexing Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-729 | Messenger Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-232 | NetMeeting Remote Desktop Sharing Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-217 | Network Dynamic Data Exchange (DDE) Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-768 | Network DDE DDE Share Database Manager (DSDM) Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-750 | Remote Access Connection Manager Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-663 | Remote Desktop Help Session Manager Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-223 | Routing And Remote Access Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-870 | Simple Mail Transfer Protocol (SMTP) Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-975 | Simple Network Management Protocol (SNMP) Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-892 | Simple Network Management Protocol (SNMP) Trap Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-940 | Simple Service Discovery Protocol (SSDP) Discovery Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-40 | Task Scheduler Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-75 | Telnet Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-974 | Terminal Services Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-608 | Universal Plug And Play Device Host Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-758 | World Wide Web Publishing Services Service Disabled |
Unnecessary services should not be running on the system. Services typically run under the local System Account, which generally have more permissions than are required by the service. Compromising a service could allow an intruder to obtain System permissions and open the system to a variety of attacks. |
| CCE-600 | arp.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-393 | at.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-166 | attrib.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-977 | cacls.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-201 | debug.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-20 | edlin.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-489 | eventcreate.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-917 | eventtriggers.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-264 | ftp.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-550 | nbtstat.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-731 | net.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-607 | net1.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-158 | netsh.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-220 | netstat.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-242 | nslookup.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-821 | ntbackup.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-997 | rcp.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-547 | reg.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-795 | regedit.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-865 | regedt32.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-543 | regini.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-657 | regsvr32.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-274 | rexec.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-168 | route.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-353 | rsh.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-516 | sc.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-922 | secedit.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-921 | subst.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-225 | systeminfo.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-159 | telnet.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-348 | tftp.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-718 | tlntsvr.exe Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-272 | ciadv.msc Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-170 | compmgmt.msc Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-386 | devmgmt.msc Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-941 | dfrg.msc Permissions |
Failure to properly configure ACL file and directory permissions, allows the possibility of unauthorized and anonymous modification to the operating system and installed applications. |
| CCE-363 | SeCEdit Permissions |
The required permissions for the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit should be assigned. |
The NIST templates set values for several registry keys not previously mentioned in this section. The following items provide the registry key name and path, describe its purpose, and recommend an appropriate setting.
| CCE-536 | CreateCrashDump |
Setting this value to 0 disables the creation of a memory dump file by the Dr. Watson program debugger. Memory dumps can contain sensitive information such as passwords. See Section 7.9 for additional information on suppressing memory dump file creation. This setting should be enabled to troubleshoot a recurring problem. |
| CCE-243 | AEDebugAuto |
Setting this value to 0 disables Dr. Watson. |
| CCE-344 | CDromAutorun |
Setting this value to 0 disables the autorun feature for CDs. |
| CCE-282 | RefuseReset |
Setting this parameter to 1 causes the system to ignore ResetBrowser frames. Such frames can be used to shut down NetBIOS and master browsers and to declare a computer as being the new master browser. Earlier versions of Windows could be attacked through ResetBrowser frames. |
| CCE-998 | EnablePMTUDiscovery |
When this parameter is set to 1, TCP attempts to discover the Maximum Transmission Unit (MTU), the size of the largest packet that can be kept intact over the path to a remote host. Setting this parameter to 0 disables the feature and causes an MTU of 576 bytes to be used for all connections that are not made to hosts on the local subnet. |
| CCE-333 | TcpMaxHalfOpen |
This setting specifies the number of connections permitted in the SYN-RCVD state before SynAttackProtect measures are implemented. |
| CCE-751 | TcpMaxHalfOpenRetried |
This setting specifies the number of connections permitted in the SYN-RCVD state for which at least one retransmission of the SYN has been sent, before SynAttackProtect measures are implemented. |
| CCE-418 | TCPMaxPortsExhausted |
This setting specifies how many connection requests can be refused before SynAttackProtect measures are implemented. |
- Establish account policies that reduce the likelihood of an attacker guessing or cracking passwords to gain unauthorized access to systems. The policies should balance security, functionality, and usability.
- Configure the audit policy to record certain types of activity to a log, so that system administrators can review the logs and detect unauthorized activity.
- Assign user rights following the principle of least privilege.
- Set additional security options to achieve greater security than the default options provide; examples include limiting the use of blank passwords, renaming the default Administrator and Guest accounts, and specifying which types of authentication may be used.
- Enable logging for the Application, Security, and System Logs.
- Remove all users from the Remote Desktop Users and Power Users groups that do not specifically need to be members.
- Disable all unnecessary services.
- Disable the Universal Plug and Play feature and the Remote Assistance feature unless they are needed.
- Use ACLs to restrict access to critical executables and registry entries.
- Set registry values that limit debugging and automatic execution of CD-ROM content, as well as configuring networking more securely.
- Review, customize, test, document, and deploy the NIST security templates to secure Windows XP systems.
The previous section of this guide discussed the configuration settings implemented by the NIST templates. This section addresses additional security-related recommendations for Windows XP that are not included in the templates. These recommendations should either be configured manually or applied with the aid of additional .inf or .adm files that are not included with the NIST guide. The recommendations address filesystem security issues, user accounts and groups, auditing, software restriction policies, network interfaces, Windows Firewall, and IPsec.
It is important to consider the concept of security for a Windows XP workstation as an ongoing task. The recommendations presented in this section and previous sections do not entail the complete set of possible security considerations and concerns for the entire life cycle of a Windows XP workstation. System administrators and end users should consider the effect that each decision made regarding a workstation might have on its security.
Filesystem security is a very important component of host security. This section describes the filesystems available in Windows XP—NTFS, File Allocation Table 16 (FAT16), and FAT32—and explains why NTFS should be used. The Folder Options section of Control Panel contains several settings that are related to filesystem security, such as determining which application should run a file based on its file extension; this section discusses those settings and recommends how they should be set. This information can be particularly helpful in preventing malware infections caused by running files with unusual file extensions. In addition, by default, Windows XP systems have registry settings that suppress the display of certain file extensions. This section explains how to find and delete the registry settings so that all filenames are displayed the same way, regardless of file extension. Another topic addressed in this section is supporting the confidentiality and integrity of data through Encrypting File System (EFS).
In terms of security, the NTFS filesystem is vastly superior to the other XP filesystem options—FAT16 and FAT32. Neither FAT16 nor FAT32 provides features for establishing access control for files or encrypting files. Windows XP uses NTFS version 3.1; it is very similar to version 3.0, which is used by Windows 2000. The most notable new features in version 3.1 are disk quotas and file encryption. NTFS can also provide highly granular access control for files, folders, and shares, as well as other resources on the system.
| NTSF Partitions |
Use NTFS for each hard drive partition unless there is a particular need to use another type of filesystem. |
Modifying the Folder Options can greatly improve defenses against malware. The system can be configured to show all filenames fully, including their extensions. In addition, Folder Options contains the associations between file types and the default applications that run each file type. By modifying the associations for file extensions that are often used for malicious purposes, such files will be run by the Notepad application, which effectively neutralizes them. The Folder Options changes described below are highly recommended for every environment. The only caveat is that any file extensions that have a legitimate function in the organization should not be remapped to Notepad, or the functionality may be broken.
TO-DO
| Printer Share Permissions |
This check verifies that shared printers have properly configured share permissions. |
TO-DO
TO-DO
By default, Windows XP includes a number of network protocols and components that are not usually required in all environments. For example, the File and Printer Sharing for Microsoft Networks service and the Client for Microsoft Networks are included in most Windows XP installations. These features allow the user to share resources on a network with other Windows systems, but they may increase the system's exposure level. The user should operate the system with only the necessary network protocols and disable the Microsoft networking client/server components if they are not being used.
As previously discussed in Section 4.1.2.1, network clients, services, and protocols that are not needed should be disabled. This reduces the likelihood that the system will be compromised or misused. Use caution when disabling any network components, because this can cause required functionality to break, sometimes in unexpected ways. The following components are candidates for being disabled:
- The QoS Packet Scheduler is designed to prioritize network traffic by application or service over slow network connections. Most applications are not QoS-aware, and some are incompatible with QoS, so the QoS Packet Scheduler is not beneficial in most situations. In general, the QoS Packet Scheduler should be disabled unless testing in a specific environment demonstrates that it is beneficial at alleviating network bandwidth issues.
- Uninstalling the File and Printer Sharing for Microsoft Networks service will prevent other systems from connecting to the local file and printer shares; it will not prevent users of the local system from connecting to remote file and printer shares. Therefore, leave this service installed only if the local system shares its resources (e.g., files, printers) and users on other systems need to connect to these resources through the network, or necessary applications (e.g., MBSA) require the service.
- Uninstalling the Client for Microsoft Networks will prevent the local system from establishing network connections to other systems’ Microsoft file and printer shares. Most systems will require the client to be enabled, so it should generally be disabled only if the system has particularly high security needs.
| Disable Unnecessary Components |
Disable all network clients, services, and protocols that are not required. |
TO-DO
Windows XP provides built-in support for wireless networking (also known as wireless fidelity, or Wi-Fi). By default, Windows XP systems use Wi-Fi in infrastructure mode, which means that they are clients connecting to a wireless access point (AP). (The alternative is ad hoc mode, which means that wireless clients connect to each other without an AP. Ad hoc mode is rarely used.) The most commonly used Wi-Fi protocol, IEEE 802.11b, relies on the Wired Equivalent Privacy (WEP) protocol, which has several known security issues. To provide a more secure Wi-Fi solution, an industry group called the Wi-Fi Alliance has created a product certification called Wi-Fi Protected Access (WPA). WPA requires stronger security than WEP provides, including more robust authentication and key management, mandatory encryption (including optional AES support), and data integrity checking. NIST recommends that Windows XP Wi-Fi users use a stronger security solution than WEP whenever possible. For WPA, this involves installing a new network adapter driver on each Windows XP system, updating APs to support WPA, and configuring Wi-Fi clients and APs to take advantage of WPA’s features.
TO-DO
- In enterprise and specialized security-limited functionality environments, rebuild existing systems based on FAT partitions with NTFS, instead of converting FAT to NTFS.
- Modify the Folder Options to improve defenses against malware by showing all filenames fully and modifying the associations for file extensions often used for malicious purposes.
- Deploy EFS when the confidentiality of the information in question is critical or when the system faces significant physical threats. Any EFS deployment should take into account key management issues; if key management is not handled effectively, the use of EFS could contribute to the loss of valuable information. On systems that are using EFS, use Syskey to establish a startup key that protects the private keys used for EFS.
- Sanitize all storage devices, including fixed devices and removable devices and media, before reusing them or disposing of them.
- Create a separate user-level account for each person performing daily operation of a system. Use administrative-level accounts for system administration tasks only.
- In non-managed environments, create a password reset disk for the system and store it in a physically secure location.
- Disable and rename the built-in Administrator and Guest accounts.
- Use a password-enabled screen saver to protect the system from unauthorized local access.
- Review audit logs on a regular basis.
- Use Windows Firewall to restrict inbound network connections unless the system is already protected by a third-party host-based firewall.
- Use a stronger security solution than WEP whenever possible for wireless networking.
- Configure the system not to create dump files, unless they are specifically needed for troubleshooting purposes.