Patch Management Process V0_3 Chapter 2

8/13/2019 Patch Management Process V0_3 Chapter 2

1/9

1


2/9

2

1 Chapter 2: Identify

Overview

This phase describes the second phase Identify of the IT Patch Management process. The Identify phase is

concerned with the identification and reliable discovery of new software updates, whether new updates are

relevant to Jetstar production environment, and whether an update represents a normal or emergency change.

Figure below shows this phase as relevant to the other phases.

Figure 1 The IT Patch Management process

The main sub steps involved in this phase are:

a. Discover new software updates.

b. Determine whether software updates are relevant to Jetstar production environment.

c. Obtain software update source files and confirm that they are safe and will install successfully.

d. Determine whether the software update should be considered a normal change or an emergency, and

submit a request for change (RFC) to deploy it. Submitting an RFC is the trigger for the next IT PatchManagement phase, which is Evaluate and Plan.

1.1.1 Discover a New Software Update

Identification of a software update starts with discovering it in a safe and reliable way. Discovery has two main

components:

How the Administrator are notified of a new software update

How the Administrator know the Administrator can trust the source and the notification

How The Administrator Are Notified of a New Software Update

Discovering a new software update starts with notification. Notification should be supplied either through

subscription to a reliable source that provides scanning and reporting activities, or by some other reliable

notification mechanism. The most commonly used notification mechanisms are:

E-mail notifications.

Vulnerability scanning tools.

The vendor relevant web site page.


3/9

3

1.1.1.1 E-Mail Notif icatio ns

Notification by e-mail is the most common form of update notification. One option for e-mail notification is to

subscribe to the vendor site (e.g. Microsoft Security Notification Service). For interim product releases, or

software updates, an e-mail message will normally be received informing the administrator that new software

updates are available on the vendor web site.

Trusted Source and Notification

It is important to handle e-mail notifications carefully. The following business guidelines (requirements) are critical

to validate each notification and ensure it is the latest security bulletin information available:

Executable attached to an e-mail notification must not be run or installed. Most vendors have a policy of

never distributing software through e-mail attachments.

Any links should not be clicked from inside an e-mail notification. Instead, it should be pasted (URLs) into

a browser window to confirm that they direct the Administrator to the vendor web site. Vendors may

provide their customers with a key to access their security bulletins.

Always visit the vendor security centre website (e.g. Microsoft TechNet Security Center Web site).

Vendors digitally sign all e-mail notifications related to security updates when it sends these notifications

to customers.

Administrator must sign up for the vendor update-alert service, which informs them of new updatesthrough an e-mail message.

Upon receiving a new e-mail notification there must be a capability within the proposed solution to detect

that the update (refereed in the vendor email notification) is applicable to systems in Jetstar production

environment:

If the update is for software that is not supported or detectable, the Administrator should use the

hardware inventory and software inventory system to determine which computers need the software

update.

If the update can be detected, the Administrator should use the proposed software patch and update

management tools to identify the computers requiring the update.

If the update is for a Microsoft Office application, and the update is in the list of updates supplied by

the Microsoft Office Inventory Tool for Updates, the Adminstrator can use the software patch andupdate management tools to identify the computers requiring the update.

1.1.2 Vulnerability Scanning Tools

As mentioned earlier in this module, administrators can use a tool (such as MS Windows Server Update tool) to

scan for missing and installed security updates on local and remote computers and to determine whether the

computer is exposed to common security vulnerabilities such as a blank administrator password.

Administrator can also use components of the tool that can scan for, and report on, missing and applied software

updates across Jetstar environment.

1.1.3 Determine Whether Software Updates Are Relevant

A large number of software updates are regularly released into the information technology (IT) operations

community. These come from a variety of sources and have been created for many reasons, including addressing

problems that could lead to security breaches. All software updates must be checked thoroughly for their

relevance to the IT infrastructure of Jetstar . The screening process outlined in this section should remove the

majority of irrelevant software updates, but it is likely there will still be more that the Administrator can discount.

Each software update received should be checked for relevance. When a notification contains information about

more than one software update, each update needs to be checked individually for its relevance to Jetstar.

The following are the applicable steps in this sub process:


4/9

4

a. The first step in checking for relevance is determining whether the software update is designed

to address the operating system or applications in Jetstar production environment.

b. Once that the software update applies to something in Jetstar production environment have

been determined, the next step is whether the application or system that the update applies to

exhibits the vulnerability the software update is designed to address. For example, a software

update might be designed for all Windows Server operating systems running Microsoft Internet

Information Services (IIS) with Active Server Pages (ASP) enabled. While Jetstar environment

might contain several Windows Server operating systems, the security update is not relevant ifJetstar organisation does not have ASP enabled on any IIS servers.

c. Not every security update that applies to something in Jetstar environment will be relevant.

Although it is important to be aware of, and have a good understanding of, existing security

