Part 10. Security, Privacy and Assurance

Chapter 8. Information Technology (IT) Security

Section 50. Servicewide Security Patch Management

10.8.50 Servicewide Security Patch Management

Manual Transmittal

November 25, 2020

Purpose

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

Material Changes

(1) The following sections have been updated/clarified with this version of policy:

  1. Interim Guidance Memoranda # IT-10-0919-0020 Internet Accessible System Remediation Timelines, dated January 1, 2020 updates the security patch installation timeline, IRM 10.8.50.3, IRM 10 8.50.3.1(2), Exhibit 10.8.50-3 Security Notifications vulnerability metric.

  2. Restructured Manual Transmittal, introductory sections, and the Risk Acceptance and Risk-Based Decisions section, as well as the Exhibits, including the Glossary and Acronyms (now combined) to match standardized Security Policy language.

  3. Updated links throughout the document to reflect new organizational links.

  4. Updated Exhibit 10.8.50-4 References: Glossary and Acronyms List: Added Six additional glossary terms for clarity of document.

  5. Updated Exhibit 10.8.50-5 References: Various references updated including TD P 85-01 to reflect current policy guidelines.

(2) Editorial changes (including grammar, spelling, URL updates and minor clarification) were made throughout this IRM.

Effect on Other Documents

This IRM supersedes all prior versions of IRM 10.8.50, Servicewide Security Patch Management dated July 01, 2019. Additionally, this IRM was updated to incorporate Interim Guidance Memoranda # IT-10-0919-0020. This IRM supplements IRM 10.8.1, Information Technology (IT) Security Policy and Guidance; IRM 10.8.2, Information Technology Security Roles and Responsibilities

Audience

The provisions in this manual apply to:
a) All offices and business, operating, and functional units within the IRS.
b) Individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate information systems that store, process, or transmit IRS Information or connect to an IRS network or system.
c) All IRS information and information systems. For information systems that store, process, or transmit classified information, please refer to IRM 10.9.1, National Security Information, for additional procedures for protecting classified information.

Effective Date

(11-25-2020)

Nancy Sieger
Acting Chief Information Officer

10.8.50.1 (07-01-2019)

Program Scope and Objectives

  1. Overview: This IRM lays the foundation to implement and manage security for security patch management within the Internal Revenue Service (IRS).

  2. Purpose of the program: Develop and publish policies to protect the IRS against potential IT threats and vulnerabilities and ensure compliance with federal mandates and legislation.

  3. Audience: The provisions in this manual apply to:

    1. All offices and business, operating, and functional units within the IRS.

    2. Individuals and organizations having contractual arrangements with the IRS, including employees, contractors, vendors, and outsourcing providers, which use or operate information systems that store, process, or transmit IRS Information or connect to an IRS network or system.

    3. All IRS information and information systems. For information systems that store, process, or transmit classified information, please refer to IRM 10.9.1 , National Security Information, for additional procedures for protecting classified information.

  4. Policy Owner: Chief Information Officer.

  5. Program Owner: Architecture and Implementation, an organization within Cybersecurity.

  6. Program Goals: Cybersecurity Policy is responsible for the development and maintenance of IRS’s enterprise information technology security policies. The IRM 10.8.X Series provides the minimum-security requirements to protect the confidentiality, integrity, and availability of data processed on IRS systems. IRMs are developed in accordance with applicable laws, policies, federal regulations, Office of Management and Budget (OMB), Treasury Directives (TDs), National Institute of Standards and Technology (NIST) Publications, and National Archives and Records Administration.

10.8.50.1.1 (07-01-2019)

Background

  1. This IRM defines the security patch management process to ensure the timely implementation of security patches for all Internal Revenue Service (IRS) computers, networks, Commercial Off-The-Shelf (COTS) software, and IRS developed applications and software.

    1. This document describes the internal policy 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 dependent; therefore, are not covered by this policy. This policy 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.

  2. IRM 10.8.50 is part of the Security, Privacy and Assurance policy family, IRM Part 10 series for IRS Information Technology Cybersecurity.

  3. FIPS 200 mandates the use of NIST Special Publication (SP) 800-53 as an initial set of baseline security controls for the creation of agency IT Security policy.

10.8.50.1.1.1 (07-01-2019)
Scope

  1. This IRM covers all security related patch management for all IRS information systems.

  2. The IRS shall ensure that the product (e.g., software, hardware) and version selected is in accordance with IRS Enterprise Architecture (EA) Enterprise Standards Profile (ESP) that dictates the official products and versions within the IRS.

  3. The IRS shall ensure the application or system version is a version for which the vendor still offers standardized technical support.

  4. In the event there is a discrepancy between this policy and IRM 10.8.1, IRM 10.8.1 has precedence, unless the security controls/requirements in this policy are more restrictive or otherwise noted.

10.8.50.1.1.2 (07-01-2019)
Objectives

  1. This IRM establishes the minimum baseline security policy and requirements for all IRS Information Technology (IT) assets to:

    1. Protect the critical infrastructure and assets of the IRS against attacks that exploit IRS assets.

    2. Prevent unauthorized access to IRS assets.

    3. Enable IRS IT computing environments that meet the security requirements of this policy and support the business needs of the organization.

  2. It is acceptable to configure settings to be more restrictive than those defined in this IRM.

  3. To configure less restrictive controls requires a risk-based decision. See the Risk Acceptance and Risk-Based Decisions (RBD) section within this IRM for additional guidance.

10.8.50.1.2 (04-30-2014)

Authority

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

10.8.50.1.3 (11-25-2020)

Risk Acceptance and Risk-Based Decisions

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

  2. Users shall:

    1. Submit Risk-Based Decision requests in accordance with IRM 10.8.1; and

    2. Use Form 14201, as described in Risk Acceptance and Risk-Based Decision (RBD) Standard Operating Procedures (SOP).

      Note:

      ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

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

10.8.50.2 (07-01-2019)

Roles and Responsibilities

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

  2. The supplemental roles and responsibilities provided below are specific to the implementation of security patch management.

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

    1. Provide oversight of the patch management process including distribution and installation of patches.

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

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

10.8.50.2.1 (04-26-2016)

IRS Patch and Vulnerability Group (PVG)

  1. In accordance with NIST SP 800-40 , organizations shall create a PVG to facilitate the identification and distribution of patches within the organization.

    Note:

    This group may be an independent entity, or its duties may be performed by existing group(s) (e.g. Configuration Control Boards).

  2. The following functions shall be performed by the designated IRS IT organization responsible for management and operations of the IRS IT 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 remediation, and emerging threats that correspond to the software within the 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 remediation on IT devices that use standardized configuration.

    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.

    11. Train administrators to apply vulnerability remediation.

  4. The PVG (or similar entity) shall communicate any impact to businesses through the IRS Security Project Management Office (PMO).

  5. Members of groups or boards with patch management oversight responsibilities shall sign up for an E-mail distribution list to receive Computer Security Incident Response Center’s (CSIRC) notifications and advisories.

10.8.50.2.2 (04-26-2016)

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 Enterprise Life Cycle (ELC) and Business Impact Analysis guidance. Refer to PM-5 Information System Inventory and PM-8 Critical Infrastructure Plan.

  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 or other entity.

    4. Refer to IRM 10.8.2, for additional guidance.

10.8.50.2.3 (11-25-2020)

IRS Information Technology (IT) Organization and other Business Functional Unit Owners

  1. IRS 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 working on each set of their pending patch activities.

    4. Maintain hardware/software inventories.

    5. Coordinate their patch activities with other Information System Owners.

  2. Business and Functional Unit Owners shall be represented on the PVG (or other entity).

