Security Incidents Revisited

Phishing remains the number one vector for depositing malware into unsuspecting users’ email through software engineering (e.g., requiring urgency, a transfer of funds, the appearance that the emails was sent from a state or federal agency, etc.) and other clever techniques such as spoofing URLs. Once the malware penetrates the network the mission to search and destroy commences. It may range from weeks to months. Time in the network is called “dwell time.”

Reducing the dwell time, in addition to comprehensive Phishing training, is likewise an effective technique because the consensus among cybersecurity professionals is that any network can be penetrated (i.e., the periphery is dead). Phishing is just one of many vectors used for penetration, but is important to focus on because it remains the most pervasive. If you can destroy the malware before it delivers its payload and kicks in you will have effectively killed the enemy before it causes damage by reducing its “dwell time”. The “kill chain” pattern works as follows:

(1) reconnaissance;

(2) weaponization;

(3) delivery;

(4) exploitation;

(5) installation;

(6) command & control; and

(7) action once the objective has been achieved.

Although reducing dwell time contributes significantly toward preventing ransomware and other monetization schemes, this requires constant monitoring of your network for unusual conduct that constitutes the radar system necessary for killing the enemy before it delivers its payload.

The challenge for the healthcare industry writ large, is that this sort of network monitoring requires highly sophisticated cybersecurity experts, that many covered entities and business associates (“Stakeholders”) either do not have the budget for or have not considered the talent which constitutes a high priority and mission critical issue. This needs to change or the healthcare industry will retains its soft target status indefinitely.

HIPAA requires that Stakeholders do the following via actualized policies and procedures:

(1) identify security incidents;

(2) respond to security incidents;

(3) mitigate harmful effects of security incidents; and document security incidents and their outcomes.

Although these requirements are generally well understood, anecdotally we are aware of a significant number of instances where management teams decided to “deep six” breaches, especially those that do not meet the HIPAA five hundred record threshold for reporting within 60 days. All breaches must be reported to HHS, either 60 days after the breach or 60 days after end of the calendar year. So even a breach of one record must be reported.

This “deep sixing” strategy provides the illusion of avoiding regulatory penalties but is unsustainable. Soon or later an organization will have a breach large enough to make headlines. You can be sure that when OCR comes calling, it will discover that their security incident management system is either entirely absent, or so weak that it cannot possibly reflect the reality on the ground.

This is especially true under the proposed Privacy Rule (i.e., probably drops in Q1 2023) because the  proposed Privacy Rule has the potential to turn point-of-care staff into  “liability generation factories.” Small breaches, such as sending PHI to the wrong patient is likely a weekly occurrence at a minimum. Sending PHI to the wrong covered entity or business associate is a recognized exception to the definition of a Breach as contained in the regulation. However, there is no such exception for sending PHI to the wrong patient.

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:

(1) having a response team in place (i.e., before a Breach);

(2) having relationships established with third-party vendors whose help they will need to recover;

(3) that each team member understands their role and responsibilities; and

(4) at a minimum, “table top” test the plan.

HIPAA mandates that Stakeholders take the following steps:

(1) consistent review of audit logs for the “bad guys” that have already penetrated their respective networks;

(2) take rigorous steps to mitigate all incidents upon discovery;

(3) document all incidents that potentially touch PHI (impossible to investigates the thousands of incidents generated by networks on a daily basis);

(4) have appropriate backups that follow the 3-2-1 backup rule (e.g., create one primary backup and two copies of your data, save your backups to two different types of media, and keep at least one backup offsite and “air gapped” requiring total disconnection from the Internet).

Stakeholders must also have a command of their Breach reporting responsibilities at both the state and federal level. Each state now has its own Breach reporting requirements. Stakeholders must comply with all of them if patient data from that state was affected by the Breach. Failure to report will lead to serious civil monetary penalties (“CMPs”) and the subsequent OCR audit will almost certainly find other “dead bodies” contained within your compliance initiative.

Without having a rigorous incident tracking system there is no way stakeholders can plausibly make the claim that their program is compliant with the regulations, let alone mature. This only one of a dozen requirements to claim maturity, but it is arguably the most important one.