Incident Response

Incident Response

Overview

The principal intent of the Incident Response controls is to establish and maintain a capability to guide the organization’s response when security or privacy-related incidents occur and to train users how to detect and report potential incidents.

This Incident Response Procedure (IRP) outlines the common cybersecurity attack vectors that could occur in the FrontRunnerHC enterprise, and provides the fundamental steps necessary to respond to, and remediate those threats.

1.0. Procedure

1.1. Common Attack Vectors

The attack vectors listed below are not intended to provide definitive classification for incidents; rather, they simply list common methods of attack, which can be used as a basis for defining more specific handling procedures.

1.1.1 Ransomware

Ransomware is a form of malware that targets both human and technical weaknesses in organizations and individual networks to deny the availability of critical data and systems. Ransomware is frequently delivered through spear phishing emails to end users. When the victim organization determines they are no longer able to access their data, the cyber actor demands the payment of a ransom, at which time the actor will purportedly provide an avenue to the victim to regain access to their data. Recent iterations target enterprise end users, making awareness and training a critical preventative measure.

Ransomware continues to be a major disruptor for companies as they are either dealing with an outbreak or are worried that their defense measures are inadequate to prevent an outbreak. New variants of ransomware are finding their way into the mainstream on a regular basis. Older variants are still active in the wild due to companies not addressing the basic security measures that can all but eliminate the possibility of contracting a ransomware outbreak on their network.

Common Ransomware types:

• Locker Ransomware: Denies access to the computer or device.
• Crypto Ransomware: Prevents access to files or data usually using encryption.

Common signs of Ransomware:

• Encryption of personal files/folders.
• Demand of payment to access files.
• Internet browsers that will not close.
• Internal traffic routing to suspicious internet addresses.
• Files with extensions that are not recognized by the computer.
• Suspicious programs running on the computer.

1.1.2 Phishing

Phishing is a form of fraud in which the attacker tries to learn information such as login credentials or account information by masquerading as a reputable entity or person in email, instant messaging, or other communication channels. Phishing is a common attack sign of many different types of security incidents.

Common Phishing techniques:

• Posing as a member of the IT department asking the user to reset their password or other credentials.
• Phone calls requesting the user to disclose private information such as passwords, IP addresses, etc.
• Emails requesting the user to verify, update, or change private information such as passwords, usernames, etc.

1.1.3 Email Attacks

Email is one of the most common areas of a company that is targeted for attack. Many email attacks lead to other security incidents identified here such as ransomware, phishing, spam, and virus outbreaks.

Common methods of attacking through email:

• Spam
• Ransomware
• Phishing
• Infected Attachments
• Infected links
• Man in the Middle attacks through compromising data that is sent unencrypted.

1.1.4 Virus Outbreak

• Worms: This program is very similar to a virus and can self-replicate leading to negative effects on your computer.
• Trojans: Trojans can illegally trace important login details of users online.
• Email: This is a virus spread via an email. Such a virus will hide in an email and when the recipient opens the email, an attachment in the email, or clicks on an internet link in the email the virus will infect the machine on which the email client resides and may attempt to propagate to connected network devices, as well as contacts in the client’s email address book.
• Browser Hijack: This virus can spread in many ways including a voluntary download. It may affect certain browser functions, especially in the form of re-directing the user automatically to certain sites.

1.1.5 Other Attack Vectors

• External/Removable Media: An attack executed from removable media or a peripheral device, for example, malicious code spreading onto a system from an infected USB flash drive.
• Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services; for example, a Distributed Denial of Service (DDOS) attack intended to impair or deny access to a service or application; a brute force attack against an authentication mechanism, such as passwords, CAPTCHAS, or digital signatures.
• Web: An attack executed from a website or web-based application; for example, a cross-site scripting attack used to steal credentials or a redirect to a site that exploits a browser vulnerability and installs malware.
• Impersonation: An attack involving replacement of something benign with something malicious; for example, spoofing, man in the middle attacks, rogue wireless access points, and SQL injection attacks all involve impersonation.
• Improper Usage: Any incident resulting from violation of an organization’s acceptable usage policies by an authorized user, excluding the above categories; for example, a user installs file sharing software, leading to the loss of sensitive data; or a user performs illegal activities on a system.
• Loss or Theft of Equipment: The loss or theft of a computing device or media used by the organization, such as a laptop, smartphone, or authentication token.
• Other: An attack that does not fit into any of the other categories.

