 So if you've heard about, um, something called the safe working group, and, um, co-ordinated in CNTF, um, this is basically the same group with 1,200 redundant rename, and now it also should be a 6, which is great. Um, so yeah, in this session, I'm going to talk a little bit more about, uh, what exactly we are, what we are trying to do, as well as ways that we are involved in, um, yeah. Um, so what exactly is 6 security? So CNTF 6 security is a group, uh, and our main vision really is to, part of it is to increase the posture of security across cloud native in general. Um, and another thing that we are hoping to be able to do is to be able to make it, um, so that whenever a developer and user, an operator or an auditor talks about creating a cloud native application solution, they should be comfortable with knowing what exactly is the security risk, what are steps that I can take to mitigate, um, um, certain risks within my security solution. Um, so we do this in three areas. One is to be able to observe the entire CNTF landscape and look at areas where we need to have better security or have a bit more focus on. Okay, all right. Okay, um, the second thing that we're doing is we want to be able to have a common understanding of two. So what we do, part of what we do are assessments, basically what we have is we look at certain security-focused projects in CNTF, we do a review of them, and then we give a little bit about, you know, here's the track model that you should be looking at when you're looking at using this product or using this, um, project. So these are things you should consider, these are things, um, if you are, if you need, if you're using this, these are things that you get from me and these are things that you don't get from me. I'll go into more detail later. Um, and the third focus area for this group is also around kind of audit and compliance. And, uh, we often get this issue where auditors come to us and we say that, okay. Hello, this is Ben. Okay. So, um, the third point which is around, um, audit, right? So, um, there are several, um, customers that come to us and, or just, um, vendors in general, and they say that auditors that look at cloud-native, um, solutions and architecture don't really know how to assess the security of it. And this is something that is fairly new and, you know, auditors still have some trouble in, you know, understanding how risk has changed when you introduce something like a, um, CICD process where containers was the isolation in that regard. Um, so these are the kind of the focus areas of the group. Uh, a little bit of history. So, this, um, the Safe Working Group started in December 2017 from, um, casual conversation between a couple folks. Um, and we started the initial Safe Working Group, which is now called SIC Security. And we started with this idea of, okay, we're going to identify all the different personas and use cases in cloud-native in terms of security. All right, um, so we, we continue on this. We merge with the Policy Working Group, um, which there's going to be a talk later that I mentioned. Um, so this is, they're looking at kind of what should cloud-native policies be, what are the policies which, you know, has security considerations, how does Spiffy, how does OPA, how do these projects get integrated with it. Um, and later down the road, um, around last year in August 2018, we created a PR for CNCF considerations. And thanks to our chairs and, um, the, our sponsors at the TOC, we were able to, um, get the SIC status in June of this year. So we are a fatty new SIC, but we, um, have quite a good amount of participation. So right now we have 45 members. Um, it's kind of a diverse set of members. We have people from, um, cloud vendors. We have, um, security providers. We have end users, financial users and so on. So a lot of representation. There's a lot of good security discussion that goes along. Um, and it really is a very open community. Basically we do everything from GitHub. So I'm going to talk about, um, two or three focus areas that, um, we've been, um, putting work into over the past, um, past year. So one of it is landscape. So some of you may be familiar with the CNCF landscape. So this, if you've seen this like big picture with a ton of different logos on the same page, uh, basically classifying, okay, what is this cognitive, um, um, technology, where should it be? Um, is it orchestration? Is it runtime, whatever? All right. So with SIC security, we want to do a similar thing for security, right? So we want to be able to, um, have a bit more of a fine grain control of, of classification of what, uh, security project is, right? Is it something to do with identity? Is it something to do with privacy? And once we are able to classify all the projects into different areas, you can kind of see the gaps and see, oh, this is where more projects should be. Or this is somewhere that, you know, we should put more interest in. Um, another thing which sets us apart from the general CNCF landscape that we're trying to push for is that, uh, when the CNCF landscape, the scope of it really is targeted at the CNCF project themselves. But with security, this is a little bit different because a lot of the security projects that I use in, um, production or in solutions, um, actually, you know, go our generic security solutions. So like key management systems like fault, um, you know, anything in the C groups, name spaces and the nuts kernel, you know, those are all generic security projects, but they're not necessarily cloud native, but they are still important in the ecosystem for security. So we, we have kind of a draft of all these things. They're moving forward. Um, um, if you are interested in helping with anything, um, the issues I've put all on the slide. So if you want to just click into it, you can kind of see, um, what the details that we, we've already drawn up now. And also if you want to contribute, we are definitely very open to that. Okay. So, um, the second thing I want to talk a little bit about is security assessments. Security assessments is something that I'm more involved with. And the idea here is that we're looking at some of, um, for, for stylists, we're looking at some of the security focused projects. So the idea here is, um, three things. One is we're going to look at cognitive security, um, projects or projects in general and make sure they have good security posture. So this, we ensure that, you know, do you have a proper CI, do you do scanning of your images and so on? Um, on top of that, we ensure that all the projects have a, um, security process. So for example, do they have a process for, if there's a vulnerability discovered in a project, is there a security team and what is their response time like? Um, so on top of that, what we do, which I'll show you a bit more details later, is that we really understand what are the threat models and how they, they, um, form a part of the architecture. So we started with two this year and they're almost complete. So the first is in total. In total is a, um, kind of, um, signature verification mechanism, which validates, um, certain processes within the container supply chain, right? To ensure that you have scanning, you have, um, you're signing done, maybe you have encryption, certain compliance steps that you want to perform. Uh, OPA, which is, um, open policy agent, some of you may be familiar, may have heard that. It's basically a policy language and a policy, um, service that allows you to, um, encode policies and make decisions on them. So what we do is we work with, um, the maintainers and the security team of, uh, the individual projects and we, what, what ends up, um, the process is that we go through, maybe it's usually about two to three weeks. Um, the main aim of this is to get a general consensus of, um, the security of a project and what the result of this is, is, uh, we get this document. So I'm just going to switch here. So this is the CNCF security page, um, around GitHub and you know, if that's basically a ton of information here and everything we have really are in the issues. Um, so if you go to the issues, um, labeled with assessments, right, you can see, uh, a couple over here. So we have OPA and in total. So if we look at the OPA one, we end up with this document, which we think that is really helpful for end users, vendors, or operators. Right. Um, so the, the document sets are really generic with kind of what is this project, what is it trying to provide in terms of security. So like a little bit of background and stuff, uh, and the goals that it's trying to achieve in terms of security, non goals and so on. And so these, these things are kind of very straightforward. You can find that in the repo, but what I think is really interesting, um, for general users, if you go down into the document, uh, what we do is we ask, we perform the security analysis. Um, so basically we're trying to identify, you know, what are the main things that you have to look, look out for. Right. So in this case, we talk about, okay, while a certain attacker scenarios that could happen, if you're, you're, if this component is going to be breached within your, your solution or your cluster, um, what are the things that you have to consider, what are the mitigating steps you can take from downwards. So we go into a few details about, okay. So what are the attack surfaces, what are the things that the project could do better in the short term in the long term, whether it's, um, enforcing better defaults, whether it's, you know, providing better education to users that, uh, this is not, this is something that the platform provides and certain things you should not assume. So this document contains a lot of, um, interesting stuff. Um, and we also have there's some, um, notes on, you know, what are some of the defaults that you should use. So another one I kind of want to share about is in, in total over here. Um, so an example of how this would be useful is that if we look at, um, so this talks about, you know, why, if you have a key compromise, what happens, what's the implications of it. Um, and another thing that I think is really useful here is for certain components. So certain projects rely on certain other components. So in the case of in total, it relies on some kind of storage, um, verifiable storage for the signatures that it creates or the, the, the content blocks that it creates. And so like this document I'll talk about, okay, what are the different tradeoffs? What are the different implications, what are the considerations you need to look at if you're going to choose a different time of back-end for storage? Um, so we, we, we see this document as a way to help assess the security to help the project grow in terms of increasing the security posture, but also as a document that users can take a look at and really understand something about the project in terms of security. All right. So we have a couple of, um, security assessments that are coming up. Um, this one that's going to be on Falco, one that was going to be on Keycloak and possibly Habba. So these are the three projects that we're looking at. If you're interested in participating in security assessments, do ping us on Slack, give us a shout out on the mailing list, um, and also put your name down on the issue. So another thing that's been going on is a policy white paper. So this is not something I'm, um, very involved with. So I don't know, it's a fungus here. Um, he's the one that's really driving this. He's part of the policy work group. And he's going to have a deep dive, um, about the Kubernetes policy work group. You know, I hope, I think he may talk a little bit about this white paper that we're writing. But if you go to this issue and you click through, there's going to be a document talking about, you know, what are the details of the white paper? All right. This is not loading. So I'm going to skip this. All right. So a few things that are coming out is, uh, one, we also have on top of the policy paper, we are also writing a more generic security white paper. So what this, this white paper is going to talk about is, you know, what is, um, how do you do security in cloud native? You know, it's not going to be something specific to Kubernetes. It's not going to be something specific to, uh, certain runtimes, certain products. It's really, you know, um, from a auditor perspective or from a security perspective, what are the, you know, the base things that you have to secure? Um, what are the things they need? Like you need some kind of, um, DevOps pipeline, some kind of verification, runtime verification. Um, so this is something that, um, is coming up. It's something that's already in progress. Like I said, the policy white paper is also ongoing. Um, another big thing that we have is the security microsite. So there's been a lot of, um, ideas around providing education about security. So one of the ones of the, one of the things that we talk about is, uh, the types of vulnerabilities that we generally see in cloud native applications. So one, one example is, uh, the talk time error, the time of track, the time of user average, right? Um, if an object is modified in between where, um, the, the value we can't make assumptions about, uh, generally we see quite a few of those type of, um, vulnerabilities. So the Microsoft is going to serve a few purposes. One of it is to put on articles, um, that share about, you know, here are the types of attacks, here are what you should look at, here's how to mitigate, uh, mitigate them and how to do it right. Uh, we also hope to put more information of how to use certain security tools and security projects. Um, and just security posture, um, articles in general. Um, and last button on these, uh, what I mentioned before, we have, uh, in total opal, we're almost done. Uh, Falco, that, um, security review is led, going to be led by Justin Cormac. I'm going to be looking at keyfork and possibly Harbor, we were still unsure on that. We had to talk to the maintenance. Um, so I just go keep it short so we can, uh, talk after this or you have any questions. Um, you can find lots of GitHub, everything that we have for some GitHub, um, you shouldn't be able to not find any information. We just have to click through a lot of links. Uh, and then we can join us on the site. We're on the CNCF site now with the six security channel. Um, unfortunately we, so we meet every week, but we also understand that, um, it's really difficult to find a time for everyone to meet. Um, so unfortunately our meeting times are not, um, do not work as well with Europe and the Asia area. But what usually happens is the meetings are not compulsory and what happens is like, if you're interested in security assessment, for example, then you know, um, we will form a small group of three to four people and they, they find a good time to meet by themselves. So if you look at the GitHub, um, and the notes on the meetings, um, meetings are really about, you know, what's going on updates from different people, but a lot of the work in the group actually happens offline. All right. Um, thank you so much for coming and, um, do let me know if you have any questions. Thank you. You can see here from HP and I had many conversations with our security act activity in our company and I can fully understand the security people always like the policies, right? The rules. So I'm more interested in, you know, on the how peace, right? How we can address all these security risks and want to be in these more than you just tell us, no, don't do that, right? So, um, so a couple of things. So that is something that we are looking at in the general white paper. Um, so if you go to go, I can't play. So if you, if you look into the issue, we have a security overview white paper. This is the one I'm talking about. So we are currently in progress to talk about, okay, here are the things that you have to secure. Here are some, um, possible, um, ideas or projects. You can look at it. So, yeah, so here's, here's an example, right? Um, this is again, this is, um, really, really rough draft. This is something that we're going to work on next. Um, so the idea is, you know, compute definition of security, what the tools and resources that you have, you can use to help with that. How do you get compliance from that? Um, you know, how do you do runtime enforcement, things like that. So I think these are some of the questions that kind of, you're talking about that may be useful if we provide some, some insight on that as well. Um, and of course, like there are things like network pass storage and stuff like that. So, um, the, the group generally has, um, quite a few people that have also very strong opinions. So, uh, we are very happy to hear more from different people. I think it's really good if we have a discussion on, you know, what are some perspectives on. So another thing is, you know, financial users may have different, um, requirements from other types of users. So, you know, one of the things to consider, maybe we can talk about, oh, should we have multiple tiers of security and compliance? Um, if you're a regular user, maybe you should do these one to three. But if maybe four, five, six isn't really for you, unless you are, for example, working with, um, uh, credit card information and need PCI or something like that. Um, so this is something that's still being worked on. We'll be super happy if, if your team or your architect wants to talk about this with us. Um, you know, every perspective that helps. Yeah, I hope that that addresses. Sorry. Oh, yeah. Um, so what I would recommend doing is, so if you, if you just like drop a, go to a GitHub issue and say you're interested in this, um, and then, um, this, we'll follow up the issue. So, so we work very hard. So we will follow up the issue. And also, um, so this, this one, I think it's owned by Sarah, who is one of our chairs. Um, so if you ping her on the Slack channel, um, I think she, she will get in touch with you as well. You mean the, the, the, the six of me? Oh, I'm located in New York. Yeah. Any more questions? Okay. Thank you.