Executive Summary

Like Microsoft, organizations across the globe face unique challenges in enhancing security for Web applications and their IT infrastructures. Issues such as improper Web server configuration, weak authentication policies, and invalidated Web requests can lead to unauthorized user access and potential attacks. To mitigate these risks, organizations must apply appropriate security policies and guidelines.

At Microsoft, the Windows Live^TM environment provides services to millions of customers each month for e-mail, mobile devices, personalized Web spaces, and search queries. The Online Services Security & Compliance (OSSC) team provides security for this extensive environment—ncluding several data centers that house more than 60,000 computers.

This white paper describes the best practices that OSSC implements to provide security for Web applications and the IT infrastructure of the Windows Live environment® from platform and network security to incident management. These best practices address strategies for identifying the risks to the environment, setting standards for asset classification, and implementing a risk management process. These best practices also offer prescriptive guidance to help organizations secure confidential information assets, sensitive customer information, and network data.

This paper is written for Microsoft partners and IT professionals who want to enhance enterprise security for Web applications and the IT infrastructure.

Introduction

Mitigating the diverse security risks for Web applications and an IT infrastructure is an intricate process. At Microsoft, OSSC established best practices based on its experiences in providing security for the extensive Windows Live environment. These guidelines address all aspects of security, including data classification, risk management, password standards, systems management, and connectivity issues. By employing these best practices, organizations of any size can effectively mitigate security vulnerabilities and risks.

Global Foundations Services

At Microsoft, the Global Foundations Services (GFS) group maintains systems manageability and security for 400 million Microsoft®MSN®and Windows Live customers around the world. GFS also provides the infrastructure for communication and collaboration services at Microsoft, in addition to other online services and Web portals, such as Microsoft.com. 

As one of the 120 groups that GFS supports, Windows Live offers Internet services and software to millions of customers. These services and software are designed to bring together in one place all the information and interests that users care about most—all with enhanced safety and security features.

Currently, the Windows Live environment maintains:

• Nearly 230 million Microsoft Hotmail®users per month.
• 6 million mobile users per month.
• 61 million personalized Web spaces per month.
• 215 million Microsoft Windows® Messenger users per month.
• More than 80,000 Windows-based server computers.
• More than 100 million search queries per month.
• Twelve data centers.

Addressing the security challenges of this dynamic environment is critical to the success of Microsoft. A combination of factors—including an evolving security landscape full of potential vulnerabilities in a large IT environment—presents a challenging array of variables to consider.

OSSC Online Services Security & Compliance

The OSSC team provides security for online services in the Windows Live environment, including managing data-center operations, enhancing application security, and helping to protect customer data. The goal of OSSC is to identify, organize, and address all potential security vulnerabilities and threats to the environment. As such, OSSC is continually developing mechanisms to understand, communicate, and prioritize existing and emerging threats to the enterprise.

The OSSC mission includes the following tasks:

• Analyze threats and risks. Deliver a trustworthy computing environment that helps protect customer data, intellectual property, and service availability.
• Define policy. Ensure that Microsoft Web applications and infrastructure conform to security-enhanced development policies and practices.
• Assess and audit compliance. Establish processes to assess adherence to security policies and standards.
• Monitor and operate. Provide the people, processes, and technology to build, maintain, and operate security-enhanced systems that in turn provide systemic prevention, detection, containment, remedy, and recovery.

Figure 1 illustrates the OSSC mission.

Figure 1. Online Services Security & Compliance mission

OSSC must continually monitor the security environment and apply systematic, trustworthy assurances for the network, the host, the application, and the user. Users must understand their roles and accountability in helping to provide a secure environment. For users, OSSC makes the following assurances:

• Customer identity are protected online
• Resources are managed in a security-enhanced manner.
• Data and communications are protected for privacy.
• Information about risk is shared in a timely manner.

The remainder of this paper focuses on the best practices that OSSC has learned in helping to secure the Windows Live environment. OSSC deploys these methods to mitigate and manage the various security challenges posed to Web applications and the infrastructure.

Security Challenges

As with the Windows Live environment, an organization must address a variety of challenges in providing security for Web applications and the IT infrastructure. The improper configuration of a Web server can lead to the exposure of confidential information assets or sensitive customer data. In addition, weak authentication policies can allow unauthorized users to access application and network data—opening an opportunity for potential attacks. These and other security vulnerabilities make it difficult for organizations of all sizes to provide effective platform and network security.

Security Categories and Risk