1.2. Common Wireless Attack Vectors

The following are some of the common methods used to attack wireless networks. These methods are widely documented on the Internet, complete with downloadable software and instructions.

• Eavesdropping: An attacker can gain access to a wireless network by “listening” to traffic. Radio transmissions can be freely and easily intercepted by nearby devices or laptops. The sender or intended receiver has no means of knowing whether the transmission has been intercepted.
• Rogue Access: If a wireless Local Area Network (LAN) is part of an enterprise network, a compromise of the LAN may lead to the compromise of the enterprise network. An attacker with a rogue access point can fool a mobile station into authenticating with the rogue access point, thereby gaining access to the mobile station. This is known as a “trust problem,” and the only protection against it is an efficient access authentication mechanism.
• Denial of Service (DOS): Due to the nature of radio transmission, wireless LANs are vulnerable to denial-of-service attacks and radio interference. DOS attacks can be used to disrupt business operations or to gather additional information for use in initiating another type of attack.
• Man in the Middle (MITM): A MITM attack includes using packet spoofing and impersonation, whereby traffic is intercepted midstream then redirected by an unauthorized individual for malicious purposes.

1.3. Signs of an Incident

Signs of an incident fall into one of two categories: precursors and indicators. A precursor is a sign that an incident may occur in the future. An indicator is a sign that an incident may have occurred or may be occurring now. While precursors are relatively rare, indicators are common. When an incident has been confirmed or analysis has not eliminated the possibility of an incident, the FrontRunnerHC Information Technology first responder should notify the Information Security Officer, if the Information Security Officer is unavailable the CEO should be notified.

Examples of precursors are:

• Web server log entries that show the usage of a vulnerability scanner.
• An announcement of a new exploit that targets a vulnerability of the organization’s mail server.
• A threat from a group stating that the group will attack the organization. Examples of indicators are:
• Files that are encrypted and inaccessible.
• An employee that fails to comply with FrontRunnerHC’s security policies, procedures, or standards.
• Reports of denial of service affecting critical infrastructure or critical FrontRunnerHC systems.
• Any system external to and not owned by FrontRunnerHC that is being attacked by a FrontRunnerHC system.
• Unauthorized scanning of the network or systems.
• Any fraud, waste, or misuse of a FrontRunnerHC system.
• A network intrusion detection sensor alerts when a buffer overflow attempt occurs against a database server.
• Antivirus software alerts when it detects that a host is infected with malware.
• A system administrator sees a filename with unusual characters.
• A host records an auditing configuration change in its log.
• An application logs multiple failed login attempts from an unfamiliar remote system.
• An email administrator sees many bounced emails with suspicious content.
• A network administrator notices an unusual deviation from typical network traffic flows.

2. Incident Reporting

To report a suspected cyber-security incident, any FrontRunnerHC employee or contractor may call the ISO. The following will be recorded:

• Date & Time call was received.
• The person reporting the incident, name, and department where person works.
• The reason the caller suspects an incident.
• If the caller knows, gather details about the involved computer (e.g., name, location, IP address, etc.).

When a member of the IT team is contacted, they become the First Responder and are responsible for the initial investigation of the suspected incident. If patient care operations are involved, the First Responder must activate the Incident Response Procedure (IRP) immediately. As soon as the First

Responder suspects the reporting MAY be an incident, the IRP will be activated, and he/she must record the current time of the event. Proper documentation and timing of events is very important for legal purposes.

3. Activating the Incident Response Procedure

As soon as the First Responder suspects the reporting MAY be an incident, the IRP will be activated. The process for activation begins when an end-user workforce member contacts the ISO.

Upon contact, the ISO begins to collect and document information. Through this assessment process, the ISO will determine if an incident has actually occurred, attempt to resolve the incident, and determine whether to escalate matters to the Incident Response Team (IRT).

4. Incident Response Handling

Once notified of a suspected incident, if possible, the notified member of the IRT should enlist the aid of a second IRT member. The IRT should work quickly to analyze and validate each incident following a pre- defined process and documenting each step taken. An IRT member that suspects that an incident has occurred should immediately start recording all facts regarding the incident. The actual date and time of the suspected incident must be recorded along with the date and time the incident is confirmed or dispelled. As a note of precaution, it is best to not power off or reboot a compromised system as this may result in the loss of data, information, or evidence required for forensic investigation later, although this may not be possible as the fastest and most effective form of containment may require powering the system off.

