WEBVTT

00:00.000 --> 00:04.485
>> Security implications of
cloud technology adoption.

00:04.485 --> 00:07.260
The learning objectives
for this lesson are to

00:07.260 --> 00:08.670
define business continuity and

00:08.670 --> 00:10.485
disaster recovery
with the cloud,

00:10.485 --> 00:13.275
to explore cloud encryption
and key management,

00:13.275 --> 00:16.245
and to define cloud log
collection and analysis.

00:16.245 --> 00:19.010
Let's get started. One of

00:19.010 --> 00:20.840
the biggest advantages
that the cloud

00:20.840 --> 00:22.880
can offer to an organization is

00:22.880 --> 00:24.560
help with their
business continuity

00:24.560 --> 00:25.925
and disaster recovery.

00:25.925 --> 00:29.255
However, before
any cloud adoption

00:29.255 --> 00:31.130
is considered for
an organization,

00:31.130 --> 00:34.130
they should conduct a
business impact assessment.

00:34.130 --> 00:36.200
This will allow them
to find areas of

00:36.200 --> 00:37.400
their company where maybe

00:37.400 --> 00:39.395
the cloud won't work
so well for them.

00:39.395 --> 00:40.790
An example of this would be

00:40.790 --> 00:43.700
legacy apps that might become
too expensive to try to

00:43.700 --> 00:45.830
shift them over to cloud or

00:45.830 --> 00:48.485
even have that be
a backup for them.

00:48.485 --> 00:51.320
However, if you are
able to define that

00:51.320 --> 00:53.060
your particular organization or

00:53.060 --> 00:55.880
your company is able to
use cloud technology,

00:55.880 --> 00:58.400
then this is one area
where it can really

00:58.400 --> 00:59.900
help and that's the
business continuity

00:59.900 --> 01:01.920
and disaster recovery.

01:03.110 --> 01:05.695
When you choose to do this,

01:05.695 --> 01:08.050
the company that you choose for

01:08.050 --> 01:10.570
these services becomes
your primary provider.

01:10.570 --> 01:12.070
Now the cloud offers

01:12.070 --> 01:14.035
significant advantages
and stability,

01:14.035 --> 01:15.720
scalability, and performance,

01:15.720 --> 01:17.320
and this is especially
true when we're

01:17.320 --> 01:19.510
talking about the larger
companies such as Amazon,

01:19.510 --> 01:22.705
AWS, Microsoft
Azure, and Google.

01:22.705 --> 01:24.880
But one thing you
want to keep in

01:24.880 --> 01:27.280
mind when you're moving
any resources to

01:27.280 --> 01:29.800
a cloud provider is that
you must do so within

01:29.800 --> 01:31.600
the legal and
regulatory restrictions

01:31.600 --> 01:33.745
that your organization is under.

01:33.745 --> 01:36.040
Shifting data to
another provider away

01:36.040 --> 01:38.350
from your direct
control might invoke

01:38.350 --> 01:39.760
additional restrictions and you

01:39.760 --> 01:41.290
need to make sure that this

01:41.290 --> 01:42.670
is handled properly when

01:42.670 --> 01:44.610
you're choosing your
primary provider.

01:44.610 --> 01:46.955
In addition, since they are now

01:46.955 --> 01:48.740
your primary provider for

01:48.740 --> 01:50.435
your backup and
disaster recovery,

01:50.435 --> 01:51.695
what are their plans?

01:51.695 --> 01:54.305
What do they have in place
to ensure your availability?

01:54.305 --> 01:55.910
Again, with your
larger providers,

01:55.910 --> 01:57.140
this is less of an issue,

01:57.140 --> 01:59.450
but it's definitely something
you want to address.

01:59.450 --> 02:01.265
Are they keeping
backups of your data

02:01.265 --> 02:03.595
offsite and away from
their data center?

02:03.595 --> 02:07.625
Or if their data center would
have come under attack,

02:07.625 --> 02:09.590
or have a natural disaster,

02:09.590 --> 02:10.925
or a fire,

02:10.925 --> 02:12.860
what would be their
ability to recover?

02:12.860 --> 02:14.195
Because if you need them

02:14.195 --> 02:15.635
and they're having
their own issue,

02:15.635 --> 02:17.790
then that becomes a problem.

02:18.310 --> 02:21.020
When you do your business
impact assessment

02:21.020 --> 02:22.355
or your risk assessment,

02:22.355 --> 02:23.900
you may end up finding that you

02:23.900 --> 02:25.415
need an alternate provider.

02:25.415 --> 02:27.470
This would be a backup
to your backup.

