WEBVTT

00:00:01.040 --> 00:00:02.930
Hi, my name is Zach Roof,

00:00:02.940 --> 00:00:06.690
and welcome to the cybersecurity course featuring Trivy.

00:00:06.690 --> 00:00:10.980
Trivy is primarily maintained by Teppei Fukuda.

00:00:10.990 --> 00:00:14.300
Now, Teppei, if you're listening to this and I totally butchered

00:00:14.300 --> 00:00:18.340
your name, just please forgive me. My intentions are pure. Okay,

00:00:18.340 --> 00:00:21.620
now if you go through Trivy's GitHub issues, you will witness

00:00:21.620 --> 00:00:23.760
Teppei's dedication to the project.

00:00:24.240 --> 00:00:26.460
I mean, in fact, Aqua Security,

00:00:26.470 --> 00:00:30.660
a security vendor, hired Teppei so he could work on Trivy full time.

00:00:31.140 --> 00:00:34.610
So obviously, I'm not the only one who has witnessed his

00:00:34.610 --> 00:00:38.900
dedication. Anyhow, I just want to thank Teppei and his sponsor,

00:00:38.900 --> 00:00:43.550
Aqua Security, for providing this wonderful project. Now, you

00:00:43.550 --> 00:00:45.860
might be wondering, well, what is Trivy?

00:00:46.340 --> 00:00:49.680
Well, Trivy is a simple and comprehensive vulnerability scanner for

00:00:49.680 --> 00:00:52.460
containers, suitable for continuous integration.

00:00:52.840 --> 00:00:54.290
Before we go further,

00:00:54.300 --> 00:00:57.520
I just want to say a prerequisite for this course is

00:00:57.520 --> 00:01:00.320
basic container or Docker knowledge.

00:01:00.330 --> 00:01:02.120
Now, if you don't have this knowledge,

00:01:02.130 --> 00:01:04.930
I'm going to do my best to fill in the gaps. However,

00:01:04.940 --> 00:01:06.760
if you're still feeling kind of left out,

00:01:07.140 --> 00:01:09.870
please check out the Getting Started with Docker course

00:01:09.880 --> 00:01:12.150
here, on Pluralsight. I highly recommend it.

00:01:12.740 --> 00:01:16.660
So in the next slide, we'll start to get a high‑level overview of Trivy.

00:01:17.240 --> 00:01:21.550
Trivy detects vulnerabilities within OS packages.

00:01:21.940 --> 00:01:25.590
Now this could be Alpine, Red Hat Enterprise Linux, Debian,

00:01:25.600 --> 00:01:26.960
Ubuntu, Amazon,

00:01:26.960 --> 00:01:32.650
Linux, the list goes on and on, and also, application dependencies.

00:01:33.040 --> 00:01:39.150
This could be Node, Ruby, Python, Java, etc. Trivy is also fast.

00:01:39.460 --> 00:01:42.870
The first Trivy scan will take roughly 10 seconds to complete.

00:01:43.170 --> 00:01:47.650
Subsequent scans will only take a few seconds. Now, other scanners can

00:01:47.650 --> 00:01:51.470
sometimes take up to 10 minutes on the first run and encourage you to

00:01:51.470 --> 00:01:54.500
maintain a vulnerability database. By contrast,

00:01:54.510 --> 00:01:58.860
Trivy's stateless and requires no maintenance or preparation.

00:01:58.860 --> 00:02:04.150
Now, because Trivy is fast, we can integrate Trivy directly into

00:02:04.150 --> 00:02:06.490
development workflows. In other words,

00:02:06.500 --> 00:02:10.090
as engineers update code, this code can be tested in

00:02:10.090 --> 00:02:12.050
real time for vulnerabilities.

00:02:12.640 --> 00:02:13.230
Okay,

00:02:13.240 --> 00:02:15.980
let's do a little framework action and see how Trivy fits

00:02:15.980 --> 00:02:18.160
into the NIST cybersecurity framework.

