FlowTrack implements an information security incident response process to consistently detect, respond, and report incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore information system functionality and business continuity as soon as possible.
The incident response process addresses:
These policies were adapted from work by the HIPAA Collaborative of Wisconsin Security Networking Group. Refer to the linked document for additional copyright information.
FlowTrack policy requires that:
(a) All computing environments and systems must be monitored in accordance to the policies and procedures specified in the following FlowTrack policies and procedures:
(b) All alerts must be reviewed to identify security incidents.
(c) Incident response procedures are invoked upon discovery of a valid security incident.
(d) Incident response team and management must comply with any additional requests by law enforcement in the event of criminal investigation or national security, including but not limited to warranted data requests, subpoenas, and breach notifications. (Subject to approval and direction of counsel)
The Security Incident Response Team (SIRT) is responsible for:
Current members of the FlowTrack SIRT:
The FlowTrack incident response process follows the process recommended by SANS, an industry leader in security. Process flows are a direct representation of the SANS process which can be found in this document.
FlowTrack's incident response classifies security-related events into the following categories:
Events - Any observable computer security-related occurrence in a system or network with a negative consequence. Examples:
Precursors - A sign that an incident may occur in the future. Examples:
Alerts raised from a security control source based on its monitoring policy, such as
Indications - A sign that an incident may have occurred or may be occurring at the present time. Examples:
Incidents - A confirmed attack / indicator of compromise or a validated violation of computer security policies or acceptable use policies, often resulting in data breaches. Examples:
FlowTrack employees must report any unauthorized or suspicious activity seen on production systems or associated with related communication systems (such as email o chat). In practice this means keeping an eye out for security events, and letting the Security team know about any observed precursors or indications as soon as they are discovered.
Incidents of a severity/impact rating higher than MINOR shall trigger the following response process, or as defined more specifically in the Incident Categories and Playbooks section.
Immediately upon observation FlowTrack members report suspected and known Events, Precursors, Indications, and Incidents in one of the following ways:
The individual receiving the report facilitates the collection of additional information about the incident, as needed, and notifies the Security Officer (if not already done).
The Security Officer determines if the issue is an Event, Precursor, Indication, or Incident.
If the issue is an event, indication, or precursor the Security Officer forwards it to the appropriate resource for resolution.
If the issue is a security incident the Security Officer activates the Security Incident Response Team (SIRT) and notifies senior leadership by email.
The lead member of the SIRT team facilitates initiation of an Incident ticket in Jira Security Project and documents all findings and details in the ticket.
The Security Officer, Privacy Officer, or FlowTrack representative appointed notifies any affected Customers and Partners. If no Customers and Partners are affected, notification is at the discretion of the Security and Privacy Officer.
In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to FlowTrack and potentially external.
In this Phase, FlowTrack's engineers and security team attempts to contain the security incident. It is extremely important to take detailed notes during the security incident response process. This provides that the evidence gathered during the security incident can be used successfully during prosecution, if appropriate.
Review any information that has been collected by the Security team or any other individual investigating the security incident.
Secure the blast radius (i.e. a physical or logical network perimeter or access zone).
Perform the following forensic analysis preparation, as needed:
Complete any documentation relative to the security incident containment on the Incident ticket, using SANS IH Containment Form as a template.
Continuously apprise Senior Management of progress.
Continue to notify affected Customers and Partners with relevant updates as needed.
The Eradication Phase represents the SIRT's effort to remove the cause, and the resulting security exposures, that are now on the affected system(s).
Determine symptoms and cause related to the affected system(s).
Strengthen the defenses surrounding the affected system(s), where possible (a risk assessment may be needed and can be determined by the Security Officer). This may include the following:
Conduct a detailed vulnerability assessment to verify all the holes/gaps that can be exploited have been addressed.
Update the Incident ticket with Eradication details, using SANS IH Eradication Form as a template.
Update the documentation with the information learned from the vulnerability assessment, including the cause, symptoms, and the method used to fix the problem with the affected system(s).
Apprise Senior Management of the progress.
Continue to notify affected Customers and Partners with relevant updates as needed.
Move to Phase IV, Recovery.
The Recovery Phase represents the SIRT's effort to restore the affected system(s) back to operation after the resulting security exposures, if any, have been corrected.
The technical team determines if the affected system(s) have been changed in any way.
The Follow-up phase represents the review of the security incident to look for "lessons learned" and to determine whether the process that was taken could have been improved in any way. It is recommended all security incidents be reviewed shortly after resolution to determine where response could be improved. Timeframes may extend to one to two weeks post-incident.
Responders to the security incident (SIRT Team and technical security resource) meet to review the documentation collected during the security incident.
A "lessons learned" section is written and attached to Incident ticket.
Evaluate the cost and impact of the security incident to FlowTrack using the documents provided by the SIRT and the technical security resource.
Determine what could be improved. This may include:
Communicate these findings to Senior Management for approval and for implementation of any recommendations made post-review of the security incident.
Carry out recommendations approved by Senior Management; sufficient budget, time and resources should be committed to this activity.
Ensure all incident related information is recorded and retained as described in FlowTrack Auditing requirements and Data Retention standards.
Close the security incident.
It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness. This also involves appropriate training of resources expected to respond to security incidents, as well as the training of the general population regarding the FlowTrack's expectation for them, relative to security responsibilities. The incident response plan is tested annually.
Category 1 – General Incidents, including physical security incidents
Category 2 – Attacks on internal corporate infrastructure, including network, hardware, software
Category 3 – Malware
Category 4 – Attacks on external facing assets, such as website, web applications, web services. Including denial of service attacks.
Category 5 – Human targets, social engineering, phishing, etc.
Category 6 – Breach/leakage of critical or confidential data
Critical – incident that involves immediate and significant interruption to business operations and/or breach of critical or confidential data
Major – incident that involves immediate interruption to business operations but will not likely result in immediate data breach
Minor – all other confirmed incidents
Prioritize handling the incident based on functional impact, informational effort, recoverability efforts and other relevant factors
Report the incident to the appropriate internal personnel and external organizations
Acquire, preserve, secure, and document evidence
Contain the incident
Eradicate the incident
Recover from the incident
Depending on the type of event, use the following incident response playbooks:
Depending on the agent type, follow these incident response playbooks:
Follow the Phishing incident response playbook
Data Theft incident response playbook outlines the response instructions
At least the following two special cases are considered when responding to an incident:
When a data breach occurs that involves unsecured PHI or ePHI, breach notifications must be performed according to HIPAA regulation requirements, including each individual impacted and as applicable, the covered entity and OCR (see Appendix for additional details).
If the breach or potential breach impacts PHI/ePHI that belongs to a Covered Entity to which FlowTrack is a Business Associate of, the IRT and management team will inform the Covered Entity per the timeframe and contact method established in the Business Associate Agreement or as described in §Breach Notification. HIPAA §164.410(b)
In the event of an attack that involves suspected criminal activities, the IRT and management team will inform law enforcement.
Members of the cross-discipline insider threat incident handling team include:
If an incident constitutes an emergency – for example, a detected cyberattack that impacts production systems – FlowTrack plans to operate in a “view/read” mode, to continue to provide customers access to their data. All update/create customer record access is temporarily blocked and data upload is paused until the emergency is resolved. This is accomplished by updating the access policies/roles in production AWS environments and/or updating datbase endpoints to a Read Only node.
In emergency operations mode, temporary access may be granted to security and/or engineering team to access the production environments to perform forensics, root cause analysis, eradication/remediation, or other necessary activities for incident recovery.
At least once per year, FlowTrack security and engineering teams jointly performs a Red Team exercise and/or a simulated "drill" of an emergency cyberattack that results in one or more CRITICAL incidents. Depending on the type of exercise, the duration may range from 2-4 hours (simulated "drill") to a couple of weeks (full Red Teaming exercise).
The exercise will follow a cyberattack playbook. It may be conducted with all internal resources or with the help of an external security consulting firm. The goal of the exercise is to ensure all parties involved receive proper training to handle an actual incident and to test out the documented procedures in order to identify gaps ahead of a real event. Senior leadership team may be invited to participate in the "drill" depending on the nature of the exercise or receive a readout of the outcome.
A record is created for each reported incident in Jira. Each incident record contains details about the incident capturing the incident attributes and progression, including the following as applicable:
If a more detailed post-mortem is applicable, the Security and/or DevOps team will create the write-up and link it in the incident record.
Fincosa LLC, 220 Calle Manuel Domenech #2012, San Juan, PR, 00918, USA