Utilize the Incident Handling Checklist (General) spreadsheet file to guide investigation of the incident.

4.1. Requirements to Address Incidents

To respond promptly to suspected incidents, FrontRunnerHC IT must be prepared with key system lists as well as tools to respond to various events.

4.1.1. System Lists

FrontRunnerHC must create and keep up to date a list of all systems in operation on the network. Additionally, recovery checklists must be in place to ensure proper restore of operations in the case of an incident.

The following items should be included in an “Incident Response Toolkit”. This toolkit should be secured for only members of the IT department that will be conducting Incident handling and should be in an easy to carry bag.

• A copy of the IRP.
• A hardcopy journal for taking notes during assessment.
• A quick chart of all IRT members that is updated regularly with contact information.
• USB drives
• Bootable USB or CD drives with up-to-date anti-malware, antivirus, and other software that can read/write to file system. This should be tested regularly.
• A laptop with forensic software to trouble shoot issues.
• Computer and network tool kits such as network cables, hard drive duplicators (write block enabled to preserve forensic evidence), toners, etc.

4.2. Identification

When the first IRT member(s) believes that an incident has occurred, the full team should be notified. The team should rapidly perform an initial analysis to determine the incident’s scope, such as which networks, systems, or applications are affected, who or what originated the incident, and how the incident is occurring (e.g., what tools or attack methods are being used, what vulnerabilities are being exploited). The initial analysis should provide enough information for the team to determine that an incident has occurred and then to prioritize subsequent activities such as containment of the incident and deeper analysis of the effects of the incident.

If the team determines this reporting is a false positive and no incident has occurred, the results of the investigation, which lead to this finding, must be fully documented as per Section 5.8 of this document. An important step for FrontRunnerHC during the identification phase is to determine if the incident may possibly affect patient care operations in any way. If there is a possibility that patient care operations have been compromised, then FrontRunnerHC’s CEO or authorized designee must be notified immediately (refer to the Incident Response Team Contact list in Section 7 of this document).

Detecting Security Events

Security events can be detected through a variety of technical and procedural mechanisms. Technical mechanisms include intrusion detection/prevention systems (IDS/IPS), log aggregation systems, and firewalls which produce alerts when suspicious network activity occurs. Procedural mechanisms include system log reviews, observations of abnormal resource utilization, and suspicious account activity. Additionally, sources external to FrontRunnerHC may detect issues by recognizing unauthorized activity or abnormal behavior on their systems and reporting the activity.

Keep in mind that some legitimate network monitors and protocol analyzers will set a network interface in promiscuous mode. Detecting an interface in promiscuous mode does not necessarily mean that a sniffer is running on a system. If a sniffer has been installed on a system, examine the output file from the sniffer, if available, to determine what other machines or accounts are at risk. Machines at risk are those that appear in the destination field of a captured packet, but if passwords across systems are common or if the source and destination machines trust each other, the source machine will also be at further risk. Additionally, it is important to note that some sniffers encrypt their logs so they may not be obvious. Because of this, check for files that grow quickly.

Be aware there may be other machines at risk in addition to the ones that appear in the sniffer log. This may be because the intruder has obtained previous sniffer logs from local systems or through other attack methods.

Typical and initial indications of security incidents include any of the following:

• Encrypted files that are inaccessible.
• A system alarm or similar indication from an intrusion detection tool.
• Suspicious entries in system or network accounting (e.g., a user obtains privileged access without using authorized methods).
• Accounting discrepancies (e.g., someone notices an 18-minute gap in the accounting log for which there is no correlation).
• Unsuccessful logon attempts.
• New user accounts of unknown origin.
• New files of unknown origin and function.
• Unexplained changes or attempts to change file sizes, check sums, and date/time stamps, especially those related to system binaries or configuration files.
• Unexplained addition, deletion, or modification of data.
• Denial of service activity or inability of one or more users to login to an account; including admin/root logins at the console.
• System crashes.
• Poor system performance.
• Unauthorized operation of a program or the addition of a sniffer application to capture network traffic or usernames/passwords.
• Port/System Scanning (use of exploit and vulnerability scanners, using network aware applications or utilities for information gathering about systems and/or users).
• Unusual usage times (statistically, more security incidents occur during non-working hours than any other time).
• An indicated last time of usage of an account that does not correspond to the actual last time of usage for that account.
• Unusual usage patterns (e.g., programs are being compiled by the account of a user who does not know how to program).
• Social engineering attempts. Although observing one of these symptoms is generally inconclusive, observing multiple symptoms in conjunction is motivation for further scrutiny.

