According to gizmodo.com, security researchers at Kromtech Security Center found a wide-open Amazon Web Services (AWS) bucket that contained over 300,000 PDFs, each one a medical file that would fall under the governance of the Health Insurance Portability and Accountability Act (or HIPAA which, arguably, finally jumpstarted the drive towards encrypting sensitive digital files thanks to generous fines levied on hospitals and other legally-covered entities that screwed up their data security).
There have been (too) many similar cases over the years, although we’re beginning to see a transition of sorts: while the past showed incorrectly configured servers at the center of an “accidental” data breach (that is, the blame didn’t lie on hackers but on what a company’s IT staff decided to do…or not do), today’s incidents increasingly tend to involve incorrectly configured cloud services, be it AWS, Microsoft’s Azure, Dropbox, or others.
Technically, they’re the same problem – misconfigured settings on boxes connected to the internet – but the former was more complex than what one deals with today: nowadays, you click on a checkbox in a webform, hit the save button, and companies like Amazon take care of the rest.
(Although, if one were to play Devil’s Advocate, it should be pointed out that AWS does support programmatic read-write permissions which are similar, but nowhere close, to server configurations of yore).
When Kromtech alerted the healthcare company of the error, the situation was corrected the very same day. However, they appear to have remained incommunicado to subsequent reach outs by the security company. Not necessarily the height of gratitude but, hey, it doesn’t look like they’re ignorantly suing Kromtech “for hacking” them, so that’s a plus.
The downside: the PDFs contained,
In addition to names, addresses, and other contact information, many of the records contained dates of birth, diagnoses, as well as the names of physicians overseeing care of the patients…
No SSNs or credit card details. However, with information like the above, obtaining such data is literally a phone call away. In a world where millions get scammed for computer tech support they don’t need, how hard would it be to socially engineer sensitive data by posing as hospital staff that know real details about someone’s recent medical history?
The answer is “not very hard.”
One easy way to lower the odds of suffering similar data breaches is to use file encryption prior to uploading digital documents to the cloud. This was the case when people set up their own internet-facing databases in the past and still is the case with cloud services. Granted, AWS’s security options are more than adequate, at least when it comes to conforming to data security requirements and regulations across the US.
But that’s within the confines of the cloud service (and assuming one doesn’t screw it up by unchecking the wrong box). If the internet is used as a cloud-based document repository, then those files will descend from the cloud at some point (which seems pretty likely for PDFs). Will they be downloaded to a laptop or a desktop? Backed up to tape? Copied over to a USB drive? Emailed as an attachment?
In each case, encrypting a file is basically the only way to secure the data. And if so, if the files are being uploaded and downloaded from the cloud, why not encrypt them before doing anything at all? The risk of something going awry may be small, but the expected ramifications are huge if or when something does go wrong.
Related Articles and Sites: