Error by Systema Software exposes millions of insurance data records | Hacker News Reader

Error by Systema Software exposes millions of insurance data records

databreaches.net

90 pointswojer54 comments

> were posted in the clear to Amazon servers by insurers using Systema Software.

Posted in the clear? As in, transmitted over unencrypted channels, dumped on public-facing FTP server, or what?

> Texan techie Chris Vickery spotted the files

Spotted the files? What does this even mean? Did he run some kind of crawler? That can land you in quite a lot of hot water, actively searching for these kinds of files.

> on Amazon web servers

Public-facing EC2 instances with no authentication? Public-facing S3 files? ????

This article is so scarce on details it's impossible to determine whether AWS, Systema Software, or users of the software are at fault. I'm inclined to point to Systema Software for not knowing how to properly secure their AWS assets.

EDIT: as mentioned elsewhere and in the article, the original source for this article is here:

http://www.databreaches.net/oops-error-by-systema-software-e...

HN mods might want to change the submitted URL to that.

After reading the article, a production S3 bucket was set to be open to the world. Pretty frightening that Systema would let that happen. Perhaps AWS' Trusted Advisor service should check for that?

Tbh I find the article title inflammatory as it implies AWS is at fault or that AWS is in any position to mitigate the problem to begin with. Do we blame car manufacturers when motorists drive drunk?

The Register is the tech world's gutter press, full of barely researched inflammatory articles. I hold about as much regard for them I as I do the Daily Mail.

Thanks, we updated the URL from http://www.theregister.co.uk/2015/09/21/amazon_medical_gaffe....

At least the article didn't blame a "glitch"

Mentioning AWS in this is just spreading anti-cloud FUD. AWS had literally nothing to do with this: the insurer could have just as easily made the same mistake in their own datacenter. They hold all the blame and trying to involve Amazon is pure sensationalism.

The only exception to this line of reasoning is that S3 buckets have the option of being open to the world---an option that may not be as flip-the-switch simple if the insurer needed to cobble together their own solution, because why would that information ever need to be world-visible?

Of course, cobbling together one's own solution opens up an entirely different (and generally larger) security surface.

> The only exception to this line of reasoning is that S3 buckets have the option of being open to the world

So do many/most cobbled-together solutions, many of which depend on FTPing files to a random web server and depending on .htaccess for protection.

I'm not sure what AWS has to do with anything - is the article suggesting that AWS was some how complicit in this? Edit: it sounds as though the user got a new instance with data already on the drives? Thats a bit different...

You're the second person in this thread to claim this? Are you reading something I am not. They talk about exactly how they got it here: http://www.databreaches.net/oops-error-by-systema-software-e...

Where is it talking about drive rollover being the cause?

There isn't anything that states that, hence the question I had. It comes from these lines in the linked article:

> Vickery has worked with the state attorney general's office to wipe the records from his hard drives and has cooperated with investigators.

> Systema Software said in a statement that initial reviews indicate Vickery was the only unauthorised user to have accessed the files.

Otherwise, why is AWS being mentioned at all...

I can practically guarantee that AWS has no role in this beyond being the host. Someone somewhere uploaded them without the proper permissions.

This is one reason we're moving off AWS and Azure at the moment. Not because of them but because it's so damn easy to accidentally fuck something up on this scale and that would be endgame for us. There is not much between deploying a correct and a faulty bucket policy that instantly exposes your entire archive over the internet.

If it is a CIFS / NFS mount on your own infrastructure, then not so easy.

On one hand, I see what you are saying. Other systems make it harder to make changes -- I get it. But is "harder" and "slower" better? Or it just gives humans more time to correct errors?

Many things can be misconfigured -- should we avoid those things and prefer things that are harder / slower/ more manual to configure?

It seems problematic to hear you someone moving away from a solid, tested, automated, fine-grained, multi-layer permission system (AWS with IAM) because it is "too easy to mess up". Let me ask this: what would it take to neutralize the "it is too easy to mess up" argument?

I'd summarize the overall problem this way. People make mistakes. Mistakes take time to surface. Certain kinds of mistakes are worth avoiding, even if it slows down a process.