By identifying the primary vulnerabilities and risks for Web applications, organizations can implement more effective security policies and guidelines to mitigate those risks. The security challenges for Web applications and the infrastructure can be divided into three primary categories:

• Confidentiality. Enforces the necessary level of secrecy at each junction of data processing and prevents the unauthorized disclosure and monitoring of data. The goal of confidentiality is to ensure that only authorized parties can access certain data.
• Integrity. Provides the assurance of accuracy and reliability of information and systems, and prevents the unauthorized modification of data. The goal of integrity is to maintain the trustworthiness of data; security measures, as much as possible, should ensure that data provided to users is trustworthy.
• Availability. Provides reliable and timely access to data and resources for authorized individuals. The goal of information availability is to maintain the usefulness of a solution at all times. Although frequently overlooked in security planning, availability is an essential part of an effective security policy.

Table 1 lists the risks associated with these primary security categories.

Table 1. Security Categories and Risks for Web Applications

Asset Classification

Asset classification is another critical component of effectively mitigating security risks. By classifying assets based on the three primary security risk categories—confidentiality, integrity, and availability—organizations can further enhance the security of their environments.

All IT organizations have physical assets, such as hardware or information in various forms, and logical assets, such as application code, server logs, or encryption keys. For each organization, we recommend designating an asset owner as the creator, generator, or primary possessor of an asset.

The asset owner should be responsible for providing security for his or her assets. Tasks include:

• Maintaining an accurate inventory of major assets.
• Classifying each asset according to the organization's guidelines, and identifying each asset's risk level.
• Ensuring that each classified asset receives an appropriate amount of protection.
• Ensuring that an asset inventory is provided to the appropriate personnel.

As a best practice, asset owners should define the level of security for all types of assets based on confidentiality, integrity, and availability. Realistically, assets will maintain varying degrees of each risk category (for example, external Web site data must be available and have complete integrity, but it is not confidential).

It is a good idea to use explanatory terms instead of general descriptors to define asset security. For example, a data asset that should not be made available outside the organization might be labeled "Internal Only."

In addition, we recommend using three asset classes to measure the value of the data to the organization. These asset classes address high business impact (HBI) data, moderate business impact (MBI) data, and low business impact (LBI) data.

HBI Data

HBI data is intended for immediate and direct authentication and/or authorization of valuable transactions, or is subject to specific regulatory requirements. Loss or unauthorized disclosure of HBI data would result in immediate and considerable impact to the business. Access to this data should be restricted to only the most trusted parties.

Examples of HBI data include:

• Highly sensitive personally identifiable information (PII) such as government-provisioned identification credentials, financial transaction or authorization data, and financial or medical profiles.
• Passwords and private cryptographic keys.
• Intellectual property.

MBI Data

MBI data cannot be used to immediately or directly authenticate or authorize valuable transactions and is intended for limited use. Loss or unauthorized disclosure of MBI data would result in indirect, limited impact to the business. The asset owner should apply strict rules to the use and management of MBI data.

Examples of MBI data include:

• PII such as name, address, phone number, e-mail address, or static IP address.
• Network infrastructure designs.
• Data on internal file shares.

LBI Data

LBI data has no formal classification or protection requirements, and it is intended for wide publication or dissemination. Loss of LBI data would result in minimal or no impact to the business.

Examples of LBI data include:

• Publicly available Web pages.
• Public cryptographic keys.
• Published documents, such as press releases.

A classification decision process, as shown in Figure 2, can help asset owners determine the appropriate data class.

Figure 2. Asset classification decision tree

Risk Management

Risk management is the process of identifying, evaluating, and mitigating risk on an ongoing basis. An effective risk management approach also involves aligning the cost of security with business needs. By investing in a risk management process that includes a solid framework with defined roles and responsibilities, organizations can better identify priorities, mitigate threats, and address potential vulnerabilities.

The following best practices apply to establishing a security risk management process:

• Identify the appropriate level of security for assets according to their data classification.
• Determine the most appropriate and cost-effective measures to mitigate security threats.
• Establish regular security risk reviews to ensure that the proper controls are in place to help protect the organization.

Risk Assessment

Effective risk management is dependent on the accurate classification of assets in terms of risk. In some cases, assets might require additional protective measures to help ensure their confidentiality, integrity, and availability. Determining risk assessment takes into account many factors, including asset aggregation and multiple standards.

Mixed Classification and Aggregation

When assets of different classifications are mixed, the protection requirements of the more sensitive class should apply. Furthermore, when assets of one class are aggregated, the set of aggregated assets may be considered more sensitive. Specifically, the value of the set of aggregated assets may be far greater than the individual assets in the set.

As a best practice, the asset owner should have the discretion to do one of the following:

• Reclassify the set of aggregated assets to the higher data-classification category, and implement the appropriate controls for that category.
• Conditionally implement particular security controls for the set of aggregated assets without reclassifying the data to a higher data-classification category.

Multiple Standards

In addition to the minimum standards imposed, additional requirements may be needed for some assets based on the implied or explicit terms of other agreements that control the protection of those assets. For example, employee agreements and privacy policies may require different confidentiality, integrity, or availability requirements.

We recommend making the asset owner accountable for understanding the direct or fiduciary responsibilities of additional standards and enforcing the appropriate level of security.

For more information about risk management at Microsoft, refer to the TechNet Security Risk Management Guide at http://www.microsoft.com/technet/security/topics/
complianceandpolicies/secrisk/default.mspx.

Platform Security

The following best practices offer comprehensive guidance for providing security for the software foundation of the IT infrastructure. Extensive account management guidelines offer prescriptive advice for setting up local and domain-based accounts. System management recommendations address antivirus software, patch management, intrusion-detection systems (IDSs), and more. In addition, guidelines for Internet Information Services (IIS) version 6.0 and Microsoft SQL Server® 2005 ensure that the Web application platform is managed according to recommended security standards.

Account Management

The following account management best practices help ensure that all accounts are created in the most secure and manageable way.

Windows Computer Accounts

Computer accounts in Windows offer a high level of control because Group Policy settings can be enforced on both the internal domain/forest environment and the Internet domain/forest environment. For Internet-facing (front-end) and internal-facing (back-end) networks, we recommend using only authorized Active Directory® directory service domains. Any Windows-based computer should be a member of the appropriate Active Directory domain and should not be configured to operate in workgroup mode.

We recommend immediately disabling or disconnecting any computer that does not meet these guidelines.

Domain User Accounts

The accurate management of accounts and user credentials is essential for security. Security organizations are responsible for creating, deleting, and modifying Domain User accounts in the managed domain/forest environment. Enforcing Domain User accounts by using Group Policy simplifies security management and enables greater control of policy enforcement.

We recommend assigning a unique account when a staff member submits an account request. In addition, we recommend using individual accounts to conduct all system administration tasks.

The following best practices apply to Domain User accounts:

• Give an account the same name as the user's corporate alias. Ensure that a user has only one standard user account in the entire domain or forest.
• Do not synchronize account credentials across domains or forests.
• Do not share user accounts or use them to run services.
• Scan accounts periodically and perform the following actions:
• Disable any account that is expired for more than 30 days. Review the account for business necessity before reactivating.
• Disable any account that is inactive for 70 days.
• Mark for deletion, and then remove, any account that is disabled for 120 days.

Domain Service Accounts

Each Domain User account should have its own Domain Service account. These accounts are application specific and not shared between applications.

We recommend making Domain Service account names descriptive of the account function and the application to which they belong. Naming conventions for these accounts should follow a consistent format.

The following best practices apply to passwords for Domain Service accounts:

• All accounts have passwords.
• All passwords meet the minimum standards for length and complexity.
• Password expiration on all accounts occurs every 70 days. In addition:
• The system automatically notifies primary and secondary account owners or delegates 14 days prior to password expiration.

We recommend not using Domain Service accounts for interactive logon or for remote access through Remote Access Service (RAS).

A best practice is to review and approve any exceptions to the organization's established guidelines. Approval should be based on the estimated risk level of the exception.

Local Accounts

The following predefined Local accounts are installed with the operating system, application, and services:

• Administrator. This account is created during installation of the operating system. The Local Administrator account should be renamed to a designated name.
• Guest. This account is created during installation of the operating system and should be disabled.
• TSINTERNETUSER. This account is created during installation of Microsoft Windows Server® 2003 Terminal Server.
• IUSER_account. This account is created during installation of IIS 6.0. It provides the mechanism that enables clients to access the Web server computer anonymously.
• IWAM_account. This account is created during installation of IIS 6.0. It is used to start out-of-the-process Web applications in IIS 6.0.
• SQLDebugger. This account is created during installation of SQL Server 2005.
• Support_388945a0. This account is created during installation of the operating system.

We recommend that the administrator does not create other Local accounts. Local accounts cannot be controlled through Active Directory. Furthermore, administrators cannot use domain credentials to control system access for these accounts.

