Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 50. Service-wide Security Patch Management

10.8.50  Service-wide Security Patch Management

Manual Transmittal

August 15, 2012

Purpose

(1) This transmits revised Internal Revenue Manual (IRM) 10.8.50, Information Technology (IT) Security, Service-wide Security Patch Management.

Background

This IRM defines the security patch management process to ensure the timely implementation of security patches on all Internal Revenue Service (IRS) computers, networks, commercial off-the-shelf (COTS) software, and IRS developed applications and software.

This document describes internal procedures with regards to the notification, testing and installation of security-related patches for both software products and operating systems. While non-security related patches are important, their installation and testing are system and application-dependant, and are not covered by this policy which specifically relates to security-related patches. Organizations that maintain custom developed systems, network components, and applications are responsible for the maintenance and assessment of security patches that impact systems under their management and supervision.

Material Changes

(1) Department of Treasury Directive Publication (TD P) 85-01 and federal regulations require that senior agency officials establish an IT security program, which includes the identification, installation and management of security patches.

(2) IRM 10.8.50 is part of the Security, Privacy and Assurance IRM family.

(3) This IRM incorporates guidance from:

  • National Institute of Standards and Technology (NIST) Special Publication (SP) 800-40, Creating a Patch and Vulnerability Management Program.

  • Treasury Directive TD P 85-01, Department of Treasury Information Technology Security Program, Volume I and II Handbook.

(4) This IRM supplements IRM 10.8.1, Information Technology (IT) Security Policy and Guidance.

(5) This IRM establishes the comprehensive uniform IT security polices to be followed by all IRS organizations when implementing and deploying security patches within the IRS.

(6) Effective July 1, 2012, the Modernization and Information Technology Services (MITS) organization changed its name to IRS Information Technology (IT) . All instances of MITS within this IRM have been updated to IRS Information Technology organization to reflect the change. Link to IT website communication is: http://it.web.irs.gov/ProceduresGuidelines/ITNameChange.htm.

(7) This IRM updates Roles and Responsibilities for CSIRC and Information System Owners.

(8) This IRM updates patch distribution schedule for Low Priority (Green) vulnerability ranking.

(9) This IRM assigns a new timeline of implementation to Low Criticality Level patches.

(10) Title changed from Acting Director, Cybersecurity Policy and Programs, to Director, Architecture and Implementation.

(11) Risk Based Decisions process supersedes the Deviations process.

Effect on Other Documents

This IRM replaces the previous version of IRM 10.8.50, Service-wide Security Patch Management dated August 1, 2010.

Audience

IRM 10.8.50 shall be distributed to all personnel responsible for ensuring the timely implementation of security patches on all IRS computers, networks, and systems. This policy applies to all employees, contractors, and vendors of the IRS.

Effective Date

(08-15-2012)

Terence V. Milholland
Chief Technology Officer

10.8.50.1  (08-01-2010)
Purpose

  1. This Internal Revenue Manual (IRM) provides policies and guidance to be used by the Internal Revenue Service (IRS) organization to carry out their respective responsibilities in information systems security regarding security patch management.

10.8.50.1.1  (08-15-2012)
Overview

  1. This policy delineates the security management structure, assigns responsibilities, and lays the foundation necessary to measure progress and compliance. Requirements in this policy are subdivided under three major security control areas: management, operational, and technical. The management and technical controls sections specifically address the IRS four phase approach for security patch management: assess, identify, evaluate and plan, and deploy. The operational controls section provides specific guidance to the IRS Patch and Vulnerability Group (PVG), Information System Owners, IRS Computer Security Incident Response Center (CSIRC), and Business Units detailing operational duties and responsibilities for security patch management.

  2. This IRM provides the security management policy to ensure timely implementation of security patches on IRS systems that are developed and managed by internal or external service providers.

10.8.50.1.2  (08-15-2012)
Scope

  1. The provisions in this policy apply to all offices, business, operating, and functional units within the IRS, external trading partners, as well as vendors with contractual arrangements with IRS, and are to be applied when information technology is used to accomplish the IRS mission. This policy also applies to individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate information technology systems containing IRS data.

    Note:

    Any approved exceptions to this policy in the outsourced operations shall be defined within the terms of the contract.

  2. This policy governs all IRS information systems.

  3. This policy applies to security-related patches for both software products and operating systems. Non-security-related patches are system and application-dependent and are not covered by this IRM.

