Medical Data on 365,000 Patients Stolen
Anonymous writes "Backup tapes and disks with data on 365,000 patients were stolen out of the car of a worker at a healthcare company in Portland. According to this Computerworld story, the tapes were in his car because he took them home as part of a disaster recovery plan, to protect the information from fire and other on-site disasters. D'oh!"
You've got to wonder why these people didn't have this stuff encrypted... An encrypted filesystem at least or straight up file encryption even... When are these companies going to get a clue?
And storing the tapes in your car? What happens if it's 100 degrees outside?
Where i work, they make the backup copies and have someone drive them to one of the other branches at the company. They make a backup every day and keep seven days worth of backup in rotation so if something went wrong 6 days ago and they backed up the problem every day, they ahve the 7th backup left to work with...
Unfortunatley i don't know what their view on encrypting the data is. With as anal retentive as the IT VP is about security though, i can't imagine they wouldn't be encrypted...
I can see hard disks being stolen..... but not tapes in the one case. Thieves like to take items with obvious value. Am I missing something here? Isn't it possible the workers simply sold the data?
At least the tapes were encrypted (not the disks in this incident). Even though this case doesn't affect me this was the first question that (always) pops in my head.
:).
:).
:).
For much the same reasons cited here our company backups are taken offsite (daily) -- only difference is that instead of tapes and disks we found that for speed, volume, and cost it was better to go with external hard drives (I figured this out almost ten years ago myself
Even though we are a small organization (under a few hundred employees) the data is encrypted. That was step one and one of the most important IMHO. The average Joe who finds / steals any of our external drives (which has never happened thankfully) would be hard pressed to even figure out the filesystem (Ext3). Not that that would really slow down anybody who knows what they're doing -- nor was it done for security (I just like / trust Linux
Of course I can think of other problem areas where data is flying around unencrypted and sensitive. The Department of Employment Security (which many states all report to for and through payroll to track dead beat dads) takes their data with your social security number in a plain ASCII text file sent through the US mail on a floppy. What happens when you lose a floppy, or what do they do with the processed disks?
Fortunately and unfortunately we need and there will be laws requiring any such sensitive information to be encrypted for "National Security" (Big Brother [tm]) reasons. It's only a matter of time. It is unfortunate that it will take a law and more bureaucratic BS to make this happen, it is fortunate for all our privacy and the fact someone has to program this (more work for me
For some reason this is seaming to be a popular activity. I remember hearing a few years back in school about a sysadmin bringing the tapes home for offsite backup. There actually was an incident where he needed to get information off the tapes. Each tape he tried was corrupted. After doing some investigation, it turned out that the magnetic field from his car's seat heater was corrupting them.
Bottom Line: Secure transport and storage plans are required no matter how sensitive or mission critical your information is.
Proof by very large bribes. QED.
I also work at a healthcare provider adn deal with this exposure every day. Normal backups provides us no disaster recovery value because our recover point objective is measured in minutes. Tape simply can't meet it. Likewise if we were to attempt to restore the entire operation from tape it would take months. Just acquiring hardware would take weeks. But our recovery time objective is forty-eight hours. Basically, if we go longer than that we are out of business. So long term, our DR strategy is based on storage and app level replication between data centers. But as it stands, we only have one site. Consequently we send our backups offsite, essentially as a placebo. But it gets better. We don't have the drive resources to duplicate tape, so we send the originals offsite. That means that if we need to do a restore we must wait an hour for someone to retrieve the tape and reinject it into our library.
Let's review here: we have a fake DR strategy which adds an hour to every file restore and exposes us to data theft. Sounds good huh? I have repeatedly told our brass it would be better to do nothing, but their position is "We don't want to tell the newspapers we had no DR strategy when the disaster strikes."
How do we remediate this? Well, we could encrypt the tape but that is a big pain in the ass and has its own disadvantages. Really, the answer is to get off our ass and build a DR data center so the potentially deadly placebo goes away.
It is cowardly, and a betrayal of whatever it means to be a Jew, to act as a white man
-James Baldwin
Consulting in the insurance industry, I'd say that most likely the disks are from a mainframe since most medical companies are still using big mainframes for processing important customer data. I'm not sure how easy it is to read from a mainframe disc without having a mainframe, but it's hardly a proprietary format.
Remember the Alamo, and God Bless Texas...
I've just completed a project for a private contractor setting up a new NHS clinic and got to see first hand all the hoops that have to be jumped through.
The security requirements are incredible...we had to make a physically seperate lan for the NHS approved kit which cannot be shared with anything else - the building now has 2 distinct set of CAT5 cabling.
Interestingly enough however, the recommended practice for backups is to take them offsite. I got root to the db machine and looked at the backup script and it's a simple mysqldump.
When i queried this with the NHS supplier, they said (and had told the private firm) that it was encrypted. I then informed the CEO of the the supplier that it was not and that taking raw text files of patient data off site was a bad idea, could he please let me know what they exact procedure should be.
The reply i got was as follows:
"As you know we are accredited to RFA99 v1.2 which dictates the way the
system is designed and built. RFA99 v1.2 has no requirement that the data
contained on backup media be encrypted."
They also sent me a policy document on backups recommending that they be removed from site every day.
I ended up making a formal recommendation to my client that the tapes never leave the site (and the reasons why) and that they be locked in a fireproof box.
With the NHS approved suppliers making recommendations like that (they will all recommend the same as they're all accredited to the same standards), this will happen here some time or another.
I'm surprised you don't think there is any real risk attached to the leaking of medical records. The risks are real and there are documented instances of their occurrences of failures with severe consequences. These include the IRA penetrating the medical records system at the Royal Victoria Hospital in Belfast to target police officers; a bank manager on the board of a US hospital finding out which of his customers had cancer and foreclosing the loans; and US insurers have disclosed health information about customers to lenders and employers without permission.
Many people are vulnerable to blackmail about sensitive aspects of their medical records, including--but hardly limited to--sexual and mental health. Similarly, people may avoid seeking medical advice for such conditions if they fear that they cannot speak in confidence. And large networked databases simultaneously increase the value of the data to malicious users (more chance of finding something interesting) and the opportunities for access.
Of course, the major threats are all internal, not external -- malicious insiders.