Understanding all of the technical workings of networks and computers is one thing. Often tech folks will say that they understand HIPAA but what that really means is they understand the technical requirements of HIPAA. The overconfidence sometimes works against them. The reasons we want response plans, policies, procedures, documentation, and checklists is to prevent problems like the ones we are discussing today.
Story #1 – investigations are required.
For years, we have been telling tech folks you can not just wipe a healthcare computer after a ransomware attack and move on. It doesn’t work that way anymore. In 2016, OCR guidance made it clear that a ransomware attack should be investigated just like any other potential breach of PHI.
Along the way, there have been consistent arguments from tech staff and refusal to believe forensics were required. “Nuke and pave to get the system back up and running as fast as possible” they always say. I don’t disagree with the need to get back up and running. I am just saying you have another requirement that must come first. It is the investigation of what went wrong. It must be part of your incident response plans to preserve evidence.
Read some news about a case this week that finally helps explain why we are right. Now I get to say check this out and then let’s talk: Premera Accused of Trashing Computer in Health Data Breach Lawsuit
Premera Blue Cross is being accused of destroying evidence in the class-action lawsuit against them. Guess what happened…. In March 2015, Premera announced a data breach affecting 11 million people. Yes, you heard that right. Of course, that was followed by several class action lawsuits.
Premera’s defense is that there can’t be harm to the patients because the data was not exfiltrated. Unless patients can prove the confidential information was exfiltrated then no harm, no foul.
Now they get this dropped on them.
Lawyers for the breach victims filed a motion Aug. 30 in the case seeking sanctions against the health insurer for “misconduct” in destroying a computer hard drive and logs that contained evidence related to the theft of data by hackers.
“By willfully destroying: (a) a computer that the hackers used in the data breach and which may have held evidence of data exfiltration; and (b) data loss prevention software logs that may have shown evidence of data exfiltration, Premera spoliated key evidence and prejudiced Plaintiffs’ ability to achieve a rightful decision in this case,” according to the motion, a copy of which was obtained by HealthITSecurity.com.
The sanctions called for include instructing the jury that because of the destruction of the computer and the logs, the jury should presume that the data exfiltration occurred…..
The HealthIT Security article goes on to quote the attorneys explaining why they filed this motion.
“The destroyed computer was perfectly positioned to be the one-and-only staging computer hackers needed to create vast staging files for the purpose of shipping even more data outside of Premera’s network. This computer functioned as the development machine for a software programmer, and as such was pre-loaded with a vast array of legitimate utilities that could be turned to any purpose,” the attorneys wrote.
Here is a case where the only machine in a ransomware attack that was completely nuked without evidence preservation happened to be the one with all the tech tools a hacker needs. That is clearly the case whether it was used by the hacker or now.
I hope that the question about whether instant nuke and pave should be done or not is answered once and for all. You never know what may happen if you don’t have things documented. It can be years from now that it comes back to haunt you.
The moral of the story is you must have a written ransomware response plan. You must know what has to be done and make sure all the tech team understands that they can not just take actions because they “know” how to do it. There is more to worry about than just getting things back up and running. It needs to be written to ensure that this message gets out and that the steps required are followed consistently.
When in doubt swap it out!
Don’t nuke and pave, the hard drive you must save.
BTW, there was an interesting story about a new way for ransomware attacks. Send infected resumes (or CVs) in response to job postings.
Story #2 – Security settings must be configured properly the first time but also checked and double checked regularly.
Medcall Healthcare Advisors gets a call from the UpGuard Cyber Risk team to let them know some disturbing news.
…that detailed medical information for employees of 181 business locations, as well as personally identifiable information (PII) for nearly 3,000 individuals was publicly exposed in an unsecured Amazon S3 storage bucket
It was a lot of data since they found a 7G storage bucket. It is most likely that some tech person of some level set up the data store. It had data from their intake system used to get details of the patients needs when they called the service. The point is clear in the UpGuard post that states:
…this incident serves as an example of how third and fourth party risk can compromise the privacy of individuals and companies if data handling practices are not properly monitored and controlled. Medical information is not just exploitable, but extremely personal, intimate, and its exposure entails more than just the possibility of fraud that accompanies all PII, a fact underlying the privileged status of the doctor-patient relationship.
We ask tech folks regularly to do audits of security settings and use checklists for setting up things like AWS buckets. It doesn’t matter whether or not you have done it 100 times or 2 times. Mistakes happen. People get confused. You never know what causes these kinds of issues but finding them on your own is way better than getting one of these calls.
The moral of story number 2 is that audits are not just there to make things hard for you. Audits must be done to confirm things are correctly secured and to catch things that are not. If there had been audits in place this would have been stopped. Even if they did audit it but since the audit the data was unsecured, they would have the proof they were making an effort to prevent these problems.
Story #3 – When things go wrong the tech folks are in the ones in the hot seat.
A report about worldwide security trends. The 8th Kaspersky Lab Global Corporate IT Security Risks Survey provided some interesting information about how data breaches are dealt with across all industries around the world.
Several findings are in the report but
One of the most common responses to a data breach is for businesses to enforce formal rules within their organizations, with 33% of SMBs and 38% of enterprises applying additional policies and requirements after an incident;
If you don’t do the things mentioned above before an incident it is likely you will need to start doing it or scramble to get it done. But, more importantly, someone may lose their job because of data breaches. However, it isn’t clear how many things were in place before these breaches. Based on these numbers it wouldn’t be far-fetched to assume the likelihood of job loss rises based on the preparedness or seriousness of the data breach.
Moral of the final story is that you need to document yo’ stuff. If you can prove you were doing all of the steps to meet industry standards and protect the information you can say you were eating your broccoli. Because of that, you can continue to afford broccoli cause you kept your job.
Spread the word with tech teams as well as managers about these stories. There are plenty of reasons to share. At a minimum, everyone knows the risks they are living with even if they didn’t want to make any changes – for now.