Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Securing Your Healthcare Data with OPA - Martin Pratt, Medudoc & Ash Narkar, Styra

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Securing Your Healthcare Data with OPA - Martin Pratt, Medudoc & Ash Narkar, Styra

In this talk, we will describe our “Shift Left” approach to security by using OPA to codify and enforce policies across our microservice architecture. We will focus on the design of our OPA driven application development process that allows us to define custom security policies using OPA and enforce them by injecting our apps with an Envoy sidecar resulting in policy-enabled apps that are now ready to provide least-privilege access to PHI and PII data of our users. In our demo we will show real-world examples of how we restrict access to sensitive data as well as how we control inbound and outbound traffic from our apps.

https://sched.co/ZemH

A

Hi my name's martin pratt and I'm here today with ash naka and we're here to talk to you about securing your healthcare data with opa.

A

So I'll start by giving a brief introduction to ourselves talk a little bit about healthcare and data and then around policy process and practice how they differ and why that's important then a little bit around open policy agent, where ash will give you a little bit of an intro to that and then we'll talk about some real world use cases of how you can apply this to secure your healthcare data and then.

B

A

Have some time for questions so to introduce ourselves hi, I'm martin, I'm currently the cto at mertudoc, and before this I was the director of platform at ada health, where I dealt with software development, life cycle processes, regulatory issues, uh infrastructure and security. I really care about designing socio-technical systems which help improve health care and and help people in general, and importantly, I believe in doing this in a way that protects people's data and privacy.

B

Hi, my name is ash narker. I am a software engineer at styra and I'm one of the maintainers of the open policy agent project. I care about developing secure systems that users can easily deploy and manage.

A

Thanks ash now we want to talk a little bit about healthcare and data and first, to start off with really talking about what is personal health information. And how does this really difficult? Personal health information, as defined by gdpr, is personal data related to the physical mental health of a natural person, including the provision of health care services, which reveal information about his or her health status.

A

Now, that's very legalese, but it's really important, because gdpr is a standard which all of us are I'm sure very well aware of, and it's something that will definitely impact you. If you work in healthcare now, phi data has to follow higher standards than personally identifiable information or regular personal data, and this is defined in gdpr, but also in the us under hipaa as well.

A

So there's many regulations that you you'll have to consider um when dealing with personal health information, um just to give a little bit an insight into some things that differentiates phi from pai. First, people must give explicit consent to the use of any phi data, which differs from pai, where you can have much more general consent, and this means how it's used exactly specifically what it is and also it must only be for the purpose of providing health care or for madness of national health. You cannot use it for other purposes such as monetization.

A

You can only use it for the specific use case that you've highlighted and that's related to healthcare or national health. Now, why does this matter? Well, there's a few things here that come into it. First and foremost. Obviously we, you know morally caring about people's health um by protecting against fraud, abuse and discrimination. These have impacts on mental health, um but also just on general healthcare. We need to really, if we're looking after people, we have to put this people first and foremost, like that's, really important.

A

um Second, if you have any issues with data, your partners will probably be concerned about it and you you could lose many partners overnight. So it's critical that you take this very seriously and really build it into the core of your business and really the cherry on top. Is you want to avoid enforcement from gdpr or the regulatory standards because they will come down on you and there's been lots of cases recently now to talk a little bit about policy and process and practice and how they differ, and why that matters to us.

A

So the key here is around policy and versus practice. Really, policy and processes are meaningless unless they're actually applied and work effectively in practice. Otherwise you have things that get around them. People will ignore them. People won't know they exist, and then you have issues that could could arise from that, and then this is often the case.

A

It's it's often that um the policies and processes aren't working as effectively in practice as they could, and this is because they sometimes suck um really starting with if they often start with infosec, who isn't necessarily talking with engineers some places they do. But I've seen it a lot where it's not and they won't sometimes talk to operations by the devops developer operations or technical operations, groups, or sometimes just general ops groups such as hr, and these teams will transfer this information between each other.

A

