Iowa Health Information Network (IHIN) Security Incident Response Plan I. Scope This plan identifies the responsible parties and action steps to be taken in response to Security Incidents. IHIN Security Policy 9: Notification, Investigation and Mitigation requires both the Iowa Department of Public Health (the Department ) and all Participants in the IHIN to investigate, respond to and report known or suspected Security Incidents related to IHIN in compliance with applicable federal and state law, the Participation Agreement signed by all Participants, and the IHIN Privacy Policies and Security Policies. Security Policy 9 describes in general terms the responsibilities of Participants and the Department with respect to Security Incidents. II. Definitions Capitalized terms not defined shall have the meanings ascribed to in the IHIN Privacy Policies and Security Policies. Breach includes, for purposes of this Plan, breach as defined in the HIPAA Privacy Rule (see Appendix A). Personally identifiable information or PII means information about an individual maintained by an organization, including (1) any information that can be used to distinguish or trace an individual s identity, such as name, social security number, date and place of birth, mother s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information. Protected Health Information or PHI means protected health information as defined in 45 C.F.R. 160.103 that is created or received by a Participant. Security Incident is the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information available through the IHIN or interference with IHIN operations, including attempted and successful privacy Breaches. III. Incident Response Process A. IHIN Incident Response Team Final Workgroup Review 1 09/2013
The IHIN Incident Response Team includes Department staff, a representative from the IHIN vendor, representatives from the e-health Privacy and Security Workgroup recommended by the Workgroup. The composition of the Incident Response Team may vary depending on the nature of the Security Incident under investigation. The Incident Response Team composition for each Security Incident under investigation will be approved by the Executive Director of the IHIN. Appendix B contains additional details regarding the composition and role of the Response Team. The Incident Response Team will convene when activated by the Department s IHIN Privacy and Security Officer. The Incident Response Team will support the IHIN Privacy and Security Officer by providing technical expertise and accessing resources with respect to investigation, mitigation, and other necessary responses, and will consult with legal counsel as necessary. B. Report or Discovery of Security Incident This phase of the plan begins with the awareness that a Security Incident has occurred. Any person may submit a complaint or concern about a Security Incident to the IHIN Privacy and Security Officer or the IHIN security hotline, 800-774-0388. 1. Once the Department discovers or is made aware of a Security Incident, the IHIN Privacy and Security Officer will open an incident ticket using the Incident Form (Appendix C), which will include a brief description of the basis of the discovered or reported Security Incident. This standardized form will be used to compile information, categorize the Security Incident, and document all steps in the discovery process and stages of the Security Incident, through mitigation and resolution. Completeness and consistency of documentation of all discovered and reported Security Incidents will facilitate accurate documentation, demonstrate due diligence, and support mitigation and reporting activities. 2. The IHIN Privacy and Security Officer and IHIN Project Manager at the Department will confer regarding the circumstances of the Security Incident, and seek information as needed from the IHIN vendor to assess immediate risks to Participants and/or the IHIN. 3. The IHIN Privacy and Security Officer will notify the Incident Response Team of discovered or reported Security Incidents. Depending upon the nature or severity of the Security Incident, the IHIN Privacy and Security Officer will activate the Incident Response Team. C. Identifying the Origin of Security Incident A key step in the discovery process is identifying the origination point of the Security Incident. The two basic sources are: i) Security Incidents originating from a Participant and Final Workgroup Review 2 09/2013
impacting the IHIN and/or other Participants; and ii) Security Incidents originating from the IHIN that may or may not also have an impact on Participant(s). Identifying the origin of the Security Incident will determine the parties roles in the response. This process is described in more detail in the Security Incident Process Flow in Figure 1. 1. If the Security Incident originates with a Participant and impacts the IHIN and/or other Participants, the Participant will lead the investigation with support from the Department. The Department may also have a role in mitigation activities. Note that if it is later determined that IHIN was not at risk, the Participant will become solely responsible for all actions. 2. If the Security Incident originates with the IHIN and may involve one or more Participant, the Department will lead the investigation with support from involved Participants. 3. Without undue delay but in any event no more than eight (8) business days following the report or discovery of a possible Security Incident, the Department will contact the entities suspected to be involved in and impacted by the Security Incident. D. Determining the Type and Magnitude of the Security Incident The process flow for determining the type and magnitude of the Security Incident appears as Figure 1. 1. Determine the category of Security Incident. More than one of these categories may apply in complex incidents. Category 1: Lost or stolen equipment, inappropriate information disposal, insider threats, and other events not covered in Categories 2-6. Category 2: Denial of Service (DoS) attacks; malicious network activity; port or vulnerability scan; and other types of network attacks. Category 3: Virus; worm; spyware; bot/botnet; Trojan/backdoor; smartphone malware; and similar types of malware events. Category 4: Inappropriate website; website defacement; unapproved software; unapproved hardware; and similar types of hardware, software and website events. Category 5: Social engineering; phishing; blackmail; and similar types of human target events. Category 6: Event involves, or probably involves, PHI or some other type of PII. 2. Determine the magnitude by identifying the systems and technology impacted by the Security Incident. This will guide the immediate mitigation activities. Final Workgroup Review 3 09/2013
a. IHIN network/server - IHIN hardware b. IHIN software or application c. IHIN databases d. Participant systems or technology not connected to IHIN e. Other 3. Ascertain who within the source organization was responsible for the Security Incident. 4. Establish who received or accessed the disclosed information? a. Was the recipient a covered entity or BA? b. Was it an Authorized User of a Participant? c. Was it an unauthorized member of a Participant s workforce (or ex-employee)? d. Was it the IHIN vendor? e. Was it the Department? f. Was it from outside the Department or IHIN Participants? The following questions (5-7) apply only for Category 6 incidents, i.e., those that involve PHI or PII. 5. Determine what type(s) of data were released: a. PII (name, SSN, DL#, Medicaid or Student ID #, health information?) b. PHI (of any kind) c. Genetic information, HIV, SA, MH? 6. Determine Severity of Security Incidents and Probability that PII or PHI was compromised. a. Were data unsecured or unencrypted? If encrypted, assess likelihood of reidentification (nature of the recipient). b. Was the PII or PHI actually viewed or used? If so, by whom (risk of malice)? c. Was risk mitigated to the extent practicable? (e.g., assurances that recipient returned or destroyed the information). Final Workgroup Review 4 09/2013
d. Were there any mitigating circumstances that should be considered? (objective is to help determine the reason for the violation: for example - inadvertent, acting in good faith, recipient could not have reasonably retained the data) i. Did recipient inadvertently or unknowingly obtain restricted information? ii. iii. iv. Was information accessed due to causes other than willful neglect? Was violation willful or deliberate (vs. accidental or inadvertent), but corrected in a timely manner? Was violation due to willful neglect and not corrected in a timely manner? v. Were 500 or more people affected? 7. Did the Security Incident trigger a reporting requirement? 8. The Incident Form guides the Incident Response Team through this fact-finding process (see Appendix C for the sample form). The incident assessment will be documented in the Incident Form, even if it is determined that no breach occurred. Final Workgroup Review 5 09/2013
Figure 1. Security Incident Process Flow Final Workgroup Review 6 09/2013
IV. Determine Necessary Actions A. Mitigation Activities Specific mitigation activities will vary depending on the category and circumstances of each Security Incident and cannot be prescribed prior to investigation. All available options will be considered as the need arises. Immediate mitigation activities focus on containment of the Security Incident and communication between all parties involved. Category 6 PHI/PII Category 5 Human event Category 4 - Website event (clinical portal) Category 3 - Malware Immediate (containment) 1. Determine which Category (1-5) led to breach of PHI/PII 2. Mitigation activities will be dependent on category 1. Suspend affected user accounts 2. Determine if there are infected devices and act accordingly 3. Assess impact to stakeholders and remediate 1. Determine depth and type of intrusion 2. Isolate any infected devices 3. Take appropriate counter measures to stop attack 4. Assess impact, if any, to system and remediate 1. Identify infected devices (IHIN and/or Participant) 2. Isolate infected devices 3. Assess impact to stakeholders and Communication 1. Participant/Xereox notifies IHIN Privacy and Security Officer/Project Manager of Category 6 Incident 2. Privacy and Security Officer notifies Executive Director and Attorney General s Office of Category 6 Breach 3. Incident Response Team is notified as appropriate 4. Participants notified as appropriate 5. OCR guidelines for notifications utilized as appropriate 1. Participant/Xerox notifies Privacy and Security Officer of Category 5 incident 2. Privacy and Security Officer notifies Xerox onboarding specialist of user account name to suspend account/reset passwords 3. Department notifies Incident Response Team as appropriate 4. Department notifies other involved Participants as appropriate 1. Xerox becomes aware of event 2. Xerox notifies Project Manager/Privacy and Security Officer 3. Department notifies Participants as appropriate 1. Xerox becomes aware of malware incident 2. Xerox notifies Project Manager/Privacy and Security Officer Final Workgroup Review 7 09/2013
Category 2 - Network attack Category 1 Lost or stolen equipment or media remediate 1. Determine network access points attacked and depth of intrusion 2. Take appropriate counter measures to stop attack 3. Assess impact, if any, to system and remediate 1. Identify what has been lost or stolen 2. Determine what information or system access may be available via lost/stolen device and take appropriate actions 3. Disable user account if individual device with IHIN access or individual accessing inappropriately 4. Department will provide support to Participant to investigate and remediate 3. Department notifies Participants as appropriate 1. Xerox becomes aware of successful network attack. 2. Xerox notifies Privacy and Security Officer/Project Manager 3. Department notifies Participants as appropriate 1. Participant/Xerox notifies IHIN Privacy and Security Officer/Project Manager of lost/stolen equipment with IHIN access or access to IHIN for unapproved purpose 2. If required, Department will notify Xerox onboarding specialist of user account to suspend/reset password B. Involve Others in Response, as Needed The Incident Response Team will determine whether a forensic response and/or law enforcement response is necessary. 1. Forensics Response: The Department will work with IHIN vendors and other state government IT resources (e.g., the Iowa Department of Administrative Services as needed to coordinate the forensics action steps. In particular, the Department will assist with the following: a. Identifying possible sources of forensic data. b. Acquiring the forensic data. i. Developing a plan to acquire forensic data ii. Coordinating with forensics team to acquire the forensic data iii. Secure/confiscate applicable equipment iv. Secure/confiscate applicable software v. Secure/confiscate applicable system logs vi. Secure/confiscate applicable data vii. Verifying the integrity of the forensic data 2. Law Enforcement Response: If the investigation into the Security Incident suggests possible criminal activity, the Department will work with legal resources Final Workgroup Review 8 09/2013
(e.g., the Iowa Attorney General s Office) as needed to facilitate the legal response. In particular, the Department will assist with the following: a. Providing documentation regarding the Security Incident. b. Facilitating acquisition of necessary evidence. c. Contacting appropriate stakeholders (or supplying contact information as requested) to respond to law enforcement needs. C. Corrective Action Under the terms of the Participations Agreement, the Department may suspend or terminate a Participant s access to the IHIN to protect the security, integrity, and availability of the IHIN to other users. V. Reporting and Communication The IHIN Privacy and Security Officer will be responsible for documenting all processes and findings (or obtaining and archiving this information). The Incident Response Team will be involved in making the necessary determinations and recommendations to the Department, which will determine the necessary reporting and communications. The IHIN Privacy and Security Officer will help coordinate communication with those involved in the investigation. A. Documentation and Reports 1. The Incident Form will facilitate a uniform investigational and documentation effort of all Security Incidents; even if the investigation concludes that no Security Incident occurred. 2. The Department will use discretion consistent with applicable law when sharing information with employees, Participants, law enforcement, vendors, business partners, the media, etc. 3. The Department will notify law enforcement as required, based on advice of legal counsel. 4. The IHIN Privacy and Security Officer will create a confidential document 1 summarizing the Security Incident that will include information such as, but not limited to: 1 This document, which shall include the forms, documents, and data comprising the investigative file, will be Confidential Records pursuant to the Iowa Health Information Network Security Policies and Iowa Code 22.7(50)(2013). Final Workgroup Review 9 09/2013
a. High-level description of the Security Incident and its scope b. Impact on the IHIN c. Actions taken to prevent further occurrences d. Recommendations for further action This report will be reviewed by the Incident Response Team, who will have an opportunity to provide feedback. 5. At each meeting of the e-health Executive Committee and Advisory Council, the Privacy and Security Officer will provide a high-level description of any confirmed Security Incidents and Breaches that may have occurred since the Council s last meeting. The description will include the number and severity levels of Security Incidents and a high-level description of the Department s actions taken in response to them. Such information may be presented orally, rather than in writing. B. Communication 1. Participant will notify individuals when their PHI is breached as required by law, and will provide the IHIN Privacy and Security Officer with findings and any actions taken in response to investigation. 2. If there has been a confirmed Breach caused by a failure in the IHIN, the Department will determine whether reporting of a PHI Breach to HHS is required and if so, whether the magnitude of the breach requires reporting to HHS within 60 days of discovery (in cases of 500 or more affected individuals) or within 60 days of end of year. If Breach notification is required, the Department will work with legal counsel to determine the specific legal obligations and the content and timeline for notification. 3. If during the investigation of a Security Incident the breach of an applicable data breach law protecting personally identifiable information (e.g., social security number, mother s maiden name, biometric records) is discovered, the party having responsibility under the law shall comply with the law s reporting requirements. Final Workgroup Review 10 09/2013
Appendix A HIPAA Breach Definition 45 C.F.R. 164.402 Breach means the acquisition, access use, or disclosure of protected health information in a manner not permitted under subpart E of this part which compromises the security or privacy of the protected health information. 1. Breach excludes: a. Any unintentional acquisition, access, or use of protected health information by a workforce member or person acting under the authority of a covered entity or a business associate, if such acquisition, access, or use was made in good faith and within the scope of authority and does not result in further use or disclosure in a manner not permitted under subpart E of this part. b. Any inadvertent disclosure by a person who is authorized to access protected health information at a covered entity or business associate to another person authorized to access protected health information at the same covered entity or business associate, or organized health care arrangement in which the covered entity participates, and the information received as a result of such disclosure is not further used or disclosed in a manner not permitted under subpart E of this part. c. A disclosure of protected health information where a covered entity or business associate has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information. 2. Except as provided in paragraph (1) of this definition, an acquisition, access, use, or disclosure of protected health information in a manner not permitted under subpart E is presumed to be a breach unless the covered entity or business associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment of at least the following factors: a. The nature and extent of the protected health information involved, including the types of identifiers and the likelihood of re-identification; b. The unauthorized person who used the protected health information or to whom the disclosure was made; c. Whether the protected health information was actually acquired or viewed; and d. The extent to which the risk to the protected health information has been mitigated. Unsecured protected health information means protected health information that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology Final Workgroup Review 11 09/2013
or methodology specified by the Secretary in the guidance issued under section 13402(h)(2) of Public Law 111-5. Final Workgroup Review 12 09/2013
Appendix B Incident Response Team The IHIN Incident Response Team is convened as needed to contain, investigate, and prevent future Security Incidents. 1. Team Composition. The Department, in consultation with the Privacy and Security Workgroup, will determine the skill sets necessary for effective incident response. The qualifications needed and the size of the team may vary by incident; therefore a core team will be identified, along with as needed team members. Members of the Incident Response Team should be available on short notice to quickly address needs. Members should be familiar with IHIN, including its objectives and the general network design. Team members are expected to share their knowledge and expertise, and help develop recommendations and action items related to Security Incident response. The IHIN Privacy and Security Officer will serve as the Security Incident lead for all Security Inc., and will coordinate all activities for the Incident Response Team. 2. Responsibilities of the Incident Response Team include: a. Collect and/or review the incident documentation and event reports b. Verify facts c. Maintain data integrity -- maintain baselines of normal activity to use for comparison d. Start forensic analysis how, what, why did this happen? e. Keep detailed logs f. Develop and record a hypothesis regarding the cause of the Security Incident: i. How does the evidence support/contradict it? ii. What evidence was discovered, and how was the hypothesis tested? iii. What important interactions took place? 3. Documentation The IHIN Privacy and Security Officer will be responsible for maintaining all evidence, logs, and data associated with the Security Incident, as well as preserving an Audit Trail. The IHIN Privacy and Security Officer will use care to avoid dissemination of confidential information in sharing reports and documents associated with Security Incident. All documentation associated with a breach will be retained for a period not less than seven years. All forms and documents Final Workgroup Review 13 09/2013
associated with a Security Incident are Confidential Records pursuant to the Iowa Health Information Network Security Policies and Iowa Code 22.7(50). 4. Contact Information The Department will create and distribute an Incident Response Phone List that is updated at least quarterly. Each member s name, role on the Incident Response Team, work/cell/home phone numbers, and e-mail address. For each Team member outside the Department, there will be an alternate or backup contact person. Final Workgroup Review 14 09/2013
Incident Response Team Phone List Last Updated: Role Name Work Phone Home Phone Cell Phone Email IDPH P&S Officer IDPH IT Project Manager PIO Forensics Expert Sarah Brooks Tracy Donner Polly Carver-Kim DAS ICA Rep Xerox Rep Workgroup and Participant Volunteer members (and alternates, in case of conflict of interest) e-health P&S WG rep (not from Participant already having team membership) Alternate Privacy Officer from Participant Alternate Security Officer from Participant Alternate Final Workgroup Review 15 09/2013
Appendix C Incident Form (Insert Excel Workbook) Final Workgroup Review 16 09/2013