WEBVTT 00:07.250 --> 00:12.530 In this episode, we're going to go back into risk management and discuss how that intersects with vulnerability 00:12.530 --> 00:13.250 management. 00:13.280 --> 00:18.020 Vulnerability management, along with risk management is kind of the caveat of what you really do as 00:18.020 --> 00:19.310 a cybersecurity analyst. 00:19.310 --> 00:24.740 You're constantly moving back and judging, hey, how risky is this versus the vulnerabilities that 00:24.740 --> 00:28.010 coincide with the different systems that you usually use? 00:28.040 --> 00:32.330 Risk and vulnerability management really make up the core of every cybersecurity analyst. 00:32.330 --> 00:34.070 And we're going to discover that today. 00:34.820 --> 00:39.890 If you remember from our previous lectures, risk management really corresponds into five main points. 00:39.890 --> 00:44.990 Identification of the risk assessment of how dangerous that risk really is. 00:44.990 --> 00:52.280 Prioritization of how difficult or how contagious or how impactful that risk is in order to be fixed 00:52.280 --> 00:58.610 within your own organization i.e., should this risk or this problem face up a higher priority to be 00:58.610 --> 01:00.710 fixed versus a lower priority? 01:00.730 --> 01:02.560 What the mitigation factors are. 01:02.590 --> 01:07.840 Can I mitigate that risk to do a lower priority or have less impact on our company? 01:07.840 --> 01:11.230 And finally, a review of the different risks that are associated with it. 01:11.260 --> 01:15.910 We're not going to go solely into risk management today, but I wanted to touch back on to it of previous 01:15.910 --> 01:16.270 lectures. 01:16.270 --> 01:18.280 So you get a good sense of where we're coming from. 01:18.310 --> 01:23.770 Risk equals threats multiplied by vulnerabilities, meaning that if I have zero vulnerabilities, but 01:23.770 --> 01:25.960 I have a lot of threats, there is no risk. 01:25.960 --> 01:31.180 Meaning I may have threats, but again, if there's nothing for them to actually impact or nothing for 01:31.180 --> 01:34.060 them to exploit, then I really don't have any risk. 01:34.090 --> 01:39.580 On the flip side, although much rarer if I have a vulnerability, but there are no threats, then again, 01:39.580 --> 01:40.720 I have no risk. 01:40.750 --> 01:45.490 There's little windows vulnerabilities that we discovered from windows XP way back in the day. 01:45.490 --> 01:50.770 We knew that the vulnerability existed, but at the time, the technology to exploit those vulnerabilities 01:50.770 --> 01:55.510 was near zero, meaning there really were no threats that could take advantage of those vulnerabilities, 01:55.510 --> 01:57.220 meaning there was no risk. 01:57.220 --> 01:59.950 We saw that in those lower windows systems. 01:59.950 --> 02:05.670 However, if I took a windows XP machine today and I have those same vulnerabilities, we have more 02:05.670 --> 02:08.130 than enough technology to exploit those vulnerabilities. 02:08.130 --> 02:11.460 Meaning there is a high risk if you're using windows XP. 02:11.490 --> 02:15.480 This comes into play with understanding risk at its most fundamental level. 02:15.540 --> 02:21.510 Threats times vulnerabilities equals risk, and I've seen other acronyms or further algorithms that 02:21.510 --> 02:21.840 come in. 02:21.840 --> 02:24.990 And they say threats plus vulnerabilities equals risk. 02:24.990 --> 02:26.340 But that's not really the case. 02:26.340 --> 02:28.830 It really is that multiplication that comes into play. 02:28.830 --> 02:33.930 Because if I have threats, but I have zero vulnerabilities with the addition factor, then I still 02:33.930 --> 02:35.910 have a risk and that's just not the case. 02:35.910 --> 02:39.810 I must have both threats and vulnerabilities in order to have risk. 02:39.840 --> 02:44.280 Vulnerability management really starts with the different aspects of understanding your network as a 02:44.280 --> 02:44.820 whole. 02:44.820 --> 02:49.740 I must understand my network and to do that I must have an inventory of every machine, whether it's 02:49.740 --> 02:53.820 a windows box or an IPS, IDs, a router, even a switch. 02:53.940 --> 03:00.150 Heck, even if I have a hub in my system, that's part of my intrinsic networking infrastructure and 03:00.150 --> 03:01.350 I need to be aware of that. 03:01.380 --> 03:07.410 Having a good inventory of your systems really provides you a detailed understanding of all the different 03:07.410 --> 03:10.260 vulnerabilities that could, in fact, be on your network. 03:10.290 --> 03:15.630 When I worked with a telecommunications company one time, we had all this equipment rolled out, and 03:15.630 --> 03:18.450 a lot of times we didn't know what we actually had in our systems. 03:18.450 --> 03:22.260 So we had these very complex switches and microwave radios. 03:22.260 --> 03:27.030 We had some great telecommunications equipment, but we had other inventory that we had no idea was 03:27.030 --> 03:27.270 there. 03:27.270 --> 03:28.170 It just worked. 03:28.170 --> 03:33.180 And unless the technician that was on site went there and actually physically put eyes on it, we had 03:33.180 --> 03:34.740 no idea that machinery was there. 03:34.770 --> 03:40.350 This is a very sad and poor way in order to understand your vulnerabilities associated with your different 03:40.380 --> 03:40.950 networks. 03:40.980 --> 03:44.880 Now the argument was always made, oh well, you have to actually know how to use the equipment. 03:44.880 --> 03:48.870 You have to know what the equipment was, because some of this equipment in telecom was literally 30 03:48.870 --> 03:50.010 or 40 years old. 03:50.010 --> 03:52.980 So most people would look at it and have no idea what they were looking at. 03:52.980 --> 03:56.670 But that's not real security, that's obscurity through obscurity. 03:56.670 --> 04:00.280 And if we're doing security through obscurity, that's not real security. 04:00.280 --> 04:01.510 It's just make believe. 04:01.510 --> 04:03.070 So you must have that inventory. 04:03.100 --> 04:06.970 You must understand everything that's in your network and have a detailed list of it. 04:06.970 --> 04:12.070 You should have serial numbers, makes, models and what the machine actually does, or how it interacts 04:12.070 --> 04:13.420 with the rest of your network. 04:13.450 --> 04:15.400 To do that, we do a lot of scanning. 04:15.400 --> 04:18.820 Now, scanning is usually done in one, sometimes two different ways. 04:18.820 --> 04:21.010 There's Openvas and there's Nessus. 04:21.040 --> 04:26.440 Openvas really provides us that open source way of scanning our different networks and understanding 04:26.440 --> 04:28.270 the different vulnerabilities that are associated with it. 04:28.270 --> 04:32.020 And Nessus is more of the commercial grade aspect of doing the same thing. 04:32.080 --> 04:37.330 Here you can see a screenshot of Openvas, where it's provided detailed information of what's on our 04:37.330 --> 04:39.070 system or what's on our network. 04:39.100 --> 04:42.880 On this screenshot, you can see the different criticalities that are associated with the different 04:42.880 --> 04:44.320 vulnerabilities that it found. 04:44.350 --> 04:48.280 This is a plain and simple vulnerability management at its core level. 04:48.280 --> 04:52.180 And your systems, your infrastructure should be scanned in this way every day. 04:52.180 --> 04:55.150 Within this we can identify prioritization. 04:55.240 --> 04:59.890 When going through the prioritization, you can see that it goes through and it provides us those most 04:59.920 --> 05:03.580 critical levels at the very top, with maybe the lower levels at the bottom. 05:03.580 --> 05:08.620 Within this you can see different aspects of the different vulnerabilities associated with each machine 05:08.620 --> 05:11.650 or each IP address within our different network. 05:11.680 --> 05:16.180 This provides us not only an inventory of every IP address associated with our network, but also different 05:16.180 --> 05:19.900 vulnerabilities that could be linked to those specific IP addresses. 05:19.900 --> 05:21.340 When we talk about priority. 05:21.370 --> 05:24.670 You need to understand where it comes into play with your specific network. 05:24.670 --> 05:30.430 Meaning, if I have a vulnerability that it's a Linux vulnerability on a windows machine, that's obviously 05:30.430 --> 05:35.590 a false positive, meaning that the positivity of the vulnerability doesn't actually exist. 05:35.620 --> 05:40.540 We have to go through and concentrate on the false negatives, the false positives, even the true positives 05:40.540 --> 05:43.600 and true negatives and truly understand what's going on with our network. 05:43.630 --> 05:48.640 This is almost a full time job by itself, and should be carefully looked at on a case by case basis, 05:48.640 --> 05:52.810 based on the different IP addresses and structures within your internal network. 05:52.840 --> 05:58.120 Prioritization really comes into play with understanding what really takes priority in our own network. 05:58.150 --> 06:03.920 You can have a very complex, highly critical system vulnerability associated with your network. 06:03.920 --> 06:09.410 And the system may be telling you, hey, knee jerk reaction, let's give it a very high priority. 06:09.440 --> 06:15.410 However, you may know through experience and understanding of your systems and network that that vulnerability 06:15.410 --> 06:17.690 really doesn't need a such a high critical level. 06:17.690 --> 06:22.190 It can actually be dropped down a couple of places, and the prioritization could be resubmitted based 06:22.190 --> 06:24.350 on that new algorithm that you utilized. 06:24.350 --> 06:30.320 This is part of prioritization where we put logic versus common sense plus intuition. 06:30.320 --> 06:33.230 This really comes into play with understanding your own network. 06:33.230 --> 06:38.510 And that makes your prioritization based on logic versus intuition or gut feeling. 06:38.510 --> 06:40.100 You know, the system of networks. 06:40.100 --> 06:44.510 If I just wanted somebody to look at it and give me a knee jerk reaction every time and say, hey, 06:44.510 --> 06:47.180 this needs a critical input because the machine said so. 06:47.210 --> 06:48.710 I don't need human beings for that. 06:48.710 --> 06:50.900 I just need a machine that runs a script to do that. 06:50.930 --> 06:56.750 Your job as an analyst is to understand those little idiosyncrasies that communications or AI and machine 06:56.750 --> 06:58.130 learning will never get. 06:58.130 --> 07:01.210 This is why human beings will always rate higher than machines. 07:01.210 --> 07:06.130 When it comes to true cyber security, patch management really makes up one of those core fundamentals 07:06.130 --> 07:10.000 that we associate with our network scanning and our core vulnerabilities. 07:10.000 --> 07:16.330 Within a management scheme, you should be patching your windows machines almost on a weekly basis whenever 07:16.330 --> 07:18.100 Microsoft comes out with a new patch. 07:18.100 --> 07:21.820 However, it's not as simple as that, and we discussed in further episodes. 07:21.850 --> 07:26.020 Patch management really comes into play with understanding the patches that are coming into our different 07:26.050 --> 07:31.060 networks, how they correspond with our core operating systems, and how they correspond with our existing 07:31.060 --> 07:31.810 software. 07:31.810 --> 07:33.940 And then we run it through a sandbox environment. 07:33.940 --> 07:39.670 Before we push that patch forward, patch management goes into a very detailed, uh, change management 07:39.670 --> 07:41.380 program that we need to be aware of. 07:41.410 --> 07:46.120 But you need to also understand that that patch management is very much a part of vulnerability management. 07:46.120 --> 07:48.550 We also need to understand configuration management. 07:48.580 --> 07:53.230 Configuration management comes into play with if I've got a new piece of equipment am I configuring 07:53.230 --> 07:54.070 it properly? 07:54.100 --> 07:59.020 Did I remove the dead set username and password that came with it? 07:59.020 --> 08:02.070 Those default username and passwords there hack. 08:02.070 --> 08:06.960 And we know that because there have been some major telecom and cellular providers that have installed 08:06.960 --> 08:10.920 new routers, they forgot to change those default username and passwords, and they've suffered data 08:10.920 --> 08:11.940 breaches because of it. 08:11.970 --> 08:16.650 Three in less than two years, if memory serves correctly, we also need to monitor our networks and 08:16.650 --> 08:18.240 understand where everything is coming to play. 08:18.240 --> 08:23.280 That's where a Siem comes in, and it really kind of gives us a aspect of our network as a whole and 08:23.280 --> 08:28.770 how it crawls and analyzes women IP address to another one piece of equipment over another, and gives 08:28.770 --> 08:31.410 us that really holistic view of our entire network. 08:31.590 --> 08:34.200 If we can't fix something, we need to mitigate it. 08:34.230 --> 08:37.530 We can mitigate through different hardware and software ramifications. 08:37.530 --> 08:42.030 We can go through and say, hey, if this vulnerability is there and I can't patch it, I can't fix 08:42.030 --> 08:43.440 it, how can I mitigate it? 08:43.440 --> 08:47.190 Mitigation should be at the top of our list when it comes to different vulnerabilities that we can't 08:47.190 --> 08:48.540 have a direct fix for. 08:48.540 --> 08:50.250 And finally, documentation. 08:50.250 --> 08:52.380 We want to document everything. 08:52.380 --> 08:57.870 If you're an OCD person that loves documenting everything that you touch, this is probably the best 08:57.870 --> 08:58.590 job for you. 08:58.620 --> 09:02.120 We literally have to document as much as we possibly can. 09:02.150 --> 09:07.460 I want you to imagine yourself in a small office with lots of equipment, a lot of heck going on, and 09:07.460 --> 09:10.430 you've got just things going on left, right and sideways. 09:10.430 --> 09:14.270 You've got multiple machines, multiple monitors, not enough manpower. 09:14.300 --> 09:17.720 You really are trying to put out fires one after another. 09:17.720 --> 09:23.060 And part of that is documentation, because with proper documentation, I can figure out what another 09:23.060 --> 09:27.020 technician did, even if they were gone for six months or a year or even yesterday. 09:27.020 --> 09:33.050 This is the problem that we see a lot as a cybersecurity analyst is a lack of documentation, meaning 09:33.050 --> 09:34.820 they don't write down everything they did. 09:34.820 --> 09:39.230 They don't document, hey, the IP address that I associated with this, I did this. 09:39.230 --> 09:41.780 If I did this, then I need to document it. 09:41.810 --> 09:46.610 Documentation really is one of the most profound things that you can do as a cybersecurity analyst. 09:46.610 --> 09:50.300 And as you go higher and higher in your career field, you need to document more and more. 09:50.300 --> 09:52.070 We need to document in detail. 09:52.070 --> 09:57.140 Now, I could beat this horse dead until it was dead 100 times, but documentation, documentation, 09:57.140 --> 10:01.090 documentation is one of those things that you need to do as a cybersecurity analyst. 10:01.180 --> 10:06.130 Throughout this episode, we talked about risk management very briefly, but we also talked more importantly 10:06.130 --> 10:08.440 about how it intersects with vulnerability management. 10:08.470 --> 10:12.340 Vulnerability management is really at the core of what a cybersecurity analyst does. 10:12.370 --> 10:14.800 We find vulnerabilities and we attempt to fix them. 10:14.800 --> 10:16.510 If we can't fix them, we mitigate them. 10:16.510 --> 10:19.330 If we can't mitigate them, then we've got some problems. 10:19.330 --> 10:23.860 This is where your job as a cybersecurity analyst really comes into play, where the meat meets the 10:23.860 --> 10:24.370 keyboard. 10:24.370 --> 10:25.810 And I don't mean that figuratively. 10:25.810 --> 10:31.090 You are really going to be pounding that keyboard a lot in your job as a cybersecurity analyst for Cisa. 10:31.120 --> 10:32.320 What do you really need to know? 10:32.350 --> 10:36.070 You need to understand everything that we discussed about vulnerability management. 10:36.070 --> 10:40.060 You need to understand if I've got different vulnerability levels, why do I have those vulnerability 10:40.060 --> 10:40.450 levels? 10:40.450 --> 10:41.650 Where do they come into play? 10:41.650 --> 10:42.940 How can I fix those? 10:42.940 --> 10:49.150 How do I take those ramifications versus impact versus threat versus risk and put them into one model 10:49.150 --> 10:49.960 if you need to? 10:49.990 --> 10:53.710 I would rewatch this video several times if you don't clearly understand it. 10:53.740 --> 10:57.250 When it comes to vulnerability management, Cisa takes it very seriously. 10:57.250 --> 11:00.600 This video was somewhat short, and that's all it really needed to be. 11:00.600 --> 11:04.830 But you need to understand the core concepts of vulnerability management when it comes to your exam, 11:04.830 --> 11:10.770 you should expect to see questions about the Cvss score and how that intersects, maybe even a prioritization 11:10.770 --> 11:13.620 list for a different drag and drop scenario. 11:13.650 --> 11:19.350 Expect scenario based questions talking about the different vulnerabilities and what you could do based 11:19.350 --> 11:21.030 on something that may happen in your network. 11:21.030 --> 11:24.840 For instance, it wouldn't be out of the question to see something where, oh well, you can't patch 11:24.840 --> 11:28.080 the machine because you're using old legacy software. 11:28.080 --> 11:33.240 How would you or what would be the most appropriate action for you as a cybersecurity analyst to solve 11:33.240 --> 11:34.050 this problem? 11:34.080 --> 11:36.420 Obviously, we want to mitigate it as much as possible. 11:36.450 --> 11:39.300 Don't expect to see a lot of technical questions that come into play. 11:39.300 --> 11:42.720 You're not going to see questions like, oh, well, you know, it's legacy software. 11:42.720 --> 11:45.480 So you need to add an IDs and a firewall and a router. 11:45.480 --> 11:50.220 But do expect to see questions that are high level talking about what factors you should go into. 11:50.250 --> 11:51.390 Should I mitigate it? 11:51.390 --> 11:53.700 Should I maybe do risk transference? 11:53.730 --> 11:58.980 What could you do as a cybersecurity analyst to solve that specific problem at a high level?