A discussion of why USA healthcare regulations apply to more software than you realize, why people working in DevOps should care, and tactics for building fluency and proficiency in security and privacy.
Burden in Startups
Elliot Murphy @sstatik [email protected]
Why it matters in general
Why you should personally try to level up on security/privacy/safety
Current scene (what software subject to regulations, who enforces regulations)
Speciﬁc tactics for building ﬂuency and proﬁciency
Typically two broad sets of regulation come to mind: PCI and HIPAA.
Not talking about PCI, because I’m pretty sure all of you work at companies that have ﬁgured out how to charge money for things. What I want to talk about today is:
Battling risk & cost in
Who here works on healthcare software?
I mean who works on software that is governed by regulations about safeguarding personal data connected to healthcare records (audience interaction/voting)
I spent 3 years working in a startup working very hard to comply with regulations. We estimated that in a 10 person SaaS company, compliance was 30% of our costs.
That burden actually stops people from building new products that could make lives better because of the cost/complexity - this stiﬂes innovation in purpose-built
healthcare software. This means that general purpose software comes to market faster and has much greater utility than purpose-built healthcare software, because it is
perceived to have less of a burden, less compliance overhead to develop. Yesterday Jennifer mentioned someone using PagerDuty to monitor glucose levels.
As the laws have changed over the last couple of years, suddenly these regulations apply to *much* more software than before. And when legislation catches up with IoT,
there will be even more. In 2013 when Amazon and Google suddenly started signing HIPAA BAA agreements after years of insisting that they didn’t have to - why?
Regulations now apply to vendors and subcontractors, even if you didn’t sign an agreement with your customer.
security and privacy typically
neglected when running
general purpose web services
Assert that today’s typical engineers are much better at scaling than securing
Assert that today’s typical application designs are much better at violating privacy than preserving dignity
This is a form of local optimization, scaling hurts now, security hurts later, privacy is complicated. People have lots of work to do, there are very real costs to spending
time on security and privacy vs features. Just like network conﬁguration, the state of the art in security/privacy is lagging behind. The path of least resistance is to build
and run insecurely, and with minimal privacy protections.
Why work on this
problem at all?
Another name for security/privacy is SAFETY
Vulnerable populations are growing: status, geography, gender, age, chronic conditions
Those of us attending conferences are in the prime of our careers / sweeping generalization and oversimpliﬁcation: least vulnerable of our lives.
All will revert to vulnerability before they die, and right now we have the most power to change the status quo.
Regulations exist to protect vulnerable populations. HIPAA enforcement by Oﬃce of Civil Rights (OCR).
Practice or the practical application of scientiﬁc knowledge is falling behind the research - 12 years or more behind. Thesis is the reason it is so far behind is becase
when we declare that software is for healthcare, it is
Regulations are spiraling in complexity, and software is oozing into health-aﬀecting roles faster than we are able to reason about it. Software becomes part of the care
pathway whether it was intended to or not.
One example: HelpScout, helpdesk software, obviously not health care related: can’t have customers in healthcare without being HIPAA compliant! Those requirements
roll all the way down the chain. If you are going after a sizable market at all, you will need to care about HIPAA compliance.
An example of my claim that the current state of the art in app security is not good enough for vulnerable populations: Glide: Beth’s story
TAKE PICTURE I LOVE YOU. Promise from community - I will build empathy for vulnerable people, and I will apply that empathy to all software I work on.
My friend Beth. Beth copes with two profound vulnerabilities (in addition to being poor):
Very limited muscle control, she is in a power chair and cannot hold her head up.
Deaf - communication is a constant challenge.
Very bright and technically savvy - see computer in the background. Story has two morals: all software can become part of the healthcare chain, and we suck at
operating secure web services.
Example of challenges caused by communication: staﬀ lifting into her bed recently tore the tendons in her shoulder so badly she could not sign with dominant hand, and
needed surgery. Because of limited communication, she was unable to report the incident. Staﬀ denied she needed medical attention.
In this life context, Beth was very excited to use glide.me. Not picking on glide, just a real life example, wonderful group of people doing their best to make an app that
has been a surprise hit in the deaf community. Glide is video based messaging. Cross platform, closer to text messaging or chat than to a video call. Remember that
Beth is poor, so she does have a tablet that has wiﬁ access but does not have a mobile phone. Glide requires SMS veriﬁcation to combat fraud in order to activate.
Contacting support, no problem, they can call a land line. Beth does have access to a video phone, government pays for a voice to video relay service. The land line
conﬁrmation consists of a computerized voice spitting out four numbers as soon as the interpreter answers the phone, before the interpreter can get Beth onto the video
phone. Eventually, by having some friends help defeat the system, Beth gets access, and can communicate with her friends and advocates. Beth can then seek
assistance in getting care, which includes discussing risky details about who injured her. Risky means she has been threatened with being kicked out of the home for
asking for equipment that can transport her without injury.
Why should we, the people at DevOpsDays, care about this?
Most of us don’t identify as working on “healthcare”.
Plato's Allegory of the Cave
People living inside the cave see shadows on the walls, caused by unseen actors outside the cave, and think the shadows are reality - don’t know the people outside the
cave exist, don’t know any of the details. In the DevOps community, we see shadows, stories about security and privacy being complicated, and rules being
burdensome, and we accept that indirect knowledge as reality. When one is painfully dragged out of the cave and exposed to additional details outside, they understand
more of the world and what is causing the shadows. When they return the to cave with diﬀerent versions of reality, people think they are damaged and refuse to learn. In
this case, the reality outside is that the rules do apply to you, even though enforcement is currently poor. The utility of general purpose software is greatly outpacing the
utility of special purpose software, and we should not try to stop it.
One pop culture ﬁlm that draws heavily from Plato’s allegory of the cave is the Matrix.
This is (I think) the most interesting character in the story, a character that I ﬁnd immensely inspiring as an archetype. The Keymaker can move between arbitrary worlds
and contexts. The Keymaker can enter and leave many caves, without being dragged. Does not have the most power, but you could argue has the most ideal situation
for being able to develop empathy.
Of course empathy and understanding multiple worlds is key to DevSecNetCustomerOps. We are the ones in the throes of building and running the general purpose
software which oozing into every facet of our lives, and we are the ones making decisions that ultimately will aﬀect us personally as we transition back into “vulnerable
populations”. We are the ones most able to understand all the tradeoﬀs involved in securely operating web services for the public, and in fact have the ability to improve
security and privacy faster than it can be legislated. I think this might be called self-regulating.
So thats why, and why us. Lets go through some doors.
HIPAA & HITECH
who enforces the rules?
OCR: Ofﬁce Civil Rights
FDA: Food & Drug
FTC: Trade Commission
SAG:State Attorney General
IoT regs haven’t hit yet
You would think, that an even simpler question than “What are the rules”, is “who enforces the rules”? Turns out they are both complicated.
OCR is responsible for enforcing security and privacy rules of HIPAA. Done when a complaint is received
State Attorney Generals have overlapping jurisdiction, and started enforcement actions in 2010.
Food and Drug is also responsible for medical devices, and has been grappling with understanding mHealth, or when does a smartphone become a medical device?
Federal Trade Commission is responsible for consumer protection, and could get involved with large scale breaches of consumer privacy or mishandling of consumer
Enforcement actions don’t necessarily provide restitution to the injured party, so private lawsuits come into play.
Understandably, when ﬁrst exposed to this reality, we might want to head back into the cave, try to kill anyone who wants to talk about these things.
In vernacular of the matrix, take the blue pill, happy and ignorant.
Lets not do that. Let’s get really good at running safe, secure, privacy-preserving services.
When Glenn gave his opening remarks, he joked about not wanting to work with enterprises because of there being too much red tape. There is truth to this, a regulated
environment can easily be stiﬂing to work in. Especially true if you start from the perspective of the rules rather than the perspective of the end goal, safeguarding a
vulnerable person. I think about it like version control: if you’ve been in the industry for a while, you remember there was a time when a lot of work was done without
version control, because version control was “too much overhead, too stiﬂing”. Then networked version control came along, then distributed version control, then
collaboration tools like github. Now NOT using version control will slow your project down. We’re overdue for a similar transformation when it comes to running securely
and privately. The more stories we can share about how we are tackling these challenges, the faster the transformation will be from painful, to highly performant.
Don't worry about whether the rules apply to you (because they tend to start applying to you without much warning). Just do a good job.
But what are the rules?
What is a good job?
What doesn’t work: A checklist-based approach to compliance is not suﬃcient. https everywhere, encryption at rest, etc are good things but not suﬃcient to count as a
“good job”. Instead, we need to think about the larger goal - cultivate empathy and solve for the real goal.
Just as we develop ﬂuency with organizational patterns, group behaviors, systems thinking and human error, develop ﬂuency with security and privacy, and understand
the connection to real people.
First: What information needs to be safeguarded: personal info.
Second: Who is supposed to be safeguarded? Techniques from UX design serve you well here, personas or roles. A nurse, a patient, a CEO, a sysadmin.
With the superpower of empathy, we can develop controls that are BOTH more eﬀective and cheaper than what the regulations steer you towards.
Concrete application: illustrate with story about "Who's seen my stuﬀ" feature.
For a few years I worked on CommonGround, which is a web app that patients use together with their psychiatrist and care team. It keeps records of each visit, how
things are going, how symptoms are, how self-care is going, etc.
HIPAA privacy rules require covered entities to tell patients, on request, who their private information has been disclosed to. This is the sort of requirement that often gets
muddled up in all kinds of technical excuse-making and ﬁnger pointing, analyzing which parties the law applies to, which kinds of disclosures have to be told, what kind
of exceptions are allowed for psychiatric notes. You can wrap this all up inside Terms of Service, pay a lawyer to tell you that everything is “compliant”.
Why does this rule exist? Whats the risk, and how does it show up inside this particular system? Whats the intention? Who is being protected? How can the system work
without introducing lots of extra audit and log review? Who audits the auditors?
Clinical staﬀ, with passwords, often have access to a much larger group of patients than they normally work with, for emergency coverage. Same for doctors,
prescribers, etc. Enforcement typically happens when there is a complaint. How can we detect small scale abuse of power? When 100K records are stolen, that gets
#2 Read the rules
Given knowledge of and empathy for the people who are entrusting their data to you, the MOST liberating step you can take is to actually read the rules. This is coming
out of the cave and getting a richer understanding of the world. It is amazing how many people never do this. It’s amazing how many policies or ways of doing things are
etched in stone because of 3rd hand corrupted misinformation about the regulations. Someone was teasing me about consulting work and saying that it’s basically
reading-as-a-service. It’s easy to get bored/lost when reading regulations, so start a reading group, and write down a document with a simple mapping of each rule to
speciﬁc policies and practices in your organization.
Do you need the data at all? Understand that encrypting passwords is best practice, but what about everything else on the User model?
Can the person decide to disclose the data? YES
How do we protect the customer against abuse of power by people with keys?
#3 Tell more stories
How can I gain experience and participate in stories when I don’t directly work on a product with speciﬁc security goals?
Voluntarily adopt some requirements. Don’t say “hey I want to voluntarily spend money on regulations that don’t apply to us”. Instead, do a risk assessment over lunch.
Pick the thing that is highest risk, and start chipping away at making it better. Tell stories! If you are writing tools for others, include security and privacy considerations in
your docs and tutorials.
Bad: conﬁguration management example that glosses over secrets management
Bad: code example from a database vendor or language advocate that glosses over encrypted connections
Bad: web frameworks (and web service frameworks) that default to mutate-in-place data stores and incredibly diﬃcult audit trails
Bad: multi-factor authentication solutions that completely ignore the most vulnerable people in our society (poor, chronically ill, etc)
All boils down sharing more stories we can share about how to eﬀectively secure applications and data
Good: Catalyze.io for publishing policies and training
Good: Ansible having Vault, Chef having encrypted data bags
Good: Google oﬀering HIPAA BAA contracts at no extra charge!
Good: AWS oﬀering Key Management System at a fraction of cost of HSM
Good: Dustin Collins Conjur blog about Secrets and Source Control Maturity Model, pluggable tools
Future dreams: Secure Multiparty Computation, Homomorphic encryption such as https://sharemind.cyber.ee/
Get in touch: