Incident Management

Purpose

The University of New Mexico is committed to protecting the information with which it is entrusted. This component of the UNM Information Security Program aligns with the National Institute of Standards and Technology (NIST) Special Publication (SP) Series and Frameworks. This Incident Management program component describes how UNM helps minimize risk to the confidentiality, integrity, and availability of information for which UNM is responsible. The Incident Management program component accomplishes this by providing UNM with a standard and consistent approach for responding to all suspected and actual Information Security Incidents.

The purpose of Incident Management is to direct the activities of UNM employees when responding to an Information Security Incident to ensure a timely and appropriate response to all Information Security Incidents. This program component distinguishes between Major and Minor Information Security Incidents. Additionally, this program component provides a consistent, structured approach to reviewing and improving the safeguards that protect Personally Identifying Information/ Sensitive and Protected Information (PII/ SPI).

Note: Information Security Incidents are generally referred to throughout the rest of this document as incidents, however, the term incident may have different meanings under various contexts. Information Security Incident Management is not fundamentally different from other forms of Incident Management.

Objectives

• Identify roles and responsibilities
• Establish approach and methodologies
• Ensure appropriate responses

Scope

This program component applies to all information and systems owned or managed by, or for which UNM is responsible.

Overview

Timely response to Information Security Incidents is critical. As soon as an Information Security Incident is detected or externally reported, it must be reported to one of the following:

*When reporting an incident to ServiceNow, do not include sensitive or protected information in the description or email content

The five primary steps in Incident Management are to identify, contain, remove, restore, and review incidents that occur. These steps apply to incidents that impact any information collected, stored, processed, or transmitted by or on behalf of UNM. In some cases, improvements to the safeguards will include vendor management activities up to and including amending contractual language and/ or services. The steps of the Incident Management process are intended to ensure that timely and appropriate response is consistently performed for any incident that impacts information and systems for which UNM is responsible. Because many Information Security Incidents are the result of known vulnerabilities, special attention must be paid during the post-incident review process to ensure that improvements to the safeguards that protect PII/ SPI thoroughly consider vulnerability and patch management.

Roles and Responsibilities

Office of the President Chief of Staff**

Responsible for coordinating executive communication and liaising with executive leadership regarding Major Incident response

Chief Information Officer** (CIO)

Responsible for Information Technology services across the University and ensures resources are available for appropriate response to the incident and liaises between University Administration, Business Process Owners, Data Owners, Stewards, and Custodians, to effect timely and appropriate communications and related response activities for the incident.

Information Security & Privacy Officer** (ISPO)

Responsible for directing the Security and Privacy-related activities of incident response across the University and ensures institutional information security and privacy practices are followed for the incident and reviewed after the incident, including specific recommendations to reduce the likelihood of incident occurrence, and to improve response processes.

Information Security & Privacy Office Staff

Provides:

• An incident handler as the primary point of contact
• Information Security Incident subject matter expertise
• Direction of IRT member activities

Incident Response Team (IRT)

Technical and unit staff responsible for carrying out the tasks necessary to identify, contain, and remove the incident and restore services. An incident response team (IRT) is a carefully selected and well-trained group of subject matter experts (SMEs) whose purpose is to promptly and correctly respond to an incident so that it can be quickly contained, investigated, and recovered from. It is usually comprised of members from within IT@UNM, however staff from other units may be included as needed.

Internal Audit Director

Responsible for assessing whether policy violations may have occurred and for reporting to state agencies, where necessary.

Public Information Officer** (PIO)

Responsible for creating and managing institutional communications to executives, to the Incident Response Team, and to the community for the incident.

University Counsel** (OUC)

Responsible for providing legal advice and counsel for the incident.

UNM Industrial Security Officer (ISO)