But some information gets lost in the chain so past the puzzle and really the practice. That's coming from engineers isn't being incorporated into how the policy and how the processes are created, and that can sometimes mean that they're not as effective as they could be so yeah. You sometimes get these gaps in knowledge between these two groups, because these groups aren't necessarily communicating in the same language or really talking in the same way or using the same tools. So it's understandable that these gaps happen and often they're very separate groups, bigger companies.

A

This is obviously even more the case than at a small startup of 10 or 20 people, and this is one of the key things that has I'm sure many people watching. This will be aware of that.

A

You know the creation of devops as a culture of practice and really as a culture rather than a as a profession that sits between operations and engineering, to really uh improve the collaboration of these two groups and really combine this into a unified culture that both of them are speaking, the same language using the same tools, and it makes much more effective processes, and this really helps improve the the collaboration between these groups.

A

However, often infosec and policy partially devsec, ops, but generally infosec policy generally, because it's more than just the technical side, I sometimes get left out of this or not included in these processes and so really making sure that the sec part is included in devops is really critical, and this can be done done by thinking about policy and bringing policy much closer into this process and having infosec engineering and operations really working together and using this communicating and sharing tools. Now. What is that? What sits in that middle between them?

A

Well, that is really this culture of practice between all three and like I said it requires tools, education, but most of all, it requires communication and like a way for these groups to talk with each other. So this is where open policy agent comes in, and I'll get ash to jump in and talk a little bit more about what open policy agent is and give some examples, and then we'll get into how it can help solve this problem.

B

What is the open policy agent oppa is an open source general purpose policy engine when you use oper, you are decoupling the policy enforcement from the policy decision making. So now your services can offload policy decisions to oppa by executing a query. So let's understand this in detail by looking at this figure.

B

Imagine you have a service, and this can be any service at all. It can be your own custom service, a kubernetes api server, kafka envoy, any service whenever your service gets a request, it's going to ask oppa for a policy decision by executing a query.

B

Oppa is then going to check or evaluate this query by using the policies and the data it has access to and send a decision back to your service where it gets enforced.

B

So you can see that we have decoupled the policy enforcement from the policy decision making the policy query itself can be any json value. So imagine if your service exposes an http api endpoint, your policy query could include the path, the method, the user and so on.

B

If your service is a kubernetes api server, your policy query could include the pod manifest, for example.

B

So as long as you give oppa some kind of structured data and you write policies which makes sense for that data, oppa will return a decision back to your service and that's why we say: oppa is a general purpose policy engine because it is not tied to any particular data format.

B

Once oppa returns a policy decision back to your service, it's up to your service to interpret it and then enforce it, and just like the query, the policy decision can be any json value. It can be a boolean, it can be a string, it can be a list object, any json value.

B

So this is the open policy agent, an open source, general purpose policy engine where the goal is to unify policy enforcement across the stack and it's to decouple the policy decision making from the policy enforcement.

A

So how does uh oprah help well? Oprah sits in the middle of these three areas, and this is really what we can the tool for communicating between these groups, so it enhances both communication and uh the as a tool for for actually implementing some of these processes and practices. Questions. Where can you put open? Where does oprah go? Where does it sit in the process and from this diagram you can kind of see that it sits everywhere. It could be, could everywhere it's everywhere.

A

You need to apply policy and where a policy could help improve processes and practices for your teams. So this could be. You know in your cloud layer when you're ingress to ensure that ingress policies are followed right down into your apis, and then your data protecting your data to make sure your practic, um your data is protected and everywhere in between part of your ci cd process, for example.

A

There's many many use cases for it. You know: data access management, service, access, control, ensuring that your infrastructure is code, policies are, and your infrastructure code is written correctly. Your terraform files are constructed correctly. Your helm, charts are constructed correctly and, like I said, admission and ingest control and filtering data as well. All these things are potential use cases for open. It's really really a general purpose, as ash ash has said.

A

So how does oprah help? Well? The key here is open decouples the policy decision making. So you know when a policy, what is the policy itself and how it's enforced within the system and provides a clear communication between the stakeholders? Infosec, who are the ones who are creating the policies or will be very heavily involved to the stakeholder in those policy, and your engineers are the ones who have to put that in place or ops teams as well, who put that in place and then enforce it.

A