10.8.50.1.3  (08-15-2012)
IRM Section Topics

  1. This IRM contains information on the following subjects:

    • Authority;

    • General Policy;

    • Management Controls;

    • Operational Controls;

    • Technical Controls;

    • Risk Based Decisions;

    • Sample IRS CSIRC Security Patch Advisory (see Exhibit 10.8.50-1);

    • CSIRC Vulnerability Ranking Matrix (see Exhibit 10.8.50-2);

    • Security Notifications (see Exhibit 10.8.50-3);

    • Acronyms (see Exhibit 10.8.50-4);

    • Glossary (see Exhibit 10.8.50-5);

    • References (see Exhibit 10.8.50-6).

10.8.50.1.4  (08-15-2012)
Authority

  1. IRM 10.8.1,Information Technology (IT) Security, Policy, and Guidance, establishes the security program and the policy framework for the IRS.

  2. This IRM is to neither contradict nor alter the meaning of requirements stated in IRM 10.8.1. In the event there is a discrepancy between this policy and IRM 10.8.1, IRM 10.8.1 has precedence unless specifically noted otherwise.

10.8.50.2  (08-15-2012)
General Policy

  1. In accordance with Treasury Directive Publication (TD P) 85-01 Vol I, Treasury Information Technology Security Program, Unclassified (Non-National Security Systems), the IRS Security Patch Management Program shall:

    1. Ensure patches are controlled as programs progress through testing to final approval;

    2. Ensure test plan standards have been developed for all levels of testing that define responsibilities for each party (e.g., users, system analysts, programmers, auditors, quality assurance, library control);

    3. Ensure detailed system specifications are prepared by the programmer and reviewed by a programming supervisor;

    4. Ensure patch test plans are documented and approved defining responsibilities for each party involved (e.g., users, systems analysts, programmers, auditors, quality assurance, library control);

    5. Ensure unit, integration, and system patch testing are performed and approved in accordance with the test plan and applying a sufficient range of valid and invalid conditions;

    6. Ensure a comprehensive set of patch test transactions and data is developed representing the various activities and conditions that will be encountered in processing;

    7. Ensure live data is not used in patch testing of program changes, except to build patch test data files.

  2. Procedures for evaluating, approving, and installing security patches shall be in place to ensure that the patches are installed in a timely manner and in conformance with appropriate configuration management plans, as specified in IRM 10.8.1.

10.8.50.2.1  (08-15-2012)
Roles and Responsibilities

  1. IRM 10.8.2,Information Technology (IT) Security, IT Security Roles and Responsibilities, defines service-wide roles and responsibilities related to IRS information and computer security, and is the authoritative source for such information.

  2. Due to criticality of Patch Management process, a collaboration between multiple Business Units and Information System Owners is required. Stakeholders responsible for Patch Management operations process shall:

    1. Establish a formal operational agreement (e.g. Service-Level Agreement (SLA), Memo of Understanding (MOU), Concept of Operations (CONOPS), etc.) The agreement shall be updated annually;

    2. Develop and implement Standard Operating Procedures (SOPs) on Patch Management, which shall designate responsible organizations for carrying out each task. The SOPs shall be updated annually.

    .

  3. The following roles and responsibilities specifically apply to security patch management.

10.8.50.2.1.1  (08-15-2012)
IRS Patch and Vulnerability Group (PVG)

  1. In accordance with NIST 800-40, Creating a Patch and Vulnerability Management Program, organizations should create a PVG to facilitate the identification and distribution of patches within the organization.

  2. The following PVG functions shall be performed by the designated IRS Information Technology (IT) organization responsible for management and operations of the IRS's information technology resources.

  3. The duties of IRS PVG shall include:

    1. Inventory the organization’s IT resources to determine which hardware equipment, operating systems, and software applications are used within the organization;

    2. Monitor security sources for vulnerability announcements, patch and non-patch remediations, and emerging threats that correspond to the software within the PVG’s system inventory;

    3. Prioritize the order in which the organization addresses remediating vulnerabilities;

    4. Create a database of remediations that need to be applied organization-wide;

    5. Conduct testing of patches and non-patch remediations on IT devices that use standardized configurations;

    6. Oversee vulnerability remediation;

    7. Distribute vulnerability and remediation information to local administrators;

    8. Perform automated deployment of patches to IT devices using enterprise patch management tools;

    9. Configure automatic update of applications whenever possible and appropriate;

    10. Verify vulnerability remediation through network and host vulnerability scanning; and

    11. Train administrators to apply vulnerability remediations.

  4. PVG shall communicate any impact to businesses thru the IRS Information Technology organization's Security PMO.

  5. PVG members shall sign up for an E-mail distribution list to receive CSIRC's notifications and advisories.

