WEBVTT 00:07.250 --> 00:08.930 As a cybersecurity analyst. 00:08.960 --> 00:14.150 You're bread and butter is what we call a Siem, a security information and event management system. 00:14.150 --> 00:18.890 The Siem really is the heart and soul of any regular SoC that you should be aware of. 00:18.920 --> 00:22.880 Now, Cisa doesn't have you going into depth with a Siem system. 00:22.880 --> 00:27.980 They don't require you to understand how to read one or all the perplexities of it. 00:27.980 --> 00:32.330 You just need to know what a Siem is and how it interacts with the different systems, which we're going 00:32.360 --> 00:33.500 to talk about today. 00:33.530 --> 00:38.300 We're also going to talk about a security orchestration, automation and response system, and how that 00:38.300 --> 00:42.860 interplays with both our Siem system as well as our infrastructure as a whole. 00:42.860 --> 00:44.900 This episode is going to be quite quick. 00:44.900 --> 00:49.940 But the great news is in the next couple episodes, we're going to talk to a SOC manager that really 00:49.940 --> 00:54.440 goes through the different tools and utilization of those tools in a SoC atmosphere. 00:54.440 --> 00:58.070 We're going to do a slight Q and A, and then we're going to follow along with the different tools that 00:58.070 --> 01:04.300 you could expect to see in a SOC environment, a security information and event management system is 01:04.300 --> 01:06.040 exactly like we're showing here. 01:06.040 --> 01:09.460 It represents a centralized approach to security management. 01:09.460 --> 01:13.960 We get the different logs that are accessible throughout our entire infrastructure. 01:13.990 --> 01:16.750 Now let's take it with a grain of salt. 01:16.810 --> 01:21.520 When you're setting up a scene for the first time, it's natural that we want to provide that scene 01:21.520 --> 01:23.950 with as much logs as humanly possible. 01:23.950 --> 01:28.750 If I have a thousand clients, the natural knee jerk reaction is to throw a thousand different client 01:28.750 --> 01:30.610 logs into that same system. 01:30.640 --> 01:32.650 However, this is often a mistake. 01:32.650 --> 01:38.410 What we really want to do and how most professionals set it up is we take the hierarchy into play. 01:38.410 --> 01:43.870 If I've got a switch that serves those clients, then I'll pull the logs off the switch as opposed to 01:43.900 --> 01:45.100 the endpoint clients. 01:45.100 --> 01:47.650 And this is really where the Siem gets its power. 01:47.680 --> 01:53.200 A Siem system operates by grabbing the logs from the routers, the switches and the different network 01:53.200 --> 01:59.140 available systems in our enterprise environment and puts them together in an easily readable and trackable 01:59.140 --> 01:59.800 format. 01:59.830 --> 02:03.950 Now, I want you to think about this as a security analyst in your own home network. 02:03.950 --> 02:09.170 If I've got a computer which is connected to a switch, which then is connected to a router, and then 02:09.170 --> 02:14.240 if you're in my house, I have all these IoT devices that are associated with it as well, then it wouldn't 02:14.270 --> 02:15.740 take much to be overridden. 02:15.740 --> 02:20.510 If I have a piece of malware that comes into play at my endpoint client, the natural reaction is to 02:20.540 --> 02:23.900 go, oh, I've got this client, I need to find out where it came from. 02:23.900 --> 02:26.960 So I'm going to start at the client and then I'm going to go to the switch. 02:26.990 --> 02:27.650 Wait a second. 02:27.650 --> 02:29.360 Did it come from IoT devices. 02:29.360 --> 02:31.850 Let's go and inspect all my IoT devices. 02:31.850 --> 02:32.420 And then. 02:32.450 --> 02:34.070 Oh, I found this IoT device. 02:34.100 --> 02:36.260 We have to go back to the switch and then over to the router. 02:36.260 --> 02:38.570 It can be very confusing very quickly. 02:38.570 --> 02:44.360 And so where it seems power come from is that I can put all those logs into a centralized service that 02:44.360 --> 02:46.130 allows me to track it very easily. 02:46.130 --> 02:52.400 So instead of examining the logs from each individual system, I can go through the Siem and say, oh, 02:52.430 --> 02:55.430 there's a piece of malware that started here, let's track it. 02:55.460 --> 03:01.100 Through that tracking process, I can identify every network piece of equipment that interacted with 03:01.100 --> 03:03.680 that same packet as it was going through the process. 03:03.680 --> 03:09.970 I can also identify if that same packet or that piece of malware intersected within my other devices. 03:10.000 --> 03:11.080 Did it expand? 03:11.110 --> 03:15.550 Did it go through the different processes of affecting other clients, other endpoints, other network 03:15.550 --> 03:20.470 devices, and if so, how and when we are able to end a Siem environment? 03:20.470 --> 03:23.200 To see all of that in an easy to use interface. 03:23.200 --> 03:27.190 It also provides different interactions through reporting structures. 03:27.430 --> 03:29.260 It also provides edrs. 03:29.260 --> 03:35.830 It can really kind of signify a central standpoint where we get a lot of information and one heads up 03:35.830 --> 03:41.650 display that makes cybersecurity so useful and so much easier to utilize. 03:42.550 --> 03:47.620 The second thing I wanted to talk about was security, orchestration, automation, and response. 03:47.620 --> 03:53.770 This is an integrated tool structure where we provide different automated tools into an easy to use 03:53.770 --> 04:00.130 profile, meaning that I can have one tool that scans, I can have another tool that looks for maybe 04:00.130 --> 04:01.810 web application interfaces. 04:01.810 --> 04:08.240 I can look at another tool that just basic scripting, and I can put them all into one easy to use foundation 04:08.240 --> 04:10.100 for my security orchestration. 04:10.100 --> 04:14.390 This really goes hand in hand with a Siem device where we're going through, and we're able to automate 04:14.390 --> 04:17.780 a lot of responses into play for different incidents. 04:17.780 --> 04:22.100 So I want you to think about it from the perspective of a security analyst, which is the role that 04:22.100 --> 04:24.800 you're trying to achieve or are already achieving. 04:24.800 --> 04:29.630 And this aspect, I've got a piece of malware that's gone through my system, and it was stopped by 04:29.630 --> 04:33.410 the intrusion prevention system through that intrusion prevention system. 04:33.410 --> 04:38.390 It's identified the problem and it's immediately stopped it at that IPS device. 04:38.390 --> 04:41.690 But what happens if it took effect before the IPS? 04:41.690 --> 04:43.670 Or maybe we only have an IDs? 04:43.700 --> 04:47.150 That source system could provide an immediate response. 04:47.150 --> 04:50.600 That immediate response could be to prevent the system from moving forward. 04:50.600 --> 04:56.810 Maybe the immediate response is to purge that system off that that file using a ready made script. 04:56.810 --> 04:59.090 This is where the saw really gets its power. 04:59.090 --> 05:04.790 It provides an automated response based on the input that we provided based on an event or an alert 05:04.790 --> 05:05.510 occurring. 05:05.510 --> 05:11.050 This can come into play on different factors and really streamline and make more efficient our jobs 05:11.050 --> 05:12.310 as security analysts. 05:12.340 --> 05:16.840 It also can prioritize different vulnerabilities that are taking effect within our systems. 05:16.840 --> 05:21.430 And this way, you can identify a different vulnerability through the vulnerability assessment process 05:21.430 --> 05:25.090 and then provide an automated response based on that priority. 05:25.120 --> 05:26.710 So let's break this down a little bit. 05:26.710 --> 05:27.910 I have a piece of malware. 05:27.940 --> 05:29.860 It comes in and it infects a client. 05:29.860 --> 05:34.090 The client is now affected by that malware through the source system the AV. 05:34.120 --> 05:39.670 The antivirus program was unable to stop it, but the Network Intrusion Prevention system or the network 05:39.670 --> 05:46.300 detection system within the system identified it as being malware or Saw identified the malware through 05:46.300 --> 05:50.140 the Nids through the Network Intrusion Detection System provided that alert. 05:50.140 --> 05:55.210 That alert then goes through the system and identifies it and says, hey, antivirus program, you need 05:55.210 --> 05:56.140 to do this. 05:56.170 --> 06:01.810 The antivirus program, if it's a properly acclimated to that store, will then carry out the commands. 06:01.810 --> 06:04.600 Let's say that the antivirus program didn't do that. 06:04.600 --> 06:06.790 It's not functional or it was. 06:06.790 --> 06:08.010 The malware had taken over it. 06:08.010 --> 06:12.720 So it's not providing that clause we had inserted as part of our security feature. 06:12.720 --> 06:18.960 If the AB doesn't act responsibly, that the store will then conduct the next process, in this case 06:18.960 --> 06:24.570 to delete the system or segment or isolate that system off of our network as a whole, because that 06:24.600 --> 06:26.670 malware poses an issue to our network. 06:26.700 --> 06:31.830 The sword then goes through and isolates that system off of our network through automated means. 06:31.830 --> 06:33.750 This is where the sword gains its power. 06:33.750 --> 06:38.520 That automation process, based on what it's seeing from the outputs of the network. 06:38.550 --> 06:40.200 It's sort of like the AI. 06:40.230 --> 06:42.240 Most people relate it to that, but not really. 06:42.270 --> 06:46.650 We're going through and we're telling this system, if this happens, then do this. 06:46.680 --> 06:48.960 If this happens, then do this. 06:48.990 --> 06:49.560 It's run. 06:49.560 --> 06:54.000 It's like running a basic script, but it's overall the entire network as a whole. 06:54.000 --> 06:58.380 It provides an orchestration of different features across different subsets of our network. 06:58.410 --> 07:04.500 It automates the process and then responds to alerts and activities or events on our system through 07:04.500 --> 07:06.060 the enterprise environment. 07:06.120 --> 07:12.280 As part of your Soar automation response, we commonly use something called endpoint detection and Response, 07:12.280 --> 07:17.140 or EDR, sometimes referred to as endpoint threat detection and response. 07:17.140 --> 07:22.570 Through endpoint detection and response, we can monitor different aspects of our network at the endpoint. 07:22.570 --> 07:27.790 This would be your clients, maybe your IoT devices, basically anything on your network that's considered 07:27.790 --> 07:28.660 an endpoint. 07:28.690 --> 07:34.810 The great part about a good EDR system is that it can respond to malicious activity very quickly, and 07:34.810 --> 07:38.530 stop that activity from progressing or spreading across your network. 07:38.560 --> 07:44.950 It often removes the offending asset from the network, if needed, to stop it from spreading through 07:44.950 --> 07:45.730 isolation. 07:45.730 --> 07:51.730 And so to reemphasize, an EDR system is part of your store environment that really provides us the 07:51.730 --> 07:57.580 ability to not only monitor and analyze the traffic that's going back and forth from our endpoint devices, 07:57.580 --> 08:00.310 but provide an automated response back to it. 08:00.730 --> 08:06.250 Our last couple videos have gone into somewhat of detail on how we utilize logs for both the security 08:06.250 --> 08:11.730 environment as well as a data or information technology environment to figure out the health of our 08:11.730 --> 08:14.160 system within a security environment. 08:14.160 --> 08:20.250 More often than not, those logs are then detailed and both a raw format or in an environment where 08:20.250 --> 08:25.590 we curtail those logs so that it matches with each and every other log that it's in our system. 08:25.590 --> 08:31.200 You need to understand that not all systems or network devices produce the logs in the same way, and 08:31.200 --> 08:35.700 so we need to break down those logs and then provide them into our seal environment. 08:35.700 --> 08:37.950 And a standardized format. 08:37.950 --> 08:42.960 That standardized format is then read by the scene, which then we utilize to track down what's going 08:42.960 --> 08:43.410 on. 08:43.440 --> 08:48.870 The raw log is more often than not sent back to a central repository in the cloud environment, where 08:48.870 --> 08:51.060 it just sits there until we don't need it anymore. 08:51.090 --> 08:56.130 Usually a year, sometimes three, depending on your individual network's needs. 08:56.160 --> 09:02.070 Now we've gone into these logs, and we've stated repeatedly that you can use a Siem system to read 09:02.070 --> 09:06.690 logs and then go through and identify what's going on within your network. 09:06.690 --> 09:11.250 We can see that if malicious activity is going through our network, we can somehow track it. 09:11.260 --> 09:17.110 and then correlate those different log items with one another within that same environment. 09:17.110 --> 09:20.410 But we never really went into detail on how to read those logs. 09:20.410 --> 09:22.510 And that's what we're going to do today. 09:22.660 --> 09:28.420 Before you in the screen you can see a standardized log from a windows environment. 09:28.420 --> 09:34.090 The good news is, is that Sisa does not expect you to understand every event, code, or event type 09:34.090 --> 09:36.310 ID associated with the log. 09:36.310 --> 09:40.900 You need to have a basic, high level understanding of what's going on within the system, and then 09:40.900 --> 09:46.600 how to correlate that information back to other logs or other events that are happening on your network. 09:46.600 --> 09:49.030 We'll go into a little bit more about that later. 09:49.060 --> 09:50.800 Let's read the log first. 09:50.800 --> 09:54.190 This log started on 621 of 2024. 09:54.190 --> 09:58.780 It's pretty easy to read because it's right up there and gives us the date time stamp code. 09:58.780 --> 10:02.770 The second one is the actual time of 1220 203. 10:02.800 --> 10:08.020 Now, it doesn't tell us whether it's Pacific Time or Eastern time, which is pretty standard for most 10:08.020 --> 10:09.520 logs on a windows environment. 10:09.520 --> 10:15.390 But we have to take into account that this is based on the local time associated with that machine. 10:15.420 --> 10:23.340 Now, this could give us some clues if our log is for 1220 2:03 p.m. and the date is 621, and somebody 10:23.340 --> 10:27.780 messed around with that date timestamp, we should be able to go back to that domain system and find 10:27.780 --> 10:30.030 out if the timestamp has been changed. 10:30.030 --> 10:35.940 That would lead us to some basic information on our event log information or our log information. 10:35.940 --> 10:40.320 We can see the login name is a security, meaning it's a security event. 10:40.320 --> 10:41.490 For a log name. 10:41.490 --> 10:44.190 We can see the event code, which we really don't need to know. 10:44.190 --> 10:50.010 For Sisa as well as the event type, they're not really going to quiz you on this basic information. 10:50.010 --> 10:51.810 Again, think high level. 10:51.810 --> 10:56.820 We can see the computer name in this case is total SIM 001. local. 10:56.820 --> 11:01.800 Now this is important because if we're looking at specific logs associated with this machine, then 11:01.800 --> 11:05.580 we would need to know exactly where this computer name is associated with. 11:05.610 --> 11:11.670 Our source name is Microsoft Windows Security Auditing, meaning that it's a security auditing log From 11:11.670 --> 11:15.050 this specific computer name We can see the type. 11:15.050 --> 11:17.120 It's for informational purposes only. 11:17.150 --> 11:21.320 It also gives us a nice little record number, and it tells us that it's an audit. 11:21.320 --> 11:27.410 We can see that its success is a task category of logoff, meaning that somebody logged off this computer 11:27.410 --> 11:28.070 system. 11:28.070 --> 11:33.770 The operational code is informational only, which we see again is right up here with the type of information 11:33.770 --> 11:35.240 we can see a message. 11:35.240 --> 11:36.830 An account was logged off. 11:36.830 --> 11:41.120 This is what the log tells us when somebody logs off the computer system. 11:41.120 --> 11:46.580 So now we have basic information that corresponds with another meaning that the message tells us as 11:46.580 --> 11:47.150 a log off. 11:47.150 --> 11:49.940 And we can see the task category was log off. 11:49.940 --> 11:51.920 So those two match which is good. 11:51.920 --> 11:57.260 We can see the subject and the security ID is S1 5.18. 11:57.260 --> 11:58.580 And then our account name. 11:58.580 --> 12:04.340 The actual person associated with this log off activity was total SIM 001. 12:04.370 --> 12:10.760 This means that the account associated with it and the computer match up, which may or may not be important. 12:10.760 --> 12:16.800 Remember that the computer name wallets total sim .001 One local could be different from our account 12:16.830 --> 12:19.440 name, which is toll sum 001. 12:19.440 --> 12:21.750 In this case it just happens to match. 12:21.750 --> 12:26.580 We can see the account domain is toll SEM, meaning the domain it's operating on. 12:26.580 --> 12:32.850 And then the logon ID is this specific hexadecimal format associated with the login name. 12:32.850 --> 12:39.390 Finally we see the login type is level three, meaning it's a network logon as opposed to a local logon, 12:39.390 --> 12:41.340 which would be a logon type two. 12:41.370 --> 12:46.320 This event is generated when a logon session is destroyed, and may be positively correlated with the 12:46.320 --> 12:49.290 long end event using the login ID value. 12:49.320 --> 12:55.620 Logon IDs are only unique between reboots on the same computer, meaning that the logon ID could be 12:55.620 --> 13:01.560 changed based on the specific reboot on the same computer, which means it could be different based 13:01.560 --> 13:03.330 on what happened with the computer. 13:03.330 --> 13:06.660 And that's important information that the windows is giving us. 13:06.660 --> 13:11.070 So this is a basic log off log from a windows environment. 13:11.070 --> 13:14.340 But how can you utilize this in a CSR environment. 13:14.340 --> 13:18.890 And what kind of exam questions Can you see now that we've learned how to read this log? 13:18.890 --> 13:25.610 Well, you might see cross coordinated questions where it's asking you specific questions on, hey, 13:25.640 --> 13:29.240 based on this computer name, we saw these other events occur. 13:29.270 --> 13:33.080 Now can we contribute that to this specific log on type. 13:33.080 --> 13:39.140 Well, if we see a log off and then a reset, well then it just told us right off the bat that log on 13:39.200 --> 13:42.560 IDs are only unique between reboots on the same computer. 13:42.560 --> 13:46.250 So that can give us a hint into what's going on with the specific system. 13:46.250 --> 13:49.550 It also tells us that somebody logged off onto the system. 13:49.550 --> 13:55.610 If we see somebody else log on within, that's a timestamp period, or within the next log associated 13:55.610 --> 14:00.830 with it, within the firewall or within a key information, then that would take place to notify us 14:00.830 --> 14:06.260 that, hey, it could be a different account type or a different account ID associated with this same 14:06.260 --> 14:06.920 log on. 14:06.920 --> 14:08.960 And that's important information to take place. 14:08.960 --> 14:13.340 Now I'm going to tell you I've seen some questions on different exams. 14:13.340 --> 14:20.020 Not necessarily Sisa but other certification exams where they specifically denote, hey, this event 14:20.020 --> 14:24.670 occurred and they give you this snippet of a log, and then they provide you with some more logging 14:24.670 --> 14:28.900 information that you need to read and ask you to find the specific information. 14:28.900 --> 14:35.320 Maybe they're asking you to find the malware or the user that associated to downloading a specific executable 14:35.320 --> 14:39.010 or even an email, and this could provide us some key information. 14:39.010 --> 14:45.250 However, I want you to pay very close attention to the date timestamp associated with the login they 14:45.250 --> 14:45.970 gave you. 14:46.000 --> 14:49.990 A lot of times they'll try to trick you and they'll change the login date. 14:49.990 --> 14:56.020 And so you need to correspond the specific login date and timestamp associated with the information 14:56.020 --> 14:57.820 that they're giving you within the question. 14:57.820 --> 15:02.860 Make sure that when you're doing this cross formation or cross coordination between the different logs, 15:02.860 --> 15:09.670 that you pay attention not only to the user ID, but also to the machine name or the computer name and 15:09.670 --> 15:14.260 the type and timestamp, because they like to mess around with those as they're going through. 15:14.290 --> 15:20.060 It's expected that you understand those different complexities and are able to sift through that environment 15:20.060 --> 15:21.620 to answer the basic question. 15:21.650 --> 15:27.020 Now, a lot of the questions they ask you honestly are very common sense based with the basic form of 15:27.020 --> 15:27.770 logic. 15:27.800 --> 15:33.020 A lot of people, when they go for their exam, they don't take the the whiteboard. 15:33.020 --> 15:35.870 And a matter of fact, I did that on my last Sisa. 15:35.900 --> 15:38.540 They asked me, do you want a piece of paper and a pencil? 15:38.540 --> 15:40.310 And I said, no, I'm good. 15:40.340 --> 15:43.220 Because based on my experience, I never really needed it. 15:43.250 --> 15:49.580 However, with this new exam type, with the one I just took for CS 003, I would definitely take it 15:49.580 --> 15:55.220 because it's nothing like one and two, where honestly, the logs and the information really wasn't 15:55.220 --> 15:56.690 that difficult to comprehend. 15:56.720 --> 16:01.400 So as you're going through that exam, make sure you take that whiteboard with you or that scratch paper 16:01.400 --> 16:06.590 so that you can actually make notes, because you will be popping between screens on some of the questions 16:06.590 --> 16:08.030 that aren't multiple choice. 16:08.030 --> 16:13.280 And that could really be beneficial to you, so that you can go through and more accurately depict what 16:13.280 --> 16:14.270 you're looking at. 16:14.300 --> 16:19.750 In this episode, we covered both the Siem and the Soar environment and how to utilize those different 16:19.750 --> 16:24.070 environments as part of our holistic viewpoint for security on our network. 16:24.070 --> 16:28.840 We also talked about endpoint detection and response, and how that's part of our store environment 16:28.840 --> 16:34.300 to provide us some endpoint detection and threat analysis through monitoring and keeping our network 16:34.300 --> 16:40.540 safe, both the Siem and the store work together to provide us a holistic security environment in which 16:40.540 --> 16:41.620 to operate from. 16:41.620 --> 16:46.150 This is going to provide us a more efficient and robust security environment in which our infrastructure 16:46.180 --> 16:48.400 can be more secure across the board. 16:48.400 --> 16:53.950 In the Sisa, you can expect to see different questions attributed both to a Siem environment as well 16:53.950 --> 16:56.620 as a store and specifically the EDR. 16:56.650 --> 17:01.600 You need to memorize the different aspects of the acronyms throughout the Sisa exam. 17:01.600 --> 17:07.480 I know I haven't said this before, but acronyms in my opinion, literally make up about 30% of the 17:07.480 --> 17:08.110 exam. 17:08.110 --> 17:12.940 If you literally just know what the acronyms are, a lot of the questions will actually answer themselves. 17:12.940 --> 17:18.310 For instance, you may see an exam question talking about endpoint detection response that literally 17:18.310 --> 17:24.350 says something like EDR you should expect to see within the scisa environment different questions that 17:24.350 --> 17:30.590 are scenario based, relating back to the same environment as well as the Saw environment and the EDR 17:30.620 --> 17:32.300 as part of that saw environment. 17:32.300 --> 17:37.820 Remember when it talks about automation and response, we're more attributed to the Saw environment. 17:37.820 --> 17:43.430 If we're talking about logs and how to utilize those logs in an easy trackable environment, we're talking 17:43.430 --> 17:44.390 about the Siem. 17:44.390 --> 17:47.150 That is that clear delineation between the two. 17:47.180 --> 17:52.820 When we're talking specifically about endpoints, then we go traverse over to that EDR. 17:52.850 --> 17:55.910 EDR is part of the overall saw environment. 17:55.910 --> 18:00.140 But the saw environment doesn't necessarily have to include an EDR environment. 18:00.140 --> 18:05.720 So if you get a question that's talking about automated response and it specifically references EDR 18:05.720 --> 18:11.690 or endpoints, and it gives you both an answer from a Saw and an EDR, you want to go with the EDR. 18:11.720 --> 18:17.540 It's the more relevant or the better answer because it's more attributed specifically to the EDR. 18:17.570 --> 18:22.130 As part of our question, this should prepare you for your Cisa exam.