Version Date: 9-21-2022

Introduction
The Incident Management Plan has been developed to provide direction and focus to the handling of information security incidents that adversely affect Information Resources. The Incident Management Plan applies to any person or entity charged with a response to information security related incidents at the organization, and specifically those incidents that affect Information Resources.
The purpose of the Incident Management Plan is to respond quickly and appropriately to information security incidents.

Event Definition
Any observable occurrence in a system, network, environment, process, workflow, or personnel. Events may or may not be negative in nature.

Adverse Events Definition
Events with a negative consequence. This plan only applies to adverse events that are computer security related, not those caused by natural disasters, power failures, etc.

Incident Definition
A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices that jeopardizes the confidentiality, integrity, or availability of information resources or operations. A security incident may have one or more of the following characteristics:
A. Violation of an explicit or implied security policy
B. Attempts to gain unauthorized access to an Information Resource
C. Denial of service to an Information Resource.
D. Unauthorized use of Information Resources
E. Unauthorized modification of information
F. Loss of Confidential or Protected information

Incident Response Framework
Recognizes that, despite reasonable and competent efforts to protect Information Resources,
a breach or other loss of information is possible. The organization must make reasonable efforts and act competently to respond to a potential incident in a way that reduces the loss of information and potential harm to customers, partners, and the organization itself.
Developing a well-defined incident response framework is critical to an effective incident response plan. The incident response framework is comprised of six phases that ensure a consistent and systematic approach.

Phase I – Preparation
It is essential to define appropriate lines of communication, articulate services necessary to support response activities, and procure the necessary tools.
(See Phase I – Preparation Details)

Phase II – Identification and Assessment
Identifying an event and conducting an assessment should be performed to confirm the existence of an incident. The assessment should include determining the scope, impact, and extent of the damage caused by the incident. In the event of possible legal action, digital evidence will be preserved, and forensic analysis may be conducted consistent with legislative and legal requirements. (See Phase II – Identification and Assessment)

Phase III – Containment and Intelligence
Containment of the incident is necessary to minimize and isolate the damage caused. Steps must be taken to ensure that the scope of the incident does not spread to include other systems and Information Resources. Root cause analysis is required prior to moving beyond the Containment phase and may require expertise from outside parties. (See Phase III – Containment and Intelligence)

Phase IV – Eradication
Eradication requires removal or addressing of all components and symptoms of the incident. Further, validation must be performed to ensure the incident does not reoccur. (See Phase IV – Eradication Details)

Phase V – Recovery
Recovery involves the steps required to restore data and systems to a healthy working state allowing business operations to be returned.

Phase VI – Lessons Learned
The Lessons Learned phase includes post-incident analysis on the system(s) that were impacted by the incident and other potentially vulnerable systems. Lessons learned from the incident are communicated to executive management and action plans developed to improve future incident management practices and reduce risk exposure.

Figure 1: Framework Model

Version Date:  9-21-2022

Introduction
The Incident Management Plan has been developed to provide direction and focus to the handling of information security incidents that adversely affect Information Resources. The Incident Management Plan applies to any person or entity charged with a response to information security related incidents at the organization, and specifically those incidents that affect Information Resources.
The purpose of the Incident Management Plan is to respond quickly and appropriately to information security incidents.

Event Definition
Any observable occurrence in a system, network, environment, process, workflow, or personnel. Events may or may not be negative in nature.

Adverse Events Definition
Events with a negative consequence. This plan only applies to adverse events that are computer security related, not those caused by natural disasters, power failures, etc.

Incident Definition
A violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices that jeopardizes the confidentiality, integrity, or availability of information resources or operations. A security incident may have one or more of the following characteristics:
A. Violation of an explicit or implied security policy
B. Attempts to gain unauthorized access to an Information Resource
C. Denial of service to an Information Resource.
D. Unauthorized use of Information Resources
E. Unauthorized modification of information
F. Loss of Confidential or Protected information