So the teams that this applies to so it decouples those so allows both of those groups to have autonomy, um but also a tighter alignment. So this decoupling, as many types of you know, loose couplings, allows for greater autonomy and tighter alignment. Infosec can define the policy ops, can roll out and test. This policy inch can make sure they are following it, and the policy is easy. Applied so it really benefits all the stakeholders in this group.

A

It can also help in other ways and that it provides similar benefit benefits to infrastructure as code. um You know you can automate it, you can apply version control to it. It's got observability tools and you can audit it. So you can log all the decisions that are made and you can really audit it as well, which is which is great I'll touch a bit more on that later.

A

So now a bit more detail about where it can go so applying it vertically and I'll talk about applying it vertically and horizontally vertically means uh what layer in your stack between the front-end api around the token or around, between your api and your backend services, to make sure that that services is actually allowed access and protecting your databases as well, you know, is that request allowed is that person allowed access to that data.

A

Now dig a little bit more into the horizontal aspect and that's the idea of pushing your security left is a well-known concept in devsecops um and that the security aspect should really start during the design and development phase of a project rather than only enforcing it or applying it at the end and oprah is a communication tool which really allows you to push policy left and policy. Being part of you know a core part of your security practices and allows you to apply it during design and development, as well as deployment and in production.

A

So you know, during the design phase, you can review critical policies. Pre-Development uh make sure that you're working within the policy constraints during development. You can actually test against some of these policies and then during deployment you can run integration checks to make sure the policies are applied correctly, and you can actually test new policies, rolling out new policies and see what impact it would potentially have on it on your system and then, obviously you can enforce them in production as well.

A

So in general, the whole idea is yeah. Make processes suck less make these processes actually work? As part of um you know, this culture of practice shift your policy left for better dev experience, apply it at different places than the sdlc, so that it supports your engineers and your developers.

A

You know policy can be automated and integrated into your ci cd systems and as well as that, you can actually choose between. You know providing just guidance or more strict enforcement, enforcing different rules as required, and so you can use that potentially to do progressive rollouts, which is really great for your ops teams. You can roll out policies quickly, but do it progressively.

A

You can ensure that these policies are applied and you can provide better communication between all these stakeholders, because you have a communication interface with oprah and obviously it provides an order and decision log which your auditors will love, and your auditors will love all of this, because you can clearly show what decisions the decisions are being made and why they're being made and give them an audit trail of when they were made.

A

And now I'd like to share some real world use cases of how you can use opa to secure your healthcare data, and these are some that we've we've come across.

A

I'd like to start with uh talking about service access management, so controlling the service ingress to assure that the origin and request are valid and how you can use, for example, um role-based access control to do this, and to do it to avoid things like unintentional data leakage due to developer error, which, when you're dealing with complex systems, there's always a risk that you want to try and avoid- and this is not necessarily due to malicious intent.

A

Often it's just a mistake and how you can put policies in place that can really support engineers to to avoid these kind of issues.

A

And here we've got an example, oper policy, and this one specifically allows only patients and the doctors who are directly responsible for those patients being the only ones who can access this personal health information. This is a patient case, and here you can see from the sample input on the left we have. Dr susan is trying to access alan's information and uh we have the data there on in the middle, which shows that susan is in fact one of alan's doctors and, on the right hand, side.

A

You can see the two truthy statements which allow the top one allowing the patient to access their own information, but in this case it's the second one which enables the doctor, who is responsible for that patient or if they have a doctor listed as one of their doctors, that they that doctor will then be able to access that information.

A

Again. Like this information of the input information uh on the left hand, side doesn't have to be um directly written like this. It could come through in different forms. For example, the user could be coming from a a dot or something like that.

A

So here's an example of the the infrastructure or the architecture here, and here we have a cluster which has two services in it, potentially here from two different tenants, and we have a service which is sitting outside of this cluster external to this cluster, potentially completely external to the system. um We are checking for three things uh here. We want to check it's inside the cluster.

A

We want to check to make sure it's the correct tenant and also we want to make sure that the request is valid so that that last one is based on the regular we had before the other two were not included for simplicity's sake. So here you can see the request that we talked about previously. Dr susan sends a request from service a which is uh tenant a accessing information from tennant a's database, and it is her patient, as we saw before so yep. That's totally fine oppa will allow that through.

