Educause Security Discussion mailing list archives

Re: High Performance Computing for Regulated Data


From: Anurag Shankar <ashankar () INDIANA EDU>
Date: Fri, 13 Nov 2015 14:00:45 -0700

Hello Matthew,

Nick was referring to my presentation at TechEx.  I've been involved in helping Indiana University achieve and maintain 
HIPAA compliance for our central HPC cyberinfrastructure since 2008.  We have implemented the NIST risk management 
framework at IU.  We use it to addresses HIPAA by aligning systems with the NIST low security baseline, mapping HIPAA 
to NIST using NIST 800-66, then addressing the HIPAA safeguards that don't map to NIST.  (NIST actually allows us to 
handle not just HIPAA but cyber compliance in general.)  As for cost, it has taken 1 FTE to ensure HIPAA compliance so 
far for 36 different central systems, both HPC and non-HPC. If you already have a reasonable level of security and 
institutional policies and procedures in place, it is not that hard to implement HIPAA. You WILL need to do a lot of 
documentation however.

At the risk of being too verbose, let me describe below what I have learned in the last eight years as it may be useful.

For many, HIPAA immediately brings to mind a Herculean vision (at least that's been my experience).  People immediately 
equate HIPAA to security controls (not appreciating that it is really all about managing risk).  If the seven years 
since we started our HIPAA project have taught me anything, it is that a control-centric approach to cybersecurity is 
largely counterproductive.  It wastes effort because controls that may seem attractive at first are often ineffective.  
Instead, being risk-centric optimizes resources and provides real protection. In our environment, for any given gap we 
first determine if a seemingly relevant security control actually mitigates risk.  Let me give an example.  Whole disk 
encryption is a popular control that is widely touted as a panacea, but in reality effective only when the data is 
vulnerable to physical theft or loss.  It is great for laptops and mobile devices but pretty much ineffective for 
servers located in a secure Data Center.  The risk on servers is typically an attacker exploiting a vulnerability to 
get root or getting in using legitimate user credentials obtained via phishing. So we reinforce the host, use a host 
firewall to restrict incoming to port 22, and educate the users about phishing.   Our risk response document indicates 
the lack of whole disk encryption on the server as a low risk, documents the reasons, identifies the actual risk, and 
describes alternate controls that mitigate it.  This addresses part of the (addressable) HIPAA encryption safeguard.   
A far more effective way to use encryption at rest on a server is to require that the data be encrypted prior to 
arriving on the server.  It's not always possible or practical, but we encourage users to use it when they can.

At the Internet2 meeting where I gave my presentation, there was a session discussing security for Science DMZs (which 
I think is what Nick was alluding to).  The central discussion there was about how HPC should deal with unhappy CISOs 
and CIOs who do not like any systems outside the perimeter firewall.  All I can tell you that all our HPC systems have 
been outside the perimeter firewall ever since deployment and will probably remain so despite HIPAA.   We handle the 
situation by (a) identifying their presence outside the firewall as a risk (in our risk assessment report), (b) 
accepting the risk and reasons -- that HPC is critical to the university's research mission, that firewalls are 
anathema to the massive HPC data flows, and that a firewall that can handle these flows without degrading performance 
either doesn't exist or is too expensive, (c) documenting alternate controls that are in place and how they mitigate 
risk, and (d) noting that their presence has kept the system incident-free for the past eight years.  We top it off by 
pointing that we have an excellent incident response procedure in case we do end up with a breach.

I should add that we can do all these because our HIPAA compliance folks are on board with us.  It may not fly where 
you are since local risk tolerance varies.  Still, it may be possible to persuade the locals by pointing out that HIPAA 
was not designed to hinder research.  Compliance cannot be an impediment to a university's mission. 

I am happy to talk with you (and others) further if you think it'd be useful.

Regards,

Anurag

---
Anurag Shankar, <ashankar () iu edu>
Senior Security Analyst, Center for Applied Cybersecurity Research (http://cacr.iu.edu)
Indiana University


Current thread: