 How's it going? Okay, now that you have your headphones on, hello. Hi. Oh my goodness. Good morning, Jason. Can you hear me? Yep, good, good. So as folks are coming in, go ahead and add yourself to today's minutes. I'll drop the link in. The document is also in the calendar. Jason, since I see you're driving, I can take care of that one for you. Thanks, Sam. And of course I will be looking for two scribes. Raise your hand. Everyone jump on. Taking notes. Thank you, Sarah. Do we have Mark yet? Mark, Mark, Mark. Do we have another volunteer scribe? Christian, Jason, Ray. This is driving. So don't take notes, Jason. Hi, Jason. Ray, will you take notes? I think I'm supposed to talk with me. So I'm a good one to take notes. Christian? I could, but I cannot figure out how I could see and scribe at the same time. I can either see one or the other window. Oh, you can make it not full screen. So I usually like make it a little smaller. I do too. Okay, I ascribe. Great. So we'll both chime in. And then if I miss something, you'll catch it. Thank you, Christian. So Mark Underwood from NIST is our presenter today. So we definitely want to wait for that. So while we're waiting and everyone's logging in and getting set up, we've grown so much and we're, you know, heading towards the TOC in April. So, you know, why don't I go around the virtual room and, you know, just to have everyone introduce themselves. So, you know, the new folks know who's here and the new folks get the introductions. So I'll start off. I'm Dan Shaw, better known as D'Shaugh. I come from the Node.js community and, you know, was looking for a place inside the cloud native ecosystem to plug in and, you know, leaning on my background and security from my days working for the Department of Defense. Plugged into security policy with JJ and Sarah. So very happy to be here and facilitating this. So I'm going to go around my screen and try not to be too confusing. So Ray, you're the immediate next person on my screen. So can you get next? Sure. I'm Ray Cullin and I've been at Google for about 14 years and I've done various bits of enterprise pieces throughout my career here and lately, for the last four years I'm working on GCP Cloud trying to make it more accessible and easier to do policy management for large organizations and recently turned my attention towards Kubernetes and trying to do the same thing there. So generally concerned about the administrators and I have a place in my heart for them and want to make sure that we're doing things right by them. Awesome. Thanks Ray. JJ? Can you hear me? Yup. I said JJ. I worked in Enterprise. I started off my career in Enterprise and then worked on infrastructure since 2007-ish with Motorola. Then Motorola was part of Google then built cloud infrastructure and then since August I've been passionately involved with security as a primary thing and authorization specifically and then created a few initiatives and efforts around it and happy to help out in any way. Thanks. Excellent. Christian? Hi, I'm Christian. I work in Google's cloud security team. I've been working on the IEM team for the last two, three years I think and I'm now looking at Kubernetes and Istio for in particular a joint authorization policy but also talk a lot with Ray about policy in general. Go ahead. Sarah? Unmute. I am part of Google Firebase recently moved to GCP and working on infrastructure that supports both Firebase rules which is authorization policy and Google Cloud Functions which has its own needs in terms of serverless functions that trigger functions. Awesome. Jason? Hi, Jason Mello with Nearform previously spent the last four or five years or so over at ADP working on a lot of public cloud, cloud-native initiatives over there early with Docker, Kubernetes more recently as well as some involvement on the open tracing side of things. Great. Welcome, Jason. Good to have you on board. Prabath? I'm Prabath from WSO2 and my focus is mostly identity and access management and I've been with WSO2 for more than 10 years now. Madam? Sree? Sorry, I was on mute. I'm Sree Tomiti and I'm the Product Lead for Identity and Access Management for a few years to provide three products and open source as well. I've been lately looking into Kubernetes, IAM as well as STO and how we can leverage those models for further products. Great. Thank you, Doug. Doug Davis from IBM heading up the team in charge of working on all things cloud-native in the open source community with obviously a main focus these days on things like Kubernetes and STO. Great. I'm going to butcher this issue. Yes, I my name is Yisue. I work for Google in the Kubernetes JK teams. I'm looking to secure enforcement in general on a Kubernetes cluster. Excellent. Fantastic. Did I miss anybody? Maybe it. So the glaring person that I'm missing is Mark who is our presenter today. So I might need to pivot from that. Ray and Sree I know you're you've been beginning to work on the white paper. Maybe we could pivot to introduce everybody to that and check in to see how that's going. I think Ray has been actually. Ray, do you want to are you able to share some of that for us as we wait for work? Sure. I can talk about it. I think JJ and Sree are being very helpful in the amount of effort that they put into this. They've done quite a lot of work. I don't know why they keep nominating me. I think it's a competition over something. I think it's a group effort. I got to figure out how to present here. Let me get on a full screen here and present a window. I missed the meeting. Give an overview of what's the context for the white paper. Sorry if it's out of town. Okay. So the white paper begins to go in building on the use cases that we've been hearing and distilling down all of Sree, are we recording we are? So this is recorded for posterity and I will post that to the meeting doc that we all signed in on when we're done. Thank you. And now I've got all the issues worked out with getting zoom set up. Go ahead. What we did is we talked about where to start with this. We wanted to come up with a set of personas. We talked about the enterprise or administrator's Bill of Rights. It was an interesting discussion and then various people said, okay, well that's cool. What are the different personas and what are their needs? We wrote the administrator's Bill of Rights obviously from the administrator's point of view. But hey, there's developers and compliance folks and a bunch of other things. Sree and Gay Gay and myself, with personas into a document to kind of start. On my team currently, we kind of give these people names. So hopefully eventually maybe we'll name them. Oh, hey, Charlie. He does this. Hopefully we'll get to know these people and feel affection for them as we go through and create our solution. We can always bring up these people and ask them questions. So the goal is is to define what these people are, these personas, what they care about. And this really should be a group effort. Everybody here just ping me or ping Gay Gay for common access. We'll share it out and just start suggesting stuff and writing personas in here as you see them and we can iterate over time. So this is a living document. This is definitely the first kind of go-around and what we did, we probably missed some. So just let us know. So overall, we have created this concept of a developer and enterprise operator, a resource captain, a network operator, an end user, which I find interesting, an infrastructure operator or and then compliance, security admin and product system. I'm not sure what that is. I'll have to have that one's new to me. So at the end of the day, I want to go into each of these and talk about them. The other thing to consider here is what angle are we looking at this from. So JJ and I had an interesting comment thread. We said, hey, as a developer, developers are both consumers of resources and they're also creating resources. And so coming from my background, I always think of developers as consuming resources as Google cloud platform or web services like developers come in and they consume our stuff and they make new stuff. And so but JJ made a very good point to say developers also create resources within their creating programs, their creating new services, those services, those resources and they want to be able to attach and take advantage of these policy systems that exist. And I think this is where things like you know what Sarah works on and being able to attach like Firebase rules to things and whatnot can be really interesting from an app developer point of view. So I think we need to consider those. To me those sound like two different personas, like a developer acting in terms of consumer and a developer acting in terms of creating something. Both have different needs. And so that was our proposal. So I'll talk about developer as a consumer because I think it's a little bit more well defined. And in this case here a developer, we put a few things in here as a developer I need to provide blogs for any changes to critical resources such as being made available for auditing. So I think this is talking again and from that producer review I'm creating stuff and I think as a developer I need to be able to tag my resources so they can be grouped by the administrator when required. So again this is talking about for the producer point of view. I think that the generalize tagging infrastructure so administrators have one view of my resources. And lastly I think as a developer I can add policy checks to my resources. So how do we do that and how do we make that easy. So thinking about developers if I'm living in the ecosystem of the safe world how do I end up integrating with that and I think that's an interesting persona. I haven't written down the developer's consumer yet but we'll get there soon. So enterprise operators who are these people and we tend to think of them on my team we think of them as Olivia like they're the overall kind of like IT they're centralized teams that generally are watching over the entire universe they are generally trying to create a safe environment for all they want safe by default is generally where they're coming from and they want to set up a set of stuff where it says hey if you just come into the system you can do stuff you're able to be productive but you are also not but you're also restricted from doing things that would be dangerous to our company dangerous to our brand dangerous to our data and so operators their goal is to effectively have no people call them so if they can set up something way so they can basically put the exceptions in place and everybody is okay and then they don't call for things that are everyday mundane things then the enterprise operators right and they also need to view their system they need to be able to troubleshoot quickly and they need to be able to take action when when required so you know this is a key thing so an enterprise operator you know they need a central way to look at all their organization's resources and so they can administer them in a single view implicit in that is the idea that there is no shadow IT right so anything that gets created must be visible and you know people can't go over here and just spin up a Kubernetes cluster and administer it on their own and no one that knows it exists that's the kind of stuff that makes this an enterprise operator gives them a lot of pause right as an enterprise operator you need the ability to see what has what has changed about a resource when it changed and who changed it right so this gets into audit logging it's about making sure that we are reporting and have easy ways to understand the state of the system and how it got there and this is especially important during incidents right both outages and in security incidents a lot of times policy changes and big changes cause outages so knowing who and when may changes were made you can a lot of times use those to to recover from outages it's also good for incident response and certification PCI in particular is very clear about needing to know who has access to what right and prove it as an enterprise operator I need a way to delegate my policy control to lower level admins who can help me scale again enterprise operators at the top level are trying to get themselves never to be called so they want to be able to delegate stuff to lower level admins who have more knowledge about what's going on so you know we talked to Costco a while back and one of the things that they were always afraid of is look you know at the top level admins when someone calls us to change a bit we're so far removed from that bit we have no idea what it does and it gives us a lot of anxiety so by being able to delegate to people who actually understand what those bits do that is a very important feature to efficiency and to safety and then enterprise operator I need to a way to nominate per policy type operators both at the higher level and lower levels right so the enterprise operator is kind of the root operator you can think of them as root in your company they lots of times take on many hats right sometimes of the quota people sometimes of the access control people sometimes of the network admins but in a big org that's too much for one person to do so they need a way to say hey Dan is the network operator in this company and he has the network operator privilege at the root level and hey Shree is the quota resource captain and she is able to determine spend and quotas for the company and so it's both a horizontal scaling but it's also a vertical scaling in terms of like okay Dan is the network operator for the YouTube division or something of that sort cool by the way stop me anytime if anything is controversial hey Ray may I ask one question when talking about the operators in a big enterprise they are belong to the same org but sometimes they have multiple departments and inside of one department it's possible they will have another small operation team represent the department so is there any distinguish between basically I'm asking if there is another division between the operators from different departments yeah that's a good question Shree this particular bullet here I need a way to delegate policy to the lower level admins who help me scale so the idea here is is you'll have a departmental operator and that operator can be given full control over their compartment and this is something we talked about in the administrator's bill of rights the fact that you as an admin can compartmentalize your resources and then you can act autonomously right so it means that the enterprise can give full rights away to you as a lower level operator and in a department and they can say you have the power to make exceptions and you have the power to be able to do this or you don't right depending on the corporate policy does that help thank you so could we express that as lower level admins including other enterprise operators yeah we can say including you know right so you mentioned here you know shadow IT you know is is it relevant to our use cases to you know to have any sort of exploration of resources in or out so you know the assumption that there are no shadow resources ever is a fallacy right there's probably going to be something somewhere created by some team or acquisition where things are going to get incorporated in is that relevant to we need to have visibility into the resources to apply policy to it yeah so the way I think about that is that the enterprise operator you know draws a rectangle and says this is the universe right and the universe might be a you know just to get down to brass tax a set of networks a set of DNS domains right you know a set of you know kind of cloud provider set up to use those networks right and share it out and I think within that rectangle we do not want people to be able to create things and hide them right now what you described like acquiring a company who has another whole deployment somewhere else they're outside the rectangle right and so therefore if they have their own DNS names they have their own networks and things like that you know they you know eventually will want to become part of the rectangle but they can be protected through the you know the base the base components of security right firewalls and DNS and things of those sort like you know for example someone in shout out he can never expose something let's say on google.com right they just can't right and the only way to expose something on google.com is to be within the rectangle those are the types of ways that I think was that help yep that's clarifying thank you okay cool okay so we can we can move on now I think you know the concept here is is when we get into the enterprise operator and we started talking about like per policy type operators right we can start thinking of who these like per policy type operators are and so one of them is the resource captain right and and the reason why I particularly like this one is because I think it's pretty easy in in authorization to really concentrate on access control lists right and and and also like you know filtering on labels and things like that but another form of authorization and policy is quota policy right it's about are you authorized to be able to you know create another VM are you authorized to be able to create more users right these things are controlled by quota policy right and so a resource captain is the is the person who is delegated to to manage that for an organization and similar to all of the things that enterprise operator has the ability to you know see stuff and delegate and and set policy resource captains need the same thing for their their purview which is which is quota so we can you know we can talk about that but I think you know as a resource captain I need to constrain how many resources a set of teams is able to use I need to be able to delegate resource quota management to sub captains right you know as a as a resource captain we can be alerted if resource quota allocation exceeds a certain amount right people go out of spec and and again I think you know it's interesting putting these things into the equation helps us think a little bit bigger than just than we can get trapped in is there anything else besides quota that the resource captain has to worry about should we call him quota operator to to stay with you know nomenclature that we can we could do that I didn't know I asked that question right you know what does it mean to be a resource captain yeah yeah actually I want to ask the same question actually I'm thinking about something more than the resource quota and the access control especially in Kubernetes there's another kinds of how to call it I'd like to call it like a resource privilege like you can create a port with a certain privilege or capability some capability of provision will be harmful to the system like the container kind of stuff I'm not sure if this falls into this category so I don't see them as a quota operator what I just heard described there is more of like a constraint right so if you think about this this is popular on windows right like you can do you can say things like windows users are not allowed to for example change their IP right and you know on these machines and they're like straight policies that even though you're an administrator the domain has prevented you through domain policy from doing certain things on your windows right and what I think you just described is the idea that a cluster admin right can say something like hey you know you as a namespace pod creator you can create pods but these pods have to have the following characteristics is that true? actually what I'm saying is this falls to a different category this is more of like constraint policies or things of that sort I don't know what the generic category if anyone here who has a lot of policy experience knows what those things are called I'd love to know we call them in GCP authorization policies you know I think windows has its own domain policies and things like that so that's a very important use case and it's actually one that I think Firebase rules is really good at I think what they do is they look at every incoming request and they can validate the map of the object and then it says hey if this thing's in this object then kick it out and that's on top of authorization like access check so it's like yep Eswe has the ability to create pods but if the pod spec doesn't look like this we're going to kick it out right? sound good and I think the question we have to ask ourselves is is that a separate policy type with a separate policy type operator right or is it part of the access control system and those who create ACLs are the ones who create these types of constraints and I think that that's a raging debate right? I think in Kubernetes that's what the admission controllers do right so whoever sets up the admission controller would be responsible for that you'd have to create a custom admission controller right? yeah but that thing could you could have an extend to RBAC and read RBAC policies with conditions right? yes so something that as we're preparing this that may be useful I'm reticent to create new nomenclature right? what we're doing is capturing context so if we have these implementation you know separate implementation in Kubernetes or whatever if we can footnote these sections with in Kubernetes this is called this and done how then I think we'll be setting ourselves for success as we navigate the name bashing that will invariably take place I wanted to interrupt for a second I think that's a great idea Dan Mark Underwood is here and we're at the half hour mark and maybe we can switch gears and pick this up but this was a great introduction to the white paper just wanted to chime in with that if you want to go back to the originally scheduled presentation thank you Sarah and Mark let's have an open discussion around that you know you have one of your peers that couldn't make it today so we could actually take this either way we can give you the floor and have the presentation now or we can reschedule that and continue raising the group what do you think Mark? sorry too many conferences I've been in today and I'm switching platforms for the fourth time I'm ready to go with this and I can live in this constraint I'm framed constraint so I have a deck if you want to let me share great so you can find the screen sharing I think it's the big green thing the bottom of your screen in zoom so let's go ahead and switch over to that why don't Ray why don't you drop a link to the use case doc into chat and into the minutes and we'll pick that up next week and continue that that's looking really good alright so Mark we went through everybody introducing themselves at the beginning of the session before you get started into the details be nice to introduce yourself and share a little bit about yourself sure so I'm I work in controls and countermeasures and synchrony synchrony is a sort of a spin off of GE's retail finance group it's a big company I think we're Fortune 140 or so prior to that I've been working in health informatics and I'm pretty involved in these in the ontology space mostly on a volunteer basis I co-chaired the 2015 conference on ontologies for IOT I have a book chapter out and on security for IOT so that's kind of my interest in it this big data group that I'm going to give you the an overview of today started working in 2015 I'm one of about 15 or 20 so it's really a pretty small group not much bigger than the one that we're in now that's been working on big data and basically just trying to give this team some ideas of the things we worried about in that group and what's a little different from some of the other standards group this is not a standard it's just a special report so it's not telling people I do things it's more like a background on this I forgot to mention one other thing so I'm also really engaged with IEEE working groups for DevOps security that's 2675 and a suite if you want to call that of the 7000 series which is trying to deal with ethical issues so there's some overlap with security and privacy issues and providence for traceability of responsibility for if you look at this facebook issue that's out that people are looking at as a security issue it really is a more of a traceability and providence and trust federation kind of issue which is really I wish people were calling it a big data problem instead of a security problem but that's okay you don't own the public discourse on this so you able to get this screen I guess I think I'm so part of the screen is that me or everybody I can make it smaller oh no that was me okay right so the homepage has the URL for this work and all the documents that are in draft are available directly with Dalmo don't have to sign in for anything that's one thing about NIST we're paying for that with our taxpayers not through the contributions of members like some other public working groups so that's one of the advantages so the second draft it's a multi volume enterprise I forget how long it is but it's pretty long I'm really just talking in this venue about the security and privacy work and I'm going to give you a taste at the end of this let me just see where we are in time that's after five after the hour I'll try to stop by a quarter after and show you a few pages out of the document that I think are relevant sounds good so the special report that's in draft has already gone through public comment we didn't actually get a whole lot which is unfortunate but it's now going through review at NIST they've got some things they want us to make changes to but I expect it'll be released for the public in early summer at the latest if not sooner so the strengths of what we've done in volume four anyway of this is that we've been at it for a while so we've gone through a few cycles like where nitties didn't even exist at the beginning of this in 2013 I mean it existed probably internally somewhere but it wasn't in the common discourse very much then at least not in our working group so it's been around seen a few product cycles and that's been good we also have seen the emergence of IOT during that time that really wasn't part of the discourse so much then that's a good thing for reasons I think I'll become clear later here we tried to make it lightweight not too regimented it doesn't say you have to go to cloud to do everything even though there's a realistic aspect of this that if you're a relatively small organization you probably are going to do all this in the cloud anyway and there is a uniform reference model even though it's a very lightweight it deals with I'll show you a picture of that later on so that's a benefit mainly because some of the draft writers don't use the same language across all the documents so it gets hard to know in the security document what's being referred to in the architecture side well interesting the weaknesses of the documents are kind of all the same things because it's mature it doesn't have the latest stuff the vendor neutrality often hides some of the use cases that are the really interesting ones Kubernetes is sort of an example of that but you know MISOs the other orchestration challenges that are product specific are really good ones to wrestle with being lightweight can be a problem it's not because it's not a standard it's not going to change people's behavior and how they build things and a lot of the less technical people involved in this working group because it wasn't just technology people they were very concerned about the sort of thing that happened with Facebook this week last week and the public disclosure but of course what happened in 2016 with that and in fact they talked about it so much we got sick of hearing about it from them we thought we'd addressed it but I think we never fully satisfied the relatively lay public's concerns about protections put around public data in the for the folks whose business models are built around consent driven use of data models pretty simplistic you know I think this group will probably find it dismissive or dismissible but that's okay at least we know it is so we think there's some things that are different about big data most maybe the key thing is that multiple security schemes have to be addressed you're looking at attack vectors that vary depending on whose organization it is countermeasures are not going to be the same for small companies compared to big companies the people that originate the data or collate it may not be the same institution that is going to deploy it there's a sensibility about how to deal with sensors that people who haven't worked in real-time systems are not aware of real-time stuff it's not new in computing but it's new for a whole generation or two of folks who who basically cut their teeth on transaction driven kind of computing relatively static database work transaction-driven databases and that's big data forces you to deal with spark and that sort of thing so that's important the unintended uses and de-anonymization is a key thing that just because you don't have a social security number in a row doesn't mean that people can't figure out who you're talking about in your data and so the architecture from privacy and security point if you need to deal with de-anonymization that occurs outside of your own organization downstream when the data is consumed there are lots of problems with scale and complexity cloud magnifies this obviously you get that with the traceability the veracity the kind of content that you're going to have to manage you know we used to call it bulk in the early days of databases now bulk stuff is you know the main thing that's moving on our networks I think somebody told me that YouTube was if not the most one of the biggest consumers on our internal networks which I find surprising because I don't I'm not on it all the time so I don't know who has time to look at it yes there is training stuff on there that's worth having of course and then there's jurisdiction issues that data is shared across continents and that's common now uncommon and so you have you have multiple jurisdictions that are responsible for the data so if you're going to share both data and code in your networks across organizations and countries big data presents you with problems you probably didn't anticipate in systems built earlier another thing that's kind of interesting is that big data power is now wielded by smaller organizations really small as one person can you know take that 50 million record data set that was floating around from Facebook and do a lot of things with it that doesn't mean they have no governance but they tend to be people with weak governance and weak training and tend to be unregulated in unregulated settings anyway so the fluffy part of talking about security for for big data is that it's affected by all these dimensions volume velocity variety veracity and volatility and of course cloud so I think people on this call you know based on my listening to this call you don't need to be told why this matters but it might be interesting to see if you think through each one of these in the frameworks that you're currently using to manage them you can see what the challenges are that you that you face and then just multiply that across organizations what's left less fluffy about what is the merge that we tried to worry about is the big data aspect of what is going to have to change in the software development life cycle so agile as part of this the API first architecture is part of this so if you haven't heard that lingo that's the build to a specification first before you write any code because if you need a geolocation service you probably are going to need to understand how to get data from Google or Microsoft or some other or from a government service that's publishing that micro services and containers are going to be important I sort of see these as children of the components and composable services movement but this is still important it it matters because that's this is going to be a new way that we need to manage security software defined networks and 5G are going to become important because mobile networks are providing this geolocation service that is one of the principal drivers for de-anonymization of data sets left shift is important because this becomes part of SecOps so the orchestration of you want to call that a play books to run the tools that you have in the stack in the security group becomes part of what needs to be coded and we're going to push that responsibility closer to the developers than it was before so people have coined this as SecDevOps or DevSecOps but it's all kind of not the fluffy part of this work to figure out how that needs to work and how what kinds of frameworks need to be adopted to allow that so chrisdm is kind of an interesting use case of a new model driven kind of thing in the health space that produced a lot of unanticipated data sharing and analytical challenges across multiple industries and it probably is the you know it's one of those tip of the iceberg kind of things but now chrisdm has been around for a while it's a portable model building thing if you haven't run into that so I think I already mentioned IOT but if you've been around a while this is distributed computing at large with just more fatter pipes and more sensors and richer sensors so the key trends we tried to worry about in the draft were cloud obviously IOT especially is related to health and safety the mobility and pervasive computing so that's you know metrics that are coming off individual people including you know the new voice driven kinds of things but also the geolocation stuff that goes with most of these things the data center automation that's happening we're basically you know as we're rethinking how we do our stack and rack kind of processes and the way that we build out protected sub networks inside the data center is now moving into software increasingly so that's pushing the automation process further down under the stack with routers and that kind of thing more than it used to be trust in federation we try to tackle that a little bit and maybe one of the key things that that I really pushed in this design was more automation on domain specific processes either through domain specific languages or explicit domain models and then the last trend is moving more toward attribute-based access models more than role-based and the reason for that is not the role-based it's gone but that you really can't effectively instrument access controls against only a purely role-based thing if you have domain-based models that are using an attribute-based model so this gets a little involved but basically if you want to consume an ontology and do that with an ABAC kind of system you're better off using attributes than roles I mean the roles can be derived from attributes so it's a longer NIST paper on this that we relied on for this Hey Mark Can I ask one question regarding the ABAC rather than the RBAC can I interpret that as RBAC plus ABAC and moving to ABAC and more so we still need ABAC right? Well that's it's like saying can you build something without admin so I have a standard rant I get into on this but you know it seems like coders the first thing they want to do is is build an admin it's like deciding to build a bridge with that has a guaranteed single point of failure in it and it's really one of the problems that we face with this that that the architecture of the things we build have role based things built into them that don't need to be there and so yeah they're unavoidable you can't you can't have that if you've got an architecture with an admin role in it you now have got to deal with it but I would argue you don't have to have that how you do that you know depends on the domain aspect of that but yeah you can't do one without the other we have a legacy of role based of controls that are not just in our hardware systems and our operating systems but in the security frameworks built around them it's just unavoidable so and I have just a question I'm not familiar with your vocabulary like what does it mean to consume an ontology yeah I knew I wouldn't get away with that so an ontology is a model and how you get from an ontology to a model you know varies a lot so there's an oasis group that's trying to develop a standard for doing that so an example of that might be if you have an ontology that allows you to make an inference about logs coming out of Splunk that represent a certain kind of attack it could be that the log information will tell you that but the ontology tells you which logs to examine which features you know which of the fields in the logs are the ones that you need to look at because now what's happening with products like Splunk is you have not just tons of logs by volume but variety so you have many different kinds of logs that need to be looked at in tandem in order to make inferences so the ontology drives the inferences but it needs to be ingested by tools like Splunk and other tools around that in order to know what to look at so that's one use case of that but there are other ones so I know I got away with saying that by talking fast here but that's of course not widely deployed right so I guess I'm trying to connect the dots between that use case which it totally makes sense to me and I would have guessed that that's what you were talking about how does that relate to A-back I can guess but I'd be interested in your exactly what so most of the strategies for getting data out of you know RDF or one of the other ontology systems you know out of Al are to treat the nodes on these graph models as attributes so that's how you get it into the attribute model but for access control yep okay so they're just storing okay I think this is a longer conversation I'll leave your white paper well it is longer conversation so yeah maybe it's more important how we got here for this short conversation and you know if there's interest more interest you know you this team might be able to drive some real solutions that are still floating around in the ether and limited to academic spaces you know more than than the practitioner space that we really would rather be in great let's keep going and then we'll circle back hopefully good good though I I mean that's an important topic so if we have time down the road that's really worthwhile so influences that drove what we did here the obviously the NIST 8053 because of its prevalence not so much the content but the prevalence of its adoption the the building automated there's a smart building ISO standard that uses ontologies as the base for it so these are and these are public because this particular ISO standard was designed to be public unlike a lot of the ISO work so if you go to this URL you'll get a sort of background on that what's interesting to me about this is how you take that obviously and try to do security with it I mentioned these other these other ISO standards that are driving some of this work in 2675 this is an emerging standard we're still I think in 18 months into working on this standard but it's it's already got a lot of content that's that might be of interest to this group I see microsegmentation and NFV is one of the the main drivers for adding protections you know we we've all we're all dealing with you know the notion of zones that goes back probably 15 years right but the idea that that application developers can control the zones and the microsegmentations in which their containers operate is a relatively new thing it's probably being done in places that we just don't know about it yet and the other influence of course is infrastructure as code so I think I covered that already so the use cases that are in the draft cover so we're doing our time here I'm overtime so I'm going to go faster so you'll find these use cases one of the key use cases for big data is network protection so if you're if you're having to rent disk space from Splunk you already know about this so what we one of the contributions I think of this report is we give them some we give the users checklist there's a pretty long bibliography that they can go to that is drawn from you know both academic sources and some industry sources we did a deep dive on HL7 which is in healthcare standard about how they manage consent I'll give you an idea about that consent problem you know the Facebook one is one that's being talked about today but a bigger problem is you know how do you give consent for somebody to make decisions about when to pull the cord on you in a hospital setting what do you do if your your ex-wife you know still has that consent because you never got around to repealing it what do you do about information about people that are handicapped in a building that's bring down do you break the rules about sharing confidential information and if it's going to be needed to save their lives so HL7 has kind of worked through a lot of those use cases and we kind of took that into the big data space to to let's say to flesh out our detailed use cases we came to the conclusion you can't do big data security without simulation that if you want to scale things up you can't you're not going to be given big data spaces to operate so if you're going to do risk management and availability piece of CIA that you are going to have to do simulation so that's another reason to have a model driven kind of approach to this and what we did was you know try to go after the safety frameworks like the material data safety standards if anyone here has worked through that we treat the data elements associated with PII and PCI on the way that people would with material data safety records lastly we have this notion of a system communicator which is a sort of standard software artifact that needs to be produced in a big data system to allow it to communicate to the various consumers so if you want to know when to do you provide consent for us to use your data for this it remembers the whole session associated with you doing that and it has a natural language sort of interface on a public website to do that so I'm going to skip these diagrams in the interest of time we can come back to this what I want to show you is the what we did with the safety conformance level so these conformance levels are people who choose to do so can look at this document and say we're attempting you know based on a self-assessment to follow a safety level of one two or three according to this NIST big data security standard so at the highest level which is what I think this group might want to be interested in is that it looks at automated use of these domain models for security operations and for the SDLC it pushes security and privacy risk to the developer environment directly and likewise to configuration management and there's a continuous test environment that moves to security not just for code scans but for things like whether firewall ports get open and closed and whether containers are spun up and shut down when they're supposed to be and also pushes the test case offering more to the application side so those are kind of principles from DevOps and left shift but they are pushed into the safety standard so that's a way a word file if I can get to it so yeah actually I'll just look for the appendix I was thinking about it now it's not going to let me jump to it I don't know what we can do with page numbers I had this up earlier oh why don't we go to questions oh here it is alright I was about to give up the screen hasn't refreshed it okay does this oh I know why here it is now can you see it yep yep alright great thanks right so what we this is basically the safety level so this this might be of interest so we you know try to identify you know what we think are the key points to improve safety and and believe me this was a tough sell even within our small group because when we tried to analogize the fact that the safety process in aviation is one that involves a lot of non-technical and trust related work that's sort of non-computational that seemed like unfamiliar territory but that kind of is the gist of this that while there are you know computationally perfectable solutions to certain parts of the problems like you know closing a firewall port or patching say a struts module there are other parts of this that have to do with less less easily protected elements that is why aviation is safe because the whole supply chain is involved in the process of making it safety making things safe so you know the risk management and safety approach to this is is a bit novel in the security space even though really it's kind of an obvious thing so the facets of this would be you know human touch points, APIs, what the application models look like authority to collect data whether you've got a communicator for the fabric whether you have forensics playbooks the business continuity capacity management for security operations how you manage consent and traceability for consent continuous delivery for security and privacy components where you maintain and export your dependency and federation models disaster planning and information sharing interoperability for the domain model so I'm not just going to read all these so these are obviously not exclusive they're the attempt is just to pick some of the key elements that we think will contribute to safety so I'll stop here and take questions this I know we're covering a lot of ground here but this document you know you can download it and we can talk about it in another meeting if it's of interest to this group this is great it would be great to add a link to the notes and this question already got it sure I'll do that too here we go no I think Christian got it already so yeah I'm equating you know Spree's comments in the chat here would be fantastic to make sure that we capture in the minutes a link to this presentation and the docs assuming they're somewhere public on the internet or can be made so if not I can you know find a place to host it if it's not make to order jobs so I'll I'll put a link to it in the Google Doc fantastic we're at time so I respect everyone's time but if anyone wants to stay a minute or so over open up the questions for Mark anyone has to leave thank you for coming apologies for not using the time right so my question Mark you mentioned that your here at NIST had additional context that was relevant to this group shall I allocate time yeah I'd love to he was a little fuzzy about what his commitment was in April he was trying to ask for time in April without naming the date so I need to nail him down but he's a he's a cryptology PhD and so he's on top of the blockchain stuff and some other things that might be of interest and you know the cryptology stuff enters into a lot of this federation and trust issues in kind of insidious ways and people have some unrealistic expectations about that and so there's that topic and also the you know the compute the problem of computing on encrypted data is worth catching up with so that's it's still a bit in the in the future planning but he's current on the work in that so I think yeah I think it would be great to have him here great well we are barreling towards a presentation at the cloud name of computing foundation TOC text to the technical oversight committee break down my acronyms on the 17th of April so I believe we'll probably need to focus in the coming weeks on preparation for that right making sure that that you know everyone's aligned all the ducks in a row and we're ready to you know put our case in front of the TOC and get approval so we can begin operating officially as a CNCF working group so let's set that aside for now and come back and potentially have that as a discussion for some date later than the 17th of April which I believe is a Tuesday and that probably means that the earliest date we could consider would be not that Friday because I'd like to debrief with everybody the 27th would be the earliest okay sure alright well thank you Mark and thank you Ray for sharing excited about the the white paper document that's getting rolling over the course of this next week team members here can have a look at that and I'd really love to get some of those footnotes put in about this being that you know called this and that and Kubernetes and what not I think that'll go a long way to helping support that thanks everybody talk to you next week thanks everyone