SMS 2003 Security Best Practices
Use this checklist to verify that your environment conforms with the recommended security best practices documented in Scenarios and Procedures for SMS 2003: Security.
Security Fundamentals
□ |
Apply principals of risk management to threats and vulnerabilities. |
□ |
Physically secure all SMS servers. |
□ |
Design for defense in depth. |
□ |
Take measures to protect against rogue administrators. |
□ |
Assign the least permissions possible. |
□ |
Create a plan for role separation. |
□ |
Create a secure baseline for all systems. |
□ |
Install all site systems on Microsoft® Windows® Server 2003. |
□ |
Verify that all clients are running Microsoft Windows XP. |
□ |
Use the Windows security templates together with the SMS security templates. |
□ |
Use NTFS on all client and server partitions. |
□ |
Design a plan to apply security updates as needed. |
□ |
Design a plan to audit for changes to the baseline. |
□ |
Use strong passwords for all SMS administrators and SMS administrator created accounts. |
Securing SMS
□ |
Install with or upgraded to SMS advanced security. |
□ |
Upgrade all sites and all clients to SMS 2003 SP1. |
□ |
Install only Advanced Clients. |
□ |
Deploy SMS in an Active Directory® domain. |
□ |
Extend the Active Directory schema. |
□ |
Manually create the System Management container in Active Directory and assigned SMS full control to that container only. |
□ |
Configure Advanced Clients to use Active Directory Only Mode. |
Creating a Secure Hierarchy
□ |
Verify that no SMS sites span Active Directory forests. |
□ |
Use the minimum practical number of SMS sites. |
□ |
Install SMS on a member server. |
□ |
Use the minimum practical number of management points. |
□ |
For advanced security only: Do not remotely install or uninstall secondary sites by using the Create Secondary Site Wizard in the SMS Administrator console. |
□ |
Do not install other applications that use the LocalSystem account on the site server. |
□ |
Create a service continuity plan for SMS. |
□ |
Design a fault tolerant site. |
□ |
Create a backup and recovery plan. |
□ |
Test the backup and recovery plan. |
□ |
Secure the backup media. |
Securing SMS Communications
□ |
Disable unsigned communications between sites, even in a single site hierarchy. |
□ |
Require secure key exchange. |
□ |
Implement IPSec to encrypt communications between site systems and the site server. |
□ |
Install the Trusted Root Key during Advanced Client Installation (only necessary if you have not extended the schema |
□ |
Configure client and perimeter firewalls to permit required SMS traffic. |
□ |
Consider Configuring the Advanced Client to use a non-default HTTP port. |
□ |
Configure all sites and Advanced Clients to use the same port. |
□ |
Enable signing and encryption of Advanced Client data. |
□ |
Enable client signing on all sites to avoid rejecting data from clients changing site assignments. |
□ |
If you have roaming clients, wait until all sites are upgraded to SMS SP1 before enabling client signing and encryption and then enable across all sites. |
Securing SMS Site Systems
□ |
Implement role separation on site systems. |
□ |
Do not remove the Admin$ share on site systems. |
□ |
(Assume that because all site servers are Windows Server 2003, all site systems that require IIS are using IIS 6.0.) |
□ |
Install only the minimum required IIS components for each site system role. |
□ |
Verify that no site systems that require IIS are installed on site servers. |
□ |
Complete the SMS 2003 IIS Hardening Checklist. |
□ |
Restrict SMS Administrator console on site server to Windows administrators. |
□ |
Create secure SMS Administrator consoles for non-Windows administrators. |
□ |
Add required users to SMS Admins group, or created alternate groups and assigned required WMI permissions. |
□ |
Create a policy to require SMS Administrators to use Run As when launching the SMS Administrator console from a remote workstation. |
□ |
Complete the SMS 2003 SQL Server Hardening list. |
□ |
Install SMS and Microsoft SQL Server™ on the same computer. |
□ |
Use a dedicated computer running SQL Server for each SMS site. |
□ |
Configure SQL Server to use Windows Authentication. |
□ |
Configure SQL Server to run with a domain user account. |
□ |
If you are using advanced security, manually create the fully qualified domain name (FQDN) and the NetBIOS SQL Server service principal names (SPNs). |
□ |
Enable HTTPS Access for Reporting Points. |
□ |
Assuming you do not have Legacy Clients, remove Everyone group from the CAP shared folder permissions and replaced with Administrators group. |
Securing SMS Features
□ |
Restrict queries and reports to authorized viewers. |
□ |
Add appropriate users to Reporting Users group. |
□ |
Disable Remote Tools (Assuming all of your clients are capable of using Remote Assistance instead.) |
□ |
Create a secure collection and subcollection strategy. |
□ |
Secure all package access permissions. |
□ |
Secure the package source files. |
□ |
For advanced security only: Store package source files on a computer running Windows 2000 or later in an Active Directory domain. |
□ |
Verify that no restricted packages are set to be downloaded and executed. |
□ |
Disable IDMIF and NOIDMIF collection in high security environments. |
□ |
Ensure that file collection does not collect critical files or sensitive information. |
Maintaining a Secure SMS Environment
□ |
Create security policies for SMS. |
□ |
Configure a secure test lab for SMS. |
□ |
Create a plan to review SMS configuration settings. |
□ |
Create a plan to review audit logs. |
□ |
Create a plan to monitor SMS connections. |
□ |
Create a plan to monitor SMS operations. |
□ |
Create a plan to test SMS security periodically. |
□ |
Develop an incident response plan. |
□ |
Secure an internal SMS documentation. |
□ |
Create a plan to do ongoing threat, vulnerability, and risk analysis. |
□ |
Train the organization about security best practices. |