1

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 Patch Management 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.

1.1.1.1

E-Mail Notifications

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 updates through 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 and update 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: 3

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 if Jetstar 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 Summary

Description 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. 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. 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

Vulnerability Details

Workarounds

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. 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. 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 based on the potential impact of the vulnerability and are intended to inform the Administrator of the urgency of any required actions.

Security Update Information

Knowledge Base article

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 and understand 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.

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 email message. It is important to ensure that somebody is responsible for checking the Universal Resource Locator (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. 6

Software update file size must be checked. File size will impact Jetstar overall release process and planfor 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 quarantine should 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. 7

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.