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.
^ (trusted relationship)
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?
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?
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
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.