Incident Response Framework
Recognizes that, despite reasonable and competent efforts to protect Information Resources,
a breach or other loss of information is possible. The organization must make reasonable efforts and act competently to respond to a potential incident in a way that reduces the loss of information and potential harm to customers, partners, and the organization itself.
Developing a well-defined incident response framework is critical to an effective incident response plan. The incident response framework is comprised of six phases that ensure a consistent and systematic approach.

Phase I – Preparation
It is essential to define appropriate lines of communication, articulate services necessary to support response activities, and procure the necessary tools.
(See Phase I – Preparation Details)

Phase II – Identification and Assessment
Identifying an event and conducting an assessment should be performed to confirm the existence of an incident. The assessment should include determining the scope, impact, and extent of the damage caused by the incident. In the event of possible legal action, digital evidence will be preserved, and forensic analysis may be conducted consistent with legislative and legal requirements. (See Phase II – Identification and Assessment)

Phase III – Containment and Intelligence
Containment of the incident is necessary to minimize and isolate the damage caused. Steps must be taken to ensure that the scope of the incident does not spread to include other systems and Information Resources. Root cause analysis is required prior to moving beyond the Containment phase and may require expertise from outside parties. (See Phase III – Containment and Intelligence)

Phase IV – Eradication
Eradication requires removal or addressing of all components and symptoms of the incident. Further, validation must be performed to ensure the incident does not reoccur. (See Phase IV – Eradication Details)

Phase V – Recovery
Recovery involves the steps required to restore data and systems to a healthy working state allowing business operations to be returned.

Phase VI – Lessons Learned
The Lessons Learned phase includes post-incident analysis on the system(s) that were impacted by the incident and other potentially vulnerable systems. Lessons learned from the incident are communicated to executive management and action plans developed to improve future incident management practices and reduce risk exposure.

Figure 1: Framework Model

Phase I – Preparation Details
The Preparation phase is easily the most important and often overlooked phase. Without proper preparation incident response activities may be disorganized, expensive, and could cause irreparable harm to organizations. Tasks included in the Preparation phase include but are not limited to the following:
– Ensure appropriate parties are aware of incident reporting processes.
– Document and share cyber insurance details with appropriate parties.
– Validate Logging, Alerting, and Monitoring policy compliance.
– Ensure the team receives appropriate training based on skill gap analysis, career development efforts, and skill retention needs.
– Ensure the team has access to the tools and equipment needed based on estimated ROI and the organization’s risk appetite.
– Define and document standard operating procedures and workflows for team.
– Improve documentation, checklists, references, etc.
– Maintain and validate Network Diagrams and Asset Inventories.
– Review Penetration Test reports and validate remediations to findings.
– Review Vulnerability Management reports and validate remediation efforts.
– Establish disposable and disabled Administrative credentials to be enabled and used for investigations.
Finally, it should be noted that the Phase I is continuous or at least cyclical as incidents are brought to conclusion.

Reporting Incidents
Effective ways for both internal and outside parties to report incidents is equally critical as sometimes
users of systems and information may be the first to observe a problem. Review the different types of incidents addressed in Phase II under Incident Categorization and list or establish reporting methods for a variety of incident types.

Phase II – Identification and Assessment Identification
When a employee or external party notices a suspicious anomaly in data, a system, or the network, or a system alert generates an event, Security Operations, Help Desk, or TEAM must perform an initial investigation and verification of the event.
Events are observed changes in normal behavior of the system, environment, process, workflow or personnel. Incidents are events that indicate a possible compromise of security or noncompliance with policy that negatively impacts (or may negatively impact) the organization.
Although there is no single symptom to conclusively prove that a security incident has taken place, observing one or more of these symptoms should prompt an observer to investigate more closely. Do not spend too much time with the initial identification of an incident as this will be further qualified in the containment phase.

Assessment
Once a potential incident has been identified, part or all of the team will be activated to investigate the situation. The assessment will determine the category, scope, and potential impact of the incident. The team should work quickly to analyze and validate each incident, following the process outlined below, and documenting each step taken.

