WEBVTT 00:14.430 --> 00:16.230 Welcome back to AppSec Village. 00:16.230 --> 00:18.170 We've made it to the end of the third day. 00:18.170 --> 00:23.630 The next talk will be the final talk for AppSec Village for DEF CON 2020. 00:23.830 --> 00:32.990 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. 00:32.990 --> 00:34.490 This is our second year. 00:34.490 --> 00:36.070 It's been a phenomenal year. 00:36.070 --> 00:42.870 The team has done a great job with very unique circumstances as we look around the world right now. 00:42.870 --> 00:47.710 So if you have a minute, jump out to AppSec Village, hit them up on Twitter, and just say thanks. 00:47.710 --> 00:55.490 Because they put in a lot of work trying to get this done in a short amount of time under really, really weird circumstances. 00:55.490 --> 00:57.210 So thanks organizers. 00:57.210 --> 00:58.770 Thanks all the volunteers. 00:58.850 --> 01:00.690 Thank you to all of our speakers. 01:00.770 --> 01:05.070 It's been a fun run, and I cannot wait to do this again next year. 01:05.070 --> 01:09.650 With that, let's talk about our final speaker for this year's DEF CON. 01:09.650 --> 01:17.950 The final topic is going to be Running an AppSec Program with Open Source Projects by Vandana Verma Sehgal. 01:17.950 --> 01:26.590 Vandana is a seasoned security professional with experience ranging from application security to infrastructure, and now dealing with DevSecOps. 01:26.590 --> 01:38.690 She has been a keynote speaker, a speaker, and a trainer at various public events, ranging from global OWASP AppSec events, to Black Hat, to regional events like B-Sides events in India. 01:38.690 --> 01:41.890 She is part of the OWASP Global Board of Directors. 01:41.890 --> 01:48.850 She also works in various communities towards diversity initiatives, including InfoSec Girls, WOSEC, and NULL. 01:49.310 --> 02:03.350 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. 02:03.350 --> 02:09.990 Please welcome to the AppSec Village stage, one more time, for Vandana. 02:13.280 --> 02:16.040 Hi everyone, thanks for joining the session today. 02:16.040 --> 02:21.160 Today we are going to talk about how to run an AppSec Program with Open Source Projects or OWASP Projects. 02:21.260 --> 02:27.360 We can also say that how to build an AppSec Program in an organization. 02:27.500 --> 02:30.780 We are all heading toward modernization of applications. 02:30.780 --> 02:37.160 We are all trying to use microservices, application programming interface, or APIs. 02:37.160 --> 02:40.700 However, we still see that the breaches are happening. 02:40.700 --> 02:47.840 And the breaches are happening because of SQL injection, sensitive data exposure, or security misconfiguration. 02:47.960 --> 02:52.010 There's a big gap which our industry is grappling. 02:52.460 --> 03:01.200 Organizations who want to set up an AppSec Program, especially from scratch, using open source tools, they have no idea where to start off. 03:01.200 --> 03:06.500 They need a security program which they can pick up and go ahead and start using it. 03:06.660 --> 03:14.280 OWASP has many projects which can tie seamlessly into the application security pipeline or application security program. 03:14.460 --> 03:18.660 However, firstly, we don't know whether they exist. 03:18.700 --> 03:22.080 Or when they exist, we don't know how to use them. 03:22.140 --> 03:24.960 So, there is a big problem lying out there. 03:24.960 --> 03:32.180 With this talk, I'm going to talk about how we can set up the AppSec Program using open source projects. 03:32.180 --> 03:43.400 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. 03:43.400 --> 03:48.400 In the end, how we can start contributing to these projects. 03:48.400 --> 03:54.240 Because it's very important to understand about these projects, and how we all can help with these projects. 03:54.240 --> 04:01.020 Another important aspect is that there are students who actually want to be part of application security. 04:01.020 --> 04:05.260 There are so many people who ask these questions, that how can I get into application security? 04:05.260 --> 04:11.740 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. 04:11.740 --> 04:13.920 How can I get into application security? 04:13.980 --> 04:23.860 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. 04:25.440 --> 04:30.740 So, before I deep dive into the presentation, I want to talk a bit about myself. 04:30.760 --> 04:32.280 I'm Vandana Verma Sehgal. 04:32.280 --> 04:35.720 My day job is with one of the multinational companies in India. 04:35.800 --> 04:43.420 And apart from that, I root for ProOne Work, and I work with OWASP, which is Open Web Application Security Project. 04:43.680 --> 04:46.900 I'm one of the global board of directors for OWASP. 04:46.900 --> 04:50.380 Apart from that, I also work with Diversity Initiatives. 04:50.380 --> 04:53.120 I am the president for InfoSec Girls. 04:53.120 --> 04:56.060 I have few noted at multiple conferences. 04:56.480 --> 04:58.360 Now, coming back to the topic. 04:58.420 --> 05:00.640 So, this is the framework which I was talking about. 05:00.640 --> 05:08.920 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. 05:08.920 --> 05:13.740 All of these things are really, really necessary when we are setting up an AppSec pipeline. 05:13.960 --> 05:20.100 So, students can have their own projects, and they want to build the whole pipeline. 05:20.100 --> 05:29.060 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. 05:29.200 --> 05:40.560 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? 05:40.560 --> 05:45.140 So, these are some basic components which I felt that we all should have in an organization. 05:45.400 --> 05:47.840 So, that's what I put in here. 05:47.840 --> 06:05.600 Let me start with a framework, that how we actually can take ahead of this framework and address all the loopholes in application security, especially about legacy applications, desktop applications, mobile, web applications, microservices, which are exploited these days. 06:05.600 --> 06:13.120 Now, cybercriminals can gain entry into an organization system and steal confidential data if we don't secure our systems. 06:13.380 --> 06:16.200 And this is a fact that breaches will happen. 06:16.200 --> 06:17.300 They are inevitable. 06:17.300 --> 06:19.880 And security flaws will exist. 06:19.880 --> 06:22.020 There's nothing which is 100% secure. 06:22.020 --> 06:25.540 However, what we can do is, we can minimize the chances. 06:25.800 --> 06:28.700 This is when the AppSec program comes into picture. 06:28.720 --> 06:34.760 And this is when I thought that, okay, how about let's use the OWASP projects and get started with this framework. 06:34.800 --> 06:47.060 So, one of the first thing that we need to understand is that we need to have an AppSec program, because if the organization doesn't feel that they need to have an AppSec program, the framework will never going to help us. 06:47.720 --> 06:55.600 So, we need to have an inventory that these are the applications that we have, or these are the applications we are going to build. 06:55.760 --> 07:03.460 So, with requirements gathering, first we need to have the requirements gathered, that these are the things that we need in an application. 07:03.460 --> 07:06.580 These are the applications that we have. 07:06.680 --> 07:09.020 Everything needs to be noted down. 07:09.020 --> 07:10.240 But where? 07:10.620 --> 07:13.440 Are we going to have some place where we can list down? 07:13.440 --> 07:15.340 Okay, these are the things that we have. 07:15.340 --> 07:21.260 And on those things, we are going to decide, okay, yes, this is our plan. 07:21.640 --> 07:33.340 So , OWASP Security RAT, Requirements Automation Tool, is an amazing project, which actually can help in automating the security requirements, especially during the development phase. 07:33.420 --> 07:43.240 Now, when we have simplified automated requirement gathering, it streamlines the whole process, because that's where the organization starts off. 07:43.720 --> 07:53.780 Now, apart from that, there's another beautiful project, which is OWASP Security Knowledge Framework, which is a big, exhaustive project in itself. 07:55.240 --> 07:59.580 It's kind of an ocean, wherein you have everything. 07:59.580 --> 08:01.820 You can note down the requirements. 08:01.820 --> 08:07.180 There's a proper medium wherein you have a lot of requirements mentioned. 08:07.180 --> 08:11.060 On top of it, you can mention your own requirement. 08:11.060 --> 08:17.920 And based on those requirements, we can define, we can figure out that what's the severity of an application. 08:17.920 --> 08:21.480 We can map it with application security verification standard. 08:21.480 --> 08:28.000 We can define the maturity of our application, our organization application security program. 08:28.000 --> 08:34.900 It provides a beautiful layout with best practices which developers can use. 08:34.900 --> 08:41.720 So, when we have RAC for automation and Security Knowledge Framework, we can gather the requirements very well. 08:41.720 --> 08:46.600 Because if we don't gather the requirements very well, we would never be able to secure application. 08:46.600 --> 08:51.100 Or we would never be able to build an application which is secure enough. 08:51.100 --> 08:57.620 So, first we need to have our own requirements noted down somewhere with the right medium. 08:58.600 --> 09:00.420 Then, once we have... 09:00.420 --> 09:03.440 Okay, these are the things that we need in an application. 09:03.440 --> 09:05.900 We need to threat model our application. 09:06.140 --> 09:10.640 Likewise, if we already have an application, we are going to build a feature. 09:10.740 --> 09:14.720 That time also we need to have a proper threat modeling in place. 09:14.720 --> 09:16.260 But how to do the threat modeling? 09:16.260 --> 09:18.780 It's like, it's a kind of a jargon. 09:18.780 --> 09:23.000 It's a kind of a technical term which we all have been talking about. 09:23.000 --> 09:26.460 But we don't understand, okay, how to go about it. 09:26.460 --> 09:28.200 Not everyone work on threat modeling. 09:28.200 --> 09:30.380 But it's actually a simple one. 09:30.380 --> 09:33.640 We can now use threat modeling as a code. 09:33.720 --> 09:37.040 We can use the tools like Threat Dragon. 09:37.120 --> 09:43.620 When you put all the details in it, it provides a beautiful graphical overview. 09:43.620 --> 09:46.220 Okay , these are the things that you have. 09:46.380 --> 09:48.620 And this is your application. 09:48.700 --> 09:54.800 So, I'm going to tell you whether it's a high severity application, medium severity application or a critical application. 09:55.300 --> 09:59.920 And if something happens to an application, what will be the impact? 09:59.920 --> 10:07.120 So, Threat Dragon provides a beautiful view of threat modeling, how we can threat model our application. 10:07.180 --> 10:18.160 Similarly, PyTM, which is a Pythonic framework for threat modeling, which is a beautiful and amazing data flow diagram project. 10:18.160 --> 10:24.200 Now, sometimes we don't understand, okay, the pieces are scattered everywhere. 10:24.200 --> 10:30.060 Now, if we have a flow chart, okay, now this is the thing where we are heading left. 10:30.240 --> 10:33.000 If we are right, we are going to go left. 10:33.460 --> 10:36.900 And if there is a problem, we should be stopping on the right side. 10:36.900 --> 10:43.080 So, with an amazing flow diagram, PyTM helps us in the threat modeling. 10:43.640 --> 10:49.580 So, all the details I've mentioned, okay, this is how the diagram looks like, if you can see on the right side. 10:49.580 --> 10:55.860 And it is like sequence by sequence, analyze the application and give you the result. 10:56.020 --> 11:00.140 And where you can find it, you can find it on this particular project's page. 11:00.140 --> 11:09.820 And you can look through it, you can understand there are so many resources which are available for you to guide how you can get started with it. 11:09.820 --> 11:15.480 Because I'm going to talk about many projects in this particular talk and giving you overview on it. 11:15.480 --> 11:17.340 Okay, this project does this. 11:17.340 --> 11:22.500 Because while I was learning about OWASP projects, few projects I knew. 11:22.500 --> 11:26.940 But there were few projects which I wanted to understand when I was building up this framework. 11:26.940 --> 11:31.400 So, I realized I had a different understanding of these projects. 11:31.400 --> 11:34.760 I thought, okay, this project was this. 11:34.760 --> 11:43.360 But when I actually researched through it, over the years, the projects have actually enhanced a lot. 11:43.360 --> 11:46.780 So, the project working, I'm going to talk about. 11:47.640 --> 11:52.760 So, once we have done the requirements gathering, we have done the threat modeling. 11:52.760 --> 11:56.540 Now we know, okay, this is the thing that we have in an organization. 11:56.600 --> 11:59.960 These are the requirements we are building up in an application. 11:59.960 --> 12:04.320 Or this is a new application which we are completely building from scratch. 12:04.600 --> 12:08.300 So, once we have that, we are going to work on the code. 12:08.300 --> 12:14.460 Now, when we are going to work on the code, we need to have the code which is securely developed. 12:14.460 --> 12:28.480 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. 12:28.480 --> 12:30.160 Or even earlier than that. 12:30.160 --> 12:33.140 Like in the requirements gathering, we start talking about security. 12:33.140 --> 12:34.860 Or even threat modeling. 12:35.060 --> 12:43.080 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. 12:43.660 --> 12:51.140 So, code review checklist is like an amazing checklist which provides, okay, these are the things that should be fixed in a code. 12:51.220 --> 12:53.620 These are the things that can be guided in. 12:53.820 --> 12:57.940 We can actually build our own checklist on top of it. 12:57.940 --> 12:59.260 Like for source code review. 12:59.260 --> 13:04.760 I have built my own checklist on top of the ones that have been provided by the code review checklist. 13:04.780 --> 13:08.820 Similarly, there is another project which is code first project. 13:08.820 --> 13:16.660 Which is a project which helps in finding the code which might be left behind. 13:16.660 --> 13:19.880 Or which we might have left at some point. 13:19.880 --> 13:26.340 So, a continuous challenge with any penetration testing or even in code review. 13:26.340 --> 13:30.040 That we don't know whether we have covered everything or not. 13:30.040 --> 13:32.500 Whether we have covered the whole application or not. 13:32.500 --> 13:36.600 So, it's purely a black box perspective. 13:36.600 --> 13:46.640 Which actually makes it almost impossible to accurately identify how much of the code or an application attack surface that has been tested. 13:46.640 --> 13:55.820 So, code first is actually a glass box tool that provides the insight into the real-time code coverage of penetration testing. 13:55.820 --> 13:58.440 All the activities that are being done. 13:58.440 --> 14:03.600 So, it automatically detects the coverage information with the test being conducted. 14:03.660 --> 14:10.740 And will even make it possible to understand the overlap and the boundaries of different tools coverage. 14:10.980 --> 14:15.600 So, code first presents the coverage information in a visual form. 14:15.600 --> 14:17.120 If you can see on the right. 14:17.160 --> 14:19.300 So, this is how it provides. 14:19.300 --> 14:21.900 Wherein you have a beautiful view. 14:21.900 --> 14:24.440 Okay, these are the things that have been covered 60%. 14:24.440 --> 14:27.260 These are the things that have been covered 90%. 14:27.260 --> 14:33.980 So, the real coverage or real-time coverage feedback makes it easy to adjust the testing activity. 14:33.980 --> 14:36.680 Especially based on the observed coverage. 14:37.240 --> 14:41.640 In addition to those testing activities which are relying on multiple techniques. 14:41.920 --> 14:48.880 It's easy to split up the recorded activity to independently and alternatively understand the overlap. 14:48.880 --> 14:50.420 Between multiple tools. 14:50.420 --> 14:54.220 Because we have so many tools from which we test an application. 14:54.220 --> 14:58.040 So, CodePulse really helps us with that. 14:58.040 --> 15:02.340 Now, we have understood that this is what we have done with the code review. 15:02.340 --> 15:10.780 But how about a specially designed code review checklist or practice guide for a certain code. 15:10.780 --> 15:11.900 Like GoCode. 15:11.900 --> 15:15.220 GoCode, I started learning a couple of years back. 15:15.220 --> 15:19.700 But before that, it was like a completely new arena for me. 15:19.700 --> 15:23.460 And then came up OWASP Go Secure coding project. 15:23.460 --> 15:26.620 Which helped me in understanding, okay, this is a Go language. 15:26.620 --> 15:29.420 And this is how we can securely code it. 15:29.440 --> 15:36.420 So, Go Secure Code is another incubator project which can help us in understanding the basics. 15:36.960 --> 15:39.860 That how to secure GoCode. 15:40.320 --> 15:44.780 Another beautiful checklist is the cheat sheet series. 15:44.780 --> 15:50.140 This cheat sheet series helped me a lot, I would say. 15:50.140 --> 15:56.080 Because this provides an amazing overview that this is a vulnerability. 15:56.080 --> 16:01.000 This is how an attacker can exploit it if we don't fix it. 16:01.000 --> 16:03.800 And then remediation procedures. 16:03.800 --> 16:06.160 It's a beautiful checklist. 16:06.560 --> 16:12.700 And it has actually catered and helped me in multiple projects in my multiple organizations. 16:12.700 --> 16:16.120 So, if you look through it, it's a beautiful document. 16:16.120 --> 16:18.680 And there's a beautiful documentation around it. 16:18.680 --> 16:21.940 For so many vulnerabilities, for so many controls. 16:22.400 --> 16:24.900 It is an exhaustive list. 16:24.900 --> 16:32.940 Starting from input validation, to cross-site scripting, to xxe, to indirect object reference, to any other vulnerability you talk about. 16:33.100 --> 16:34.960 It has the details. 16:35.060 --> 16:37.780 So, you should actually take a look at this cheat sheet series. 16:37.780 --> 16:43.760 And every time I look at it, I actually feel that I'm more connected to it. 16:43.760 --> 16:49.600 I really fell in love with this cheat sheet series, the new one that has been developed by the team. 16:49.600 --> 16:54.340 Or the remodeled website which is there for the cheat sheet series. 16:54.640 --> 17:03.500 Another important aspect is, when we have worked on the code review, and we tend to miss software composition analysis. 17:03.500 --> 17:07.780 Which we have seen that there are breaches which have happened in the past. 17:07.780 --> 17:08.960 Like Equifax. 17:09.120 --> 17:13.320 Those happened because of using the components with known vulnerabilities. 17:13.720 --> 17:15.780 Or there were projects which were in use. 17:15.780 --> 17:22.880 There were open source code which were in use, but we missed to update the code. 17:22.880 --> 17:24.980 There were so many reasons. 17:25.300 --> 17:30.560 So, when we know these things are there, why don't we fix it? 17:30.560 --> 17:31.820 But how to fix it? 17:31.820 --> 17:32.940 It's a big challenge. 17:32.940 --> 17:43.340 I was actually going through one of the research paper wherein white source has quoted that 96.5% code on the internet is all open source. 17:43.440 --> 17:46.160 That's a huge amount of code. 17:46.200 --> 17:52.060 When almost all the code on the internet is open source, what can go wrong? 17:52.260 --> 17:58.180 Which means, can we say that everything which is lying over there, which we are using is all secure? 17:58.180 --> 17:58.840 No. 17:58.840 --> 18:01.860 If that's the case, then breaches wouldn't have happened. 18:01.860 --> 18:03.680 Why the breaches are happening? 18:03.960 --> 18:11.840 So, to reduce that, we have started understanding that we should have software composition analysis wherein we are scanning our code base. 18:11.880 --> 18:17.160 But is it too easy to buy a software composition analysis tool? 18:17.640 --> 18:19.660 We just go ahead and buy it? 18:19.720 --> 18:26.100 I am not against the tools, but I am in no support of buying a tool in the first place. 18:26.300 --> 18:30.180 You are just saying that you want this and you are going ahead with the tool. 18:30.180 --> 18:32.480 So, what else can we do? 18:32.480 --> 18:34.480 Is there any project by OWASP? 18:34.480 --> 18:35.260 Yes. 18:35.260 --> 18:41.480 So, OWASP has dependency check, which is called DC, people call it as. 18:41.480 --> 18:50.560 So, dependency check, this is an open source component, which is now an integral part of many organizations. 18:50.620 --> 18:55.520 And it helps in checking or scanning open source components. 18:55.520 --> 18:57.280 So, why it helps? 18:57.280 --> 19:03.720 Because now, as I mentioned that open source components have become an integral part of software development. 19:03.720 --> 19:14.180 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. 19:14.240 --> 19:16.460 Or the breaches will keep happening. 19:16.460 --> 19:27.560 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. 19:27.560 --> 19:31.500 We are keeping a record, okay, these are the libraries which exist. 19:31.700 --> 19:34.100 So, how should we do that? 19:34.140 --> 19:36.840 Are we going to just go ahead and buy a tool as I said? 19:36.840 --> 19:39.880 No, I am not going to do that. 19:39.880 --> 19:53.940 The increasingly widespread use of open source components have actually taken us to a way wherein 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. 19:54.180 --> 20:05.880 So, we need to understand that throughout the development process, the software products that we are developing or we are creating, we need to maintain them. 20:05.880 --> 20:10.660 We cannot just think that, okay, we have developed a product and we are good. 20:10.720 --> 20:13.180 We need to actually keep updating it. 20:13.180 --> 20:16.460 But how to keep a track of all the third party components? 20:16.460 --> 20:36.300 OWASP Dependency Checker actually helps or resolves these concerns for developers which identifies project dependencies and checks if there is any in the code or if there is a publicly disclosed vulnerability in the code as part of open source component. 20:36.300 --> 20:43.300 Now, how good it is or how bad it is or how heavy is this? 20:43.300 --> 20:47.380 Because all the tools that I have been working on, they are so heavy. 20:47.760 --> 20:55.680 So, to put it this way, OWASP Dependency Check is the lightweight and very easy to download, install and run component or a tool. 20:55.720 --> 21:01.560 So, when I downloaded it for the first time, it took me some time to download the NVD database. 21:01.760 --> 21:03.580 However, after that, it was a Delta scan. 21:03.580 --> 21:05.540 So, it was like a very quick scan. 21:05.540 --> 21:09.200 So, the scanning process is seamless. 21:09.580 --> 21:16.180 When we are scanning the code, it finds out, okay, these are the third party components we have in the tool. 21:16.380 --> 21:19.080 And these are the products. 21:19.080 --> 21:20.460 This is the version. 21:20.460 --> 21:25.740 And we have to fix this particular version if there is a vulnerability that exists. 21:25.820 --> 21:35.520 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 lifecycle. 21:35.520 --> 21:40.770 We can integrate with Jenkins, which can allow us to integrate with the CI-CD pipeline. 21:41.400 --> 21:58.920 So, apart from that, we also have OWASP Dependency Check, which is an intelligent supply chain management or component analysis project or a platform that allows organizations to identify and reduce risk from the third party early in the lifecycle. 21:58.920 --> 22:10.300 And this can also help us in tracking the application, tracking the libraries, tracking the frameworks that we are using, operating systems and hardware components. 22:10.300 --> 22:11.860 It's like a huge list. 22:11.860 --> 22:14.160 Apart from that, what else it helps us? 22:14.160 --> 22:25.180 It helps us in identifying multiple risk areas like component with known vulnerabilities, out-of-date components, modified components, license risks. 22:25.780 --> 22:28.380 Then there are many other things which are coming soon. 22:28.380 --> 22:34.760 So, it includes a comprehensive auditing workflow for triggering results. 22:34.760 --> 22:41.160 Because once we have scanned it, if we don't have a proper result, obviously we are going to suffer it. 22:41.160 --> 22:44.380 So, once we figured that out, we need to have the results. 22:44.520 --> 22:50.040 And not just that, it is very simple to configure as well. 22:50.040 --> 22:53.780 Because configuring a tool is like a nightmare sometimes. 22:53.780 --> 23:03.280 I've been in the 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. 23:03.280 --> 23:07.760 So, I know sometimes it's like pain to configure a tool. 23:07.760 --> 23:10.560 So, this is like a pretty easy to configure project. 23:10.620 --> 23:14.000 And we can go ahead and get started with the bigger projects. 23:14.300 --> 23:17.420 Now, we have gathered the requirements. 23:17.620 --> 23:20.020 We've done the threat modeling. 23:20.020 --> 23:22.640 We've done the source code review. 23:22.640 --> 23:23.680 What else we have done? 23:23.680 --> 23:26.120 We've done the software composition analysis. 23:26.300 --> 23:28.080 So, what else is pending? 23:28.460 --> 23:29.840 Vulnerability testing. 23:29.840 --> 23:35.300 When I started in the industry, we were doing very less of a code review. 23:35.580 --> 23:37.980 Leave the software composition analysis. 23:38.020 --> 23:40.860 We were just doing the vulnerability assessment and we are good. 23:40.880 --> 23:45.220 And I have been an evil person in the project team. 23:45.220 --> 23:49.600 Where if there was a critical vulnerability, I have stopped the releases. 23:49.600 --> 23:51.260 But then over the year, we all grow. 23:51.260 --> 23:52.220 We in the industry grow. 23:52.220 --> 23:56.440 We understand, okay, stopping a release is never going to answer us. 23:56.560 --> 23:59.640 So, we need to go through all the life cycle. 23:59.640 --> 24:01.300 How about we start early? 24:01.300 --> 24:02.300 We shift left. 24:02.300 --> 24:03.440 And that's where we are. 24:03.440 --> 24:05.100 We are all shifting left. 24:05.480 --> 24:07.200 We are talking about it. 24:07.500 --> 24:13.300 So, now in the vulnerability testing, what are the things we cater to? 24:13.300 --> 24:16.400 Like, what exactly we can use? 24:16.400 --> 24:19.300 Or how exactly we can perform a vulnerability testing? 24:19.300 --> 24:22.640 We've been doing, okay, most of the aspects we must be knowing. 24:22.640 --> 24:23.500 I'm sure. 24:23.500 --> 24:28.480 But then how about using the open source project for that? 24:28.580 --> 24:31.320 So, let me go ahead and get to it. 24:31.320 --> 24:34.520 So, this one, I'm sure you must be aware about it. 24:34.520 --> 24:37.520 Web Application Security Testing Guide. 24:37.820 --> 24:43.600 Which is an exhaustive guide on how to start an application security testing. 24:43.600 --> 24:46.300 Robots.txt file. 24:46.320 --> 24:47.820 What is crawling? 24:47.820 --> 24:49.260 What is spridering? 24:49.260 --> 24:51.200 What is STLC? 24:51.220 --> 24:52.860 Software Development Life Cycle. 24:52.860 --> 24:55.220 Everything in detail. 24:55.320 --> 24:58.640 If there is a flaw, information gathering. 24:58.920 --> 25:01.420 Everything summarizing it. 25:01.420 --> 25:03.660 Like, okay, this is what it is. 25:03.820 --> 25:10.300 Then, if this has a problem, what will be the vulnerability? 25:10.440 --> 25:14.280 Once the vulnerability is there, how to remediate it? 25:14.280 --> 25:18.320 I've created a presentation on how to implement a web security testing guide. 25:18.320 --> 25:20.360 You can actually look through it. 25:20.360 --> 25:26.040 So, which provides a good detail about how to use the web security testing guide. 25:26.040 --> 25:27.540 And it will help you. 25:27.540 --> 25:28.360 Trust me. 25:28.360 --> 25:30.680 It's an amazing guide. 25:30.700 --> 25:35.180 So, when I was introduced to OWASP, this was the first thing I was introduced to. 25:35.180 --> 25:37.840 There's a web security testing guide which exists. 25:37.860 --> 25:39.920 And I should start using it. 25:39.920 --> 25:46.240 And that's where my journey in detail in application security testing started off. 25:46.240 --> 25:51.620 Now, when application security testing guide is there, we're talking about applications. 25:51.740 --> 25:55.400 But in the beginning, I mentioned that we're all talking about modernization. 25:55.400 --> 25:58.520 We're all talking about using APIs. 25:58.520 --> 26:04.780 So, when all of these things are there, how to make sure that we are using them correctly? 26:05.060 --> 26:07.780 And there's no flaw in them. 26:07.780 --> 26:13.520 So, OWASP API Security Top 10 answers just that. 26:13.520 --> 26:26.060 Wherein, 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. 26:26.360 --> 26:31.460 And it also helps at the same time that how to fix that bug. 26:31.460 --> 26:34.620 How this bug can be avoided. 26:34.620 --> 26:39.580 All of these things are part of OWASP API Security Top 10 Guide. 26:39.580 --> 26:44.100 And not just that, the project leaders keep on enhancing it. 26:44.100 --> 26:48.700 Wherein, API Security Testing Guide, they start working on it. 26:48.700 --> 26:52.420 They are planning to merge it with the Application Security Testing Guide. 26:52.880 --> 26:55.960 It's more of an add-on to it. 26:56.040 --> 26:58.200 So, API Security Testing would be there. 26:58.200 --> 27:02.480 But then, it will be an add-on to Web Application Security. 27:02.480 --> 27:04.980 Applications are using APIs. 27:04.980 --> 27:07.580 But how to secure those APIs? 27:07.580 --> 27:10.900 How to find the bugs at the right time? 27:10.900 --> 27:14.440 Especially with the rise of APIs that we have seen. 27:14.440 --> 27:16.060 There's a huge amount of APIs. 27:16.060 --> 27:19.380 Even for a small function, we start using APIs. 27:19.380 --> 27:22.440 A small web app call, we start using it. 27:22.440 --> 27:26.820 APIs, when they expose application logic. 27:26.820 --> 27:30.760 And they contain so much sensitive data. 27:31.320 --> 27:32.840 Like PIR data. 27:33.560 --> 27:37.720 And there's so much other information when that's there. 27:37.720 --> 27:40.360 So, it becomes evitable that we secure them. 27:40.360 --> 27:50.420 So, this crucial project helps in understanding or making us understand what role API plays in an application architecture. 27:50.420 --> 27:56.280 And how we can take help from the API Security Project to secure them. 27:56.280 --> 28:06.640 At the same time, how emergence of APIs, especially specific issues related to them, need to be considered into the radar. 28:06.640 --> 28:09.220 We cannot just avoid them. 28:10.320 --> 28:17.360 Now, when we have something for APIs, when we have something for applications, do we not need it for mobile? 28:17.360 --> 28:22.000 Because we all are working day in and day out on the mobile devices. 28:22.000 --> 28:24.900 So, we need something for mobile devices as well. 28:24.900 --> 28:32.920 So, there has to be something like a testing guide which should be there for mobile or mobile application security testing. 28:32.920 --> 28:37.220 Project leaders and everyone call it as Mobile Security Testing Guide, MSTG. 28:37.220 --> 28:45.440 Which is an exhaustive list of testing procedures which contains Android, iOS, and many other things. 28:45.440 --> 28:51.120 So, it's like a complete detailed project on mobile security testing. 28:51.120 --> 29:02.520 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. 29:02.540 --> 29:07.880 So, if you want to take a view, this helps just with that. 29:07.880 --> 29:21.720 Another important aspect is that it also has a beautiful ASVS which is Application Security Verification Standard which has step-by-step information and an exhaustive checklist. 29:21.720 --> 29:24.020 Because now you have a big testing guide. 29:24.340 --> 29:26.980 And from that testing guide, you tend to make a checklist. 29:26.980 --> 29:27.800 I did it. 29:27.800 --> 29:32.940 Trust me, I had no idea there is something called ASVS that exists way back. 29:33.320 --> 29:44.260 But now I would say that it's like a beautiful moon for me where it is helping me in my own projects now also. 29:44.480 --> 29:46.740 And I recommend it to the developers. 29:46.740 --> 29:53.240 I recommend it to the functional testers who are actually working on all the groundwork. 29:53.240 --> 29:56.440 So, this really helps in mobile security. 29:56.940 --> 29:59.880 Another thing is how to automate everything. 29:59.880 --> 30:01.780 Now we are doing web application testing. 30:01.780 --> 30:05.200 We are doing the mobile security testing. 30:05.200 --> 30:08.320 But is there any tool that can help us in doing that? 30:08.320 --> 30:10.060 That is an open source tool. 30:10.120 --> 30:14.580 So, OWASP ZAP, which is Z-Attack Proxy, helps just with that. 30:14.580 --> 30:22.940 There are so many APIs which are available which we can integrate with the QA tools or functional testing tools like Selenium. 30:22.940 --> 30:25.100 Many other tools that can be integrated. 30:25.280 --> 30:32.140 And if we specifically want to call a specific API from this tool, we can just do that. 30:32.140 --> 30:34.160 So, ZAP really helps. 30:34.160 --> 30:36.600 And especially how it came into existence. 30:36.600 --> 30:42.520 The project leaders, they were developers. 30:42.520 --> 30:43.940 Yes, you heard it right. 30:43.940 --> 30:45.300 They were not the security testers. 30:45.300 --> 30:46.780 They were developers. 30:47.120 --> 30:51.600 So, they were facing a lot of issues with the application security testing. 30:51.600 --> 30:53.560 And sometimes it becomes crazy. 30:53.560 --> 31:01.060 So, they developed a project, ZAP, and now it's being used widely all over the world. 31:01.060 --> 31:04.980 And it has multiple test cases. 31:04.980 --> 31:09.020 You can create your own test cases and upload it on it. 31:09.040 --> 31:13.340 If I talk about myself, I also have created multiple test cases. 31:13.340 --> 31:15.040 And I have uploaded on ZAP. 31:15.040 --> 31:17.020 And I keep testing them. 31:17.100 --> 31:21.620 I make sure that I use it exhaustively for my pen test assignments. 31:21.880 --> 31:25.920 Apart from that, there's another project which is AMAS project. 31:25.920 --> 31:27.620 Now, what is this AMAS project? 31:27.620 --> 31:29.940 You might not have ever heard it. 31:29.940 --> 31:34.200 So, when I heard about it, I felt, oh, there's something that exists. 31:34.200 --> 31:35.040 Wow. 31:35.080 --> 31:40.180 So, OWASP AMAS project performs the network mapping of attack surface. 31:40.180 --> 31:43.420 And it can also check for the external asset discovery. 31:43.420 --> 31:48.780 So, if there are any assets which are outside the organization, we can actually figure them out. 31:48.780 --> 31:54.280 Using this open source information gathering and active reconnaissance technique, which it has. 31:54.280 --> 32:00.920 So, it can actually use multiple search engines. 32:00.920 --> 32:04.320 It can use the SIM tools. 32:04.320 --> 32:08.460 It can leverage APIs from multiple tools. 32:08.460 --> 32:12.260 It can also leverage and figure out web services. 32:12.260 --> 32:16.240 So, it's an amazing project which provides the reconnaissance technique. 32:16.240 --> 32:22.380 And once we have our application, we want to know what are the components which are open source or which are on the internet. 32:22.380 --> 32:25.540 So , AMAS project is the project to go for it. 32:25.540 --> 32:29.360 And I would strongly recommend you just take a look at it. 32:29.460 --> 32:32.700 So, you should actually take a look at this project. 32:32.700 --> 32:37.120 Now, once we have done that, we have got the requirements gathered. 32:37.120 --> 32:40.400 We have got the requirements gathered. 32:40.400 --> 32:42.500 Then we have done the threat modeling. 32:42.500 --> 32:44.460 We have done the source code review. 32:44.460 --> 32:47.040 We have done the software composition analysis. 32:47.040 --> 32:48.180 What else we have done? 32:48.180 --> 32:50.280 We have done the vulnerability testing. 32:50.280 --> 32:54.440 Now, once that's done, is there any place we can document it? 32:54.440 --> 33:02.020 If, 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? 33:02.060 --> 33:05.460 Defect Dojo helps just with that. 33:05.780 --> 33:13.640 It's an amazingly wonderful tool which actually documents the findings. 33:13.640 --> 33:16.400 It can be integrated with commercial tools as well. 33:16.400 --> 33:20.940 So, when it documents the findings, it provides the severity levels. 33:20.960 --> 33:22.520 High, medium, low. 33:22.520 --> 33:24.040 And it keeps on popping it. 33:24.040 --> 33:30.000 If you can see on the right-hand side, there is a beautiful graphical view that it provides. 33:30.000 --> 33:33.600 Especially if you have to send a report to the management. 33:33.600 --> 33:36.880 Because leadership always looks for graphs, reports. 33:36.880 --> 33:40.180 They don't want to go like, okay, these are the 10 vulnerabilities that are there. 33:40.180 --> 33:42.060 These are these things which are there. 33:42.060 --> 33:44.040 So, they look for numbers. 33:44.040 --> 33:49.420 They look for understanding, okay, these are the high-level items that we need to address. 33:49.420 --> 34:00.760 So, Defect Dojo is a tool that actually not only stores the findings, but also helps in streamlining our entire application security program. 34:00.760 --> 34:04.440 It simplifies vulnerability management by offering templates. 34:04.440 --> 34:06.300 So, we can have our own templates. 34:06.300 --> 34:07.800 We can generate the report. 34:07.800 --> 34:09.980 We can have metrics. 34:09.980 --> 34:17.660 We can check if there are duplicate findings which were there in the past report and now it's coming up again. 34:17.660 --> 34:19.540 There's a baseline that we can set. 34:19.540 --> 34:21.460 We can fine-tune the project. 34:21.460 --> 34:30.000 So, the top goal for this project is to reduce the amount of security professionals which they take in logging vulnerabilities. 34:30.240 --> 34:32.400 So, Defect Dojo addresses that. 34:32.400 --> 34:36.900 Because I have worked with the top-notch pen testers. 34:37.420 --> 34:42.480 And especially the people who worked for me, they were facing a lot of challenges in reporting it. 34:42.780 --> 34:45.120 Like, reporting it in the tool. 34:45.120 --> 34:46.060 It's a big challenge. 34:46.060 --> 34:47.760 Like, you have to copy-paste, this, that. 34:47.760 --> 34:52.720 It's more of a job wherein sometimes you feel, oh, this is not what I want to do. 34:52.720 --> 34:54.600 But this is an important task. 34:54.600 --> 34:59.080 If you don't log it, there's no point doing all of that. 34:59.080 --> 35:06.040 So, Defect Dojo helps in template system, which is like a template system for vulnerability. 35:06.040 --> 35:09.310 It can provide self-service baseline tools. 35:09.940 --> 35:14.220 It can also import common vulnerability scanners. 35:14.300 --> 35:19.460 So, if there is a scanner which is like Collis, Nessus, it can actually fetch the data from there. 35:19.460 --> 35:21.060 Fetch the reports from there. 35:21.300 --> 35:25.520 And then generate the report based on the one that we require. 35:25.520 --> 35:28.120 It can provide the beautiful metrics. 35:28.660 --> 35:38.600 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. 35:39.320 --> 35:47.100 And, once we have that, because it's important to fix the bugs, we need to make sure that we have some defensive controls. 35:47.200 --> 35:49.540 Now, what are these defensive controls? 35:49.660 --> 35:51.140 Why do we need it? 35:51.140 --> 35:57.540 Because sometimes, when we have all of it, we need open source defenses as well. 35:57.540 --> 36:04.400 Think about, there's something which is placed in front of my application and it's helping me. 36:04.820 --> 36:09.180 So, these defensive controls help just with that. 36:09.220 --> 36:13.120 So, there are some of the defensive projects which I have mentioned. 36:13.120 --> 36:20.060 There are a few projects which are under pipeline, which you can just go to OWASP.org and you can get to know about them. 36:20.060 --> 36:28.220 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. 36:28.220 --> 36:34.820 Even though that's not part of OWASP anymore, but then it's still a problem with many, many applications. 36:35.040 --> 36:38.620 So, CSRF Guard actually helps with that. 36:38.620 --> 36:51.640 And then another project is OWASP ModSecurity Core Ruleset, which is a set of generic attack detection rules for use with the ModSecurity. 36:51.640 --> 36:56.120 And it acts as a web application firewall. 36:56.120 --> 37:09.360 So, Core Ruleset's main goal is to protect the web application from a wide range of attacks, including the OWASP 10, with the minimum false alerts. 37:09.360 --> 37:15.300 Because if there's a web application firewall, it sometimes actually generates a lot of false alarms. 37:15.300 --> 37:20.300 So, it protects us from insecure web application design. 37:20.300 --> 37:33.360 So, ModSecurity rulesets, I would say, can actually provide a layer of protection for web application, such as WordPress, PHP, VB, or any type of web application. 37:33.360 --> 37:44.680 It can actually potentially protect against vulnerability or vulnerable applications, which are outdated or which are using the outdated components. 37:45.240 --> 37:49.600 It can also protect us against the generalized malicious traffic. 37:49.600 --> 37:54.860 We've seen that DDoS or DDoS is like a big problem for any organization. 37:54.860 --> 37:56.860 So, it helps us with that. 37:56.940 --> 38:04.520 And it can identify that this is a malicious traffic by using the ModSecurity rulesets. 38:05.840 --> 38:10.380 Another important project, which I never want to miss, is Proactive Control. 38:10.380 --> 38:21.720 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. 38:21.720 --> 38:34.080 So, Proactive Control helps with that, wherein it provides a list of controls that developers, testers, security researchers need to know. 38:34.080 --> 38:41.000 These are the pointers like encode data, verify for security early and often. 38:41.000 --> 38:43.280 All of this, we should know. 38:43.320 --> 38:46.060 And what are the frameworks and libraries we should be using. 38:46.060 --> 38:49.740 If we are using third-party libraries, when to secure it. 38:49.740 --> 38:54.160 So, all of that, Proactive Control is emphasizing on that. 38:54.160 --> 38:58.940 And it's the place to go for any of the developers, I would say. 39:00.260 --> 39:07.560 Now, once we know about Proactive Control, what else we should be looking at? 39:07.700 --> 39:16.220 Now, we have the Proactive Controls, how about we train our developers, testers, and even the people who are part of security. 39:16.220 --> 39:20.840 It's very, very important to secure our applications. 39:21.060 --> 39:27.240 Because if we don't train our people, we would be leaving so much behind. 39:27.240 --> 39:30.540 So, what are the things that can help us? 39:30.660 --> 39:33.620 Is there any place where I can learn this? 39:33.920 --> 39:38.380 So, OWASP WebGuard is one of the oldest projects, I would say. 39:38.380 --> 39:39.880 One of the oldest projects. 39:40.340 --> 39:46.340 That used to come in a CD and I have copied on my system and then started working on this particular project. 39:46.340 --> 39:48.420 Which has matured over the years. 39:48.420 --> 39:58.580 So, OWASP WebGuard actually is a deliberately vulnerable web application where there are so many challenges which we can solve and we can fix the bugs. 39:58.580 --> 40:02.620 So, it gives you a view that, okay, this vulnerability could be looking like this. 40:02.660 --> 40:04.480 So, it helps with that. 40:04.600 --> 40:10.560 Another project is Security Shepherd, which I usually use in my trainings, which I give. 40:10.560 --> 40:17.280 So, this is like an exercise which you can see on the screen that, yes, it's a lesson and there's a scoreboard. 40:17.280 --> 40:22.100 Once you solve all of these things, it becomes from cross to check. 40:22.540 --> 40:27.580 And it provides an exhaustive list of all the test cases. 40:27.580 --> 40:30.860 There's a SQL injection that can be done multiple ways. 40:30.860 --> 40:31.500 It provides that. 40:31.500 --> 40:33.080 There's a blind SQL injection. 40:33.080 --> 40:34.360 How does that happen? 40:34.360 --> 40:35.680 So, it provides with that. 40:35.680 --> 40:42.740 So, it builds a story around an application and helps us in understanding the bugs. 40:43.060 --> 40:50.100 Another project is DevSlock, which is more of a working project rather than a training project. 40:50.200 --> 41:02.540 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. 41:03.780 --> 41:07.880 This particular project can be used in the whole DevSecOps lifecycle. 41:08.300 --> 41:14.200 And how this particular project can be used could be in the source code review. 41:14.200 --> 41:19.060 So, the team actually works real-time on that, do the live demos. 41:19.060 --> 41:20.760 There are failures that do happen. 41:20.760 --> 41:28.140 Even I was part of one of the sessions wherein I gave a session on dependency check and we were troubleshooting live. 41:28.140 --> 41:31.640 Okay, we downloaded dependency check. 41:31.640 --> 41:32.700 What next? 41:32.700 --> 41:35.280 How are we going to work with NVD database? 41:35.280 --> 41:36.760 How are we going to run the scan? 41:36.760 --> 41:38.460 Where are we going to put the jar files? 41:38.460 --> 41:40.340 Where are we going to pick the code? 41:40.340 --> 41:43.480 So, everything we did live on the session. 41:43.480 --> 41:48.880 It's not like we are actually recording a video and then cutting it. 41:48.880 --> 41:51.900 Whatever is the best shot, that should be there. 41:51.900 --> 41:52.780 No. 41:53.000 --> 41:55.020 They do it live. 41:55.200 --> 41:56.180 Failures do happen. 41:56.180 --> 41:59.120 They keep on implementing those new things. 41:59.120 --> 42:00.440 They keep on working on it. 42:00.440 --> 42:04.120 And all the sessions, you can see it on the OWASP project. 42:04.120 --> 42:11.660 Similarly, they have PXE, which is an Intentionally Vulnerable API project. 42:11.660 --> 42:14.580 Which is an amazing project you should take a look at. 42:15.120 --> 42:25.060 So, now, once we've talked about it, how can I leave Jushop, which is like the most modern web application with all the relevant bugs. 42:25.060 --> 42:27.320 And even I have used it for CTFs. 42:27.320 --> 42:30.020 You can use it for CTFs within the team as well. 42:30.020 --> 42:37.300 So, I wanted to showcase some of the test cases to one of the development team and even my team. 42:37.300 --> 42:43.800 So, we used it as a project, as a CTF platform for the testing. 42:43.800 --> 42:53.260 And it has actually helped us a lot in finding and making the teams understand these are the bugs that exist in an application. 42:55.360 --> 42:59.000 So, this really helps with that. 42:59.760 --> 43:10.000 Another thing is that when you go to Jushop, it gives you a kind of feeling like a real application. 43:10.000 --> 43:12.140 And then you start exploiting it. 43:12.140 --> 43:16.440 So, I really like the project and even the project leaders are super cool. 43:16.440 --> 43:18.760 They keep on adding new stuff in it. 43:18.760 --> 43:30.040 If you reach out to them, if you want to help them, help them in modifying some challenges or adding some new challenges, they are always open for it. 43:30.040 --> 43:32.220 So, make sure that you reach out to them. 43:32.740 --> 43:39.080 Once we know about these projects, how about we go to the awareness item. 43:39.080 --> 43:40.760 Now, we have talked about testing. 43:40.760 --> 43:42.920 How can we miss top 10 projects? 43:42.920 --> 43:50.100 I am sure everybody knows that there is a flagship project, top 10. 43:50.100 --> 43:56.500 And any organization which wants to secure application security, they go through top 10. 43:56.500 --> 44:05.220 And they use top 10 as like a project which cannot be forgotten, which cannot be left behind. 44:05.220 --> 44:07.200 It acts as a framework. 44:07.200 --> 44:13.520 We have to make sure that top 10 bugs don't exist in an application or in our application. 44:13.520 --> 44:18.240 You must be thinking that I have covered so many things around application security, mobile security. 44:18.240 --> 44:20.600 And did I leave OWASP top 10? 44:20.600 --> 44:21.480 No. 44:21.480 --> 44:29.840 So, I have left it for the awareness session that we all should be aware that OWASP top 10 exists. 44:29.840 --> 44:36.760 And every 3 to 4 years, there are new sets of top 10 cases which come. 44:36.760 --> 44:39.540 And those are not done by OWASP. 44:39.540 --> 44:41.000 It's done by community. 44:41.000 --> 44:42.600 It's done by the organization. 44:42.600 --> 44:44.480 The data comes from the organization. 44:44.560 --> 44:45.980 And then people work on it. 44:45.980 --> 44:47.160 Community work on it. 44:47.160 --> 44:48.640 Community share the feedback. 44:48.640 --> 44:52.520 Okay, these are the test cases that are there. 44:52.520 --> 44:54.960 Or these are the top 10 vulnerability. 44:55.140 --> 44:58.640 And every 3 years, you would see this shuffling happening. 44:58.980 --> 45:05.740 And past few years, I would say, SQL injection has been on top. 45:05.740 --> 45:10.500 Which I would say that we all have to work together and make sure that that actually goes down. 45:10.500 --> 45:19.040 There are few vulnerabilities which have taken a place like using components with open source or vulnerable components. 45:19.340 --> 45:23.540 Using components with known vulnerabilities, which is A9. 45:23.540 --> 45:31.080 Then XXC, that has become a part of it, which is A4, which is on the top 4 list. 45:31.080 --> 45:34.040 So, it addresses all of that. 45:34.040 --> 45:40.260 Then, there's another amazing project, which is ASVS, Application Security Verification Standard. 45:40.260 --> 45:42.280 Which I've talked about in the beginning. 45:42.280 --> 45:44.420 So, what it is. 45:44.420 --> 45:57.040 So, the primary aim of OWASP Application Security Verification Standard is to provide an application security platform, a standard for web apps and web services of all types. 45:57.560 --> 46:00.980 And my experience is like, I'm a big fan of checklists. 46:00.980 --> 46:09.120 And during my penetration testing time when I was starting off, from web testing guide, I created my own checklist. 46:09.120 --> 46:13.460 And then later, I got to know that there is something called ASVS that exists. 46:13.460 --> 46:15.200 It was a bummer for me. 46:15.200 --> 46:19.840 So, I thought, why don't I introduce it to you. 46:20.100 --> 46:27.000 OWASP Application Verification Standard has security controls, which has like 4 levels. 46:27.000 --> 46:30.120 Starting with the cursory, which is level 0. 46:30.120 --> 46:34.300 It goes to level 1, which is opportunistic. 46:34.400 --> 46:36.680 Then it's standard level 2. 46:36.680 --> 46:38.880 Then it becomes the advanced level 3. 46:38.880 --> 46:48.040 And how it happens is like, ASVS level 1, which is for low assurance, for applications which are penetration testable. 46:48.040 --> 46:51.220 And then those are low severity applications. 46:51.300 --> 47:01.080 Then level 2 is like the application that contains sensitive data, which requires protection in some form and is the recommended level for most of the applications. 47:01.300 --> 47:08.080 Now, when it comes to level 3 ASVS, it is like the most critical applications. 47:08.300 --> 47:16.240 And applications that perform high value transactions, like banking, I would always recommend level 3 for them. 47:16.240 --> 47:31.340 So, the standard provides the requirements and it gives you the good checklist in the form of a word, CSV file, and a PDF, which we can take it and go back and map it to our own organization. 47:31.340 --> 47:42.140 We can use it in the requirements gathering, requirements mapping, even SKF, security knowledge frameworks, leverage is the same. 47:43.360 --> 47:49.420 Now, when we have mobile testing guide, why don't we have mobile top 10? 47:49.420 --> 47:57.370 So, we do have mobile top 10, which is like the top 10 flaws in the mobile or mobile arena. 47:57.960 --> 48:01.640 And mobile top 10 guide helps just with that. 48:01.640 --> 48:18.780 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. 48:19.200 --> 48:26.480 Not to miss the privacy risks, because for any organization, privacy is like a big concern. 48:26.480 --> 48:33.760 So, another list is top 10 privacy risks, which is part of application security. 48:33.760 --> 48:41.200 And this project aims to offer tangible tips on how to embed privacy in the design of web application. 48:41.200 --> 48:49.340 It helps developer, security tester, and everyone understand the consequences of these privacy risks. 48:49.340 --> 48:56.100 So, these top 10 risks include web application vulnerabilities, operator side data leakage. 48:56.100 --> 48:58.520 Insufficient data breach response. 48:58.520 --> 49:00.640 All of the privacy concerns that could be there. 49:00.640 --> 49:05.760 Insufficient deletion or insufficient deletion of personal data. 49:05.900 --> 49:07.860 Non-transparent policies. 49:07.920 --> 49:11.960 The data which is stored in an encrypted format, which is not required. 49:12.000 --> 49:17.420 Or the data which is required to be encrypted, that's not being stored in the encrypted format. 49:17.420 --> 49:20.380 So, sharing of data with a third party. 49:20.420 --> 49:21.920 This addresses that. 49:21.920 --> 49:27.420 Because there have been breaches which have happened because of sharing the data with the third parties. 49:27.800 --> 49:31.920 Then, missing or insufficient session expiration. 49:32.220 --> 49:34.400 Insufficient data transfer. 49:34.560 --> 49:36.480 So, all of that, it talks about it. 49:36.480 --> 49:42.920 Now, when we have talked about all of this, how about avoiding all those automated bots? 49:42.920 --> 49:52.320 Automated technologies which run on our application and make us part of the breaches. 49:52.640 --> 50:03.720 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. 50:03.720 --> 50:08.200 And it helps us in fixing all the automation bugs. 50:08.200 --> 50:11.140 So, now what we have learned? 50:11.240 --> 50:15.020 We have gathered the requirements. 50:15.120 --> 50:17.500 We have done the threat modeling. 50:17.500 --> 50:19.160 We have done the source code analysis. 50:19.160 --> 50:21.960 We have done the software composition analysis. 50:21.960 --> 50:25.660 We have also done the vulnerability testing. 50:25.660 --> 50:28.800 Now, once we have done all that, we have done the technical training. 50:28.800 --> 50:30.960 We have some defensive controls. 50:30.960 --> 50:39.900 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. 50:40.280 --> 50:45.320 So, once we have added that, how about having a knowledge base of things which can help us? 50:45.320 --> 50:51.900 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. 50:51.980 --> 50:54.980 Similarly, security knowledge frameworks. 50:54.980 --> 51:02.360 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. 51:02.960 --> 51:08.960 Is there any place where I can just go and check if I use it in a certain way? 51:08.960 --> 51:11.460 What could be the vulnerability on this application? 51:11.940 --> 51:20.480 So, security knowledge frameworks is like a standard for multiple vulnerable code snippets and how to fix them. 51:20.480 --> 51:25.580 It helps in requirement gathering, it helps in threat modeling, and many other things. 51:25.700 --> 51:31.360 And ASVS, or application security verification, complements that beautifully. 51:31.880 --> 51:35.920 Then, another important project is Snake and Ladders. 51:35.920 --> 51:40.820 Now, what is Snake and Ladders and why are we talking about an application security program? 51:40.820 --> 51:44.820 So, Snake and Ladders is an educational application security awareness game. 51:44.820 --> 51:48.960 So, this is a board game for understanding the behaviors. 51:49.180 --> 51:51.900 Virtuous behavior is ladder. 51:52.280 --> 51:57.880 Then, security coding practices are OWASP proactive controls. 51:58.120 --> 52:02.880 And devices, or snakes, are application security risk. 52:02.880 --> 52:05.200 So, why are we picturizing it? 52:05.200 --> 52:12.400 So, this is a board game which generally is being played in Asia, wherein if a snake bites, you will come down. 52:12.400 --> 52:19.960 Similarly, if you have an application security risk, your application might be part of a breach or your application might be at risk. 52:19.960 --> 52:21.880 So, let's talk about just that. 52:22.200 --> 52:27.400 Another educational program or a project is Cornucopia. 52:27.400 --> 52:39.080 Because there are some times wherein if we want to make developers, program managers, security testers, understand why we need Agile in a security platform. 52:39.080 --> 52:43.600 Why we need Agile or DevOps in an application security program. 52:43.700 --> 52:46.380 Cornucopia helps with a card game. 52:46.380 --> 52:52.300 Like, we all are working remotely and we might need something to play for. 52:52.300 --> 52:55.600 So, this project helps with that. 52:55.600 --> 53:01.580 Which is a project, which is a fun game, wherein we can play online. 53:01.580 --> 53:04.540 And I have ordered my card, which I have yet to receive. 53:04.540 --> 53:09.400 And it's a beautiful bundle of cards, which I am going to play with my developers and make them understand. 53:09.400 --> 53:14.620 Okay, these are the challenges that we can address by using these things. 53:15.880 --> 53:18.760 So, I have been talking about all of it. 53:18.760 --> 53:21.620 But is there one place where I can see all the projects? 53:21.620 --> 53:27.860 So, this is the slide that I wanted to showcase. 53:27.860 --> 53:31.420 This is the framework, which contains every... 53:31.420 --> 53:37.680 So, this is the project, which contains every project that I've just told you. 53:37.680 --> 53:43.760 Starting with requirements gathering, till the training and awareness, and how it can help. 53:43.940 --> 53:46.840 And all of these slides will be available to you. 53:46.840 --> 53:49.860 And you can leverage it at any point of time. 53:51.220 --> 53:56.080 But, there comes a point when, how can you contribute to these projects? 53:56.080 --> 53:58.420 Because these are all open source, community driven. 53:58.420 --> 54:00.780 So, you can contribute to the code. 54:00.780 --> 54:06.880 If you feel that there is something, which you can add it to any of the projects, please do. 54:06.900 --> 54:13.040 But if you want to help in writing test cases, helping curate the content, please do help. 54:13.920 --> 54:17.500 Sometimes, not enough time, wherein we can write the documentation. 54:17.500 --> 54:21.920 If you want to help with the documentation, please do help. 54:21.920 --> 54:23.800 The project leaders, you can help. 54:23.900 --> 54:31.060 And also, if nothing can be possible, how about promoting a project, which is close to your heart? 54:31.060 --> 54:35.500 Like, there are so many projects, which are close to my heart, and I keep talking about them. 54:35.640 --> 54:37.760 So, you can actually talk about them. 54:37.840 --> 54:40.240 You can suggest some features. 54:40.300 --> 54:41.820 You can report the bugs. 54:41.960 --> 54:44.260 And actually, project leaders work on them. 54:44.260 --> 54:46.160 You can just make a pull request. 54:46.160 --> 54:47.420 Make suggestions. 54:47.580 --> 54:48.920 And they do work on it. 54:49.560 --> 54:51.800 Then, how do we move forward? 54:51.800 --> 54:55.000 Is there anything else that I can do with OWASP or OWASP projects? 54:55.000 --> 54:57.700 If I want to be part of the bigger community. 54:57.860 --> 55:06.320 So, OWASP.org is the place where you can go and look for the projects nearby, chapters nearby. 55:06.400 --> 55:07.660 And projects are there. 55:07.660 --> 55:08.720 All the projects. 55:08.720 --> 55:10.160 Even detailed information. 55:10.160 --> 55:11.860 I've just touched upon it. 55:11.900 --> 55:14.220 You can actually get the detailed view of it. 55:14.220 --> 55:16.520 So, OWASP.org is the place to go. 55:16.520 --> 55:20.520 Then, you can also join the nearest chapter. 55:20.880 --> 55:22.780 Like in Bangalore, I'm in India. 55:22.780 --> 55:23.920 Bangalore has a chapter. 55:23.920 --> 55:24.940 Delhi has a chapter. 55:24.940 --> 55:26.020 Pune has a chapter. 55:26.020 --> 55:27.380 Orissa has a chapter. 55:27.380 --> 55:30.860 So, I'm sure if you are in any part of the world, OWASP has a chapter. 55:31.040 --> 55:36.620 And if there is no chapter right now, if you want to start a community, do go for it. 55:36.620 --> 55:40.620 You can raise a request on the OWASP.org page. 55:40.620 --> 55:47.980 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. 55:47.980 --> 55:52.100 Even if you are a student and you want to create a chapter in your college. 55:52.100 --> 55:54.460 So, there are student chapters which are there. 55:54.460 --> 56:00.320 So, you can be a student leader and help in your college in getting started. 56:00.960 --> 56:07.760 So, if you feel that you are not part of the community, you can be part of the community. 56:07.760 --> 56:11.060 You just have to step up and ask for help. 56:11.100 --> 56:14.140 And everyone will be there to help you. 56:14.140 --> 56:21.400 And the one thing that I've actually received from the security community is that the peeps are so helpful. 56:21.640 --> 56:22.860 So warm. 56:22.860 --> 56:24.540 And I've learned a lot. 56:24.540 --> 56:27.260 And that's when I'm able to contribute. 56:28.280 --> 56:31.860 What you can do is, you can reach me if you have any feedback. 56:31.860 --> 56:34.220 If you have any questions around this talk. 56:34.220 --> 56:40.640 Or if you want to discuss about something, you can reach me here. 56:41.380 --> 56:44.380 So, we are going to take question answers now. 56:45.740 --> 56:47.360 Thank you so much. 56:47.360 --> 56:50.860 And please feel free to reach me anytime. 56:50.860 --> 56:53.580 This is Namaste, which is a form of a greeting. 56:53.580 --> 56:55.580 And thank you or a goodbye.