Incident Response Policy

RosettaHealth 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:

• Continuous monitoring of threats through intrusion detection systems (IDS) and other monitoring applications;

• Establishment of clear procedures for identifying, responding, assessing, analyzing, and follow-up of information security incidents;

• Workforce training, education, and awareness on information security incidents and required responses; and

• Facilitation of clear communication of information security incidents with internal, as well as external, stakeholders

Applicable Standards

Applicable Standards from the HITRUST Common Security Framework

• 11.a - Reporting Information Security Events

• 11.c - Responsibilities and Procedures

• 11.d - Learning from Information Security Incidents

Applicable Standards from the HIPAA Security Rule

• 164.308(a)(5)(i) - Security Awareness and Training

• 164.308(a)(6) - Security Incident Procedures

Incident Management Policies

RosettaHealth’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:

  • Hardware component failing causing service outages.

  • Software error causing service outages.

  • General network or system instability.

• Precursors - A sign that an incident may occur in the future. Examples:

  • Monitoring system showing unusual behavior.

  • Audit log alerts indicated several failed login attempts.

  • Suspicious emails targeting specific RosettaHealth staff members with administrative access to production systems.

• Indications - A sign that an incident may have occurred or may be occurring at the present time. Examples:

  • IDS alerts for modified system files or unusual system accesses.

  • Antivirus alerts for infected files.

  • Excessive network traffic directed at unexpected geographic locations.

• Incidents - A violation of computer security policies or acceptable use policies, often resulting in data breaches. Examples:

  • Unauthorized disclosure of ePHI.

  • Unauthorized change or destruction of ePHI.

  • A data breach accomplished by an internal or external entity.

  • A Denial-of-Service (DoS) attack causing a critical service to become unreachable.

RosettaHealth employees must report any unauthorized or suspicious activity seen on production systems or associated with related communication systems (such as email or Slack). In practice this means keeping an eye out for security events, and letting the Security Officer know about any observed precursors or indications as soon as they are discovered. RosettaHealth customers who identify a potential security-related event should inform RosettaHealth support (via the support system or by direct email).

Identification Phase

1. Immediately upon observation, be it by RosettaHealth employees or customers, RosettaHealth members are to report suspected and known Events, Precursors, Indications, and Incidents to management, the Security Officer, or Privacy Officer.

2. The Privacy and Security Officer will investigate the incident to determine if the incident potentially involved a breach of ePHI, and if so, the extent of the breach. This investigation will include:

   1. Determine how was the data collected

   2. Determine when was the data collected

   3. Determine who may have had unauthorized access ePHI.

   4. Determine exactly what ePHI data in question and if it was accessed. This will involve examination of system interface logs, platform component logs and Linux system logs. If confirmed then initiate the processes described in the ePHI Breach.

   5. Determine the vulnerability and associated risk that allowed the unauthorized access

   6. Develop mitigation plan to address the risk as described in Risk Management.

3. Privacy and Security Officer will document the security incident in the Security Event Log and store in the corporate document management system.

4. The Security Officer, Privacy Officer, or RosettaHealth 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.

5. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to RosettaHealth and potentially external.

Containment Phase (Technical)

In this Phase, RosettaHealth Admins work with ClearDATA 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.

1. The RosettaHealth Admins work with ClearDATA to secure the network perimeter.

2. The RosettaHealth Admins working with ClearDATA performs the following:

   1. Securely connect to the affected system over a trusted connection.

   2. Retrieve any volatile data from the affected system.

   3. Determine the relative integrity and the appropriateness of backing the system up.

   4. Change the password(s) to the affected system(s).

   5. Determine whether it is safe to continue operations with the affect system(s).

   6. If it is safe, allow the system to continue to function;

      1. Complete any documentation relative to the security incident on the Security Event Log.

      2. Move to Phase V, Follow-up.

   7. If it is NOT safe to allow the system to continue operations, discontinue the system(s) operation and move to Phase III, Eradication.

3. Continuously apprise Senior Management of progress.

4. Continue to notify affected Customers and Partners with relevant updates as needed

Eradication Phase (Technical)

The Eradication Phase represents the efforts by RosettaHealth Admins and ClearDATA to remove the cause, and the resulting security exposures, that are now on the affected system(s).

1. Determine symptoms and cause related to the affected system(s).

2. 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:

   1. An increase in network perimeter defenses.

   2. An increase in system monitoring defenses.

   3. Remediation (“fixing”) any security issues within the affected system, such as removing unused services/general host hardening techniques.

3. Conduct a detailed vulnerability assessment to verify all the holes/gaps that can be exploited have been addressed.

   1. If additional issues or symptoms are identified, take appropriate preventative measures to eliminate or minimize potential future compromises.

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

5. Apprise Senior Management of the progress.

6. Continue to notify affected Customers and Partners with relevant updates as needed.

7. Move to Phase IV, Recovery.

Recovery Phase (Technical)

The Recovery Phase represents the effort to restore the affected system(s) back to operation after the resulting security exposures, if any, have been corrected.

1. The RosettaHealth Admins and ClearDATA determines if the affected system(s) have been changed in any way.

   1. If they have, the technical team restores the system to its proper, intended functioning (“last known good”).

   2. Once restored, the team validates that the system functions the way it was intended/had functioned in the past. This may require the involvement of the business unit that owns the affected system(s).

   3. If operation of the system(s) had been interrupted (i.e., the system(s) had been taken offline or dropped from the network while triaged), restart the restored and validated system(s) and monitor for behavior.

   4. If the system had not been changed in any way, but was taken offline (i.e., operations had been interrupted), restart the system and monitor for proper behavior.

   5. Update the documentation with the detail that was determined during this phase.

   6. Apprise Senior Management of progress.

   7. Continue to notify affected Customers and Partners with relevant updates as needed.

   8. Move to Phase V, Follow-up.

Follow-up Phase (Technical and Non-Technical)

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.

1. Responders to the security incident meet to review the documentation collected during the security incident.

2. Create a “lessons learned” document.

3. Evaluate the cost and impact of the security incident to RosettaHealth.

4. Determine what could be improved.

5. Communicate these findings to Senior Management for approval and for implementation of any recommendations made post-review of the security incident.

6. Carry out recommendations approved by Senior Management; sufficient budget, time and resources should be committed to this activity.

7. Close the security incident.

Periodic Evaluation

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 RosettaHealth’s expectation for them, relative to security responsibilities.