10.8.50.2.1.2  (08-15-2012)
Information System Owner

  1. The Information System Owner is the agency official responsible for the overall procurement, development, integration, modification, and operation and maintenance of the information system. At the IRS, the Information System Owner is the Business and Functional Unit Owner.

  2. Appropriate Authorizing Official shall approve new patch management technologies and services based on the assessment of risk. Refer to IRM 10.8.1 for ELC and Business Impact Analysis guidance.

  3. In accordance with NIST 800-40:

    1. Business and Functional Unit Owner's shall acknowledge receipt of the advisories per the Acknowledgment of Receipt schedule. Refer to the Security Patch Advisory Acknowledgement of Receipt section of this IRM for schedule details;

    2. In the event an applicable patch is not applied, the Business and Functional Unit Owner shall document this occurrence in a Plan of Action and Milestones (POA&M) associated with the Security Assessment and Authorization (SA&A) package;

    3. Business and Functional Unit Owners shall be represented on the PVG.

    4. Refer to IRM 10.8.2, for additional guidance.

10.8.50.2.1.2.1  (08-15-2012)
IRS Information Technology (IT) Organization and other Business Functional Unit Owners

  1. IRS Information Technology (IT) organization and other Business and Functional Unit Owners, that maintain systems, network, IRS applications and COTS shall:

    1. Develop implementation policies and procedures for managing security patches to the systems and applications for which they are responsible;

    2. Review various sources for security-related patches specific to their systems and applications;

    3. Notify CSIRC prior to the working on each set of their pending patch activities;

    4. Maintain hardware/software inventories;

    5. Coordinate their patch activities with the Business and Functional Unit Owners and the CSIRC;

    6. IRS Information Technology (IT) organization and Business Functional Unit Owners shall be represented on the PVG.

10.8.50.2.1.3  (08-15-2012)
IRS Information Technology (IT) organization Cybersecurity Computer Security Incident Response Center (CSIRC)

  1. The IRS Information Technology (IT) organization's CSIRC shall assist Information System Owners and other patch management stakeholders in defining relevant patches, prompting their implementation, and reporting their disposition.

  2. In accordance with TD P 85-01 and IRM 10.8.1 the CSIRC shall:

    1. Publish vulnerability alerts, advisories, and bulletins on the CSIRC web site, http://www.csirc.web.irs.gov, to be used by Information System Owners and other patch management stakeholders. See Exhibit 10.8.50-1 for a sample advisory;

      Note:

      Advisories published by CSIRC are not the all-inclusive authoritative source for vulnerabilities and patches. The advisories shall be used by Information System Owners in collaboration with advisories from product vendors, Department of Homeland Security, and other relevant sources.

    2. Designate which patches are security-related patches subject to enterprise security patch management policies and procedures;

    3. Notify IRS management of critical vulnerabilities and patches to facilitate timely actions;

    4. Review various sources for security-related system and application patches;

    5. Coordinate with external (to IRS) organizations to remain current on known vulnerabilities, exploits, and patches;

    6. Provide the PVG with educational materials and information for distribution;

    7. Maintain a Security Notification Mailing List, which includes the e-mail addresses of all PVG members and other designated personnel;

    8. Assign a criticality level and associate an implementation schedule with each advisory;

    9. Follow the procedures in this policy for advisory processing; and

    10. Send approved advisories as e-mail messages to the PVG members. The e-mail subject line of an advisory shall contain, IRS Patch Advisory <Advisory Number> <Alert Level> <Color Code> <Title>.

10.8.50.2.1.4  (08-15-2012)
Information Systems Security Officer (ISSO)

  1. ISSO roles shall be determined as needed to support Patch Management operational processes by ACIO of Cybersecurity and applicable Authorizing Official.

10.8.50.3  (08-15-2012)
Management Controls

  1. Management controls focus on the management of risk for an application or system and the management of computer security controls to mitigate that risk. Refer to IRM 10.8.1 for general information and computer security management control requirements.

10.8.50.3.1  (08-15-2012)
10.8.50.3.1 IRS Security Patch Management Approach

  1. The IRS’s approach to security patch management through the implementation of management controls consists of four (4) phases (as described below):

    • Assess

    • Identify

    • Evaluate and Plan

    • Deploy

10.8.50.3.1.1  (08-15-2012)
Assess Phase

  1. During the Assess phase, the IRS shall:

    • Assess the current production environment;

    • Determine security threats and vulnerabilities; and

    • Develop a plan to implement new security patches.

10.8.50.3.1.2  (08-15-2012)
Identify Phase

  1. During the Identify phase, the IRS shall:

    • Identify new security patch updates in a reliable way;

    • Determine if the security patch updates are relevant to the production environment; and

    • Determine the urgency of the security patch update.

10.8.50.3.1.3  (08-15-2012)
Evaluate and Plan Phase

  1. During the Evaluate and Plan phase, the IRS shall:

    • Evaluate security patches to determine the implication of an implementation;

    • Develop a strategy to deploy security patches; and

    • Test patches in a test environment prior to moving security patches into the production environment to ensure the security patch does not compromise business critical systems and applications.

10.8.50.3.1.4  (08-15-2012)
Deploy Phase

  1. During the Deploy phase, the IRS shall:

    • Deploy the approved security patches into the production environment.

10.8.50.4  (08-15-2012)
Operational Controls

  1. Operational controls address security mechanisms that primarily are implemented and executed by individuals as opposed to systems. They often require technical or specialized expertise and rely on management activities as well as technical controls. See IRM 10.8.1, for general information and computer security operational control requirements.

  2. Operational controls are detailed through the following steps – security patch implementation policy and procedures, assign severity levels, preparation of security patch advisories, security patch advisory acknowledgment of receipt, and patch processing metrics. The following sections define the requirements for the patch management process.

10.8.50.4.1  (08-15-2012)
Security Patch Implementation Policy and Procedures

  1. IRS Information Technology (IT) organization or the appropriate Information System Owner shall:

    1. Document formal security patch implementation change requests in accordance with the Configuration Management process;

    2. Implement security patches automatically and/or manually;

    3. Implement security patches in a timely manner for all systems and applications within the owner’s control;

    4. Identify resources that cannot be patched from a central location;

    5. Provide a prioritization scheme for systems and applications (i.e., making a distinction between servers and end-user systems when servers are often of higher priority);

    6. Ensure security patches are tested before distribution;

    7. Integrate security patch processes with relevant configuration management policies and procedures; and

    8. Ensure tracking mechanism captures compliance and non-compliance to meet system security requirements and latest patching requirements. Reporting requirements include (but are not limited to) providing information reported during the daily Leadership Review and Federal Information Security Management Act of 2002 (FISMA) metrics.

  2. Security patch management procedures shall:

    1. Implement security patches in accordance with IRS Security Patch Advisories.

    2. Identify vulnerabilities and security patches associated with systems and applications not monitored by CSIRC; and

    3. Provide CSIRC with updates on any additional identified vulnerabilities for further assessment, in accordance with PVG governance board’s established procedures.

10.8.50.4.2  (08-15-2012)
Assign Severity Levels

  1. Information System Owner shall collaborate with ISSM/ISSO to complete in-depth vulnerability analysis focusing on the precise versions of applications or operating systems affected to validate its applicability to IRS systems environment.

    Note:

    Due to the large volume of vulnerabilities that create risks to IRS systems and networks, it is necessary to prioritize vulnerabilities, assigning criticality levels to ensure security patches associated with the vulnerabilities can be installed effectively.

  2. All vulnerabilities shall be assigned a criticality ranking based on a specific criteria and formula. See the "CSIRC Vulnerability Ranking Matrix" in the Exhibits section for the criteria and formula.

  3. TD P 85-01 requires that agencies test and install security patches on a timeline in accordance with the criticality of the patches.

  4. The following table provides the distribution schedule based on the criticality ranking:

    Code Priority Time to Implement
    Red Critical Distribution shall begin within 72 hours of patch availability.
    Orange High Distribution shall begin within 5 business days of patch availability.
    Yellow Medium Distribution shall begin within 30 calendar days of patch availability.
    Green Low Distribution shall begin within 90 calendar days of patch availability.

10.8.50.4.3  (08-15-2012)
Preparation of Security Patch Advisories

  1. The CSIRC shall prepare and send out security patch advisories.

  2. Security patch advisories shall include (as information is available):

    • A unique identifier;

    • A unique title;

    • Which computer or network systems are affected;

    • Version numbers for all affected software;

    • A description of the vulnerability and how it might be exploited;

    • A description of the solution and how it works;

    • A link to the corrective patch;

    • A color coded severity level, and

    • Instructions for what to do if assistance is required.

  3. In situations where the security patch documented in the original advisory adversely impacts a system or application, the CSIRC shall provide an updated advisory when a fix is provided by the vendor.

