WEBVTT 1 00:00.000 --> 00:04.270 I'd like to walk you through one more example of leveraging events and 2 00:04.270 --> 00:05.840 incidents in tracking 3 00:05.840 --> 00:09.440 a bigger problem or issues that are happening on the network. So here we are in 4 00:09.440 --> 00:10.160 40 analyzers. 5 00:10.160 --> 00:15.130 Let's begin by going to incidents and events and let's start off by going to 6 00:15.130 --> 00:16.240 event monitor. 7 00:16.240 --> 00:20.490 And what I'd like to do is take a look at the last, let's go ahead and say the 8 00:20.490 --> 00:21.360 last hour. 9 00:21.360 --> 00:24.320 So there's been a bunch of events that have been created. Again, those are all 10 00:24.320 --> 00:25.120 created 11 00:25.120 --> 00:29.550 courtesy of our wonderful event handlers right here. And so let's go ahead and 12 00:29.550 --> 00:30.640 do a sort. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:29.550 --> 00:30.640 do a sort. So 13 00:30.640 --> 00:33.750 if we have a custom view that we can use, we can choose that. So I've got a 14 00:33.750 --> 00:34.480 custom view. If 15 00:34.480 --> 00:38.240 you use the drop down here, I've got one called critical, which is filtering 16 00:38.240 --> 00:38.960 just on severity 17 00:38.960 --> 00:42.500 equals critical. So we'll go and say last hour. And here we have this Linux 18 00:42.500 --> 00:42.880 client. 19 00:42.880 --> 00:49.510 Wow, busy Linux client. So all of these are critical. They're all in the event 20 00:49.510 --> 00:51.120 type IPS. And 21 00:51.120 --> 00:54.660 they have all happened within the last hour. Let's actually go down to the last 22 00:54.660 --> 00:56.160 30 minutes. Yeah, 23 00:56.160 --> 01:00.080 that's a lot. So let's go ahead and grab all these. And what we'll do is we'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 23 00:56.160 --> 01:00.080 that's a lot. So let's go ahead and grab all these. And what we'll do is we'll 24 01:00.080 --> 01:00.880 right click and we'll 25 01:00.880 --> 01:04.940 simply with the drop down here, create a new incident. If it fits into the one 26 01:04.940 --> 01:06.080 of the categories that's 27 01:06.080 --> 01:09.800 predefined for us, we can use that or we could go ahead and click on the plus 28 01:09.800 --> 01:10.560 symbol and so let 29 01:10.560 --> 01:14.540 me create a new category. And let's call it not sure yet. And I just lost 30 01:14.540 --> 01:16.320 connectivity to my 40 31 01:16.320 --> 01:21.460 analyzer. And I am not sure why. However, I did launch a whole bunch of attacks 32 01:21.460 --> 01:23.200 in the last 30 33 01:23.200 --> 01:29.380 minutes. So I could have caught something here in my lab environment. I'm not 34 01:29.380 --> 01:30.320 sure. We'll find WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 34 01:29.380 --> 01:30.320 sure. We'll find 35 01:30.320 --> 01:34.340 out here in a moment. All the attacks that I launched were from little VMs, not 36 01:34.340 --> 01:35.200 from my management 37 01:35.200 --> 01:40.470 PC here. So let me go ahead and let me do a refresh and advanced and continue. 38 01:40.470 --> 01:40.720 All right, 39 01:40.720 --> 01:45.430 let's go back and take a look at the last 30 minutes. In fact, let's go the 40 01:45.430 --> 01:46.880 last hour. Great, great, 41 01:46.880 --> 01:49.710 great. And I think we created the incident. I think it took so let's go take a 42 01:49.710 --> 01:50.240 look. We'll 43 01:50.240 --> 01:53.890 get incidents and no, it didn't create so let's go ahead and take these 44 01:53.890 --> 01:54.960 existing incidents, get 45 01:54.960 --> 01:59.230 it out of the way, right click and delete and okay. And let's go back to event 46 01:59.230 --> 02:00.240 monitor and let's go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 46 01:59.230 --> 02:00.240 monitor and let's go 47 02:00.240 --> 02:04.380 back to the filter for the last 30 minutes. And we'll right click here and do a 48 02:04.380 --> 02:05.520 filter matching only 49 02:05.520 --> 02:09.280 on critical. And sure enough, there's our client. Wow. Okay, that client's been 50 02:09.280 --> 02:10.240 pretty busy. So we'll 51 02:10.240 --> 02:13.820 do is we'll right click once again. And we're going to take all 65 of those 52 02:13.820 --> 02:14.480 events. And we're 53 02:14.480 --> 02:17.580 going to create a new incident. And for the category, I'm going to go ahead and 54 02:17.580 --> 02:18.880 click in the plus symbol 55 02:18.880 --> 02:22.310 and call it not sure yet. That's where it blew up on us last time. So we'll 56 02:22.310 --> 02:23.360 click on okay. 57 02:23.360 --> 02:27.280 Now that's better. And for MITRE Tech, I'm not sure yet, which I do that would 58 02:27.280 --> 02:28.160 be severity. 59 02:28.160 --> 02:31.760 They are all critical. So we're going to leave it high. And for the status, I'm WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 02:28.160 --> 02:31.760 They are all critical. So we're going to leave it high. And for the status, I'm 60 02:31.760 --> 02:32.560 going to go ahead 61 02:32.560 --> 02:36.200 and let's go and put it into analysis mode and for the description, for the 62 02:36.200 --> 02:37.040 description, we'll put 63 02:37.040 --> 02:42.120 need to sort this out. And then we'll assign that to myself. And we'll click on 64 02:42.120 --> 02:43.280 okay. All right. So now 65 02:43.280 --> 02:49.160 we have a new incident with all of those events. Let's go to incidents. And 66 02:49.160 --> 02:50.720 there it is. And let's 67 02:50.720 --> 02:54.630 begin. So we'll double click on the incident. So the effect at endpoint is 80 68 02:54.630 --> 02:55.600 user two at the IP 69 02:55.600 --> 03:00.810 address 1020 0.102 with this MAC address. So if there's a whole bunch of stuff WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 02:55.600 --> 03:00.810 address 1020 0.102 with this MAC address. So if there's a whole bunch of stuff 70 03:00.810 --> 03:01.920 happening with that 71 03:01.920 --> 03:06.850 IP address right now, I might want to take a moment and find that device find 72 03:06.850 --> 03:08.240 that user and basically 73 03:08.240 --> 03:12.020 turn off that device physically or forget the option within point software 74 03:12.020 --> 03:13.040 running on that device. 75 03:13.040 --> 03:16.570 We could quarantine it. But certainly there's a lot going on. So let's go ahead 76 03:16.570 --> 03:17.680 and scroll down. 77 03:17.680 --> 03:21.760 So here's the attack timeline. We can also scroll with the mouse to go ahead 78 03:21.760 --> 03:23.040 and make that larger or 79 03:23.040 --> 03:27.480 smaller. I'll go ahead and continue scrolling down. And here are the events. So 80 03:27.480 --> 03:28.240 let me go ahead and 81 03:28.240 --> 03:31.810 use the gear. I'm going to remove the column for suppress and leave everything WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 03:28.240 --> 03:31.810 use the gear. I'm going to remove the column for suppress and leave everything 82 03:31.810 --> 03:32.960 else there. Let's go 83 03:32.960 --> 03:36.210 back and take a look. So as we scroll down, there are some intrusion port 84 03:36.210 --> 03:38.160 scanning. As we continue 85 03:38.160 --> 03:41.710 to scroll down, there are some SQL injection happening. So I was going to grab 86 03:41.710 --> 03:42.720 one of these right click 87 03:42.720 --> 03:46.700 on it. And I want to do a search and log view. And that's going to take us out 88 03:46.700 --> 03:47.760 into another pane 89 03:47.760 --> 03:51.050 of glass where we're going to go into logs. And that way I can come back here 90 03:51.050 --> 03:52.000 right where I left 91 03:52.000 --> 03:55.840 it. So we'll click here search and log view. So here in log view, let's go 92 03:55.840 --> 03:56.960 ahead and narrow it down 93 03:56.960 --> 04:01.690 to that IP address, which is 10 dot 20 dot 0 dot 102. So currently, I'm only WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 93 03:56.960 --> 04:01.690 to that IP address, which is 10 dot 20 dot 0 dot 102. So currently, I'm only 94 04:01.690 --> 04:02.880 looking at HQ firewall 95 04:02.880 --> 04:06.330 one. I'm going to go ahead and say I want to look at all devices, click OK. And 96 04:06.330 --> 04:06.720 here I'm going to 97 04:06.720 --> 04:11.690 specify the last hour. And then this is the traffic logs we're looking at. Let 98 04:11.690 --> 04:12.880 me go ahead and let's 99 04:12.880 --> 04:19.000 go to security and IPS. And these are all about that machine at 1020 0 dot 102. 100 04:19.000 --> 04:21.360 So we're using HTTP, 101 04:21.360 --> 04:23.950 going to this IP address, which is in the US. Oh, and then there's a whole 102 04:23.950 --> 04:24.560 bunch of other 103 04:24.560 --> 04:29.000 addresses here 23 dot 102 shows us Spain. But that's the little subnet I use 104 04:29.000 --> 04:29.760 here in my lab 105 04:29.760 --> 04:33.290 environment that represents the rest of the internet. And here showing TCP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 105 04:29.760 --> 04:33.290 environment that represents the rest of the internet. And here showing TCP 106 04:33.290 --> 04:34.640 protocol number four. So if 107 04:34.640 --> 04:37.460 we want to know more about that, I'll double click on that and scroll down. Oh, 108 04:37.460 --> 04:37.920 that's the 109 04:37.920 --> 04:42.880 decision port. So the source port was a high number for 49,026. And as far as 110 04:42.880 --> 04:44.720 destination port of four, 111 04:44.720 --> 04:48.450 I'm curious what that is. So I'm going to do a quick search and look up TCP 112 04:48.450 --> 04:49.600 port number four. 113 04:49.600 --> 04:55.440 So port number four is not an assigned well known port. All right, so that's a 114 04:55.440 --> 04:56.480 little bit concerning. 115 04:56.480 --> 04:59.360 And so I might want to leverage here. I might want to leverage the option here 116 04:59.360 --> 05:00.320 for threat hunting. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 04:59.360 --> 05:00.320 for threat hunting. 117 05:00.320 --> 05:03.830 And that way, threat hunting, I can go ahead and search based on some 118 05:03.830 --> 05:05.200 categories. So I'm going to 119 05:05.200 --> 05:08.780 go ahead and start here with source IP and the address is 10 dot 20 dot 0 dot 120 05:08.780 --> 05:09.920 102. This is just 121 05:09.920 --> 05:13.110 right here. So let me right click on that and I'm going to add that to hunting, 122 05:13.110 --> 05:13.760 which effectively 123 05:13.760 --> 05:17.830 is just adding a filter here. And let me also go ahead over to a threat name 124 05:17.830 --> 05:18.480 and look at all these 125 05:18.480 --> 05:21.460 threats and that filter in place means they're all associated with that IP 126 05:21.460 --> 05:22.800 address. So some 127 05:22.800 --> 05:26.980 port scanning, some malicious websites, some unrated websites, and also a SQL 128 05:26.980 --> 05:28.160 injection attack. And 129 05:28.160 --> 05:31.540 if I want to focus on destination here, we can click on destination. And a lot WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 129 05:28.160 --> 05:31.540 if I want to focus on destination here, we can click on destination. And a lot 130 05:31.540 --> 05:32.160 of these, oh, 131 05:32.160 --> 05:36.090 these would have been for a scan. Looks like they're scanning the entire subnet 132 05:36.090 --> 05:36.720 and for the threat 133 05:36.720 --> 05:40.350 type. So the reconnaissance here, those were all blocked. That's why it's 134 05:40.350 --> 05:41.600 yellow there. And risky 135 05:41.600 --> 05:44.840 destination. If we don't click on that, it'll put a filter in for us. Then we 136 05:44.840 --> 05:45.600 can take a closer 137 05:45.600 --> 05:48.790 look. It looks like these are all some name resolution. So let me close that. 138 05:48.790 --> 05:49.840 So this is a great way of 139 05:49.840 --> 05:53.980 drilling into the logs as we need to, taking a closer look at the nitty gritty 140 05:53.980 --> 05:54.880 details. So I'm 141 05:54.880 --> 05:58.080 going to go back to the original pane for the Fort analyzer, back to our 142 05:58.080 --> 05:59.520 instant analysis. And if 143 05:59.520 --> 06:02.550 other people are working on this as well, I could click on refresh and get the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 143 05:59.520 --> 06:02.550 other people are working on this as well, I could click on refresh and get the 144 06:02.550 --> 06:03.360 latest and greatest 145 06:03.360 --> 06:06.460 information here. And here's a sequence. In fact, there's two SQL injection 146 06:06.460 --> 06:07.200 attacks and go ahead 147 06:07.200 --> 06:11.110 and click on that. And I'm going to go ahead and do a view logs for that first 148 06:11.110 --> 06:12.080 one. And look at 149 06:12.080 --> 06:17.150 the details. So here, this was reported by firewall one, the destination was 65 150 06:17.150 --> 06:20.160 .61.137.117. We scroll 151 06:20.160 --> 06:23.780 down on a thread of the SQL injection attack. If you scroll down further, it's 152 06:23.780 --> 06:24.240 going to test 153 06:24.240 --> 06:29.230 fire. So that's a test website from IBM. So that may not be too much of a real 154 06:29.230 --> 06:30.320 risk. Let's take a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 154 06:29.230 --> 06:30.320 risk. Let's take a 155 06:30.320 --> 06:35.050 look at the other one. So here, if we click on this second one, and we click on 156 06:35.050 --> 06:36.000 view logs, and then 157 06:36.000 --> 06:39.430 we don't click on the details here and we scroll down. This is also a SQL 158 06:39.430 --> 06:40.640 injection attack as it 159 06:40.640 --> 06:43.640 showed right here. And if you scroll down, where was this one going? This is 160 06:43.640 --> 06:45.120 also going to test fire. 161 06:45.120 --> 06:48.720 Because it looks like it was not going to a production website, where they're 162 06:48.720 --> 06:49.280 really trying to 163 06:49.280 --> 06:52.450 attack somebody. And the risk looks like port scanning. So I'm going to go to 164 06:52.450 --> 06:53.440 reports. So here, 165 06:53.440 --> 06:58.030 with all reports selected, I'm going to search for 360. And here's a 40 gate 166 06:58.030 --> 06:59.440 360 security report. 167 06:59.440 --> 07:02.480 I'm going to go ahead and select that. And I'm going to go ahead and run that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 06:59.440 --> 07:02.480 I'm going to go ahead and select that. And I'm going to go ahead and run that 168 07:02.480 --> 07:03.120 report. We can do 169 07:03.120 --> 07:06.890 either by clicking on run report or right clicking on it. And then from here, 170 07:06.890 --> 07:08.320 selecting run report. 171 07:08.320 --> 07:11.720 And in a moment, that will be generated. And we can associate that or attach 172 07:11.720 --> 07:12.240 that 173 07:12.240 --> 07:17.390 to our incident. So here's the generated reports. And based on the timestamps. 174 07:17.390 --> 07:18.560 And there is our running 175 07:18.560 --> 07:22.710 report right there. Okay, fantastic. So that'll be ready here in a moment or 176 07:22.710 --> 07:23.440 two, there's a little 177 07:23.440 --> 07:27.290 progress bar over on the right for status. And once it's done, we can right 178 07:27.290 --> 07:28.640 click and associate 179 07:28.640 --> 07:32.660 that or include that as part of our incident. All right, that report is almost WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 07:28.640 --> 07:32.660 that or include that as part of our incident. All right, that report is almost 180 07:32.660 --> 07:33.680 ready. All right. 181 07:33.680 --> 07:36.720 So we'll right click on it. And what we can do is add that to an existing 182 07:36.720 --> 07:38.000 incident, which we will. 183 07:38.000 --> 07:41.280 And there's our only incident I deleted the other so we'll select it and click 184 07:41.280 --> 07:42.320 on. Okay. All right, 185 07:42.320 --> 07:46.970 it's been successfully attached. So now to go back to the incident and events 186 07:46.970 --> 07:48.160 and go to our incidents, 187 07:48.160 --> 07:52.950 that report is now included there for taking a look at. So if we scroll down 188 07:52.950 --> 07:53.680 under the reports 189 07:53.680 --> 07:57.120 widget, it's right here. So we can go ahead and click on the PDF and it'll open 190 07:57.120 --> 07:57.760 it up for us. 191 07:57.760 --> 08:02.240 And the data included here is based on that 360 report definition. Some Wi-Fi, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 191 07:57.760 --> 08:02.240 And the data included here is based on that 360 report definition. Some Wi-Fi, 192 08:02.240 --> 08:02.960 top 10 policy 193 08:02.960 --> 08:08.340 by bandwidth, top 10 policy by session, top 10 policy details, top sources, top 194 08:08.340 --> 08:09.200 destinations. 195 08:09.200 --> 08:12.560 And as we continue to scroll down, here's threat detection prevention, 196 08:12.560 --> 08:13.600 application visibility and 197 08:13.600 --> 08:17.570 control. And as we continue to scroll down, here we have top 10 web categories 198 08:17.570 --> 08:18.160 by visited, 199 08:18.160 --> 08:22.470 top five viruses bots, spyware, adware, phishing sites, top five victims of 200 08:22.470 --> 08:23.040 malware, 201 08:23.040 --> 08:28.120 top five malicious phishing sites, and application vulnerabilities. So here for 202 08:28.120 --> 08:29.280 the SQL injection, 203 08:29.280 --> 08:33.280 it's showing a count of 13, many of those which recently happened. So this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 203 08:29.280 --> 08:33.280 it's showing a count of 13, many of those which recently happened. So this 204 08:33.280 --> 08:34.400 report may not be too 205 08:34.400 --> 08:37.750 valuable for the incident that we're currently working on. So we might want to 206 08:37.750 --> 08:38.480 choose a more 207 08:38.480 --> 08:42.000 detailed report focusing on the events that are happening. I just kind of 208 08:42.000 --> 08:43.120 grabbed one at random. 209 08:43.120 --> 08:47.540 So based on this incident with the events that are included, it looks like the 210 08:47.540 --> 08:48.240 client was doing a 211 08:48.240 --> 08:51.240 lot of port scanning. And the handler that picked it up was the default 212 08:51.240 --> 08:52.400 malicious code detection. 213 08:52.400 --> 08:56.030 So if the client had some malware installed and that malware was beginning to 214 08:56.030 --> 08:56.880 scan other parts of 215 08:56.880 --> 09:00.560 the network, that's what caught it. So this default malicious code detection by WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 215 08:56.880 --> 09:00.560 the network, that's what caught it. So this default malicious code detection by 216 09:00.560 --> 09:01.840 endpoint handler 217 09:01.840 --> 09:05.560 matched on this rule right here intrusion detection group by destination 218 09:05.560 --> 09:06.240 endpoint. 219 09:06.240 --> 09:08.850 So we'll close that. And if we think there's other events that should be 220 09:08.850 --> 09:10.160 associated with this 221 09:10.160 --> 09:13.360 from that client, we could go back to event monitor. And I'm going to go ahead 222 09:13.360 --> 09:13.840 and specify 223 09:13.840 --> 09:17.000 for the last four hours, and I'm also going to remove the filter for just 224 09:17.000 --> 09:17.840 critical. And let's 225 09:17.840 --> 09:22.020 take a closer look at this one. So this also was a source user 10200102. So 226 09:22.020 --> 09:22.880 that's also suspicious 227 09:22.880 --> 09:26.880 we can right click on that one and add that to our existing incident. So here's 228 09:26.880 --> 09:27.440 our incident. We'll 229 09:27.440 --> 09:30.670 add that click on OK. There's another DNS request made to a malicious WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 229 09:27.440 --> 09:30.670 add that click on OK. There's another DNS request made to a malicious 230 09:30.670 --> 09:31.680 destination. So 231 09:31.680 --> 09:37.540 let's double click on that and open up the details. And that was successful. So 232 09:37.540 --> 09:38.160 that was a malicious 233 09:38.160 --> 09:41.780 website and the DNS resolution was successful. So it was a DNS request to a 234 09:41.780 --> 09:43.040 malicious website. 235 09:43.040 --> 09:46.760 So let's remove the lows and mediums. I'll right click here and say we don't 236 09:46.760 --> 09:48.000 want to see the lows. 237 09:48.000 --> 09:52.220 And let's also say we don't care about seeing the mediums. So add that under 238 09:52.220 --> 09:54.000 search here say and 239 09:54.000 --> 09:57.660 not medium. And that was just leave our highs and criticals. So the port 240 09:57.660 --> 09:59.040 scanning we know about 241 09:59.040 --> 10:03.030 the SQL injection we took a look at. And those events are already included as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 241 09:59.040 --> 10:03.030 the SQL injection we took a look at. And those events are already included as 242 10:03.030 --> 10:04.160 part of our incident. 243 10:04.160 --> 10:10.910 But this DNS request and that one and that one and that one and that one, which 244 10:10.910 --> 10:11.600 all just recently 245 10:11.600 --> 10:15.400 happened, they could be also associated with that user, Cisco, and grab all 246 10:15.400 --> 10:16.960 those and right click. 247 10:16.960 --> 10:20.370 And we'll add those to the existing incident as well. So there's our incident. 248 10:20.370 --> 10:20.880 We'll select it 249 10:20.880 --> 10:25.120 and click on OK. So it says successfully added seven events to that incident. 250 10:25.120 --> 10:25.760 So now as we scroll 251 10:25.760 --> 10:29.300 down, we have these additional events included as part of our incident. So we 252 10:29.300 --> 10:30.560 select one of those. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 252 10:29.300 --> 10:30.560 select one of those. 253 10:30.560 --> 10:35.090 Sure enough, it is 80 user two. And if we double click on the details, that was 254 10:35.090 --> 10:35.920 an A record request. 255 10:35.920 --> 10:42.300 So this customer is successfully able to resolve names to IP addresses for 256 10:42.300 --> 10:43.360 malicious websites. 257 10:43.360 --> 10:46.560 In this example, that was the website right there. And this is being reported 258 10:46.560 --> 10:48.480 by firewall one. 259 10:48.480 --> 10:53.320 Also, this log was created from this profile called DNS monitor. And the 260 10:53.320 --> 10:55.440 protocol was UDP that 17 261 10:55.440 --> 11:00.320 and was coming from 80 user to. So what we might want to do is take a look and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 261 10:55.440 --> 11:00.320 and was coming from 80 user to. So what we might want to do is take a look and 262 11:00.320 --> 11:01.120 see what the heck 263 11:01.120 --> 11:05.720 is going on with firewall one that would allow all this type of malicious 264 11:05.720 --> 11:06.880 activity to happen. 265 11:06.880 --> 11:12.880 Port scans, SQL injections, and also name resolution for malicious websites. 266 11:12.880 --> 11:15.680 And again, if we wanted to go ahead and do additional searching, we could do a 267 11:15.680 --> 11:16.720 search and log view, 268 11:16.720 --> 11:20.170 which again, opens up a separate pane. Once again, we get a threat hunting for 269 11:20.170 --> 11:20.880 the time frame that 270 11:20.880 --> 11:24.310 we want to look at, go to source IP, give it a moment to refresh. And then here 271 11:24.310 --> 11:24.960 we could add 272 11:24.960 --> 11:29.160 that as a filter or just view the raw logs by clicking on view logs. And then 273 11:29.160 --> 11:29.680 it'll put the 274 11:29.680 --> 11:33.990 filtering for us. So if we want to not see the notices, we can go ahead and say WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 274 11:29.680 --> 11:33.990 filtering for us. So if we want to not see the notices, we can go ahead and say 275 11:33.990 --> 11:34.480 , don't include 276 11:34.480 --> 11:38.830 notice and right click and say, and not informational and not warning by 277 11:38.830 --> 11:41.200 clicking add and filter events 278 11:41.200 --> 11:44.720 ready, not equal to warning, and then further drill down into any of these 279 11:44.720 --> 11:45.680 specific logs. 280 11:45.680 --> 11:50.000 So it appears based on the logs that we're looking at and the ones we've added 281 11:50.000 --> 11:50.560 into the 282 11:50.560 --> 11:54.190 incident. And we see that by going back to incident events and the incidents 283 11:54.190 --> 11:55.440 looks like this user, 284 11:55.440 --> 12:00.650 which is 80 user to a disciple address had issued several SQL injection attacks WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 284 11:55.440 --> 12:00.650 which is 80 user to a disciple address had issued several SQL injection attacks 285 12:00.650 --> 12:00.880 , 286 12:00.880 --> 12:05.750 which are shown right here. They also did some port scanning of some networks 287 12:05.750 --> 12:06.160 looked like it was 288 12:06.160 --> 12:11.500 in the 23.1.2 address base, and also made a ton of DNS requests that were 289 12:11.500 --> 12:12.800 successful regarding 290 12:12.800 --> 12:16.660 malicious websites. So it could end up being an end user that is curious and 291 12:16.660 --> 12:18.080 trying out some things, 292 12:18.080 --> 12:21.990 or it could be some malware that's installed on their computer that's trying to 293 12:21.990 --> 12:22.560 make these 294 12:22.560 --> 12:26.350 outbound requests, including the scans. And behind these events, if we look at 295 12:26.350 --> 12:27.040 the details here in 296 12:27.040 --> 12:31.120 the logs, they're all coming from firewall one. So the proper course of action WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 296 12:27.040 --> 12:31.120 the logs, they're all coming from firewall one. So the proper course of action 297 12:31.120 --> 12:32.000 would be a couple 298 12:32.000 --> 12:36.440 things. Number one, we'd want to lock down that device that IP address. So it 299 12:36.440 --> 12:37.280 can't do additional 300 12:37.280 --> 12:41.960 harm or damage. We'd want to have chat with 80 user to probably with HR 301 12:41.960 --> 12:43.280 regarding policies, 302 12:43.280 --> 12:47.410 acceptable use policies. And we also want to make sure that on the firewall 303 12:47.410 --> 12:48.160 firewall one, 304 12:48.160 --> 12:51.360 that we correct the security issues that allowed that traffic to happen in the 305 12:51.360 --> 12:51.760 first place, 306 12:51.760 --> 12:55.210 because most of that traffic was allowed. So if we go back to firewall one, we 307 12:55.210 --> 12:55.840 can also see the 308 12:55.840 --> 12:59.600 logs here as well. If you're good at a login report and good or security events 309 12:59.600 --> 13:00.160 , I'm going to go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 309 12:59.600 --> 13:00.160 , I'm going to go 310 13:00.160 --> 13:04.520 ahead and tell it to pull from memory. And let's go to IPS. And sure enough, it 311 13:04.520 --> 13:05.680 was 80 user two. 312 13:05.680 --> 13:09.840 There's a SQL injection, there's the port scanning. And so the fact that they 313 13:09.840 --> 13:10.960 were able to do that, 314 13:10.960 --> 13:14.500 let's just open up one of these. And here we can also see what the policy was 315 13:14.500 --> 13:15.440 here on firewall one 316 13:15.440 --> 13:19.730 that allowed that. So right here, we have a policy idea of temp for vendor. Oh 317 13:19.730 --> 13:21.280 my gosh. So it very 318 13:21.280 --> 13:24.970 likely could have been some policy was put in place for the benefit of a vendor 319 13:24.970 --> 13:25.920 . It says temp. 320 13:26.720 --> 13:30.400 Maybe they needed to test something. And it wasn't approved. It didn't go WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 320 13:26.720 --> 13:30.400 Maybe they needed to test something. And it wasn't approved. It didn't go 321 13:30.400 --> 13:31.680 through change control. 322 13:31.680 --> 13:35.800 And unfortunately, it's allowing this user 80 user to to send out a lot of 323 13:35.800 --> 13:36.720 traffic that shouldn't be 324 13:36.720 --> 13:40.200 going through the firewall. So let's go find that policy. So we go to policy 325 13:40.200 --> 13:40.800 and objects. 326 13:40.800 --> 13:45.190 Go to firewall policy here on firewall one. There it is right there. If we 327 13:45.190 --> 13:45.920 double click on it, 328 13:45.920 --> 13:49.270 take a look at the profiles associated with it. It looks like it's allowing any 329 13:49.270 --> 13:50.240 traffic coming in 330 13:50.240 --> 13:54.830 from the 1020 zero subnet traffic coming in on the inside zone being routed out 331 13:54.830 --> 13:56.240 of the outside zone. 332 13:56.240 --> 14:00.320 It's being allowed. There's the name temp for vendor. It's proxy based. And WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 332 13:56.240 --> 14:00.320 It's being allowed. There's the name temp for vendor. It's proxy based. And 333 14:00.320 --> 14:01.120 here are the security 334 14:01.120 --> 14:05.740 profiles which are effectively monitoring everything, which I also imagine 335 14:05.740 --> 14:07.520 based on the results is not 336 14:07.520 --> 14:12.140 blocking on anything. So having the correct security profiles in place here or 337 14:12.140 --> 14:13.520 possibly just even 338 14:13.520 --> 14:18.120 disabling this policy altogether by right clicking on it and going to set 339 14:18.120 --> 14:19.280 status and clicking on 340 14:19.280 --> 14:23.180 disabled that should prevent assuming this next policy here has the correct 341 14:23.180 --> 14:24.320 security in place 342 14:24.320 --> 14:27.710 that should start preventing a lot of the attacks that we just saw. So if we 343 14:27.710 --> 14:28.400 open this one up, 344 14:28.400 --> 14:31.900 this is allowing seven at 20 and 30. And if we scroll down, it looks like we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 344 14:28.400 --> 14:31.900 this is allowing seven at 20 and 30. And if we scroll down, it looks like we 345 14:31.900 --> 14:32.640 have some better 346 14:32.640 --> 14:37.010 security profiles in place. And that temporary one, unfortunately, it was being 347 14:37.010 --> 14:37.760 matched, which 348 14:37.760 --> 14:40.910 also means that new traffic coming through with that temporary one from the 349 14:40.910 --> 14:42.080 vendor wouldn't require 350 14:42.080 --> 14:46.770 authentication. Now fortunately, our 80 user to initially went through and they 351 14:46.770 --> 14:47.840 got authenticated. 352 14:47.840 --> 14:51.690 That's why we know it's 80 user to not just an IP address, but new devices that 353 14:51.690 --> 14:52.480 came up where 354 14:52.480 --> 14:57.200 the 40 gate did not yet know exactly who the user was behind that IP address. 355 14:57.200 --> 14:58.000 If there's no policy 356 14:58.000 --> 15:02.450 in place like this temp for vendor with no group authentication required, those WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 356 14:58.000 --> 15:02.450 in place like this temp for vendor with no group authentication required, those 357 15:02.450 --> 15:03.360 IP addresses would 358 15:03.360 --> 15:07.020 go through without a username required to be associated with them. So in this 359 15:07.020 --> 15:08.080 case, it was a 360 15:08.080 --> 15:11.800 temporary policy that was put in place that was very, very lax. And that was 361 15:11.800 --> 15:12.880 causing our security 362 15:12.880 --> 15:15.800 issues by allowing traffic through the firewall that shouldn't have been 363 15:15.800 --> 15:16.880 allowed. So if we go back 364 15:16.880 --> 15:21.170 to the 40 gate and we go to our instant here, what we can do is we can add a 365 15:21.170 --> 15:22.720 comment. So here in 366 15:22.720 --> 15:27.980 the comments, we'll say temporary, on off, sec policy rule, emergency change 367 15:27.980 --> 15:29.280 control used to 368 15:29.280 --> 15:32.700 disable it. And also, of course, you'd want to go through whatever change WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 368 15:29.280 --> 15:32.700 disable it. And also, of course, you'd want to go through whatever change 369 15:32.700 --> 15:34.320 control is required 370 15:34.320 --> 15:37.900 before you just go in and make a change on a production system. So I'll click 371 15:37.900 --> 15:38.560 on post here. 372 15:38.560 --> 15:42.640 So all the other admins can see that also go back to instance, then right here, 373 15:42.640 --> 15:46.050 I'll right click and we can go ahead and edit it. And I changed the status from 374 15:46.050 --> 15:47.120 analysis to 375 15:47.120 --> 15:50.300 closed. And if I want to update the description here also to indicate there was 376 15:50.300 --> 15:51.440 a temporary policy, 377 15:51.440 --> 15:54.440 I can put it here as well, we could also update the name. So I'll say the 378 15:54.440 --> 15:55.440 temporary policy was 379 15:55.440 --> 15:58.720 too lenient. And then down here in the description, we could update the 380 15:58.720 --> 15:59.840 description. And it's usually 381 15:59.840 --> 16:03.370 a good idea to just add information instead of replace it. And that way, there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 381 15:59.840 --> 16:03.370 a good idea to just add information instead of replace it. And that way, there 382 16:03.370 --> 16:04.000 's a history 383 16:04.000 --> 16:08.340 regarding what exactly happened. So click on okay. And that incident is now 384 16:08.340 --> 16:09.440 closed. And in your 385 16:09.440 --> 16:13.000 organization, there's gonna be policies and procedures regarding what to do 386 16:13.000 --> 16:13.360 when certain 387 16:13.360 --> 16:17.640 events are found, and the process for dealing with assigning and following up 388 16:17.640 --> 16:18.320 with incidents.