Security and Delegation in Configuration Manager 2007 : Securing the Configuration Manager Infrastructure (part 1) - Securing Site Systems

You should consider your organization’s security requirements throughout the life cycle of your ConfigMgr implementation. During the hierarchy design phase, keep the following considerations in mind:

• Active Directory considerations— Although it is possible for a ConfigMgr site to span more than one AD forest, doing this might compromise your AD security design. The forest is a security boundary in AD. Allowing a site server in one forest to configure site systems or administer clients in a second forest could violate the autonomy of the forest in which the managed systems reside. You can also have a child primary site report to a parent site in a different forest. Again, this might compromise the security boundary between the forests. By design, administration flows from the parent site to the child site. There are also attack vectors through which a child site could constitute a threat to other sites in the hierarchy. The strongest protection for the integrity of your AD forests is to isolate each ConfigMgr hierarchy within a single forest. You should weigh this decision against the possible administrative advantages of using a single ConfigMgr hierarchy to manage multiple forests.

• Configuration Manager site selection— In general, the fewer sites you have, the easier it is to maintain site security. Additional sites increase the number of site servers, site databases for primary sites, and intersite communications links you need to administer and secure. In some cases, however, you might consider using dedicated sites for specific security needs. A dedicated site might allow you to restrict administrative access to a smaller group and configure site-wide settings appropriately for the security requirements of the target environment. As an example, if you use remote tools elsewhere in your organization, you can choose not to enable the remote tools client agent in a specific site, protecting those systems from the threat of misuse of remote tools functionality.

• Site system role assignment— Microsoft recommends using role separation to reduce server attack surface and avoid creating a single point of failure. It is important to consider both the advantages and disadvantages of this approach from a security standpoint. Reducing the attack surface of your site systems is an important security consideration. Although you might reduce the attack surface of each site system by using dedicated servers with one site role per server, distributing site roles across a large number of systems might actually increase the overall attack surface of your site. Each system, account, and network communications path you add represents a potential point of attack that can lead to the compromise of the entire site.

  Carefully consider the administrative and physical resources you have available to support the security of distributed site roles. It is most important to move client-facing roles, such as the management point and distribution point, off the site server. You can greatly reduce the risk of a network attack by restricting client access to only those server roles that require it. The site server and site database server are the most important roles in your site, and allowing clients to establish a network connection to these systems is a risk you need to consider eliminating.

  Installing Internet Information Services (IIS) on a server greatly increases the server’s attack surface. For that reason, you should generally separate server roles requiring IIS from those that do not.You need to also separate the Fallback Status Point (FSP) server role from all other system roles.

  The FSP must be configured to accept unauthenticated client data. Accepting unauthenticated client data presents a risk you should avoid exposing other site roles to. One exception to Microsoft’s recommendations to separate server roles is the site database server. The best security practice is to locate the site database on the site server to simplify security administration. Perhaps the most important security consideration for assigning system roles is to avoid using systems that host other applications as site systems, especially those with applications based on IIS or SQL Server. Poorly written or vulnerable web and database applications are favorite targets of attackers and could be exploited to gain control of a site system. Placing a distribution point on a server that provides file and print services is a much lower risk.

• Server placement— All site systems should be deployed in locations that are as secure as possible in terms of physical and network access. An attacker with physical access to a site system or administrative workstation could compromise your system—for example, the attacker could install a hardware device such as a keystroke logger or boot the system to an insecure operating system. You might want to consult with the team responsible for physical security to help determine the most secure locations consistent with the functional requirements of each system. Network traffic should be restricted to that necessary for ConfigMgr operations and basic server functions. 

Effective management and monitoring can greatly enhance the security of your environment. Potential compromise of a management application, however, is a threat you cannot afford to ignore. After all, why should an attacker go to the trouble of deploying and managing malware agents in your environment if he can just use the highly capable agents you have deployed for him?

Many organizations deploy management applications in a separate, highly secure network zone to protect them from network attacks. Each of these scenarios involves placing sites or systems in a perimeter network to provide services to Internet clients. You can apply the same principles to your hierarchy by placing your highest value sites and systems in more secure zones within your internal network. For example, you can adapt the model for having a site span the internal network and the perimeter network to create a hierarchy that spans your secure management network zone and the zone in which your application servers typically reside. In this instance, you would place the site server and site database server in the secure management zone. In the same manner, you can place a central site or a site with high-security requirements in a higher security network zone and configure communications with less secure sites, similar to the models for dedicated sites for Internet clients. In each case, if administrative workstations reside in the less secure network zones, they should use a Virtual Private Network (VPN) to connect to systems in the higher security zone.

Securing Site Systems

Consider your ConfigMgr site server and site systems as among the most security-sensitive assets in your organization, on a par with domain controllers. All basic controls applicable to such systems should be applied to your site systems.

Physical Security and Hardware Selection

Choose the most secure possible location and most secure hardware available for your site systems. Site servers and site database servers should be located in secure data centers. You need to balance security concerns with your other requirements as you consider the placement of client-facing systems such as distribution points. If possible, ensure that cameras are oriented to monitor access to server hardware, while protecting keyboards and monitors from being viewed through those cameras. Server-class hardware often provides functionality such as alarms that alert when detecting an open chassis or modifications to hardware. Newer hardware implements protection features such as processor-based data execution prevention (DEP). Choose hardware with the maximum reliability and redundancy for systems with high availability requirements.

System Software Security

Choose the most recent version of Microsoft Windows consistent with your system requirements, and keep up to date on all service packs and security patches. Evolving security awareness and technology is reflected in the design of modern operating systems, and each version of Windows has contained numerous security enhancements over its predecessor. Often the accumulation of small enhancements can make as much or more difference as the more highly publicized features. In addition to OS patches, you should keep system components such as the Basic Input Output System (BIOS) and firmware up to date and regularly update all drivers and applications installed on your systems.

A number of resources are available that provide current information on software and hardware vulnerabilities, threats, and countermeasures. The United States Computer Emergency Response Team (US-CERT) site, http://www.us-cert.gov/cas/alldocs.html, is a great place to start. US-CERT provides security bulletins, alerts, and a wide range of security-related information. Many software and security vendors provide additional vulnerability alerts and threat information services. Microsoft provides security bulletins related to Microsoft software, guides for securing Microsoft Windows platforms, and additional security information at http://www.microsoft.com/security/default.mspx.

Attack Surface Reduction and Server Hardening

One of the most basic and important principles for securing any system is to reduce the number of potential vulnerabilities by eliminating unnecessary services, accounts, applications, network shares, open network ports, and so on. The key to reducing the attack surface without reducing required functionality is determining those features unnecessary on a particular system so that you can turn them off. In addition to reducing the attack surface of your servers, you can “harden” the server by modifying default settings such as requiring the use of more secure network protocols and limiting access to certain Graphical User Interface (GUI) features. Microsoft provides a set of tools that greatly simplifies attack surface reduction and server hardening for the Windows operating system and for ConfigMgr and SQL Server systems:

• Windows Security Configuration Wizard (SCW)

• SQL Server Surface Area Configuration

• Configuration Manager 2007 Desired Configuration Management

Windows Server 2003 Service Pack 1 introduced the Security Configuration Wizard for Windows Server 2003. You can install the SCW through Control Panel -> Add/Remove Programs -> Windows Components. The SCW is an attack surface reduction tool that helps you identify and disable unnecessary ports and services and harden the network stack. On Windows Server 2008 systems, the SCW is installed automatically with updated functionality to configure IPv6 settings. Although you can use the Windows Server 2008 Server Manager to configure server roles, SCW provides more advanced settings, including granular control over security settings.

The Security Configuration Wizard Template for Configuration Manager 2007, included in the Microsoft System Center Configuration Manager 2007 (ConfigMgr) Toolkit, provides SCW templates for the following ConfigMgr server roles:

• Primary and secondary site servers

• Server locator points

• Management points

• Reporting points

• Fallback status points

• State migration points

• PXE service points

• Software update points

• System health validator points

To apply the appropriate security settings to a site system role, run SCW on the appropriate system after you have installed and configured all appropriate ConfigMgr roles. To apply security policies based on the template, perform the following steps:

1.	Download and run ConfigMgr2007ToolKit.exe from http://go.microsoft.com/fwlink/?LinkId=93071; then install the CCM tools (CcmTools.msi).
2.	Copy the ConfigMgr07.xml template file from %ProgramFiles%\ConfigMgr 2007 Toolkit\CCM Tools\SCW Template to the security\msscw\kbs folder under your Windows folder.
3.	Enter the following command at the Windows command prompt to unregister the SMS 2003 template: scwcmd register /kbname:SMS /d
4.	Enter the following command at the command prompt to register the ConfigMgr 2007 template: scwcmd register /kbname:CM07 /kbfile:%windir%\security\msscw\kbs\ConfigMgr07.xml
5.	Launch the Security Configuration Wizard from the Administrative Tools program group and click Next on the Welcome page.
6.	Figure 1 displays the SCW Configuration Action page. Select Create a new security policy and click Next. Note that you can also use the tool to edit or apply existing policies or roll back a security policy. Figure 1. The Security Configuration Wizard Configuration Action page with the Create a new security policy option selected
7.	Enter your server name on the Select Server page and click Next. The wizard now processes the configuration database. When processing completes, click Next and then Next again to begin Role-Based Service Configuration. Figure 2 displays the Select Server Roles page. Verify the appropriate roles are selected, and then click Next. Figure 2. The Security Configuration Wizard Select Server Roles page with the detected roles on a primary site server
8.	The next three pages ask you to select client features, administrative and other options, and additional services. On each of these pages, verify that the appropriate features are selected, and then click Next. On the Handling Unspecified Services page, you generally accept the default option to leave the services unchanged and click Next. Although choosing the Disable the service option for handing unspecified services provides slightly better security, you need to rerun the wizard each time you apply the policy to a new server or install new software. Note: About Administrative and Other Options Enable the appropriate options on the Administrative and Other Options page of the SCW if you plan any of the following activities: Running the Configuration Manager 2007 console on the server Using the server as a Configuration Manager 2007 distribution point Supporting Background Intelligent Transfer Service (BITS) Connecting to the server using Configuration Manager 2007 Remote Control Implementing remote WMI (required for remote ConfigMgr administration) Remotely administering IIS on the server
9.	Figure 3 shows the Confirm Service Changes page. Review the list of proposed changes and navigate back to the previous pages if you need to change any of the selections. If you are satisfied with the proposed changes, click Next. Figure 3. The Security Configuration Wizard Confirm Service Changes page with proposed changes for the primary site server
10.	On the Network Security page, click Next to review and modify the list of open ports. Figure 4 shows the Open Ports and Approve Applications page. When you complete your port selection, click Next and then Next again to confirm your choices. Figure 4. The Security Configuration Wizard Open Ports and Approve Applications page showing proposed changes for the primary site server
11.	On the Network Security page, click Next to launch the Registry settings section of the wizard. The Registry settings need to be consistent with your network environment. The available registry settings govern Server Message Block (SMB) Security Signatures Lightweight Directory Access Protocol (LDAP) Signing Outbound and Inbound Authentication Methods You should disable connections from computers that require LAN Manager authentication and computers not configured to use NTLMv2 (NT LAN Manager version 2) authentication unless these are required in your environment. If you enforce the signing and authentication settings in the group policy, you can choose to skip this section of the wizard.
12.	The Audit Policy section of the wizard suggests changes to the local Windows audit policy. The Internet Information Services section restricts IIS features and removes unnecessary virtual directories such as help and samples. After you complete (or skip) each section of the wizard, you can save your policy selections as an .xml file that you can apply to the local server or other servers through the SCW. You also have an option to apply the policy setting locally now, which generally requires a reboot.

You can also apply the policies through AD group policy using the scwcmd /configure command line option for the Windows Server 2003 SCW or the scwcmd /transform option for Windows Server 2008. This section has only discussed a fraction of what you can do with the Security Configuration Wizard.

• For more information about the SCW for Windows Server 2003, see http://www.microsoft.com/windowsserver2003/technologies/security/configwiz/default.mspx.

• For additional information about the SCW for Windows Server 2008, see http://technet.microsoft.com/en-us/library/cc771492.aspx.

Configuration Manager 2007 DCM can help you to reduce the attack surface and identify other configuration issues on site systems. DCM provides additional monitoring and reporting capabilities that help you maintain the configuration baseline. Microsoft provides two DCM configuration packs (CPs) for specific ConfigMgr site system roles:

• The System Center Configuration Manager 2007 Vulnerability Assessment CP provides baselines to help you identify vulnerabilities in you Windows, IIS, and SQL Server configurations.

• The System Center Configuration Manager 2007 CP provides a baseline for management points, distribution points, and software update points.

You can download the configuration packs from http://technet.microsoft.com/en-us/configmgr/cc462788.aspx. 

You can install the SQL Server Surface Area Configuration tool from the SQL Server 2005 Setup program. For SQL Server 2008 environments, you can import the tool into SQL Server Management Studio from %ProgramFiles%\Microsoft SQL Server\100\Tools\Policies\Surface Area Configuration for Database Engine 2008 Features.xml. Using The Surface Area Configuration tool allows you to turn off unnecessary SQL Server features and functionality. 

Security Software

