WEBVTT

00:00:00.540 --> 00:00:02.810
So, let's say as an organization,

00:00:02.810 --> 00:00:07.510
you are performing an audit, or an audit is being performed on you,

00:00:07.510 --> 00:00:11.430
maybe it's an internal audit, and it's not the audit that we talked

00:00:11.430 --> 00:00:17.400
about from the major providers. We have to know that depending on the

00:00:17.400 --> 00:00:19.850
depth and purpose of the audit,

00:00:19.860 --> 00:00:23.750
there may be a need to prove out the effectiveness of control by

00:00:23.750 --> 00:00:28.570
means of some type of testing. Audit scope restrictions will make

00:00:28.570 --> 00:00:34.830
it so that we have acceptable and unacceptable testing periods, and

00:00:34.830 --> 00:00:37.610
we have to make sure that the environment is protected from

00:00:37.620 --> 00:00:39.140
destructive practices.

00:00:39.150 --> 00:00:44.060
We also need to ensure that there's reduced impact upon

00:00:44.070 --> 00:00:46.900
operational or live environments.

00:00:46.910 --> 00:00:51.870
Some cloud service providers do not allow certain types of testing.

00:00:51.880 --> 00:00:58.030
Things like denial‑of‑service are not allowed by a number of platforms.

00:00:58.040 --> 00:01:00.640
So it's up to us to ensure that we understand what

00:01:00.640 --> 00:01:02.460
the cloud service provider allows.

00:01:02.540 --> 00:01:04.330
Amazon, for instance,

00:01:04.340 --> 00:01:09.990
has a set of services that it says are permitted when it comes

00:01:09.990 --> 00:01:14.670
to penetration testing, on systems like EC2 instances, Elastic

00:01:14.670 --> 00:01:16.470
load balancers and CloudFront,

00:01:16.480 --> 00:01:21.060
but it doesn't allow things like zone walking or port

00:01:21.060 --> 00:01:24.050
flooding and other DDoS activities.

00:01:24.050 --> 00:01:28.300
So it's important for us to be able to understand that. All other

00:01:28.300 --> 00:01:33.540
testing requires preauthorization and permission. In the introduction to

00:01:33.540 --> 00:01:38.050
testing rules of engagement, not only does Azure say that you must

00:01:38.050 --> 00:01:39.900
follow all the rules stated in the policy,

00:01:39.900 --> 00:01:43.960
but any damage your testing causes to Microsoft or any customers

00:01:43.960 --> 00:01:47.500
makes you responsible, and penalties include suspension or

00:01:47.500 --> 00:01:50.510
termination of service for any violation.

00:01:50.520 --> 00:01:55.620
So they have things that are in scope and things that are actually prohibited.

00:01:55.630 --> 00:01:56.330
For instance,

00:01:56.340 --> 00:02:00.020
they have rules against generating large amounts of

00:02:00.020 --> 00:02:03.020
traffic. Google, on the other hand,

00:02:03.030 --> 00:02:07.820
as you review the top three providers and you get into their

00:02:07.820 --> 00:02:11.590
penetration testing policies, they have always allowed

00:02:11.590 --> 00:02:14.030
penetration testing on your own project,

00:02:14.040 --> 00:02:18.640
and they have the most scaled‑down policy statement of the top three providers.

00:02:18.700 --> 00:02:24.040
It's literally in this paragraph that you see here. The reason why is a

00:02:24.040 --> 00:02:28.160
completely different story for a different period of time.

00:02:28.170 --> 00:02:30.420
If you look up BeyondCorp,

00:02:30.430 --> 00:02:34.760
you will find the answer as to why they're so open about being able to

00:02:34.760 --> 00:02:38.010
test and why they actually don't express prohibitions,

00:02:38.010 --> 00:02:43.550
besides not taking illegal actions against another customer or Google.