WEBVTT 00:07.130 --> 00:11.960 As a cyber security expert, you'll often come into contact with different scanning or scanning principles 00:11.960 --> 00:13.040 that you need to be aware of. 00:13.070 --> 00:18.140 A lot of times we need to do vulnerability scanning as part of our compliance or regulatory contractual 00:18.140 --> 00:19.100 obligations. 00:19.100 --> 00:24.080 Whatever the case, you need to understand that special considerations need to be made in most cases 00:24.080 --> 00:27.080 when it comes to scanning processes in place. 00:27.110 --> 00:29.390 Now we're not just talking about scanning as a whole. 00:29.390 --> 00:30.950 We're talking about scheduling. 00:30.950 --> 00:37.460 And when scheduling occurs for any type of scanning on your network, it can have some unforeseen consequences 00:37.460 --> 00:42.440 on that network in which you're scanning, whether it's the entire network or a single machine. 00:42.440 --> 00:47.180 The fact is, is that sometimes we need to juggle what we're doing and how we're doing it. 00:47.210 --> 00:51.980 We need to juggle risk within the process of scanning along with our impact. 00:52.010 --> 00:56.090 How is it going to affect the profitability of our network or our company as a whole? 00:56.090 --> 01:01.680 What resources are available and how it affects those assets as you're scanning for vulnerabilities. 01:01.950 --> 01:04.830 Scheduling is obviously the first take that comes into mind. 01:04.860 --> 01:09.180 Most of our vulnerability scanning or scanning in part, is going to be done during the maintenance 01:09.180 --> 01:09.720 window. 01:09.750 --> 01:13.950 Now every organization has their own maintenance window that they utilize. 01:13.950 --> 01:17.220 Sometimes it's from 10:00 pm at night until 6 a.m. in the morning. 01:17.220 --> 01:20.640 Sometimes you get lucky and that maintenance window is in the middle of the day. 01:20.670 --> 01:25.140 Each organization is going to be different, and they're going to set aside their own maintenance window, 01:25.170 --> 01:29.700 where we can do a lot of different things to our IT systems, that it's not going to cause a lot of 01:29.700 --> 01:31.530 problems for our network as a whole. 01:31.560 --> 01:36.360 Usually this is judged on two factors profitability of the organization as a whole. 01:36.390 --> 01:41.520 Because if I'm scanning servers and they accidentally drop, then that could cause a loss in profitability. 01:41.550 --> 01:43.200 It also has to do with workflow. 01:43.230 --> 01:48.180 How are they people that are usually working during that time frame affected by the scanning that I'm 01:48.180 --> 01:48.900 conducting? 01:48.900 --> 01:54.180 This is a performance issue that you need to be aware of when you're scanning for vulnerabilities outside 01:54.180 --> 01:55.470 of the maintenance window. 01:55.620 --> 02:02.800 However, sometimes we have an incident that occurs within our organization that requires us to scan, 02:02.830 --> 02:07.720 scan for vulnerabilities, or scan our network as a whole for rogue devices or other aspects within 02:07.720 --> 02:08.500 our network. 02:08.530 --> 02:14.680 When we take into account that aspect, we need to look at criticality of our systems as well as the 02:14.680 --> 02:15.880 impact that it has. 02:15.910 --> 02:18.640 Now, we're not just looking at the impact of our scanning. 02:18.640 --> 02:20.920 We're looking at the impact of the network as a whole. 02:20.920 --> 02:27.460 I can scan a single server, and if I have five servers all doing the same aspect or the same job function, 02:27.460 --> 02:33.040 and there are only at a 40% load, it's really not going to affect the network as a whole if I send 02:33.040 --> 02:34.810 that single server. 02:34.810 --> 02:38.500 However, what else is attached to that piece of networking device? 02:38.500 --> 02:43.630 Let's say that I have to scan multiple departments or a single department for a piece of malware, or 02:43.630 --> 02:45.610 a vulnerability associated with it. 02:45.640 --> 02:51.160 Could the impact cause a negative impact to the profitability or operations within our network as a 02:51.160 --> 02:51.640 whole? 02:51.640 --> 02:56.020 If the case is yes, then we have to do some special considerations in place. 02:56.020 --> 03:02.360 How does that negative effect affect the entire action of our servers and our network and our security 03:02.360 --> 03:05.930 within that network to the operations of our company as a whole. 03:05.930 --> 03:10.040 When we're taking this into an aspect, we need to look at the whole picture. 03:10.040 --> 03:12.770 We can't just look at it from a cybersecurity standpoint. 03:12.770 --> 03:16.130 If we look at it purely from a cybersecurity standpoint, we go security. 03:16.160 --> 03:16.580 Security. 03:16.610 --> 03:17.030 Security. 03:17.060 --> 03:17.900 Security. 03:17.930 --> 03:20.510 And we don't pay any attention to availability. 03:20.540 --> 03:25.130 The availability factor is what comes into play for the normal people that are coming into our business 03:25.130 --> 03:30.650 on a day to day basis, whether it's employees or consumers, and we need to take that into account. 03:30.680 --> 03:33.890 The second aspect that we need to be aware of is priority. 03:33.920 --> 03:39.290 Priority takes place when maybe I have an incident or some type of environment that's taking place. 03:39.290 --> 03:41.690 But I also have something big going on. 03:41.690 --> 03:47.330 Maybe there's a giant product launch where we're expecting a lot of traffic on our networks, and by 03:47.330 --> 03:51.080 scanning it, we could unintentionally provide a loss of profitability. 03:51.080 --> 03:53.540 There's also resources that are coming into play. 03:53.540 --> 03:59.350 If we're launching a new product and we're expecting a major traffic load on those servers that normally 03:59.350 --> 04:01.540 operate at only a 40% capacity. 04:01.570 --> 04:05.620 We expect an 80% capacity because we're going through a new product launch. 04:05.620 --> 04:08.350 Then we have a problem with our resources. 04:08.350 --> 04:12.820 However, sometimes I could have an incident that's affecting one network, and instead of scanning 04:12.820 --> 04:15.730 the entire network, maybe I can segment it off. 04:15.730 --> 04:21.460 Maybe in this terms I have a HR department where we're having a major product launch, and normally 04:21.460 --> 04:26.200 I would have to scan the entire environment, but because it's regulated to a specific department or 04:26.200 --> 04:31.420 departments that don't have a lot to do with that product launch, I can scan those specific segments 04:31.420 --> 04:32.470 one at a time. 04:32.500 --> 04:35.350 In this scenario, HR doesn't have a lot to do. 04:35.380 --> 04:40.030 Let's segment it off and scan the HR department during the day to try and clear up that problem. 04:40.030 --> 04:43.480 And then we'll come back to the servers at night during the maintenance window. 04:43.510 --> 04:48.280 Whatever the case, when we go through priority, we need to look at the overall picture and how it 04:48.280 --> 04:51.310 encompasses our profitability of our environment as a whole. 04:51.340 --> 04:53.800 Sometimes the priority needs to be security. 04:53.830 --> 04:55.540 However, sometimes it's not. 04:55.540 --> 04:57.570 And that's something that we just need to be aware of. 04:57.600 --> 05:01.440 As cyber security professionals, we can't always have our cake and eat it too. 05:01.470 --> 05:04.110 Even though we'd really like to only work during the day. 05:05.370 --> 05:08.790 Other considerations that need to come into place is our sensitivity levels. 05:08.790 --> 05:11.580 And we're not talking about how sensitive the HR department is. 05:11.580 --> 05:16.110 When we start scanning their services in the middle of the day, we're more talking about the data that's 05:16.110 --> 05:17.550 secured on those levels. 05:17.550 --> 05:23.700 So when we're talking about this, while we scan the HR level, there may be a server or servers that 05:23.700 --> 05:25.800 have sensitive data associated with it. 05:25.830 --> 05:29.550 We need to be aware of those sensitive data levels on those systems. 05:29.550 --> 05:34.170 Let's take back our product launch example again I have a product launch. 05:34.170 --> 05:36.240 We're expecting a lot of traffic going on there. 05:36.240 --> 05:40.560 And our HR department has a server that may have some malware associated with it. 05:40.560 --> 05:45.030 Because of an incident that's occurring, we could segment it off and go in and start scanning it, 05:45.030 --> 05:47.190 and that would still fall within our priority list. 05:47.190 --> 05:49.260 But let's take this into a different level. 05:49.260 --> 05:54.510 Let's say that HR department is planning on onboarding a lot of brand new employees today because it's 05:54.510 --> 05:57.720 Monday and they normally on board 50 new employees. 05:57.720 --> 05:59.790 This ties up a lot of their resources. 05:59.790 --> 06:05.430 However, we discover a piece of vulnerability or a piece of malware affecting a vulnerability of their 06:05.430 --> 06:11.640 systems, and one of those malwares is affecting the sensitivity or the data associated with PII on 06:11.640 --> 06:15.420 our systems, that PII has a high sensitivity level. 06:15.420 --> 06:20.070 And because of that, we deem it to be very important, and we need to shore up that vulnerability as 06:20.070 --> 06:21.060 soon as possible. 06:21.060 --> 06:28.410 In this case, the sensitivity level of the data that they are securing takes context or priority over 06:28.410 --> 06:30.180 the onboarding of new employees. 06:30.180 --> 06:34.230 We need to secure that data because the data sensitivity level is high. 06:34.230 --> 06:39.300 If the data sensitivity level was low, i.e. HR is just doing random stuff on their computers. 06:39.300 --> 06:45.720 And it could be, you know, some basic, uh, word documents or Excel documents, and it's going to 06:45.750 --> 06:46.860 interrupt their day. 06:46.890 --> 06:52.890 Maybe it doesn't take priority, maybe because the impact or the level of the malware is only affecting 06:52.890 --> 06:55.440 those levels, and they're doing a lot of onboarding. 06:55.450 --> 06:57.790 we deem it to not be a higher priority. 06:57.790 --> 07:00.340 This is where sensitivity levels really come into play. 07:00.370 --> 07:02.860 Regulatory compliance is another factor. 07:02.860 --> 07:08.620 We could have regulatory compliance based on HIPAA or PCI, DSS or any number of other factors that 07:08.620 --> 07:14.230 come into play that require us to scan and immediately deal with that vulnerability, regardless of 07:14.230 --> 07:19.510 what's going on within the systems, we could also have contractual obligations that state, hey, our 07:19.510 --> 07:25.000 servers must be free of malware based on these delimiters that we need to be aware of. 07:25.030 --> 07:30.610 Both regulatory compliance and contractual obligations will dictate a lot of times what we have to do 07:30.640 --> 07:32.140 as cyber security professionals. 07:32.140 --> 07:36.670 They will also dictate whether or not we can move forward based on the priority. 07:36.670 --> 07:42.370 In this context, we're updating the priority to a higher level based on those compliance and contractual 07:42.400 --> 07:44.590 obligations, and they take precedence. 07:44.590 --> 07:49.060 However, sometimes regulatory compliances aren't a factor and we don't have to deal with them. 07:49.300 --> 07:54.190 Throughout this episode, we talked about different special considerations in terms of both scheduling 07:54.190 --> 07:56.960 and Sin City levels when it comes to different data sets. 07:56.960 --> 08:02.210 We also talked about contractual and legal obligations that we may have based on what we're storing 08:02.210 --> 08:03.320 within our systems. 08:03.320 --> 08:09.110 Within the CSA exam, you can expect to see different levels or scenarios based on exactly what we talked 08:09.110 --> 08:09.890 about today. 08:09.890 --> 08:14.840 They may provide you a scenario based on different priorities, and they would go through and maybe 08:14.840 --> 08:20.180 ask a question like you are tasked with doing a vulnerability scan based on an incident with a very 08:20.180 --> 08:24.020 low priority that is affecting minimal systems throughout your environment. 08:24.020 --> 08:28.520 When would be the best time to conduct a vulnerability scan and that feature? 08:28.520 --> 08:33.200 The correct answer would be most likely in the maintenance window, as that's probably the best answer 08:33.200 --> 08:34.220 for that scenario. 08:34.250 --> 08:39.350 However, you might also have a question that talks about high priority or high sensitivity levels. 08:39.350 --> 08:43.280 In this case, it really is a judgment call for most cases. 08:43.280 --> 08:48.770 But use your common sense and understand that higher sensitivity levels and higher priority levels dictate 08:48.770 --> 08:54.290 us to move forward with those vulnerability scans, regardless of the maintenance windows considerations.