10.8.50. Enterprise Incident, Vulnerability, and Security Patch Management

(1) In accordance with NIST SP 800-40, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, organizations must create a Patch and Vulnerability Group (PVG) to facilitate the identification and distribution of patches within the organization.

(2) The following functions must be performed by the designated IRS IT organization responsible for management and operations of the IRS IT resources.

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

(4) Members of groups or boards with patch management oversight responsibilities must sign up for an email distribution list to receive Computer Security Incident Response Center’s (CSIRC) notifications and advisories. Refer to Exhibit 10.8.50-3, Security Notifications, for more information.

(1) The appropriate authorizing official (AO) must 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 IRM 10.8.1 for PM-05 Information System Inventory and PM-08 Critical Infrastructure Plan guidance.

(1) The IRS IT organization and other business and functional unit owners, that maintain systems, networks, IRS applications and COTS, must:

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

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 must be represented on the PVG (or other entity).

(1) The IRS IT organization's CSIRC must assist information system owners and other patch management stakeholders in defining relevant patches, prompting their implementation, and reporting their disposition.

(2) In accordance with Treasury Directive Publication (TD P) 85-01 and IRM 10.8.1 CSIRC must:

1. Publish vulnerability alerts, advisories, and bulletins on the CSIRC web site, to be used by information system owners and other patch management stakeholders. Refer to Exhibit 10.8.50-1, Sample IRS CSIRC Security Patch Advisory, for a sample advisory.

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 email 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 email messages to the PVG. The email subject line of an advisory must contain, IRS Patch Advisory <Advisory Number> <Alert Level> <Color Code> <Title>. Refer to IRM 10.8.50.5.2 Assign Severity Levels subsection within this IRM for additional information.

    Note: Advisories published by CSIRC are not the all-inclusive authoritative source for vulnerabilities and patches. The advisories must be used by information system owners in collaboration with advisories from product vendors, Department of Homeland Security, and other relevant sources.

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

(1) Information systems security officer (ISSO) roles must be determined as needed to support incident, vulnerability, and patch management operational processes by the Associate Chief Information Officer (ACIO) of Cybersecurity and applicable AO.

(1) The IRS shall report breaches or incidents – regardless of severity or priority, whether confirmed or suspected, to the Treasury Shared Service Security Operations Center (TSSSOC) (portal: https://treasury.servicenowservices.com/) as quickly as possible after discovery and in no more than one business day. Bureaus shall not wait for absolute confirmation of a breach or incident before reporting. Analysis is often an ongoing process, and the IRS must not hold up reporting due to an inability to provide complete information. (Treasury IRP: Section 4.2)

(2) The IRS must declare the incident by taking the following actions: (Treasury IRP: Section 4.2)

1. Perform initial categorization of incident. (OMB M-20-04)

2. Designate IRS incident coordination lead.

3. Notify CISA and, if applicable, law enforcement.

(3) The IRS must determine investigation scope by taking the following actions: (Treasury IRP: Section 4.2)

1. Identify the type and extent of the incident.
   i. Document (and provide to TSSSOC) contact information for both the impacted and reporting organizations.
   ii. Document (and provide to TSSSOC) description of what did or is suspected to have occurred, including impact.
   iii. Document (and provide to TSSSOC) date/time of occurrence, including time zone.
   iv. Document (and provide to TSSSOC) date/time of detection and identification, including time zone.
   v. Document (and provide to TSSSOC) associated system name (as tracked in TFIMS).
   vi. Document (and provide to TSSSOC) physical system location(s) (e.g., Washington, DC, Los Angeles, CA).

2. Assess operational or informational impact on IRS mission.
   i. Document (and provide to TSSSOC) functional impact.
   ii. Document (and provide to TSSSOC) information impact.
   iii. Document (and provide to TSSSOC) recoverability.

(4) The IRS must collect and preserve data by taking the following actions: (Treasury IRP: Section 4.2)

1. Collect and preserve the data necessary for incident verification, categorization, prioritization, mitigation, reporting, attribution, and as potential evidence in accordance with NIST SP 800-61, Computer Security Incident Handling Guide.
   i. Document (and provide to TSSSOC) mitigation actions taken or planned, if applicable.
   ii. Document (and provide to TSSSOC) impact assessment (i.e., number of records and/or users affected).
   iii. If applicable, document (and provide to TSSSOC) data elements/information types involved (e.g., social security number (SSN), name, phone numbers, taxpayer information, medical/health information, financial information).
   iv. If applicable, document (and provide to TSSSOC) information regarding vulnerable populations involved (e.g., children, active-duty military, government officials in sensitive positions, senior citizens, individuals with disabilities, confidential informants, witnesses, certain populations of immigrants, non-English speakers, and victims of certain crimes such as identity theft, child abuse, trafficking, domestic violence, or stalking).
   v. Document (and provide to TSSSOC) observed activity, if known.
   vi. Document (and provide to TSSSOC) free-form data or analyst comments and any of the following optional documentation:

• Related indicators (e.g., hostnames, domain names, network traffic characteristics, registry keys, X.509 certificates, MD5 file signatures)

• Details describing any vulnerabilities involved (i.e., Common Vulnerabilities and Exposures (CVE) identifiers)

• Source and destination Internet Protocol (IP) address, port, and protocol

• Operating System(s) affected

• Mitigating factors (e.g., full disk encryption or two-factor authentication)

• Device function(s) (e.g., web server, domain controller, or workstation)

• Sources, methods, or tools used to identify the incident (e.g., Intrusion Detection System or audit log analysis)

Note: The IRS is not required or expected to provide Actor Characterization, Cross-Sector Dependency, or Potential Impact information. These are assessed independently by National Communications, Coordination, and Integration Center (NCCIC)/CISA incident handlers and analysts. Additionally, Observed Activity is not currently required and is based on the attack vector, if known, and maps to the Office of the Director of National Intelligence (ODNI) Cyber Threat Framework.

2. Log all evidence and note how the evidence was acquired, when it was acquired, and who acquired the evidence.

(5) The IRS must perform technical analysis by taking the following actions: (Treasury IRP: Section 4.2)

1. Develop a technical and contextual understanding of the incident.

2. Based on analysis thus far and available CTI, form a hypothesis of what the adversary was attempting to access/accomplish.

3. Update scope as investigation progresses and information evolves. Report most recent findings and incident status to CISA.

4. Terminating condition: Technical analysis is complete when the incident has been verified, the scope has been determined, the method(s) of persistent access to the network has/have been identified, the impact has been assessed, a hypothesis for the narrative of exploitation has been cultivated (tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs)), and all stakeholders are proceeding with a common operating picture.

5. Correlate events and document timeline.
   i. Analyze logs to correlate events and adversary activity.
   ii. Establish an incident timeline that records events, description of events, date-time group (using Coordinated Universal Time (UTC)) of occurrences, impacts, and data sources. Keep updated with all relevant findings.

6. Identify anomalous activity.
   i. Assess affected systems and networks for subtleties of adversary behavior which often may look legitimate.
   ii. Identify deviations from established baseline activity - particularly important to identify attempts to leverage legitimate credentials and native capabilities and tools (i.e., living off the land techniques).

7. Identify root cause and enabling conditions.
   i. Attempt to identify the root cause of the incident and collect threat information that can be used in further searches and inform subsequent response efforts.
   ii. Identify and document the conditions that enabled the adversary to access and operate within the environment.
   iii. Assess networks and systems for changes that may have been made to either evade defenses or facilitate persistent access.
   iv. Identify attack vector. This includes how the adversary accessing the environment (e.g., malware, Remote Desktop Protocol (RDP), Virtual Private Network (VPN)).
   v. Assess access (depth and breadth). This includes all compromised systems, users, services, and networks.

8. Gather Incident Indicators.
   i. Review available CTI for precedent of similar activity.
   ii. Analyze adversary tools. Assess tools to extract IOCs for short-term containment.
   iii. Identify and document indicators that can be used for correlative analysis on the network.
   iv. Share extracted threat information (atomic, computed, and behavioral indicators, context, and countermeasures) with internal response teams and CISA.

9. Analyze for common adversary TTPs.
   i. Identify initial access techniques (e.g., spear phishing, supply chain compromise).
   ii. If access is facilitated by malware, identify associated command and control (e.g., identify port, protocol, profile, domain, IP address).
   iii. Identify the techniques used by the adversary to achieve code execution.
   iv. Assess compromised hosts to identify persistence mechanisms.
   v. Identify lateral movement techniques. Determine the techniques used by the adversary to access remote hosts.
   vi. Identify the adversary’s level of credential access and/or privilege escalation.
   vii. Identify the method of remote access, credentials used to authenticate, and level of privilege.
   viii. Identify mechanism used for data exfiltration.

10. Validate and refine investigation scope.
    i. Identify new potentially impacted systems, devices, and associated accounts.
    ii. Feed new IOCs and TTPs into detection tools.
    iii. Continue to update the scope and communicate updated scope to all stakeholders to ensure a common operating picture.

(6) The IRS must determine if third-party support is needed. (Treasury IRP: Section 4.2)

1. Identify if third-party analysis support is needed for incident investigation or response. CISA may recommend use of another agency or a third-party for intrusion detection and incident response support services.

2. Invoke Federal Network Authorization (FNA) to enable CISA incident response and hunt assistance. (CISA Services Catalog, First Edition: Autumn 2020)

3. Coordinate and facilitate access if incorporating third-party analysis support into response efforts.

4. Coordinate response activities with IRS service providers for systems hosted outside of the IRS.

(7) The IRS must adjust tools by taking the following actions: (Treasury IRP: Section 4.2)

1. Tune tools to slow the pace of advance and decrease dwell time by incorporating IOCs to protect/detect specific activity.

2. Introduce higher-fidelity modifications to tools. Tune tools to focus on tactics that must be used by the adversary to obtain operational objectives (e.g., execution, credential access, and lateral movement).

(1) To facilitate appropriate escalation, TSSSOC will use a color-coded severity schema to categorize incident, breach, and event reports. The IRS must include their perceived severity as of the time of the initial report to TSSSOC using the following: (Treasury IRP: Section 4.2.3.1)

(2) If an incident or breach constitutes a “major incident” and/or a “significant cyber incident” (Orange or Red incident), the IRS must perform incident containment, incident eradication, incident recovery, and post-incident activity. (Treasury IRP: Chapters 4.3, 4.5.1, 4.5.2)

(3) The IRS must implement a risk response. Examples of this include distributing and installing a patch, purchasing cybersecurity insurance, deploying additional security controls, and changing asset configurations and state (e.g., software reset, platform reboot). Any issues that occur during implementation must be resolved. (NIST SP 800-40: Section 2.2)

(1) TSSSOC is the primary party responsible for ensuring appropriate Departmental (e.g., Treasury, TIGTA) and external resources (e.g., CISA, OMB, Congress) are engaged during an incident. (Treasury IRP: Section 4.2.3.2)

(2) For breaches that involve PII, the IRS must evaluate and assess the nature of the following data elements subject to the breach: (Treasury IRP: Section 4.2.2.2)

