HIPAA Security Rule Security Incident Procedures
Every October, in recognition of National Cybersecurity Awareness Month, the federal government and its partners work to educate stakeholders on cybersecurity awareness and how best to protect the privacy and security of confidential data. Within the health care industry, the HIPAA Security Rule1 applies to covered entitiesand their business associates (“regulated entities”) and electronic protected health information (ePHI). Because ePHI identifies individuals and includes information relating to an individual’s health, treatment, or payment information, it is a valuable target for cyber-criminals.
Cybersecurity incidents and data breaches continue to increase across all industries. A 2022 cybersecurity firm report noted a 42% increase in cyber-attacks for the first half of 2022 compared to 2021, and a 69% increase in cyber-attacks targeting the health care sector. The number of data breaches occurring in the health care sector also continue to rise. Breaches of unsecured protected health information (PHI), including ePHI, reported to the HHS Office for Civil Rights (OCR) affecting 500 or more individuals increased from 663 in 2020 to 714 in 2021. Seventy-four percent (74%) of the breaches reported to OCR in 2021 involved hacking/IT incidents. In the health care sector, hacking is now the greatest threat to the privacy and security of PHI. A timely response to a cybersecurity incident is one of the best ways to prevent, mitigate, and recover from cyberattacks.
The HIPAA Security Rule requires regulated entities to “implement policies and procedures to address security incidents.” This means regulated entities need to have a plan in place and documented for responding to security incidents (suspected or known) that includes:
- Identifying security incidents;
- Responding to security incidents;
- Mitigating harmful effects of security incidents; and
- Documenting security incidents and their outcomes.
Security incidents will almost inevitably occur during the lifetime of a regulated entity. Having a plan established and documented is essential to being able to detect security incidents quickly in order to respond to and recover from security incidents effectively.
Forming a Security Incident Response Team
In preparing their security incident response process, regulated entities should consider forming a security incident response team that is organized and trained to effectively respond to security incidents.
There are many options to consider when it comes to forming a security incident response team. In Special Publication 800-61 Computer Security Incident Handling Guide - PDF, the National Institute of Standards and Technology (NIST) provides several areas to consider when forming a security incident response team, including:
- Selecting a team structure and staffing (e.g., use a centralized or distributed model, staff with full-time employees or partially outsource, ensure team members have appropriate expertise – organizational and technical)
- Establishing relationships and lines of communication between the security incident response team and other groups (both internal and external)
- Identifying internal groups that may need to participate in incident handling (e.g., management, information technology support, legal, public affairs and communications, human resources, business continuity/disaster recovery, physical security, facilities management)
- Identifying points of contact at external groups that may be helpful to include in the event of an incident (e.g., network service providers, software and hardware vendors, local and federal law enforcement, incident handling teams of business partners and customers)
- Determining what services the security incident response team should provide (e.g., intrusion detection, advisory distribution, education and awareness, information sharing)
Once formed, the security incident response team should conduct regular testing of security incident procedures. This could involve conducting tests involving different types of potential security incident scenarios, for example, a malicious insider exfiltrating sensitive information, a cyber-criminal’s infiltration and deployment of ransomware, or a distributed denial of service (DDoS) attack that interrupts system operations. Security incident procedures should be updated with lessons learned from testing as well as from actual security incidents to improve the team’s response and effectiveness.
Within the HIPAA Security Rule regulation itself, there are many helpful steps that regulated entities must take to protect against cyber threats.
Identifying Security Incidents
The HIPAA Security Rule defines a security incident as “the attempted or successful unauthorized access, use exit, disclosure exit, modification, or destruction of information or interference with system operations in an information system.”
Having audit logs in place and regularly reviewing such logs are actions that regulated entities are required to take and greatly improve their ability to identify security incidents early. The HIPAA Security Rule audit controls standard requires that regulated entities, “implement hardware, software, and/or procedural mechanisms to record and examine access and other activity in information systems that contain or use electronic protected health information.” For example, log filesmay be able to help identify when and how a cyber-criminal entered an information system and what activities occurred. The HIPAA Security Rule information system activity review implementation specification also requires regulated entities to "implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports."
By recording information system events, alerts, user actions, and other activities in appropriate logs and conducting regular reviews of such logs, regulated entities will have mechanisms and procedures in place to record and review information system activity and be able to identify and respond to security incidents quickly.
Responding to Security Incidents
When responding to a security incident, a regulated entity should contain the security incident and any threat it may pose to ePHI and take appropriate action(s) to ensure the confidentiality, integrity, and availability of its ePHI. Failing to do so could have a wide range of negative repercussions, including identity theft, financial loss, or negative consequences to the reputation or safety of the individual. Important steps to ensure that the threat is neutralized include:
- · Determining the nature and extent of the damage caused by the security incident;
- · Identifying and removing any malicious code and components that the security incident may have left behind; and
- · Mitigating any vulnerabilities that may have permitted the security incident to occur.
Collecting and preserving data relevant to investigating the security incident, such as log files, registry keys, and other artifacts, should also be part of security incident response activities.
To be better prepared to respond to security incidents, regulated entities should consider including the following as part of their security incident procedures:
- Designating appropriate personnel (qualified internal resources and/or external third parties) to be members of the security incident response team;
- A communication plan and contact information for notifying all members of the security incident response team, and others as required (e.g., management) when a security incident occurs;
- Processes to identify and determine the scope of security incidents;
- Instructions for managing the security incident;
- Creating and maintaining a list of assets (computer systems and data) to prioritize when responding to a security incident;
- Conducting a forensic analysis to identify the extent and magnitude of the security incident;
- Reporting the security incident to appropriate internal and external entities (e.g., the regulated entity’s IT and legal departments, local FBI Cyber Taskforce Field Office, federal and state regulatory authorities, and other individuals or entities as required);
- Processes for collecting and maintaining evidence of the security incident (e.g., log files, registry keys, and other artifacts) to determine what was accessed during the security incident;
- Processes for conducting regular tests of the security incident response process.
While each security incident has its own set of facts that require a well-tailored response, regulated entities should develop a process for security incidents that commonly occur. For example, a regulated entity might have a specific process for responding to a ransomware attack and other processes for responding to insider malicious activity, cyber-attacks from hackers, and phishing attacks. Specific processes addressing common types of security incidents can improve workforce members’ understanding of what to do and the regulated entity’s speed in responding to these security incidents.
Mitigating Harmful Effects of a Security Incident
After the security incident has been neutralized and any malware removed, the next steps should include mitigating the harmful effects of the security incident including recovery and restoration of systems and data to return to normal operations. A critical component of an effective recovery from a security incident is preparation. The HIPAA Security Rule requires that regulated entities establish a contingency plan. The cornerstones of any data centric contingency plan must include robust data backup and recovery processes. Data backup and disaster recovery plans are required implementation specifications of the HIPAA Security Rule’s contingency standard.
Frequent backups and verification of the integrity of the backed-up data are crucial to being able to recover data that may have been deleted or had its integrity compromised as a result of a security incident. Backup logs should be reviewed regularly, and test restorations of backups conducted periodically to ensure the integrity of backups and provide confidence in the regulated entity’s ability to restore its data. Because some malware, including some ransomware variants, are known to delete or otherwise disrupt online backups, regulated entities should consider maintaining at least some of their backups offline and unavailable from their networks.
When backing up data, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) recommends following the “3-2-1” backup strategy:
- Keep 3 copies of important data – 1 primary copy and 2 backup copies;
- Keep backups on 2 different media types (e.g., local disk, hosted cloud, removable media);
- Keep at least 1 of your backup copies offsite.
Depending on the nature of the security incident and damage caused, the recovery process may involve one or more of the following processes recommended by CISA in its Eradicate & Recover procedures for cybersecurity incidents:
- Reimage affected systems from clean backups;
- Rebuild systems from scratch (i.e., install operating system and application software from trusted media or vendor sources);
- Rebuild hardware (especially if rootkit malware was found or suspected);
- Replace compromised files with known good versions;
- Install current updates and patches;
- Reset passwords and implement multi-factor authentication.
Documenting the Security Incident
Once a security incident has ended, systems and data have been restored, and operations have returned to normal, regulated entities should document their response and analysis into a record of the security incident. This record can be used to synthesize lessons learned to improve future response activities and may be helpful for regulatory purposes if applicable. The HIPAA Security Rule requires regulated entities to document security incidents and their outcomes. A regulated entity’s security incident procedures should include a section on documenting security incidents and what information to include in the documentation (e.g., discovery of the security incident; systems and data affected; response and mitigation activities; recovery outcomes; root cause analysis; forensic data collected).
Understanding your Breach Reporting Obligations
When considering their security incident procedures and how to respond to security incidents, regulated entities need to be mindful of their obligation to report breaches of unsecured PHI. The Breach Notification Rule requires covered entities to report breaches affecting 500 or more individuals to the affected individuals, to OCR, and (in certain cases) to the media without unreasonable delay and no later than 60 calendar days from the discovery of the breach.
Covered entities are required to report breaches affecting less than 500 individuals to the affected individuals without unreasonable delay and no than 60 calendar days from the discovery of the breach and to OCR no later than 60 days after the end of the calendar year in which the breach was discovered. It is important for covered entities to note that the “the time period [for reporting] begins when the incident is first known, not when the investigation of the incident is complete, even if it is initially unclear whether the incident constitutes a breach as defined in the rule.” Further, 60 days is the outer limit for notification and, “in some cases, it may be an ‘unreasonable delay’ to wait until the 60th day to provide notification.”
Recent Resolution of OCR Investigation
In July 2022, OCR announced the resolution of an investigation of Oklahoma State University – Center for Health Sciences concerning a hacker gaining unauthorized access to a web server that contained ePHI. The hacker installed malware that resulted in the disclosure of the ePHI of 279,865 individuals, including their names, Medicaid numbers, healthcare provider names, dates of service, dates of birth, addresses, and treatment information. OSU-CHS initially reported that the breach occurred on November 7, 2017, but later reported that the ePHI was first impermissibly disclosed on March 9, 2016.
OCR’s investigation found potential violations of the HIPAA Rules including impermissible uses and disclosures of PHI; failure to conduct an accurate and thorough risk analysis; failure to perform an evaluation, failures to implement audit controls, security incident response and reporting, and failure to provide timely breach notification to affected individuals and HHS. OCR successfully resolved this investigation with a monetary settlement of $875,000, and a resolution agreement and corrective action plan that includes two years of OCR monitoring.
The policies and procedures regulated entities create to prepare for and respond to security incidents can pay dividends in the long run with faster recovery times and reduced compromises of ePHI. A well thought-out, well-tested security incident response plan is integral to ensuring the confidentiality, integrity, and availability of a regulated entity’s ePHI.
Reference
U.S. Department of Health & Human Services
Office for Civil Rights (OCR)
Fall 2022 OCR Cybersecurity Newsletter
