Home
Independent
Security

Security Policies

  1. Security Policies Introduction
  2. Security Policies
  3. Password Policy
  4. Remote Access Policy
  5. Internet Connection Policy
  6. Approved Application Policy
  7. Asset Control Policy
  8. Mobile Computer Policy
  9. Computer Training Policy
  10. Wireless Use Policy
  11. Anti-Virus Policy
  12. System Update Policy
  13. User Privilege Policy
  14. Application Implementation Policy
  15. System Lockdown Policy
  16. Server Monitoring Policy
  17. IT Equipment Purchase and Failure Prevention Policy
  18. Incident Response Plan
  19. Incident Response Plan Example
  20. Intrusion Detection Policy
  21. File Backup and Restore Policy
  22. Network Documentation Policy
  23. Server Documentation Policy
  24. Network Scanning Policy
  25. Network Risk Evaluation
  26. Credits

Security
Independent
Home

System Update Policy

1.0 Overview
This policy is an internal IT policy which defines how often computer system updates are done and under what conditions they are done.

2.0 Purpose
This policy is required to establish a minimum process for protecting the organizational computers on the network from security vulnerabilities. This policy shall determine how updates are done for both servers and workstations, and who is responsible for performing the updates along with specifying the tools used to perform system updates.

3.0 Update Requirement Determination
This section defines methods used to determine what updates should be done and when they should be applied.

3.1 Update Types
Several types of updates may be required on any computer and all the types should be considered for the below listed computer system components. They include:

  1. The computer BIOS.
  2. The operating system.
  3. Application updates.

3.2 Update Checking
There are several methods to determine when updates should be performed.

  1. Review of posted security flaws and patches for each type of update applicable to the computer system.
  2. An automatic scanning of the system to determine available updates not yet applied to the system or application.

The review of posted security flaws and patches should always be used for the computer operating system, BIOS, and applications. The manufacturer website should be used and there may also be other appropriate sites posting relevant bulletins. If an automatic update ability is available, it should be compared to the listing of posted updates to be sure it is accurate.

3.3 Update Vulnerability Types
The update considerations should address vulnerabilities caused by:

  1. Code errors
  2. Misconfigurations not covered by patches - An example would be a configuration problem with a mail server allowing non authenticated users to relay email using the mail server.


3.4 Update Information
Before approving updates, administrators should know:

  1. The addressed vulnerability
  2. What previous patches are required or what system update is required.
  3. What programs are affected by the change
  4. What may be broken by the change
  5. How to undo the change.
  6. It is recommended that new patches be tested in a controlled environment that mimics the infrustructure of the production environment before patches are applied. For small organizations that do not have these resources, one technique is to watch the emial groups like NTBugTraq to find out what problems other organizations may be having with the patch. The disadvantage is that you may need to wait a little longer before applying the patch which may slightly increase the time your organization is vulnerable.
  7. Be sure you have a good system and data backup before applying a patch on any system.
  8. Each server should have documentation including a list of applications running on it and a patch history.
  9. All patches approved for client computers or applied to client computers should be documented.

3.5 Support Procedures
To support the update requirements definition and update, the following documents should be created to provide a managed response for system updates:

  1. A procedure for identifying vulnerabilities, patches, and configuration changes.
  2. Procedures for determining how appropriate the patch or configuration change is to each system.
  3. Test procedures
  4. Prioritization rules
  5. Guidelines for implementing patches or configuration changes.

4.0 Server Updates
Server updates shall be done by a qualified and authorized system administrator. Updates for servers shall be checked no less than monthly to determine whether any new updates to any computer system components are required. The system administrator shall determine the following:

  1. Whether the update applies to the computer system under consideration.
  2. Whether the update is safe to apply or whether it make break an application or some other part of the operating system where functionality is required.

A test environment should be used to determine whether updates may break functionality prior to implementation of production environments. The ability to provide a test environment and thoroughness of determining whether any functionality is broken by the update will vary from organization to organization depending on available resources.

5.0 Workstation Updates
Workstation updates may be done using any provided tools depending on the type of workstations and their operating systems. In this policy workstation updates shall be performed using Microsoft system update server. System update server will save a great deal of time and expense since all systems may be updated from one server at the same time. All workstations shall be Microsoft Windows 2000 Professional or Microsoft Windows XP Professional. A qualified and authorized system administrator shall review available updates weekly. Normally updates shall be applied in the test environment two to three days before being applied to the main organization.