Slashdot Mirror


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!"

10 of 226 comments (clear)

  1. hmmm by rwven · · Score: 3, Interesting

    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...

  2. Is it really theft? by rolfwind · · Score: 4, Interesting
    The incident is the second data theft from a motor vehicle announced this week. Yesterday, Minneapolis-based financial services company Ameriprise Financial Inc. said it is notifying some 158,000 customers and 68,000 financial advisers that a laptop containing personal information about them -- including names, account numbers or Social Security numbers -- was stolen from a parked car late last month (see "Ameriprise notifying 226,000 customers, advisers of data theft").


    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?
  3. Partially encrypted by krray · · Score: 4, Interesting

    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 :).

  4. Don't Use Your Car by slashbob22 · · Score: 2, Interesting

    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.
  5. I Live In Fear of This by good+soldier+svejk · · Score: 4, Interesting

    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
    1. Re:I Live In Fear of This by Anonymous Coward · · Score: 1, Interesting

      I'd push for the alternate data center. I've worked places where it's came in handy. A shutdown for a fire was a big one. But computing stuff that should NOT happen, but does, cause people are dumb, is another good reason to have a warm offsite backup. At one place we were very redundant in our EDI area too, because you just can't count on people, or telcos.

    2. Re:I Live In Fear of This by Anonymous Coward · · Score: 1, Interesting

      Easy. Order a ton of dell servers, pay for the next or try to get them to do same day shipping, order a huge EMC san, slip the installer a few hundreds so they do it that day. Hardware recovery CAN happen on the same day if you are willing to pay through the nose for it, and let everyone in the loop know you are restoring a datacenter and it's critical no time is wasted.

  6. Re:The further story by GodBlessTexas · · Score: 2, Interesting

    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...
  7. Re:What's the problem by Anonymous Coward · · Score: 2, Interesting

    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.

  8. Re:My take... by shilly · · Score: 4, Interesting

    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.