Could Native Secure Access

Cloud Native Secure Access

Tuesday 3F Convener: Sarah A., Rachel M. Notes-taker(s): Rachel M.

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

What can we do to make sure developers can deploy to the cloud confidently? What are the requirements for tools for auditing policy in hybrid-cloud systems? Open Policy Agent (OPA) is an open source policy language still in development. We should all get involved, start hacking with it, and make sure it meets our needs.

Sarah A: The world is more complicated. When I started, security was all about the network boundary

Alan: Is this about Enterprise or individual developers?

Sarah A: The individual’s problem is not the hard problem, but all the hard problems happen in the Enterprise

Alan: I think managing Enterprise developers in the cloud has hidden something important. So the enterprise case is easier.

Cloud Provider

^ ^

Enterprise Individual

^ (trusted relationship)

Employee

This simplifies the Cloud Provider's job.

Paul: Thinking of proposing a ledger that contains personal information.

The table would be held by cloud providers, but I don't want it to be owned by anyone

What kind of relationship would I have to cloud providers?

Alan: ?

Sarah: How is this GDPR Compliant?

Paul: There is sensitive and non-sensitive data, and the sensitive data is stripped out

Most people would probably be okay with posting sensitive data if it can't be traced back

to a human. I'm also finding that any text field is sensitive data.

Ray: What is the GDPR's definition of sensitive data?

Paul: There is a definition but it's not as strong or as clear as it could be

Alan: How does this relate to the policies?

Paul: This doesn't have an owner. Sensitive information is

Sarah A and Rachel: The thing that we're building is that everyone who puts things

on the cloud should be confident and understand what they're building and who has access to it

Alan: There are two different cases, what the developer standing up a cloud service is allowed to do

and what the users of those cloud services can do

Denis: Should we be worried about irresponsible developers

Micah: Do we need to think about multi-tenancies and isolation?

Shantau: We must have thought of what the needs of fin tech, etc, and built tools

for what compliance, and then the tools thats

Micah: And building tools that guide the developer, for example, to get a certificate, be HIPPA compliant

Chris: Having a WYSIWYG editor for API, and then applying UMA2 on top of that

Alan: So you're envisioning a standard

Sarah: We're thinking of OPA, so there's a common way of expressing policy. We

created a policy language, and someone said "a policy language won't make you secure?"

Alan: You can't be security without expressing policy.

Sarah A: What else do we need?

Mark: You need a risk assessment. SOX, HIPPA, and PCI all now include a risk assessment.

Davide: You could build components. Edugain lets you say they're compliant with a CoC, and that requires an audit.

Micah: That's something cloud providers could do, so it's not up to individual

developers to know what they need to have when it's time to go through a security audit.

Sarah A: One company has 10ks of apps

Alan: All we need to be able to prove is that we enforce any policy that is expressed in the policy

And then we're decoupled from all the services offered on Google Cloud

Paul: I'd like a way of knowing what fields are considered personal, sensitive information that should never go out

Alan: That could be something you use as the developer.

Denis: GDPR requires expressing HOW you enforce policy

Alan: You can look at what each Cloud provider says

Chris: You could write a testing tool. Are there encrypted at rest requirements in GDPR?

Everyone: Yes.

Alan: If I say this is personal information, and this is the policy around it,

then the auditors only have to audit the policy, and how Google enforces the policy

Micah: GDPR is a a good case, where the app developers will be able to do all the best practices by default

Paul: <

Alan: I think the hard part is to make the policy language that all the cloud providers agree on.

Sarah A: Are people bought in to the idea of a policy language?

Seidev: I've used Amazon policy, and it was a good concept. It could be extended to many providers.

Alan: And we have the flexibility that policy could be expressed in many ways

Sarah A: Some things are not documented and are hard to discover, when is it

effective? And that's not part of the policy language. So what else

Micah: Is it centered around access?

Sarah A: Borrows from Xacmul, which has the concept of deligation.

Micah: Janrain is building policy language in Xacmul. Customers hate it, so they go back to XML.

Alan: It was so expressive, and we built a few checkboxes that generated the XML that no one would ever see.

Sarah: Can we express the policy across multiple providers, and in cases where it's more complicated.

Alan: I looked into limiting what parts of the database by making queries for things you're not allowed to make

Denis: You can do an interference attack

Alan: Instead we gave them a view of the database that only had what they needed. (We found out later?)

Sarah S: Why are you trying to do this? Making a infographic of the database?

Sarah A: Say I have a front end, back end, lots of services in different infrastructure. How do we reason about it and

understand the high level review. There's the problem of knowing what is correct, and there's the problem of implementing

what you've decided.

Denis: You'll want in some case to want to start checking the token, and additionally the region

Alan: As long as you allow delegation.