 Thanks, Pushka. Yeah, Pushka is a great member of our community. He's worked on a lot of the stuff that you see today in our presentation. Cool, so let's get started. Yeah, we got somewhat of a contentious title, creating cloud-native security. What do we mean by that? Isn't cloud-native by definition intrinsically secure or meant to be? We're going to talk through the slides and during the presentation, what do we actually mean for creating cloud-native security? How to do open-source security in public, working in public, advancing the space, safeguarding the systems upon which we run critical applications and mitigating the structural risk as a whole. Brandon? Yeah, so today we're going to quickly go through who we are, how we're doing the things that understated, how we're going to secure our cloud-native security, build the whole thing. And also how we're doing it, which is very important and which we're collaborating with many different groups, both security and as almost as importantly, the non-security groups. So we're going to start off a little bit about talking about us. So who are we? We are the CNCF tax security. And the tax initially renamed from sick security exists as part of the technical oversight committee or the TOC of the CNCF. Essentially, you can think about the tax as kind of extensions, like arm extensions of the TOC in order to kind of help educate and to be able to help drive the technical decisions of the TOC. So our main scope of work, our main charter, is really create cloud-native security with essentially the goal of balancing the whole protection versus usability, right? That's the HO question with security. We concentrate a lot on common tooling. And I think this is a very essential part of, we are given this gift of having a green field with cloud-native. And we want to make sure that we build everything together as a community. We have common tooling. We have common auditability methods and so on. Our charter, just to add, informs everything we do. It informs how we engage. It informs our strategy. You've seen the cloud-native ecosystem, the interactive page where it has all these projects. A good chunk of those are security solutions. And there's no clear interface or boundary between many of these. The space and the problem domain is quite broad. There's a number of sharp tools out there. And we work with all these different projects. We prioritize work based on incoming requests from the TOC and the community. So we jump onto different projects. We do look out for common tooling. And part of it is, well, the problem is challenging because a lot of the getting started on the technologies is a high barrier of entry. These are very complex, expert-level systems. And there's not a lot of documentation. The maintainers may have a very good understanding of the failure modes, of the security boundaries, of the execution paths. But these are typically not well documented. So we do fill in for quite a bit of that. And around it, well, we're trying to fill in those blanks. And in order to fill in all these blanks, we, as a community, are not just security professionals. We work with developers, DevOps, Ops folks, the managers, engineering managers, and also folks that are coming in new to security because we are building all this for them and not for us. So we are largely community-based. We believe that this has been a successful model so far. All issues, all the PRs, all the efforts mostly have been driven by the members and participants of the community. And right now, we are almost, I think, at least over 100 members. And we come from 60 different companies. If I could get a show of hands, members of the tag who are here in the room with us. Awesome. Pretty good turnout. Some of you are security engineers. Some of you are practitioners. I see some product managers in the room. I see some tech writers. So we're a diverse group of folks. There's work for everyone. And there's just many ways to get involved, and we're going to talk through those. But yeah, part of that is democratizing security, making it accessible. So over time and the two, three years of existence of the technical advisory group, we have been very focused on outputs and artifacts. The way we work has proven successful by recent publications that have been quite timely. We have the cloud-native security map. We have the cloud-native security landscape. We have the secure software supply chain. Best practices. We have a reference architecture that is in the works. We have a number of other security resources. Cloud-native aid guiding principles for building security from the ground up. That is currently open for review. We're going to make some of these links available for posterity. We want to get as many eyes as we want on it. A lot of it is departing from security by obscurity. You can see a list here of a few other things. While the personas, the supply chain catalog, we're going to show different samples of these. Awesome. So one of the things that was initially our focus area within, this was back I think a year and a half to almost two years now, was the cloud-native security of white people. And essentially the whole idea of this was that we got a lot of people coming to us that were like, I don't really understand what cloud-native security is. How is it different from regular security, traditional security? Folks that are moving from on-prem VMs to containers are like, what's different with this? What is DevOps? How do I use it? And essentially we got together and we built the cloud-native security white paper. So the white paper is it first defines what is cloud-native security? Why is cloud-native security different enough for us to write a white paper just about it? Talking about the essential tenants and the methodology of cloud-native and how security has to evolve so adapt to them. So we go all the way from develop, distribute all the way to runtime, going from how do I develop my application? How do I do the checks? How do I publish these artifacts in cloud-native ecosystem? How do I consume and use these different artifacts? And then we talk a little bit about high-assurance things which are a bit more popular in cloud-native deployment such as zero trust. Now that essentially we are able to create Kubernetes platforms or different container platforms on top of infrastructure, how do we establish trust between the different islands? And we talk a little bit about compliance in terms of how it also affects different regulatory industries like finance, financial and federal. One cool thing is that this white paper has been very useful. We'll talk a bit about later. We've got some really good feedback that drives some of the work that we're doing. In fact, this white paper wanted to be used by, I think, in Brazil. And in Brazil there's a policy that you can only use a document for government contracts if it's written in Portuguese. So we do have a couple of folks that are translating this into Portuguese. I think we also have it, it's already translated in simplified Chinese and we have a couple that are ongoing. Obviously we also are going to adapt to some of the new things that are coming in. We are planning a version 2 white paper with the EOs coming in with this publishing the SSDF paper which has been, I think, some public command last week. We'll be looking at that and perhaps thinking about how we are going to close some gaps that I mentioned in the paper. Part of the intent here is I personally come to KubeCon and I get super excited for a lot of what I see and I tend to grasp it typically really quick, but I get back to work the following week and I struggle to be able to explain it to anyone else in my team. Particularly so if there are other security folks and let's not even talk about risk people. So the idea here is to empower individuals with a toolkit where they can become conversant and help articulate the value prop of security back to the organization and just get through those challenges of working with the different stakeholders. Yeah, and so another thing that we've done here and this was a follow up from the white paper is something we call the CloudNative Security Map. And the idea behind the CloudNative Security Map is to create a way or an interactive way for folks that are coming in to have a bit more practical guidance on things in the white paper. In the white paper we talk about general concepts or you need to sign your things, you need to verify them, you need to check the provenance of your containers and configure your runtime, but it doesn't talk about specific technologies. How do I actually go about doing this? So the CloudNative Security Map is an interactive page and it's actually hosted as a website. It's live, unfortunately it doesn't work on mobile, so don't try that. But the idea is you can navigate into the white paper and look at, okay, I'm interested as, you know, you have to start in security somewhere, right? So evaluating within your organization maybe I'll start with container image provenance, right? So I go into development or go into container image signing and provenance and then it will tell me basically, you know, here are the tools that I can use to go ahead with that, so it will talk about in total, it will talk about things like 6R, basically all the bunch of different tools and some general guiding principles around that. Another version tool that we have on this security map is to come up with something we call guided tours. This is still work in progress, it's about to start. The idea behind this is we want to define really what are certain tangible stories that people can take and start adopting. So let's say my boss goes to me and says, we need to do supply chain, supply chain security, right? So we will have a guided tour that says, okay, here's how you go about doing supply chain security. Here is how you're going to go about doing runtime security, doing risk management and things like that. So these guided tours will basically provide the connections between the different parts of the white paper and to put it in context of a specific technology. And we recognize those journeys are typically a progression. It maps a little bit to a crawl, walk, run almost. There's a process of discovery, there's a process of developing a better understanding from there going to a place where you can do architectural reviews and design reviews of these technologies to where you can make it part of your infrastructure topologies. So we're trying to incorporate that progression of adoption of a technology. So it's not just you go from zero to like full-blown web-scale prod, but it's gradual. It's a little bit of a couch to 5K program for security. So another project that we want to highlight here is something called the supply chain catalog. And this was put into place to kind of address and help folks understand and also show the importance of supply chain security. This catalog contains all, well, most of the supply chain security breaches over the past few years and is a good resource to kind of learn about the different types of supply chain security in the real world in the wild and also as a way to kind of convince stakeholders and high-level executives that supply chain is indeed something that's going to put you in the Wall Street Journal. One thing I'd like to mention about this piece of work, which I think this was really cool because this stemmed from a single contributor that was like, I want to do this. It was a maintainer of InTotal of Santiago and basically said, I want to do this. He proposed it to the tech. We said, cool, this is the line with what we want to do as a community. We did it. A bunch of people got on. Now, this is our living document. It's in GitHub. You know, if you find a new supply chain, something gets released. Supply chain vulnerability. Supply chain breach. You can go ahead. You can go in and just create a PR to do this. One of our other work streams very much tied to secure supply chain has been producing a codified what are the recommended practices. If you look at what are the entire set of controls mapped to risk profiles. If you are reasoning about a set of workloads that are not top secret but you still be secured and you require a variance between there's a differential between the guarantees. What are those different levels and how do you implement those in? Do you have a question? I saw you raising your arm. We produced and published the best practices white paper. This was led by Jonathan Meadows head of cyber and city collaboration with myself. We had about 15 to 20 other people who contributed and collaborated to this effort. There's a recording from KubeCon Europe where we talk about and go through the different aspects of the white paper. We have progressed from there well now that we have described a software factory end to end that incorporates security from the ground up. How do we translate that into an architecture that pieces all the different components that you can use as a reference. This is being developed with I see a number of folks in the room Marina Moore called Kennedy driving a lot of the work of well if you're reasoning about reproducible builds what's the relationship of that to like cryptographic identity. These are things that we typically don't see the relevance from one to the other but as you look into the bigger picture you need the different moving parts. As someone said yesterday you could have all the parts that make up a piano but if they're not assembled together right you can't actually play it. So it is that effort of like how to build the software factory with yes paying a lot of attention to the assembly line but ensuring that well the access point the entry of physical security of the different layers of it are also commercially secure that they're watertight. We are going to be opening it up for public comment in the coming weeks and from there then we intend to start writing some code so people could check it out and run a sample of that software factory and start building around it and on top of it. Brandon if you want to add something to that. Yeah I think this is something that really we want to as a committee show people that this is something that is attainable it's something that if you put a bit of effort there and I think Michael showed this a few others are showing this there's a lot of projects out there that can help you attain reasonable levels of supply chain security. There are gaps that need to be filled but we think that by showing this to others they'll follow suit and be able to say that this is a reasonable goal that's not adopting it in an organization. You probably have heard a lot of Salsa this week this factors and Salsa it factors different risk profiles, different security guarantees what are the compensating controls so it is very much attainable we're trying not to be overly prescriptive and say well at the current time these are the most mature or feature complete technologies in our ecosystem that you can piece together to accomplish this but we're also trying to provide alternatives and say well you could very well do this with tecton chains or you could do it with Jenkins X as an example. So we talked a little bit about what are some artifacts that we produce as a group and I want to spend a bit of time before we talk about how to contribute some of the things we do not necessarily things that end up in papers but things we do to help strengthen the security of the ecosystem and how we work together with other groups so big part of cognitive security and creating it is education and partnership this actually comes in the form of engagement of different projects and communities so an example of that the ecosystem in cncf we have something that we introduced earlier called security pals the idea is that especially with new projects coming into cncf as sandboxing or incubating we will have someone there to guide them to talk about what are the security considerations you should integrate from the start security is something you should keep in mind and not an afterthought so that is something that we are piloting it is going great we almost have our first projects done with that we also have something else that we do is security assessment and joint reviews this essentially is looking at the other cncf projects and assessing the security posture of it I won't go into much detail because Andrews will cover that in the next slide and of course we work with a lot of related groups OpenSSF, obviously Sousa for supply chain stuff we work with the Kubernetes 6 security group there is a lot of overlap with the members and this is great because we call each other out and also we want to make sure that we set realistic goals and make sure everyone is on the same page and then for our members presentations this go from presentations of projects in cncf or on security recently we had security defense, Kyver new projects coming into the cncf so that folks can get updated with it and also we have certain talks around like threat model you know behavioral security, how you manage security and organization and things like that cool, so do you want to talk about security assessments? we'll tell you about security assessments we'll start off to tell you my an anecdote really of how I got involved in security assessments I was working in the spiffy inspired projects shout out to the team, I see them here in the front seat and the project was at sandbox stage and we were pursuing trying to get to incubation and performing that due diligence and security audit security reviews where one of the requirements would have to meet in order to make that progression and the project had actually been scrutinized and reviewed and threat modeled and I quite didn't understand why would we have to do this over again and put it in a particular template format and it seemed a lot like an inconvenience so well we're security experts we know what we're doing our technology is battle tested it runs in production I don't think we're going to do it extract much value of it and it's more something we just need to get done now we got engaged through first off being able to in order to kick off an assessment you have to produce a self assessment and you need to explain to the technical advisory group the design of your project the threat model of your project the different security attributes of it and from there on folks, the reviewers start poking holes and this engagement typically lasts between a month or two months it's 10 to 20 hours over the course of this period of time after we completed that we actually not only got a better ability of how we talked about the security and value prop of our projects we were also left with a great artifact that helped us gain a broader reach because one of the typical bottlenecks when we were helping organizations trying to adopt SPIRE was a platform engineer would get it some security engineer would get it but when they had to deal with the infosec as part of the review in order to get to production they always had to call Evan Gilman or Andrew Harding or myself to threat model the project life so now we had a document sanctioned by the CNCF that would help us to speed through this review and would actually shorten the time to get to production because yes we can come up with an idea we can develop a code we can deploy it to some cloud environment but in order to get to production the biggest gate remains to be going through a security review going through a third party audit and now we have something that drastically accelerated actually getting there and having those folks satisfied with defensible arguments so it codifies a lot of that since that I've participated and I have to pay it back and this is how I got involved with tax security as we extracted so much from this I want to help other projects in this journey I led the security assessment for Harbor it is published also the assessment for BuildPEX, Brandon you've done a few others you're actually the reviewer for the Spiffy Inspire assessment so security assessments and reviews are something that we've done way back a lot of the projects that come to us say that they like it it gives them a document to point to and also it provides kind of a boost of confidence with the TOC as well in terms of doing due diligence we also will be working to integrate this into the graduation process obviously that's always changing so we are finding the right place for it but this has been something that the TOC has always advocated and we will continue to do so I want to underline the word confidence it's not just confidence for the different stakeholders but even for the project team for the maintainers because oftentimes we suffer from imposter syndrome and until you actually restate assumptions and look at your code base and say oh we're actually doing signed binaries and we're actually following the set secure software development best practices so part of the assessment is actually filling out the rubric for the core infrastructure best practices batch and it was a huge boost for all those different projects that have gone through the process because well we understand how we stack rank against it we actually do quite a bit of it or we don't do this much but here are all the other directions that we could do that are going to give our end users trust are going to make us more trustworthy and we're again better equipping them to take this places at their respective jobs so yeah I think that's all I have to say about security reviews yeah I think that the last thing I may add is like for projects that may want to get an official security audit like a KO53 trail bits type audit is helpful so to go to us we can do an assessment and then we can also make a recommendation to the CNCF TOC that this is a security critical project we think that it should be audited and we should buy an audit for it yeah and our experience working with Q53 Q53 always gives praise because it actually helps them come up to speed much faster so you're going to be able to take more advantage better use of the professional third-party audit that the CNCF pays for once you've done the prep work produce the information it's only going to expedite the process and I'm going to give them more to work with cool so I think the last thing that we wanted to talk about today just in terms of what we do is micro-surface or surveys in general this is something we do to kind of keep a pulse on you know what's happening outside the end users you know outside the security bubble what do people think about from the outside what are some things we can work on as well as to you know go back to the TOC and say that okay here is kind of a constant pulse of what's happening and how we're trying to address it so we did this we did the cloud native security white paper survey to kind of get people's feedback on you know after understanding cloud native what do you think is lacking what do you think we can work on the results of the survey said that security faults was number 1 and then we had the cloud native 8 which was talking about security faults that Pushkar was working on which is up for public comment by the way so please take a look at it all the feedback is valuable and then based on that just recently a couple months ago we started on the cloud native micro survey and this survey was talking about what are the challenges of organizations today what are they worried about and we see a lot interesting data we saw that you know obviously supply chain is a big issue but actually not far to behind of supply chain vulnerability management was like 10% behind supply chain secret management was another one we talked about where organizations saw that there was a gap in open source so this was around like secret management vault kind of stuff HSM alternatives there were no HSM alternatives that people were kind of looking for in terms of trying to use them in their organization and then part of these surveys also we think a little bit kind of ahead to things like H and 5G we kind of ask people what their concerns are and they kind of look pretty much the same but what the regular concerns are with addition on detecting suspicious behavior because you know all these devices are in places where there is physical access cool so Andres do you want to talk a little bit about where you can jump in? I think we're coming up in time but there's plenty of ways to get involved it is a collaborative effort security is a huge responsibility but look to your right, look to your left this is a good chunk of the people in the world who are entrusted with it unmitigating like the pervasive attacks we keep on seeing that it's mind-boggling that these things continue to occur when technology is available we just haven't productionized it well enough so we have a mailing list click on it sign up, stay in the loop of our different communications come to our github repository we do our best to triage issues what's low hanging fruit what's a good first issue what areas are we looking for help we meet weekly every Wednesday over soon Cameron Cedar is regularly on the calls you can ask him and see how we work there come join us we have calls for the different working groups the supply chain call happens every Thursday come to our Slack channel if you don't want to jump into the deep a good glimpse is our roadmap the project board on github that will give you a good sense what initiatives are at play what things are in our radar that we're planning for what things are we being asked for but we haven't actually quite gotten into so there's plenty of ways to get involved if you don't see something that is immediately interesting and you have ideas propose if you are particularly passionate about something that you think we have overlooked we'd love to hear what's on your mind we would love to collaborate with you on how to engage others we're looking to participate and help us continue to secure and safeguard the cloud native ecosystem with that before I walked in and to the room I had a huge confidence boost from Cole Kennedy who has a little bit of a recent participation but I'm trying to paraphrase what you said but we could hand him a mic and share what you said so it's just not me trying to tell you the virtuosity of tax security but if you could share a little bit of your experience yeah so I first got involved with tech security through some of the work I was doing Spiffy Spire presented a little bit actually last year at KubeCon through the CNCF Slack and from that moment on I just felt like a big hog from the SIG Security and my clients that I was working with at the time when the SolarWinds happened were really affected by it it's a serious issue so the first thing I did was we didn't have the expertise to deal with that but when we got to SIG Security and started working with them and it really you know Andres brought me in he actually co-authored an article that we posted on our company blog and he was working for VMware at the time so not only did I feel that personal hug he also helped my company deliver value to our customer she didn't need to do what the security tag can do for you is both elevate not only you on a personal level by including you but also on a business aspect right you have some of the greatest security experts in the world ready to answer like any questions that you want and that's a really powerful tool to use to help your customers and your initiatives that you have within your organization to ensure that you're more secure so what it is is that when you do get involved when you come to places like CubeCon there hasn't been one dull moment here I've been invited to dinners every single night I've been here I don't know how many hugs I got from pop and bananas so if you have issues with your cloud native deployments or questions from your regulators about the security come in and ask your questions I promise you'll be welcome thanks so much we're available to your disposal consider as your security friends yeah and just like a reminder again we drive everything to GitHub very community focused again open to whether you're someone that's new to security someone that's keen to learn our community is very friendly we need folks all types of folks to give different perspectives and ideas and yeah as the leadership team the co-chairs and the TLs are always open to your DM so message us just ping us on the Slack channel what questions or feedback do you all have for us this is our mascot by the way any questions one in the back thank you for talking what are your thoughts on getting a pen test traditionally done on your servers to test your security in the context of Kubernetes like clusters something that's viable worth considering I'm gonna try to say back to you what I understand your question is do we conduct pen tests and if not is it something we could be doing just your opinions on it like if it's good practice doing pen tests absolutely you want to stress test systems you want to measure them for their resiliency and how fragile they are and understand which different ways can they break a lot of what we do with the security audits is produce the information that will inform pen testers so we talked about the third party security audit that CNCF gives as a service to the projects I don't know if it's something they're going to be doing with the new credits program but a few different of the projects I've been involved they put in a very sophisticated crew of individuals to black box attack your project I don't know if you would come in here in front recently went through one of those I don't know if you would mind saying a word or two about that I'll pass the microphone up here great question thank you thanks Andres yeah so our projects went through I wouldn't quite call it penetration test but it was the cure 53 security audit that was referred to earlier it was like half way kind of I guess it was half way between white box and black box but it's one of the benefits of being incubation of a project in CNCF is that you're able to do this audit and the CNCF will cover cost our experience going through that process was actually very good and those folks knew exactly what they were doing they uncovered a few pretty nasty things that we were able to respond to quickly luckily but we learned a lot in that process and it was hugely, hugely valuable probably one of the most valuable security review processes we've gone through and so you know I cannot recommend it highly enough I'm not sure if that's exactly what you're referring to it with the pen testing you know I know that there are different opinions on the effectiveness of live pen testing on production environments but the experience that we had going through CNCF sponsor security review was second to none and I cannot recommend it high enough yeah there's actually, thank you Evan for that that's very insightful there's one distinction in there of the usefulness of a pen test of a runtime system and when we talk about the ephemerality of things and like systems that should be immutable there shouldn't be any runtime drift arguably a pen test would be poking a little bit into those wounds if those things are not there but it can surface additional information the audit is a little bit more like not in production to say but yeah all right so I love the enthusiasm but we are out of time so I request everyone to go and chat with any of the tax security members including me on the hallway thank you Brandon and Andres for the session hope you all enjoyed it yeah thank you