Incident Categorization
Our framework is based on a globally-accessible knowledge base of adversary tactics and techniques and should be leveraged when categorizing security incidents. While many techniques may be used in a single incident, select the method that was primarily leveraged by the adversary. Some examples of this may be:

  • Phishing
  • Unsecured Credentials
  • Network Sniffing
  • Man-in-the-Middle
  • Data Destruction
  • OS Credential Dumping
  • Event Triggered Execution • Account Creation
  • Disk Wipe
  •  Network Denial of Service
  • Resource Hijacking
  • Defacement
  • File and Directory Permissions Modification
  • It should be noted that our framework may not address some situations, specifically those without malicious intent, that trigger the Incident Response Management Plan. The following exceptions may require categories of their own as dictated by the organization’s Risk Management entities or policies:
  • Data Loss
  • Administrative Errors
  • Unsecured Credentials
  • Data Destruction
  • Lax File and Directory Permissions • Account Creation
  • Disk Wipe
  • Network Denial of Service
  • Resource Misuse (non-malicious)
  • ADD OTHERS AS APPLICABLE TO
    THE ORGANIZATION/INDUSTRY

Incident Scope
Determining the scope will help the TEAM understand the potential business impact of the incident. The following are some of the factors to consider when determining the scope:

  • How many systems are affected by this incident?
  • Is Confidential or Protected information involved?
  • What is/was the entry point for the incident (e.g. Internet, network, physical)?
  • What is the potential damage caused by the incident?
  • What is the estimated time to recover from the incident?
  • What resources are required to manage the situation?
  • How could the assessment be performed most effectively?

Incident Impact
Once the categorization and scope of an incident has been determined, the potential impact of the incident must be agreed upon. The severity of the incident will dictate the course of action to be taken in order to provide a resolution; however, in all instances an incident report must be completed (this can be done in the form of a support ticket if appropriate). Functional and informational impacts are defined with initial response activity below:

Phase III – Containment and Intelligence
The objective of the containment phase of the incident response is to regain control of the situation and limit the extent of the damage. To achieve this objective, our team has defined a number of containment strategies relevant to a variety of incident types. Reference the procedures related to one or more of the Containment Strategies listed below.

Containment Strategies
Use the list of strategies below to choose the procedure(s) most appropriate for the situation. If none of these strategies match the current situation, refer to Common Containment Steps listed below.
• Stolen credentials – disable account credentials, reset all active connections, review user activity, reverse changes, increase alerting, harden from future attacks.
• Ransomware – isolate the impacted system, validate the ransomware claim, identify whether additional systems have been impacted and isolate as needed
If DOS/DDOS – control WAN/ISP.
• Virus outbreak – contain LAN/system.
• Data loss – review user activity, implement data breach response procedures.
• Website defacement – repair site, harden from future attacks.
• Compromised API – review changes made, repair API, harden from future attacks.

Common Containment Steps
Containment requires critical decision-making related to the nature of the incident. The team should review all the containment steps listed below to formulate a strategy to contain and limit damages resulting from the incident.
All attempts to contain the threat must consider every effort to minimize the impact to the business operations. Third-party resources or interested parties may need to be notified. Where law enforcement may become involved, efforts must be made to preserve the integrity of relevant forensic or log data and maintain a clear chain-of-custody. Where evidence cannot be properly maintained due to containment efforts, the introduced discrepancy must be documented.
When evaluating containment steps, consider the following:
• Enable disposable Administrative accounts for use during the investigation and reset associated passwords if believed to have been at risk of compromise while in being used. (See Phase I – Preparation Details)
• Will the ability to provide critical services be impacted? How? For how long?
• When should the Cyber insurance carrier be notified?
• Is a legal investigation or other action likely? Does evidence need to be preserved?
• How likely is the containment step to succeed? What is the end result, full containment or partial?
• What resources are required to support the containment activity?
• What is the potential damage to equipment and other resources?
• What is the expected duration of the solution? (temporary, short-term, long-term, or permanent)
• Should IR team members act discretely to attempt to hide their activities from the attacker?
• Is the assistance of a third party required? What is the expected response time?
• Do interested parties (customers, partners, investors) need to be notified? If so, when?
• Does the impact to equipment, network, or facilities necessitate the activation of the Disaster Recovery Plan?
• Does the data impacted include protected data such as cardholder data? If yes, refer to Notification Requirements.

