Patch Management Plan

Patch management consists of scanning Servers, computers, Network Devices

(Switches, Routers, Firewalls), OS, Software Applications or other machines on a
network for missing software updates, known as “patches” and fixing the problem by
deploying those patches at a determined time. Patches are necessary to ensure that
the systems are fixed, up to date and protected against security vulnerabilities and
bugs.

The Patch Management Lifecycle, involves a number of key steps:

Vulnerability Risk Assessment Patch

Preparation Identification & & Prioritization Patch Testing Deployment &
Patch Acquisition Verification

I. Preparation
The following are suggested as part of the preparation process:

1. Create and maintain an SOC hardware and software inventory.

System administrators should create and maintain a clear inventory
record of all hardware equipment and software packages, along with
version numbers of those software packages most used within the
SOC. This inventory will help system administrators better monitor and
identify vulnerabilities and patches that are applicable across the SOC.
2. Standardise configurations: Standard configurations should be
created and maintained for every major group of IT resources, such as
servers, user workstations and network devices. Standardised
configurations can simplify the patch testing and application updating
process.
 3. Educate users : Information security is everybody’s business and
an effective patching process cannot be implemented without the
cooperation and participation of end-users across the SOC. Users
should be made aware of the importance of IT security and patch
management as part of their daily work process.

II. VULNERABILITY IDENTIFICATION AND PATCH ACQUISITION

There are a number of information resources available to system

administrators in order to monitor vulnerabilities and patches that may be
applicable to their installed hardware and software systems.

1. Product vendor websites and mailing lists: Product vendor

websites are probably the most direct and reliable resources for
system administrators on vulnerability and patch related information for
specific products. Many large vendors also maintain support mailing
lists that enable them to broadcast notifications of vulnerabilities,
patches and updates to subscribers via email. However, it should be
noted that vendors sometimes do not report new vulnerabilities straight
away, as they may not wish to report a specific vulnerability until a
patch is available. It is therefore necessary to track other IT security
resources for timely vulnerability and patch information.
2. Third-party security advisory websites: A third-party security
advisory website is one that is not affiliated with any one vendor, and
may sometimes provide more detailed information about vulnerabilities
that have been discovered. These websites may cover a large number
of products and report new vulnerabilities ahead of the product. These
third-party vulnerability advisory websites can be divided into two
categories: websites run by Computer Emergency Response Teams
CERT-IN / CERT and websites run by security vendors.
 a) Security advisory websites run by CERT-IN / CERT. It provides
technical information about any newly uncovered vulnerability
that can assist system administrators and security professionals
in assessing the threat from the vulnerability. These advisories
are updated as soon as new information is available from the
product vendors.
b) Security advisory websites / resources run by security vendors:
A number of third party mailing lists, such as NTBugTraq
maintained by CyberTrust, and BugTraq maintained by
SecurityFocus, are popular with IT professionals. However,
system administrators should verify the information released in
these websites with product vendors to confirm the accuracy of
any newly discovered vulnerabilities. These websites may also
offer newsgroups that system administrators can use to
communicate with other users in the same field. System
administrators should be careful not to release sensitive
information through joining and using these mailing lists and
newsgroups.

III. RISK ASSESSMENT AND PRIORITISATION

Timely response is critical to effective patch management. With limited

resources, system administrators may need to prioritise the deployment of
new patches, performing a risk assessment to determine which systems
should be patched first. In general, this prioritisation should be based on the
following criteria:
1. Threat – A threat is any potential direct danger to information systems.
Examples of systems facing high threat levels are servers, networking &
security.
 2. Vulnerability – A vulnerability signifies the absence of, or a weakness in, a
safeguard which could be exploited by an attacker. It could be a flawed
software service running on a server and so on.
3. Criticality – This is a measure of how important or valuable a system is to
operations. Systems that are frequently considered as mission critical include
servers, network & security devices .
In general, systems facing more threats, or that are more vulnerable, or are
mission critical should be accorded a higher priority in the patch management
process.
System administrators should identify the associated risks and actions that
need to be taken once a security vulnerability has been confirmed (for
example, scheduling system down time for reboot after installing a patch),
and assess any impact associated with installing a security patch once that
patch becomes available. Before applying a patch, system administrators
need to ensure that the new patch is not going to affect the overall
functionality of the system and its applications.

IV. PATCH TESTING

Patch testing is vital to ascertain whether or not a new patch will affect the
normal operation of any existing software. It is important that this testing is
performed on a mirror system that has an identical or very similar
configuration to the target production system. This is to ensure that the patch
installation does not lead to any unintended consequences on the production
system.
In addition to identifying any unintended problems, patches themselves
should be tested to ensure that they have fully patched the vulnerability in
question or corrected the performance issue as intended. This can be
accomplished by:
1. Checking that the files or configuration settings that the patch is intended to
correct have been changed as outlined in the vendor’s documentation.
 2. Scanning the host system with a vulnerability scanner that is capable of
detecting known vulnerabilities. This technique however may not always be
effective because vulnerability scanners may not check for the actual
presence of the vulnerability in question. Many vulnerability scanners only
check software version numbers or patch levels to determine whether
vulnerabilities exist or not. If it is not feasible to install the patch because, for
example, testing results show that the patch will crash or seriously disrupt the
production system, alternate security controls should be implemented.

V. PATCH DEPLOYMENT AND VERIFICATION

1. Patching vulnerabilities in a system may be as simple as modifying a

configuration setting, or it may require the installation of a completely
new version of the software.
2. No single patch method can apply across all software applications and
operating systems. Product or application vendors may provide
specific instructions for applying security patches and updating their
products, and it is recommended that system administrators read all
the relevant documentation provided by vendors before proceeding
with patch installation.
3. In addition, security patches should be deployed through an
established change control process. Before applying a new patch,
administrators may want to conduct a full backup of the system to be
patched. This enables a quick and easy restoration of the system to a
previous state if the patch has an unintended or unexpected impact on
the system.
4. After the patch is deployed, system administrators and users should
verify that all systems and applications are functioning normally, and
that they comply with laid down security policies and guidelines.
VI. Patch Process
If the urgency determination requires immediate action and a work-around solution
is either not available or not the best option, then the following actions should to be
taken:
1. Where possible, create a backup/archive and verify its integrity by deploying it
on a standby system.

2. Create a checklist/procedure for patch activities and deploy the patch on the
standby system.

3. Test the patched standby system for operational functionality and

compatibility with other resident applications.

4. Swap the patched standby system into production and keep the previous
unpatched production system as a standby for emergency patch regression.

5. Closely monitor the patched production system for any issues not identified
during testing.

6. Patch the standby system (old production) after confidence is established with
the production unit.

7. Update software configuration management plan and related records. Even

though it is recommended that a standby system be in place, some sectors
may not have a requirement for this system. In these cases, at a minimum,
there should be a backup and archive performed that has been verified for
restore capability.