4.3. Assessment

Once the IRT has determined that an actual security incident has or is taking place, the next step is to assess the scope, the impact, and the magnitude of the incident. The following are considerations to help classify the incident:

Functional Impact of the Incident

Incidents targeting IT systems typically impact the business functionality that those systems provide, resulting in some type of negative impact to the users of those systems. Incident handlers should consider how the incident will impact the existing functionality of the affected systems. Incident handlers should consider not only the current functional impact of the incident, but also the likely future functional impact of the incident if it is not immediately contained.

Questions to ask are:

• How many computers are affected by this incident?
• How many users are affected?
• What is the entry point of the incident (e.g., network, phone dial)?
• How should the assessment be performed effectively?

After reviewing the data, select a Functional Impact from the table below:

Level	Effect
None	No effect to the organization’s ability to provide all services to all users
Low	Minimal effect, the organization can still provide all critical services to all users but has lost efficiency
Medium	The organization has lost the ability to provide a critical service to a subset of system users
High	The organization is no longer able to provide some critical services to any users

Information Impact of the Incident

Incidents may affect the confidentiality, integrity, and availability of the organization’s information. For example, a malicious agent may exfiltrate sensitive information. Incident handlers should consider how this information exfiltration will impact the organization’s overall mission. An incident that results in the exfiltration of sensitive information may also affect other organizations if any of the data pertained to a partner organization.

Questions to ask include:

• Are patient care operations involved or potentially involved? If yes, FrontRunnerHC’s CEO or authorized designee must be notified immediately.
• Is sensitive information involved?
• What is the potential damage caused by the incident?

After reviewing the data, select an Information Impact from the table below:

Breach	Impact
None	No information was exfiltrated, changed, deleted, or otherwise compromised
Privacy	Breach Sensitive protected health information (PHI) or personally identifiable information (PII) of employees, patients, etc. was accessed or exfiltrated. Refer to Breach Notification Procedure for more information and if further action is required.
Proprietary Breach	Unclassified proprietary information, such as protected critical infrastructure information (PCII), was accessed or exfiltrated.
Integrity Loss	Sensitive or proprietary information was changed, encrypted, or deleted

Recoverability from the Incident

The size of the incident and the type of resources it affects will determine the amount of time and resources that must be spent on recovering from that incident.

Questions to ask include:

• 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?

After reviewing the data, select a Recovery Impact from the table below:

Recovery	Impact
Regular	Time to recovery is predictable with existing resources
Supplemented	Time to recovery is predictable with additional resources
Extended	Time to recovery is unpredictable, additional resources and outside help are needed
Not Recoverable	Recovery from the incident is not possible (e.g., sensitive data exfiltrated and posted publicly), an investigation should be launched.

4.3.1. Classifying an Event

The next step is to classify the event based upon FrontRunnerHC’s specific categories according to the impact guidelines. It is important to note that these classifications can change over time as more information about the incident becomes available. Those classifications are:

Extreme – These incidents can potentially affect human life or cause irreversible loss of company resources. High – These incidents may affect the integrity or confidentiality of data, which may result in direct loss of business and/or reputation, e.g., loss of large quantities of proprietary information. Medium – These incidents typically affect the availability of information, but not data integrity, e.g., encountering network failures. Low – These incidents may affect the functionality of the systems or create other IT issues; however, no data loss has occurred. FrontRunnerHC should already be secured against these incidents, but constant surveillance may still be necessary to detect early signs of unauthorized activities. Insignificant – These incidents pose negligible risk to FrontRunnerHC.

FrontRunnerHC Classification	Functional Impact	Informational Impact	Recovery Impact
Extreme	High	Integrity, Loss/Proprietary, Breach/Large loss of Proprietary Information	Not Recoverable
High	High/Medium/Low/None	Integrity, Loss/Proprietary, Breach/Loss of Proprietary Information	Extended: Need additional resources and/or outside help
Medium	High/Medium	Privacy Breach/None	Supplemental: Predictable recovery time with additional resources (e.g., overtime or outside help)
Low	Low/None	No Data loss but system functions may be impacted	Regular or Supplemental
Insignificant	None	None	Regular