Preserve Evidence
NOTE: If there is strong reason to believe that a criminal or civil proceeding is likely, the (Company) Chain of Custody form (location) must be used any time evidence has been taken into custody, or custody is transferred for the purpose of investigation. For incidents involving cardholder data, Visa has defined specific requirements to be followed to preserve evidence and facilitate the investigation.
Consult legal counsel regarding applicable laws and regulations related to evidence collection and preservation. Create a detailed log for all evidence collected, including:
• Identification information (e.g. serial number, model, hostname, MAC address, IP address, or other identifier).
• Name and contact information for all individuals who have handled the evidence during the investigation.
• Date and time of each transfer or handling of the evidence.
• List of all locations where the evidence was stored.
• Deviations from SOP and associated justifications.

Reduce Impact
Depending on the type of incident, the team must act quickly to reduce the impact to affected systems and/or reduce the reach of the attacker. Actions may include, but are not limited to the following:
• Stop the attacker using access controls (disabling accounts, resetting active connections, changing passwords, implementing router ACLs or firewall rules, etc.).
• Isolate compromised systems from the network.
• Avoid changing volatile state data or system state data early on.
• Identify critical external systems that must remain operational (e.g. email, client application, DNS) and deny all other activity.
• Maintain a low profile, if possible, to avoid alerting an attacker that you are aware of their presence or giving them an opportunity to learn the TEAM’s tactics, techniques, or procedures.
• To the extent possible, consider preservation of system state for further investigation or use as evidence.

Conduct Research
Performing an Internet search, consulting third party resources, and/or consulting IT Insurance carrier using the apparent symptoms and other information related to the incident you are experiencing may lead to more information on the attack. For example, if the insurance carrier has received multiple reports of similar incidents, or if a mailing list message contains the same IP or text of the message you received.

Notify Interested Parties
Once an incident has been identified, determine if there are others who need to be notified, both internal (e.g. human resources, legal, finance, communications, business owners, etc.) and external (e.g. service providers, government, public affairs, media relations, customers, general public, etc.). Always follow the “need to know” principle in all communications. Most importantly, remain factual and avoid speculation.
Depending on the degree of sensitivity of the incident, it may be necessary for Legal/Management to require employees to sign NDAs or issue gag orders to employees who need to be involved.

Key Decisions for Exiting Containment Phase
• The attacker’s ability to affect the network has been effectively controlled/stopped.
• The affected system(s) are identified.

Investigation
As the team works to contain, eradicate, and recover from the incident, the investigation will be ongoing. As the investigation proceeds, you may find that the incident is not fully contained, eradicated, or recovered. If that is the situation, additional it may be necessary to revisit earlier phases. The Containment, Eradication, and Recovery phases are frequently cyclical.
The investigation attempts to fully identify all systems, services, and data impacted by the incident, including root cause analysis, which helps to determine the entry point of an attacker or weakness in the system that allowed the event to escalate into an incident.

A third party may need to be contracted if investigation is beyond the skills of the team, impacted systems are owned by a Cloud Service Provider, or forensic analysis is required.

Phase IV – Eradication Details
The Eradication consists of full elimination of all components of the incident.

Eradication
Steps to eradicate components of the incident may include:
• Disable breached user accounts.
• Reset any active sessions for breached accounts.
• Identify and mitigate vulnerabilities leveraged by the attacker.
• Close unnecessary open ports.
• Increase authentication security measures (implement MFA, add geolocation restrictions).
Increase security logging, alerting, and monitoring.
• Clean installation of affected operating systems and applications.
All re-installed operating systems and applications must be installed according to system build standards, including but not limited to:
A. Applying all the latest security patches.
B. Disabling all unnecessary services.
C. Installing anti-virus software.
D. Applying hardened system configuration baselines.
E. Changing all account passwords (including domain, user and service accounts).
NOTE: It may be possible to restore the system without the need to perform a full clean installation. IT personnel, at the direction of the TEAM, will make this determination.

