Professional Windows Server 1002003 Security A Technical Reference [Electronic resources]

Roberta Bragg

نسخه متنی -صفحه : 194/ 135

Maintenance Strategies for Change Management

Change management is the process that formalizes and appropriately organizes the response to necessary changes. Patch management is one form of change control, albeit a potentially more volatile one. Change management, however, encompasses all potential changes, even those that are not security-related. It includes system upgrades, release changes to existing software packages, and new programs, hardware, and systems. Another part of change management, security configuration maintenance, must be a part of change control as well. Security configuration maintenance is the process of keeping security configuration and practices in place. Over time, security practices may be modified due to performance, temporary requirements, or some legitimate change to the system, which may weaken security.

NOTE: Changes Can Mean New Threats

Changing from passwords to smart cards for authentication is a change that, at face value, improves the security of the network, but if not handled properly, can have the opposite effect. For example, if the process required to obtain a smart card does not include proof that the requestor has a current account on the system or is approved for a new account, unauthorized individuals may obtain credentials that permit them to access the system. The attacker does not have to break the increased security that smart cards provide because he has legitimate credentials. Other changes, such as the addition of PDAs that interface with the network, may not appear to be security-related at all and yet bring with them the potential to impact security. PDAs might be lost and, if not correctly configured, might offer unrestricted access to the organization's network to anyone who finds the PDA or access to sensitive data on the PDA. In addition, PDAs configured for wireless communications might become infected with a virus and spread it to the network. Each change, therefore, should be evaluated for the impact on security before and after the change is made.

Although testing and troubleshooting is not usually considered part of change management, these processes can have a significant impact on security. While testing should be done in a lab or test environment, not in production, it doesn't always happen this way. Security settings may be relaxed in order to tell if they are the reason for a problem or because the person performing the tests knows that they have the potential for causing a problem. If the security configuration is not returned to its previous state, a permanent reduction in security may result. In some cases, the security change is not reinstituted because it will prevent some required new functionality or reinstate something required that was removed when a security configuration was made. In either case, the reason for the security configuration change should be determined, not simply left as a decision made by the troubleshooter.

Security Policy Maintenance

Security policy maintenance is the process of ensuring that security settings, policies, and practices remain in place. In an Active Directory domain, security settings established in Group Policy will automatically be refreshed, as described in Chapter 7, "Active Directory's Role in Domain Security." In addition, Group Policy is reapplied during computer startup and user logon. However, if there is no policy and procedure in place to manage changes to Group Policy or to authorize administrators who can change Group Policy, security settings might be arbitrarily changed, and what once was a strong security framework might become weakened or perverted over time. Ensure the proper administration of GPOs by training, approving, and auditing administrators. Do this and manage the permissions on GPOs, and you ensure the maintenance of these policiesas long as Group Policy is operating correctly. If Group Policy fails, security settings will not be refreshed.

Be aware that other Group Policy settings outside of domain-based Group Policy must also be maintained. Other management processes must be established for these settings. These settings include the following:

Those established on standalone computers

Those established directly in local Group Policy for individual computers (and not overridden by domain-based policy)

Those that are established outside of any Group Policy

Two ways to ensure the maintenance of security configuration are the normal reapplication made when the security settings of Group Policy are applied, and the use of security audits to determine that settings that are being applied in compliance with your organization's security policy. Security Settings, a section of Group Policy, are reapplied every 16 hours whether or not changes to Group Policy are made. Security Settings do not encompass every security configuration that might be made with Group Policy but do include those made in Account Policy, Local Policy, Event Log, and so on, as shown in Figure 16-1. It does not include security settings made in the Administrative Templates sections of User or Computer Configuration.

Figure 16-1. Security Settings areas that are automatically refreshed.

Chapter 18, "Auditing."

As part of your maintenance strategies, establish a periodic review of security settings. Just as an IT auditor might review your current security settings against your organization's security policy and information security best practices, you should review the actual security settings to ensure that they remain the way they are supposed to. There are numerous ways to do so. Steps that should be part of your security maintenance plan are as follows:

Ensure that Group Policy is working. If Group Policy is not working, cached Group Policy will be applied to the computer. However, problems with Group Policy mean problems for any new changes to Group Policy. Part of security maintenance should include verification that Group Policy is working.

Directly test application of security settings by analyzing different classes of computers using Security Configuration and Analysis (SCA). Use a template that accurately reflects the security for the computer tested and that is added to the system to be tested just for the test, not a local copy of the template that might have been subject to modification. A good practice is to keep a template copy in a secure location. SCA will point out differences between the actual security on a system and the security that is supposed to be applied. Because the "actual" security is tested against a known security policy, you can be sure of discovering any problems due to unauthorized changed in Group Policy, or the movement of computer accounts to OUs where the proper security for this specific computer is not linked. SCA can also be used to test standalone computers.

Use Resultant Set of Policy to determine the security in place when a specific type of user is logged on. RSoP will also show the impact of administrative templates, which SCA cannot do.

Periodically review OU locations of user and computer accounts. If an account is not in the proper OU, it may not be getting the appropriate security applied.

Ensure that change control practices are designed to consider the impact of changes on security. Changes to security may improve security and mitigate risk or they may weaken security and increase risk. Ensure that the design is implemented in written policies and procedures and audit their use. If proposed changes do not indicate security changes, review security after changes are made to ensure that this is so. If proposed changes will impact security, ensure that management properly reviews this impact.

Updating Security

Security updates can be both reactive and proactive. Reactive security updates are responses to announcements of security vulnerability and, in most cases, are accomplished via patch management. Proactive security updates are the result of either the acquisition of new security information (you learn, for example, that you can reduce exposure by limiting permissions on some critical resource or by disabling some unnecessary service and do so) or new security policy. Reactive security updates are undertaken as the result of the public notice of some new vulnerability, sometimes after an exploit that takes advantage of the vulnerability is already circulating. Security patch installation may be reactionary; it may also become mostly proactive if a well-designed patch management program is in place. Because service pack installations provide security updates as well as other fixes and feature changes and are not usually provided as critical updates, they can be either proactive or reactive. On one hand, they are usually applied after much testing and planning, which may be part of the patch management program. On the other hand, if systems are long overdue on a service pack update, installation may be reactionary as it applies multiple security patches at one time.

Methods for performing updates vary. Proactive security updates may require manual configuration, changes to Group Policy, or the development of scripts. They may also include the slipstreaming of service packs and patches into new operating system installs. Reactive updates often use well-established methods such as Windows Update, Automatic Update, Software Update Services (SUS), or third-party products. However, these patch installation methods may also be part of a well-planned and operated patch management program.

Implementing Proactive Updates

Manual changes are described throughout this book, and modification of Group Policy is described in Chapter 7. Information on developing scripts is amply covered in the "Microsoft Windows 2000 Scripting Guide," which can be downloaded from http://www.microsoft.com/technet/scriptcenter/guide/default.mspx. The guide includes a basic tutorial on script writing. Many additional sample scripts can be found at the Script Center Repository at http://www.microsoft.com/technet/scriptcenter/scripts/default.mspx.

New systems should always be updated before being put into production. This means that service packs and security patches should be slipstreamed during the installation process or applied right after installation. In prior editions of Windows, the application of multiple updates potentially required multiple reboots or the use of the qchain.exe utility. This ensured that the most recent version of updated software was retained. All Windows Server 2003 updates have this functionality built in when the /z switch is used with the security patch update.exe executable.

Slipstreaming updates during an installation requires some initial setup but can save time by automating the process for multiple installations. The process outlined here is further discussed in the article "Guide for Installing and Deploying Updates for Microsoft Windows Server 2003 and Windows XP 64-Bit Edition Version 2003" (http://www.microsoft.com/technet/security/topics/patch/hfdeploy.mspx). To prepare a network server installation point with slipstreamed security patches, follow these steps:

Create and share a folder on a file server that will be used for server installs. You can name the folder and the share as you wish; in this example, the name W2K3 is used. Give the Administrators group or selected administrators full control of this folder. Provide users authorized to install servers with the Read and Execute permissions.

Copy the installation files for Windows Server 2003 from the installation CD-ROM and the updates to the shared distribution folder. Use xcopy to do so. In this example, the folder name C:\W2K3\I386 is used.

Open and edit the file dosnet.inf. This file can be found in the C:\W2K3\I386 folder.

If necessary, create the section [OptionalSrcDirs] in the file.

Add the word svcpack to this section.

Create the subfolder C:\W2K3\i386\svcpack.

Copy each update to the new subfolder.

Rename each update from the longname format to an 8.3 format, KB######.exe, where ###### is the KB number of the update.

Copy each update to the subfolder.

Expand each update to its own temporary folder, one at a time.

Ignore the contents of the rtmqdr folder created by the expanded update.

From the rtmqfe folder, copy the catalog file (KB######.cat) to the svcpack folder.

Evaluate and then copy if necessary the update binary files (.exe, .dll, or .sys) from the temporary folder to the C:\W2K3\i386 folder.

Examine the version number of the update. (Right-click the file, click Properties, click the Versions tab, and examine the File version enTRy.)

Find the same file in the i386 folder and examine its version number.

If the version number in the i386 folder is later than the update, do nothing.

If the version number on the update is later than that in the i386 folder, copy the update to the i386 folder.

If there is no matching file in the i386 folder, copy the update file to the folder.

10.

Each file copied in step 9 should be listed in the dosnet.inf [Files] section in the format d1,filename. If it is not, add an entry using the same syntax.

11.

Delete the svcpack.in_ file in the i386 drive.

12.

Create an svcpack.inf file. In the file, add the section [version] and enter the following lines:

[Version]
Signature="$Windows NT$"
MajorVersion=5
MinorVersion=5
BuildNumber=3790
[SetupData]
CatalogSubDir="\WS2003\i386\svcpack"

13.

Add the section [ProductCatalogsToInstall]. For each catalog file, add an entry; for example:

[ProductCatalogsToInstall]
KB######.cat

14.

Add the section [SetupHotfixesToRun] and, for each update, add the update executable. The options suggested are /Q for quiet, /N for not backups, and /Z for do not restart. A sample section might look like this:

[SetupHotfixesToRun]
KB######.exe /Q /N /Z

To install the server, connect to the share and run winnt.exe or winnt32.exe from the i386 folder.

Implementing Reactive Updates

Some very creative people, both those interested in protecting systems and those interested in destroying them, are hard at work searching for vulnerabilities or weaknesses in computer software. No matter who finds the problem, the end result is the same. If you are responsible for the security of computer systems on which the vulnerable software is running, you must take steps to ensure that the systems are protected from any attack that might exploit the new vulnerability. Those organizations that follow sound security principles may already have in place controls that might prevent or mitigate the impact of such an attack. However, even if this describes your organization, each new discovery should be investigated and properly addressed.

Unfortunately, many organizations install security patches willy-nilly in response to imminent attacks. They download the patch and install it individually on computers using the patch's update executable, use Windows Update, or frantically write scripts in hopes of speeding application over multiple systems or of multiple patches. When the next worm or exploit becomes known, the process starts again. This reactionary fiasco can be turned into a managed process. Although there may still be times when emergency patches must be quickly deployed because of the announcement of an exploit at the same time as a patch, most updates can be carried out as part of normal maintenance.