10.8.50.2.4 (04-26-2016)

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 CSIRC shall:

    1. Publish vulnerability alerts, advisories, and bulletins on the CSIRC web site, 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 educational materials and information for distribution.

    7. Maintain a Security Notification Mailing List, which includes the e-mail addresses of all designated personnel with patch management responsibilities.

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

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

    10. Send approved advisories as e-mail messages to the PVG. The e-mail subject line of an advisory shall contain, IRS Patch Advisory <Advisory Number> <Alert Level> <Color Code> <Title>. See Section 10.8.50.4.2 Assigned Severity Levels within this IRM for additional information.

    Note:

    This group may be an independent entity, or its duties may be performed by existing group(s) (e.g. Configuration Control Boards).

10.8.50.2.5 (04-26-2016)

Information Systems Security Officer

  1. Information Systems Security Officer (ISSO) roles shall be determined as needed to support Patch Management operational processes by Associate Chief Information Officer (ACIO) of Cybersecurity and applicable Authorizing Official.

10.8.50.3 (11-25-2020)

Security Patch Management

  1. Security Patch Management focuses on the management of security patches in regards to risk associated with 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.

  2. Procedures for evaluating, approving, and installing security patches shall be in place to ensure that the patches are installed within the patch severity timeframe and in conformance with appropriate configuration management plans, in accordance with IRM 10.8.1.

  3. The IRS shall develop and implement configuration, vulnerability, and patch management plans for all of IRS IT systems and networks in accordance with:

    • Department of Homeland Security (DHS) Binding Operational Directive (BOD) 19-02, Vulnerability Remediation Requirements for Internet-Accessible Systems

    • Federal Information Processing Standard Publication (FIPS) 200, Minimum Security Requirements for Federal Information and Information Systems and applicable controls listed in the following:

    • National Institute of Standards and Technology (NIST) Special Publications (SP) 800-128, Guide for Security-Focused Configuration Management of Information Systems

    • NIST SP 800-53 Rev 4, Security and Privacy Controls for Federal Information Systems and Organizations

    • NIST SP 800-70 Rev 2, National Checklist Program for IT Products-Guidelines for Checklist Users and Developers

    • NIST SP 800-40 Rev 3, Guide to Enterprise Patch Management Technologies Appendix C of TD P 85-01. (TD P 85-01 Section 3.5)

10.8.50.3.1 (11-25-2020)

IRS Security Patch Management Approach

  1. In accordance with TD P 85-01, the IRS Security Patch Management Program shall:

    1. Ensure patch development is 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, and 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, and 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.

      Note:

      See IRM 10.5.8 , Sensitive But Unclassified (SBU) Data Policy: Protecting SBU in Non-Production Environments, for additional clarification on exceptions for use of live data

  2. The IRS shall perform the following actions: (DHS: BOD 19-02)

    1. Ensure Cyber Hygiene Access and Verify Scope:
      i. Remove Cyber Hygiene source Internet Protocol (IP) addresses from block lists to ensure Cyber Hygiene scanning access;
      ii. Notify Cybersecurity and Infrastructure Security Agency (CISA) at NCATS@hq.dhs.gov within five (5) working days of any modification(s) to IRS Internet-accessible IP addresses; and

      Note:

      This includes newly acquired Internet-accessible IP addresses or reassigned Internet-accessible IP addresses that are no longer part of the agency's asset inventory.


      iii. Submit updated Cyber Hygiene agreements to NCATS@hq.dhs.gov upon request from CISA.

    2. Review and Remediate Critical and High Vulnerabilities:
      i. Review Cyber Hygiene reports issued by CISA upon receipt;
      ii. Remediate the critical and high vulnerabilities detected on IRS Internet-accessible systems; and
      -- 1. Critical vulnerabilities shall be remediated within 15 calendar days of initial detection.
      -- 2. High vulnerabilities shall be remediated within 30 calendar days of initial detection.

      Note:

      Initial detection dates for identified vulnerabilities are included within Appendix G of the Cyber Hygiene report.


      iii. Review CISA remediation plans identifying all overdue, in-scope vulnerabilities.
      -- 1. Complete the following fields within the remediation plan:
      ------ a. Vulnerability remediation constraints;
      ------ b. Interim mitigation actions to overcome constraints; and
      ------ c. Estimated completion dates to remediate the vulnerability.
      -- 2. Return completed remediation plans within three (3) days of receipt to FNR.BOD@hq.hds.gov.

      Note:

      Refer to DHS BOD 19-02 Frequently Asked Questions for guidance on resolving “false positives” of Cyber Hygiene-identified vulnerabilities.

      Note:

      For additional information about DHS BOD 19-02, refer to web site https://cyber.dhs.gov/bod/19-02/.

    3. Coordinate with the affected ACIO area to minimize impact to operations and restoration of lost capabilities. (IRS-defined)

  3. The IRS approach to security patch management shall be applied through the implementation of controls consisting of five (5) phases (as described below):

    • Assess

    • Identity

    • Evaluate and Plan

    • Deploy

    • Next Steps

10.8.50.3.1.1 (04-26-2016)
Assess Phase

  1. During the Assess phase, the IRS shall:

    1. Assess the current production environment:
      i. Identify business-critical assets
      ii. Determine which systems and applications are in the production environment

    2. Determine security threats and vulnerabilities:
      i. Determine the threats to, and vulnerabilities of, the production environment

    3. Develop a plan to implement new security patches:
      i. Determine which systems and applications can automatically receive security patches and those systems that require manual installation
      ii. Ensure that security patch distribution tools are configured, maintained, and able to support normal and emergency security patch installations

    4. 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.3.1.2 (04-26-2016)
Identify Phase

  1. During the Identify phase, the IRS shall:

    1. Identify new security patch updates in a reliable way:
      i. Ensure that a mechanism is available to be notified of all security patch updates
      ii. Confirm that security patch update notification comes from an authorized source

    2. Determine if the security patch updates are relevant to the production environment:
      i. Ensure that the security patch update is relevant to systems in the IRS production environment
      ii. Obtain the security patch update source files and confirm that they are virus free

    3. Determine the urgency of the security patch update:
      i. Determine whether the patch update is an emergency and submit a Request for Change (RFC) to deploy it into production
      ii. Ensure the receipt and verification of relevant security patch updates, and that they are safe to deploy

10.8.50.3.1.3 (04-26-2016)
Evaluate and Plan Phase

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

    1. Evaluate security patches to determine the implication of an implementation.

    2. Develop a strategy to deploy security patches:
      i. Establish a formal process to determine whether it is in the best interests of the agency to deploy the security patch updates.
      ii. Determine the owner of the security patch update(s) who will be responsible for ensuring that it is deployed.
      iii. Develop a systemic approach for rolling out the patch to the production environment.

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

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

10.8.50.3.1.4 (04-26-2016)
Deploy Phase

  1. During the Deploy phase, the IRS shall:

    1. Rescan the environment to assess success, and patch any computers and/or applications that failed to install the security patch updates.

    2. Ensure that the security patch update installation is successful.

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

10.8.50.3.1.5 (04-26-2016)
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.

    5. Assess operational effectiveness.

10.8.50.3.2 (07-01-2019)

Software Inventory

  1. As part of an effective Patch Management Program, software inventory and baseline configurations shall be maintained in accordance with IRM 10.8.1.

    1. At a minimum, the inventory shall contain:

      • operating systems

      • versions of all software

      • patch levels

      • installed applications

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

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

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

10.8.50.4 (04-26-2016)

Operational Approach

  1. The Operational approach is 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.

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

    3. Provide CSIRC with updates on any additional identified vulnerabilities for further assessment, in accordance with established procedures.

10.8.50.4.2 (04-30-2014)

Assign Severity Levels

  1. Information System Owner shall collaborate with Information System Security Management (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. See Exhibit 10.8.50-3 for a table of criticality rankings and distribution schedules.

    Note:

    Operational impact of not deploying a patch must be considered using Risk-Based Decision and Risk Acceptance process.

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

    • Instructions for what to do if assistance is required

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:

    Note:

    This group may be an independent entity, or its duties may be assumed by multiple existing groups (Configuration Control Boards, Steering Committees etc.)

    Color Priority Acknowledgement Timeframe
    Red Critical 1 Hour
    Orange High 2 Hours
    Yellow Medium 24 Hours
    Green Low None
10.8.50.4.5 (07-01-2013)

Patch Processing Metrics

  1. Cybersecurity 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 at a minimum, on a monthly basis for the following purposes:

    • Annual FISMA Reporting

    • Quarterly reports for senior leadership

    • Treasury Cyber Analysis and Reporting Dashboard (CARD)

    • IRS IT organization’s Internal Dashboard

    • Ad-hoc reporting

  3. The process and procedures for collecting patch and vulnerability metrics (based on Treasury and NIST guidance) shall be defined in Standard Operating Procedures.

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 3 Advisory Distribution

    • &&CSIRC-MAC Advisory options, and 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
    Vendorhttp://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 x Q2 x Q3),1/3) where Q1, Q2, etc. receive assigned rating values based on the CSIRC Vulnerability Ranking Matrix table that follows.

  • Severity = square root of ((Q4 x Q5),1/2)

  • Exposure = square root of ((Q6 x Q7),1/2)

  • 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 of 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-4 1
5-19 2
20-49 4
50-99 6
100-199 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)) 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 ) that are vendor default or are IRS standard 10
Advisory Security Rating
Rating Color Code Value Range
None None 0
Low Green 1-99
Medium Yellow 100-199
High Orange 200-499
Critical Red 500-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 /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.

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

Code Priority Remediation Timelines:
** Remediation begins when a vulnerability is discovered **
Red Critical Internet-Accessible systems identified in Cyber Hygiene Reports – 15 days
All other systems -30 days
Orange High Internet-Accessible systems identified in Cyber Hygiene Reports – 30 days
High Value Assets (HVAs) - 60 days
All other Systems - 90 days
Yellow Medium 120 days
Green Low 180 days


(DHS BOD-19-02; SI-2_N.02; SI-2(2)_T.255; SI-2(2)_T.256; FY2019 FISMA Metrics; IRS-defined) (L, M, H)

Note:

Operational impact of not deploying a patch must be: (i) considered using Risk Based Decision and Risk Acceptance process; or (ii) documented in a POA&M and the information system’s System Security Plan.

Advisory Distribution Mailing Lists:

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)

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

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

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

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

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

  • &&CSIRC-DB Advisory Distribution - All databases

  • &&CSIRC-MAC Advisory Distribution - All MAC operating systems

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

Exhibit 10.8.50-4

Glossary and Acronyms List

Glossary and Acronyms List
ACIO Associate Chief Information Officer
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.
AO Authorizing Official
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.
BOD Binding Operational Directive
CARD Cyber Analysis and Reporting Dashboard
CISA Cybersecurity and Infrastructure Security Agency
CONOPS Concept of Operations
COTS Commercial Off-the-shelf, as in software readily available on the market.
CSIRC IRS Computer Security Incident Response Center
CVE Common Vulnerabilities and Exposures
Cyber Hygiene Report A weekly report by CISA, which operates under DHS. Cyber Hygiene leverages the Common Vulnerability Scoring System (CVSS), which is a vulnerability scoring system designed to provide a universally open and standardized method for rating IT vulnerabilities. CVSS helps organizations prioritize vulnerability management strategies by providing a score representative of the base, temporal, and environmental properties of vulnerabilities. (DHS BOD 19-02
DHS Department of Homeland Security
ELC Enterprise Life Cycle
EA Enterprise Architecture
EOPS Enterprise Operations
ESP Enterprise Standards Profile
FIPS Federal Information Processing Standards
FISMA Federal Information Security Management Act of 2002
GUI Graphical User Interface
High Value Asset Are those assets, Federal information systems, information, and data for which an unauthorized access, use, disclosure, disruption, modification, or destruction could cause a significant impact to the United States' national security interests, foreign relations, economy, or to the public confidence, civil liberties, or public health and safety of the American people. HVAs may contain sensitive controls, instructions, data used in critical Federal operations, or unique collections of data (by size or content), or support an agency's mission essential functions, making them of specific value to criminal, politically motivated, or states-sponsored actors for either direct exploitation or to cause a loss of confidence in the U.S. Government. (OMB M-17-09)
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.
HTTP Hypertext Transfer Protocol
Internet-Accessible System An Internet-Accessible System is any system that is globally accessible over the public internet. It has a publicly routed IP address or a hostname that resolves publicly in DNS to such an address. It doesn’t pertain to infrastructure that is internal to a bureau network that enables endpoints to be accessible over the internet, systems reachable from the internet but that require special configuration or access controls (e.g. via a Virtual Private Network), or shared services.
IP Internet Protocol
IRM Internal Revenue Manual
IRS Internal Revenue Service
ISSM Information System Security Management
ISSO Information Systems Security Officer
IT Information Technology
MOU Memorandum of Understanding
NIST National Institute of Standards and Technology
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.
PBX Public Branch Exchanges
PC Personal Computer
PMO Project Management Office
POA&M Plan of Action and Milestones
POC Point of Contact
PVG Patch and Vulnerabilities Group
RBD Risk-Based Decision
RFC Request for Change
SA&A Security Assessment and Authorization
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.
Shockwave A multimedia platform for building interactive multimedia applications and video games. Such content can be viewed in a web browser on any computer with the Shockwave Player plug-in installed.
SLA Service-level Agreement
SOP Standard Operating Procedure
SP Special Publication
SQL Structured Query Language
System See host
TDP Treasury Directive Publication
URL Uniform Resource Locator is the term for the World Wide Web address that is used in a web browser to navigate to other locations.
Vulnerability Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source.
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-5

References

  1. Department of Treasury

    • TD P 85-01 (v3.1.1) - Treasury Information Technology Security Program, July16, 2020

    • Department of the Treasury Memorandum, TCIO M 19-03, Update to Treasury Directive Publication 85-01 Appendix A – System and Information Integrity

  2. Internal Revenue Service

    • IRM 10.5.8 - Sensitive But Unclassified (SBU) Data Policy: Protecting SBU in Non-Production Environments

    • IRM 10.8.1 - Information Technology (IT) Security, Policy and Guidance

    • IRM 10.8.2 - Information Technology (IT) Security, IT Security Roles and Responsibilities

    • IRM 10.9.1 - National Security Information

  3. National Institute of Standards and Technology (NIST)

    • NIST SP 800-40 Rev 3 - Guide to Enterprise Patch Management Technologies, July 2013

    • NIST SP 800-53 Rev 4 - Security and Privacy Controls for Federal Information Systems and Organizations, April 2013 (Updated 1/22/2015)

    • NIST SP 800-70 Rev 3 - National Checklist Program for IT Products-Guidelines for Checklist Users and Developers, December 2015

    • NIST 800-128 - Guide for Security-Focused Configuration Management of Information Systems, August 2011

    • FIPS Publication 200 - Minimum Security Requirements for Federal Information and Information Systems, March 01, 2006

  4. Defense Information Systems Agency (DISA

    • None

  5. Other

    • OMB M-19-03 - Strengthening the Cybersecurity of Federal Agencies by enhancing the High Value Asset Program, December 10, 2018

    • FY 2019 CIO FISMA Metrics V1, December 2018

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

    • Department of Homeland Security (DHS), Binding Operational Directive (BOD) 19-02, Vulnerability Remediation Requirements for Internet-Accessible Systems, April 29, 2019

  6. The following Interim Guidance Memorandums have been incorporated into this version of the IRM:

    • Interim Guidance (IG) Memorandum (Memo) IT-10-0919-0020 - Information Technology (IT) Security, Servicewide Security Patch Management – Internet Accessible System Remediation Timelines