Maintaining a Secure SMS Environment

  • Article

Putting Systems Management Server (SMS) security in place is critical to maximize the integrity of your computer infrastructure, and putting SMS security in place properly is crucial to the successful operation of SMS. In order to maintain SMS security and react to security issues when they arise, you must be vigilant.

You must routinely review your security (and enhance it where appropriate), and take advantage of new security options when they become available.

Create Security Policies and Adhere to Them

Documented policies and procedures are beneficial for any system, and they are mandatory for SMS security. Security policies are statements about standards and behavior. Security procedures are detailed instructions of how each organization implements the security policies. For example, your SMS security policy might state when it is acceptable to use Remote Tools. Your security procedures would include the steps for verifying that remote tool status messages are being collected, how frequently the reports should be reviewed, and what to do if a violation is suspected.

By documenting your company’s SMS security policies and the procedures to be used, all relevant staff and managers can have an opportunity to review those policies and procedures in a systematic way and ensure that your SMS sites remain secure.

In order to be effective, policies must be reviewed periodically and revised as needed.

For more information, see the Policies and Procedures Index (https://go.microsoft.com/fwlink/?LinkId=50941) in the TechNet Security Center.

Use a Test Lab to Test Future Change Configurations for Security Concerns

Do not install SMS on any of your production servers before you install it and work with it in your test lab. Installing SMS in a production environment without first testing it on an isolated network can cause undesirable and potentially damaging results.

For the test results to be useful, ensure that the lab environment reflects your production environment as closely as possible. Continually update your test lab environment as your production environment changes.

Before introducing new security measures in your production environment, test them in your lab. Verify that you can implement the security procedures without introducing new vulnerabilities in your network. Verify that the new measures do not interfere with mission critical business activity. For example, implementing IPsec is an important security measure for data transmission security, but implementing it incorrectly could totally stop all network communications.

For more information about setting up a test lab, see the “Establish Test Lab Environment” section in Scenarios and Procedures for SMS 2003: Planning and Deployment on Microsoft TechNet (https://go.microsoft.com/fwlink/?linkid=29105).

Secure your test lab

Test labs require as much security as the production environment. Unsecured test labs could allow attackers to study vulnerabilities that could be reproduced in the production environment. Often password security is lax in a lab environment. Passwords might be taped to lab computers or changed very infrequently so as not to interfere with testing. An attacker might gain access to the scripts and packages that are developed in the lab and introduce vulnerabilities that could be exploited in production.

Physically secure the lab environment. Enforce the same password standards for the lab as you do for your production environment. Audit the lab environment for signs of intrusion.

Test Your Backup and Recovery Procedures

Backup procedures are worthless unless they are periodically tested. SMS backup and recovery are complex procedures and should be routinely tested. For more information about developing and implementing your backup and recovery procedures, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Backup, Recovery and Maintenance (https://go.microsoft.com/fwlink/?LinkId=31434).

Review SMS Configuration Settings

Good change and configuration management facilitates good security. Ideally no change should happen in production without proper planning, testing, authorization, and change tracking. Even if you have the best possible change controls, you should still periodically review your SMS configuration to verify that there have not been any unauthorized changes.

Review Audit Logs

You can use Microsoft Operations Manager (MOM) in conjunction with the SMS 2003 Management Pack to consolidate and alert you to significant event log activity.

Monitor the Windows event logs

You can monitor operating system security by using the auditing facility of the operating system. After you have enabled security auditing, watch the security event log for SMS-related events. Check closely for any failures that involve SMS accounts or resources.

Back up the Windows event logs

Windows event logs can get full, and by default, new items will start to overwrite older items. To diagnose problems, and for other reasons, it might be necessary to refer to an older event log. It is recommended that you back up Windows event logs, and store the backups in a safe and accessible location. If necessary, increase default log file size to accommodate larger amounts of data.

Monitor SMS connections

You can watch connections to SMS servers by using the Computer Management administrative tool on servers running Windows 2000 or Windows Server 2003. SMS communicates primarily through shared folders, so watching this kind of activity is quite useful for SMS monitoring.

Monitor SMS operations

You should also watch SMS operational activities to ensure that only authorized activities are occurring. For example, watch for the creation of large or suspicious collections, the creation of advertisements, the addition of links from large collections to collections that are being advertised to, or package updates.

The SMS status subsystem provides audit events to watch for such activities. All audit events are maintained for 180 days by default. Other server status messages are kept for 30 days by default. SMS provides several default status message queries that you can use to audit SMS activity. The following is a partial list of status message queries that you might find useful when monitoring for unauthorized activity:

  • Security rights created, modified, or deleted

  • Advertisements created, modified, or deleted

  • Packages created, modified, or deleted

  • Programs created, modified, or deleted

  • Clients that (failed to run) (failed to start) a specific advertised program

  • Server component configuration changes

  • Client component configuration changes

  • Remote tools activity (all)

  • Site addresses created, modified or deleted

  • Site boundaries created, modified or deleted

  • SQL commands created, modified or deleted

  • SQL tasks created, modified, or deleted

  • All audit status messages (for a specific user) (from a specific site)

Periodically Test SMS Security

Test SMS security when you are putting it in place and test it periodically thereafter. Try to access all types of SMS resources using accounts you have created and delegated tasks to in order to verify that SMS objects and data are protected.

You can use the SMS Security Test worksheet contained in the Security Checklists to help collect and document this information.

SMS 2003 Security Test Checklist

Develop an Incident Response Plan

Even with the best security design and implementation, your technology environment can still be successfully attacked. Not all vulnerabilities are resolved by the application of security updates; some vulnerabilities are related to weak computer security configurations. The most devastating attacks often use ingenious social engineering techniques to get authorized users to assist in the attack.

Designing an incident response plan could be as crude as “unplug affected computers from the network, reformat, and reinstall” or it might be a sophisticated endeavor with trained forensics experts who know precise techniques for gathering evidence that can be used in prosecution. Decide what your appropriate level of response is and practice your plan periodically.

For more information about disaster recovery and incident response, see Disaster Recovery and Incident Response (https://go.microsoft.com/fwlink/?LinkId=28825) on the Microsoft TechNet site.

Secure Your Internal SMS Documentation

Your network documentation can provide everything someone needs to know to implement a successful attack. Even your list of internal SMS contacts could be used in a social engineering attack. Store your SMS documentation in a secure location. Dispose of SMS documentation in a shredder or by using a secure document removal service. If you keep backup copies of SMS documentation for disaster recovery, secure the backup copies.

Conduct Ongoing Threat, Vulnerability, and Risk Analysis

Securing your SMS environment is not a task you can complete once and forget about. Every day, new attacks are being developed to exploit newly discovered vulnerabilities. A merger or new product line might completely change your organization’s tolerance for security risk. Periodically review every aspect of your SMS security implementation, including design, implementation, policies, and maintenance.

Train Your Organization to Follow Security Best Practices

Develop a comprehensive user education program for your end users to train them that security is everybody’s responsibility. Train your network administrators on proper security procedures and enforce strict adherence to security policy. SMS administrators who do not lock their SMS Administrator consoles are inviting attacks from disgruntled employees. Receptionists who are trying to be helpful can inadvertently give attackers everything they need to compromise valuable trade secrets.