02:27.470 --> 02:29.375
Should your primary
provider fail,

02:29.375 --> 02:30.635
you would want to make
sure that you add

02:30.635 --> 02:32.040
a secondary for it.

02:32.040 --> 02:33.980
Then shifting operations from

02:33.980 --> 02:35.720
your primary provider can be

02:35.720 --> 02:38.030
an automated or manual process.

02:38.030 --> 02:40.175
Not all organizations
are going to need this,

02:40.175 --> 02:43.040
but those that really
need the availability and

02:43.040 --> 02:44.990
the ability to know
that they are going

02:44.990 --> 02:47.165
to be able to recover
should something happen,

02:47.165 --> 02:50.070
would have an
alternate provider.

02:51.290 --> 02:54.405
Encryption and key lifecycle.

02:54.405 --> 02:56.460
Encryption is critical for

02:56.460 --> 02:59.890
cloud data and this is
because anything that's

02:59.890 --> 03:02.500
sensitive that is no longer
in your direct control

03:02.500 --> 03:05.950
must be encrypted on the
cloud service provider.

03:05.950 --> 03:08.725
Not only must it be encrypted
while it's stored there,

03:08.725 --> 03:10.000
but it must be encrypted also

03:10.000 --> 03:11.890
while it's in use and in motion.

03:11.890 --> 03:14.275
Now, in the lessons on
cryptography that are coming up,

03:14.275 --> 03:15.460
we will go over in
a little bit more

03:15.460 --> 03:16.915
detail what that means.

03:16.915 --> 03:20.185
But again, because of legal
and compliance requirements,

03:20.185 --> 03:22.810
you need to make sure that
you are adhering to those

03:22.810 --> 03:23.980
and most of those are going to

03:23.980 --> 03:26.570
require that the
data be encrypted.

03:28.230 --> 03:30.460
In addition to that,
you're going to

03:30.460 --> 03:31.840
want to make sure you
have policies and

03:31.840 --> 03:32.950
procedures in place for the

03:32.950 --> 03:35.200
following: you want to
make sure that you are

03:35.200 --> 03:37.180
managing the lifecycle
of the keys that you're

03:37.180 --> 03:39.819
using for your encryption
and your key generation,

03:39.819 --> 03:41.785
the replacement,
and the revoking.

03:41.785 --> 03:43.465
You also want to make
sure that you have

03:43.465 --> 03:44.860
guidance in place for which

03:44.860 --> 03:46.885
cryptographic algorithms
and protocols

03:46.885 --> 03:48.910
are you going to
allow to be used.

03:48.910 --> 03:50.860
Some of these are no longer
secure and shouldn't be

03:50.860 --> 03:53.845
used and that needs to be
defined in your policies.

03:53.845 --> 03:55.870
How are you going to
handle your key storage

03:55.870 --> 03:56.920
and your key ownership?

03:56.920 --> 03:59.350
You want to make
sure that you're not

03:59.350 --> 04:00.760
putting your keys anywhere

04:00.760 --> 04:02.435
in the source code of your apps,

04:02.435 --> 04:04.420
and also that your keys aren't

04:04.420 --> 04:06.385
being stored in
public repositories.

04:06.385 --> 04:08.770
This has happened several
times where people's keys

04:08.770 --> 04:11.340
ended up in a GitHub
repository to be downloaded

04:11.340 --> 04:13.420
and then now that means
that the data could be

04:13.420 --> 04:16.590
decrypted by anyone that had
access to that repository.

04:16.590 --> 04:18.560
You also want to make
sure that you're rotating

04:18.560 --> 04:20.210
keys frequently and then

04:20.210 --> 04:22.565
key management and the
usage of the keys should

04:22.565 --> 04:26.070
be separate duties and not
performed by the same person.

04:28.280 --> 04:32.105
Let's talk about key
management system patterns.

04:32.105 --> 04:35.360
First, we have cloud-native
key management systems.

04:35.360 --> 04:37.670
This is a KMS that
is operated by

04:37.670 --> 04:40.820
the same company that provides
you the cloud services.

04:40.820 --> 04:43.845
We also have external
key origination.

04:43.845 --> 04:45.270
This is when the KMS is

04:45.270 --> 04:47.165
not the cloud
provider being used.

04:47.165 --> 04:49.175
It's a third party
at that point.

04:49.175 --> 04:52.504
We also have cloud service
using external KMS.

04:52.504 --> 04:54.965
It's similar to
the external above

04:54.965 --> 04:57.140
but this KMS has hardware that

04:57.140 --> 04:59.060
may be used by the
customer and it

