- Stick to the Essentials on the Server Host Machine
- Keep Operating Systems and Applications Software Up-to-Date
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Keep Operating Systems and Applications Software Up-to-Date
Administrators need to stay informed of vendors' security-related updates to their products, which may be called updates, upgrades, patches, service packs, hot fixes, or workarounds. Whenever an update is released, an administrator needs to evaluate it; determine whether it is applicable to the organization's servers; and, if so, install it.
Why This Is Important
Because software systems are so complex, it is common for security-related problems to be discovered only after the software has been in widespread use. Although most vendors try to address known security flaws in a timely manner, there is normally a gap between the time the problem is publicly known and the time the vendor requires to prepare the correction; and additional time elapses before the update can be installed. This gap gives potential intruders an opportunity to take advantage of the flaw and mount an attack on an organization's servers. To keep this time interval as short as possible, administrators need to stay attuned to announcements of security-related problems that may apply to their systems; determine immediate steps they can take to reduce their exposure to the vulnerability, such as disabling the affected software; and obtain permanent fixes from vendors.
How to Do It
Installing applicable vendors' updates can reduce server vulnerability to attack. Use vendor Web sites and other commonly available sources of information to stay current: for example, the CERT/CC site and the implementation Maintaining currency by periodically reviewing public and vendor information sources.
Establish a procedure for monitoring these information sources. Consider purchasing comprehensive vendor services and support for critical servers.
Evaluate and Install Updates
Not all updates are (1) applicable to the particular configuration of an organization's servers, and (2) required to meet security requirements.
Evaluate each update to determine its applicability, and weigh the cost of deploying an update against the benefits of doing so. Keep in mind that failure to install a vendor patch may result in a known vulnerability being present in the server's operational configuration. This basically becomes a risk assessment/management decision.
Installing an update can itself cause security problems, such as the following:
During the update process, the server may temporarily be placed in a more vulnerable state.
If the update is scheduled inappropriately, it might render a server or information asset unavailable when needed.
If an update must be performed on a large number of servers, there may be a period of time when some servers on the network are using different and potentially incompatible versions of software, which might cause information to be lost or corrupted.
The update may introduce new vulnerabilities.
Updates can also cause a number of problems in other installed software. We recommend installing updates in an isolated test environment and running a previously developed regression test suite to compare current performance with past performance. Additionally, run a series of user trials before releasing the update on operational systems. A less-desirable but perhaps more practical approach would be to apply the update to a small number of less-critical servers to see if any problems emerge before rolling out the change to all servers.
Several software tools (such as Tripwire) are designed to reveal any differences in the system as a result of installing the update. We recommend the use of one of these tools so that an administrator can fully understand and analyze the effects of the update on each server. In addition, always back up any system before applying any update. And ensure that the system can be restored from the backup in the event of problems
Any method of updating that depends on an administrator physically visiting each server is labor-intensive, but will work for networks with a small number of servers. Automated tools are needed, however, to roll out updates to a large number of servers. Although vendors provide some of these tools for their product, an administrator may need to develop tools that are tailored to the environment if vendor tools are insufficient.
Given the number and diversity of operating systems and applications, the update process can become unmanageable if appropriate levels of automation do not support it. In such cases, updates may not be performed, which in turn places servers at risk by allowing intruders to take advantage of known vulnerabilities.
When using automated tools to roll out updates, the affected servers are likely to be vulnerable to attack during the update process. To lessen this vulnerability, use only an isolated network segment when propagating the updates; alternatively, consider using secure connectivity tools such as SSH. (For further information about SSH, refer to http://www.ssh.com and http://www.openssh.com/.)
Install the updates using a documented procedure to avoid errors and ensure that all bases are covered.
It is possible that an administrator may not have enough information to decide whether or not to apply an update. An organization may not be able to afford a comprehensive test environment in which to evaluate the effects of an update. In either of these situations, we recommend implementing the steps in this practice as far as is both possible and practical. Try to recognize and manage any remaining risks of exposure.
The February 2002 issue of Information Security magazine contains several articles that provide further guidance on whether or not to patch, and contains tools for managing configurations and updating security patches in a distributed computing environment. ("Patchworks" by Russ Cooper and "Patching Across the Enterprise by Scott Sidel and Andy Briney. Available at http://www.infosecuritymag.com/.)
Deploy New Servers with Up-to-Date Software.
When new servers are being deployed, it is common to install the operating system and other software from the original distribution media supplied by vendors. However, those software versions may not include recent security-related updates. Maintain an archive of updates that have been evaluated and chosen to install on existing servers, so that they can be installed on new servers before deployment.
Acquire and install the most current production-release driver software (often available from vendors' Web sites) for all components and peripheral devices. These drivers typically address performance and security issues that have been discovered since the components were packaged and shipped. Be sure to read all the release documentation associated with the updated drivers before using them. Whenever possible, verify the integrity and authenticity of the new driver software, using methods such as comparing cryptographic checksums with those supplied by the vendor.
Create New Integrity-Checking Information
After making any changes in a server's configuration or its information content, create new cryptographic checksums or other integrity-checking baseline information for that server.
Integrity checking tools (such as Tripwire) can identify changes made to files and directories. By creating another baseline and subsequently monitoring these changes, an administrator can learn more about how the server is working and, over time, identify unexpected changes that require further investigation.
CERT provides a checklist on securing UNIX-based systems at http://www.cert.org/tech_tips/AUSCERT_checklist2.0.html, and SANS provides guides for Linux, Windows 2000, Windows NT, and Solaris at http://www.sansstore.org/Templates/frmTemplateK.asp?SubFolderID=22&SearchYN=N.
These guides assist an administrator in thinking about the issues to be considered when hardening and securing a system.
The CERT® Guide to System and Network Security Practices provides a detailed description of the practices necessary to harden and secure a general-purpose server (Chapter 2), a public Web server (Chapter 3), and a firewall system (Chapter 4).