WEBVTT

00:00.559 --> 00:04.290
>> Secure infrastructure design.

00:04.290 --> 00:07.485
The learning objectives
for this lesson are to

00:07.485 --> 00:10.305
configure networks to
achieve resiliency,

00:10.305 --> 00:13.365
to create networks
for scalability,

00:13.365 --> 00:15.360
and to discover how automation

00:15.360 --> 00:16.859
>> can aid us in networking.

00:16.859 --> 00:20.760
>> Let's get started.
Scalability is

00:20.760 --> 00:22.290
your ability to expand

00:22.290 --> 00:23.700
your network with

00:23.700 --> 00:26.115
the changing needs of
your organization.

00:26.115 --> 00:28.065
For example, if you have

00:28.065 --> 00:31.230
a sudden burst in
traffic onto one of

00:31.230 --> 00:33.120
your web servers and you needed

00:33.120 --> 00:35.340
additional processing power and

00:35.340 --> 00:38.035
memory to be able to handle
that burst of traffic,

00:38.035 --> 00:40.455
that would be an example
of vertical scalability

00:40.455 --> 00:42.630
where you could add
that on the fly.

00:42.630 --> 00:45.520
You could add additional
processing power or memory

00:45.520 --> 00:48.535
or even storage to an
individual system.

00:48.535 --> 00:51.925
With horizontal
scalability, we are

00:51.925 --> 00:53.590
adding additional servers that

00:53.590 --> 00:55.225
are processing the
same workload.

00:55.225 --> 00:56.740
This is an example
of clustering.

00:56.740 --> 01:00.055
If we have three servers and
one of them were to fail,

01:00.055 --> 01:03.260
the other two would continue
processing the workload.

01:04.220 --> 01:06.729
Some examples of scalability

01:06.729 --> 01:08.845
would be a Content
Delivery Network.

01:08.845 --> 01:10.990
This is when you had
additional servers that are

01:10.990 --> 01:13.770
delivering the same
data to end users.

01:13.770 --> 01:16.785
This is an example of
horizontal scaling.

01:16.785 --> 01:18.535
We can also use caching,

01:18.535 --> 01:20.380
which makes copies of
data that either doesn't

01:20.380 --> 01:22.240
change often or maybe
it never changes.

01:22.240 --> 01:23.920
By doing this, we are

01:23.920 --> 01:26.840
improving the load
times for that data.

01:27.280 --> 01:31.580
Resiliency. This enables you to

01:31.580 --> 01:35.870
recover if a part or even your
whole system were to fail.

01:35.870 --> 01:37.445
How quickly you're
able to do that,

01:37.445 --> 01:39.725
is measured by how
resilient you are.

01:39.725 --> 01:43.190
You can offer high
availability of resources so

01:43.190 --> 01:45.110
that in the event

01:45.110 --> 01:47.075
you have an increased
demand or failure,

01:47.075 --> 01:48.995
you're able to recover from it.

01:48.995 --> 01:52.085
But by adding in these
types of things,

01:52.085 --> 01:54.275
we're increasing the
complexity and the cost

01:54.275 --> 01:56.885
and the overall management
of our network.

01:56.885 --> 01:58.580
If we add an additional servers

01:58.580 --> 02:00.365
or a second wired connection,

02:00.365 --> 02:01.700
that increases our costs,

02:01.700 --> 02:04.040
but it also makes it harder
for us to do our jobs.

02:04.040 --> 02:07.380
We have to factor that in
more building our plans.

02:09.010 --> 02:12.365
We can use course of
action orchestration.

02:12.365 --> 02:15.335
These are automated responses
to specific events.

02:15.335 --> 02:17.585
When we need additional
memory on the fly,

02:17.585 --> 02:18.890
that memory can be added to

02:18.890 --> 02:21.650
a specific system so that
we can scale vertically.

02:21.650 --> 02:24.125
We can also use
distributed allocations,

02:24.125 --> 02:26.000
which is where we
spread workloads across

02:26.000 --> 02:28.580
multiple units that are
all working together.

02:28.580 --> 02:31.565
Replication allows
us to copy the data

02:31.565 --> 02:32.840
to another location where it

02:32.840 --> 02:34.900
can be used most effectively.

02:34.900 --> 02:36.680
Lastly, we have clustering,

02:36.680 --> 02:37.790
which is when we group servers

02:37.790 --> 02:39.740
together to distribute
the workload.

02:39.740 --> 02:41.735
This allows us for failover.

02:41.735 --> 02:43.445
When one of the servers dies,

02:43.445 --> 02:47.220
the other servers in the
cluster will continue working.

02:48.380 --> 02:51.920
Virtualization.
This is sometimes

02:51.920 --> 02:53.840
something that can be
complicated for some people,

02:53.840 --> 02:55.715
so we're going to spend a
little bit of time on it.

02:55.715 --> 02:57.590
But virtualization at its core,

02:57.590 --> 02:59.180
is simply running

02:59.180 --> 03:02.200
multiple operating systems
on the same computer.

03:02.200 --> 03:05.375
Virtualization requires
three main parts.

03:05.375 --> 03:07.145
The first is the host hardware.

03:07.145 --> 03:10.880
This is the actual computer
that will be used for this.

03:10.880 --> 03:13.345
The second is the hypervisor.

03:13.345 --> 03:16.730
The hypervisor is the
virtualization software that

03:16.730 --> 03:18.815
manages how the virtual machines

03:18.815 --> 03:20.705
interact with the hardware.

03:20.705 --> 03:23.900
Lastly, we have our
guest operating system,

03:23.900 --> 03:26.545
our virtual machines,
or instances.

03:26.545 --> 03:29.030
If you're using a
type 2 hypervisor,

03:29.030 --> 03:30.070
which we'll get
into in a moment,

03:30.070 --> 03:32.450
you still have to have a
base operating system on

03:32.450 --> 03:36.140
the hardware to be able to
serve up the virtual machines.

03:36.140 --> 03:39.205
But if you're using a type
1, then you don't need that.

03:39.205 --> 03:42.320
That brings us to the
types of virtualization.

03:42.320 --> 03:45.305
Type 1 is also known
as bare metal.

03:45.305 --> 03:48.080
It doesn't need an operating
system installed on

03:48.080 --> 03:52.075
the hardware so that you can
install virtual machines.

03:52.075 --> 03:54.120
It's often easier to understand

03:54.120 --> 03:55.990
this by starting with type 2,

03:55.990 --> 03:57.350
because that's what
most people are

03:57.350 --> 03:59.000
familiar with by maybe

03:59.000 --> 04:02.345
using something like VMware
Workstation or VirtualBox.

04:02.345 --> 04:04.100
But with a type 2,

04:04.100 --> 04:06.140
you have to install
an operating system

04:06.140 --> 04:07.325
first on the hardware,

04:07.325 --> 04:08.990
say for example, Windows 10,

04:08.990 --> 04:11.900
and then you install
VirtualBox on top of that,

04:11.900 --> 04:13.700
and then you create a
virtual machine with

04:13.700 --> 04:16.685
VirtualBox that allows you
to run Linux, for example.

04:16.685 --> 04:20.150
However, with type
1 hypervisors,

04:20.150 --> 04:22.240
we eliminate the
Windows 10 layer

04:22.240 --> 04:24.775
and the hypervisor takes
over for all that for us.

04:24.775 --> 04:26.060
This is more efficient because

04:26.060 --> 04:27.470
now we don't have
to have resources

04:27.470 --> 04:31.820
dedicated for the
operating system.

04:31.820 --> 04:33.410
The hypervisor can
take that and give

04:33.410 --> 04:35.390
it all back to the
virtual machines.

04:35.390 --> 04:36.890
Some examples of a type

04:36.890 --> 04:39.305
1 hypervisor are:
Microsoft Hyper-V,

04:39.305 --> 04:43.285
XEN, Proxmox, and VMware ESXI.

04:43.285 --> 04:46.510
Examples of type 2
would be VirtualBox,

04:46.510 --> 04:49.810
VMware Workstation, and
Parallels Workstation.

04:51.090 --> 04:54.975
We can also use application
virtualization.

04:54.975 --> 04:56.750
This is when a client or user,

04:56.750 --> 04:59.275
accesses an app that's
hosted on a server.

04:59.275 --> 05:01.900
This almost always takes

05:01.900 --> 05:04.175
place through the
user's browser.

05:04.175 --> 05:07.420
This allows us to virtualize

05:07.420 --> 05:09.970
specific applications
that are served from

05:09.970 --> 05:11.320
a single server and it's

05:11.320 --> 05:13.615
served through the
user's browser.

05:13.615 --> 05:16.180
Some examples of this
are Microsoft App-V,

05:16.180 --> 05:18.320
XenApp, and ThinApp.

05:19.490 --> 05:22.470
Containerization.

05:22.470 --> 05:24.250
This is also known

05:24.250 --> 05:27.145
as operating system-level
virtualization.

05:27.145 --> 05:28.705
But instead of a hypervisor,

05:28.705 --> 05:30.620
it uses the system's kernel.

05:30.620 --> 05:33.550
It creates a virtual environment

05:33.550 --> 05:37.270
with the bare minimum needed
parts for an app to run.

05:37.270 --> 05:39.790
This allows us to
have a performance

05:39.790 --> 05:42.370
benefits because it
doesn't need a hypervisor.

05:42.370 --> 05:45.890
An example of containerization
would be Docker.

05:48.290 --> 05:51.315
Virtual desktop infrastructure.

05:51.315 --> 05:54.805
Desktops are completely
virtualized and ran from servers.

05:54.805 --> 05:56.320
This separates the user from

05:56.320 --> 05:58.165
a physical machine completely.

05:58.165 --> 06:00.410
We have three deployment models.

06:00.410 --> 06:01.925
The first is hosted.

06:01.925 --> 06:03.905
It's provided by a third party.

06:03.905 --> 06:07.100
Centralized is hosted within
the enterprise itself.

06:07.100 --> 06:08.945
Lastly, we have synchronized,

06:08.945 --> 06:10.010
which allows for work to

06:10.010 --> 06:12.245
continue even if
you're disconnected.

06:12.245 --> 06:14.515
This requires more
local resources.

06:14.515 --> 06:17.015
I remember back in
the very old days,

06:17.015 --> 06:18.710
we used to have terminals

06:18.710 --> 06:20.660
that you might have seen some of

06:20.660 --> 06:22.790
these with the green screens,

06:22.790 --> 06:25.280
or even sometimes there were
amber and all the work was

06:25.280 --> 06:28.745
done on a server in the back,

06:28.745 --> 06:31.160
and each person only
got an actual terminal.

06:31.160 --> 06:33.755
Then we shifted
everything towards PCs,

06:33.755 --> 06:37.045
and the work shifted towards
being done on the local PC.

06:37.045 --> 06:39.320
Now, we're shifting
back to again,

06:39.320 --> 06:40.340
because of the Cloud and

06:40.340 --> 06:42.575
also this virtual
desktop infrastructure,

06:42.575 --> 06:45.470
shifting everything back to
everything can be done on

06:45.470 --> 06:46.940
another server or in the Cloud

06:46.940 --> 06:49.010
instead of being done
on the local computer.

06:49.010 --> 06:52.340
It's a cyclical way
of doing things.

06:52.340 --> 06:53.720
We've been here before and

06:53.720 --> 06:55.700
it doesn't necessarily
mean that this way is

06:55.700 --> 06:57.500
better or that having

06:57.500 --> 06:59.180
everything on a local
workstation is better.

06:59.180 --> 07:00.200
It's just the nature of how

07:00.200 --> 07:02.640
things change with
the technology.

07:05.480 --> 07:09.495
Here are some virtual
desktop vulnerabilities.

07:09.495 --> 07:11.490
We can have VM escape.

07:11.490 --> 07:12.710
This is when you jump from

07:12.710 --> 07:14.690
one virtual machine to another.

07:14.690 --> 07:17.340
We can also have
privilege escalation.

07:17.340 --> 07:18.950
Once you're in one VM as

07:18.950 --> 07:21.140
a regular user, by
using exploits,

07:21.140 --> 07:25.295
you can escalate your way up
to become a privileged user.

07:25.295 --> 07:28.235
We have live VM migration,

07:28.235 --> 07:30.110
which is a feature
that's built into

07:30.110 --> 07:31.880
some hypervisors that allows for

07:31.880 --> 07:33.170
that VM to be copied to

07:33.170 --> 07:36.035
another server while
it's still in use.

