- [Instructor] Software and hardware vendors
may actually have separate teams
that handle the investigation, resolution,
and also the disclosure of security vulnerabilities.
And typically,
these teams are called
Product Security Incident Response Team,
or otherwise known as a PSIRT.
As a matter of fact, I'm actually a part of a PSIRT team,
you know, the Cisco Product Security Incident Response Team.
Now, before you understand how a PSIRT operates,
you must understand
what actually is a security vulnerability, right,
so this, of course, might be a refresher
from the Security Fundamentals exam.
And whenever you were preparing for that exam,
but just as a refresher,
the National Institute of Standards and Technology,
or NIST, defines a security vulnerability as,
"A flaw or a weakness in system security procedures, design,
"implementation, or other internal controls,
"that could be exercised,
"that means, accidentally triggered
"or intentionally exploited,
"and result in a security breach or a violation
"of the system's security policy."
Right.
Now, there are tons of other definitions out there,
but they tend to be variations
of the one that NIST actually provides,
and the one that actually I quote here.
Now, you may ask yourself,
why should you worry about security vulnerabilities
in products, right?
And this is because each of them represents a potential risk
and vector how to, you know,
how threat actors can actually compromise
your systems and your network, right.
Each vulnerability carries a certain amount of risk,
you know, within, you know, that vulnerability, right,
so one of the most widely adopted standards
to actually calculate the severity of a given vulnerability,
and that is also used by many PSIRT teams,
is the Common Vulnerability Scoring System, or CVSS, right.
And CVSS has three major metrics or components,
the base, temporal, and environmental scores, right.
Each component is actually represented
as a score on the scale from zero to 10.
Again, you learned all about CVSS
in the preparation to the Sec Fun exam,
but here's actually a, you know,
very brief refresher, right.
So CVSS is an industry standard,
that is actually maintained by FIRST, right,
and it's actually used by many PSIRT teams
to convey information about the severity of vulnerabilities
that they actually disclose to their customers.
In CVSS, a vulnerability is evaluated under three aspects,
and scores are assigned to each of those,
you know, different categories, right.
So the base groups represent
the characteristics of a vulnerability
that are constant over time
and do not depend on a user specific environment, right.
So the temporal group assess the vulnerability,
as it actually changes over time.
And the environmental, you know, just like the word says,
actually provides and represents
the characteristics of a vulnerability,
taking into account the organization's environment, right.
Now, again, the score for the base group
is between zero and 10,
where zero is the least severity,
and 10 is assigned to the, you know,
highly critical vulnerabilities, right.
You know, for instance,
for vulnerabilities that can allow an attacker
to compromise the system and get full control of the system,
and perhaps, you know, do a remote code execution,
you will see a higher score whenever, you know,
you compare it to vulnerabilities,
that perhaps are a lot more,
you know, less risky,
and also harder to actually exploit, right.
Now, the formula used to obtain the scores
takes into account
various characteristics of the vulnerability
and how the attacker is actually able
to leverage those characteristics, right.
So again, I'm actually sharing here FIRST website
that includes the standard specification.
They also include a calculator
that you can actually take advantage of
and many other resources
for you to become familiar with CVSS.
At the time of recording,
the latest version of CVSS was version three,
and that's actually what Cisco
and many other organizations actually now use
to determine the risk of a given vulnerability, right.
Now, there's several other things
that are actually taken into consideration, right,
and one thing is actually the chaining role,
and, you know, of a vulnerability
and fixing prioritization based on that chain, right.
Now, in many instances security vulnerabilities
are actually not exploited in isolation.
Threat actors actually exploit
more than one vulnerability in a chain,
and they do that to carry out their attacks
and compromise their victims.
Now, by leveraging different vulnerabilities in a chain,
attackers can actually infiltrate progressively
to further, you know, compromise the system and the network,
then gaining more control over it, right.
This is something that PSIRT teams are actually aware of
and must be aware of,
and developers, security professionals,
and users must also be aware of this chaining capabilities,
because they can actually change the order
in which the vulnerability needs to be fixed or patched,
you know, in the actual affected systems, right.
So, for example, you know,
multiple low severity vulnerabilities
can actually become severe,
if they're actually combined
to perform a specific action, right.
So performing vulnerability chaining
is not a trivial task, right,
any type of vulnerability can actually be chained.
So several commercial companies claim
that they can actually easily do it,
but the way that you can chain vulnerabilities
is actually pretty much endless, right.
Now a PSIRT can learn about vulnerabilities
in a product or service, you know,
during internal testing or at the development phase, right.
This, of course, is the preference of any vendor,
to be able to actually find the vulnerabilities
before somebody else finds it.
However, vulnerabilities can also be reported
by external entities, like security researchers,
customers, and other vendors, right.
Now the dream of every vendor is actually
to be able to find and patch all security vulnerabilities
during the design and development phases,
however, of course,
that's actually close to impossible, right.
Now, this is why a secure development life cycle, or an SDL,
is extremely important for any organization
that actually produces software and hardware.
Cisco has their own SDL program,
and it's actually documented at the link
that I'm actually sharing in here, right.
So Cisco defined the SDL as,
"A repeatable and a measurable process
"that actually they have designed
"to increase the resiliency
"and also the trustworthiness of their products."
Cisco's SDL is actually part
of the product development methodology,
or what they call PDM,
and it's also compliant with the ISO9000 Standard, right.
It actually includes,
you know, different areas,
but it's actually not limited to this list,
but here are some of the general concepts and topics
that it actually includes, right.
So that actually has a base product security requirement,
what they call a PSB, right.
Also, third party software security, right,
how you handle open source
and third party software vulnerabilities.
Secures design guidelines,
guidelines around secure coding, secure analysis,
and also vulnerability testing.
Now, the goal of the SDL is actually
to provide tools and processes
that are designed to accelerate
the product development methodology
by developing secure, resilient,
and trustworthy systems, right.
Now, third party software,
and, you know, open source security
is one of the most important tasks
for any organizations, right.
Most of today's organizations actually use
open source and third party software libraries, right.
Now, this creates two requirements
on the product security team.
The first one is actually to know
what third party software libraries are used and reused
within your company and where, right,
and the second one is, of course,
to patch any vulnerabilities that affect such library
or the third party software component.
So, for example,
if there's an vulnerability in open SSL or NTP,
you know, and it's actually disclosed today,
what do you actually have to do?
Can you quickly assess the impact
of those vulnerabilities in your products?
Also, if you use commercial third party software,
is the vendor of such software,
transparently disclosing all the security vulnerabilities?
You know, are they actually even gonna ask you for money,
if they they need to actually fix a vulnerability, right?
Nowadays, many organizations
are including security vulnerability disclosure SLAs,
in their contract with third party vendors, right.
This is very important,
as many third party software vulnerabilities,
both in the commercial space and also open source software,
go on patch for many, many months or even years, right.
Now, third party software security is a monumental task
for any company of any size, right.
To get a feeling of the scale
of third party software, you know, code usage,
visit webpages,
either of organizations that are making these libraries
or third party security bulletins published by Cisco
at the link that I'm actually sharing in here.
Now, another good resource is CVEdetails.com, right.
They actually have tons of statistics and data
around vulnerabilities and, you know,
specific vendors, right.
Now, there are many tools available in the market today
to enumerate all open source components used in a product.
Now these tools either interrogate the product source code
or scan binaries for the presence of third party software.
Here, are a few examples, but, of course,
there are many others out there.
The first one is actually Black Duck.
There's also AppCheck from Codenomicon.
Palamida, Lexumo, SourceClear,
and again, the list goes on and on.