[Beowulf] $1, 279-per-hour, 30, 000-core cluster built on Amazon EC2 cloud
Robert G. Brown
rgb at phy.duke.edu
Wed Oct 5 05:40:53 PDT 2011
On Tue, 4 Oct 2011, Douglas Eadline wrote:
>
> Several years ago I flippantly proposed what seems to be
> a simple way to ensure important consumer private data
> (medical, finance, etc.) was safe. Pass a law that says
> organization who collects or holds personal data must
> include the same data for organization's Board of Directors and
> officers (CEO, COO etc) in the database. At least
> the CEO might start taking security serious when
> someone in Bulgaria is buying jet skies with his AMX card.
It wouldn't help. Physicians are too clueless to understand or care
(mostly, not universally) and besides, what can they do? They don't
write software. The companies that provide the software won't have
their board's information in the DB under any circumstances, and they
are the problem. Or rather, the unregulated nature of the business is
the problem. The government is spending all sorts of energy specifying
the detailed structure of the DB and ICD codes for every possible
illness at a staggering degree of granularity so that they can
eventually micro-specify compensation rates for fingering your left
gonad during an exam but are leaving HIPAA -- a disaster from day one in
so very many ways -- in place as the sole guardian of our medical
privacy.
HIPAA fails to specify IT security, and obscures precisely who will be
held financially responsible for failures of security or what other
sanctions might be applied. HIPAA has had the easily predictable side
effect of placing enormous physical and financial obstacles in the path
of medical research, to the point where I think it is safe to say that
HIPAA alone has de fact killed thousands to tens of thousands of people
simply by delaying discovery for years to decades (while costing us a
modest fortune to perform such research as is now performed, with whole
departments in any research setting devoted to managing the
permissioning of the data). Finally, HIPAA's fundamental original
purpose was to keep e.g. health insurance companies or employers from
getting your health care records and using them to deny coverage or
employment, and it didn't really succeed even in that because of the
appalling state of deregulation in the insurance industry itself.
It's really pretty amazing. It's hard to imagine how anyone could have
come up with a piece of governance so diabolically well designed to be
enormously expensive in money and lives while failing even to accomplish
its own primary goals or the related goals that it SHOULD have tried to
accomplish (such as mandating a certain -- high -- level of security and
complete open-standard interoperability and data portability in emergent
EMR/PM systems, at least at the DB level), even if they tried. However,
we should never be hasty to ascribe to human evil that which can
adequately be explained by mere incompetence and stupidity.
But this is OT, and I'll return to my muttons now. Soap box out.
rgb
>
> --
> Doug
>
>
>
>
>
>> On Tue, 4 Oct 2011, Lux, Jim (337C) wrote:
>>
>>>
>>> The reason it wasn't encrypted is almost certainly not because it
>>> was difficult to do so for technology reasons. When you see a story
>>> about "data being lost or stolen from a car" it's because it was an ad
>>> hoc situation. Someone got a copy of the data to do some sort of
>>> analysis or to take it somewhere on a onetime basis, and "things went
>>> wrong".
>>>
>>> Any sort of regular process would normally deal with encryption or
>>> security as a matter of course: it's too easy to do it right.
>>
>> The problem being that HIPAA is not amused by incompetence. The
>> standard is pretty much show due diligence or be prepared to pay massive
>> bucks out in lawsuits should the data you protect be compromised. It is
>> really a most annoying standard -- I mean it is good that it is so
>> flexible and makes the responsibility clear, but for most of HIPAA's
>> existence it has provided no F***ing guidelines on how to make protected
>> data secure.
>>
>> Consequently (and I say this as a modest consultant-level expert) your
>> data and mine in the Electronic Medical Record of your choice is
>> typically:
>>
>> a) Stored in flat, unencrypted plaintext or binary image in the base
>> DB.
>>
>> b) Transmitted in flat, unencrypted plaintext between the server and
>> any LAN-connected clients. In other words, it assumes that your local
>> LAN is secure.
>>
>> c) Relies on third party e.g. VPN solutions to provide encryption for
>> use across a WAN.
>>
>> Needless to say, the passwords and authentication schemes used in EMRs
>> are typically a joke -- after all, the users are borderline incompetent
>> users and cannot be expected to remember or quickly type in a user id or
>> password much more complicated than their own initials. Many sites have
>> one completely trivial password in use by all the physicians and nurses
>> who use the system -- just enough to MAYBE keep patients out of the
>> system while waiting in an examining room.
>>
>> I have had to convince the staff of at least one major EMR company that
>> I will refrain from naming that no, I wasn't going to ship them a copy
>> of an entire dataset exported from an old practice management system --
>> think of it as the names, addresses, SSNs and a few dozen other
>> "protected" pieces of personal information -- to them as an unencrypted
>> zip file over the internet, and had to finally grit my teeth and accept
>> the use of zip's (not terribly good) built in encryption and cross my
>> fingers and pray.
>>
>> Do not underestimate the sheer power of incompetence, in other words,
>> especially incompetence in an environment almost completely lacking
>> meaningful IT-level standards or oversight. It's really shameful,
>> actually -- it would be so very easy to build in nearly bulletproof
>> security schema that would make the need for third party VPNs passe.
>>
>> I don't know that ALL of the EMRs out there are STILL this bad, but I'd
>> bet that 90% of them are. They certainly were 3-4 years ago, last time
>> I looked in detail.
>>
>> So this is just par for the course. Doctors don't understand IT
>> security. EMR creators should, but security is "expensive" and they
>> don't bother because it isn't mandated. The end result is that
>> everything from the DB to the physician's working screen is so horribly
>> insecure that if any greed-driven cracker out there ever decided to
>> exclusively target the weaknesses, they could compromise HIPAA and SSNs
>> by the millions.
>>
>> Sigh.
>>
>> rgb
>>
>>> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
>>> To change your subscription (digest mode or unsubscribe) visit
>>> http://www.beowulf.org/mailman/listinfo/beowulf
>>>
>>
>> Robert G. Brown http://www.phy.duke.edu/~rgb/
>> Duke University Dept. of Physics, Box 90305
>> Durham, N.C. 27708-0305
>> Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
>>
>>
>> _______________________________________________
>> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
>> To change your subscription (digest mode or unsubscribe) visit
>> http://www.beowulf.org/mailman/listinfo/beowulf
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>
>
> --
> Doug
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
More information about the Beowulf
mailing list