 We wrote a book. We wrote a book about all the security assessment activities we are doing, what are the things that is covered in these activities, and how you can get some goodness. So let's dive into it. I mean, what a wonderful world today, isn't it? At least for the last two days, I've heard and listened and been part of so many activities, and it's so overwhelming. Everything is connected and there's innovation everywhere. I think it's the best time to be here around and be here in Silicon Valley. That's so awesome. This is not Silicon Valley. I understand San Jose and San Francisco and these times are. But I just came from India, so please bear with me. But in the same context, there are also a lot of things connected, and the attack surface is increasing more than ever. And that means if anything is, in fact, indeed kind of compromised, then all of us are in soap. And Lock 4j, for that matter, was a really good example to show that if everything is connected and if everything is, in fact, the way it is, we need to be really careful about what we are doing in the first place. And it is important to understand how secure are we really are. And memes kind of like this kind of make me scared most of the time. And it says that if any project is not looking into security in the first place, and they just build and look into their features and ship something, and then see, oh my god, how did we get hacked? That kind of makes me really, really weird and scared for the rest of my life. So that's one of the reasons why I joined tax security, because you're not alone in this process. There is a lot of help available for you. There is a lot of help in terms of what you should be doing and how you can actually do them in terms of tools and mappings and guidelines and everything. And there is also help to see if you've done it the right way. We also have a particular team of volunteers to actually help you go through the security assessment in terms of self-assessment, joint reviews, and things like that. And shout out to one of my colleagues and volunteers here. Shlomo is giving a talk in about 45 minutes. So please feel free to go to that talk and see all the goodness that we are providing as part of tax security. But then we also thought, how can we actually supplement all these goodness? How can we help you verify what you did was, in fact, right? And how can we help you verify at the earliest what you did or what you're going to do is indeed right? And that's where we want to introduce you to Security Assessment's book. Security Assessment's book is intended for project maintainers and security enthusiasts, security reviewers who want to join us in this process, understand what is going in the background, and we want to make sure we really lower the barrier for entry so all of us are in this together. If you want to perform some security review for your project, or if you want to join hands with us and join hands in this activity of assessment, it's really clear what is happening in the background, and we can all be together in this and improve the security posture of our landscape. And the benefit really is to understand the security assessment process and the benefit that you get as part of making the software itself more secure. And it started as part of, like Andy said, it started as part of a part of lightweight threat modeling because we had a very good process. But there were certain experts who knew what they need to be done. And if I wanted to join, I'm a student right now. I did a bit of my engineering and enterprise experiences before, but I'm a student right now. If I want to join, how do I really get started? Who tells me what I need to do? And that was not very transparent before, and that was primary reason why we started this project. So all of us get a clear visibility of what is happening and what needs to be done. And kudos to our primary author, Justin Kappos. He couldn't be here with us today, but he is wishing us the best from China. So thank you, Justin. And we want to make this a community resource. We're looking for feedback from all of you in terms of what you need. And if we are addressing everything you need, and if there is any scope for improvement, do feel free to reach out to us. Now, let's delve into what all the goodness is all about. So I'll be talking about the security assessment, how it is different from audit, how to perform one such thing. And if you don't want to perform yourself, we have volunteers who do that for you, how to get one security assessment for yourself. And what's next in terms of this project. So security assessment is about examining the architecture and the posture of your project. It's to give a holistic view on what are the things that you are doing and is it actually aligning with the goals of security in terms of your project. It dives deep into the systemic and the design-related issues, not necessarily the implementation. And provided your architecture doesn't change drastically, it does stay for a longer time. It sounds more similar to audit's right, but then audit has fewer minor details that is what makes it different from assessment. So audit really looks into the implementation issues. It doesn't really, it does, but not specifically meant to look into a systemic or design-related issues. And audit provides you a snapshot of your security posture at that point in time with the addition of minor details and new lines of code, that posture may change as the project progresses. But security assessments on the other hand, it's meant to be valid for a longer duration until you really change your architecture or revamp your project as a whole. Now, how to actually perform a security assessment? To do that, you need to know what you're protecting. You need to know what your assets are. You need, and assets are something that brings value to you and you have control to do something. Now, say for example, I wanna create a website. I host it in some cloud provider. I use DNS, I use routing services, I use my ISP to actually route my traffic to the web server. In this, something that is of value to me and which I have in my control to actually do something about it is my web server and my web application. Other than that, I can change a few things but not necessarily dwell deep into how they are implemented and make changes over there. So understanding what our assets are and how they interact with each other is something really important. And assets need not be just intangible ones. It can be tangible ones as well. So differentiating what is that that is important for us and how they interact with each other in terms of data flow diagrams among many others, that becomes very important. Once you know what your assets are, understanding who the actors are that is associated with the asset is another secondary factor. So there are actors who increase the security posture of your asset and there are actors who try to decrease your security posture. And then there are also actors who supplement it based on their activities. It can enhance or it can decrease. So understanding who these actors are is kind of very important. Now, once you know your asset, once you know the actors, you need to also understand what are the goals for your system? Is it confidentiality? Is it integrity? Do you want it to be available all the time? What exactly is the goal for your system? Now, for example, governments may be very careful and they may be very conscious about protecting their information and making it very confidential. On the other hand, Facebook and Google and availability may be very important for them because even one hour of downtime or even one minute of downtime will bring a loss of huge amount of revenue for them. And these, the CIA tried, is considered the holy tried, but it's not necessarily enough. There is also other secondary factors, such as authentication, non-repudiation, secrecy, privacy, and other factors that may also be important for you. Understanding what these goals are is very essential. And with these goals, we will be able to map what are the things that are in threat and how we can actually mitigate it. Now, on the other hand, the attackers are very, very interested in bringing down all our goals. So they may be interested in disclosing our sensitive information, altering our assets and hampering our integrity and distracting our services and bringing down the availability. So understanding what the attacker goal may be and what is that your primary concern will help you in mitigating all the risks. Now, from the assessment perspective itself, there are three primary goals. In terms of assessment, you need to identify what your threats and risks are and then you need to categorize based on the impact and then respond based on what is that as most important for you. From the identification perspective, if you've been in the previous talk, you've heard in lengths and depths about this thing, there is several modules that is available and methodologies and frameworks that's available for you in terms of what actually is in threat for the service or the application. So basically, in terms of identification, we need to know what are the threats that is possible for the service and to know that we already went through the actors and assets that is important for us and among the various frameworks, Andy talked about stride, but there are also other things like pasta, tried and octave and linden that is newly available for privacy. So based on what approach your organization is taking, is it a risk-based approach? Is it attacker-centric? Is it developer-centric? You can choose the relevant model for your identification and then work upon the threats accordingly. So now in the cloud-native community, we are mostly developer-centric and we are very focused on our community and stride is one such developer-centric model that helps us identify the threats and help in the mitigation steps. So in this book, we talked more about stride framework. So stride basically stands for, it's an abbreviation for spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. So when we want to discover any threats that is applicable in our environment, it can be fitting into one of these buckets. So if there is no TLS, no encryption, then it is hampering our information disclosure and it's actually bringing down the confidentiality and things like that. So this is how we can identify what really matters for us and how threats are impacting our product. Now once we know what are the threats that is applicable here, we need to know what is the damage that is caused because we do not have forever, we cannot boil the whole ocean, we cannot address every little thing that comes upon us. We need to be able to find what is that is most craziest for us or what is that is most easiest for us? Because for some threats, stars need to align and some crazy four, five, 10 zero-day vulnerabilities has to come up for some threats to be realized. But for others, it's clearly visible. Some web application is running on HTTP, that's clearly a threat for us. So those are the ways in which we can identify the impact and the likelihood and then find out what are the damage that is caused for our service and mitigate it accordingly. And there are popular frameworks like common vulnerability scoring system and Dread from Microsoft that is available for us to see what is the impact and categorized based on that and address accordingly. Now once the impact of the threat is known, next step is to go for how we respond for those threats. Now we know there are high severity, medium severity or low severity threats and how we respond to those threats is very important in terms of if there is a possibility to prevent something, let's prevent it. Let's not put some patch and just make it something like immediate thing. Let's think about the long term and if there is a preventative measure, let's do that. But if there is no preventative measure that's available, at least let's recover from it. If there does happen some damage, let's recover from that damage. If that's also not possible, let's detect that some damage has happened and trace the whole source of it. If there's no traceability, at least let's detect it. Otherwise, at least let's do some traceability. So this is how the prioritization works. So we prevent it, if not possible, let's recover and if that's also not possible, let's at least detect with some traceability. So we did supplement, we wrote a big book about it to verify if what you did is right or how we can verify at the earliest what you're doing is right. Now this is already a process in tax security. We have a big process for all the projects that is going from sandbox to incubation or entering sandbox or you want to go to graduation. So what we recommend is first step as performing the self-assessment. So there is a lot of material that is available in our repository. You can go ahead and perform the self-assessment as per the template that is shared and present the details in one of our tag meetings. So tag technical advisory group for security. We meet every Wednesday and you can present it in any of our meetings and it's a community of security engineers. We are more than happy to review and share our feedback. And once you have completed the self-assessment and given the presentation, tag will include it in our repository and you can just create a PR and include the self-assessment and we're more than happy to include it in our repo. And once that is done, this is usually recommended for projects that are entering a sandbox to us and a bit lower in the maturity in the tag graduation process. And the next one is the joint assessment that is recommended for somebody who's going from sandbox to incubation or incubation to greater maturity of graduation. And in that, the volunteers from our tag sit together with you, understand the whole process of what exactly your application is doing and where the threats are coming from and what is the impact of each of these threats and how you can mitigate it to enhance your graduation level or maturity level. So to get one such assessment, you can initiate a joint review request. You can add an issue in our tag repository. All of the links are given here and the slides will be shared. So you can issue one such issue in our repository and we as reviewers, we sit together and see if there is a conflict of interest and we declare that conflict of interest and get together who are not having any such conflicts and then we sit together with the project teams and understand your project scope and what are the threats that is applicable and we clarify all the review process together. And in some cases, we also perform the hands-on reviews and finally, this is discussed with you and finally it'll be presented in one of our tag meetings and the assessment will be added to our repo. And I really need to mention a couple of names here. These are the folks who have done awesome work in tag security assessment, Justin Capos, Matthew Kisa and Romartin and other tag contributors who have really spent a lot of time in helping increase our posture and as a community. So that's really awesome. Now what's next? You know there's a book now. I literally walked, I talk too much now. So how can you get involved? So if you have any feedback, go through the book first. If you have any feedback, anything that is missing, anything that could be done differently or any major things, please feel free to let us know. We are more than happy to inculcate the feedback. And for folks who have already gone through this process, if you have any commentary, expert commentaries, or feedback you wanna include in that book, please feel free to reach out to us. We chat in the tag security assessment slack channel in the CNCF workspace. And we have come together a teeny bit of guidelines for engagement so that we accelerate this process and not stick together with small nitty gritties. So we try to focus as much on the high level of problems and omissions and we welcome any expert commentaries and feedbacks from the community. And to maintain the uniformity and single voice in the book, some of the modifications may be paraphrased by our primary author. So these are some of the requests for you in terms of guidelines for engagement. But other than that, feel free to reach out to us for any form of feedback. And with this, I end. Any questions? Thank you.