10.8.50.4.4  (08-15-2012)
Security Patch Advisory Acknowledgement of Receipt

  1. Point of Contacts (POCs) receiving an advisory shall provide acknowledgment of receipt to the PVG, depending on severity, using the following schedule:

    Color Priority Acknowledgement Timeframe
    Red Critical 1 Hour
    Orange High 2 Hours
    Yellow Medium 24 Hours
    Green Low None

  2. Each organizational POC shall disseminate the security patch advisory to responsible representatives or system administrators for testing and implementation.

    1. If testing is successful, each organization shall implement the new patch.

    2. If testing fails, the POC shall provide the details to the PVG.

    3. If no patch is available for a given security vulnerability, each PVG POC shall be notified to ensure the organization can implement appropriate risk mitigation controls.

10.8.50.4.5  (08-15-2012)
Patch Processing Metrics

  1. The PVG shall identify the program metrics that will help manage the strengths and weaknesses, as well as trends in the IRS’ patch management program and security posture of the Enterprise, and means of delivering these metrics.

  2. Cybersecurity shall collect metrics data via the PVG for the following purposes:

    • Annual FISMA Reporting,

    • Quarterly reports for senior leadership,

    • Treasury data calls

    • IRS Information Technology (IT) organization's Internal Dashboard, and

    • Ad-hoc reporting.

  3. Metrics data shall include, but not limited to:

    1. Number of security vulnerabilities identified;

    2. Number of alerts, bulletins, and advisories published per application and operating system;

    3. Total number of systems impacted by individual vulnerabilities by organization, activity, or business unit per advisory;

    4. Total number of systems successfully patched by organization, activity, or business unit per advisory;

    5. Total number of systems that failed to receive the patch during patch deployment by organization, activity, or business unit per advisory; and

    6. Total number of systems pending patch deployment by organization, activity, or business unit per advisory.

10.8.50.5  (08-15-2012)
Technical Controls

  1. Technical controls focus on the security controls that the computer system executes. These controls provide automated protection from unauthorized access or misuse, facilitate detection of security violations, and support security requirements for the systems or applications. The implementation of technical controls shall be consistent with the management of security within the organization. See IRM 10.8.1 for general information and computer security technical control requirements.

  2. The IRS shall ensure that security patches address IT vulnerabilities to prevent exploitation. At a minimum security controls must provide automated protection from unauthorized access or misuse, facilitate detection of security violations, and support security requirements for systems and applications. The implementation of technical controls shall be consistent with the management of security within the IRS.

10.8.50.5.1  (08-15-2012)
IRS Security Patch Management Approach

  1. The IRS’s approach to security patch management through the implementation of technical controls consists of five (5) phases (as described below):

    • Assess

    • Identify

    • Evaluate and Plan

    • Deploy

    • Next Steps

10.8.50.5.1.1  (08-15-2012)
Assess Phase

  1. During the Assess phase, the IRS shall:

    1. Determine the threats to, and vulnerabilities of, the production environment;

    2. Identify business-critical assets;

    3. Determine which systems and applications are in the production environment;

    4. Determine which systems and applications can automatically receive security patches and require manual installation;

    5. Ensure that security patch distribution tools are configured, maintained, and able to support normal and emergency security patch installations; and

    6. Ensure that technical personnel have assigned roles and responsibilities and that they know how to deal with the security patch update and how to mitigate its impact.

10.8.50.5.1.2  (08-15-2012)
Identify Phase

  1. During the Identify phase, the IRS shall:

    1. Ensure that a mechanism is available to be notified of all security patch updates;

    2. Confirm that the security patch update notification comes from an authorized source;

    3. Ensure that the security patch update is relevant to systems in the IRS production environment;

    4. Obtain the security patch update source files and confirm that they are virus free;

    5. Ensure that the security patch update installation is successful;

    6. Determine whether the patch update is an emergency and submit an Request for Change (RFC) to deploy it into production; and

    7. Ensure the receipt and verification of relevant security patch updates are safe to deploy.

10.8.50.5.1.3  (08-15-2012)
Evaluate and Plan Phase

  1. During the Evaluate and Plan phase, the IRS shall:

    1. Ensure a formal process to determine whether it is in the best interests of the agency to deploy the security patch updates;

    2. Determine owner of the security patch updates who will be responsible for ensuring that it is deployed.

    3. Implement approved security patch updates and develop a systemic approach for rolling out the patch to the production environment; and

    4. Test security patches in a lab and, if needed, pilot test it in a production environment to confirm that it does not compromise systems or applications.

10.8.50.5.1.4  (08-15-2012)
Deploy Phase

  1. During the Deploy phase, the IRS shall:

    1. Establish the order in which the security patch updates will be rolled out into production;

    2. Survey the production environment to ensure the system or application will handle the security patch updates;

    3. Deploy security patch updates into the production environment;

    4. Rescan the environment to assess success, and patch any computers that failed to install the security patch updates; and

    5. Perform a review of the security patch management process once the deployment is complete.