You should run antivirus software on all systems in your environment and update virus signatures regularly. Relatively little hacker activity today is carried out by interactively accessing systems and manually exploiting system vulnerabilities. Instead, hackers deploy malware with sophisticated capabilities to detect and exploit known vulnerabilities. Traditional antivirus software compares files and processes against a database of signatures used to recognize known malware. Signature-based malware detection is reasonably effective against widely deployed viruses, spyware, and other malware and is an essential part of an antimalware strategy. Some antivirus programs also use behavior-based detection that responds to suspicious activity such as a program opening a network port. Software firewalls, including the Windows firewall, provide protection from network-based attacks. In high-security environments, you might choose to use specialized host intrusion prevention (HIP) software to provide an additional layer of protection by detecting and blocking a more extensive range of suspicious process activity. File Integrity Monitoring (FIM) software protects critical files from alteration. You might consider using FIM to alert you if key ConfigMgr files such as the service executables, site control file, and client source files are altered.

Security programs are by their nature intrusive. They often consume significant amounts of system resources and sometimes block legitimate activity. You should test and adjust your security software settings in your proof of concept environment and continue to monitor the impact of security software in your pilot and production environments. To improve system performance and availability, it is sometimes advisable to exclude certain directories from virus scanning. Exclusions are typically applied to files frequently accessed or generally locked during normal operations that are not common vectors for introducing malware into the environment, such as log files or the Windows paging file. Any scanning exclusions you create can introduce a potential weakness in your protection framework that could be exploited by malware. You should follow your organization’s risk policy when considering any exclusions or exceptions in your controls framework. Microsoft recommends certain exclusions for all Windows systems as described in http://support.microsoft.com/kb/822158. Here are some additional virus scanning exclusions you might want to consider for ConfigMgr site systems:

• All files of type *.log.

• The Windows paging file, pagefile.sys.

• Any mapped network drives or Storage Area Network (SAN) storage mounted as drives. You can use antivirus software specifically designed for SAN environments to scan SAN storage.

• All files under the <ConfigMgr Install Path>\Inboxes folder on ConfigMgr site servers, other than those in the clifiles.src sub folder.

• All files under the SMS_CCM\ServiceData folder on management points.

• The IIS Temporary Compressed Files and inetsrv folders on servers with IIS installed.

• The SQL Server database, backup and log files on the site database server (*.mdf, *.ldf, *.ndf, *.bak, *.trn). If SQL Server is installed on a clustered SQL Server instance, you might also need to exclude the cluster folder and the quorum drive.

• The backup folder on the site server.

• The WSUS and MSSQL$WSUS folders on your SUP.

You should also consider any vendor-recommended exclusions for installed components such as backup software or host-based adapters (HBAs). Keep in mind, however, that vendors are typically more concerned with the functioning of their products than the security of your systems and might publish overly broad recommendations for excluding their software.

Review the logs created by your security software for malware detection and blocked actions. If you find false positive detections, evaluate the impact on system functionality and modify security software settings as required. If you suspect that on-access virus scanning is affecting system or application stability or performance, you can use Process Monitor to determine what files your virus scanner is opening. If you see files that are frequently scanned, you might consider them for exclusions. Some enterprise antivirus applications allow you to apply on-access scanning exclusions to files opened by specific processes you designate as low risk or low priority. This is a much safer practice than allowing all processes to read from or write to the excluded files without scanning. If your antivirus software supports this, you should designate the ConfigMgr processes as low risk and apply exclusions for specific site roles only to low risk processes. Here are some processes you might want to designate as low risk:

• ccmexec.exe (on management points)

• sitecomp.exe

• smsexec.exe

• smsrph.exe (on reporting points)

• smswriter.exe

• sqlservr.exe (on site database servers)

• sqlwriter.exe (on site database servers)

With any exclusion, you should be sure to scan all downloaded files for malware before copying them to locations where they are excluded from scanning.

Securing the Site Database

The site database server is the heart of your ConfigMgr site. Its security is at least as important as that of the site server. You should use a dedicated SQL Server for each primary site or locate the database on the site server itself.

Use a low privilege domain account for the SQL Server startup account, rather than running SQL Server under Local System. When you run SQL Server in a low privilege account context, you need to manually register the Service Principal Name (SPN) for the server in AD. Clients use the SPN to locate SQL services. 

Configure SQL Server to use Windows authentication only and enable logging for at least failed logon attempts. Be sure to drop the sample databases. You can run the SQL Server Surface Area Configuration from the SQL Server -> Configuration Tools program group to eliminate unnecessary features. Be sure to test any changes you make with the SQL Server Surface Area Configuration in your Proof of Concept environment before applying them in production.