00:02:18.740 --> 00:02:24.130
The framework is divided into three parts, core, profile, and tiers. The

00:02:24.130 --> 00:02:28.000
framework core that is currently on the screen contains high‑level best

00:02:28.000 --> 00:02:32.990
practices for cybersecurity and risk management, in general. Trivy primarily

00:02:32.990 --> 00:02:36.060
sits within the identify and protect functions.

00:02:36.440 --> 00:02:38.150
Let's dive into this a little bit more.

00:02:41.340 --> 00:02:44.610
Then, this framework defines categories for every function.

00:02:44.680 --> 00:02:52.100
Trivy primarily sits within two categories, risk assessment and

00:02:52.110 --> 00:02:54.950
information protection processes and procedures.

00:02:55.740 --> 00:02:56.560
As they say,

00:02:56.570 --> 00:02:58.960
it's turtles all the way down, so let's dig into these

00:02:58.960 --> 00:03:01.050
specific subcategories for Trivy.

00:03:05.240 --> 00:03:06.210
As a brief aside,

00:03:06.220 --> 00:03:08.840
I'm going to quickly go through the framework sections so we

00:03:08.840 --> 00:03:10.850
can get to the demos as quickly as possible.

00:03:12.140 --> 00:03:16.730
First off, asset vulnerabilities are identified and documented, so Trivy

00:03:16.730 --> 00:03:22.040
will help us audit vulnerabilities within our Docker images, and

00:03:22.050 --> 00:03:26.030
configuration change control processes are in place. In this course,

00:03:26.030 --> 00:03:29.390
we're going to be leveraging GitHub Actions to implement change control

00:03:29.390 --> 00:03:31.850
processes through the lens of Trivy.

00:03:32.190 --> 00:03:32.780
In other words,

00:03:32.780 --> 00:03:37.440
we're going to be doing some pretty sweet automation. MITRE ATT&CK

00:03:37.440 --> 00:03:41.150
coverage for Trivy is going to setter upon the infrastructure analysis

00:03:41.150 --> 00:03:45.610
area. For the purposes of this course, we'll focus our defenses on two

00:03:45.620 --> 00:03:52.850
attack techniques. Supply chain compromise.

00:03:53.440 --> 00:03:55.270
So within the context of this course,

00:03:55.280 --> 00:03:58.450
this is really software supply chain compromise.

00:03:58.840 --> 00:03:59.740
In other words,

00:03:59.750 --> 00:04:03.180
one of the packages that is used by an application such as

00:04:03.180 --> 00:04:07.750
Python or a package that is used by the operating system has a

00:04:07.750 --> 00:04:12.480
disclosed vulnerability. Notice that I say disclosed. Trivy does

00:04:12.480 --> 00:04:14.240
not find new vulnerabilities.

00:04:14.250 --> 00:04:17.240
It simply looks up the version of a given package in its

00:04:17.250 --> 00:04:19.760
own internal vulnerability database.

00:04:20.339 --> 00:04:20.880
Now,

00:04:20.890 --> 00:04:23.500
the information in this database comes from publicly

00:04:23.500 --> 00:04:25.260
available vulnerability feeds.

00:04:25.740 --> 00:04:29.270
Okay, and the second attack we're going to see in this course, implant

00:04:29.280 --> 00:04:33.250
container image. When an attacker uploads a malicious Docker image

00:04:33.250 --> 00:04:37.250
directly to the Docker registry, we need a way to check for this

00:04:37.250 --> 00:04:40.520
tampering and also to do forensics on the image.

00:04:40.530 --> 00:04:44.560
We're going to do this forensics through Google's container‑diff

00:04:44.940 --> 00:04:47.960
and through Trivy. It's going to be pretty sweet.

00:04:48.340 --> 00:04:52.090
Now we're going to check out the MITRE Shield section. In

00:04:52.090 --> 00:04:54.560
particular, we see the MITRE ATT&CK technique,

00:04:54.940 --> 00:04:59.350
supply chain compromise, mapped to the MITRE Shield active defense.