10.8.50.5.1.5  (08-15-2012)
Next Steps Phase

  1. Once IRS personnel have deployed the security patch update, the IRS shall:

    1. Inventory/discover existing computing assets;

    2. Assess security threats and vulnerabilities;

    3. Determine the best source for information about patch updates;

    4. Assess the existing software distribution infrastructure; and

    5. Assess operational effectiveness.

10.8.50.5.2  (08-15-2012)
Software Inventory

  1. Software inventory and baseline configurations shall be maintained in accordance with IRM 10.8.1

  2. At a minimum, the inventory shall contain:

    • operating systems;

    • versions of all software;

    • patch levels; and

    • installed applications.

  3. The inventory shall be updated as software is added or deleted from the baseline.

  4. Changes to the baseline shall be documented in a timely manner.

  5. The baseline inventory shall be managed by version control to provide a record of changes over time.

10.8.50.6  (08-15-2012)
Risk Based Decisions

  1. An exception to this policy requires that the Authorizing Official (AO) make a Risk Based Decision.

  2. Risk Based Decision requests shall be submitted in accordance with IRM 10.8.1, as described in Request for Risk Acceptance and Risk Based Decision Standard Operating Procedures (SOPs).

  3. Refer to IRM 10.8.1 for additional risk acceptance guidance.

Exhibit 10.8.50-1 
Sample IRS CSIRC Security Patch Advisory

IRS CSIRC Advisory - 05082012-009-Critical (Red) Adobe Shockwave Player Multiple Memory Corruption Flaws Vulnerabilities

  1. Vulnerability
    The CSIRC has been made aware of multiple vulnerabilities in Adobe Shockwave Player. A remote attacker could cause the arbitrary code to be executed on the target user’s system.

  2. Severity
    The CSIRC considers this to be a critical risk. Exploitation of these vulnerabilities could result in the execution of arbitrary code and/or user access via network.

  3. Systems Affected
    Operating Systems:

    • Windows (Any)

    • Unix (OS X)


    Applications:

    • Shockwave 11.6.3.634 and prior

  4. CSIRC Distribution

    • &&CSIRC-Tier 2 Advisory Distribution

    • &&CSIRC-Tier 3Advisory Distribution

    • &&CSIRC-MAC Advisory Distribution

    • &&CSIRC-Critical Advisory Distribution

  5. Technical Description
    According to a report received by CSIRC, multiple vulnerabilities were reported in Adobe Shockwave Player. A remote attacker could cause arbitrary code to be executed on the target user's system. A remote attacker could create specially crafted Shockwave content that, when loaded by the target user will trigger a memory corruption error and execute arbitrary code on the target system. The code will run with the privileges of the target user.

  6. Solution
    Update to version 11.6.5.635 http://get.adobe.com/shockwave/

  7. References
    CVE: CVE-2012-2029, CVE-2012-2030, CVE-2012-2031, CVE-2012-2032, CVE-2012-2033
    Vendor: http://www.adobe.com/support/security/bulletins/apsb12-13.html

  8. Notes
    Business units and individuals responsible for patching affected systems must provide the CSIRC the total number of systems affected and the number of systems patched. This information must be provided on a daily basis until all affected systems are patched. CSIRC does not endorse the application of any referenced patch without the proper testing in its applicable environment. CSIRC urges administrators of systems for which a fix is not yet available to routinely check for patch availability.

Exhibit 10.8.50-2 
CSIRC Vulnerability Ranking Matrix

The advisory criticality rating assigned to each advisory is calculated based on a vulnerability metric calculation derived from the seven questions listed in the CSIRC Vulnerability Ranking Matrix. The seven questions assess the vulnerability based on three key characteristics:

  • Threat -An activity with the potential of causing harm to a computer system or network.

  • Exposure -A flaw, misconfiguration, or weakness that allows the violation of security.

  • Severity -A measure of how important or valuable a system is to the organization’s mission.

The formulas for calculating an advisory rating and its associated color code are:

  • Threat =cubed root of (Q1 * Q2 * Q3) where Q1, Q2, etc. receive assigned rating values based on the CSIRC Vulnerability Ranking Matrix table that follows.

  • Severity =square root of (Q4 * Q5)

  • Exposure =square root of (Q6 * Q7)

  • Advisory Rating =Threat * Severity * Exposure

