
Error by Systema Software exposes millions of insurance data records - wojer
http://www.databreaches.net/oops-error-by-systema-software-exposes-millions-of-records-with-insurance-claims-data-and-internal-notes/
======
ihsw
> 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...](http://www.databreaches.net/oops-error-by-systema-software-
exposes-millions-of-records-with-insurance-claims-data-and-internal-notes/)

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?

~~~
jon-wood
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.

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

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

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

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

~~~
UnoriginalGuy
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...](http://www.databreaches.net/oops-error-by-systema-software-
exposes-millions-of-records-with-insurance-claims-data-and-internal-notes/)

Where is it talking about drive rollover being the cause?

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

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

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

~~~
dj-wonk
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.)

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

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

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

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

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

------
pavel_lishin
> _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?

~~~
UnoriginalGuy
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...](http://www.databreaches.net/oops-error-by-systema-software-
exposes-millions-of-records-with-insurance-claims-data-and-internal-notes/)

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

------
peterwwillis
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)

------
callesgg
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)

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

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

~~~
yureka
It can be! [https://aws.amazon.com/compliance/hipaa-
compliance/](https://aws.amazon.com/compliance/hipaa-compliance/)

~~~
clarkevans
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...](http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/contractprov.html)
[2] [http://www.rackspace.com/en-
us/information/legal/hipaabaa](http://www.rackspace.com/en-
us/information/legal/hipaabaa)

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

~~~
clarkevans
[https://www.prometheusresearch.com/how-amazon-reminded-us-
th...](https://www.prometheusresearch.com/how-amazon-reminded-us-that-not-all-
business-associates-agreements-baa-are-created-equal/) (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...](http://webcache.googleusercontent.com/search?q=cache:tzvzlVGSuwAJ:https://www.prometheusresearch.com/how-
amazon-reminded-us-that-not-all-business-associates-agreements-baa-are-
created-equal/)

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

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

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

~~~
antsar
Why mention AWS at all, other than to mislead?

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

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

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

