 Hello, everyone, and thank you so much for joining Brandon and I's introduction to Cloud Native Security. We are so excited that you are here, even if we can't see you, and we hope that you are staying happy and healthy wherever you are. Today, I'm going to get us started with a brief introduction about the special interest group for security, what we do, who we are, and why we're amazing. Then Brandon is going to jump in with some excellent resources for you to dig into later and even talk about some things that are going to make your lives and the Cloud Native Security community's lives better. I'll wrap things up with how you can get involved with this stellar group of folks and help move Cloud Native Security forward. Here we go. The mission of the special interest group for security in the Cloud Native Computing Foundation is to reduce risk that Cloud Native applications expose end user data or allow other unauthorized access. Everyone wants to protect their data and only allow authorized users access to applications. We're here to help make that possible in the community. We have three primary focus areas, ensuring the protection of Cloud Native systems while providing the needed access to authorized users and services, establishing a common understanding and common tooling to help developers meet security requirements and promote common tooling for audit and reasoning about system properties. And we do this through a lot of great opportunities within the SIG to include some major projects that we have underway. We're wrapping up our Cloud Native Security white paper and hopefully by the time you are hearing this, it will be published and linked in our repo. The white paper is designed to be a guide to your first Cloud Native security architecture. It was developed with love by the SIG and its members to help all teams and Cloud Native be more secure. We introduced a new model for Cloud Native security layers as you see in this diagram. It dives into each of these areas and features an executive summary. Later, we will be linking various sections with the new version of the CNCF's landscape, which is coming soon. The Cloud Native security white paper has a lot of excellent content, so be sure if you're reading through it that you take your time. With over 36 pages and a lot of great details, we can't wait to get your feedback and help make it that much better. This SIG does a lot to help ensure the security of Cloud Native projects while helping to identify projects that push more secure development and deployments. As you can see, we focused on quite a few different areas from container registries to key management and general security and compliance. It's important to us that the community continue to move forward with Cloud Native security and the assessments that we perform on these projects, as well as our special projects that we have like supply chain, help move that forward. Now over to Brandon. All right, thank you, Emily. So as SIG security, we have many different activities going on as always, and so we're going to go through a couple of these. So first and foremost, we have presentation discussions. These usually happen during our weekly meetings on Wednesdays, and these vary from presentations about projects such as Passag and KeyLime and other security projects to end user vendor stories and lessons about security. So on top of that, we have several discussions, and these topics are brought in by community members, so this could be technical where once we talked about the management and rating of CVEs for Cloud Native projects, to discussions about how we can collaborate on certain topics. For example, recently members of the Confidential Computing Consortium, the CCC, came to discuss what they were doing and also explore avenues to collaborate with parts of the Cloud Native ecosystem. So example of a security resource produced and maintained by the group is the supply chain catalog. This is the effort that resulted in a couple of interested members in the community. And what the security supply chain catalog is really is it provides a list of supply chain compromises and descriptions of, you know, what are some of the threats that apply to supply chain management. For example, we talk about a few different ideas like what does it mean for a threat called typosquadding? What the signing mean in the context of supply chains. So the document is meant to provide more both a means of education, but also serve to help security practitioners, convince management and decision makers on the importance of supply chain attacks. So as I mentioned earlier, this is community managed. So if this is something that you're interested in and you see a new supply chain compromise or would like to add more information about the threats and mitigations, please do come by and create a PR. So traditionally on top of our weekly meetings and when we don't have a pandemic going on, we hold in-person events co-located with KubeCon, Cloud NativeCon, or basically any security slash Cloud Native Conference that we have a forum of members at. So as we come to the close of 2020, we hope that the situation will get better soon. We, like many of you, look forward to seeing when we can continue in-person meetups safely. And last but not least, I want to spend some time on one of our co-activities, which are security assessments. So security assessments is something we do regularly. And to date, we have completed five security assessments for CNCF projects. These are Haber, Spiffy, Spire, InTotal, Opa, and Keycook. So audit is a security assessment. So first off, just to clarify, the term security assessment can be often overloaded. And so we just want to make it clear that a security assessment is not a security audit. To us, a security assessment is to be able to access the security posture of a project. This includes looking at the goals of the project and evaluating the amount of thought that has been given to the security aspects of the project. So this ranges from overall architecture and design patterns of the project, and includes also the evaluation of security processes by the project. For example, how does the project handle security issues and respond to security incidents? So the security assessment also helps the SIG provide recommendations to the CNCF Technical Oversight Committee or the CNCF TALK, for example, for projects that are incubating or graduating. And in certain cases, we also provide some feedback. For example, in the Spiffy-inspired assessment, we recommended that the project go to a security audit since it is a critical security component in the CNCF ecosystem. Finally, what comes out of the security assessment is a document, which we'll be seeing shortly, which provides an overview of the project and the security considerations. So at the end of it, this is a very useful document for both the project as a security.md type file. And in addition to that, for end users who would like to use the project and really don't know where to start in terms of security, this document will help guide them in terms of getting started and adapting the technology. So let's go take a look at an assessment. So what we have up here is kind of the overview of what the HABA assessment looks like. So the security assessment documents start off with, as you can see, details of the project, what the goals of the project, what does it do, and how does it work. Then we go into details of what the design architecture of the project is. So it ends up being a nice encapsulation of most of the details you would need to know about project starting from the ground up. After all that, we get into the call of the security analysis. So this usually consists of several parts, including the types of attacks, the attack capabilities that could be present, as well as for other different threats and mitigations. So in addition to this, security considerations also discuss here. For example, if a project uses a plugin or external database, what happens if the database on component gets compromised? So kind of a little bit of high level threat modeling that's happening in this section as well. So as you can see from this picture, this is actually a screenshot from the HABA assessment as well. You can see that in this case, different components being compromised would lead to different levels of risk being exposed. So this could help inform the decision if someone was to create a deploy HABA, they would be able to say, okay, looks like my compromise storage back end really is low risk. So I don't have to put as much controls as I would have example for a number 18, the compromise reddish cache. So I would want to put a lot more controls around reddish and then my storage back end, for example. And finally, we cover the implications of the project has in terms of the security of the cloud native ecosystem as well as the security processes of a project. For example, how does one file a security bug report? What is the process of handling that? And also the more technical aspect of this, right? So does the project have a DevSecOps pipeline? Are the releases of the project signed and how is the key stored, for example? And after the entire review is done, we create a one site summary for the TOC. And this covers briefly what the project is. As you can see on the left, we have the goals of design, security analysis and maturity, as well as some recommendations for the CNCF as well as for the project. So in the example we have here, this was from the OPA assessment. And one of the big findings that we had were that the policy language regal we found was difficult to use and sometimes would result in mistakes in writing policies. So for the CNCF, we had a recommendation that they should survey users of OPA to detect if they see any certain patterns of insecurity that may arise in policies. And for the project, we recommended that they improve the documentation as well as work on usability of the policy language. So that sums up the gist of an assessment. So if you find any of this really interesting to you, the good news is that you can volunteer to be a security assessment reviewer. Our team of reviewers has grown tremendously over the year and we've seen a lot of great new faces. And just in case you're not sold on that yet, there are many opportunities for professional development as well in participating with these reviewers. It provides an opportunity to really deeply dive into a new CNCF project or something that you've been always looking at and never really had the chance to look into. And throughout the entire review process, you have the other reviewers as well as the project maintainers who are there and really engage in the review. In addition to that, there are many networking opportunities, so both with the other six members as well as project maintainers and CNCF staff. So awesome, how do I get started? Security assessments are done in three-week sprints. The expectation is that one would spend a total of 10 hours over these three weeks dedicated to the review. So if this gets you excited, come shout out on Slack to us. We currently have a security assessment that is almost ready to go. This is for cloud native build packs. So if you're interested, comment on the issue as well. Now here is how you can get involved with this wonderful group of individuals. And I know that you want to. Check out our repo and join one of our meetings. We don't require that you're a security expert. We want you to listen in and learn or maybe if you are, present on a security topic. We've got over 68 members and we are growing strong, but we always need more passionate people such as yourself to help make our community even better and make cloud native security better too. There are lots of things for new members to do. We encourage you to read through the repo, familiarize yourself with who we are, what we're working on and how we run things. We love it when new members or folks looking to join, review our PRs, comment on them, improve them, submit issues in a proposal or even make a PR to close out an open issue. We've got some easy ones in there. We have labels for tickets that need help and sometimes just a quick review is all that's needed. As Brandon talked about, we've got presentations and proposals and suggestions and even security assessments that can all be excellent ways to contribute and grow the community. But it just starts by submitting an issue. You can learn more in our Slack channel, sig-security, in our meetings every Wednesday at 10 a.m. Pacific and through our mailing list. We look forward to seeing you at our next meeting and saying hi in Slack. Thanks, everyone.