00:04:59.740 --> 00:05:03.140
In this course, we're going to see examples of these defenses.

00:05:03.400 --> 00:05:07.070
So first off is decoy network. A defender can install any

00:05:07.070 --> 00:05:11.320
suspect hardware or software on an isolated system or network

00:05:11.330 --> 00:05:13.660
and monitor for non‑standard behaviors.

00:05:14.140 --> 00:05:18.220
We're going to do this leveraging a GitHub feature called GitHub Actions.

00:05:18.230 --> 00:05:20.050
It's going to be pretty awesome.

00:05:20.440 --> 00:05:24.450
Now we see the second attack technique in this course, implant container image.

00:05:24.530 --> 00:05:27.550
This is mapped to the behavioral analytics defense.

00:05:28.040 --> 00:05:32.990
Now a defender can monitor user interactions with images and containers to

00:05:32.990 --> 00:05:36.650
identify ones that are added or altered anomalously.

00:05:37.140 --> 00:05:38.000
In this course,

00:05:38.000 --> 00:05:40.910
we're going to be looking at the signatures of Docker images

00:05:41.090 --> 00:05:44.500
and see when tampering is present. At a very high level, we're

00:05:44.500 --> 00:05:46.350
going to view how Trivy works.

00:05:47.940 --> 00:05:50.660
It all starts with the Docker image registry.

00:05:51.140 --> 00:05:55.230
The registry houses Docker images. Now as far as

00:05:55.230 --> 00:05:57.040
where the registry can be located,

00:05:57.050 --> 00:06:02.260
it can be in your data center or cloud, or it could be hosted by a third party.

00:06:02.640 --> 00:06:05.040
In this course, we're going to be using Docker Hub, a

00:06:05.040 --> 00:06:09.310
third‑party Docker registry. The server uses a Docker image

00:06:09.320 --> 00:06:11.460
to instantiate a Docker container.

00:06:12.140 --> 00:06:14.960
This container can contain anything.

00:06:15.340 --> 00:06:19.360
For example, the container on the screen can be a running Apache Server.

00:06:20.140 --> 00:06:24.010
And, in general, this process is similar to how a virtual machine

00:06:24.020 --> 00:06:27.250
image is used as the basis for a virtual machine.

00:06:27.740 --> 00:06:31.550
The virtual machine is instantiated from the virtual machine image.

00:06:32.940 --> 00:06:34.610
The attackers.

00:06:34.620 --> 00:06:36.380
Okay, so what are they doing?

00:06:36.390 --> 00:06:39.150
Well, there's a couple of different attack paths here.

00:06:39.540 --> 00:06:43.760
First, they can upload a malicious image directly to the Docker registry.

00:06:44.340 --> 00:06:46.630
Now an example of this could be, say,

00:06:46.630 --> 00:06:50.360
a version of Apache that contains the Heartbleed vulnerability.

00:06:50.940 --> 00:06:54.760
So the next time the server downloads the Docker image and runs the container,

00:06:54.770 --> 00:06:56.160
it will now be vulnerable.

00:06:56.640 --> 00:07:00.360
The other attack path is just to exploit the Docker container directly.

00:07:00.840 --> 00:07:04.950
For example, the Apache Docker container isn't up to date on patches.

00:07:05.340 --> 00:07:08.220
In that case, the attacker could use Metasploit or some other

00:07:08.220 --> 00:07:11.360
offensive framework to exploit these various weaknesses.

00:07:12.140 --> 00:07:15.760
Trivy audits Docker images that are housed within this registry.

00:07:16.540 --> 00:07:20.960
In this course, we will find proactive ways to mitigate both attack paths.

00:07:21.190 --> 00:07:25.120
Alright, while these diagrams were needed to lay our foundation,

00:07:25.180 --> 00:07:28.310
I'm starting to get some PowerPoint fatigue. From here on out,

00:07:28.320 --> 00:07:31.340
we'll be in the demo environment getting some hands‑on experience.

00:07:31.470 --> 00:07:33.850
Next up is installing the demo environment.