WEBVTT 00:07.310 --> 00:12.290 As a cyber security analyst, you should understand how to utilize active defensive measures to better 00:12.290 --> 00:14.660 protect your network from malicious activity. 00:14.690 --> 00:19.220 We're going to discover in this episode where those active defenses should come into play, where you 00:19.220 --> 00:24.020 should focus those defenses, and how we can improve detection across our network to better prepare 00:24.020 --> 00:26.510 ourselves to defend against malicious activity. 00:26.540 --> 00:30.710 Throughout this episode, we're going to discover not only those active defenses and improved detection, 00:30.710 --> 00:32.300 but how they're intertwined with another. 00:32.300 --> 00:35.900 To create a better cybersecurity strategy within your organization. 00:35.900 --> 00:42.050 You'd be surprised how often misconfigurations within our network relate back to data exfiltration and 00:42.050 --> 00:44.420 data manipulation within our own networks. 00:44.450 --> 00:49.760 Configurations are one of those human error elements that we see constantly from day to day, that pose 00:49.760 --> 00:51.560 dangerous problems within our network. 00:51.590 --> 00:56.030 You, as a cybersecurity analyst, need to understand that configurations need to be kept up to date. 00:56.030 --> 01:01.010 If I change one portion of my network, then I need to change the other portion as well to match that 01:01.010 --> 01:03.800 so that we're not creating a new vulnerability within our systems. 01:03.830 --> 01:07.220 It also means that I need to change those default username and passwords. 01:07.220 --> 01:13.130 We go through our different new items within our network, and anytime we add, delete or modify something, 01:13.130 --> 01:19.850 we need to look at the opposing or applied different technologies associated with that single change 01:19.850 --> 01:21.770 that we made in that single item. 01:21.770 --> 01:27.770 If I change a firewall, then I need to look at the IPS, the IDs, the router, and any switches corresponded 01:27.770 --> 01:32.930 to that firewall to ensure that I didn't accidentally create a vulnerability within my system, we need 01:32.930 --> 01:35.660 to make sure that we're looking at new vendor requirements as well. 01:35.660 --> 01:40.610 They come out with new items or new, uh, new technology within our network. 01:40.610 --> 01:46.460 We need to go through and identify what does the vendor require with this newest technology, what is 01:46.460 --> 01:51.680 their standard, and are we meeting that standard to make sure that our systems and our requirements 01:51.680 --> 01:52.700 are up to date? 01:52.700 --> 01:57.350 Meeting vendor requirements doesn't sound like something very glamorous, but believe it or not, it's 01:57.350 --> 02:02.030 something that you need to be aware of so that when you go through, our network remains secure. 02:02.060 --> 02:04.490 We also need to make sure that we have secure logins. 02:04.490 --> 02:06.260 Secure logins should be separated. 02:06.290 --> 02:09.170 Do I have an administrative login versus a working login? 02:09.200 --> 02:14.120 You'd be surprised how many people use the same login for everything that they do, and they always 02:14.120 --> 02:16.100 tend to use the highest of the logins. 02:16.130 --> 02:18.860 This is a problem across our networks on a whole. 02:18.860 --> 02:23.900 If I have administrative access, do I need to be accessing that system with the administrative login 02:23.900 --> 02:25.190 to do normal stuff? 02:25.220 --> 02:30.650 It's not uncommon to see somebody with admin access using that access to check their emails, or even 02:30.680 --> 02:34.310 do limited work that doesn't require that admin access. 02:34.340 --> 02:39.890 We need to make sure that our secure logins stay secure and only utilize when they need to be utilized. 02:39.920 --> 02:44.930 Further, we need to make sure that our logins are secure, that we're using a login for each individual 02:44.930 --> 02:46.910 user rather than a group of people. 02:46.910 --> 02:49.580 We don't want one login for five different people. 02:49.580 --> 02:53.000 We'll never be able to tell who accessed what or why they accessed it. 02:53.000 --> 02:56.000 And then we're getting different stories and then minds fade. 02:56.000 --> 02:57.530 We can't go in and go, oh well. 02:57.560 --> 03:01.700 On Tuesday at 8:33 p.m., this user, you did this to our network. 03:01.700 --> 03:02.630 Why did they do that? 03:02.660 --> 03:05.120 You have five technicians that all use the same login. 03:05.150 --> 03:09.320 You're going to be jumping through hoops and making constant phone calls, trying to figure out why 03:09.320 --> 03:10.430 they logged into the system. 03:10.430 --> 03:14.330 And even then, you can't prove that it was that individual user that actually did it. 03:14.360 --> 03:18.110 So you could get a lot of he said she said stuff and you just don't want that. 03:18.140 --> 03:23.120 Misconfigurations provide us with weak login credentials and insecure access control. 03:23.150 --> 03:27.410 Now, we kind of touched on that already, but you need to understand that when it comes to weak login 03:27.410 --> 03:33.860 credentials, we're talking about usernames that may not be exactly what I would call profound. 03:33.860 --> 03:37.400 You want your login credentials to be related to a specific person. 03:37.400 --> 03:41.600 We don't want to pass on our login credentials and we don't want shared login credentials. 03:41.600 --> 03:46.310 Meaning I don't want one person to share their same login credentials with everybody else. 03:46.340 --> 03:50.330 Now I beat that dead horse in our last slide, so I'm going to stop with it on that one. 03:50.330 --> 03:53.300 We want insecure access control to be secured. 03:53.300 --> 03:58.250 If I'm using telnet or I'm using something that's insecure and unencrypted, that's a problem. 03:58.250 --> 04:02.030 That means anybody that's listening in could technically get that login information. 04:02.030 --> 04:05.930 We want to use two factor or even multi-factor authentication when it comes to login. 04:05.930 --> 04:10.400 We want those insecure access controls to be shored up as quickly as possible. 04:10.400 --> 04:14.330 We want open insecure ports to be blocked down when we're not using them. 04:14.360 --> 04:18.920 Yeah, it's great to have Https open all the time and that's fine on a server. 04:18.920 --> 04:20.840 But why am I using HTTP? 04:20.870 --> 04:22.070 What about FTP? 04:22.100 --> 04:23.270 What about telnet? 04:23.300 --> 04:24.830 All those insecure ports? 04:24.830 --> 04:26.750 If they're not being used, let's lock them down. 04:26.750 --> 04:29.330 Let's shut them down so that somebody can't get onto them. 04:29.330 --> 04:35.090 Even if I'm using a port like RDP and it only gets used once in a while, maybe once every 30 days, 04:35.090 --> 04:38.300 I should lock it down and then only open it when I need to. 04:38.330 --> 04:42.980 We want to make sure our encryption is up to date, and that we're using new encryption keys at least 04:42.980 --> 04:44.930 every 30 days for AAS. 04:44.960 --> 04:49.640 We don't want our encryption to be the same encryption key that we've been using for the last five years. 04:49.640 --> 04:52.940 Sometimes it's used to being updated and we want to do that. 04:52.940 --> 04:55.580 We want to make sure our default settings aren't in place. 04:55.580 --> 05:01.770 I can't tell you how many times I see on the news every single month that some Organization got locked 05:01.770 --> 05:06.150 into their system, and a malicious malware got into their system because they used default network 05:06.150 --> 05:12.000 credentials or default settings that just left open a known common vulnerability. 05:12.000 --> 05:16.860 Because when you first log into the system, it's like, oh, access this port, plug in this username 05:16.860 --> 05:19.110 and password, and it gives you full reign to the system. 05:19.110 --> 05:20.190 This is a problem. 05:20.190 --> 05:22.260 This is a misconfiguration that needs to be handled. 05:22.260 --> 05:26.610 And you as a cybersecurity analyst, whenever you're dealing with a new piece of equipment or resetting 05:26.610 --> 05:28.830 a piece of equipment, need to be aware of that. 05:28.830 --> 05:31.410 Within every network we have an isolated network. 05:31.440 --> 05:38.100 Usually this user network is usually used for testing, or it's off grid or it's not connected to the 05:38.100 --> 05:40.380 internet, it's isolated from everything else. 05:40.380 --> 05:42.930 It doesn't even have to be on the main network. 05:42.930 --> 05:47.520 It could just be a subset or a Vlan of that existing network that doesn't really have access to the 05:47.520 --> 05:49.260 rest of our internal workings. 05:49.260 --> 05:53.790 This isolated network can be used for a variety of different reasons, from research and development, 05:53.790 --> 05:58.260 all to shuffling malware or malware infected networks into that system. 05:58.290 --> 06:01.850 It can also be used for hunting bots or honey nets, which we'll get into a little bit later. 06:01.850 --> 06:06.080 But within these isolated networks, we want to provide the same monitoring tools that we utilize on 06:06.080 --> 06:07.040 our live network. 06:07.070 --> 06:11.750 The worst thing that you can do is provide an isolated network and then not monitor what's going on. 06:11.780 --> 06:16.400 We want to understand the baseline within our network, within our isolated networks, to make sure 06:16.400 --> 06:21.710 that we have an understanding of how much traffic is going in and around that specific isolated network. 06:21.740 --> 06:25.250 Again, that comes into play with monitoring and how it's being deviated. 06:25.250 --> 06:30.140 If something goes wrong, we want to do file system and integrity checks via hashing files. 06:30.140 --> 06:34.820 We can do a variety of different tools, like Hashcat or something else that provides us hash values 06:34.820 --> 06:38.360 of those internal workings to where if something changes, we're aware of it. 06:38.390 --> 06:40.520 We also want to do behavioral analysis. 06:40.550 --> 06:42.920 What are they impacting within that isolated network? 06:42.920 --> 06:43.910 Who's accessing it? 06:43.940 --> 06:45.440 What kind of data is being maneuvered? 06:45.440 --> 06:50.330 If we have a behavioral analysis and a baseline of that behavior, then we know what to expect. 06:50.330 --> 06:54.980 And if it changes, then that should set off a problem or an alarm so that we can investigate. 06:55.010 --> 06:57.080 We also want to do manual inspections. 06:57.080 --> 07:03.050 Sometimes automated tools just aren't good enough And I while we love to lean on it quite a bit, especially 07:03.050 --> 07:06.650 as of late, it doesn't do as well as a real analyst does. 07:06.680 --> 07:11.570 And with that takes manual inspection to figure out what's going on and if the system is operating, 07:11.570 --> 07:12.380 how it should. 07:12.410 --> 07:16.550 Isolated networks are the same way, the same tools that we utilize inside our live network. 07:16.580 --> 07:18.770 We're going to try and duplicate those as much as possible. 07:18.800 --> 07:22.130 And those isolated networks, given the cost that's required. 07:22.160 --> 07:24.230 Now we talked about isolated networks. 07:24.230 --> 07:26.600 Let's talk about business critical assets. 07:26.600 --> 07:32.030 These are assets within our network that may have a priority based on what they do for us and the company. 07:32.060 --> 07:37.550 Meaning that if I have a piece of equipment that we utilize that literally makes us $1 million per day, 07:37.550 --> 07:39.560 that would be a business critical asset. 07:39.590 --> 07:44.960 Maybe I've got a server that connects to all my operations and R&D guys, and our job or our company's 07:44.960 --> 07:48.920 job is to research new equipment or new procedures in place. 07:48.920 --> 07:51.650 Those are critical assets that need to be protected. 07:51.650 --> 07:56.600 We need to identify those assets and then put a priority on those assets in the event of an attack or 07:56.630 --> 08:01.190 a problem that's going on within our network, we need to provide continuous monitoring to those critical 08:01.190 --> 08:06.050 assets to ensure they're behaving in the way that we already identified what's going on with those systems. 08:06.050 --> 08:10.340 We need to know if the antivirus alarm goes off and what got into that system. 08:10.340 --> 08:15.680 We may need to investigate something minor that we wouldn't normally look at on one of our other systems, 08:15.680 --> 08:17.480 because it's a critical asset. 08:17.480 --> 08:22.760 If we're not expecting malware to get to our systems and suddenly we have malware, even if the AV took 08:22.760 --> 08:25.940 care of it, we may want to find out how it got there in the first place. 08:25.940 --> 08:31.460 We need to look at behavioral analysis and understand what kind of behavior is the norm on that system, 08:31.460 --> 08:32.360 and what changes. 08:32.360 --> 08:34.790 If it does change, why did it change? 08:34.790 --> 08:39.860 These critical assets really need a more of a Microsoft viewpoint than what we may see on something 08:39.860 --> 08:40.400 else. 08:40.400 --> 08:42.860 We also want to do threat intelligence integration. 08:42.860 --> 08:48.260 If we're seeing trends or threat intelligence that pinpoints to a specific attack or a vector of an 08:48.260 --> 08:53.390 attack, that could put our critical assets in jeopardy, we need to be aware of it, and we need to 08:53.420 --> 08:57.950 put in those mitigating factors as quick as possible to defend against those types of attacks. 08:57.980 --> 09:02.420 Threat intelligence, integration really comes into play as a holistic viewpoint when it comes to critical 09:02.420 --> 09:02.900 assets. 09:02.900 --> 09:06.860 We just need to pay attention to those assets a little bit more than what we would on a normal client 09:06.860 --> 09:07.670 infrastructure. 09:07.700 --> 09:09.800 And then finally, vulnerability management. 09:09.800 --> 09:14.960 We want to may want to scan those critical assets more than we scan other devices on our network. 09:14.960 --> 09:20.510 We may get away with scanning our normal PCs or operating systems or clients, maybe once a month, 09:20.510 --> 09:21.650 maybe once a week. 09:21.650 --> 09:25.940 We may want to look at our critical assets and double, if not triple, the vulnerability scanning that 09:25.940 --> 09:27.110 we do on those assets. 09:27.110 --> 09:33.020 We want to be understanding of those vulnerabilities as often as possible, and as soon as the new vulnerability 09:33.020 --> 09:34.790 pops up, we want to rescan it. 09:34.820 --> 09:37.400 We want to make sure that our library is up to date. 09:37.400 --> 09:43.520 And if we update Nessus or Openvas with a new attack, vectors or new problems that they've seen, we 09:43.520 --> 09:48.800 want to rescan those critical assets as soon as possible to make sure we are not in danger of exploitation. 09:48.800 --> 09:53.210 Now, we talked about research and development, but did you know, as a cybersecurity expert or as 09:53.210 --> 09:55.220 an analyst, we can do our own R&D. 09:55.220 --> 09:58.250 This is usually comes into play with honeypots and honey nets. 09:58.250 --> 10:03.920 These are virtual Well most of the time virtual machines that correspond on our live network and look 10:03.950 --> 10:08.300 exactly like a live network or a live client that's operating on our network. 10:08.330 --> 10:13.640 This provides us with a glimpse of what attackers may be after we can set these honeypots or honey nets 10:13.670 --> 10:18.470 up to be as realistic as possible, so that we can track and monitor what's going on within them. 10:18.500 --> 10:22.790 This means that if I've got a fresh attacker that's coming into my network and they get into my honey 10:22.820 --> 10:28.250 net, I can track what's going on within that network and identify how they're getting in, what they're 10:28.250 --> 10:30.710 interacting with, what attacks they utilize. 10:30.710 --> 10:34.490 And it can also provide me a little bit of early detection against my own network. 10:34.520 --> 10:36.140 No one should be on my honey net. 10:36.170 --> 10:40.400 A lot of that traffic is going to be simulated so that the attacker doesn't realize what's going on. 10:40.400 --> 10:44.990 But if we suddenly see an attacker going in there and we can monitor their activity, then it could 10:44.990 --> 10:50.090 provide us some leverage or some key notes that we can then utilize within our live network to see if 10:50.090 --> 10:54.380 anybody's taking the exact same advantage that we want our honeypots and honey nets to be as close, 10:54.380 --> 10:59.240 as realistic as possible, because we want to fool those attackers into thinking they are really invading 10:59.240 --> 11:00.380 an actual network. 11:00.380 --> 11:04.760 This provides us early detection as well as research and analysis of what's going on. 11:04.790 --> 11:09.800 We're providing deception by telling the attacker that they this is a real network, and there's real 11:09.800 --> 11:11.240 things on there that you can download. 11:11.270 --> 11:18.530 Now we want to make it as as as realistic as possible, even by providing semi tangible assets in there 11:18.530 --> 11:20.840 that they may want to download or exfiltrate. 11:20.840 --> 11:24.830 That doesn't mean that we shouldn't make it gobbly goop or make it misleading. 11:24.830 --> 11:25.520 That's fine. 11:25.520 --> 11:30.230 We're going to use deception to understand where they're coming from and understand how they got into 11:30.230 --> 11:31.310 our network in the first place. 11:31.310 --> 11:36.140 This also provides us that threat intelligence that we can then share within our own organization or 11:36.140 --> 11:40.940 outside of our organization, within that research and analysis of the different attacks that a malware 11:40.970 --> 11:45.770 or malicious actor is utilizing within any network, we want to understand active defense. 11:45.800 --> 11:51.380 Active defense is actively defending our network against perceived dangers or threats. 11:51.380 --> 11:55.880 This means that we want to go through and actively defend against threats. 11:55.880 --> 11:58.310 This means using threat hunting as an atmosphere. 11:58.310 --> 12:02.720 We're going to go through and we're going to actively pursue different threats or alarms or alerts on 12:02.720 --> 12:03.350 our network. 12:03.380 --> 12:07.670 We're not just going to let them sit idly by and expect our automated services to take care of it. 12:07.700 --> 12:12.050 We're going to use deceptive technology like honeypots and honey nets to try and get more research and 12:12.050 --> 12:17.210 development, or research and analysis of what's going on within our networks by providing that R&D 12:17.210 --> 12:19.970 or that research and analysis within a honeypot or a honeynet. 12:20.000 --> 12:25.430 We can more actively see what's going on and perhaps identify if that is going on within our live network 12:25.430 --> 12:26.060 as well. 12:26.090 --> 12:29.330 We want to provide incident response when an incident occurs. 12:29.330 --> 12:34.070 We want to respond to it accordingly, whether from a priority of high or a priority to low. 12:34.100 --> 12:38.780 We want to track that incident response and go through the motions, just like we would with every single 12:38.780 --> 12:39.380 attack. 12:39.410 --> 12:42.920 Now, obviously I say every single attack, but that's just not going to be the case. 12:42.920 --> 12:46.880 Sometimes we'll have an AV that just wipes it out and we're too busy that we can't get to it. 12:46.880 --> 12:51.650 But if we're seeing an attack in motion that is taking advantage of a vulnerability and properly exploited 12:51.650 --> 12:54.590 it, we need to respond to that in the proper way. 12:54.590 --> 12:59.030 We want to do threat intelligence sharing with other companies, organizations and governments so that 12:59.030 --> 13:03.650 we get the most latest and updated information so that we can understand what's going on, not only 13:03.650 --> 13:07.160 with other networks, but what could perceive to be happening within our own network. 13:07.190 --> 13:09.710 And finally, we want to actively monitor our network. 13:09.740 --> 13:11.510 We have monitors all over the place. 13:11.510 --> 13:17.480 We have logs every time we access an IP, every time you go through a firewall or an IPS or even a client, 13:17.480 --> 13:18.770 it produces a log. 13:18.770 --> 13:23.930 We should actively be monitoring all these logs within a system to figure out what's going on within 13:23.930 --> 13:24.830 our own networks. 13:24.830 --> 13:30.980 This can provide us clues and gateways into malicious activity on our network, and by not actively 13:30.980 --> 13:34.610 monitoring it, we could be putting ourselves in pure danger from an attacker. 13:34.610 --> 13:37.160 Whether it's a denial of service or even a ransomware attack. 13:37.160 --> 13:42.350 We need to provide an active defense and as part of that active defense, provide a concerted effort 13:42.350 --> 13:47.720 with a holistic viewpoint, not only within our own organization, but with other organizations as well. 13:47.720 --> 13:52.190 We need to provide threat intelligence feeds from not only the government, but other organizations 13:52.190 --> 13:57.770 and individuals that are like minded with our own to properly provide a defensive structure and active 13:57.770 --> 13:59.090 defense within our network. 13:59.090 --> 13:59.780 As a whole. 13:59.780 --> 14:06.080 Within the CSA exam, you can expect to see high level questions specific to active defense and focused 14:06.080 --> 14:11.180 defense, with some subsidiary questions on improved detection methodologies. 14:11.210 --> 14:16.190 A lot of your improved detection questions should have already been covered in Security+, but don't 14:16.220 --> 14:19.790 underestimate the fact that they will probably appear in Cisa as well. 14:19.790 --> 14:23.960 We should expect to see scenario based questions specific to everything we discussed today. 14:23.990 --> 14:29.600 Expect to see questions like, hey, what type of active defense would you utilize in this scenario? 14:29.600 --> 14:36.200 If I have a legacy system that utilizes this operating system, what critical component would utilize? 14:36.200 --> 14:38.150 I would not expect to see questions like that. 14:38.150 --> 14:43.550 When we go through the exam, I would expect to see questions at a high level that talk about proper 14:43.550 --> 14:45.680 configuration and why it's important. 14:45.680 --> 14:52.040 You may get questions as to hey, for username and passwords, would you utilize a SSL or a federated 14:52.040 --> 14:55.940 sign on, or would you utilize an administrative password for everything you do? 14:55.970 --> 15:00.140 These are basic questions that you should have a basic common knowledge of when you go through this 15:00.140 --> 15:00.860 exam.