04:59.060 --> 05:02.180
is exclusively used
by that customer.

05:02.180 --> 05:05.030
Then finally, we have
multi-cloud KMS.

05:05.030 --> 05:06.800
This is where the
KMS can be used by

05:06.800 --> 05:11.300
multiple clouds and multiple
clouds can use mini KMS's.

05:14.480 --> 05:17.580
Data dispersion
and bit splitting.

05:17.580 --> 05:20.900
Data dispersion is intentionally
spreading data across

05:20.900 --> 05:22.990
multiple storage
locations and/or

05:22.990 --> 05:25.850
cloud providers to ensure
that the data is safe.

05:25.850 --> 05:28.835
This offers increased
availability.

05:28.835 --> 05:31.730
Bit splitting or
cryptographic splitting is

05:31.730 --> 05:32.840
the practice of splitting

05:32.840 --> 05:35.030
encrypted data into
multiple parts,

05:35.030 --> 05:36.320
which are then stored in

05:36.320 --> 05:39.740
different storage locations
and then encrypted again.

05:39.740 --> 05:43.530
This offers higher
confidentiality.

05:44.540 --> 05:47.070
Serverless computing.

05:47.070 --> 05:50.150
All network architecture
is hosted in the cloud.

05:50.150 --> 05:51.455
We're not talking about

05:51.455 --> 05:53.900
any form of physical
server anymore.

05:53.900 --> 05:56.795
This is designed to replace
the local area network.

05:56.795 --> 06:00.020
Applications are functions
and microservices that

06:00.020 --> 06:01.400
interact with each other for

06:01.400 --> 06:03.415
handling different
client requests.

06:03.415 --> 06:05.315
The cloud will
create a container,

06:05.315 --> 06:07.010
and it will perform
the processing

06:07.010 --> 06:08.660
and then it will
destroy the container.

06:08.660 --> 06:10.700
Billing is handled
by the execution of

06:10.700 --> 06:12.845
time rather than hourly rates.

06:12.845 --> 06:14.195
You're going to be billed on

06:14.195 --> 06:18.990
how much time you're using
instead of by the hour.

06:19.270 --> 06:23.820
This is also known as
function as a service.

06:25.410 --> 06:29.395
Serverless computing
removes the need

06:29.395 --> 06:33.385
for anyone to have to manage
VMs or physical servers.

06:33.385 --> 06:35.740
The underlying
architecture is managed

06:35.740 --> 06:38.455
by the service provider
rather than the organization.

06:38.455 --> 06:41.440
They do have their
own security risks.

06:41.600 --> 06:43.735
One of these is because

06:43.735 --> 06:47.575
the best practices and use
cases are not very mature yet,

06:47.575 --> 06:49.210
as this is new technology,

06:49.210 --> 06:52.524
we don't really have a lot in
the way of best practices.

06:52.524 --> 06:54.130
It's very dependent on

06:54.130 --> 06:56.155
the service provider
that you've chosen.

06:56.155 --> 06:57.925
It's event-driven.

06:57.925 --> 06:59.455
When a client connects,

06:59.455 --> 07:02.215
multiple services are
called for authentication,

07:02.215 --> 07:06.980
session creation, load
allocations, and database access.

07:08.450 --> 07:11.230
Software-defined networking.

07:11.230 --> 07:13.820
This is known as
infrastructure as a code.

07:13.820 --> 07:15.410
It's partially facilitated by

07:15.410 --> 07:17.779
both physical and
virtual appliances

07:17.779 --> 07:20.675
that can be configured
using scripts and APIs.

07:20.675 --> 07:23.450
As network complexity
increases with

07:23.450 --> 07:26.045
more and more virtual resources
and physical devices,

07:26.045 --> 07:27.770
it becomes difficult to manage

07:27.770 --> 07:29.779
networks and security policies.

07:29.779 --> 07:31.385
Software-defined networking

07:31.385 --> 07:33.830
allows for fully
automated deployment

07:33.830 --> 07:36.305
or provisioning
of network links,

07:36.305 --> 07:39.030
appliances, and servers.

07:39.490 --> 07:43.385
Collecting and
managing cloud logs.

07:43.385 --> 07:45.500
Logging must be
enabled and set up

07:45.500 --> 07:48.005
properly so that logs
can be received.

07:48.005 --> 07:51.770
Logs must be directed to a
log management system that

07:51.770 --> 07:53.390
will collect all the logs being

07:53.390 --> 07:55.700
generated across
your cloud network.

07:55.700 --> 07:58.699
We're back to those legal
and regulatory frameworks.

