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

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

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

Maintain hardware/software inventories.

Coordinate their patch activities with other information system owners.

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.

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

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

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

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

Provide educational materials and information for distribution.

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

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

Follow the procedures in this policy for advisory processing.

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.

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

Designate IRS incident coordination lead.

Notify CISA and, if applicable, law enforcement.

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

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.

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:

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

Develop a technical and contextual understanding of the incident.

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

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

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.

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.

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

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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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.

Identify all security tools used to protect the data.

Determine how long the PII was exposed.

Assess whether evidence of misuse already exists.

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

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

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

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.

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.

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.

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

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.

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

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.

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

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.

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

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

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.

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.

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.

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.

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.

Evaluate security patches to determine the implication of an implementation.

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.

Prioritize security patches based upon effectiveness of patches and upon criticality of assets. (NIST SP 800-40: Section 2.3.1)

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

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)

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

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)

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

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

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

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

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

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

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)

Ensure that the security patch update installation is successful.

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

Inventory/discover existing computing assets.

Assess security threats and vulnerabilities.

Determine the best source for information about patch updates.

Assess the existing software distribution infrastructure.

Assess operational effectiveness.