What are the solutions to this problem? A: Use a slow, tool that does not allow quick, possibly dangerous changes. B: Continue using fast, easily configurable solutions but build technology and process around them to provide the guarantees your business needs.

The problem with the problem A, as described, is you lose the benefits of the fast, nimble system because you want to slow things down.

It seems to me that (B) is worth considering. Perhaps you could look into additional internal tooling and/or process to verify permissions.

(Keeping configuration carefully controlled is essential in any case.)

Well we use option C which is a layered architecture with default deny policies between each layer.

It's not about speed but about the consequences of making a bad change.

Adding tools never decreases risk. Adding process never decreases risk.

Start from impossible then make it possible. Dont start from possible and then make it less likely.

> But is "harder" and "slower" better? Or it just gives humans more time to correct errors?

For risk mitigation, these are somewhat equivalent. There's a reason critical switches get molly-guarded.

You are totally right but there are people for shom some kind of risks cannot (as in they deem it totally impossible) be outsourced: either total responsibility (and hence no delegation) or no business.

They really should offer ways to disable public access by default. Same as having ways to disable deletes without some kind of secondary confirmation.

Correct me if I am wrong but this is literally a felony under HIPAA

Putting it up there, having it there (owner or AWS?), viewing it there, or having copies ending up on the viewer's disk?

HIPAA has strict standards for storage and transmission.

So that would be the person putting it there.

But you can fax medical data under HIPAA so go figure.

> HIPAA has strict standards for storage and transmission.

If only. HIPAA barely has technical standards (much less strict ones) at all, essentially, the only ones are backed into through the HITECH Act breach notification requirements (and, because of that, there's some debate as to the extent to which they are requirements, since technically the HITECH act standards aren't requirements for how data has to be treated, they are standards for determining, once a breach occurs, whether the breach was of "unsecured" PHI); HIPAA's standards are mostly administrative rather than technical.

Lots of vendors sell particular technical solutions as being HIPAA compliant or even required-under-HIPAA, but that's mostly marketing bafflegab rather than a reflection of those products following clear and strict technical standards laid down in HIPAA and its implementing regulations.

Yep, we can't fedex a server with HIPAA data unless it has encrypted drive. Or mail backup tapes for that matter. But that banker box full of claim statements? Go right ahead.

To be fair, a backup tape can have a couple TB worth of claims whereas a banker box has got maybe 5000 if you pack'em real tight.

As far as I know virtually no one has ever been "convicted" of a HIPAA violation. It's pretty much a nothing threat. My employer back a few years just paid off some audit firm despite a complete lack of interest in securing our production servers.

you can fax over POTS lines because common carriers (telcos, basically) are considered secure. But HIPAA's 'standards' are anything but strict. It doesn't spell out any standards other than noting the difference between data in flight and data at rest and that both should be secure. In some ways this is probably a good thing, in that it doesn't keep the industry locked to standards that are broken on down the road. On the other hand, because HIPAA does spell out lots of nasty penalties for breaking the rules, it would be nice to have some clarity about what the rules are.

> Texan techie Chris Vickery spotted the files on Amazon web servers and reported the breach to Systema Software.

> Vickery has worked with the state attorney general's office to wipe the records from his hard drives and has cooperated with investigators.

> Systema Software said in a statement that initial reviews indicate Vickery was the only unauthorised user to have accessed the files.

I thought AWS would wipe volumes before assigning them to different users?

That isn't how they said they got the information, so I don't understand the relevance. This is how they said they got the information: http://www.databreaches.net/oops-error-by-systema-software-e...

Ah, I took "his harddrives" to mean "his EBS volumes" or something similar.

Sounds like he found them on someone else's publicly accessible s3 volume and downloaded them. He probably agreed to destroy his own local copies.

Yes it looks like somebody a: copied unencrypted backups to S3 and b: set the s3 bucket to be publicly accessible

BIG oops.

Security has nothing to do with their business model. You're not going to stop going to the doctor just because they leak medical records. You need them more than they need you. Not only is there very little legal repercussion, but it's enough for them to just be aware of and document the leaks in their system. I wouldn't expect record privacy from any health care provider (or educational facilities for that matter)

Are names, addresses, social security numbers/tax ID numbers, phone numbers, state, and zip code's all secret in the US?

Tax ID numers i dont know what those are, but all the others are open information here in sweden.

I can go to a website find out any* persons legal status(maried, single.., current resident, social security numer, names and so on)

*(there is exceptions for some people)

The basic problem is that, many years ago, we somehow decided as a country that your SSN was a valid GUID for a person, and one that could be used to secure lines of credit and all sorts of other things. At the same time, we decided that there was no reason to make it properly secured or obscure, or to make it easy to make a new one, or anything else.

So, it's this kind of quasi-bad thing that is mostly just good for getting your identity stolen.

What were these records doing on AWS in the first place? AWS isn't HIPAA compliant, surely?

It can be! https://aws.amazon.com/compliance/hipaa-compliance/

While Amazon offers a business associate agreement ("BAA"), our legal review found it to be unacceptable -- the BAA we were privately provided last year significantly deviates from the standard language recommended by the U.S. Department of Health and Human Services [1].

Notably, Rackspace's BAA is public [2] (I'm not associated with Rackspace) and reasonably supports the standard language (I am not a lawyer).

[1] http://www.hhs.gov/ocr/privacy/hipaa/understanding/covereden... [2] http://www.rackspace.com/en-us/information/legal/hipaabaa

Would you happen to remember any issues your team had with Amazon's BAA that they didn't have with Rackspace's?

https://www.prometheusresearch.com/how-amazon-reminded-us-th... (2014)

In particular, Amazon's agreement included: A clause that puts all of the burden for securing data on the CE. No terms outlining how the BA would respond to breaches of unsecured PHI. Lack of specification about the BA’s level of access to PHI. A non-disclosure clause.

EDIT: Google Cache for this page... http://webcache.googleusercontent.com/search?q=cache:tzvzlVG...

AWS offers a BAA with some services

https://aws.amazon.com/compliance/hipaa-compliance/#What_Ser...?

Offering a BAA is necessary, but not sufficient, to be a HIPAA-compliant service.

You'd be surprised (or many not!) of the percentage of healthcare companies which aren't HIPAA compliant.

But that's illegal...

Well, yes and no and yes and no.

HIPAA doesn't actually protect you as much as you'd think--for example everyone who is signed on as a business partner (and similarly HIPAA qualified) can, if memory serves, view records.

They can, but they are similarly bound to have audit records of access, restrict access to only those with a business need to the information, and most importantly, BA's have a duty to notify of a breech. Prior to HITECH it was only the provider who was obligated to notify of a breech—business associates could do pretty much whatever they wanted as far as CMS was concerned, though the data sharing agreements oftentimes had more teeth to them than HIPAA itself.

Yes, "bound." However those things are never really checked.

Seeing as how I'm the guy that used to do the checking, I humbly disagree.

I reported the same vulnerability to a company with millions of users last week, as of now it is still not fixed ...

Misleading title. AWS did not expose these, but the insurers using AWS did.

Its not misleading at all, any more than "1.5 million medical records found on street" would be if the insurer had dumped paper records on the street.

(Nor does it implicate AWS as responsible, any more than the analogous one would implicate the street as responsible.)

Not really. It says "exposed on AWS" which these records certainly were stored there, not "exposed by AWS" which would have been misleading and untrue implying AWS did the leaking. Semantics for sure, but not at all misleading.

Why mention AWS at all, other than to mislead?

Title on Hackernews I don't have a problem with, title on The Register I can agree with you...

Clickbait for sure, but that's media.

It is not completely misleading to all users but enough for me to say something.

>Systema Software said in a statement that initial reviews indicate Vickery was the only unauthorised user to have accessed the files.

Ashley Madison moment right here.

this reminds me of all the cloud based enterprise tools that depend on AWS that proudly shows 'HIPAA compliant, Securely hosted on Enterprise Grade Cloud from AWS'.

>Insurance Authority area, there are nearly 3 million payment entries dating back to 1987 that contain the following fields:

that is insane

Reply on news.ycombinator.com