4.4. Containment

The objective of the containment phase is for the IRT to regain control of the situation by limiting the extent of the damage. The IRT may consider isolating the compromised system, which can include a single client machine, multiple clients within a single department or across multiple departments, a single server, multiple servers, mobile device(s), the entire data center, or any combination of these. Isolation from the rest of the network systems may disrupt the business operation if the compromised system is critical or multiple systems were affected by the incident, as in the example of a Ransomware attack. Hence, the IRT, along with management, must evaluate on a per case basis the risk of continuing operations versus regaining control of the compromised system. All attempts to contain the threat must consider every effort to minimize the impact to the business operations.

Furthermore, a backup of the compromised system should be performed to maintain the current (infected) state of the system to facilitate postmortem analysis and forensic investigation later. The IRT may also consider changing the system passwords to prevent the possibility of Trojan programs being installed on the compromised system that allows the intruder from returning to the system via a backdoor.

4.4.1. Wireless Containment

If the affected system uses a wireless network connection, the external network adapter may be unplugged from the computer or the internal network adapter may be disabled to sever the network connection. If neither option is possible, then powering off the wireless network access point that the computer is using should achieve the same result; however, doing so may prevent users outside the scope of the investigation from performing their daily routines. In addition, there could be more than one access point within range of the computer. Some wireless network adapters automatically attempt to connect to other access points when the primary access point is unavailable, so containing the incident in this way could involve disconnecting several access points.

4.4.2. Checking Other Systems on the Network

It is a good practice to check all systems related to the affected system, not just the one that is known to be compromised. This check should include any systems associated with the compromised system.

4.4.3. Checking for Systems Involved or Affected at Remote Sites

While examining log files, intruder output files, and any files modified or created during or since the time of the intrusion; also look for information that leads to another site that may be associated with the compromise. Frequently, additional sites associated with a compromised system (whether upstream or downstream) have also been victims. Therefore, it is important, responsible, and courteous to identify and notify all other potential victim sites as soon as possible.

4.5. Eradication

After the containment phase, further investigation should be performed to uncover the cause of the incident by analyzing system logs of various devices (e.g., firewall, router, host logs). It is important that the IRT uses a separate set of administrative tools for the investigation and not those in the compromised system. If the perpetrator has modified the system configuration, execution of any system tool may have dire consequences. For example, in some cases, Ransomware will limit the ability for internal tools to run and may give false information on the status of the machine.

Identify when it is necessary to consider the system too compromised to sanitize without completely rebuilding the system from scratch.

A clean operating system should be reloaded into the compromised server after the investigation. Many off-the-shelf operating systems are not developed with security in mind. Hence, to increase the security defense of the system, it must undergo a hardening process, which should include:

• Applying all the latest patches.
• Security Awareness Training.
• The Integrity of Backup and Restore Operations.
• Web Content Filtering (including blocking uncategorized sites).
• Countermeasures in Place (if an outbreak occurs).
• Disabling any unnecessary services.
• Installing anti-virus software.
• Applying FrontRunnerHC’s security policy to the system.

4.6. Recovery

Prior to restoring the system from a clean backup, it is recommended that the IRT validate that the eradication procedures have been properly performed. After installing the backup, the system should be monitored in a test environment to determine if it is functioning normally before it can be restored into the business operation.

Furthermore, a network surveillance tool should be implemented to detect any unauthorized attempts such as additional scans or probes that may signal the return of the intruder.

4.7. Postmortem Analysis

The objective of a postmortem analysis is to perform a detailed investigation of the incident to identify the extent of the incident and potential impact prevention mechanisms. Performing postmortem activities is one of the most critical activities in responding to incidents. This helps improve the incident response process as well as aiding in the continuing support of any efforts to prosecute those who have broken the law.

Post-mortem activity includes:

• Analyzing what has transpired and what was done to intervene.
• Determining if there was sufficient preparation to prevent the incident.
• Determining if detection occurred promptly. If not, why?
• Determining if additional tools have helped the detection and recovery process.
• Verifying that the incident was sufficiently contained.
• Analyzing communication and determining if it was adequate. If not, what could have improved communication?
• Analyzing any practical difficulties that were encountered.
• Determining if sensitive data could have been better protected.
• Determining if adequate administrative, technical, and/or physical controls are in place to mitigate any future incident(s). If not, recommendations for additional controls should be identified.
• Verifying that the work was performed within the stipulated time frames allocated to dealing with the incident (including time necessary to restore systems).
• An “Incident Report” should be created for any security incident. Answers to the following questions and any plans for mitigation of future incidents should be included in this report.
  • How much was the monetary cost of the incident, including all time required to respond and recover?
  • How much disruption did the incident cause?
  • Was any data irrecoverably lost or stolen, and, if so, what was the effect of the loss?
  • Was FrontRunnerHC’s sensitive data potentially compromised?
  • A timeline of the event should also be included in the report.

4.8. Documentation

The final incident report is titled with an id & tag: “Incident Report – IR00XX”. Every step taken from the time the incident was suspected to its final resolution must be documented and time stamped. Every document regarding the incident must also be dated and signed by the incident handler. Information of this nature may also be used as evidence in a court of law if legal prosecution is pursued. Whenever possible, handlers should work in teams of at least two; one person can record and log events while the other person performs the technical tasks.

The IRT should maintain records about the status of incidents along with other pertinent information. Using an application or a database, such as an issue tracking system, helps ensure that incidents are handled and resolved in a timely manner.

The documentation should contain information on the following:

• The status of the incident (new, in progress, forwarded for investigation, resolved, etc.).
• A summary of the incident.
• Indicators related to the incident.
• Other incidents related to the incident.
• Actions taken by all incident handlers on the incident.
• Chain of custody, if applicable.
• Impact assessments related to the incident.
• Contact information for other involved parties (e.g., system owners, system administrators).
• A list of evidence gathered during the incident investigation.
• Comments from incident handlers.
• The next steps to be taken (e.g., rebuild the host, upgrade an application).

The IRT should safeguard incident data and restrict access to it as it often contains sensitive information; for example, data on exploited vulnerabilities, recent security breaches, and users that may have performed inappropriate actions. For example, only authorized personnel should have access to the incident tracking system. Incident communications (e.g., emails) and documents should be encrypted or otherwise protected so that only authorized personnel can read them.

All details related to the incident response process should be documented and filed for easy reference. This documentation provides valuable information to unravel the course of events and serve as evidence if prosecution of intruders is necessary.

The following items should be maintained:

• All system events (audit records).
• All actions taken (including the time that an action is performed).
• All external conversations (including persons with whom the discussion was held, the date and time, and the content of the conversation).

Furthermore, an incident report documenting the following should be prepared as the final closing step:

• A description of the exact sequence of events.
• The method of discovery.
• Preventive measures put in place.
• An assessment to determine if the recovery step taken is sufficient and what other recommendations need to be considered.

The objective of the report is to identify potential areas of improvement in the incident handling and reporting procedures. Hence, the review of the report by management should be documented, together with the lessons learned, to improve on the identified areas. The report can then be used as reference for future incidents.

4.8.1. Forms

Use the Incident Response Checklists (Incident Response Checklists.xlsx) to stay on track throughout the incident.

The following checklists offer guidance for responding to a specific incident type and should be used in addition to the Incident Handling Checklist (General) (i.e., applicable to any incident type):

• Ransomware Incident Handling Checklist
• Phishing Incident Handling Checklist
• Virus Outbreak Incident Handling Checklist
• Incident Response Checklists
• Chain of Custody Form

Use the Incident Chain of Custody Form for any forensic evidence collected. Maintain any email communications in a manner such that it can be consolidated when it is time to perform the final documentation of the incident.

4.8.2. Final Report

A final report, which provides an overview of the incident, the actions taken, actions recommended, and lessons learned should be created at the end of each incident as part of the postmortem examination. The Final Incident Report must be released to the necessary audience so that they can learn about the incident response process even if they were not involved in responding to the incident in question. The report should be developed by the Information Security Officer and forwarded to the IRT and IT management for review. Full details of some incidents may need to be sanitized, depending on the intended audience.

4.8.3. Records Retention

Unless specified by another contract, policy, or procedure; all incident response records must be maintained and destroyed in accordance with section 11.2.7. of the Data Classification & Handling policy.

4.8.4. Review & Testing

The IRP should be reviewed for changes after an incident as part of the postmortem examination. Additionally, the IRP must be reviewed and tested on an annual basis. Finally, the IRT team should have in depth training on this incident response plan at least annually.