07:58.699 --> 08:01.190
Those requirements
may also state that

08:01.190 --> 08:03.800
the use of log collection
and alerting is required.

08:03.800 --> 08:05.315
This is often the case.

08:05.315 --> 08:08.090
I use HIPAA from time
to time as an example,

08:08.090 --> 08:09.650
but HIPAA also wants to

08:09.650 --> 08:11.450
see that you're
collecting the logs,

08:11.450 --> 08:13.610
but also someone is
reviewing those logs.

08:13.610 --> 08:15.950
It's a lot easier on a
local network because

08:15.950 --> 08:19.100
it's easy to extract that
data on your local network.

08:19.100 --> 08:20.510
But you need to make sure that

08:20.510 --> 08:22.000
you're doing the same
thing in the cloud,

08:22.000 --> 08:23.690
all of those log
files are going to

08:23.690 --> 08:26.460
a central point where
they can be reviewed.

08:27.760 --> 08:32.680
Let's talk about some cloud
log monitoring services.

08:33.170 --> 08:35.660
AWS CloudTrail is

08:35.660 --> 08:39.085
an audit logging service
for AWS applications.

08:39.085 --> 08:42.440
AWS CloudWatch provides a
graphical reporting and

08:42.440 --> 08:45.875
analytics dashboard for
monitoring and alerting.

08:45.875 --> 08:49.130
Microsoft also has the
Microsoft Monitor Logs.

08:49.130 --> 08:51.170
This is collected
and organized in

08:51.170 --> 08:54.840
Azure and it can be
visualized in Azure portal.

08:55.990 --> 08:58.985
Cloud misconfigurations.

08:58.985 --> 09:01.250
Cloud misconfigurations
can cause

09:01.250 --> 09:04.460
any number of security
problems for an organization.

09:04.460 --> 09:07.580
For example, when services
are improperly provisioned on

09:07.580 --> 09:09.280
the cloud platform or

09:09.280 --> 09:11.260
maybe they have
improper permissions,

09:11.260 --> 09:13.250
unsecured data storage locations

09:13.250 --> 09:14.780
where maybe your data
is not encrypted,

09:14.780 --> 09:17.360
or permissions aren't
set properly on them,

09:17.360 --> 09:20.065
and leaving default
settings unchanged,

09:20.065 --> 09:22.805
or even worse, disabling
security controls.

09:22.805 --> 09:24.170
These are all common things

09:24.170 --> 09:25.670
that happen and you're
going to want to make sure

09:25.670 --> 09:27.890
that you take notice
of if you were to use

09:27.890 --> 09:30.305
Cloud technology for
your organization.

09:30.305 --> 09:31.760
I'm sure you've seen
in the news there were

09:31.760 --> 09:33.680
several times where
data was found on

09:33.680 --> 09:37.235
an open AWS bucket and

09:37.235 --> 09:39.530
the people had put
all information

09:39.530 --> 09:40.760
there where they collected

09:40.760 --> 09:42.410
information on millions of

09:42.410 --> 09:43.610
individuals and they were maybe

09:43.610 --> 09:44.990
going to use it for
marketing purposes,

09:44.990 --> 09:46.520
that type of thing,
and they just left

09:46.520 --> 09:48.200
it there with the
default configurations,

09:48.200 --> 09:50.360
no access control
on them whatsoever.

09:50.360 --> 09:53.270
Because of it, all
that information

09:53.270 --> 09:55.850
for all those millions of
people was then exposed.

09:55.850 --> 09:58.010
This usually happens
because of the lack of

09:58.010 --> 10:00.785
skills and lack of
change controls

10:00.785 --> 10:03.440
that we would normally
have in place

10:03.440 --> 10:06.290
to track these changes
or these settings.

10:06.290 --> 10:09.530
Not having those is a huge
problem and we need to

10:09.530 --> 10:10.910
make sure that all of

10:10.910 --> 10:12.575
these things are
checked off properly.

10:12.575 --> 10:13.950
The cloud is great but

10:13.950 --> 10:15.680
just like any other
form of technology,

10:15.680 --> 10:16.490
we have to make sure that

10:16.490 --> 10:18.900
we're implementing
them correctly.

10:20.480 --> 10:25.110
Cloud access security
broker or CASB.

10:25.110 --> 10:27.590
This is an enterprise
management tool

10:27.590 --> 10:29.000
that will help mediate access to

10:29.000 --> 10:32.345
cloud services by users
of all types of devices.

10:32.345 --> 10:34.445
Examples include Blue Coat,

10:34.445 --> 10:38.545
SkyHigh Networks, Microsoft
Cloud App Security.