Local Group Accounts

We recommend not adding individual Domain User accounts are to Local Group accounts. For users who require access, it is best to add them to a domain-based group and then add the domain-based group to the computer's Local Group account.

Domain Security Groups

Domain Security groups simplify the ongoing management of security for server accounts. The following best practices apply to Domain Security groups:

• For each group, assign owners who are responsible for maintaining the group.
• Add users who need administrative rights to a Domain Security group. Then, add the Domain Security group to the Local Administrator group on each computer as required. Permit access only through domain-based groups. In addition:
• Create Domain Security groups per server or group of servers to allow granular control over the domain/forest environment.
• Ensure that users who are members of the Domain Administrator group do not use the same password, or any derivation of that password, simultaneously for administrator-level accounts in multiple domains.

Local Administrator Account (RID 500)

The Local Administrator account should be used only to troubleshoot events in which the member server computer is experiencing network issues and domain authentication is not working. We recommend renaming the default Local Administrator account (relative identifier [RID] 500) to a standard specified by the organization's security group.

To rename the Local Administrator account:

1. Log on as Administrator or as a user with administrator permissions.
2. Right-click My Computer, and then click Manage.
3. In the left pane, expand the Local Users and Groups node, and then click Users.
4. In the right pane, right-click Administrator account.
5. On the shortcut menu, click Rename, type the name you want, and then press ENTER.
6. Close the Computer Management console. The new settings will apply the next time you log on to this computer.

Local Administrator Group

An organization should not support individual Domain User accounts in the Local Administrator group. An organization can include individual users as part of a domain-based group, and then add the domain-based group to the Local Administrator group.

Guest Accounts

We recommend disabling all Guest accounts and Local Guest accounts in managed domains.

To disable a Guest account:

• Log on as Administrator or as a user with administrator permissions.
• Right-click My Computer, and then click Manage.
• In the left pane, expand the Local Users and Groups node, and then click Users.
• In the right pane, double-click Guest account.
• On the General tab, select the Account is disabled check box, and then click OK.
• Close the Computer Management console. The new settings will apply the next time you log on to this computer.

Password Standards

Implementation of strong passwords is a critical component of helping to protect the corporate network from unauthorized access. Poorly chosen passwords are often guessed, resulting in a security breach that can compromise the entire network.

We recommend applying the following standards to all user-chosen passwords. Passwords should be at least eight characters long and contain the following elements:

• Uppercase or lowercase letters (A, B, C, Z; a, b, c, z)
• Numbers (0, 1, 2, 3, 9)
• Symbols, which are all characters not defined as letters or numbers (~, !, @, #, $, and so on)

Passwords should not contain any recognizable part of the user's name; however, this is not an enforceable policy. Furthermore, passwords should differ significantly from prior passwords. Specifically, users should not use iterative passwords, which contain the same basic content as previous passwords, but with only a part of the content changed. 

Strong passwords and expiration policies can be enforced through Group Policy and Active Directory.

Password Changes and Storage

All accounts (including service accounts, IIS 6.0 anonymous user accounts, and administrator accounts) should require password changes at least once every 70 days. The following best practices apply to password changes, storage, and transmission:

• Avoid storing or writing passwords in readable form in any of the following locations:
• Batch files
• Automatic logon scripts
• Software macros
• Terminal function keys
• Computers without access control
• Do not store passwords in locations to which unauthorized persons might gain access.
• Do not share passwords with anyone other than the authorized users.
• Change passwords immediately if unauthorized users obtain them.
• Do not transmit user names and passwords together in an unencrypted format.
• Store user names and passwords in an encrypted format, and restrict access to the user name and password files.
• Do not send passwords in an unencrypted format through e-mail.

Password Management

It is important to designate a password manager to maintain and store the Local Administrator password for each computer. In addition, we recommend the following best practices:

• Enable Group Policy settings to verify password complexity and history for all accounts. Password history should include 24 prior passwords.
• Review nondefault password filters to help ensure security compliance.
• Store passwords in a security-enhanced location, such as a database that has strict access restrictions. This action helps ensure that only authorized individuals can access password information.

For more information, refer to the Microsoft Everyday Productivity Education (EPE) documentation. Click the "Zip Download (16.6 MB)" link to download the EPE files, and then refer to the article "Best Practices for Creating Strong Passwords" at http://www.microsoft.com/technet/itshowcase/epe.mspx.

Systems Management

Through the deployment of antivirus software, supported software versions, and patch management, enterprise systems can maintain a high level of protection from the latest known security threats. Furthermore, Microsoft Systems Management Server (SMS) 2003 can help organizations ensure systems compliance, and Microsoft Operations Manager (MOM) 2005 provides an integrated alert infrastructure to quickly identify system problems and minimize downtime.

Antivirus Software

Viruses present a substantial security risk to the network infrastructure and to customers. Antivirus software reduces the threat of viruses that cause unauthorized access, system downtime, or the destruction of data associated with enterprise services. Antivirus software also reduces the unintentional spreading of destructive viruses to other users.

Supported Software Versions

The use of earlier applications—whether Web server, database server, operating system, or e-mail—introduces substantial security risk to the IT environment. Vendors may no longer release security updates or otherwise support earlier systems, leaving the IT environment open to a greater potential for attack. Furthermore, earlier systems might not implement the latest security technologies.

Therefore, we recommend maintaining current software versions across the environment. This means permitting only N–1 operating system and server software versions, which is one release older than the current version. This recommendation is based on the assumption that the earlier version is still supported.

Patch Management

To reduce the risk of exposure to known security exploits, it is important to implement an effective patch management strategy to control the maintenance of interim software releases into the environment. We recommend assigning an asset owner to each system. The asset owner should be responsible for obtaining and applying the latest security updates.

For systems that are physically connected to the domain/forest environment, a best practice is to apply the strictest security update policy.

Monitoring: Intrusion-Detection Systems

It is important for all organizations to protect the integrity of information assets by using monitoring to identify potential and actual attacks. We recommend covering the following classes of threats through monitoring:

• The presence of viruses, Trojan horses, and worms
• DoS attacks
• Hacker intrusions or attempted intrusions
• Unauthorized transmission or theft of intellectual property
• Accidental or purposeful information leaks
• Violations of corporate policy, such as mishandling intellectual property, violating security policies, and browsing unauthorized Web sites
• Unusual network behavior or unknown executable files

Monitoring for intrusions and security events includes the use of passive and active IDSs.

Passive Intrusion-Detection Systems

Passive IDSs involve the manual review of event log files and application log files after an attack has occurred. By inspecting log files, IT security personnel can review and reconstruct the attack method and prevent future occurrences.

Active Intrusion Detection Systems

Active intrusion detection can identify an attack as it occurs. An active IDS analyzes incoming network traffic at the application layer to identify and block known attack patterns or commands. Some detection systems can send an alert to the administrator if a severe threat occurs.

Systems Management Server 2003

A best practice is to install the SMS 2003 agent on all systems for the purposes of configuration management and compliance management. SMS 2003 delivers an integrated patch management solution to help ensure compliance for all computers running Windows operating systems.

We recommend configuring the SMS agent to check in at least once in a 24-hour period. This recommendation is based on the size of the environment, the frequency and rate of change, and the volume of events. To enable SMS 2003 reporting, administrators:

• Activate one or more site systems as a reporting point (for example, a site system that hosts the code for Report Viewer and any supplemental reports).
• Activate all reporting points as required to provide access to reports. To balance a heavy demand for reports in a larger site, administrators enable more than one reporting point and then point different groups of users to different URLs for each reporting point. Then, the users can select the reporting point needed from Report Viewer.

For more information about the reporting features of SMS 2003, refer to the Systems Management Server 2003 Operations Guide at http://www.microsoft.com/technet/
prodtechnol/sms/sms2003/opsguide/default.mspx?mfr=true.

Microsoft Operations Manager 2005

A best practice is to install the MOM agent on all systems. MOM 2005 simplifies IT management by determining the root cause of problems and facilitating quick problem resolution to minimize system downtime.

MOM alerts help administrators proactively monitor server activity for problems. MOM alerts can also be integrated with an organization's existing ticketing system.

State monitoring uses the MOM alert infrastructure to update the status of managed computers. MOM provides the status of a monitored computer at several levels, including:

• Computer group level
• Computer level
• Application level
• Application-instance level

The status of a managed computer is determined by an alert severity level that specifies how severe the problem is within the environment. In the operator console, the status is mapped to colors that are associated with the alert severity, as shown in Figure 3.

Figure 3. MOM alert severity levels

Administrators can set state roles by raising alerts through MOM. A red or yellow state alert is a traditional MOM alert that is visible to operators. A green alert is not visible to operators, and it is used to clear the state for red or yellow alerts.

We recommend using the following health indicators to set state roles:

• Red—immediate user intervention required. This is a typical high-priority MOM alert that requires user intervention for the application to start working and perform effectively.
• Yellow—the application or role is performing poorly. Components of the application might stop working without user intervention. Or, health cannot be determined for a component.
• Green—the application or role is healthy. No user action is required.

For more information about the alert functionality of MOM 2005, refer to the MOM 2005 Operations Guide at http://www.microsoft.com/technet/prodtechnol/mom/mom2005/Library/faf19f47-facd-4467-9510-e7c84c671572.mspx?mfr=true.

Operating System Configuration

Configuring session time-outs and maintaining proper audit logs are key steps for maintaining security-enhanced settings for operating systems.

Session Time-Outs

A best practice is to configure consoles with password-protected screen-saver activation after a maximum of 10 minutes of inactivity.

Audit Logs

Audit logs provide a record of past actions and events. Each server computer should create and maintain appropriate audit logs, which include the following events at the platform level:

• Failed and successful logon attempts
• Account management
• System events
• Policy changes

Other Services, Applications, and Protocols

For additional services, applications, and protocols, the following best practices apply:

• During configuration, do not enable Internet Connection Sharing (ICS), which is disabled by default.
• Do not configure Routing and Remote Access.

SMTP

IIS 6.0 includes a full-featured Simple Mail Transfer Protocol (SMTP) virtual server that administrators can use to receive and relay e-mail to other SMTP servers on a network or on the Internet. When the SMTP virtual server relays e-mail, it can forward mail that is addressed to any e-mail domain.

If Internet users can access the SMTP virtual server, unscrupulous users can forward e-mail to the SMTP virtual server, and as a result, distribute unsolicited commercial mail to several computers. This activity can have an adverse effect on internal bandwidth. It can also cause the e-mail server to be placed on a list of unauthorized servers for open mail relay. Therefore, a best practice is to prevent open relay for incoming SMTP messages.

For more information, refer to the Knowledge Base article "How To Prevent Mail Relay in the IIS SMTP Virtual Server in Windows Server 2003" at http://support.microsoft.com/kb/324281/en-us.

SQL Server 2005

This section includes best practices for computers running Microsoft SQL Server 2005. Recommendations are provided for server installation, configuration, authentication, and administration.

Installation

The following best practices apply to the SQL Server 2005 installation process:

• Make sure that any computer running SQL Server 2005 is not Internet-facing. Place each computer on a local area network (LAN) that cannot be accessed from the Internet.
• Use Microsoft Windows NT® authentication when installing software and service packs. This technique avoids the potential exposure of administrator passwords.
• Permit SQL Server 2005 and IIS 6.0 to coexist on the same computer if the following conditions exist:
• The test environment does not contain user or customer PII. PII includes but is not limited to name, address, phone number, e-mail address, or static IP address.
• There is one physical server computer running multiple virtual computers in which one computer is running SQL Server and another computer is running IIS 6.0.
• Back-end computers cannot be directly accessed from the Internet. Specifically, these computers do not have externally routable IP addresses.
• Do not install SQL Server on a domain controller computer.

File and Registry Security

The following best practices apply for enforcing strong file security:

• Store all files on NTFS file system partitions.
• Configure all files to avoid user manipulation. This includes executable files and dynamic-link libraries (DLLs).
• Enable Full Control permissions for the user account, the Local Administrator group, and the local system account. Do not set any other permissions.

To enhance security for registry keys, it is important to use NTFS permissions. It is a best practice to apply Full Control permissions to the Local Administrator group, the startup account for the MSSQLServer service, and the local system account. Use the security-enhanced registry keys shown in Table 2.

Table 2. SQL Server Security-Enhanced Registry Keys

Server Configuration

The following best practices apply to the SQL Server configuration process:

• Ensure that linked server computers do not use system administrator accounts. This recommendation prevents lower delegated accounts from escalating authorization levels by connecting to a remote server computer.
• Audit all logon attempts. To configure the audit level setting:

1. Go to Enterprise Manager, right-click the computer you want, and then click Properties.
2. In the Properties dialog box, click the Security tab.
3. Under Audit Level, select the Successful check box, and then select the Failed check box.

• Do not allow updates to system tables. To prevent the updates, verify that the sp_configure Allow Updates option is set to 0. This is the default setting.
• Maintain strict control over exploitable standard procedures and extended stored procedures. The system administrator should be the only user allowed to execute the following exploitable procedures:
• xp_cmdshell
• xp_regread
• xp_regwrite
• xp_regaddmultistring
• xp_regdeleteke
• xp_regdeletevalue
• xp_regremovemultistring
• xp_regenumvalues
• xp_regenumkeys

The stored procedures in Table 3 pose a potential threat and should be restricted to system administrators.

Table 3. Server Configuration: High-Risk Stored Procedures

• Disable remote access if it is not required. The Remote Access option controls the execution of stored procedures from remote server computers running SQL Server. Options for setting remote access are as follows:
• Set the Remote Access option to 1 to allow the execution of stored procedures from remote server computers. This is the default setting.
• Set the Remote Access option to 0 to prevent the execution of stored procedures from a remote server computer. Use this option unless there is an application dependency on remote procedure calls (RPCs).

• In the Network Utility setting, set the Network Protocol Library to TCP/IP. TCP/IP should be first priority in this setting because it provides maximum security.
• Change the default port setting to a fixed port number. The default port setting for SQL Server is TCP port 1433.

Kerberos and delegation require a Service Principal Name (SPN), part of which is the port number. Delegation provides the ability to bridge credentials across multiple computers without having to store passwords. Assigning a fixed port number helps ensure that Kerberos and delegation can continue to work if the service stops and restarts.

Authentication

We recommend using Windows Server 2003 Network Service accounts as the preferred authentication method for applications that are connecting to a computer running SQL Server. There are several advantages to using Windows-based authentication instead of SQL Server® based authentication, as described in the following sections.

Windows Server 2003 Network Service Accounts

Windows Server 2003 Network Service accounts are similar to authenticated user accounts. Each Network Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard the environment if services or processes are compromised. Services that are part of the Network Service account can access network resources by using the credentials of the computer account.

Advantages of Windows-Based Authentication

There are several advantages to using Windows-based authentication instead of SQL Server–based authentication, including:

• Security is easier to manage through a single, Windows-based security model instead of a separate, SQL Server–based security model.
• Passwords and user names are not embedded in connection strings. There is no need to store passwords on IIS server computers.
• User names and passwords are not transmitted over the network in clear text.
• Logon security is achieved through password expiration periods, minimum lengths, and account lockout after multiple invalid logon attempts. Maintaining this level of security can be enforced through a Group Policy setting from a central location, which makes it easier to comply with corporate password policies.

Kerberos and NTLM are the preferred security protocols. In addition, Kerberos allows for delegation. This is possible only with Windows-based logons.

Domain User Accounts and SQL Server Roles

We recommend the following best practice for Domain User accounts and SQL Server roles: Instead of creating additional local users on the server computer, add the Domain User accounts to Local Group accounts, and then assign Local Group access to the appropriate SQL Server roles.

Account Administration

The following best practices apply to administering accounts for SQL Server:

• Restrict the number of system administrators for Windows NT and SQL Server. Create unique, domain-based accounts for administrative tasks related to platform security. These accounts may vary depending on the size of the organization, but some examples include:
• Platform security.
• Hardware and operating system support.
• Tape backup support.
• Monitoring.
• Security.
• Database Administrator support.

Special consideration should be granted to system engineers who diagnose site problems that are potentially related to the back-end database. As such, System Engineer accounts can connect to a computer running SQL Server to perform basic troubleshooting tasks. It is also possible to grant read-only access to system engineers.

We recommend creating a separate role for system engineers and adding all system engineers to that role.

• Ensure that the Service account is not a Domain Administrator account or Local Administrator account. A Domain User account with the following permissions allows a Service account to run in non-administrator mode:
• Act as part of the operating system = SeTcbPrivilege
• Bypass traverse checking = SeChangeNotify
• Increase quotas = SeIncreaseQuotaPrivilege
• Lock pages in memory = SeLockMemory
• Log on as a batch job = SeBatchLogonRight
• Log on as a service = SeServiceLogonRight
• Replace a process-level token = SeAssignPrimaryTokenPrivilege
The startup accounts for the MSSQLServer and SQLServerAgent services are added to the SQL Server System Administrator role.
• Grant the Domain\NT account user a logon to SQL Server.
• Disable the Windows Guest User account.
• Ensure that the SQL Guest User account is not present in any database other than Master and Tempdb.
• Do not use the Public role for security administration and do not grant any administrative rights to that role.

For information about clusters, full-text indexes, and other special configurations, refer to the relevant Microsoft Knowledge Base articles at http://support.microsoft.com/.

Application and Database Configuration

The following best practices apply to the configuration of SQL Server applications and databases:

• Ensure that the system administrator owns all databases. To change the database owner, use the sp_changeDBOwner stored procedure.
• Ensure that the system administrator owns all SQLAgent jobs.
• Do not require Database Administrator permissions for applications.
• Do not place system administrator dependencies on applications.
• Use only Windows-based authentication when creating Data Transformation Services (DTS) packages.
• Store DTS packages on a security-enhanced NTFS file structure with proper permissions.
• Do not assign permissions to base tables. Managing data access through stored procedures offers many advantages, including:
• Stored procedures can be individually protected within the database. A client can have permissions to execute a stored procedure without having access to the underlying tables.
• Stored procedures result in easier maintenance. Modifying a stored procedure is easier than changing a hard-coded Structured Query Language (SQL) statement within a deployed component.
• Stored procedures add an extra level of abstraction from the underlying database schema because the client is isolated from the implementation details.
• Stored procedures usually result in improved performance because the database can optimize the procedure's data access plan and cache it for subsequent reuse.
• Stored procedures can reduce network traffic. The Web server computer can request data from the SQL Server computer through a single stored procedure instead of running multiple dynamic queries.
• Validate user input for protection against SQL Server injection attacks. If the application allows free-form user input, check this data for embedded SQL commands that might be used to attack the SQL Server back end.
• Carefully administer cross-database ownership chaining. It is essential that owners of each of the databases, and the members of the db_ddladmin and the db_owner role in each of these databases, are trusted individuals. These roles come with high permissions, including the ability to create objects in another users' schema. Minimize membership in these roles and restrict membership to trusted parties.
• If the environment will support distributed queries, use linked server computers instead of remote server computers. To configure linked server accounts, identify the set of logons needed for this functionality and allow access to only these logons. Do not specify a blanket linked server account for all logons unless it is absolutely necessary.

• Do not propagate SQL Server–based errors back to the application or the end user. Hackers typically build attacks in stages, relying on SQL Server error messages to reveal information about the application and schema. The application may conceal the error by using application-specific messages.
• If the application must use SQL Server logons, consider using strong encryption techniques and storing the encrypted credentials in a security-enhanced manner in the middle tier. To strengthen security, turn on Secure Sockets Layer (SSL) when connecting to SQL Server.

Internet Information Services 6.0

IIS 6.0 is a powerful Web server that provides a highly reliable, manageable, and scalable Web application infrastructure for all versions of Windows Server 2003.

This section includes detailed recommendations for configuring and maintaining security for Web sites and applications in IIS 6.0.

Installation

IIS should be installed on a dedicated server computer. The IIS Web services root store directory should be installed on a separate partition from the operating system.

To install IIS 6.0, complete the following steps:

1. Install Windows Server 2003 by using the default configuration settings.
2. Open Control Panel, double-click Add or Remove Programs, and then install IIS 6.0 by using the default settings.

Security Configuration for Web Sites and Applications

There are several best practices for providing security for Web sites and applications in IIS 6.0. These best practices, illustrated in Figure 4 as a process, help ensure that only authorized users can access sensitive enterprise information as appropriate.

Figure 4. The process for providing security for a Web site

Reduce the Attack Surface of the Web Server

To reduce the attack surface of the Web server, we recommend enabling only the essential components for each of the following:

• Windows Server 2003 components
• IIS components and services
• Web service extensions
• Multipurpose Internet Mail Extensions (MIME) types

Furthermore, configuring additional Windows Server 2003 security settings may be necessary if the following conditions apply:

• Web sites and applications are available to users on the Internet.
• Web sites and applications contain confidential information.

The Microsoft IIS Lockdown Tool version 2.1 can help reduce the attack surface available to attackers by turning off unnecessary features. For more information, refer to the TechNet documentation and download instructions for using the IIS Lockdown Tool at http://www.microsoft.com/technet/security/tools/locktool.mspx.

Enable Web Service Extensions

The default configuration settings of IIS 6.0 will suffice only for static Web content. Web sites and applications that include dynamic content need Web service extensions.

Web service extensions include Active Server Pages (ASP), Microsoft ASP.NET, Common Gateway Interface (CGI) scripting, Microsoft FrontPage® 2002 Server Extensions, and Web Distributed Authoring and Versioning (WebDAV). Administrators can enable these features by using the Web Service Extensions node in IIS Manager.

Table 4 lists the predefined Web service extensions.

Table 4. Predefined Web Service Extensions