The resulting calculations produce a value ranging from 0 to 1000. See the CSIRC Vulnerability Ranking Matrix to determine the value associated with each question (e.g., Q1, Q2, etc.). Then see the Advisory Security Rating table to establish the rating and color code for an advisory based on the final calculation, Advisory Rating, compared to the rating ranges in the Rating table. In both tables, below, one (1) is lowest and ten (10) is highest.

CSIRC Vulnerability Ranking Matrix
Question Risk Category Rating
1. Is the vulnerability widely known? Only IRS and the vendor know 1
Only a few individuals are aware 2
Solutions are publicly available 3
General concept of the vulnerability is public 5
Public, major security lists are on the web 8
Exploit code is publicly available 10
2. Is exploitation of the vulnerability being reported? No exploit reports received 1
Exploit report from a single unofficial non-government source 3
Exploit reports from multiple unofficial sources 5
Exploit report from a single trusted security industry source 7
Exploit reports from multiple trusted security industry sources 9
Exploit detected internally in the IRS Enterprise 10
3. Is the Internet infrastructure at risk? Must convince a System Administrator to take a specific action 1
Must convince a System User to take a specific action 2
Need assembler/protocol expertise 3
Must create a custom IP packet 4
Attackers can customize a toolkit 5
Attackers can use plausible-sounding social engineering 6
Instructions are available as a complex set of commands 7
Instructions are available as 1-2 simple commands 9
Publicly available Graphic User Interface (GUI) toolkit 10
4. What is the number of systems at risk? Vulnerable application not on the IRS network 0
Obscure application or service in Enterprise vulnerable 2
Default Linux/UNIX (non-Solaris) configuration vulnerable 3
Default Solaris configuration vulnerable 5
Common internal service vulnerable (Web, FTP, NetBIOS, Tivoli, etc.) 6
Major internal service vulnerable (DNS, routers, PDC/BDC, Exchange, etc.) 7
Default Windows configuration vulnerable 8
COE image configuration vulnerable 9
Public-access service vulnerable (Web Servers, FTP Servers, SMTP, etc.) 10
5. What is the impact? Minimal impact 1
Annoyance to users 2
Degraded system performance 3
Temporary denial of service on systems accessed only by internal users 7
Temporary denial of service on systems accessed by the public 8
Service-wide downtime required to contain and recover systems 9
Compromise or destruction of data 10
6. How many systems are vulnerable? None 0
1 to 4 1
5 to 19 2
20 to 49 4
50 to 99 6
100 to 999 9
1000 or more 10
7. What is the access level required to exploit the vulnerability? Must have privileged access 1
Another trusted host is required 3
Local access to a user account is required 5
Another nearby host is required (i.e., on the same subnet) 7
None required. Any remote user accessing network services or protocols (e.g., SQL (Structured Query Language), HTTP (Hypertext Transfer Protocol), etc.) that are not vendor default or are not IRS standard 9
None required. Any remote user accessing network services or protocols (e.g., telnet, NetBIOS, etc.) that are vendor default or are IRS standard 10

Advisory Security Rating
Rating Color Code Value Range
None None 0
Low Green 1 to 99
Medium Yellow 100 to 199
High Orange 200 to 499
Critical Red 500 to 1000

Exhibit 10.8.50-3 
Security Notifications

As new threats emerge and vulnerabilities are discovered, CSIRC provides security notifications to the enterprise using advisories. These advisories contain one of three levels of warning:

Warning Description
Alerts The highest level of warning. Address a major threat or incident information concerning imminent or in-progress attacks targeting specific national networks, critical infrastructures or the IRS enterprise.
Advisories Address significant threat or incident information that suggests a change in readiness posture, protective options, and/or response.
Bulletins The lowest level of warning. Address general incidents or issue awareness information and analysis that are significant and current, but that do not necessarily suggest immediate action.

The CSIRC employs a vulnerability metric to assign a severity rating and distribution schedule to each advisory using the following scale:

Criticality Level Distribution Schedule
Red (Critical) Patch availability and distribution begins within 72 hours.
Orange (High) Patch availability and distribution begins within 5 business days.
Yellow (Medium) Patch availability and distribution begins within 30 calendar days.
Green (Low) Patch availability and distribution begins within 90 calendar days.

Advisory Distribution Mailing Lists:
The CSIRC maintains distribution lists for each Advisory category listed below. Please complete the Subscription Form, available for download on the CSIRC web site, if you wish to join or leave any of the Advisory Distribution Lists.

  • &&CSIRC-Tier 1 Advisory Distribution - IBM and Unisys Mainframes (e.g., IDRS, SACS, terminal controllers, other resources, etc.)

  • &&CSIRC-Tier 2 Advisory Distribution -Mid-range servers (e.g., UNIX, Linux, Wintel domain servers and other Wintel resource servers, etc.).

  • &&CSIRC-Tier 3 Advisory Distribution -Wintel workstations (e.g., desktops, laptops, and local area network resources, etc.).

  • &&CSIRC-Tier 4 Advisory Distribution -Voice and data telecommunication resources (e.g., Public Branch Exchanges (PBXs), routers, switches, domain name server, etc.)

  • &&CSIRC-Linux Advisory Distribution -LINUX without UNIX.

  • &&CSIRC-Web Advisory Distribution -All the web environments (i.e., Intranet and Internet).

  • &&CSIRC-Critical Advisory Distribution -Executive management for ensuring that vulnerabilities with a severity rating of "Critical" are prioritized accordingly.

Exhibit 10.8.50-4 
Acronyms

Acronyms
AO Authorizing Official
CONOPS Concept of Operations
COTS Commercial Off-the-shelf
CSIRC IRS Computer Security Incident Response Center
ELC Enterprise Life Cycle
EOps Enterprise Operations
EUES End User Equipment and Services Division
FISMA Federal Information Security Management Act of 2002
IRM Internal Revenue Manual
IRS Internal Revenue Service
IT Information Technology
MITS Modernization Information Technology Services
MOU Memorandum of Understanding
NIST National Institute of Standards and Technology
POA&M Plan of Action and Milestones
POC Point of Contact
PVG Patch and Vulnerabilities Group
RFC Request for Change
SA&A Security Assessment and Authorization
SLA Service-level Agreement
SOP Standard Operating Procedure
SP Special Publication
TD P Treasury Directive Publication

Exhibit 10.8.50-5 
Glossary

This table contains the significant patch management terms and their definitions.

Glossary
Application Any data entry, update, query, report, or program that processes data for the user. It includes not only the generic productivity software (spreadsheets, word processors, database programs, etc.) but also custom and packaged programs for payroll, billing, inventory, and other accounting purposes.
Advisories The CSIRC communication for a patch. These advisories include vendor information about their alerts, and their own vendor advisories. For purposes of this IRM, advisories only relate to the CSIRC patch communications.
Host A computer that acts as a source of information or signals. The term can refer to almost any kind of computer, from a centralized mainframe that is a host to its terminals, to a server that is host to its clients, to a desktop personal computer (PC) that is host to its peripherals. In network architectures, a client station (user's machine) is also considered a host because it is a source of information to the network in contrast to a device such as a router or switch that directs traffic.
Hotfix A hotfix is a single, cumulative package that includes one or more files that are used to address a problem in a product. Hotfixes address a specific customer situation and may not be distributed outside the customer organization.
Patch A patch is a small file that when executed will patch or fix specific problems in a target file or application. The benefit of a patch is that it is smaller in size than a full software update, and saves the user from downloading redundant, previously functioning files. The limitation of patching is that the process is often version-specific. In other words, the patch is targeted to work only if the user has a particular version installed.
For purposes of this policy, hotfixes, patches, service packs, workarounds and other related corrections and updates to systems and applications will be termed, "patch(es)." This policy is only concerned with security-related patches.
Service Pack A Service Pack (more commonly, SP) is a software program that corrects known bugs, problems, or adds new features. Companies that produce large applications (e.g., Microsoft Windows XP®) typically release a service pack when the number of individual patches to the application becomes too large. Service Packs are easier to install than groups of patches, especially with multiple computers that need to be updated over a network.
System See host.
Vulnerability Flaw or weakness in an information system's design, implementation, or operation and management that could potentially be exploited by a threat to gain unauthorized access to information, disrupt critical processing, or otherwise violate the system's security policy.
WebDAV Web-based Distributed Authoring and Versioning, WebDAV is a platform-independent extension of HTTP that allows users to collaborate and manage files on Web servers.

Exhibit 10.8.50-6 
References

IRM 10.8.1 - Information Technology (IT) Security, Policy and Guidance, November 25, 2011

IRM 10.8.2 - Information Technology (IT) Security, IT Security Roles and Responsibilities, April 29, 2011

NIST SP 800-40 - Creating a Patch and Vulnerability Management Program, November 2005

TD P 85-01 Vol I (v.2.2.6) - Treasury Information Technology Security Program, Unclassified (Non-National Security Systems), June 8, 2011

The E-Government Act of 2002 (P.L. 107-347) Title III, Federal Information Security Management Act of 2002 (FISMA)


More Internal Revenue Manual