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