WEBVTT 00:07.430 --> 00:12.530 Any type of enterprise environment needs to be set up from the get go as a secure environment, and 00:12.530 --> 00:18.320 putting security at the basis or the foundation of our environment makes a lot more sense than coming 00:18.320 --> 00:23.780 in halfway through the process and then spending an exorbitant amount of monies, uh, as well as time 00:23.780 --> 00:29.030 and manpower and labor, to go back through and reconfigure items or change items to ensure that secure 00:29.060 --> 00:29.690 environment. 00:29.690 --> 00:30.230 Further. 00:30.230 --> 00:35.090 It's never as secure that it could have been if it was designed from the outset as just being secure. 00:35.090 --> 00:39.350 Within this chapter, we're going to talk about different hardware mechanisms, the different configurations, 00:39.350 --> 00:40.730 policies and procedures. 00:40.760 --> 00:44.870 But we're really going to dive into a zero trust environment as well as what that entails. 00:44.870 --> 00:49.730 We're going to discuss secure access, secure edge and how it's intertwined within our enterprise environment. 00:49.730 --> 00:55.310 And then finally software defined networks and how those are utilized to ensure rapid scalability and 00:55.310 --> 00:58.400 security as a modern technology has evolved. 00:58.970 --> 01:04.540 Now, our segmentation is the art of segmenting our networks away from one another, meaning that if 01:04.540 --> 01:07.390 I have one network that's operating on one department. 01:07.420 --> 01:13.750 Say operations, and I have another department say HR operating on another part of our network, I really 01:13.750 --> 01:15.760 don't want the two to intertwine with each other. 01:15.760 --> 01:22.210 There's no reason for HR to have access to our servers or our IT infrastructure or anything that encompasses 01:22.300 --> 01:23.140 technology. 01:23.140 --> 01:24.280 That's not their job. 01:24.280 --> 01:29.290 At the same point, we don't want to have our operations department, i.e. our IT specialists and our 01:29.290 --> 01:31.870 cybersecurity people talking to HR. 01:31.900 --> 01:36.340 That doesn't mean we don't want them talking to HR, but we don't want to have access to HR information. 01:36.370 --> 01:41.650 HR has a lot of compliance regulations and federal mandates in place, and it just doesn't make sense 01:41.650 --> 01:45.190 for having IT guys to have access to that data or that information. 01:45.220 --> 01:50.200 We call that network segmentation, but it provides us a little bit more details as far as security 01:50.200 --> 01:55.150 is concerned as well, by not allowing those two departments to talk to each other through technology. 01:55.180 --> 01:57.250 We're also making more secure environment. 01:57.250 --> 02:03.520 If our HR department accidentally clicks on phishing link, they now do not have access into our, uh, 02:03.520 --> 02:05.620 operations department's infrastructure. 02:05.620 --> 02:11.550 This provides kind of a line in the sand that says, hey, you guys are split, and even if one department 02:11.550 --> 02:15.480 is taken over or has malware, it's not going to affect our entire company. 02:15.510 --> 02:18.150 Network segmentation provides us some security in that. 02:18.150 --> 02:23.700 In that aspect, it also provides us some performance capabilities by having the HR department set up 02:23.700 --> 02:28.320 as their own little subnet within our infrastructure environment, they're going to be able to talk 02:28.320 --> 02:32.880 to one another a lot quicker than if they were combined with other departments, as their different 02:32.880 --> 02:35.220 IP addresses kind of go through the process. 02:35.250 --> 02:40.530 Also, there's different servers that are usually related or reserved for different departments. 02:40.530 --> 02:46.230 And so having HR specific to an HR server, which is in the same segment, allows for better performance 02:46.230 --> 02:50.520 and management, those of those different types of infrastructure. 02:51.360 --> 02:53.490 Finally, there's a compliance point of it, right? 02:53.520 --> 03:01.470 If I'm doing IPS or PCI, DSS or HIPAA or some other form of regulatory requirement for compliance, 03:01.470 --> 03:07.830 I need to make sure that my systems are separated that they're encrypted, and that access is only the 03:07.830 --> 03:13.070 way it's supposed to go, whether you're dealing with PCI, DSS or HIPAA or FERPA or any of those other 03:13.070 --> 03:19.340 requirements that come into play, we need to make sure that compliance is at the forefront of our network 03:19.340 --> 03:19.970 architecture. 03:20.000 --> 03:27.680 Usually, segmentation provides us a lot of movement or a lot of of delineation between those two different 03:27.680 --> 03:28.280 departments. 03:28.310 --> 03:33.800 A zero trust environment is usually what we go for at any type of security infrastructure. 03:33.800 --> 03:37.040 That means that we're going to verify everything that you tell us, right? 03:37.070 --> 03:40.160 Zero trust means I don't trust you as far as I can throw you. 03:40.190 --> 03:42.440 You've probably heard that scene before, right? 03:42.470 --> 03:46.160 But when it comes to it, it's literally what we're going to utilize. 03:46.160 --> 03:51.350 You can come in and say, hi, my name is Chet, and I'm here to teach cybersecurity, but you're going 03:51.350 --> 03:52.520 to ask me, what's your ID? 03:52.820 --> 03:54.440 Can you provide a Pin number for that? 03:54.470 --> 03:58.760 And let's use some multifactor authentication to verify what you just told us. 03:58.790 --> 04:04.730 Verification in a zero trust environment really is authenticating authentication where we're going through. 04:04.730 --> 04:09.260 And we're saying, I need you to provide more than just the Pin number and username that you're associated 04:09.260 --> 04:12.730 with your account, so that we can verify you are who you say you are. 04:12.760 --> 04:15.010 There's the least privileged aspect as well. 04:15.010 --> 04:21.730 If I'm an IT guy or a cyber guy and I work specifically with servers, then I don't need access to, 04:21.760 --> 04:23.800 say, client machines or endpoints. 04:23.830 --> 04:26.140 Maybe my job has nothing to do with firewalls. 04:26.140 --> 04:30.580 By using the principle of least privilege, we're only allowed to have access to things that we need. 04:30.610 --> 04:34.630 And since we talked about HR department, that's an aspect of least privilege. 04:34.660 --> 04:39.550 My IT guys do not need access to air, and air does not need access to it. 04:39.790 --> 04:41.500 That's a principle of least privilege. 04:41.530 --> 04:46.690 Often you'll see in least privileged, uh, within the least privileged environment where somebody gets 04:46.690 --> 04:52.780 promoted or moved out or changed to a different department, or maybe their their roles within that 04:52.780 --> 04:53.950 department has changed. 04:53.950 --> 04:58.510 When I worked for a different company, my primary responsibility was actually at the switch, where 04:58.510 --> 05:03.160 we would control different cellular towers and how those towers interacted with one another. 05:03.160 --> 05:04.300 That was my job. 05:04.300 --> 05:07.960 I was the guy that programmed all those cell towers to talk to one another. 05:07.990 --> 05:11.050 We call that handovers, and there was a lot of programming that went into it. 05:11.050 --> 05:12.400 That was my first job. 05:12.430 --> 05:16.650 Then I moved on to actually cell towers and working on the equipment at the bottom of the towers. 05:16.650 --> 05:21.750 When that occurred, my privileges to the cell infrastructure, to the switch infrastructure was cut 05:21.750 --> 05:22.110 off. 05:22.140 --> 05:26.130 There was no reason for me to have continued access into that switch environment. 05:26.130 --> 05:30.330 And when I went over to cell towers, they then allowed me to work on the equipment at the bottom of 05:30.330 --> 05:30.930 the towers. 05:30.930 --> 05:35.640 I gained permissions to work on that role of it so that least privilege goes both ways. 05:35.640 --> 05:40.200 We want to cut off, and we only want to provide access to the tools that we actually need to do the 05:40.200 --> 05:40.740 job. 05:40.740 --> 05:44.130 We want to continually monitor those users as well. 05:44.130 --> 05:49.530 If I give my HR department access to HR tools, then I need to monitor what they're doing. 05:49.530 --> 05:53.370 We're not just going to say, oh yeah, you work at HR and say you have access to all these tools, 05:53.370 --> 05:54.150 and that's great. 05:54.150 --> 05:56.010 We want to monitor and see what they're doing. 05:56.010 --> 06:02.520 If you see a user that's never used the server that we put in place for them that had PII data on it, 06:02.520 --> 06:05.100 then it may be time to cut off that access point. 06:05.130 --> 06:10.500 However, if they suddenly start accessing it at 2 a.m. in the morning and they never had before, then 06:10.500 --> 06:15.420 that monitoring is going to lead us into a problem, and we need to identify that problem very quickly, 06:15.420 --> 06:18.060 very efficiently and then they cut it off before it starts. 06:18.060 --> 06:23.970 So that continual monitoring, a process not only between roles and job functions, also provides us 06:23.970 --> 06:26.250 a little bit of latitude when it comes to security. 06:26.550 --> 06:32.070 Our Secure Access Secure Edge, or Sassing, is an environment that is software based, providing a 06:32.070 --> 06:37.980 simplified management structure to consolidate items such as firewalls with secure gateways and a zero 06:37.980 --> 06:45.090 trust network access point that unifies our cloud native model into an infrastructure that allows flexibility 06:45.180 --> 06:48.480 and secured methodologies when it comes into that environment. 06:48.510 --> 06:53.580 Fastly enhances an organization's security posture by controlling access and swiftly identifying and 06:53.580 --> 06:56.520 mitigating those threats within a cloud based architecture. 06:56.550 --> 07:02.220 They combine network and security functions and allow for a zero trust, access based environment that 07:02.220 --> 07:06.660 allows us to quickly identify different threats and threat vectors. 07:07.800 --> 07:13.830 A software defined network, or Sdn, provides a centralized point to configure different aspects of 07:13.830 --> 07:14.640 our network. 07:14.640 --> 07:19.630 When you think a software defined network, realize that it is basically just a regular network that 07:19.630 --> 07:23.020 you may see on prem, but it's utilized in sort of configurations. 07:23.020 --> 07:24.580 We're using programmability. 07:24.610 --> 07:31.450 We're using the process of software to identify and manage our software in a seamless environment that 07:31.450 --> 07:32.830 is also on demand. 07:32.860 --> 07:37.480 This means that while we've talked about a virtual environment or containerized environment, to quickly 07:37.510 --> 07:43.060 scale up or scale back different aspects of our enterprise environment within an Sdn, we can actually 07:43.060 --> 07:43.690 do that. 07:43.690 --> 07:46.390 This is the focal point of network architecture. 07:46.390 --> 07:52.840 Within that environment, within a virtual network, we identify different network segmentations zero 07:52.840 --> 07:58.240 trust, SAS and Sdn and went through the different processes and how they interact with one another. 07:58.270 --> 08:03.040 The main points you need to get out of this different chapter was that we need to put network security 08:03.040 --> 08:06.130 at the forefront and bring it from the foundation up. 08:06.130 --> 08:10.480 If you're trying to implement security infrastructure in the middle or even at the end of your network, 08:10.510 --> 08:11.740 you're going to find gaps. 08:11.740 --> 08:13.090 You're not going to get everything. 08:13.090 --> 08:19.540 And so proper planning really does lead to a more effective and more secure network infrastructure utilizing 08:19.540 --> 08:21.850 either SAS or Sdn within our environment.