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 Sehgal.
Vandana is a seasoned security professional with experience ranging from application security
to infrastructure, and now dealing with DevSecOps.
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.
She is part of the OWASP Global Board of Directors.
She also works in various communities towards diversity initiatives,
including InfoSec Girls, WOSEC, and NULL.
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 OWASP 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.
OWASP 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.
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 Sehgal.
My day job is with one of the multinational companies in India.
And apart from that, I root for ProOne Work,
and I work with OWASP, which is Open Web Application Security Project.
I'm one of the global board of directors for OWASP.
Apart from that, I also work with Diversity Initiatives.
I am the president for InfoSec Girls.
I have few 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 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.
Now, cybercriminals can gain entry into an organization system and steal 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 AppSec program comes into picture.
And this is when I thought that, okay, how about let's use the OWASP 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 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.
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.
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 we can list down?
Okay, these are the things that we have.
And on those things, we are going to decide, okay, yes, this is our plan.
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.
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 OWASP Security Knowledge Framework,
which is a big, exhaustive project in itself.
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 RAC 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 are 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.
We can now use threat modeling as a code.
We can use the tools like Threat Dragon.
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, 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, the pieces are scattered everywhere.
Now, if we have a flow chart, 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 project's page.
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.
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 OWASP 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 a 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 an amazing checklist which provides, okay,
these are the things that should be fixed in a code.
These are the things that can be guided in.
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 have been provided by the code review checklist.
Similarly, there is 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 presents 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, CodePulse really helps us with that.
Now, we have understood that this is what we have done with the code review.
But how about a specially designed code review checklist or practice guide for a certain code.
Like GoCode.
GoCode, I started learning a couple of years back.
But before that, it was like a completely new arena for me.
And then came up OWASP Go Secure coding project.
Which helped me in understanding, okay, this is a Go 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.
That how to secure GoCode.
Another beautiful checklist is the 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 we 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 is an exhaustive list.
Starting from input validation, to cross-site scripting, to xxe, to indirect 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.
And 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 one that has been developed by the team.
Or the remodeled website which is there for the 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 Equifax.
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.
There were so many reasons.
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 wherein white source has quoted that 96.5% code on the internet is all open source.
That's a huge amount of code.
When 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 have 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?
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.
You are just saying that you want this and you are going ahead with the tool.
So, what else can we do?
Is there any project by OWASP?
Yes.
So, OWASP has dependency check, which is called DC, people call it as.
So, dependency check, this is an open source component, which is 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 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.
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.
We cannot just think that, okay, 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?
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.
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, OWASP 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 lifecycle.
We can integrate with Jenkins, which can allow us to integrate with the CI-CD pipeline.
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.
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.
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 results.
And not just that, it is very simple to configure as well.
Because configuring a tool is like a nightmare sometimes.
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.
So, I know sometimes it's like pain to configure a tool.
So, 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.
Where if there was a critical vulnerability, I have stopped the releases.
But then over the year, we all grow.
We 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.
Web Application Security Testing Guide.
Which is an exhaustive guide on how to start an application security testing.
Robots.txt file.
What is crawling?
What is spridering?
What is STLC?
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 OWASP, 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're talking about applications.
But in the beginning, I mentioned that we're all talking about modernization.
We're 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, OWASP API Security Top 10 answers just that.
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.
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 OWASP API Security Top 10 Guide.
And not just that, the project leaders keep on enhancing it.
Wherein, API Security Testing Guide, they start working on it.
They are planning to merge it with the 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.
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, we start using APIs.
A small web app call, we start using it.
APIs, when they expose application logic.
And they contain so much sensitive data.
Like PIR 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 understand 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 step-by-step information and an exhaustive checklist.
Because now you have a big testing guide.
And from that 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 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 groundwork.
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?
That is an open source tool.
So, OWASP ZAP, which is Z-Attack 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 a specific API from this tool, we can just do that.
So, ZAP really helps.
And especially how it came into existence.
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 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 pen test assignments.
Apart from that, there's another project which is AMAS project.
Now, what is this AMAS project? You might not have ever heard it.
So, when I heard about it, I felt, oh, there's something that exists.
Wow.
So, OWASP AMAS 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 SIM tools.
It can leverage APIs from multiple tools.
It can also leverage and figure out web services.
So, it's an amazing project which provides the reconnaissance technique.
And once we have our application, we want to know what are the components which are open source or which are on the internet.
So, AMAS 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's done, is there any place we can document it?
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?
Defect Dojo helps just with that.
It's an amazingly wonderful tool which actually documents the findings.
It can be integrated with commercial tools as well.
So, when it documents the findings, 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, reports.
They don't want to go like, 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 stores 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 fine-tune the project.
So, 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 pen testers.
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 wherein sometimes you feel, oh, 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-service baseline tools.
It can also import common vulnerability scanners.
So, if there is a scanner which is like Collis, Nessus, 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 a few projects which are under pipeline, which you can just go to OWASP.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 OWASP anymore, but then it's still a problem with many, many applications.
So, CSRF Guard actually helps with that.
And then another project is OWASP ModSecurity Core Ruleset, which is a set of generic attack detection rules for use with the ModSecurity.
And it acts as a web application firewall.
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.
Because if there's a web application firewall, it sometimes actually generates a lot of false alarms.
So, it protects us from insecure web application design.
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.
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 or 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 ModSecurity rulesets.
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 Control helps with that, wherein it provides a list of controls that developers, testers, security researchers need to know.
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 third-party libraries, when to secure it.
So, all of that, Proactive Control is emphasizing on that.
And it's the place to go for any of the developers, I would say.
Now, 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, OWASP WebGuard is one of the oldest projects, I would say.
One of the oldest projects.
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, 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.
So, it gives you a view that, okay, 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 blind SQL injection.
How does that happen?
So, it provides with that.
So, it builds a story around an application and helps us in understanding the bugs.
Another project is DevSlock, 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.
This particular project can be used in the whole DevSecOps lifecycle.
And how this particular project can be used could be in the source code review.
So, the team actually works real-time on that, do the live demos.
There are failures that do happen.
Even I was part of one of the sessions wherein I gave a session on dependency check and we were troubleshooting live.
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, you can see it on the OWASP project.
Similarly, they have PXE, which is an 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 Jushop, 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 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.
And it 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 to Jushop, it gives you a kind of feeling like a real application.
And then you start 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 are 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 projects?
I am sure everybody knows that there is a flagship project, top 10.
And 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.
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 OWASP top 10?
No.
So, I have left it for the awareness session that we all should be aware that OWASP top 10 exists.
And every 3 to 4 years, there are new sets of top 10 cases which come.
And those are not done by OWASP.
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.
And every 3 years, you would see this shuffling happening.
And past 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 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 A4, which is on the top 4 list.
So, it addresses all of that.
Then, there's another amazing project, which is ASVS, Application Security Verification Standard.
Which I've talked about in the beginning.
So, what it is.
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.
And my experience is like, I'm a big fan of checklists.
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.
OWASP Application Verification Standard has security controls, which has like 4 levels.
Starting with the cursory, which is level 0.
It goes to level 1, which is opportunistic.
Then it's standard level 2.
Then it becomes the advanced level 3.
And how it happens is like, ASVS level 1, which is for low assurance, for applications which are penetration testable.
And then those are low severity applications.
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.
Now, when it comes to level 3 ASVS, it is like the most critical applications.
And applications that perform high value transactions, like banking, I would always recommend level 3 for them.
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.
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 or 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.
Not to miss the privacy risks, because for any organization, privacy is like a big concern.
So, another list is top 10 privacy risks, 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.
It helps developer, security tester, and everyone understand the consequences of these privacy risks.
So, these top 10 risks include web application vulnerabilities, operator side data leakage.
Insufficient data breach response. All of the privacy concerns that could be there. Insufficient deletion or insufficient deletion of 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 a 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 a 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 requirement 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 Ladders is an educational application security awareness game.
So, this is a board game for understanding the behaviors.
Virtuous behavior is ladder.
Then, security coding practices are OWASP proactive controls.
And devices, 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, wherein 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, let's talk about just that.
Another educational program or a project is Cornucopia.
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.
Why we need Agile or DevOps in an application security program.
Cornucopia helps with a card game.
Like, we all are working remotely and we might need something to play for.
So, this project helps with that.
Which is a project, which is a fun game, wherein we can play online.
And I have ordered my card, which I have yet to receive.
And it's a beautiful bundle of cards, which I am 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...
So, this is the 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 projects, please do.
But if you want to help in writing test cases, helping curate 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.
And also, if nothing can be possible, how about promoting a project, which is close to your heart?
Like, there are so many projects, which are close to my heart, and I 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?
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 projects.
Even detailed information.
I've just touched upon it.
You can actually get the detailed 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.
Orissa 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 right 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 are 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 when 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 this talk.
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 a form of a greeting.
And thank you or a goodbye.