WEBVTT 00:00:01.870 --> 00:00:04.790 [Autogenerated] let's take a look at the data that we're ingesting into the 00:00:04.790 --> 00:00:09.940 Elastic Stack and see some visualizations we'll explore Kibana and the event 00:00:09.940 --> 00:00:13.120 data that's coming in and see a few ways to use it. 00:00:13.740 --> 00:00:14.740 Let's hop in. 00:00:16.090 --> 00:00:16.850 All right, 00:00:16.860 --> 00:00:20.590 welcome back to the lab and as we mentioned and this one 00:00:20.590 --> 00:00:24.170 we're gonna be exploring that snort data in Kibana itself 00:00:24.180 --> 00:00:25.750 so we can visualize it better. 00:00:26.540 --> 00:00:30.660 So here we are in our Kibana instance on the global elastic 00:00:30.670 --> 00:00:33.360 box that we have and this is where we were sending those 00:00:33.360 --> 00:00:35.540 snort logs to using file beat. 00:00:36.330 --> 00:00:40.450 Now the first step in making sure that the data is coming in properly is to 00:00:40.450 --> 00:00:43.530 make sure that you have an index pattern defined here. 00:00:44.720 --> 00:00:47.330 So we're going to navigate over to stack management 00:00:47.340 --> 00:00:50.010 and then go to index patterns. 00:00:50.020 --> 00:00:53.760 Now, as you can see, I have a couple different index patterns here, 00:00:53.770 --> 00:00:57.580 but one of them is built specifically for file beat dash snort. 00:00:57.590 --> 00:00:59.560 Now the file b dash snort, 00:00:59.570 --> 00:01:03.360 that's part of the index parameter that we had being sent from our 00:01:03.370 --> 00:01:06.870 Elasticsearch output portion of the configuration file for file 00:01:06.870 --> 00:01:12.200 beat and then the star is a wild card meaning I don't care about 00:01:12.200 --> 00:01:14.170 what day the data came in. 00:01:14.980 --> 00:01:18.860 This index pattern will support all of it and then we can 00:01:18.860 --> 00:01:21.200 control the date in the actual search parameters. 00:01:22.020 --> 00:01:23.720 So let's check this out. 00:01:23.740 --> 00:01:28.250 This index pattern specifically defines all of the fields and field 00:01:28.250 --> 00:01:32.150 mapping is that we have available to us from the snort logs. 00:01:32.780 --> 00:01:37.330 This is based on what Kibana knows and what is also seen coming 00:01:37.330 --> 00:01:41.520 in and what's really cool about this is we can modify the fields 00:01:41.530 --> 00:01:45.770 and have custom labels or custom formatting and there's even 00:01:45.770 --> 00:01:49.010 advanced settings here, as I mentioned before. 00:01:49.010 --> 00:01:52.050 If you need a refresher on the Elastic Stack Pluralsight has a 00:01:52.050 --> 00:01:55.730 lot of course is dedicated to how to get this up and running very 00:01:55.730 --> 00:02:00.400 quickly now that we saw some of the fields available and the 00:02:00.400 --> 00:02:02.860 index pattern specifically, let's go search the data. 00:02:03.750 --> 00:02:07.810 I'm gonna navigate over to the discover tab or the discovered dashboard 00:02:07.820 --> 00:02:13.510 and this is where we search our data in this little drop-down I'm gonna 00:02:13.510 --> 00:02:17.110 change the index pattern to our file beat Snort one just to make sure 00:02:17.110 --> 00:02:22.510 that that's the data that we're pulling And we have all of our events now 00:02:22.510 --> 00:02:27.220 my search defaulted to the last 15 minutes and as you can see we have 116 00:02:27.220 --> 00:02:27.870 records here. 00:02:29.090 --> 00:02:34.100 If we expand one of them we can see a lot of information and a lot of 00:02:34.100 --> 00:02:36.970 those fields that we saw just now in the index patterns. 00:02:37.910 --> 00:02:43.130 Our action for this one was lau we have our agent information from where 00:02:43.130 --> 00:02:46.240 we got the data from which was the global p cap box. 00:02:47.130 --> 00:02:48.000 We have our I. 00:02:48.000 --> 00:02:52.420 P addresses and our Mac addresses for who transmitted the information, 00:02:53.520 --> 00:02:57.870 we have the operating system type where the log came from and then 00:02:57.870 --> 00:03:02.710 finally we have the log message itself with all of the information 00:03:02.710 --> 00:03:04.160 and the field value pairs there. 00:03:05.410 --> 00:03:06.280 We have a rule I. 00:03:06.280 --> 00:03:06.740 D. 00:03:06.750 --> 00:03:08.610 So this is the rule that was triggered. 00:03:08.750 --> 00:03:13.640 We have our CID are VLAN number and that snort tag as well. 00:03:13.670 --> 00:03:15.690 So there's a lot of information here. 00:03:17.180 --> 00:03:20.290 It's really cool that we can look at this data and really 00:03:20.290 --> 00:03:22.280 understand what was going on with it. 00:03:22.950 --> 00:03:26.180 So being able to search the snort data in a visual 00:03:26.180 --> 00:03:28.260 manner is an awesome capability. 00:03:28.260 --> 00:03:32.010 So we can sift through the logs and identify specific events 00:03:32.010 --> 00:03:33.570 that are happening in our environment. 00:03:34.220 --> 00:03:38.130 And if you use the Elastic Stack or any other sim for log ingestion, 00:03:38.140 --> 00:03:43.490 you can build in automation capabilities to define alerts for specific events, 00:03:43.490 --> 00:03:47.230 you can tie it into an orchestration to allow yourself 00:03:47.230 --> 00:03:50.050 remediation actions for specific events as well. 00:03:50.060 --> 00:03:55.640 So tying snort into a sim and having those logs centrally available 00:03:55.650 --> 00:03:59.850 and searchable is such a powerful capability and it's not just for 00:03:59.850 --> 00:04:01.600 snore it's for any security product. 00:04:01.600 --> 00:04:04.850 Having that information available is crucial to being able to 00:04:04.850 --> 00:04:08.810 understand not only what happened but create the ability to 00:04:08.810 --> 00:04:10.290 mitigate that moving forward. 00:04:11.170 --> 00:04:16.060 We can also use kibana to visualize the information here. 00:04:16.070 --> 00:04:21.010 So if we go to the visualization library we can pull up specific 00:04:21.010 --> 00:04:25.150 visualizations that have been pre built for applications, 00:04:25.160 --> 00:04:27.580 There's visualizations in here for snore, 00:04:27.590 --> 00:04:33.520 there's ones for Apache for a sp .NET API servers so on and so forth. 00:04:33.520 --> 00:04:37.020 There's a lot of built in visualizations but you can also create your 00:04:37.020 --> 00:04:40.540 own and so I'm just going to create a quick lens one, 00:04:40.540 --> 00:04:44.370 but you can add G o IP data and view maps with the 00:04:44.370 --> 00:04:46.750 destination I PS at the source I PS of them, 00:04:46.750 --> 00:04:49.740 you can create your custom visualizations or 00:04:49.750 --> 00:04:53.620 aggregation based ones for the lens one. 00:04:53.630 --> 00:04:56.080 We're just going to create a simple chart with some of the 00:04:56.080 --> 00:04:59.840 data so I'm gonna switch that to snort and I want to search 00:04:59.840 --> 00:05:02.150 for the host IP just as an example. 00:05:02.150 --> 00:05:07.230 So I searched that in the search box and now I can just drag and drop the 00:05:07.230 --> 00:05:11.080 field that I want to create a chart for straight over to this. 00:05:11.090 --> 00:05:15.680 And as you can see we have two IPv4 addresses and two IPv6 00:05:15.680 --> 00:05:17.950 addresses and these are for the same exact box, 00:05:18.850 --> 00:05:22.160 we can change up the visualization and make them donuts or 00:05:22.160 --> 00:05:26.880 make them a daily bar stacked chart and we can add additional 00:05:26.880 --> 00:05:28.810 layers onto these visualizations. 00:05:28.820 --> 00:05:32.580 So the visualization piece alone is a super powerful tool in 00:05:32.580 --> 00:05:36.430 Kibana and this is just a very small example of it. 00:05:37.320 --> 00:05:40.680 Now you might be thinking why is all of the data that we're 00:05:40.680 --> 00:05:44.480 getting in from snort only about the snort box and not about 00:05:44.490 --> 00:05:46.090 any of the hosts in the network. 00:05:46.180 --> 00:05:50.510 Well it doesn't have a lot of rules configured for it to use yet, 00:05:50.560 --> 00:05:53.050 there's only a couple and we haven't triggered them yet 00:05:53.110 --> 00:05:55.830 and if we want to confirm what some of these fields are 00:05:55.830 --> 00:05:59.340 that we're actually receiving, we can google the rule idea. 00:05:59.370 --> 00:06:02.650 So 1 12 1 colon 11. 00:06:02.660 --> 00:06:05.690 Let's go ahead and google that and we can pull that 00:06:05.690 --> 00:06:07.590 straight up into the snort rule docks. 00:06:08.710 --> 00:06:11.280 Just a normal art request that's unique cast. 00:06:11.280 --> 00:06:12.190 Not broadcast. 00:06:14.200 --> 00:06:17.380 What I really love about the ability to search the snort rule 00:06:17.380 --> 00:06:19.470 docks though is the information that it provides. 00:06:19.470 --> 00:06:23.680 This one's not giving us much because it's just an art message but 00:06:23.680 --> 00:06:26.580 some of the other rules will have extensive documentation in here 00:06:26.580 --> 00:06:28.900 and link to the miter attack framework. 00:06:29.520 --> 00:06:29.950 Alright. 00:06:29.950 --> 00:06:34.440 The last thing I want to show you is the security dashboard now, 00:06:34.450 --> 00:06:35.990 this is really cool. 00:06:36.000 --> 00:06:38.580 If you're using the Elastic Stack for security use cases, 00:06:38.580 --> 00:06:42.050 if you're using it for snore or any other security platform, 00:06:42.660 --> 00:06:46.920 you could actually create those detection rules and alerts that I was talking 00:06:46.920 --> 00:06:51.340 about a couple of minutes ago and actually investigate any events that are 00:06:51.340 --> 00:06:54.540 occurring on your network straight from in here. 00:06:54.550 --> 00:06:56.600 Now, if your dad is not normalized, 00:06:56.610 --> 00:07:02.170 you have to be careful because a lot of the capabilities in Kibana need some 00:07:02.170 --> 00:07:06.130 sort of normalization in the BCS standard so keep that in mind, 00:07:06.140 --> 00:07:09.200 you'll need to make sure that you have your data normalized to be able to 00:07:09.200 --> 00:07:12.420 use some of these features but it's really cool because you can go in and 00:07:12.420 --> 00:07:18.320 create alerts and also there's a whole bunch of rules pre configured for 00:07:18.330 --> 00:07:20.310 tools like snore and stuff like that. 00:07:20.310 --> 00:07:20.560 Right? 00:07:20.560 --> 00:07:24.870 So we have rules defined for sport scanning and trace route and tell night. 00:07:24.900 --> 00:07:28.010 So you have a lot of built in capabilities that you can use 00:07:28.020 --> 00:07:30.270 straight out of the box right after you set it up.