A

Then. We have a second request that comes through from service b, it's not from the correct tenant, but it's asking for something from 10 and a so that's a initial concern and we would also not allow it because it is not giving us the information of which user is coming from. So we don't know if it's from the patient requesting it or if it's the doctor so again, we'll say no. For that reason, and the third case is we actually have a request coming from completely externally.

A

This is directly to the service. It's not from inside the cluster and therefore we just say no and we wouldn't actually even get to the tenant or the valid request sections, because we would have already rejected it because it's outside the cluster, so that gives you some even even more security.

A

If you have highly sensitive data, which is the case here now, I want to talk a little bit about controlling or managing internal data access, so that is actually your engineers inside the company, how you control, who has access to what data- and this is actually really important.

A

This is a topic that came up um and that the auditors want to actually know about, and in this case we apply the principle of least privilege um to make sure that devs only have the access that they need, and sometimes this will mean adding and removing access to something at different point in time. However, devs obviously still need access to it, and so you can use oper to reduce the overhead through automating the application of role-based access control, so I'll give a little example of how we do this key thing here.

A

Is you have a whole bunch of stakeholders? You have the developer, who want to do their jobs, but also within policy constraints. You have it team who want to add delete users and update their info. So this is more on the hr op side.

A

Then you have your information security team who want to update and enforce policy and then, when an order comes in they're, going to want to order to make sure the policy was followed, and then you have the engineering management or operations team who want to ensure engineers have the roles that they need and update those, but also really make sure that the processes are actually followed, because that's something that they're, probably managing during audits as well.

A

So here we have. The developer wants to get a token to access the database and, for example, here we're using mongodb and we use atlas and the dev gets their token and then we'll make a request to the database, for example, to do a migration or or to look up retrieve some information about a particular patient, and they have this task they want to do.

A

We wanted to keep this as much in line with what they were doing as possible, so we want to be using the roles that we could exist within atlas, but we want to do this in an automated fashion.

A

So we have this user system roles that can be managed by the engineering management team and that sits and get engineering management team wants to update the role for a user for a developer so that they can access some personal health information, some phi information to for a specific user, and to do that they need to update the permissions. So uh here that requires potentially wanting to have a check to make sure that the particular developer is actually allowed access, for example, that they have had a background check done, because this is particularly secure information.

A

So we have this policy that is in place, which checks to make sure that they have a background check and we want to grab that information from a repo about that user, for example, octa which will be managed by the it or hr team that will update and keep that information about our internal team.

A

And so what we do is we have all that together, and all of this is automated, so that the system is updated and make sure that user information is is automatically updated and pushed to the oppa daemon and that any changes to policy as well as updates to roles will trigger some of this automation to make sure that these then propagated to atlas via the atlas api.

A

Now we have use case here like I was saying before, where a user wants to access some of this phi and we want to give them the permissions or the role and to to allow them to do that, and we then check to make sure that they have this background check completed. We check that in the the policy that was applied by the infosec team and yep, they have it so that's cool we within can update using the api's, the user permissions in atlas. We have another user, then, who also wants access to similar information.

A

The engineering management team try and make the update as well, but in this case the user hasn't actually had the background check done. So uh the policy says no opus says no and we'll return that information back to the engineering management team saying this is why we declined that and then that will be logged so that the info tech team later on can use that for an audit to say we didn't allow it for this reason, but, interestingly, there's actually something else.

A

We can do, for example, if they weren't allowed permission to production uh for that uh for the phi um data, but they were actually allowed uh it for potentially staging or some development uh environments. We can then modify the request to give them permissions for that, but not permissions for frauds prod. So we can actually do some data transformational request transformation to do that. So that's pretty that's a pretty cool use case and that's pretty helpful if you have potentially different um cascading permission. Sets that you you want to allow.

A

So thank you. That was our talk and I hope you enjoyed it and if you have any questions for myself about how to apply oprah to healthcare scenarios or you have questions for ash around how opal works or some more detail on on opa then feel free to ask thanks.