1. Single data elements that contain PII (e.g., SSNs, passport numbers, driver's license numbers, state identification numbers, bank account numbers, passwords, and biometric identifiers).

2. Combination of non-sensitive data elements that when combined contain PII.

(3) For PII breaches, the IRS must evaluate and assess the following characteristics of the PII subject to the breach: (Treasury IRP: Section 4.2.2.2)

1. PII that may subject an individual to embarrassment, blackmail, or emotional distress (e.g., personnel or criminal information, personal debt and finances, medical conditions, treatment for mental health, pregnancy related information including pregnancy termination, sexual history or sexual orientation, adoption or surrogacy information, and immigration status).

2. PII that may subject an individual to identity theft or other financial risk (e.g., SSNs, bank account numbers, credit card numbers (especially when combined with the expiration date and security code), bank card pin numbers, passwords, or tax identification numbers).

3. PII that cannot be changed (e.g., permanent biometric information including fingerprints, hand geometry, retina or iris scans, and Deoxyribonucleic Acid (DNA) or other genetic information (considering both current and future uses).

(4) For PII breaches, the IRS must determine context by considering all relevant facts and circumstances regarding the breach and the PII involved in the breach. (Treasury IRP: Section 4.2.2.2)

1. Context must be considered in assessing risk (e.g., the name of an individual on a list of personnel who attended a meeting on tax policy vs. a name of an individual on a request for an accommodation for a disability).

2. Context including an assessment of the vulnerabilities of potentially affected individuals (e.g., children, active-duty military, government officials in sensitive positions, senior citizens, individuals with disabilities, confidential informants, witnesses, certain populations of immigrants, non-English speakers, and victims of certain crimes such as identity theft, child abuse, trafficking, domestic violence, or stalking) must be considered.

(5) For PII breaches, the IRS must determine the likelihood that the breached PII is accessible to and usable by those with unauthorized access to it. (Treasury IRP: Section 4.2.2.2)

1. Identify all security tools used to protect the data.

   Note: This includes an analysis of all of the security features available in the format or media type involved, how long the PII was exposed, whether encryption was used, the likelihood that any encryption keys were exposed during the breach, whether PII was capable of and actually remotely wiped, and whether data masking, redaction, truncation, or anonymization were used (assuming the information underlying these techniques [e.g., redacted information available in the system to some but not all users] was not itself exposed during the breach).

2. Determine how long the PII was exposed.

3. Assess whether evidence of misuse already exists.

(6) For PII breaches, the IRS must assess whether the breach was intentional or unintentional by reviewing the following: (Treasury IRP: Section 4.2.2.2)

1. Evidence of intent to target the information or device may elevate risk.

2. Lack of evidence of intent to target the information or device may still reveal a high risk.

3. Evidence that the PII was disclosed to a known or unknown recipient.

(7) Data breaches (incidents involving PII) must be reported to Privacy, Governmental Liaison and Disclosure (PGLD)/Incident Management (IM) immediately upon discovery using the PII Breach Reporting form. Refer to the PGLD website at https://irsgov.sharepoint.com/sites/PGLD. (IRS-defined)

1. PGLD's Incident Management Program includes the management of the IRS data breach reporting process, as well as the risk assessment and tracking of IRS data breaches and notification to individuals potentially impacted by IRS data breaches.

2. Refer to IRM 10.5.4, Privacy and Information Protection, Incident Management Program; Document 13347, Data Breach Response Playbook; Document 13347-A, IRS Data Breach Response Plan; and the Report Losses, Thefts or Disclosures page located at https://irsgov.sharepoint.com/sites/ETD-KMT-KB003/SitePages/Privacy/Report_Losses_Thefts_Disclosures/Report_Losses_Thefts_Disclosure.aspx in the Disclosure and Privacy Knowledge Base site for additional information about PGLD's Incident Management Intake, Risk Assessment, and Notification process.

3. Refer to IRM 11.3.38, Disclosure of Official Information, Role and Responsibilities of Disclosure, for additional information on Reporting Suspected Willful Unauthorized Accesses or Disclosures.

(8) For PII breaches, the IRS must determine the capability of the IRS to independently mitigate the harm resulting from the breach. (Treasury IRP: Section 4.2.2.2)

(1) Common secure configurations (Common Configuration Enumerations (CCEs)) must be established and applied to prevent attackers from compromising a system or device which in turn may be used as a platform to compromise other systems or devices. (NISTIR 8011 Vol 1)

(2) Software and firmware vulnerabilities (CVEs) must be identified and patched to prevent attackers from compromising a system or device which in turn may be used to compromise other systems or devices. (NISTIR 8011 Vol 1)

(3) The IRS must perform the following actions, for vulnerability remediation requirements for internet-accessible systems: (CISA BOD 19-02)

1. Ensure Cyber Hygiene access and verify scope:
   i. Remove Cyber Hygiene source IP addresses from block lists to ensure Cyber Hygiene scanning access;
   ii. Notify CISA at NCATS@hq.dhs.gov within five 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 IRS 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 must be remediated within 15 calendar days of initial detection.
   -- 2. High vulnerabilities must 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 days of receipt to FNR.BOD@hq.hds.gov.

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

Note: Refer to CISA BOD 19-02 for additional guidance: 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)

(4) The IRS must perform the following actions, in accordance with CISA guidance for reduction of significant risk of known exploited vulnerabilities (KEVs): (CISA BOD 22-01)

1. Document vulnerability management procedures, for the following actions, by January 3, 2022:
   i. Establishing a process for ongoing remediation of vulnerabilities that CISA catalogs and within remediation timeframes set forth by CISA;
   ii. Assigning roles and responsibilities for ongoing remediation of vulnerabilities that CISA catalogs and within remediation timeframes set forth by CISA;
   iii. Defining necessary actions required to enable prompt response to remediation actions required by CISA;
   iv. Establishing internal validation and enforcement procedures to ensure adherence to remediation of vulnerabilities that CISA catalogs; and
   v. Setting internal tracking and reporting requirements to evaluate adherence to remediation of vulnerabilities that CISA catalogs and to provide reporting to CISA.

Note: CISA provides a catalog, or repository, of known exploited vulnerabilities at the web site: https://cisa.gov/known-exploited-vulnerabilities.

2. Remediate all vulnerabilities identified within the CISA-managed vulnerability catalog according to the timelines set forth in the catalog.

   Note: The default remediation timeline requirements are to remediate within 6 months for vulnerabilities having a CVE ID assigned prior to 2021 and within two weeks for all other vulnerabilities. These default timelines may be adjusted by CISA in the case of grave risk to the Federal Enterprise.

   Note: CISA provides a catalog, or repository, of KEVs at the web site: https://cisa.gov/known-exploited-vulnerabilities.

3. Report on the status of vulnerabilities listed in the CISA catalog.
   i. The IRS must automate data exchange and report implementation status through the Continuous Diagnostics and Mitigation (CDM) Federal Dashboard.
   ii. Prior to October 1, 2022, the IRS must submit quarterly reports either through CyberScope submissions or through the CDM Federal Dashboard.
   iii. Starting on October 1, 2022, if the IRS has not yet automated reporting to the CDM Federal Dashboard, the IRS must update status through CyberScope bi-weekly, until that automation, through the CDM Federal Dashboard, occurs.

Note: Refer to CISA BOD 22-01 for additional guidance: https://cyber.dhs.gov/bod/22-01/.

(5) Refer to IRM 10.8.1 for additional guidance on Flaw Remediation.

(1) During the Assess phase, the IRS must define baseline systems and networks before an incident occurs to understand the basics of “normal” activity (Treasury IRP: Section 4.1):

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.

(2) The IRS must prepare for risk responses. This encompasses any preparatory activities, such as acquiring, validating, and testing patches for the vulnerable software; deploying additional security controls to safeguard the vulnerable software; or acquiring a replacement for a legacy asset that cannot be patched. It might also include scheduling the risk response and coordinating deployment plans with enterprise change management, business units, and others. (NIST SP 800-40: Sections 2.2, 3.3)

(1) During the Identify phase, the IRS must: (IRS-defined)

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.

(1) During the Evaluate and Plan phase, the IRS must: (IRS-defined)

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 IRS 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. Prioritize security patches based upon effectiveness of patches and upon criticality of assets. (NIST SP 800-40: Section 2.3.1)

4. Schedule security patch deployment as part of IRS change management activities. (NIST SP 800-40: Section 2.3.1)

5. Acquire the security patch through being downloaded from the internet, built internally by developers or system administrators, or provided through removable media. (NIST SP 800-40: Section 2.3.1)

6. Validate the security patch to determine the patch’s authenticity and integrity, preferably by automated means. (NIST SP 800-40: Section 2.3.1)

7. Test security patches in a test environment prior to deploying security patches into the production environment to reduce operational risk and to ensure the security patch does not compromise business critical systems and applications. Testing may be performed manually or through automated methods. (NIST SP 800-40: Section 2.3.1)

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

(1) During the Deploy phase, the IRS must: (IRS-defined)

1. Distribute the patch. (NIST SP 800-40: Section 2.3.2)

2. Validate the patch. (NIST SP 800-40: Section 2.3.2)

3. Install the patch. (NIST SP 800-40: Section 2.3.2)

4. Change software configuration and state. (NIST SP 800-40: Section 2.3.2)

5. Resolve any issues. (NIST SP 800-40: Section 2.3.2)

6. Verify deployment. Rescan the environment to assess success, and patch any computers or applications that failed to install the security patch updates. (NIST SP 800-40: Section 2.3.3)

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

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

(1) Once IRS personnel have deployed the security patch update, the IRS must: (IRS-defined)

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.

(2) The IRS must verify the risk response. This step involves ensuring that the implementation has been completed successfully. For patching, this means confirming that the patch is installed and has taken effect. For deploying additional security controls, ensure they are functioning as intended. For risk avoidance, verify that vulnerable assets were decommissioned or replaced. (NIST SP 800-40: Section 2.2)

(3) The IRS must continuously monitor the risk response. Make sure that the risk response continues to be in place: no one uninstalls the patch, deactivates the additional security controls, lets the cybersecurity insurance lapse, or restarts the decommissioned asset. (NIST SP 800-40: Sections 2.2, 2.3.4)