Key Decisions for Exiting Eradication Phase
• Has the root cause been identified and identified vulnerabilities been remediated?
• Have all impacted accounts, including TEAM burner credentials been reset?
• TEAM is confident that the network and systems are configured to eliminate a repeat occurrence.
• There is no evidence of repeat events or incidents.
• Sign-off from IR Manager for limited-severity incidents or CIO for moderate and critical-severity incidents

Phase V – Recovery Details
Prior to restoring systems to normal operation, it is critical that the TEAM validate the system(s) to determine that eradication was successful, and the network is secure. Once the organization has been attacked successfully, the same attackers will often attack again using the same tools and techniques leveraged in the initial attack. Having gained access to the compromised system(s) or network once, the attacker has more information at their disposal to leverage in future attacks.
Recovery steps may include:
• Restoring systems from a clean backup.
• Replacing corrupted data from a clean backup.
• Restoring network connections and access rules.
• Communicating with interested parties about changes related to increased security.
• Increasing network and system monitoring activities (short or long-term).
• Increasing internal communication/reporting related to monitoring.
• Engaging a third party for support in detecting or preventing future attacks.

Key Decisions for Exiting Recovery Phase
• Have business operations been restored?

Phase VI – Lessons Learned
The follow-up phase includes reporting and post-incident analysis on the system(s) that were the target of the incident and other potentially vulnerable systems. The objective of this phase is continued improvement to applicable security operations, response capabilities, and procedures.

Lessons Learned and Remediation
The team will meet with relevant parties (technical staff, management, vendors, security team, etc.) to discuss and incorporate lessons learned from the incident to mitigate the risk of future incidents. Based on understanding of the root cause, steps will be taken to strengthen and improve information systems, policies, procedures, safeguards, and/or training as necessary. Where mitigations or proposed changes are rejected, a Risk Acceptance Process must be followed. Incidents should be analyzed to look for trends and corrective action should be considered where appropriate.
Lessons Learned discussion should cover:
• Review of discovery and handling of incident(s).
• How well staff and management performed and whether documented procedures were followed.
• Review of actions that slowed or hindered recovery efforts.
• Proposed improvements to future response and communication efforts.
• Recommendations to increase the speed of future detection and response efforts.
• Recommendations for long and short-term remediation efforts.

Key Decisions for Exiting Lessons Learned Phase
• Management is satisfied that the incident is closed.
o IR Manager makes the decision for limited-severity incidents. CIO makes the decision for moderate and critical-severity incidents.
• There is an action plan to respond to operational issues which arose from this incident. At this point, it is time to return to the Preparation Phase.

Customers
• All customers who are affected by the incident must be notified according to applicable contract language, service level agreements (SLAs), applicable statutes and/or regulations.
• Communications with customers must be consistent, with the same or similar message delivered to each. The message sent to customers will be created by members of the Communications Team.
• Customer service and/or customer account managers will communicate with customers according to the message developed by the Communications Team.

The Preparation phase is easily the most important and often overlooked phase. Without proper preparation incident response activities may be disorganized, expensive, and could cause irreparable harm to organizations. Tasks included in the Preparation phase include but are not limited to the following:
– Ensure appropriate parties are aware of incident reporting processes.
– Document and share cyber insurance details with appropriate parties.
– Validate Logging, Alerting, and Monitoring policy compliance.
– Ensure the team receives appropriate training based on skill gap analysis, career development efforts, and skill retention needs.
– Ensure the team has access to the tools and equipment needed based on estimated ROI and the organization’s risk appetite.
– Define and document standard operating procedures and workflows for team.
– Improve documentation, checklists, references, etc.
– Maintain and validate Network Diagrams and Asset Inventories.
– Review Penetration Test reports and validate remediations to findings.
– Review Vulnerability Management reports and validate remediation efforts.
– Establish disposable and disabled Administrative credentials to be enabled and used for investigations.
Finally, it should be noted that the Phase I is continuous or at least cyclical as incidents are brought to conclusion.

Reporting Incidents
Effective ways for both internal and outside parties to report incidents is equally critical as sometimes
users of systems and information may be the first to observe a problem. Review the different types of incidents addressed in Phase II under Incident Categorization and list or establish reporting methods for a variety of incident types.

