A culture of safety

Discussions of security, compliance, and safety all too often start and end with technical controls. In this talk I'll share experiences helping multiple companies meet the demands of regulators and customers for safeguarding medical data without driving the engineers to frustration. No buzzwords or FUD, just real human experience of overcoming the challenges to applying infrastructure as code in traditionally conservative domains.

Transcript

1. Minimizing misery A culture of safety in regulated environments Elliot Murphy @sstatik kindlyops.com Worked for a couple of decades now on mission critical systems: telephone systems for emergency centers, backup software, databases, operating systems, healthcare web app for mental health treatment, as a consultant to regulated companies: increasingly been exposed to policy, and the hard work involved in making rules for others or trying to figure out: are we doing a good job? Minimizing misery really is about the people involved. Safety comes from people! If people are irritated they won’t be doing a good job. I want to tell you why you should care, and then 3 big ideas.
2. Regulations are increasing October 2105 Court Justice of the European Union repeals Safe Harbor April 2016 European Commission passes General Data Protection Regulation 2016 US Office for Civil Rights begins Phase 2 HIPAA audit program. Elliot Murphy @sstatik kindlyops.com Increased regulation means increased scrutiny while we are just trying to work, and can lead to deep frustration. Sometimes regulations are applied in stupid ways, sometimes regulations are misunderstood, but they aren’t all bad. Sometimes engineers see extra effort and cost as waste, and this is a hypocritical and unhelpful perspective. Tell me about how rules for protecting customers are wasteful and then tell me about how you aren’t using load balancers & replicated data for high availability. Instead: lets talk about some ways to reduce the frustrations.
3. 1. Connect controls to requirements Empower engineers to understand how to completely change the controls while meeting the original requirement. Elliot Murphy @sstatik kindlyops.com Sometimes you have regulations, or laws, that require something specific. Usually they are a bit vague about how to accomplish it: example that is easy to understand: you must use encryption in transit and at rest. Many different ways to accomplish it: GPG, TLS, encryption before/in/under database. Then you get requirements that change over time: they come from a customers well-intentioned security policy, or from changing guidance about interpretation of the regulations. Crucial that you maintain a map of where each regulation came from. STORY: about one state not allowing vendor hiring of people with a misdemeanor criminal record. Maintained a tight connection between that control/hiring policy and that customer. Options: not hire someone, hire and define their job such that it didn’t require access to this customer, fire the customer. Any of those options would leave us compliant. Bad thing to do would have been to enshrine this rule in company policy and forget where it came from. Rules need half-lives, context.
4. 2. Solve for intent Some policies are out of date, don’t use them as an excuse to do a bad job. Remember the humans that have to use the system. Elliot Murphy @sstatik kindlyops.com Don’t just meet the letter of the law, remember there are real people, real human factors involved in systems. Story of Beth, difficulty with muscle control, in a power chair, deaf, uses video phone. Trying to sign up for Glide, video instant messenger, required SMS confirmation. Beth doesn’t have a cell phone. No problem, can make a voice call instead. Uses a video interpreter, automated system spits out 4 numbers before the interpreter can get Beth on the video phone.
5. 3. Always be auditing Search for Racist Algorithms Accountable Algorithms http://papers.ssrn.com/sol3/ papers.cfm? abstract_id=2765268 Elliot Murphy @sstatik kindlyops.com Please please be building auditing into the systems. It’s a two-fold protection, it protects customers and it protects operators from wrongly being accused. Auditing is particularly useful when trying to DevOps: grant broad permissions and then review how they are used. Auditing We’re rushing headlong into a pretty serious problem, which is that auditing is getting more and more impossible due to the volume of data and the fact that more and more is being done by algorithms. There have been multiple incidents in 2016 when we have been shocked at the results coming from algorithms, and it’s crucial that we figure out how to audit our algorithms and data.
6. Elliot Murphy @sstatik kindlyops.com https://speakerdeck.com/statik/a-culture-of-safety All images from unsplash.com 1. Regulations are part of our life 2. Connect controls to requirements 3. Solve for intent 4. Always be auditing 5. It is possible to work in an environment where risk is present and still enjoy it. 6. Starting a podcast called safety at speed, with a focus on the human side of things. I’ve been in touch with some of you and asked for interviews, if you would like to share stories please come say hello and I’d love to interview you.