4.8.5. Revising policies, processes, standards, and procedures

Developing effective policies and procedures is an iterative process in which feedback from follow up activity is essential. The Final Incident Report should be used as the basis for modifying FrontRunnerHC Policies and Incident Handling Procedures.

5.0. Media & External Communications

When an incident happens, it may be of extreme interest to the media and they will utilize multiple means to access information, including social engineering. Therefore, all employees and contractors involved with an incident should not speak to any external parties regarding an incident, including confirming or denying an incident. If contacted by an outside party, the response should be limited to this statement: “I have no comment, please direct inquires to our CEO, thank you.” and hang up the phone or walk away. The CEO is the only person who may discuss any incident, potential incident, or past incident with the media or external parties.

FrontRunnerHC may engage the services of an outside security firm, forensic investigator, or PCI forensic investigator if necessary, during or after an incident. These outside resources will be made known to the IRT and full disclosure of information to them is authorized by FrontRunnerHC. However, if there is any doubt, please contact the Information Security Officer to validate their access to information.

6.0. Incident Response Team

Below are the IRT member’s titles and contact information:

Recipient	Title	Location	Contact
Marc Machin	CISO	Remote	Email: mmachin@frhc.com Phone: 714-457-4539
John Donnelly	CEO	On/Off Site	Email: jdonnelly@frhc.com Phone: 617-699-9570
Elisabeth Friese	COO	On/Off Site	Email: efriese@frhc.com Phone: 913-488-6488

7.0. Definitions and Terms

Assessment : After the identification phase, an initial assessment should be performed to confirm the existence of the incident. The assessment should include determining the scope, the impact of the incident, and the extent of the damage caused by the incident.

CAPTCHAS : An acronym for “Completely Automated Public Turing test to tell Computers and Humans Apart” is a type of challenge-response test used in computing to determine whether the user is human.

Containment : Containment of the incident is necessary to minimize and isolate the damage incurred.

Eradication : In order to successfully eliminate the possibility of the incident reoccurring again, the IRT needs to determine the cause of the incident that resulted in the system compromise.

Event : An occurrence that has not been verified as a Security Incident.

Follow-up : As a follow-up, a post-mortem analysis of the compromised system should be performed to understand the weaknesses that resulted in the incident and other potential vulnerable areas. In the event that FrontRunnerHC is considering legal action against the perpetrator, forensic specialists and/or law enforcement agencies should be engaged to ensure that digital evidence is accumulated and preserved in a manner that is consistent with a legal follow-up.

Identification : The occurrence of an incident is unpredictable. An anomaly in the system behavior may indicate an incident or configuration errors. Hence, identifying an incident amidst routine daily operations is not always an easy task.

Preparation : In any IRP, it is essential to form an IRT prior to other tasks. The role of the team is to promptly handle an incident so that it will have minimal impact to the business operation. The team is formed of members from various functional roles in FrontRunnerHC.

Ransomware : A type of malware that prevents or limits users from accessing their system. This type of malware forces its victims to pay the ransom through certain online payment methods to grant access to their systems, or to get their data back. Some ransomware encrypts files (called CryptoLocker). Other ransomwares use TOR to hide C&C communications (called CTB Locker).

Recovery : The recovery phase restores operations of the compromised system to facilitate the resumption of normal business operations. Prior to the resumption process, a validation check should be performed to ensure that the system is secured against any repeated incidents. Furthermore, the system should be placed under surveillance to ensure that if the perpetrator returns, unauthorized attempts may be detected early.

Security Incident : An irregular or adverse event that occurs within any part of FrontRunnerHC’s information systems infrastructure. These include (but are not limited to) computer intrusions, denial of service attacks, theft of information, inappropriate modification of data, any unauthorized or unlawful activity that requires support personnel, system administrators, or computer crime investigators to respond.

8.0. Revision Tracking

Rev	Description	Date	Approved
-	Original Document	September 2018	M Machin
1.0	Inclusion of Information Support ticketing for tracking	October 2019	M Machin
2.0	Remove Section 9 referencing BCS	September 2020	M Machin
3.0	Formatting Update	October 2022	WSI
4.0	Minor update: Information Impact of the Incident Section	January 2023	WSI
5.0	Updated and approved for 2024	July 2024	WSI
6.0	Updated and approved for 2025	July 2025	M Machin