Phase II – Identification and Assessment Identification
When a employee or external party notices a suspicious anomaly in data, a system, or the network, or a system alert generates an event, Security Operations, Help Desk, or TEAM must perform an initial investigation and verification of the event.
Events are observed changes in normal behavior of the system, environment, process, workflow or personnel. Incidents are events that indicate a possible compromise of security or noncompliance with policy that negatively impacts (or may negatively impact) the organization.
Although there is no single symptom to conclusively prove that a security incident has taken place, observing one or more of these symptoms should prompt an observer to investigate more closely. Do not spend too much time with the initial identification of an incident as this will be further qualified in the containment phase.

Assessment
Once a potential incident has been identified, part or all of the team will be activated to investigate the situation. The assessment will determine the category, scope, and potential impact of the incident. The team should work quickly to analyze and validate each incident, following the process outlined below, and documenting each step taken.

Incident Categorization
Our framework is based on a globally-accessible knowledge base of adversary tactics and techniques and should be leveraged when categorizing security incidents. While many techniques may be used in a single incident, select the method that was primarily leveraged by the adversary. Some examples of this may be:

  • Phishing
  • Unsecured Credentials
  • Network Sniffing
  • Man-in-the-Middle
  • Data Destruction
  • OS Credential Dumping
  • Event Triggered Execution
  • Account Creation
  • Disk Wipe
  • Network Denial of Service
  • Resource Hijacking
  •  Defacement
  • File and Directory Permissions Modification

    It should be noted that our framework may not address some situations, specifically those without malicious intent, that trigger the Incident Response Management Plan. The following exceptions may require categories of their own as dictated by the organization’s Risk Management entities or policies:

  • Data Loss
  • Administrative Errors
  • Unsecured Credentials
  • Data Destruction
  • Lax File and Directory Permissions • Account Creation
  • Disk Wipe
  • Network Denial of Service
  • Resource Misuse (non-malicious)
  • ADD OTHERS AS APPLICABLE TO
    THE ORGANIZATION/INDUSTRY

Incident Scope
Determining the scope will help the TEAM understand the potential business impact of the incident. The following are some of the factors to consider when determining the scope:

  • How many systems are affected by this incident?
  • Is Confidential or Protected information involved?
  • What is/was the entry point for the incident (e.g. Internet, network, physical)?
  • What is the potential damage caused by the incident?
  • What is the estimated time to recover from the incident?
  • What resources are required to manage the situation?
  • How could the assessment be performed most effectively?

Incident Impact
Once the categorization and scope of an incident has been determined, the potential impact of the incident must be agreed upon. The severity of the incident will dictate the course of action to be taken in order to provide a resolution; however, in all instances an incident report must be completed (this can be done in the form of a support ticket if appropriate). Functional and informational impacts are defined with initial response activity below:

Phase III – Containment and Intelligence
The objective of the containment phase of the incident response is to regain control of the situation and limit the extent of the damage. To achieve this objective, our team has defined a number of containment strategies relevant to a variety of incident types. Reference the procedures related to one or more of the Containment Strategies listed below.

Containment Strategies
Use the list of strategies below to choose the procedure(s) most appropriate for the situation. If none of these strategies match the current situation, refer to Common Containment Steps listed below.

  • Stolen credentials – disable account credentials, reset all active connections, review user activity, reverse changes, increase alerting, harden from future attacks.
  • Ransomware – isolate the impacted system, validate the ransomware claim, identify whether additional systems have been impacted and isolate as needed
    If DOS/DDOS – control WAN/ISP.
  • Virus outbreak – contain LAN/system.
  • Data loss – review user activity, implement data breach response procedures.
  • Website defacement – repair site, harden from future attacks.
  • Compromised API – review changes made, repair API, harden from future attacks.

Common Containment Steps
Containment requires critical decision-making related to the nature of the incident. The team should review all the containment steps listed below to formulate a strategy to contain and limit damages resulting from the incident.
All attempts to contain the threat must consider every effort to minimize the impact to the business operations. Third-party resources or interested parties may need to be notified. Where law enforcement may become involved, efforts must be made to preserve the integrity of relevant forensic or log data and maintain a clear chain-of-custody. Where evidence cannot be properly maintained due to containment efforts, the introduced discrepancy must be documented.
When evaluating containment steps, consider the following:

  • Enable disposable Administrative accounts for use during the investigation and reset associated passwords if believed to have been at risk of compromise while in being used. (See Phase I – Preparation Details)
  • Will the ability to provide critical services be impacted? How? For how long?
  • When should the Cyber insurance carrier be notified?
  • Is a legal investigation or other action likely? Does evidence need to be preserved?
  • How likely is the containment step to succeed? What is the end result, full containment or partial?
  • What resources are required to support the containment activity?
  • What is the potential damage to equipment and other resources?
  • What is the expected duration of the solution? (temporary, short-term, long-term, or permanent)
  • Should IR team members act discretely to attempt to hide their activities from the attacker?
  • Is the assistance of a third party required? What is the expected response time?
  • Do interested parties (customers, partners, investors) need to be notified? If so, when?
  • Does the impact to equipment, network, or facilities necessitate the activation of the Disaster Recovery Plan?
  • Does the data impacted include protected data such as cardholder data? If yes, refer to Notification Requirements.

Preserve Evidence
NOTE: If there is strong reason to believe that a criminal or civil proceeding is likely, the (Company) Chain of Custody form (location) must be used any time evidence has been taken into custody, or custody is transferred for the purpose of investigation. For incidents involving cardholder data, Visa has defined specific requirements to be followed to preserve evidence and facilitate the investigation.
Consult legal counsel regarding applicable laws and regulations related to evidence collection and preservation. Create a detailed log for all evidence collected, including:

  • Identification information (e.g. serial number, model, hostname, MAC address, IP address, or other identifier).
  • Name and contact information for all individuals who have handled the evidence during the investigation.
  • Date and time of each transfer or handling of the evidence.
  • List of all locations where the evidence was stored.
  • Deviations from SOP and associated justifications.

Reduce Impact
Depending on the type of incident, the team must act quickly to reduce the impact to affected systems and/or reduce the reach of the attacker. Actions may include, but are not limited to the following:

  • Stop the attacker using access controls (disabling accounts, resetting active connections, changing passwords, implementing router ACLs or firewall rules, etc.).
  • Isolate compromised systems from the network.
  • Avoid changing volatile state data or system state data early on.
  • Identify critical external systems that must remain operational (e.g. email, client application, DNS) and deny all other activity.
  • Maintain a low profile, if possible, to avoid alerting an attacker that you are aware of their presence or giving them an opportunity to learn the TEAM’s tactics, techniques, or procedures.
  • To the extent possible, consider preservation of system state for further investigation or use as evidence.

Conduct Research
Performing an Internet search, consulting third party resources, and/or consulting IT Insurance carrier using the apparent symptoms and other information related to the incident you are experiencing may lead to more information on the attack. For example, if the insurance carrier has received multiple reports of similar incidents, or if a mailing list message contains the same IP or text of the message you received.

Notify Interested Parties
Once an incident has been identified, determine if there are others who need to be notified, both internal (e.g. human resources, legal, finance, communications, business owners, etc.) and external (e.g. service providers, government, public affairs, media relations, customers, general public, etc.). Always follow the “need to know” principle in all communications. Most importantly, remain factual and avoid speculation.
Depending on the degree of sensitivity of the incident, it may be necessary for Legal/Management to require employees to sign NDAs or issue gag orders to employees who need to be involved.

Key Decisions for Exiting Containment Phase

  • The attacker’s ability to affect the network has been effectively controlled/stopped.
  • The affected system(s) are identified.

Investigation
As the team works to contain, eradicate, and recover from the incident, the investigation will be ongoing. As the investigation proceeds, you may find that the incident is not fully contained, eradicated, or recovered. If that is the situation, additional it may be necessary to revisit earlier phases. The Containment, Eradication, and Recovery phases are frequently cyclical.
The investigation attempts to fully identify all systems, services, and data impacted by the incident, including root cause analysis, which helps to determine the entry point of an attacker or weakness in the system that allowed the event to escalate into an incident.

A third party may need to be contracted if investigation is beyond the skills of the team, impacted systems are owned by a Cloud Service Provider, or forensic analysis is required.

Phase IV – Eradication Details
The Eradication consists of full elimination of all components of the incident.

Eradication
Steps to eradicate components of the incident may include:

  • Disable breached user accounts.
  • Reset any active sessions for breached accounts.
  • Identify and mitigate vulnerabilities leveraged by the attacker.
  • Close unnecessary open ports.
  • Increase authentication security measures (implement MFA, add geolocation restrictions).
  • Increase security logging, alerting, and monitoring.
  • Clean installation of affected operating systems and applications.

All re-installed operating systems and applications must be installed according to system build standards, including but not limited to:
A. Applying all the latest security patches.
B. Disabling all unnecessary services.
C. Installing anti-virus software.
D. Applying hardened system configuration baselines.
E. Changing all account passwords (including domain, user and service accounts).
NOTE: It may be possible to restore the system without the need to perform a full clean installation. IT personnel, at the direction of the TEAM, will make this determination.

Key Decisions for Exiting Eradication Phase

  • Has the root cause been identified and identified vulnerabilities been remediated?
  • Have all impacted accounts, including TEAM burner credentials been reset?
  • TEAM is confident that the network and systems are configured to eliminate a repeat occurrence.
  • There is no evidence of repeat events or incidents.
  • Sign-off from IR Manager for limited-severity incidents or CIO for moderate and critical-severity incidents

Phase V – Recovery Details
Prior to restoring systems to normal operation, it is critical that the TEAM validate the system(s) to determine that eradication was successful, and the network is secure. Once the organization has been attacked successfully, the same attackers will often attack again using the same tools and techniques leveraged in the initial attack. Having gained access to the compromised system(s) or network once, the attacker has more information at their disposal to leverage in future attacks.
Recovery steps may include:

  • Restoring systems from a clean backup.
  • Replacing corrupted data from a clean backup.
  • Restoring network connections and access rules.
  • Communicating with interested parties about changes related to increased security.
  • Increasing network and system monitoring activities (short or long-term).
  • Increasing internal communication/reporting related to monitoring.
  • Engaging a third party for support in detecting or preventing future attacks.

Key Decisions for Exiting Recovery Phase

  • Have business operations been restored?

Phase VI – Lessons Learned
The follow-up phase includes reporting and post-incident analysis on the system(s) that were the target of the incident and other potentially vulnerable systems. The objective of this phase is continued improvement to applicable security operations, response capabilities, and procedures.

Lessons Learned and Remediation
The team will meet with relevant parties (technical staff, management, vendors, security team, etc.) to discuss and incorporate lessons learned from the incident to mitigate the risk of future incidents. Based on understanding of the root cause, steps will be taken to strengthen and improve information systems, policies, procedures, safeguards, and/or training as necessary. Where mitigations or proposed changes are rejected, a Risk Acceptance Process must be followed. Incidents should be analyzed to look for trends and corrective action should be considered where appropriate.
Lessons Learned discussion should cover:

  • Review of discovery and handling of incident(s).
  • How well staff and management performed and whether documented procedures were followed.
  • Review of actions that slowed or hindered recovery efforts.
  • Proposed improvements to future response and communication efforts.
  • Recommendations to increase the speed of future detection and response efforts.
  • Recommendations for long and short-term remediation efforts.

Key Decisions for Exiting Lessons Learned Phase

  • Management is satisfied that the incident is closed.
    • IR Manager makes the decision for limited-severity incidents. CIO makes the decision for moderate and critical-severity incidents.
  • There is an action plan to respond to operational issues which arose from this incident. At this point, it is time to return to the Preparation Phase.

Customers

  • All customers who are affected by the incident must be notified according to applicable contract language, service level agreements (SLAs), applicable statutes and/or regulations.
  • Communications with customers must be consistent, with the same or similar message delivered to each. The message sent to customers will be created by members of the Communications Team.
  • Customer service and/or customer account managers will communicate with customers according to the message developed by the Communications Team.