WEBVTT 00:00:00.140 --> 00:00:04.600 One of the best ways an organization can reduce the blast 00:00:04.600 --> 00:00:08.670 radius from the threats previously mentioned is to implement 00:00:08.680 --> 00:00:11.330 zero‑trust cloud architecture. 00:00:11.840 --> 00:00:16.610 The five steps to zero‑trust, as exemplified by John Kindervag, 00:00:16.610 --> 00:00:19.460 would include defining a protect surface, 00:00:19.460 --> 00:00:23.760 map transaction flows, architect your zero‑trust network, 00:00:23.760 --> 00:00:26.870 create a zero‑trust policy, and finally, 00:00:26.930 --> 00:00:32.659 to be focusing on monitoring and maintaining the zero‑trust network. From 00:00:32.659 --> 00:00:37.000 the standpoint of defining the protect surface, organizations should 00:00:37.000 --> 00:00:41.170 think about what is their DAAS, or their data, 00:00:41.180 --> 00:00:46.510 the applications, the assets, and the services. Knowing what's important, 00:00:46.520 --> 00:00:51.360 what's critical to the survival of your business in these four spaces 00:00:51.370 --> 00:00:56.270 is integral to being able to architect a zero‑trust environment. 00:00:56.270 --> 00:01:01.670 Mapping transaction flows means that the technologist is going to have 00:01:01.670 --> 00:01:06.710 to understand what do the major transactions in the organization 00:01:06.720 --> 00:01:11.020 accomplish? This means that they are trading in their technology hat 00:01:11.020 --> 00:01:12.160 for the business hat. 00:01:12.320 --> 00:01:16.590 How well do you understand the interdependencies of 00:01:16.590 --> 00:01:18.950 the functionality of your business? 00:01:18.960 --> 00:01:24.480 How well do you understand the profit and loss that could occur based upon 00:01:24.480 --> 00:01:28.470 how a transaction is successful or is not successful? 00:01:28.480 --> 00:01:32.320 It's okay to start with an approximation of understanding what 00:01:32.320 --> 00:01:36.130 these transactions are, but think of it being an iterative 00:01:36.130 --> 00:01:38.890 process where you gain more clarity, 00:01:38.890 --> 00:01:43.090 the more you go through it. When architecting the zero‑trust network, 00:01:43.100 --> 00:01:47.930 this means that you have to think of your environment as being 00:01:47.930 --> 00:01:52.070 one that is created for your business success. 00:01:52.080 --> 00:01:53.170 So, in essence, 00:01:53.180 --> 00:01:58.030 it can't be based upon just a generic schema, but has to be based 00:01:58.030 --> 00:02:01.440 upon what it is that you do. The protect surface that you are 00:02:01.440 --> 00:02:07.410 investigating now becomes, at a minimum, a layer‑7 examination of 00:02:07.420 --> 00:02:10.669 everything that goes on in the network. You are going to be thinking 00:02:10.669 --> 00:02:15.640 about the identification and authentication of applications of users, 00:02:15.640 --> 00:02:17.950 and also of content. 00:02:18.240 --> 00:02:21.600 Rudyard Kipling had a famous poem that said, 00:02:21.610 --> 00:02:26.640 "I keep six honest serving men, they taught me all I knew; their names are what 00:02:26.640 --> 00:02:32.860 and why and when and how and where and who." It is those six questions of 00:02:32.870 --> 00:02:37.600 existence that need to be asked in the zero‑trust policy that's being 00:02:37.600 --> 00:02:42.290 developed. The zero‑trust policy should not only think about who the asserted 00:02:42.290 --> 00:02:47.550 id is, but what is it that's being accessed, the protect surface of that 00:02:47.560 --> 00:02:52.650 asserted id. Here, we're getting a micro‑segmented layer of understanding of 00:02:52.650 --> 00:02:57.620 how it's going to be used. When that user is accessing, it could be an 00:02:57.620 --> 00:02:59.050 imperative. For instance, 00:02:59.060 --> 00:03:04.580 if a user normally logs in between 8 a.m. and 5 p.m., but now we see that 00:03:04.580 --> 00:03:09.410 there's activity occurring between 10:30 p.m. and 1 a.m., that may actually 00:03:09.410 --> 00:03:14.360 be a sign to say the authentication should not be successful. Where it's 00:03:14.360 --> 00:03:19.340 coming from and where it's going to, as far as the access goes, and here's a 00:03:19.340 --> 00:03:25.800 deeper question to ask, almost ontological in nature: why is the id 00:03:25.800 --> 00:03:27.100 attempting to access it? 00:03:27.110 --> 00:03:32.630 If your zero‑trust policy engine interrogates the why, you may 00:03:32.640 --> 00:03:36.180 actually find out that why was okay today, 00:03:36.190 --> 00:03:38.820 but there is no justification for it tomorrow. 00:03:38.830 --> 00:03:43.140 Also, how? Think of the amount of data that's being consumed. 00:03:43.150 --> 00:03:48.240 The policy enforcement engine could look at something like a remote desktop 00:03:48.240 --> 00:03:54.280 protocol and see that so much data is being pulled out or pushed in. That 00:03:54.280 --> 00:03:58.540 could also be a sign that an attack is occurring. The final stage of 00:03:58.540 --> 00:04:01.160 zero‑trust says to maintain and monitor. 00:04:01.170 --> 00:04:06.970 So the analysis is continuous and what may be an overbearing and unuseful 00:04:06.980 --> 00:04:11.690 amount of information from an event perspective would be inclusive in the 00:04:11.690 --> 00:04:16.029 monitoring that's happening with a zero‑trust policy engine. The more, the 00:04:16.029 --> 00:04:21.480 better. Also, introducing other types of capabilities in the monitoring that 00:04:21.490 --> 00:04:25.950 actually can be more predictive about behavior and about threats that are 00:04:25.950 --> 00:04:27.450 occurring in the environment.