updates, the Administrator should only deploy security updates that have relevance to Jetstar

environment. This will minimise the effort that is required to keep Jetstar environment up-to-date

and secure.

d. Although the information in a software update might be classified as irrelevant, it is important to

note that it exists by passing the information to personnel in problem management. If it later

becomes relevant and is required, the organisation will have access to this information at the

original source.

There are several screening methods that can be used to determine the applicability of a software update to

Jetstar IT infrastructure:

Reading security bulletins and vendor knowledge base articles (e.g. Microsoft Knowledge Base (KB)

articles).

Reviewing the individual software updates.

Using the proposed solution Administrator console (e.g. MS System Centre -2012 Admin Console).

Using the proposed built-in reports.

1.1.4 Reading Security Bulletins and KB Articles

Information in security bulletins on the vendor web site is arranged into sections that help the Administrator to

determine how critical the described vulnerabilities are to Jetstar environment. Although Administrator should

review all information in a security bulletin, they should pay close attention to the following sections shown in

Table 1 below when first examining a security bulletin (note that Microsoft security bulletin details has been used

as an example).

Section Description

Summary Summary section of a security bulletin must immediately be reviewed. The Maximum

Severity Rating, Impact of Vulnerability, Affected Software, and Recommendation

items contain information that will assist the Administrator with determining how prone

Jetstar environment is to the vulnerability.

Vulnerability

Details

The Vulnerability Details section should provide an in-depth technical description of

the vulnerabilities. This section also outlines the mitigating factors and the severity of

the vulnerability for all affected products.

Workarounds The Workarounds section includes information on the workarounds that the vendor

might have tested in order to help mitigate the threat until the Administrator have


5/9

5

updated Jetstar environment. This section must be read as part of Jetstar risk

assessment.

Frequently

Asked Questions

The Frequently Asked Questions section provides answers to commonly asked

questions specific to that vulnerability or fix. This is a good place to start after reading

the Summary section.

Security Update

Information

This section lists items like prerequisites, platform-specific Installation Information,

deployment information, restart information, removal information, file information

(including file names, size, versions, target folder), and update verification steps.

Knowledge Base

article

Additional information on the vulnerabilities and any updates prescribed by the

security bulletin might be provided in the KB article.

Table 1: Security Bulletins - Key Information

In addition to the items described in Table 1, numbers of vendors provide a maximum severity rating system to

assist the Administrators with quickly determining how important an update is to Jetstar. These ratings are basedon the potential impact of the vulnerability and are intended to inform the Administrator of the urgency of any

required actions.

1.1.5 Reviewing Individual Software Updates

Each software update in a notification requires a detailed and in-depth review. This review should include all

associated documentation, including that sent with the software update and supporting information that might be

found, for example, on the Microsoft TechNet Web site. Sub process steps involved are as follow:

a. Once the Administrator receives an e-mail message identifying applicable software updates,

they must make someone responsible for investigating them. This team member should then

take ownership of the software update. The reviewer needs to read the relevant KB article andunderstand what is fixed by the software update.

b. The software update may be specific to particular scenarios or configurations. The reviewer

should check whether the scenario/configuration deployed in production matches that covered

by the KB article.

The following business rules are applicable in terms of software update dependencies:

Are there dependencies relating to the update? For example, do certain features need to be

enabled or disabled for the update to be effective?

Does the software update require a certain service pack to be installed? Is the software update

superseded by a service pack or another software update and does it makes sense to wait for a

newer version?

c. Identifying the above dependencies is critical because it will have a direct impact on Jetstar

release and deployment planning for the software update. Document which service pack (SP)

the software update will appear in and whether a different version of the software update is

required, is depending upon the active service pack. (It is important to know this in case

compliance problems occur as users upgrade from one service pack to another.)

d. The Administrator can use the scan results and reports generated by the proposed solution

Software Patch and Update Management features to view the specific and applicable

information regarding a software update.


6/9

6

1.1.6 Identifying and Verifying the Software Update

Once a software update has been identified and its relevance established, the Administrator must obtain the

software update source files and confirm that they are safe and will install successfully. The verification process

will either authenticate security updates or highlight updates that are not security-validated. In the latter case,

when an invalid notification is received, information about the notification should be sent to those responsible for

the subscription process and to the security team for further investigation. For example, if a notification comes

from a normally reliable source of information, but the specific notification has errors on validation, this might raise

security concerns about the quality of the notifications from this particular source. The source should be

investigated and any issues resolved.

At a minimum, Jetstar software update verification should consist of the following steps:

Identifying and verifying the software update.

Reviewing all accompanying documentation:

o Reviewing software update files.

o Identifying software update size.

o Identifying software update dependencies:

o Identifying any pre-updating or post-updating actions needed.

o Verifying that software update install procedures exist.

o Verifying that software update uninstall procedures exist.

