>> All right. Let's look at the OWASP Top
10 and it's kind of migration from
its very humble beginnings into
>> what we see now in 2021.
>> Our learning objectives are to explain the OWASP Top
10 and why it's important for
a web application security,
and then summarize the history and
methodology of the OWASP Top 10,
which has shifted a lot over time.
Let's talk about that.
The OWASP Top 10 was first released in 2003.
This has been nearly two decades long process.
It was updated initially in 2004
>> and then again in 2007,
>> and it was really by incident number.
So it's how much of this vulnerability that we
see in web application security or in web apps,
I should say, that took
the center stage or populated the top 10 at that time.
In 2010, things changed.
Things changed to prioritize risk.
We might have a thousand cross-site scripting
vulnerabilities reflected,
but maybe that's not as serious
or as risky as a SQL injection.
OWASP revamped things to then really look at
risk rather than just amount of incidence.
In 2013 and 2017, things changed again
but most people are familiar with this version of
the OWASP Top 10 and are used to seeing it
as far as prioritizing,
again, looking at risk,
really looking at risk.
Things have changed a lot in the 2021 version.
So I want to get to that and show you what
has changed and what has stayed the same.
Here we go. If you look at this,
it looks like a giant mess,
but let's break this down.
Injection used to be at the top,
injection like command injection, SQL injection.
I would even classify XXE, which was number 4,
and cross-site scripting at seven,
those are injection vulnerabilities.
You can see injection went from
the number 1 spot to the number 3 spot.
Broken authentication, that is no longer there,
that has been integrated into
identification and authentication failures.
So these two categories no longer exist.
Sensitive data exposure went from
the number 3 position all the way
to the number 2 position in cryptographic failures.
As you can see, number 4,
that is gone but had been
integrated into security misconfigurations.
Beloved XXE is now part of
security misconfigurations number 5.
Broken access control,
that is number 1 now.
Security misconfigurations is now number 5.
Cross-site scripting, that is gone,
but that has been moved
into injection, which I agree with.
Insecure deserialization has been moved
into software and data integrity failures.
Using components with known
vulnerabilities has stayed and
it's moved into the number 6 position.
Slightly different name,
vulnerable and outdated components.
Then insufficient logging and monitoring,
that is now migrated into
security logging and monitoring failures.
If you see we have these new categories,
we have insecure design, which is number 4.
We have number 8,
which is software and data integrity failures,
which insecure deserialization became part of.
At the bottom of the list,
we have server-side request forgery.
A specific vulnerability has
now made its way to number 10.
If we look, the last two are from a survey.
The top eight are from data,
and the last two OWASP put out a survey,
and people voted for what they thought was
the most serious risk in web applications.
Then two that they got back at
the top of the list are security
logging and monitoring failures,
as well as server-side request forgery.
Now I want to explain some terms
before we go forward so you
understand why OWASP has changed things up.
There are CWEs,
which are Common Weakness Enumeration.
CWE is a specific weakness.
So cross-site scripting, SQL injection,
a weakness not in a specific piece of software.
That is a CVE.
Do not get these two confused.
Think CWE is a bigger picture weakness, you could say.
Again, like SQL injection.
Then a CVE is a specific vulnerability,
SQL injection, in a specific piece of software.
Not to pick on WordPress,
but perhaps a SQL injection and a
WordPress plugin or in Drupal,
or a Drupalgeddon,
which we saw a while ago,
was vulnerable to SQL injections.
That is a CVE because it is
a vulnerability for a specific piece of software,
or I should say specific software.
We also have CVSS or
>> Common Vulnerability Scoring System.
>> This is how we determine if something's really,
really bad or not so bad
but we do that numerically and
they can also be color-coded.
CVSS has changed,
it's now on version 3.1.
There was version 1, version 2,
which you might see still some version 2,
version 3, and version 3.1
but that's really our way to determine with
a quantitative score how bad a vulnerability is.
Who determines the top 10?
We talked a little bit about the bottom two
being from a survey that OWASP put out
but we have a huge dataset
>> that OWASP analyzed for 2021.
>> They got this from different
web application security vendor,
security scanners.
We can see bug bounty programs like HackerOne.
They got a lot of data from HackerOne.
If you've been involved in the bug bounty space,
when you submit a vulnerability,
you have to map it to something like a CWE.
This is how they get this data are from platforms like
HackerOne and also places like Veracode.
As I talked about, eight of
these categories are from the data,
strictly the data, and then
two are from this community survey.
The data was collected from May to November of 2020,
a kind of short timeframe.
You can see a sample of the submission here in GitHub.
OWASP does a lot in GitHub,
so you can find a copy of the submission there.
I would say this is
probably the most comprehensive year,
as far as mapping CWEs to the OWASP Top 10.
There are a huge number,
like 400 CWEs,
that are mapped to the top 10, whereas before,
it was only 30, as you can see at the very bottom here.
I would say, don't focus solely on the top 10,
but this year out of any other year,
they cover things pretty
comprehensively in the OWASP Top 10.
Also makes things, in my opinion,
a lot more confusing than instead of having
30 CWEs that OWASP is prioritizing,
they now have 400 CWEs
and it's really impossible for you to
memorize and know every single CWE
now in the OWASP Top 10.
Whereas before, like in 2017,
it was easy to learn and know these 30 CWEs.
The methodology behind the data.
In this year, as far as risk,
which was previous years,
OWASP is really focusing on exploitability,
how easy it is to exploit something,
and the impact,
the technical impact that a vulnerability has.
I talked about cross-site scripting,
let's say reflected cross-site scripting.
It may be easily exploitable,
but what's the technical impact?
If there's not a big technical impact,
is this really a risk that should be
>> on the OWASP Top 10?
>> That's just an example.
I'm not saying it is or it isn't,
but cross-site scripting is now
gone and migrating new injection.
So take that for what it is. This is a lot.
You may have to read this a few times
but our CVEs or
specific vulnerabilities are grouped by CVSS score.
So how bad or how not bad something is and by CWE.
Every CVE is mapped to a CWE.
Now it's weighted both exploit and impact,
so we're going back to exploitability and impact,
scored by the percentage of
the population that has CVSS scores.
Not all CVEs have numerical scores.
Some do, some don't;
but they took the ones that did have scores
to get an overall average.
Then they map these averages to the CWEs in the dataset
to use as exploit and technical impact scoring.
That's a lot. Again, you may have to read this.
I suggest you do read the source of the bottom,
the introduction of how OWASP got their methodology.
Because it is very data-driven,
it is somewhat complicated.
There are a lot of terms that go into it,
but the biggest takeaways are now OWASP is looking at
exploitability and technical impact,
whereas it hadn't really done that before.
When we go over the top 10,
OWASP now looks at
how many CWEs are mapped to that category.
Now, I believe out of CWEs,
there's like 600 CWEs out there.
So 400 of the 600 is a lot.
We have a lot of the CWEs mapped now.
Incident rate is the percentage of
application is vulnerable to that
CWE from the population tested.
The weighted exploit.
We're using a numerical score here,
the 10-point scale, 10 being the worst.
Weighted impact. Again,
we're looking at CVSS scores.
I talked about versions 2 and versions 3.
Some CVEs are so old that
>> they only have CVSS version 2,
>> and those have to be translated into a common language
with CVSS 3, the newer version.
They normalize this on
both the weighted exploit and the weighted impact,
and both are on a 10-point scale.
They also looked at coverage.
The percentage of applications tested by
all organizations for a given CWE.
The total number of occurrences mapped
across categories and the total number of
CVEs that are applicable to those map CWEs.
Now, as you can probably guess,
CWEs are more generally
a category like SQL injection cross-site scripting.
CVEs, there's a whole lot more.
There's over a 170,000 CVEs out there.
In summary now, we should understand the importance of
the OWASP top 10 for web application security.
We should now understand also the OWASP Top 10 history,
what has changed,
and the new methodology for
the 2021 version of the OWASP Top 10.