07:36.035 --> 07:38.075
However, if it is not
configured correctly,

07:38.075 --> 07:39.440
an attacker could
do the same thing

07:39.440 --> 07:40.910
and copy it to another machine

07:40.910 --> 07:44.395
so that they could get into
it and use it for an attack.

07:44.395 --> 07:45.970
We also have data remnants,

07:45.970 --> 07:47.810
which are pieces of
data that were left

07:47.810 --> 07:50.760
behind from previous
virtual machines.

07:52.240 --> 07:54.770
Methods of automation.

07:54.770 --> 07:57.820
This is automation in
our Cloud deployments.

07:57.820 --> 07:59.370
The first is bootstrapping.

07:59.370 --> 08:02.300
This is an automated way
to deploy an instance.

08:02.300 --> 08:04.760
We may have scripts
set up and that would

08:04.760 --> 08:07.190
contain settings, and apps,

08:07.190 --> 08:08.510
and things that we
want to install

08:08.510 --> 08:09.695
in that particular instance,

08:09.695 --> 08:12.980
and with using bootstrapping,

08:12.980 --> 08:15.140
we can have all that
done automatically.

08:15.140 --> 08:16.895
We also have auto-scaling,

08:16.895 --> 08:19.490
which dynamically
adjusts the resources

08:19.490 --> 08:21.380
that we have based
on the current need.

08:21.380 --> 08:24.170
Going back to my example
of we have a spike in

08:24.170 --> 08:25.820
traffic and we maybe need to

08:25.820 --> 08:27.880
add additional processing
power and memory,

08:27.880 --> 08:30.240
this can be done automatically.

08:32.030 --> 08:36.049
Security orchestration,
automation, and response.

08:36.049 --> 08:40.580
This is an automated response
to a security incident.

08:40.580 --> 08:42.560
Incident response is usually

08:42.560 --> 08:44.450
a long list of items
that have to be

08:44.450 --> 08:48.710
performed when a given
threat is spotted.

08:48.710 --> 08:50.300
But because these types of

08:50.300 --> 08:52.385
situation cause a lot of stress,

08:52.385 --> 08:54.760
it often makes
things easy to skip.

08:54.760 --> 08:57.695
We can create these
into playbooks,

08:57.695 --> 08:59.450
which are simply scripts that

08:59.450 --> 09:01.780
are performed when an
incident is observed.

09:01.780 --> 09:04.970
SOAR can scan the threat
data collected from

09:04.970 --> 09:06.410
various sources and then run

09:06.410 --> 09:10.260
the responses in these
playbooks automatically for us.

09:12.460 --> 09:15.505
Let's summarize what we
went over in this video.

09:15.505 --> 09:17.125
We discussed scalability,

09:17.125 --> 09:19.180
both horizontally
and vertically.

09:19.180 --> 09:22.415
We discussed methods
to achieve resiliency.

09:22.415 --> 09:25.880
We also discussed automation
and Cloud deployments.

09:25.880 --> 09:27.800
Finally, we went
over virtualization

09:27.800 --> 09:29.820
and containerization.

09:29.960 --> 09:32.145
Let's do some questions.

09:32.145 --> 09:35.180
Example 1, what
technology allows for

09:35.180 --> 09:37.340
multiple redundant
processing nodes they

09:37.340 --> 09:41.040
share data with each other
to accept connection?

09:41.600 --> 09:46.680
Clustering. Example 2,

09:46.680 --> 09:48.960
VMware, Proxmox, Xen,

09:48.960 --> 09:50.690
and Hyper-V are all examples of

09:50.690 --> 09:53.550
which type of virtualization.

09:54.190 --> 10:00.610
Type 1 hypervisors. Question 3,

10:00.610 --> 10:05.560
what is operating system
virtualization also known as?

10:06.020 --> 10:11.775
Containerization. Question 4,

10:11.775 --> 10:13.520
adding additional resources to

10:13.520 --> 10:15.139
a system such as processors,

10:15.139 --> 10:18.985
memory, and storage is
which type of scalability?

10:18.985 --> 10:22.505
That is vertically
or vertical scale.

10:22.505 --> 10:24.680
I hope this lesson
was helpful to you,

10:24.680 --> 10:26.940
and I'll see you
on the next one.