Ensuring that the software update is safe.

Vendors normally notify their clients Administrators of new software updates through e-mail messages, but it

never includes (or attaches) software files to these messages. The following are key business rules and practices

with regards to notification and verifying a vendor as the software update owner:

Vendors will occasionally send an e-mail message to customers to inform them that upgrades and

software updates are available. However, the message will provide links to the download sites only. The

software itself will never be attached. These links will always lead to either the vendor Web site or the

vendor File Transfer Protocol (FTP) site, never to a third-party site. Some malicious e-mail messages

might contain Internet links in which the link is not the same as the text shown in an HTML-formatted e-

mail message. It is important to ensure that somebody is responsible for checking the Universal ResourceLocator (URL) of the Web site visited.

In addition to links provided in e-mail notifications, vendors make software updates available on the

Internet. The Administrator should cross check both links to ensure that they are from the same source.

The software update files may also be provided on physical media such as CD- ROMs and floppy disks.

Most vendors always use authenticode technology to digitally sign its products and allow administrators to

ensure that the files have not been tampered with.

1.1.7 Reviewing All Attached Documentation

Before applying any software update, the Administrator should read and peer review all relevant documentation.

The peer-review process is crucial as it mitigates the risk of a single person missing critical and relevant points

when evaluating the update. Following are a set of applicable business rules;

Adopting the update must not cause other problems, resulting in a compromise of the production system.

The Administrator may need to perform any actions prior to deploying the update.

The Administrator may need to perform any actions after deploying the updates.

Any available workarounds or mitigation steps must be checked and understood while the Administrator

update Jetstar environment.

Software update install procedures must be available.

Software update uninstall procedures must be available.


7/9

7

Software update file size must be checked. File size will impact Jetstar overall release process and plan-

for example, how the Administrator handles mobile users.

The Administrator will find information in the security bulletin, under the sections described earlier in Table 1,

which will help the Administrator to comply to the above business rules.

1.1.8 Ensuring That the Software Update Is Safe

To prevent virus infection or malicious code from affecting Jetstar environment, the following should be looked at:

a. Any files related to a software update in an isolated (quarantined) environment. This quarantineshould be imposed on all software and documentation. There should be strict controls in place

in the quarantined environment and, to ensure this, the quarantine process should be carried

out by a group of specialists in the organisation.

b. Software updates may only require the Administrator to make registry or configuration file

changes or adjust application settings, but most software updates will involve downloading files.

Always quarantine the files that the Administrator download by isolating them from Jetstar

production network while the Administrator examine them for viruses and confirm their digital

authenticity.

If the Administrator use WSUS, each update is signed; a hash is computed and sent with the metadata (metadata

that describes what an update is useful for). When an update is downloaded, WSUS checks the digital signature

and hash. If the update has been tampered with, it is not installed..

1.1.9 Verifying the Software Update Install Procedures

The following are the steps required for verifying the software update install procedures:

Follow the instructions given in the vendor provided knowledge base articles and security bulletin

accompanying a software update to verify that it installs correctly.

Determine whether the software update requires a restart. If it requires a restart, special considerations

during the planning and deployment phases for mission-critical servers have to be taken into

consideration. To get more information on these issues, refer to the details listed in this document for

phase 3 , "Patch and update management Phase 3 - Evaluate and Plan."

Assess how much disk space the software update requires (including an Uninstall folder).

Check whether the update provides configuration options that are available to the Administrator during

the install.

Read any supporting documentation for additional information about installing a software update.

Despite Jetstar/Lincom testing, the Administrator may run into problems after installing the software update that

requires the Administrator to uninstall it. It is important, therefore, to test that the uninstall procedure works. After

uninstalling, the Administrator should check that the server continues to run as expected and continue to watch

the event/system log.

Some of the updates released by vendors provide an uninstall path, whereas others do not. The Administrator

should have to determine which software updates can be uninstalled by reviewing the technical details in the

security bulletin (if any).

1.1.10 Submit RFC

After identifing the software update, determining its relevance to Jetstar , obtaining software update source files,

and confirming that they are safe and will install successfully, the next step is to submit a request for change

(RFC) to start the evaluation and planning phase of the software update.

The change request submitted must address the following information:

Change details

Vulnerability details the change is in response to.


8/9

8

List of services will be impacted by the change.

Is a software update already being deployed for that service?

Does the software update require a restart to complete the installation?

Can the software update be uninstalled?

Testing and deployment requirements for the software update.

Test strategies recommended for this change.

RFC priority, impact, etc.

If a software update addresses critical security issue or system instability, the priority of the RFC should be

marked as equivalent to "emergency". An emergency RFC should be created only when the deployment of a

software update or the implementation of security countermeasures such as closing network ports must be

performed as a matter of urgency.


9/9

Documents

Patch Management Process V0_3 Chapter 2