In this lesson,
we're going to discuss
the Security Content Automation Protocol.
Now, the Security Content Automation Protocol,
also known as SCAP, or SCAP,
plays a vital role in maintaining the security posture
of an organization's technology infrastructure.
The Security Content Automation Protocol is
a suite of open standards
that enhances the automation of vulnerability management,
measurement and policy compliance,
evaluation of systems
that are deployed across your organization.
So what exactly is SCAP?
Well, SCAP was developed
by the National Institute of Standards and Technology,
known as NIST,
and is designed to provide organizations
with a standardized approach
to maintaining the security of their systems
and includes a number of components
that are used together to automate security tasks,
including vulnerability scanning, configuration checking,
and software inventory.
Now, the security content automation protocol is
a NIST framework that outlines various accepted practices
for automating vulnerability scanning
by adhering to standards for scanning processes,
results reporting and scoring,
as well as vulnerability prioritization.
SCAP is also heavily used
with internal and external compliance requirements
because of all the different vulnerability scanners
and tools will now support the same SCAP-formatted data.
This makes it really easy to transfer information
from one tool to another tool
because they're all speaking that exact same language,
which we call SCAP.
Now, there are three main languages
that are used inside a SCAP.
These are OVAL, XCCDF, and ARF.
The first one we have is OVAL, which is pronounced oval.
Now OVAL is the Open Vulnerability and Assessment Language,
which is an XML schema for describing system security states
and querying vulnerability reports and information.
OVAL is used to describe the systems information,
the machine state,
and the reporting for a given scan target.
OVAL will allow us to have a consistent
and interoperable way
of collecting and assessing information
about all of our targets,
regardless of what tool's actually used to conduct the scan
and vulnerability assessment of that target.
Second, we have XCCDF.
Now, XCCDF is
the Extensible Configuration Checklist Description Format,
which is also an XML schema,
but this one is used for developing and auditing
best-practice configuration checklist and rules.
Before XCCDF was available,
the best practice guides were long documents
containing step-by-step guidance
that told you exactly what to check.
Each one might include 30 or 40 or 50 pages
of detailed information.
And during an assessment,
you would print out that guide
and then manually check all the steps in that guide
one by one as you went through it.
By migrating to XCCDF, though,
we can now use scanning tools and automation
to check our systems
against those best practice guidelines
using the XCCDF machine-readable format
that can then be applied and validated
using compatible software.
Now, if your software doesn't support
performing these checks automatically,
it can still be used as your checklist
as you're performing the manual steps
and collecting your responses in that software tool as well,
making XCCDF a really great option for you to consider.
The third one we have is known as ARF.
Now, ARF stands for the Asset Reporting Format.
And this is, again, an XML schema.
But it's being used to express information about the assets
and the relationships between the assets and the reports.
The standardized ARF data model is going to help us facilitate
reporting, correlating, and fusing of asset information
throughout and between our different organizations.
ARF is really great
because it's vendor and technology neutral,
and it makes it very flexible
and well-suited to a wide variety of reporting applications.
Now, in addition to these three languages
used by the Security Content and Automation Protocol,
or SCAP, we're also going to be supporting
three different methods of enumerating our assets.
These are known as CCE, CPE, and CVE.
Now first we have CCE.
CCE is the Common Configuration Enumeration.
The CCE is a scheme
for provisioning secure configuration checks
across multiple sources.
Essentially, CCE is a collection
of configuration best practice statements
that allows us to have these configurations
and then use an automated tool
to verify they're actually being properly used.
The Common Configuration Enumeration will then go ahead
and provide us with the unique identifiers
for different system configuration issues.
That way we can quickly and accurately get a correlation
of the configuration data
across multiple information sources and tools.
Second, we have CPE.
Now, CPE stands for the Common Platform Enumeration.
The Common Platform Enumeration is a scheme
for identifying hardware devices,
operating systems and applications.
CPE is written in a machine-readable format
that begins with cpe:/
and then is a series of information
that's separated by colons.
Now, the standard format of a CPE message is
cpe:/part:vendor:product:version:update:edition:language.
Now, each platform being shared as a CPE will then be sent
in this format.
For example, the part portion of the CPE refers
to whether or not the platform is
actually an operating system, an application,
or a piece of hardware.
And to do this, we list this as either O, A, or H,
depending of if it's an operating system, application,
or piece of hardware.
Third, we have CVEs.
Now, a CVE is the Common Vulnerabilities and Exposures.
The Common Vulnerabilities and Exposures is
a list of records where each item contains
a unique identifier
that's used to describe a publicly known vulnerability.
Each CVE begins with CVE, followed by the year,
and then a unique number.
For example, if you search the CVE of CVE-2017-0144,
this indicates this was a common vulnerability
that was first identified back in 2017,
and it was the 144th vulnerability
that was identified that year.
If you look up the description of this unique vulnerability,
you'll see it's a vulnerability
that affects Microsoft Windows operating systems.
It's associated with an SMB protocol vulnerability.
If you dig into this a little bit more,
you'll start to see a description of the vulnerability,
some references about the vulnerability,
how the vulnerability can be exploited,
and what you can do to stop or patch this vulnerability
on your systems.
Now, this particular CVE is actually pretty well known.
And if you've been in the cybersecurity world for a while,
you've probably heard of the CVE,
which is known as EternalBlue as its nickname,
which is CVE-2017-0144.
Now, technically, EternalBlue is actually the tool
that was used to exploit this SMB vulnerability,
but most people in our industry started using it
interchangeably to call it the EternalBlue vulnerability
when they were talking about CVE-2017-0144.
Now, why do you care about EternalBlue?
What makes it so important?
Well, back in 2017,
this vulnerability was used by the WannaCry ransomware
and it was spreading all over the internet.
WannaCry was assigned
to exploit this specific vulnerability.
So if you looked up CVE-2017-0144
and you followed the suggestions
for installing the hot fix that Microsoft released,
or to disable SMB V1,
this was actually going to make sure
you are not vulnerable to this exploit
because only SMB V1,
or people who missed the software patch,
would be exploited
as WannaCry started spreading across the internet.
Next, we need to talk about how SCAP is going to be used
to provide us with a metric system
that's going to be called the CVSS,
or Common Vulnerability Scoring System.
Now, there are currently multiple versions of CVSS,
but the latest version is CVSS 3.
CVSS 3 is going to be used to provide a numerical score
to reflect the severity of a given vulnerability.
This score ranges from 0 to 10,
and this score will then be translated
into a qualitative rating
of how serious of vulnerability it is
by calling it either none, low, medium, high, or critical.
If you have a CVSS score of zero,
then it's going to be considered none
in terms of its criticality.
If you have a score between 0.1 and 3.9,
it's going to be considered low.
If you have a score between 4.0 and 6.9,
it's considered medium.
If you have a score between 7.0 and 8.9,
it's considered high.
And if you have a score of 9.0 to 10.0,
it's considered critical.
Now, while these scores are helpful
in aiding in your determination
of how critical vulnerability really is,
it does not account for any mitigation
that you may already have in place inside of your networks.
For example, the EternalBlue vulnerability is rated
as an 8.1 on the CVSS 3 scale,
making it a high level of criticality.
But if your network already has SMB V1 disabled
before the exploit for the vulnerability was discovered,
guess what?
You're not subject to this attack
and it would become very low
on your priority list of criticality
in terms of remediation efforts
because you're already protected against it.
Finally, let's discuss the use of SCAP
inside of benchmarking,
which is one of the reasons for using SCAP
in the first place.
Now, a benchmark is a set of configuration rules
for some specific set of products
to provide a detailed checklist
that can be used to secure the systems
back to a specific baseline.
These benchmarks are usually going to be expressed
in the Extensible Configuration
Checklist Description Format,
known as XCCDF,
which is an XML format specifying security checklist
and reporting results of security benchmarks
for your compliance and testing.
Now, there are many SCAP benchmarks available for use
by a variety of different system applications,
including things like Red Hat Enterprise Linux Benchmarks
and the Center for Internet Security's
Microsoft Windows 10 Enterprise Benchmarks.
For example, if you're using
the Red Hat Enterprise Linux Benchmarks,
these provide you a comprehensive set of configuration rules
for Red Hat Enterprise Linux Servers
that includes rules for configuring system authentication,
setting up your firewalls,
configuring your system logging, and much more.
The CIS Microsoft Windows 10 Enterprise Benchmark
will also provide you a set of security configuration rules
by this time
for the Microsoft Windows 10 Enterprise Edition,
which includes rules for the user account control,
data execution prevention, system firewall settings,
and much more.
These benchmarks when used
with a SCAP-compliant tool can help organizations
automate the process of maintaining system security
and ensuring that your systems are configured correctly
and that vulnerabilities are being identified and mitigated.
So remember, the Security Content Automation Protocol,
or SCAP,
is a suite of open standards
designed to automate vulnerability management, measurement,
and policy compliance evaluation.
SCAP benchmarks are set of security configuration rules
for specific sets of products,
and there are three main languages used in SCAP,
including OVAL, XCCDF, and ARF.
When you're using SCAP for benchmarking,
you're usually going to be using the XCCDF,
or Extensible Configuration Checklist Description Format,
with your SCAP-compliant tools
to help your organization to automate the process
of maintaining your system security.