[Beowulf] $1, 279-per-hour, 30, 000-core cluster built on Amazon EC2 cloud

[Douglas Eadline]

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.

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