Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Businesses Privacy Security IT Your Rights Online

US Health Insurer Anthem Suffers Massive Data Breach 223

An anonymous reader writes Anthem, the second-largest health insurer in the United States, has suffered a data breach that may turn out to be the largest health care breach to date, as the compromised database holds records of some 80 million individuals. Not much is known about how the attack was discovered, how it unfolded and who might be behind it, but the breach has been confirmed by the company's CEO Joseph Swedish in a public statement, in which he says they were the victims of a "very sophisticated external cyber attack." The company has notified the FBI, and has hired Mandiant to evaluate their systems and identify solutions to secure them. Swedish said the breach is extensive: the vulnerable data included "names, birthdays, medical IDs/social security numbers, street addresses, email addresses and employment information, including income data," though "no credit card or medical information, such as claims, test results or diagnostic codes were targeted or compromised." (Also covered by Reuters.)
This discussion has been archived. No new comments can be posted.

US Health Insurer Anthem Suffers Massive Data Breach

Comments Filter:
  • by 3.5 stripes ( 578410 ) on Thursday February 05, 2015 @08:57AM (#48988065)

    Huge databases full of personal info are gigantic targets, and properly securing them is very very difficult (and what's worse, uneconomical, since most of them are owned by publicly traded companies)..

    Pandora's box is open now, but don't say the tinfoiled warriors didn't warn you..

    • by SQLGuru ( 980662 ) on Thursday February 05, 2015 @09:18AM (#48988233) Homepage Journal

      PII should be classified based on sensitivity. At a certain level, that PII must be encrypted during transit. At the highest level, it must be encrypted during transit and at rest. SSN falls in the highest sensitivity level. SOP for years. This doesn't guarantee you won't get hacked, but it reduces / minimizes the impact if you are hacked.

      PII - Personally Identifiable Information
      SSN - Social Security Number
      SOP - Standard Operating Procedure

      • PII should be classified based on sensitivity. At a certain level, that PII must be encrypted during transit. At the highest level, it must be encrypted during transit and at rest. SSN falls in the highest sensitivity level. SOP for years. This doesn't guarantee you won't get hacked, but it reduces / minimizes the impact if you are hacked.

        PII - Personally Identifiable Information
        SSN - Social Security Number
        SOP - Standard Operating Procedure

        Out of curiosity since you are familiar with the subject, where is the acceptable place to keep the encryption key? During a compromise it doesn't do much good when it's on or near the same server as the DB with the data. Two servers, with two distinct access control credentials?

        • If it really needs to be exceptionally secure and you're dealing with a system that is constantly running, why not just keep any encryption keys in memory only where it's that much harder to get them and have them manually be entered by someone if the system needs to be brought down. That or use some module with the encryption baked in at a physical level to handle encryption and decryption. Yes, it's more expensive, but these systems are already hugely expensive and it makes it incredibly difficult for any
          • The information needs to be accessible. The insurance company has to access it, of course, as well as partners like billing and collection companies, doctors and hospitals query the system, and to enforce ACA the IRS needs access, the state exchange you bought it through ... Probably three more types of entities I'm not thinking of off the top of my head. I'd bet there are at least a dozen different government agencies involved with ACA who can query your information.

            If the IRS, the insurance company, the

            • So only the guy in the server room can access any patient^H^H^H^H^H^H customer data, for a company with millions of customers? That's going to be one busy guy! Roughly everyone who works at the insurance company needs some access to their customers' information, so it has to be on the network. The IRS demands access too, so the insurance company has to connect it to the internet.

              The notion of an operator-provided or operator-unlocked key is the way it used to work "back in the days" when every server had a monitor plugged into it. You would provide a password on bootup which was a mini-key to decrypt the actual SSL/TLS keys. It would get stashed in memory at that point and (hopefully) operator intervention wouldn't be needed again until the next scheduled reboot. Before too long, the threat of in-memory attacks far eclipsed the threat of physical server theft and this practice w

          • If it really needs to be exceptionally secure and you're dealing with a system that is constantly running, why not just keep any encryption keys in memory only where it's that much harder to get them and have them manually be entered by someone if the system needs to be brought down. That or use some module with the encryption baked in at a physical level to handle encryption and decryption. Yes, it's more expensive, but these systems are already hugely expensive and it makes it incredibly difficult for anyone without physical access to get at the actual data.

            Is there some practical reason why it couldn't be done this way or something else that I'm missing outside of the obvious that there's another, cheaper way of doing things?

            Putting the key alongside the data is a bad idea no matter how the key gets there. Finding it in RAM would be no different than finding it somewhere on the disk (assuming the disk approach is more complex than c:\config\crypto.key) so that's out. There are TPM solutions that can make it secure (storing the key in tamperproof memory, never releasing it, doing the encryption/decryption only at the request of signed binaries) but at this scale I don't know if the TPM can keep up or if doing it all on one clo

          • It's not a matter of "why not just" anything. Keys in memory just mean an attacker runs a memory dump once the system is online. Keys in a file means an attacker reads that file. All major database servers will use an encryption keystore to encrypt the keys with the credentials of the service account the database runs under. They're not plaintext files, they're protected as strongly as the service account itself. If this is set up properly, it means an attacker that can get at the key on disk you can a

        • by dclydew ( 14163 )

          There are a number of solutions to the problem. There are data protection appliances that can be integrated to databases or applications (via API) where encrypted data is sent to for decryption and available only in the result set; never written to disk in the clear. In this scenario, even root or dba don't have access to the sensitive data, unless authorized by the appliance. Another option, (becoming more popular) is tokenization. The sensitive data is replaced by consistent non-sensitive token values. Th

          • Tokens can also retain some of the original data. So if we tokenized SSN 123-45-6789, we could generate a token that kept the same last 4 digits, 541-30-6789. If customer support uses the last four digits of SSN to verify customers on the phone, they can now do it without being exposed to the real sensitive data.

            While it is very common practice in the US to verify customers using the last 4 digits of their SSN, this practice is actually poor security.

            If you know someone's place and date of birth, you can determine the first 5 digits. This is because SSN assignment was done by regional offices, each assigned a block from which to allocate SSNs.

            Even though centralized SSN assignment is now used, vast numbers of US citizens were assigned their SSNs from the regional blocks.

      • Acronym usage (Score:4, Insightful)

        by gcnaddict ( 841664 ) on Thursday February 05, 2015 @09:24AM (#48988281)
        If you're only using an acronym once, expand it in-line. For instance:

        Personally identifiable information (PII) should be classified based on sensitivity. At a certain level, that PII must be encrypted during transit. At the highest level, it must be encrypted during transit and at rest. Social security number falls in the highest sensitivity level. Standard operating procedure for years. This doesn't guarantee you won't get hacked, but it reduces / minimizes the impact if you are hacked.

        Not saying this to be a dick. Saying it because the way you come across right now is as someone who takes pride in stuffing jargon in the faces of others.

      • by jellomizer ( 103300 ) on Thursday February 05, 2015 @09:38AM (#48988391)

        HIPAA requires all PHI to be encrypted when transmitted.
        The hack got into the systems after the data is at rest. As are most data breaches. There are very few hacks from packet sniffing. (Our infrastructure tends to be using Switches and Routers, instead of the old Hubs, so there is less packets being spread to less than trustworthy areas)
        If you were to encrypt the data a rest, where would you store the key? And if someone could gain access to that key you are in just as much trouble.

        Better rules would be for systems that access PHI, to be off the Internet entirely. So you will have two networks. That are physically on different networks. One where you have the PCs that are hooked to the normal intranet and internet. Then one system just for PHI.
        Now how do we send data from one institution to the next (say from the hospital to the insurance company) Then you will need a trusted point to point encrypted channel. Once the data is send, that point to point needs to be closed, and perhaps physically unplugged from the internet.

      • by qwijibo ( 101731 ) on Thursday February 05, 2015 @10:43AM (#48989127)

        Encryption is not a panacea.

        I'm in full agreement that sensitive data should be encrypted, but I've seen too many cases where encryption (even bad encryption) is an excuse for lazy and bad security decisions.

        SSN is a bad "secret" for anything, given how simple and ubiquitous it is. The idea that shared secrets establish identity has been wrong for many years and it's just going to keep getting worse until we, as consumers, can make companies leverage public key cryptography for authentication.

        Policies that require encrypting SSN at rest and PII in transit usually results in a database table with:
        Name
        Address
        Date_of_Birth
        Encrypted_SSN

        That sounds like a step in the right direction, unless you consider that how easy it is to decrypt the SSN. On my laptop, it takes 62 seconds to go through every possible SSN using a script that took me less than 60 seconds to write. Add some time for doing an encrypt operation and lookup for each possible value, but it's clearly possible to brute force the entire SSN range on any computer in a very short amount of time. Ultimately, once someone can get access to the data, they can easily generate every possible encrypted SSN and match up actual value to what's in the table.

        Real world example:
        Cox insisted on having my SSN to get internet service through them. The last 4 of the SSN is used to confirm the user on the web site. They insisted that storing SSN on the internet was safe because it's encrypted. They really want the SSN to be able to track you down if you don't pay and skip town. Most of their customers aren't going to argue with them because they hear that encryption is magic. I eventually convinced a supervisor that their security is a joke and we agreed that my SSN would be in their system as 3.14159265, without the decimal point.

        When people believe that encryption makes their data safe, it allows people to decide to make riskier choices with where the data resides. Encryption is a step in the right direction, but it's just one piece of the security puzzle.

    • by RenderSeven ( 938535 ) on Thursday February 05, 2015 @09:32AM (#48988341)
      It wont stop until we start arresting the CIO's for being complicit in the breaches. My 10-year-old kids get it - "it may not be your fault but its your responsibility" - so why do overpaid do-nothing executives get a free pass when they utterly fail at their job?
      • It's a bit premature to suggest that the breach was a result of negligent security. Look at the Hannaford's Supermarket breach a few years back: they had just had (and passed) their PCI review but being PCI Compliant didn't prevent their breach. To use your analogy, your son may be held accountable if he brought his 3DS to school and it was stolen, but the consequences are different if the 3DS was stolen from his desk compared to having it stolen from his locked school locker.
      • They do NOT get a free pass. They contribute heavily to PACs!

  • by BVis ( 267028 ) on Thursday February 05, 2015 @08:58AM (#48988073)

    The hell you say! I'm sure all that money they saved not building an adequate infrastructure is much more than this breach will cost them. Oh, wait...

    • by Anonymous Coward

      When I see a new doctor, they always demand a SS# along with all of your personal information.

      And when I tell them that I am uncomfortable with it, I always get a stern and rude demand. Any explanation of how insecure medical is - those people email and fax that information willy nilly - I get this "I'm full of shit look."

      I hope those people get their identity stolen and their credit ruined so they can learn a lesson.

      • SS# isn't a demand from the Dr. but from the Insurance Company... Yell at them for requiring it.

        Also of a note. Your doctor probably has a patient list of around 25,000 people. That he must record and track by law. The SS# is one of the easier ways to insure you have the correct patient matched in the system. Bigger institutions can work around it, ones with a large IT Staff. But the small Dr. Office is quite limited, and subjected to the whims of the vendors.

        • by rossdee ( 243626 )

          " Your doctor probably has a patient list of around 25,000 people."

          Thats a huge practise for just one doctor. Even for a GP

          • Small practices usually range 5,000 - 40,000 patients. 15,000 patients per doctor. I have done a lot of practice data conversions, those are the numbers I tend to see.
            You have the following calculation.
            Normally about 50% of the visits are from new patients.
            8 hour day, with 10 minute intervals. for 5 days a week for 50 week. That is 6000 patients. They will need to keep 4-5 years of data on the patent. So we go up to 25,000 range.

            Now we have variances based on specialty, and level of care, but 25,000 for

    • by jellomizer ( 103300 ) on Thursday February 05, 2015 @09:09AM (#48988147)

      Working in Health Care, the issue is much harder then you think.
      We have conflicting rules and regulations that we must follow.
      We are by law demanded to keep our data safe, at the same time, we need to share it with others (Insurance Companies, Legal Cases, Governments, individuals, competing health care professionals) at a whim. Complex rules for what is acceptable and not are in place, meaning there is an IT Infrastructure that is older, because it contains an organic set of rules. Dumping the old systems for new ones that are more secure are a major undertaking.
      Even with a skilled IT Staff larger then most organizations it is nearly impossible to keep up with all the changes required by law, and focus completely on security. Putting in a code freeze until we get security fixed cannot happen.

      • Comment removed based on user account deletion
      • by div_2n ( 525075 )

        It's almost always a lack of will to spend the money required or accept the pain necessary and NOT technical feasibility. If you build your systems to the strictest of standards or beyond, then you are by default in compliance with the rest.

        Doing things "right" almost always gets hamstrung by the dollar figures required or by "business" push-back. "Do we really need to install IDS/IPS equipment in every little branch network we have?" Yes, yes you do if you want to prevent and catch breaches early. "What do

  • 80 Million? (Score:5, Insightful)

    by giltwist ( 1313107 ) on Thursday February 05, 2015 @08:59AM (#48988079)
    So of the roughly 300 million people with SSNs, nearly a third of them are nearly compromised? Great.
    • Re:80 Million? (Score:5, Insightful)

      by wezelboy ( 521844 ) on Thursday February 05, 2015 @09:05AM (#48988113)
      Might be a great excuse to replace SSNs with something better- like a key pair.
      • Sir, I lost my keyfob and can't log into my medical website, can you help me?
      • NO.

        The better way to fix this is to require strict liability to the Credit reporting agencies. If they put data in your credit report that is false, If they link you to debt that you actually didn't take out, then they have unlimited liability to damages to you plus statutory punitive damages.

        The hell, if when they come and sell me credit protections services isn't extortion i don't know what is.
        "Nice credit score you have. It would be a shame if someone stole your identity and messed that up so that we
  • income data? (Score:4, Interesting)

    by SemperUbi ( 673908 ) on Thursday February 05, 2015 @08:59AM (#48988081)
    Why is a healthcare insurance provider collecting income information on the people they insure? That's none of their business. The answer is probably 'just because they can,' but that doesn't mean I have to like it.
    • by cdrudge ( 68377 )

      Marketing demographic information most liklely. It doesn't say how accurate or what the source of that portion of the data is.

      Like many companies, my company has various different methods that we obtain leads. We automatically run every lead through a service to obtain demographic information about the email address that can tell us household size, residence value, own or rent, income, education level, field of employment, interests, age, etc. All those go towards scoring the lead as it relates to our targe

      • Marketing demographic information most liklely. It doesn't say how accurate or what the source of that portion of the data is.

        Like many companies, my company has various different methods that we obtain leads. We automatically run every lead through a service to obtain demographic information about the email address that can tell us household size, residence value, own or rent, income, education level, field of employment, interests, age, etc. All those go towards scoring the lead as it relates to our target market.

        While a data breach is a data breach, if it's somewhat public information or otherwise readily available from any number of other sources it's not like the damage from having income information is catastrophic.

        In this case, it was one less step the miscreants have to go through to grade each record set for sale on the black market. No doubt they are going to (or already have) sort by income descending, break them into nice 100 ID chunks, and sell them to the highest bidder.

    • Re:income data? (Score:5, Informative)

      by Motard ( 1553251 ) on Thursday February 05, 2015 @09:30AM (#48988319)

      Why is a healthcare insurance provider collecting income information on the people they insure?

      I've worked in employee benefits for over 25 years, and the usual reason is that they are administering more than your health insurance. Often you also have short-term and/or long-term disability insurance, or life insurance. The benefits of these are based on some percentage of your salary. Your short term disability benefit may be 60% of your salary, or your life insurance benefit may be 2 X salary.

      In all my time working for insurers like Anthem I have never been asked to pull salary data for anything not related to the above.

      • I can see that as a likely explanation. PII is supposed to be handled as securely as PHI, and companies are supposed to make an active effort to minimize how much they store. But who has time?
    • by dclydew ( 14163 )

      Monetization of data. All big companies do it. They collect as much data as possible and then sell subsets of data (perhaps anonymized) to 3rd parties, or they may provide roll-up analytic reports to third parties... Stuff like:

      I want to build a for profit practice that specializes in cancer treatments. What part of the country am I most likely to find a high number of cancer patients who make enough money to afford what I want to charge for my services?

      I buy a service from a data analytics company, they ha

    • Credit score and income level are two key indicators on how high your rates will be, and how much government assistance you will get.

  • by Himmy32 ( 650060 ) on Thursday February 05, 2015 @09:04AM (#48988107)
    Always stuck me as silly that your SSN was supposed to be secret and is used as a password. But you can never change it and you have to give to everyone including companies like this that lose it. Seems like the SSA should also give you a password that you can update that places could authenticate against. That way if you suspect a breach and you could update that number. Something like they you come in verify your identity and give you a new PIN.
    • The silly part is that knowing an SSN and a few other pieces of publicly available information is enough for someone to grant credit, and then for collections of such credit to be enforceable in court against the supposed borrower.

    • by Cmdr-Absurd ( 780125 ) on Thursday February 05, 2015 @09:56AM (#48988565)
      It gets better. secure.ssa.gov currently gets an F rating at ssllabs. (Vulnerable to Poodle both sslv3 and TLS).
    • The issue you are talking about is not exactly right. SSN is an ID .. that is a fact. ID's are never, ever, supposed to be secret. They are in fact supposed to be public so we can discern whom is who. However what you are railing against is the proof of identity, which is a separate issue. For example, knowing someone's SSN should not be proof of identity. The issue is that banks/insurance companies/etc. are using insecure practices when it comes to establishing proof of identity.

    • Your SSN was never supposed to be secret. Your SSN was supposed to be used only by the SSA for collection and disbursement of social security payments. It was never intended to be used as a national ID. However, in light of there being no other ID which uniquely identifies each individual in the country, everyone glommed onto using the SSN for that purpose. Which is when it started to become important to keep it secret.
  • by fastgriz ( 1052034 ) on Thursday February 05, 2015 @09:13AM (#48988177)
    Don't worry, they are going to give you a free trial of credit monitoring... The credit monitoring company probably even gives them a kickback for referring 80 million potential new customers after the 1 year trial subscription expires!
  • Badum-tish! (Score:4, Funny)

    by Dr. Eggman ( 932300 ) on Thursday February 05, 2015 @09:14AM (#48988189)
    Maybe they should change their name to Anathema Insurance
  • by gstoddart ( 321705 ) on Thursday February 05, 2015 @09:20AM (#48988253) Homepage

    Sadly, in the absence of data protection laws which makes corporations liable for this, this will continue.

    Unless companies carry a real cost for failing to secure this stuff, they'll continue to treat this as an afterthought.

    But apparently forcing corporations to not be clueless and careless idiots would somehow be a bad thing.

    Sorry, but if you need to have private information like that, you need to be accountable. If you aren't going to make companies accountable, don't allow them to have the data in the first place.

    • The scary thing is that this is in the industry with the most consumer data protection laws (healthcare). We've never had a breach this large, so we have no idea on the fine size. The largest fine levied so far was a combined $4.8M split between two entities. Unfortunately, I suspect the cost of securing a network this large accumulated over 5 years is probably more than the fine. The bigger pain will be the knock on effects of lost business, remediations, etc. The only other similar breach is Community Hea
    • The data protection laws need to target the credit agencies. If Experian or Equifax had unlimited strict liability if they added a loan to your report that didn't belong to you they'd change what they allow which would in turn force the credit issuers to be sure to get real proof of identity, otherwise they lose all recourse in trying to get the debt payed back.
    • I'm not sure more laws will help. The health industry is already under tons of laws like HIPAA and this still happened. I also believe that past some reasonable point, more and more regulations make people who do the actual work in the field (doctors in this case) resentful about their jobs.

      • by kbdd ( 823155 )
        At least it looks like the HIPAA data was not leaked. That is probably due to the HIPAA regulation and if so, they did work, so let's not throw the baby with the bath water.
  • by l3v1 ( 787564 ) on Thursday February 05, 2015 @09:20AM (#48988255)
    Simply WTF. If nothing else but "names, birthdays, medical IDs/social security numbers" would've been stolen, that in itself would've been much more then acceptable. Hell, one would expect the most sensitive data of people would be more protected... At the very least, the company should cover IDtheft protection expenses for _all_, for at least a year, maybe more. Plus, they should be fined, with such a large amount that they'd get scared, and start implementing _real_ data protection policies. Yeah, you wish...

    At companies and agencies handling such data, _all_ kinds of data leaks or thefts should be treated as criminal offenses and they should be punished, I mean really punished. If you can't handle the protection of the data, don't handle them in the first place.

    While I also consider the thieves to be criminals, I'm more angry with those, who simply are inept to protect their best assets, even more so since they have the money, manpower and resources to do so.

    Also, I'd like to see a national blacklist established, with all companies and agencies on it, who had similar massive data breaches, and made publicly available, so as everyone could judge and decide whether they'd like to entrust their data to such idiots.
  • by Cigamit ( 200871 ) on Thursday February 05, 2015 @09:27AM (#48988303) Homepage

    Its nice that they notified us today that our information was breached, but the real question is why they didn't notify us sooner.

    They setup a specific website about this breach.
    http://anthemfacts.com/ [anthemfacts.com]

    The problem to me is that they just now notified us, yet they registered the domain for the breach on 2014-12-13. Which goes to show that they knew about the breach nearly 2 months (or possibly more) before deciding to inform us.

    • Because as any good Security person knows, you have to follow the trail, and find as much information as possible about the hack. Notice they did not say a lot about how it was done, and they cannot even tell what was taken. They need time to work on that, and that is why they hired a digital forensics company to do that. They were required by law to disclose after a certain time frame (2 months), so they did. Otherwise they would have sat on this so they could answer every person's question properly an

  • Swedish said the breach is extensive: the vulnerable data included "names, birthdays, medical IDs/social security numbers, street addresses, email addresses and employment information, including income data," though "no credit card or medical information, such as claims, test results or diagnostic codes were targeted or compromised."

    Security was breached, personal information was stolen, but no CC or medical information. Can they tell us what prevented the theft of medical information? How can that information be used to prevent the future theft of data with other companies? Using the same methods, could it protect things like employment info and income data? Can systems be designed to be more bullet proof?

    My first guess is that the medical information was on different servers, maybe at different locations, and access to those systems

  • by mdecheser ( 4004767 ) on Thursday February 05, 2015 @09:49AM (#48988511)
    Has any information been release regarding how the attack was performed?
  • by EvilSS ( 557649 ) on Thursday February 05, 2015 @10:40AM (#48989093)
    The potential exposure for individual financial fraud and identity theft is really bad with this but it's not the only concern. With this breach they have SSN plus detailed employment info for what probably amounts to nearly every employee at any company who uses Anthem for their health plans. What do 90% of helpdesks ask for when resetting something like a password or issuing one-time use tokens for 2-factor authentication? Last 4 of your SSN. With a little work to figure out a few things like login ID formats this data could be used as a jumping off point to target any of the thousands of companies that use Anthem for their employee health plans, across who knows how many industries. This could be the breach that keeps on breaching for a long time to come.
  • Seems to be annual ritual now. Just watch accounts and credit histroy.
  • The bad guys took every other piece of relevant data about you, but not your credit card data; ya, right.
  • though "no credit card or medical information, such as claims, test results or diagnostic codes were targeted or compromised.

    Whew... what a relief! I was really worried there for a minute...

  • by kbdd ( 823155 ) on Thursday February 05, 2015 @11:54AM (#48989849) Homepage
    Why would my health insurance have my income data? What does it have to do with my health?

    How did they get it in the first place? Probably through my employer of course.

    Of course, they do not even acknowledge it on their FAQ any more, that was quickly removed.. Now it only says "employment information".

  • by bugs2squash ( 1132591 ) on Thursday February 05, 2015 @12:17PM (#48990103)

    By now my SSN must have been stolen several times from several different organizations that simply did not do their jobs properly. If there are consequences of this breach for me and I sue Anthem they'll just point to any of the many other ways in which my PII has been mishandled as a reason to dodge blame. Everyone uses the SSN, even costco asked for my SSN to join (I refused, but I bet there are many who didn't).

    The change has to be in the meaning of the SSN, If the government wants a unique numeric name for any individual I understand, but it's not the same as proof of ID. Proof of ID needs to be either something biometric or something to do with your relationships to other people (but then, Anthem gave away as much of that as they possibly could too).

  • "Someone's gonna kiss the donkey." -- Battleship

No spitting on the Bus! Thank you, The Mgt.

Working...