 Welcome back to AppSec Village. We've made it to the end of the third day. The next talk will be the final talk for AppSec Village for DEF CON 2020. Now before we go into our final discussion, I'd like to take a minute and thank the organizers for putting on AppSec Village 2020. This is our second year. It's been a phenomenal year. The team has done a great job with very unique circumstances as we look around the world right now. So if you have a minute, jump out to AppSec Village, hit them up on Twitter, and just say thanks because they put in a lot of work trying to get this done in a short amount of time under really, really weird circumstances. So thanks organizers. Thanks all the volunteers. Thank you to all of our speakers. It's been a fun run and I cannot wait to do this again next year. With that, let's talk about our final speaker for this year's DEF CON. The final topic is going to be running an AppSec program with open-source projects by Vandana Verma Segal. Vandana is a seasoned security professional with experience ranging from application security to infrastructure and now dealing with DEBSEC ops. She has been a keynote speaker, a speaker and a trainer at various public events ranging from global OWAF's AppSec events to Black Hat to regional events like B-Sides events in India. She is part of the OWAF's Global Board of Directors. She also works in various communities towards diversity initiatives including InfoSec Girls, WOSEC and NO. Vandana has been the recipient of several prestigious awards and has also been listed as one of the top women leaders in the field of technology and cybersecurity in India by InstaSafe. Please welcome to the AppSec Village Stage one more time for Vandana. Hi everyone, thanks for joining the session today. Today we are going to talk about how to run an AppSec program with open-source projects or OWAF projects. We can also say that how to build an AppSec program in an organization. We are all heading toward modernization of applications. We are all trying to use microservices, application programming interface or APIs. However, we still see that the breaches are happening and the breaches are happening because of SQL injection, sensitive data exposure or security misconfiguration. There's a big gap which our industry is grappling. Organizations who want to set up an AppSec program, especially from scratch using open-source tools. They have no idea where to start off. They need a security program which they can pick up and go ahead and start using it. OWAF has many projects which can tie seamlessly into the application security pipeline or application security program. However, firstly, we don't know whether they exist or when they exist, we don't know how to use them. So there is a big problem lying out there. With this talk, I'm going to talk about how we can set up the AppSec program using open-source projects. I'm going to share a framework which can help in tying up the projects, especially when we are talking about using them in the DevSecOps pipeline or application security program or pipeline. In the end, how we can start contributing to these projects because it's very important to understand about these projects and how we all can help with these projects. So another important aspect is that there are students who actually want to be part of application security. There are so many people who ask these questions that how can I get into application security? I'm a fresher or I've been working on a network security or I've been working as a developer. I've been working as a tester. How can I get into application security? So with all these projects, we can get a sense of how application security projects are set up and how we can actually kickstart our career in application security. So before I deep dive into the presentation, I want to talk a bit about myself. I'm Vandana Verma-Seghal. My day job is with one of the multinational companies in India. And apart from that, I root for Pro1Work and I work with OWAS, which is open-source application security project. I'm one of the global board of directors for OWAS. Apart from that, I also work with diversity initiatives. I'm the president for InfoSec Girls. I've even noted at multiple conferences. Now, coming back to the topic, so this is the framework which I was talking about. This is what I felt that in every AppSec pipeline, these are the things which are required, like requirements gathering, threat modeling, source code review. All of these things are really, really necessary when we are setting up an AppSec pipeline. So students can have their own projects and they want to build the whole pipeline. They can start understanding, okay, these are the things which are necessary and which we should be catering to, which we should be addressing to. Before even coming out of the college and especially for a startup, if they don't have any view that, okay, if I'm going for an application security program, what are the components that I need to have? So these are some basic components which I felt that we all should have in an organization. So that's what I put in here. Let me start about with a framework that how we actually can take a help of this framework and address all the loopholes in application security, especially about legacy applications, desktop applications, mobile web applications, microservices, which are exploited in these days. Now cyber criminals can gain entry into an organization system and see confidential data if we don't secure our systems. And this is a fact that breaches will happen. They are inevitable and security flaws will exist. There's nothing which is 100% secure. However, what we can do is we can minimize the chances. This is when the app set program comes into picture. And this is when I thought that, okay, how about let's use the OS projects and get started with this framework. So one of the first thing that we need to understand is that we need to have an app set program because if the organization doesn't feel that they need to have an app set program, then the framework will never going to help us. So we need to have an inventory that this is these are the applications that we have or these are the applications we are going to build. So with requirements gathering, first we need to have the requirements gathered that these are the things that we need in an application. These are the applications that we have. Everything needs to be noted down. But where are we going to have some place where and we can list down. The things that we have and that's one of those things we're going to decide. Okay, yes, this is our plan. So OS security rat requirements automation tool is an amazing project which actually can help in automating the security requirements, especially during the development phase. Now, when we have simplified automated requirement gathering, it streamlines the whole process because that's where the organization starts off. Now, apart from that, there's another beautiful project which is a vast security knowledge framework, which is big of exhaustive projects and project in itself. It is, it's a like, it's kind of an ocean wherein you have everything you can note down the requirements. There's a proper medium wherein you have a lot of requirements mentioned on top of it, you can mention your own requirement. And based on those requirements, we can define, we can figure out that what's the severity of an application. We can map it with application security verification standard. We can define the maturity of our application, our organization application security program. It provides a beautiful layout with best practices which developers can use. So when we have rat for automation and security knowledge framework, we can gather the requirements very well. Because if we don't gather the requirements very well, we would never be able to secure application or we would never be able to build an application which is secure enough. So first we need to have our own requirements noted down somewhere with the right medium. Then once we have, okay, these are the things that we need in an application. We need to threat model our application. Likewise, if we already have an application, we're going to build a feature. That time also we need to have a proper threat modeling in place. But how to do the threat modeling? It's like, it's a kind of a jargon. It's a kind of a technical term which we all have been talking about, but we don't understand, okay, how to go about it. Not everyone work on threat modeling, but it's actually a simple one where we can now use threat modeling as a code. We can use the tools like threat dragon wherein when you put all the details in it, it provides a beautiful graphical overview. Okay, these are the things that you have. And this is your application. So I'm going to tell you whether it's a high severity application, medium severity application or a critical application. And if something happens to an application, what will be the impact? So threat dragon provides a beautiful view of threat modeling that how we can threat model our application. Similarly, PyTM, which is a Pythonic framework for threat modeling, which is a beautiful and amazing data flow diagram project. Now, sometimes we don't understand, okay, these pieces are scattered everywhere. Now, if we have a flow chart wherein, okay, now this is the thing where we are heading left. If we are right, we are going to go left. And if there is a problem, we should be stopping on the right side. So with an amazing flow diagram, PyTM helps us in the threat modeling. So all the details I've mentioned, okay, this is how the diagram looks like if you can see on the right side. And it is like sequence by sequence, analyze the application and give you the result. And where you can find it, you can find it on this particular projects page. And you can look through it. You can understand there are so many resources which are available for you to be to guide that how you can get started with it. Because I'm going to talk about many projects in this particular talk and giving you overview on it. Okay, this project does this because while I was learning about OAS projects, few projects I knew, but there were few projects which I wanted to understand when I was building up this framework. So I realized I had different understanding of these projects. I thought, okay, this project was this, but when I actually researched through it, over the years the projects have actually enhanced a lot. So the project working, I'm going to talk about. So once we have done the requirements gathering, we have done the threat modeling, now we know, okay, this is the thing that we have in an organization. These are the requirements we are building up in an application or this is a new application which we are completely building from scratch. So once we have that, we are going to work on the code. Now, when we are going to work on the code, we need to have the code which is securely developed. Especially, we have talked about so many research projects wherein if we fix a bug in production, which is a much higher cost than the bug which can be fixed in the development phase or even earlier than that. Like in the requirements gathering, we start talking about security or even threat modeling. We talk about, okay, these are the things that we should be fixing now which can help us in the later stages of the application security project. So code review checklist is like amazing checklist which provides, okay, these are the things that should be fixed in a code. These are the things that can be guided. We can actually build our own checklist on top of it. Like for source code review, I have built my own checklist on top of the ones that we provided by the code review checklist. Similarly, there's another project which is code first project, which is a project which helps in finding the code which might be left behind or which we might have left at some point. So a continuous challenge with any penetration testing or even in code review, that we don't know whether we have covered everything or not, whether we have covered the whole application or not. So it's purely a black box perspective which actually makes it almost impossible to accurately identify how much of the code or an application attack surface that has been tested. So code first is actually a glass box tool that provides the insight into the real time code coverage of penetration testing, all the activities that are being done. So it automatically detects the coverage information with the test being conducted and will even make it possible to understand the overlap and the boundaries of different tools coverage. So code first present the coverage information in a visual form. If you can see on the right, so this is how it provides wherein you have a beautiful view, okay, these are the things that have been covered 60%. These are the things that have been covered 90%. So the real coverage or real time coverage feedback makes it easy to adjust the testing activity, especially based on the observed coverage. In addition to those testing activities which are relying on multiple techniques. It's easy to split up the recorded activity to independently and alternatively understand the overlap between multiple tools because we have so many tools from which we test an application. So code pulse really, really helps us with that. Now, we have understood, okay, this is what we have done with the code review. But how about specially designed code review checklist or practice guide for a certain code, like go code. Go code, I started learning like a couple of years back, but before that it was like a completely new arena for me. And then came up with a secure coding project, which helped me in understanding, okay, this is a goal language and this is how we can securely code it. So go secure code is another incubator project which can help us in understanding the basics of how to secure code. Another beautiful checklist is cheat sheet series. This cheat sheet series helped me a lot, I would say, because this provides an amazing overview that this is a vulnerability. This is how an attacker can exploit it if you don't fix it. And then remediation procedures. It's a beautiful checklist and it has actually catered and helped me in multiple projects in my multiple organizations. So if you look through it, it's a beautiful document and there's a beautiful documentation around it for so many vulnerabilities for so many controls. It's it is an exhaustive list starting from input validation to cross-site scripting to XXC to intellect object reference to any other vulnerability you talk about. It has the details. So you should actually take a look at this cheat sheet series. Every time I look at it, I actually feel that I'm more connected to it. I really fell in love with this cheat sheet series. The new that has been developed by the team or the remodel website which is there for cheat sheet series. Another important aspect is when we have worked on the code review and we tend to miss software composition analysis, which we have seen that there are breaches which have happened in the past like EpiFax. Those happened because of using the components with known vulnerabilities or there were projects which were in use. There were open source code which were in use, but we missed to update the code or there were so many reasons. Now, so when we know these things are there, why don't we fix it? But how to fix it? It's a big challenge. I was actually going through one of the research paper where invite source has quoted that 96.5% code on the Internet is all open source. Now, that's a huge amount of code. When like almost all the code on the Internet is open source, what can go wrong? Which means, can we say that everything which is lying over there which we are using is all secure? No, if that's the case then breaches wouldn't have happened, why the breaches are happening. So to reduce that, we've started understanding that we should have software composition analysis wherein we are scanning our code base. But is it too easy to buy a software composition analysis tool? Like we just go ahead and buy it. I am not against the tools, but I am in no support of buying a tool in the first place. Like you're just saying that you want this and you're going ahead with the tool. So what else can we do? Is there any project by OWASP? Yes. So OWASP has a dependency check which is called DC, people call it as. So dependency check, this is an open source component which is like now an integral part of many organizations. And it helps in checking or scanning open source components. So why it helps? Because now as I mentioned that open source components have become an integral part of software development. We need to make sure throughout the development process the software products which we are actually creating and even maintaining don't contain the vulnerable components. Or the breaches will keep happening. If we are using any third party library we have to make sure that we are making sure that there is a place wherein we are updating them. We are keeping a record. Okay, these are the libraries which exist. So how should we do that? Are we going to just go ahead and buy a tool as I said? No, I am not going to do that. The increasingly widespread use of open source components have actually taken us to a way where if we don't know what we have in our code we will never be able to secure our organization from any of the breaches. So we need to understand that throughout the development process that the software products that we are developing or we are creating we need to maintain them. We cannot just think that we have developed a product and we are good. We need to actually keep updating it. But how to keep a track of all the third party components? OVAS dependency check actually helps or resolves these concerns for developers which identifies project dependencies and checks if there is any in the code or it is a publicly disclosed vulnerability in the code as part of open source component. Now how good it is or how bad it is or how heavy is this? Because all the tools that I have been working on, they are so heavy. So to put it this way, OVAS dependency check is the lightweight and very easy to download, install and run component or a tool. So when I downloaded it for the first time, it took me some time to download the NVD database. However, after that it was a delta scan, so it was like a very quick scan. So the scanning process is seamless. When we are scanning the code, it finds out, okay, these are the third party components we have in the tool and these are the products. This is the version and we have to fix this particular version if there is a vulnerability that exists. So there are plugins which are available for Gradle, Maven and many other projects which allow us to integrate them as part of our whole life cycle. We can integrate with Jenkins which can allow us to integrate with the CACD pipeline. So apart from that, we also have OVAS dependency check which is an intelligent supply chain management or component analysis project or a platform that allow organizations to identify and reduce risk from the third party early in the life cycle. And this can also help us in tracking the application, tracking the libraries, taking the frameworks that we are using, operating systems and hardware components. It's like a huge list. Apart from that, what else it helps us? It helps us in identifying multiple risk areas like component with known vulnerabilities, out of date components, modified components, license risks, then there are many other things which are coming soon. So it includes a comprehensive auditing workflow for triggering results because once we have scanned it, if we don't have a proper result, obviously we are going to suffer it. So once we figured that out, we need to have the result and not just that. It is very simple to configure as well because configuring a tool is like a nightmare sometimes. Like I've been in that industry for quite some time now and I've worked on all the tools starting from the basic tool to the advanced tool that we have. So I know sometimes that's like pain to configure a tool. This is like a pretty easy to configure project and we can go ahead and get started with the bigger projects. Now we have gathered the requirements. We've done the threat modeling. We've done the source code review. What else we have done? We've done the software composition analysis. So what else is pending? Vulnerability testing. When I started in the industry, we were doing very less of a code review, leave the software composition analysis. We were just doing the vulnerability assessment and we are good. And I have been an evil person in the project team. Whereas if there was a critical vulnerability, I have stopped the releases. But then over the year, we all grow. In the industry grow, we understand, okay, stopping a release is never going to answer us. So we need to go through all the life cycle. How about we start early? We shift left and that's where we are. We are all shifting left. We are talking about it. So now in the vulnerability testing, what are the things we cater to? Like what exactly we can use or how exactly we can perform a vulnerability testing? We've been doing, okay, most of the aspects we must be knowing, I'm sure. But then how about using the open source project for that? So let me go ahead and get to it. So this one, I'm sure you must be aware about it. We're an OVAS web application security testing guide, which is an exhaustive guide. We're in how to start an application security testing. Robots.exe file. What is crawling? What is spridering? What is SCLC? Software development life cycle, everything in detail. If there is a flaw, information gathering, everything summarizing it. Like, okay, this is what it is. Then if this has a problem, what will be the vulnerability? Once the vulnerability is there, how to remediate it? I've created a presentation on how to implement a web security testing guide. You can actually look through it. So which provides a good detail about how to use the web security testing guide. And it will help you. Trust me. It's an amazing guide. So when I was introduced to OVAS, this was the first thing I was introduced to. There's a web security testing guide which exists. And I should start using it. And that's where my journey in detail in application security testing started off. Now, when application security testing guide is there, we are talking about applications. But in the beginning, I mentioned that we are all talking about modernization. We are all talking about using APIs. So when all of these things are there, how to make sure that we are using them correctly. And there's no flaw in them. So OVAS API security top 10 answers just that. It is a good list of the top 10 breaches or the top breaches that can happen from all the vulnerabilities which are listed in the project. And it also helps at the same time that how to fix that bug. How this bug can be avoided. All of these things are part of OVAS API security top 10 guide. And not just that, the project leaders keep on enhancing it. Where in API security testing guide, they start working on it. They are planning to merge it with application security testing guide. It's more of an add-on to it. So API security testing would be there. But then it will be an add-on to web application security. That applications are using APIs. But how to secure those APIs. How to find the bugs at the right time. Especially with the rise of APIs that we have seen. There's a huge amount of APIs. Even for a small function that we start using APIs. A small web app call. We start using it. So APIs when they expose application logic. And they contain so much of sensitive data. Like PII data. And there's so much other information when that's there. So it becomes evitable that we secure them. So this crucial project helps in understanding or making us understanding what role API plays in an application architecture. And how we can take help from the API security project to secure them. At the same time. How emergence of APIs. Especially specific issues related to them. Need to be considered into the radar. We cannot just avoid them. Now when we have something for APIs. When we have something for applications. Do we not need it for mobile. Because we all are working day in and day out on the mobile devices. So we need something for mobile devices as well. So there has to be something like a testing guide. Which should be there for mobile or mobile application security testing. Project leaders and everyone call it as mobile security testing guide MSTG. Which is an exhaustive list of testing procedures which contains Android, iOS and many other things. So it's like a complete detailed project on mobile security testing. So I would say I would recommend you to go back and check how it can help you in mobile security development of an application. So if you want to take a view this helps just with that. Another important aspect is that it also has a beautiful ASVS which is application security verification standard. Which has like step by step information. And an exhaustive checklist because now you have a big testing guide. And from the testing guide you tend to make a checklist. I did it. Trust me. I had no idea there is something called ASVS that exists way back. But now I would say that it's like a beautiful moon for me where and it is helping me in my own projects now also. And I recommend it to the developers. I recommend it to the functional testers who are actually working on all the ground work. So this really helps in mobile security. Another thing is how to automate everything. Now we are doing web application testing. We are doing the mobile security testing. But is there any tool that can help us in doing that? And that is an open source tool. So OWASP ZAP which is ZATAC proxy helps just with that. There are so many APIs which are available which we can integrate with the QA tools or functional testing tools like Selenium. Many other tools that can be integrated. And if we specifically want to call specific API from this tool, we can just do that. So ZAP really helps. And especially how it came into existence. My understanding like the project leaders, they were developers. Yes, you heard it right. They were not the security testers. They were developers. So they were facing a lot of issues with the application security testing and sometimes it becomes crazy. So they developed a project ZAP. And then now it's being used widely all over the world. And it has multiple test cases. You can create your own test cases and upload it on it. If I talk about myself, I also have created multiple test cases and I have uploaded on ZAP and I keep testing them. I make sure that I use it exhaustively for my pentest assignments. Apart from that, there's another project which is AMASP project. Now what is this AMASP project? You might not have ever heard it. So when I heard about it, I felt, oh, is something that exists? Wow. So AMASP project performs the network mapping of attack surface and it can also check for the external asset discovery. So if there are any assets which are outside the organization, we can actually figure them out using this open source information gathering and active reconnaissance technique, which it has. So it can actually use multiple search engines. It can use the SIEM tools. It can leverage APIs from multiple tools. It can also leverage and figure out web services. So it's amazing project which provides the reconnaissance technique. And once we have our application, we want to know that what are the components which are open source or which are on the internet. AMASP project is the project to go for it. And I would strongly recommend you just take a look at it. So you should actually take a look at this project. Now, once we have done that, we have got the requirements gathered. We have got the requirements gathered. Then we have done the threat modeling. We have done the source code review. We have done the software composition analysis. What else we have done? We have done the vulnerability testing. Now once that done, is there any place we can document as a startup or a person who is new to the industry and I don't have a paid commercial tool? So what should I do? Defect dojo has just with that. It's amazingly wonderful tool which actually documents the findings. It can be integrated with commercial tools as well. So when it documents the finding, it provides the severity levels. High, medium, low. And it keeps on popping it. If you can see on the right hand side, there is a beautiful graphical view that it provides, especially if you have to send a report to the management because leadership always looks for graphs report. They don't want to go to, okay, these are the 10 vulnerabilities that are there. These are these things which are there. So they look for numbers. They look for understanding, okay, these are the high level items that we need to address. So defect dojo is a tool that actually not only stored the findings, but also helps in streamlining our entire application security program. It simplifies vulnerability management by offering templates. So we can have our own templates. We can generate the report. We can have metrics. We can check if there are duplicate findings which were there in the past report and now it's coming up again. There's a baseline that we can set. We can find you in the project. The top goal for this project is to reduce the amount of security professionals which they take in logging vulnerabilities. So defect dojo addresses that because I have worked with the top notch pentesters and especially the people who worked for me, they were facing a lot of challenges in reporting it. Like reporting it in the tool. It's a big challenge. Like you have to copy paste this, that it's more of a job. Sometimes you feel this is not what I want to do. But this is an important task. If you don't log it, there's no point doing all of that. So defect dojo helps in template system which is like a template system for vulnerability. It can provide self-surface baseline tools. It can also import common vulnerability scanners. So if there is a scanner which is like callus, it can actually fetch the data from there, fetch the reports from there. And then generate the report based on the one that we require. It can provide the beautiful metrics which is like you can see that it provides a dashboard with a beautiful summary health check of the overall product or application security program. And once we have that because it's important to fix the bugs, we need to make sure that we have some defensive controls. Now, what are these defensive controls? Why do we need it? Because sometimes when we have all of it, we need open source defenses as well. Think about there's something which is placed in front of my application and it's helping me. So these defensive controls help just with that. So there are some of the defensive projects which I have mentioned. There are few projects which are under pipeline which you can just go to ovaas.org and you can get to know about them. So CSRF Guard is one of the projects which helps us in avoiding CSRF vulnerability cross-site request forgery because that had been a pain even though that's not part of Ovaas top 10 anymore but then it's still a problem with many, many applications. So CSRF Guard actually helps with that. And then another project is Ovaas Mod Security which is a set of generic attack detection rules for use with the mode security and it acts as a web application firewall. So core rule set main goal is to protect the web application from a wide range of attacks including the Ovaas top 10 with the minimum false alerts because if there's a web application firewall it sometimes actually generate a lot of false alarms. So it protects us from insecure web application design. So mode security sets, rule sets I would say can actually provide a layer of protection for web application such as WordPress, PHP VVV or any type of web application. It can actually potentially protect against vulnerability or vulnerable applications which are outdated or which are using the outdated components. It can also protect us against the generalized malicious traffic. We've seen that DDoS is like a big problem for any organization so it helps us with that and it can identify that this is a malicious traffic by using the mode security rule sets. Another important project which I never want to miss is proactive control. Now what this proactive control is that once we are developing an application or once we have this application developed we want to make sure that we are proactively monitoring it. So proactive controls helps with that wherein it provides a list of controls that developers, testers, security researchers need to know that these are the pointers like encode data verify for security early and often. All of this we should know and what are the frameworks and libraries we should be using if we are using a third party libraries when to secure it. So all of that proactive control emphasizing on that and it's the place to go for any of the developer I would say. So now once we have talked about once we know about proactive control what else we should be looking at. Now we have the proactive controls how about we train our developers, testers and even the people who are part of security. It's very very important to secure our applications because if we don't train our people we would be leaving so much behind. So what are the things that can help us? Is there any place where I can learn this? So OVAS WebGOT is one of the oldest project I would say one of the oldest project. That used to come in a CD and I have copied on my system and then started working on this particular project which has matured over the years. So OVAS WebGOT actually is a deliberately vulnerable web application where there are so many challenges which we can solve and we can fix the bugs. So it gives you a view that this vulnerability could be looking like this so it helps with that. Another project is Security Shepherd which I usually use in my trainings which I give. So this is like an exercise which you can see on the screen that yes it's a lesson and there's a scoreboard once you solve all of these things it becomes from cross to check and it provides an exhaustive list of all the test cases. There's a SQL injection that can be done multiple ways. It provides that there's a blank SQL injection. How does that happen? So it provides with that. So it builds a story around an application and helps us understanding the bugs. Another project is DevSlog which is more of a working project rather than a training project but this is still I would say it's a part of a learning which provides a view of application security, DevSecOps or DevOps with security in a working way that how this particular project can be used in the whole DevSecOps life cycle and how this particular project can be used could be in the source code review. So the team actually works real time on that through the live demos. There are failures that do happen. Even I was part of one of the session where I gave a session on dependency check and we were troubleshooting live. That okay, we downloaded dependency check. What next? How are we going to work with NVD database? How are we going to run the scan? Where are we going to put the jar files? Where are we going to pick the code? So everything we did live on the session. It's not like we are actually recording a video and then cutting it, whatever is the best shot, that should be there. No, they do it live. Failures do happen. They keep on implementing those new things. They keep on working on it. And all the sessions can be, you can see it on the OVAS project. Similarly, they have a Pixi which is a intentionally vulnerable API project which is an amazing project you should take a look at. So now, once we've talked about it, how can I leave juice shop which is like the most modern web application with all the relevant bugs and even I have used it for CTFs. You can use it for CTFs within the team as well. So I wanted to test, I wanted to showcase some of the test cases to one of the development team and even my team. So we used it as a project, as a CTF platform for the testing which has actually helped us a lot in finding and making the teams understand these are the bugs that exist in an application. So this really helps with that. Another thing is that when you go, so another thing is that when you go to juice shop it gives you a kind of feeling like a real application and then you start up exploiting it. So I really like the project and even the project leaders are super cool. They keep on adding new stuff in it. If you reach out to them, if you want to help them, help them in modifying some challenges or adding some new challenges, they're always open for it. So make sure that you reach out to them. Once we know about these projects, how about we go to the awareness item. Now we have talked about testing. How can we miss top 10 project? I am sure everybody of you knows, everyone knows that there's a flagship project, top 10. In any organization which wants to secure application security, they go through top 10. And they use top 10 as like a project which cannot be forgotten, which cannot be left behind. It acts as a framework. Okay, we have to make sure that top 10 bugs don't exist in an application or in our application. You must be thinking that I have covered so many things around application security, mobile security. And did I leave OAS top 10? No. So I have left it for the awareness session that we all should be aware that OAS top 10 exists. And every three to four years, there are new sets of top 10 cases which comes. And those are not done by OAS. It's done by community. It's done by the organization. The data comes from the organization. And then people work on it. Community work on it. Community share the feedback. Okay, these are the test cases that are there. Or these are the top 10 vulnerability. In every three years, you would see the shuffling happening. And past a few years, I would say, SQL injection has been on top. Which I would say that we all have to work together and make sure that that actually goes down. There are a few vulnerabilities which have taken a place like using components with open source or vulnerable components. Using components with known vulnerabilities, which is A9. Then XXC that has become a part of it, which is the A4, which is on the top four list. So it addresses all of that. Then there's another amazing project, which is the ASVS application security verification standard, which I've talked about in the beginning. So what it is. So the primary aim of OAS application security verification standard is to provide an application security platform, a standard for web apps and web services of all types. And my experience is like, I'm a big fan of checklist. And during my penetration testing time, when I was starting off from web testing guide, I created my own checklist. And then later I got to know that there is something called ASVS that exists. It was a bummer for me. So I thought, why don't I introduce it to you? OAS application verification standard has security controls, which has like four levels starting with the cursory, which is level zero. It goes to level one, which is opportunistic. Then it's standard level two, then becomes the advanced level three. And how it happens is like ASVS level one, which is for low assurance for applications, which are penetration testable. And then those are low severity application. Then level two is like the application that contains sensitive data, which requires protection in some form and is recommended level for most of the applications. Now, when it comes to level three ASVS, it is like the most critical applications. And applications that perform high value transactions, like banking, I would always recommend level three for them. So the standard provides the requirements and it gives you the good checklist in a form of a word, a CSV file and a PDF, which we can take it and go back and map it to our own organization, which we can use it in the requirements gathering, requirements mapping, even SKF, security knowledge frameworks, leverage is the same. Now, when we have mobile testing guide, why don't we have mobile top 10? So we do have mobile top 10, which is like the top 10 flaws in the mobile arena and mobile top 10 guide helps just with that. Similarly, like OAS ASVS, we have mobile ASVS, Mobile Application Security Verification Standard, which is coming up or which is there, but then it's getting matured, which provides the completeness for mobile application security testing. So it's important not to miss the privacy risks because for any organization, privacy is like a big concern. So another list is top 10 privacy risk, which is part of application security and this project aims to offer tangible tips on how to embed privacy in the design of web application and helps developer, security tester and everyone the consequences of these privacy risks. So these top 10 risks include web application vulnerabilities, operator site data leakage, insufficient data breach response, all of the privacy concerns that could be there, insufficient deletion or insufficient deletion or personal data, non-transparent policies. The data which is stored in an encrypted format, which is not required or the data which is required to be encrypted, that's not being stored in the encrypted format. So sharing of data with the third party, this addresses that because there have been breaches which have happened because of sharing the data with the third parties. Then missing or insufficient session expiration, insufficient data transfer. So all of that, it talks about it. Now when we have talked about all of this, how about avoiding all those automated bots, automated technologies which run on our application and make us part of the breaches? So automated threat management or automated threats to web application project helps us in understanding what are the automated threats which can be there for an application and it helps us in fixing all the automation bugs. So now what we have learned? We have gathered the requirements. We have done the threat modeling. We have done the source code analysis. We have done the software composition analysis. We have also done the vulnerability testing. Now once we have done all that, we have done the technical training. We have some defensive controls. We have vulnerable applications wherein we can just pick it up and start bombarding it rather than doing it on the actual live web application. So once we have added that, how about having a knowledge base of things which can help us? So application security and verification standard, I don't know why but it's so close to my heart that it fits all the places. Similarly, security knowledge frameworks. If as a developer I want to go back and understand, okay, I'm working on a go code. I'm working on a PHP or I'm working on R. Is there any place where I can just go and check if I use it in certain way? What could be the vulnerability on this application? So security knowledge frameworks is like a standard for multiple vulnerable code snippets and how to fix them. It helps in requirements gathering. It helps in threat modeling and many other things. And ASVS or application security verification complements that beautifully. Then another important project is snake and ladders. Now, what is snake and ladders? And why are we talking about an application security program? So snake and ladder is an educational application security awareness game. So this is a board game for understanding the behaviors where a virtuous behavior is ladder. Then secured coding practices are OAS proactive controls and the vices or snakes are application security risk. So why are we picturizing it? So this is a board game which generally is being played in Asia where if a snake bites, you will come down. Similarly, if you have an application security risk, your application might be part of a breach or your application might be at risk. So it's talk about just that. Another educational program or a project is cornucopia. Because there are sometimes where if we want to make developers, program managers, security testers, understand why we need agile in security platform. Why we need agile or DevOps in an application security program. Cornucopia helps with a card game. We all are working remotely and we might need something to play to. So play for. So this project helps with that. Which is a project which is a fun game wherein we can play online and I've ordered my card, which I'm yet to receive. And it's a beautiful bundle of cards which I'm going to play with my developers and make them understand. Okay, these are the challenges that we can address by using these things. So I have been talking about all of it. But is there one place where I can see all the projects? So this is the slide that I wanted to showcase. This is the framework which contains every project, which contains every project that I've just told you. Starting with requirements gathering till the training and awareness and how it can help. And all of these slides will be available to you and you can leverage it at any point of time. But there comes a point when how can you contribute to these projects? Because these are all open source community-driven. So you can contribute to the code. If you feel that there is something which you can add it to any of the project, please do. But if you want to help in writing test cases, helping curated the content, please do help. Sometimes not enough time wherein we can write the documentation. If you want to help with the documentation, please do help the project leaders. You can help. Also, if nothing can be possible, how about promoting a project which is close to your heart? There are so many projects which are close to my heart and keep talking about them. So you can actually talk about them. You can suggest some features. You can report the bugs. And actually project leaders work on them. You can just make a pull request, make suggestions and they do work on it. Then how do we move forward? Is there anything else that I can do with OWASP or OWASP projects or if I want to be part of the bigger community? So OWASP.org is the place where you can go and look for the projects nearby, chapters nearby and projects are there. All the project, even detailed information, I just touched upon it. You can actually get the detail view of it. So OWASP.org is the place to go. Then you can also join the nearest chapter. Like in Bangalore, I'm in India. Bangalore has a chapter. Delhi has a chapter. Pune has a chapter. Urisa has a chapter. So I'm sure if you are in any part of the world, OWASP has a chapter. And if there is no chapter now, if you want to start a community, do go for it. You can raise a request on the OWASP.org page. The team will work on it and provide you with the right information, sources and help you in getting the chapter created in your area. Even if you are a student and you want to create a chapter in your college. So there are student chapters which are there. So you can be a student leader and help in your college in getting started. So if you feel that you're not part of the community, you can be part of the community. You just have to step up and ask for help. And everyone will be there to help you. And the one thing that I've actually received from the security community is that the peeps are so helpful, so warm, and I've learned a lot. And that's one I'm able to contribute. What you can do is you can reach me if you have any feedback, if you have any questions around the stock. Or if you want to discuss about something, you can reach me here. So we are going to take question answers now. Thank you so much. And please feel free to reach me anytime. This is Namaste, which is the form of a greeting. And thank you or a goodbye.