Responsible for ensuring compliance with technology control plans (TCP's) for export-controlled research, and for reporting suspicious activities where required by law.

UNM Police Chief, UNMPD

Responsible for liaising with external Law Enforcement entities for the incident.

Compliance Officer(s)**

Responsible for managing and overseeing institutional communications to the public and for collaborating on all incident response-related communications.

Risk Manager**

Responsible for ensuring that UNM Risk Management practices are followed for the incident.

Data Owner*

Responsible for defining and promulgating operational safeguards and trainings for the PII/ SPI for which they are responsible, and for assisting in the direction of incident response activities in the unit in which the incident occurred. See data.unm.edu for the list of current data owners.

Business Process Owner*

Responsible for complying with operational and technical safeguards for PII/ SPI, for providing unit resources in responding to the incident, and for paying the costs of responding to the incident.

Other Plan Members as Appropriate

*Primarily responsible for developing information security incident/ breach notices.
**Responsible for assisting in the development and review of information security incident/ breach notices.

Incident Levels

Major Incident

Major incidents can involve highly sensitive data, can have a high impact, or can have the potential for high impact on institutional reputation, services, information, and operations. These types of incidents require the involvement of various UNM teams, internal and external, to assist in the response. Examples of these types of incidents may include, but are not limited to:

• Incidents involving High severity vulnerabilities as defined by the ISPO Vulnerability Management Program Component
• Incidents involving breaches on enterprise systems of record, especially those that result in extended outages
• Incidents involving systems that are conducting attacks against other UNM services or against the services of third parties
• Incidents involving law enforcement agencies
• Incidents involving successful targeted social engineering, such as Spear Phishing

Minor Incident

Minor incidents rarely have a significant impact on institutional services and operations. Often, minor incidents are isolated and / or not the result of targeted attacks. Furthermore, these types of incidents have a prescribed or known method of resolution, such as a patch installation, malware definition update, or configuration change. These types of incidents are generally resolved by following Standard Operating Procedures (SOPs). Examples of these types of incidents include, but are not limited to:

• Incidents involving web page defacements
• Incidents involving non-targeted email phishing
• Incidents involving malware infections where no sensitive data was at risk

Major Incident Response Stages

Incident Response Plans (IRPs) will be developed for each major incident according to the following steps:

Identify

When a major incident has occurred, or is likely to have occurred, the individuals in the roles identified in the Roles and Responsibilities section above, will be called to meet to develop the IRP and:

• Validate that incident has occurred;
• Determine the Scope of the incident, including
  • Systems/ services involved
    • UNM-Managed;
    • Third-Party;
  • Data Owner(s) involved
  • Business unit(s) involved;
  • Information involved;
    • PII/ SPI involved;
  • Initial Communication(s);
• ISPO will develop recommendations to contain the incident

Contain

Once a major incident has been identified and validated, the team reviews and affirms ISPO recommendations to contain the incident, including directing activities to

• Limit access to appropriate systems/ services;
• Conduct discovery to determine potential PII/SPI exposures;
• Conduct discovery to determine how the incident occurred;
• Create investigative copies of
  • logs for all involved systems/ services;
  • storage media for drives of involved systems/ services;
  • PII/ SPI as necessary for analysis, reporting, communication, etc.
• ISPO to Develop recommendations for IRP members to remove incident cause.

Remove

Once a major incident has been contained, the team reviews and affirms ISPO recommendations to remove incident cause including directing activities to

• Change passwords for all relevant applications, systems, and user accounts;
• Re-image all relevant systems/ services with known good operating systems/ services
  • Ensure all systems/ services have current patches and updates and secure configurations;
• Restore data from known good backups;
• Correct any unauthorized data changes;
• ISPO to develop recommendations for IRP members to restore the involved information and services to production.

Major Incident Response Stages (cont.)

Restore

Once the causes of an incident have been removed, the IRP team reviews and affirms ISPO recommendations to restore services, including directing activities to

• Establish timeframe to restore services in accordance with UNM business cycles;
  • Including technical and functional testers and stakeholders;
• Monitor
  • For recurrence of incident (for ensuring systems are not vulnerable to same incident cause);
  • For anomalous behavior (for ensuring that systems do not have indications that root cause of incident was not removed);
• Determine that services are secured against recurrence of the root cause of the incident;
• Develop plan to conduct any breach response activities
  • General for systems/ services;
  • Specific to PII/ SPI involved;
• Provide incident closeout communications to IRP Team;
• ISPO to develop recommendations for additional safeguards for appropriate systems/ services and information;
• ISPO to develop recommendations for IRP members to close incident and schedule post-incident review.

Post-Incident Review

Once the involved services have been restored and are secured against recurrence, the IRP Team

• Reviews incident root cause(s);
• Ensures breach response related to systems or PII/ SPI is complete;
• Reviews recommendations for additional safeguards for involved systems/ services;
• Develop executive summary of incident and post-incident review;
• ISPO to review execution of IRP for process improvements to be implemented by responsible unit(s).

Minor Incident Response Stages

Minor incident response is a routine activity for large organizations like UNM. Standard operating procedures (SOPs) should be developed by system administrators to address minor security incidents in consultation with the ISPO. information below provides a methodology by which system administrators can create such SOPs. The following qualitative analysis provides an overview of how the five stages should relate to each other for such SOPs:

Identify

This step is used to evaluate and triage the minor incident. Information Security Analysts will work with system-level administrators to determine whether an event or set of events constitutes a minor incident, based on indicators of compromise (IOC), such as system deviations from normal operations or other indication of malicious or otherwise unusual acts. The anomalous event(s) could occur or be observed at the network level, the host level or the application level. Logs from routers, firewalls, IDS, SIEM, AV gateways, operating system, network flows, etc. can aid in identification that a minor incident has occurred. After identifying and affirming that a minor incident has occurred, the impact and severity of the incident will be defined. Appropriate individuals, which always include the ISPO, must be notified as soon as it is determined that a minor incident occurred.

Contain

At this step, the systems and information involved must be contained for the minor incident to prevent additional harm. Containment could be as simple as revoking user accounts, blocking access to the system or information through a firewall, or updating antivirus rules to stop the execution of malicious code. The faster the response to a minor incident, the more likely damage from the minor incident will be minimized.

Remove

At this step, the cause of the incident must be addressed, including removal of any malicious code, unauthorized alterations to information or content, unpatched vulnerabilities, etc., that were responsible for the incident. Forensic analysis should be completed and logs kept throughout the remediation/ removal process.

Restore

This step is where the systems are brought back online and accounts reactivated. The response team must continue to monitor the systems for any aberrant behavior help ensure that the minor incident has been fully resolved and the underlying causes removed. Ongoing monitoring will also help detect suspicious behaviors going forward.

Post-Incident Review

The last step of follow up activity is crucial to identify improvements for incident handling processes and procedures, and more importantly, to review areas of improvement in systems to reduce the likelihood of similar minor incidents in the future. Minor incidents are regularly reported to UNM Leadership.

Definitions

Event

An occurrence within a system or network

Exploit

An exploit (from the English verb to exploit, meaning "using something to one's own advantage") is software, data, or a commands that takes advantage of a bug or vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or an electronic device (usually computerized).

Personally Identifiable Information

Data where some explicit, direct identifier data, such as a full legal name or social security number, is part of the information collection. Identifiable information is usually considered protected. That is, where identification of the individual is likely, or reasonably likely, given other indirect identifiers. For example, a record with age, gender and nine-digit zip code might easily be matched to a particular person, depending upon the geographic area.

Indicator of Compromise

An artifact observed on a network or in an operating system or application that, with high confidence, indicates a computer intrusion

Impact

A measure of the effect of an incident, problem, or change on business or IT processes

Incident

An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident – for example, failure of one disk from a mirror set.

Information Security Incident

(Minor and Major) A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

Risk

A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of: (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of the occurrence of that risk.

Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, and other organizations.

Threat

Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, or other organizations through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service

Security Posture

A measure of an organization's resistance to full or partial loss of confidentiality, integrity, or availability of information or resources

Sensitive and Protected Information

Information prescriptively identified in UNM Policy as requiring specific administrative, physical, and technical safeguards. Access to this information is limited to only those with a specific authorized business need to know in order to perform their employment duties. Generally, this information is defined or identified by a contract, law, regulation, or compliance standard, especially when that contract, law, regulation, or compliance standard requires specific safeguards around that information.

Vulnerability

A weakness in information systems, security procedures, internal controls, or implementations that could be exploited or triggered by a threat source

Zero Day

A vulnerability that has been discovered, and distributed but a patch has not been created for or otherwise mitigated

Appendix A: HIPAA Incident Response Addenda

The following are in addition to the general Information Security Incident Response steps for those incidents that involve HIPAA and / or PHI.

Identify

This step is used to evaluate potentially affected data to determine if it is PHI data. If there is a question about the potential PHI status the Contact action must be followed.

Contact

Major or Minor Incidents which involve HIPAA Protected Health Information (PHI) require notification to the HIPAA Privacy Officer. At this step the Incident Handler contacts the HIPAA Privacy Officer. The Incident Handler will provide the reasoning for determination and collaborate on any additional tasks.

If you have questions or would like to provide feedback regarding this document, please use ServiceNow to submit a request to ensure your question or feedback is received and tracked.