10:38.545 --> 10:41.990
A cloud access security
broker will provide

10:41.990 --> 10:44.030
visibility into how clients and

10:44.030 --> 10:46.219
nodes are using cloud resources.

10:46.219 --> 10:48.350
For example, single sign-on

10:48.350 --> 10:51.185
authentication from
network to cloud provider.

10:51.185 --> 10:55.070
They also scan for malware
or non-compliant devices,

10:55.070 --> 10:57.890
and they can monitor and
audit user activities.

10:57.890 --> 11:00.770
This can help limit
data exfiltration by

11:00.770 --> 11:04.590
preventing access to
unauthorized cloud resources.

11:07.550 --> 11:10.410
Now, we can implement a cloud

11:10.410 --> 11:13.250
access security broker
in one of three ways.

11:13.250 --> 11:15.035
We can use it forward proxy,

11:15.035 --> 11:16.520
which is an appliance
that would be at

11:16.520 --> 11:18.170
the network edge
of the customer,

11:18.170 --> 11:20.120
and then traffic
will be directed to

11:20.120 --> 11:22.550
the cloud network
if policies allow.

11:22.550 --> 11:24.200
Now what this means
is we would set up

11:24.200 --> 11:28.610
specific policies for
access to the cloud and

11:28.610 --> 11:31.190
then whatever data match

11:31.190 --> 11:32.960
those policies would
be allowed to be

11:32.960 --> 11:35.195
sent through the proxy
to the cloud provider.

11:35.195 --> 11:37.145
We can also use a reverse proxy,

11:37.145 --> 11:38.660
and this is positioned
at the cloud

11:38.660 --> 11:40.460
network edge and it will direct

11:40.460 --> 11:42.005
traffic to the cloud services

11:42.005 --> 11:44.875
again if that traffic
matches the policies.

11:44.875 --> 11:47.330
Finally, we can use
an API which brokers

11:47.330 --> 11:49.370
connections between
a cloud provider and

11:49.370 --> 11:54.465
a customer. Let's summarize.

11:54.465 --> 11:55.890
In this lesson, we went over

11:55.890 --> 11:57.485
cloud and business continuity.

11:57.485 --> 12:01.210
We went over primary and
alternate providers for BCDR,

12:01.210 --> 12:03.825
we also discuss cloud
log management,

12:03.825 --> 12:05.935
encryption and the
key life cycle,

12:05.935 --> 12:07.925
and we went over
serverless computing,

12:07.925 --> 12:09.545
software-defined networks,

12:09.545 --> 12:11.780
and cloud access
security broker.

12:11.780 --> 12:14.290
Let's do some sample questions.

12:14.290 --> 12:18.230
Question 1; this type
of KMS pattern is where

12:18.230 --> 12:20.030
keys are not managed

12:20.030 --> 12:22.920
by the cloud provider
where the keys are used.

12:22.990 --> 12:28.695
External key
origination. Question 2;

12:28.695 --> 12:31.870
this allows for the fully
automated deployment

12:31.870 --> 12:33.865
or provisioning
of network links,

12:33.865 --> 12:36.260
appliances, and servers.

12:36.260 --> 12:40.815
Software-defined
networking. Question 3;

12:40.815 --> 12:42.690
if a BIA finds that

12:42.690 --> 12:47.410
a contingent cloud platform
is needed, this is called?

12:47.930 --> 12:50.770
Alternate provider. Keep in mind

12:50.770 --> 12:52.405
sometimes questions on the test

12:52.405 --> 12:53.755
will be exactly like this.

12:53.755 --> 12:55.780
You would be expected
to know what a BIA

12:55.780 --> 12:58.985
means and that's why it
will be written this way.

12:58.985 --> 13:02.830
A lot of times it will not be
spelled out and by knowing

13:02.830 --> 13:04.635
the term automatically
you should have

13:04.635 --> 13:07.980
a good idea of what the
answer is looking for.

13:08.420 --> 13:11.465
Finally, Question
4. True or false.

13:11.465 --> 13:13.280
Cloud services can be utilized

13:13.280 --> 13:15.305
by any organization
to save costs,

13:15.305 --> 13:18.265
increase scalability,
and security.

13:18.265 --> 13:22.085
This is false. Because
of legacy applications

13:22.085 --> 13:23.720
some organizations
with finite too

13:23.720 --> 13:26.015
costly to use cloud services.

13:26.015 --> 13:27.980
Well, that sums up this lesson.

13:27.980 --> 13:29.105
I hope it was helpful for you

13:29.105 --> 13:31.140
and I'll see you
in the next one.