1 1 00:00:00,450 --> 00:00:02,640 Detection and Analysis. 2 2 00:00:02,640 --> 00:00:03,570 In this lesson, 3 3 00:00:03,570 --> 00:00:06,630 we are going to talk more about detection and analysis. 4 4 00:00:06,630 --> 00:00:07,770 Detection and analysis 5 5 00:00:07,770 --> 00:00:10,110 is one of our phases of incident response, 6 6 00:00:10,110 --> 00:00:11,010 and in this phase, 7 7 00:00:11,010 --> 00:00:13,620 we're going to determine if an incident has taken place, 8 8 00:00:13,620 --> 00:00:14,700 we're going to triage it, 9 9 00:00:14,700 --> 00:00:17,340 which means we're going to categorize it and prioritize it, 10 10 00:00:17,340 --> 00:00:20,010 and then we're going to notify relevant stakeholders. 11 11 00:00:20,010 --> 00:00:22,470 Now most organizations are going to use a SIEM 12 12 00:00:22,470 --> 00:00:25,020 as their central repository of data for use 13 13 00:00:25,020 --> 00:00:27,150 in the detection and analysis phase. 14 14 00:00:27,150 --> 00:00:29,400 And so, if you have a properly tuned SIEM, 15 15 00:00:29,400 --> 00:00:32,130 you're going to be able to generate a lot of different alerts. 16 16 00:00:32,130 --> 00:00:33,570 When those alerts are gotten, 17 17 00:00:33,570 --> 00:00:36,600 you then have to go through and analyze those alerts. 18 18 00:00:36,600 --> 00:00:39,480 For example, here in the screen, you can see a SIEM 19 19 00:00:39,480 --> 00:00:42,120 that is a large number of real-time events and alerts 20 20 00:00:42,120 --> 00:00:45,420 and all of these need to be manually assessed and triaged. 21 21 00:00:45,420 --> 00:00:46,440 When we triage them, 22 22 00:00:46,440 --> 00:00:48,360 we're looking at them based on their priority, 23 23 00:00:48,360 --> 00:00:49,350 their category, 24 24 00:00:49,350 --> 00:00:52,950 and possible investigation, if they're severe enough. 25 25 00:00:52,950 --> 00:00:54,720 Now as we go through and we do this, 26 26 00:00:54,720 --> 00:00:57,660 we have to use our known indicators of compromise. 27 27 00:00:57,660 --> 00:01:00,420 If we have a known indicator of compromise, or IOC, 28 28 00:01:00,420 --> 00:01:03,060 we can use these to trigger an alert automatically for us, 29 29 00:01:03,060 --> 00:01:05,190 and if it's a known IOC, 30 30 00:01:05,190 --> 00:01:07,560 we can then use that to automatically categorize 31 31 00:01:07,560 --> 00:01:10,170 and prioritize that particular event 32 32 00:01:10,170 --> 00:01:12,390 because, for instance, if I have a known IOC 33 33 00:01:12,390 --> 00:01:15,180 for a nation state actor, that's pretty serious. 34 34 00:01:15,180 --> 00:01:18,090 It might automatically flag that, categorize it 35 35 00:01:18,090 --> 00:01:19,620 and put it as a high priority 36 36 00:01:19,620 --> 00:01:21,690 for us to immediately act upon. 37 37 00:01:21,690 --> 00:01:24,060 Now when you're dealing with indicators of compromise, 38 38 00:01:24,060 --> 00:01:25,890 these don't have to just be technical. 39 39 00:01:25,890 --> 00:01:28,560 They could be both technical and non-technical 40 40 00:01:28,560 --> 00:01:31,170 and there's lots of different IOCs that you can use 41 41 00:01:31,170 --> 00:01:33,420 as you're going through your detection phases. 42 42 00:01:33,420 --> 00:01:36,210 For example, if I'm using anti-malware software, 43 43 00:01:36,210 --> 00:01:37,710 this can actually generate an alert 44 44 00:01:37,710 --> 00:01:39,780 based on a signature definition being matched, 45 45 00:01:39,780 --> 00:01:43,230 showing us there's a virus or malware on that given system. 46 46 00:01:43,230 --> 00:01:45,600 If we're using a network intrusion detection system 47 47 00:01:45,600 --> 00:01:47,610 or a network intrusion prevention system, 48 48 00:01:47,610 --> 00:01:49,740 we can generate alerts automatically 49 49 00:01:49,740 --> 00:01:52,080 based on automated port scans that are being detected 50 50 00:01:52,080 --> 00:01:55,020 or other such things that match our signatures. 51 51 00:01:55,020 --> 00:01:57,510 If we have a host based intrusion detection system 52 52 00:01:57,510 --> 00:01:59,730 or a host based intrusion prevention system, 53 53 00:01:59,730 --> 00:02:02,670 we can generate alerts based on a cryptographic hash 54 54 00:02:02,670 --> 00:02:04,830 for important files that are being changed. 55 55 00:02:04,830 --> 00:02:07,800 For example, if I'm looking at explorer.exe, 56 56 00:02:07,800 --> 00:02:09,480 I know what that file should look like, 57 57 00:02:09,480 --> 00:02:10,920 and if its hash changes, 58 58 00:02:10,920 --> 00:02:13,170 that means the integrity has been compromised 59 59 00:02:13,170 --> 00:02:15,150 and that should generate an alert. 60 60 00:02:15,150 --> 00:02:16,920 If I'm looking through the system logs, 61 61 00:02:16,920 --> 00:02:19,290 I can be looking in the Windows event logs for example 62 62 00:02:19,290 --> 00:02:21,480 for any login on events with new credentials 63 63 00:02:21,480 --> 00:02:23,760 or any multiple failed login attempts. 64 64 00:02:23,760 --> 00:02:25,830 All those could be indicators of compromise 65 65 00:02:25,830 --> 00:02:27,870 that I would want to generate an alert for. 66 66 00:02:27,870 --> 00:02:29,790 If I'm looking through my network device logs, 67 67 00:02:29,790 --> 00:02:31,710 I could be looking at firewall log entries 68 68 00:02:31,710 --> 00:02:33,030 for any dropped connections 69 69 00:02:33,030 --> 00:02:35,040 that were going towards a blocked port. 70 70 00:02:35,040 --> 00:02:35,873 If I'm looking 71 71 00:02:35,873 --> 00:02:38,700 for a security information event management system logs, 72 72 00:02:38,700 --> 00:02:40,650 I have lots of different alerts that are generated 73 73 00:02:40,650 --> 00:02:42,630 based on different anomalous behavior, 74 74 00:02:42,630 --> 00:02:44,700 and all of those could be tied to different signatures, 75 75 00:02:44,700 --> 00:02:47,280 and possibly, be indicators of compromise. 76 76 00:02:47,280 --> 00:02:49,260 If I'm looking at flow control devices, 77 77 00:02:49,260 --> 00:02:50,580 I might look at the amount of flow 78 78 00:02:50,580 --> 00:02:52,170 that's being sent over the network. 79 79 00:02:52,170 --> 00:02:54,540 If there's more flow going outbound of the network, 80 80 00:02:54,540 --> 00:02:57,270 that could indicate a data exfiltration in progress 81 81 00:02:57,270 --> 00:02:59,280 and that could be an indicator of compromise. 82 82 00:02:59,280 --> 00:03:01,740 If there's a lot of information coming into my network, 83 83 00:03:01,740 --> 00:03:04,440 that might be a denial of service attempt. 84 84 00:03:04,440 --> 00:03:05,970 If I look at internal personnel, 85 85 00:03:05,970 --> 00:03:08,250 this is one of my more non-technical indicators 86 86 00:03:08,250 --> 00:03:09,270 of compromise. 87 87 00:03:09,270 --> 00:03:12,030 If I start looking at what employees say or do, 88 88 00:03:12,030 --> 00:03:13,920 they might have witnessed a breach, for instance. 89 89 00:03:13,920 --> 00:03:16,920 That would be a non-technical indicator of compromise. 90 90 00:03:16,920 --> 00:03:19,140 If I look at people outside the organization, 91 91 00:03:19,140 --> 00:03:20,670 sometimes I have a third-party 92 92 00:03:20,670 --> 00:03:23,430 who tells us they've seen some sort of our information 93 93 00:03:23,430 --> 00:03:24,600 that's out on the web, 94 94 00:03:24,600 --> 00:03:25,560 and if that's the case, 95 95 00:03:25,560 --> 00:03:27,840 we may have been victims of a data breach. 96 96 00:03:27,840 --> 00:03:30,420 For example, if there is a big massive data breach 97 97 00:03:30,420 --> 00:03:32,400 and some security researcher found it, 98 98 00:03:32,400 --> 00:03:33,390 they could come and tell us 99 99 00:03:33,390 --> 00:03:36,060 and they are somebody who's outside our organization. 100 100 00:03:36,060 --> 00:03:38,310 And finally, we have cyber threat intelligence 101 101 00:03:38,310 --> 00:03:39,630 as one of our sources. 102 102 00:03:39,630 --> 00:03:42,570 These are third-party research and vulnerability databases. 103 103 00:03:42,570 --> 00:03:45,780 They gather information about the state of the industry 104 104 00:03:45,780 --> 00:03:48,420 and they may find information about our systems as well 105 105 00:03:48,420 --> 00:03:49,800 and be able to tell us about that 106 106 00:03:49,800 --> 00:03:52,020 or that might be a good source of information 107 107 00:03:52,020 --> 00:03:53,670 to develop our own IOCs 108 108 00:03:53,670 --> 00:03:56,460 to look for those things inside of our SIEMs. 109 109 00:03:56,460 --> 00:03:59,280 Now once the indicators are compromised or detected, 110 110 00:03:59,280 --> 00:04:02,250 our incident handlers need to work quickly and effectively 111 111 00:04:02,250 --> 00:04:05,460 to classify the indicators into one of three categories, 112 112 00:04:05,460 --> 00:04:08,190 benign, suspicious or malicious. 113 113 00:04:08,190 --> 00:04:09,420 If something is benign, 114 114 00:04:09,420 --> 00:04:11,940 that essentially means we have a false positive. 115 115 00:04:11,940 --> 00:04:13,650 The analyst looks at that indicator, 116 116 00:04:13,650 --> 00:04:15,120 they weigh the evidence they see 117 117 00:04:15,120 --> 00:04:18,060 and they determine that it's nothing to worry about. 118 118 00:04:18,060 --> 00:04:19,590 Now when the incident handler determines 119 119 00:04:19,590 --> 00:04:21,360 that something was indeed an incident, 120 120 00:04:21,360 --> 00:04:24,900 it's called malicious and instant response might begin. 121 121 00:04:24,900 --> 00:04:26,910 Now if the incident handler is unsure, 122 122 00:04:26,910 --> 00:04:29,100 they could classify this as suspicious 123 123 00:04:29,100 --> 00:04:31,110 and they can pass it up for further analysis 124 124 00:04:31,110 --> 00:04:34,200 by a more senior analyst if they need to. 125 125 00:04:34,200 --> 00:04:35,460 Now another thing we can use 126 126 00:04:35,460 --> 00:04:37,650 as we're going through all these indicators of compromise 127 127 00:04:37,650 --> 00:04:39,090 is automation. 128 128 00:04:39,090 --> 00:04:42,180 This process is essentially a triage function after all, 129 129 00:04:42,180 --> 00:04:43,350 and with today's technology, 130 130 00:04:43,350 --> 00:04:45,900 a lot of this triage is being handled automatically 131 131 00:04:45,900 --> 00:04:47,040 through automation, 132 132 00:04:47,040 --> 00:04:48,330 but there is still a lot of work 133 133 00:04:48,330 --> 00:04:51,240 that must be done by a real living, breathing human 134 134 00:04:51,240 --> 00:04:53,130 who can make the right decisions. 135 135 00:04:53,130 --> 00:04:55,140 Now after all, automation can help us 136 136 00:04:55,140 --> 00:04:57,420 but it can't eliminate this important function 137 137 00:04:57,420 --> 00:04:58,530 of incident handling 138 138 00:04:58,530 --> 00:05:00,840 by using a living, breathing, thinking human 139 139 00:05:00,840 --> 00:05:02,430 to do that work. 140 140 00:05:02,430 --> 00:05:03,990 So you may be wondering, 141 141 00:05:03,990 --> 00:05:06,780 how does an incident handler make the decision to classify 142 142 00:05:06,780 --> 00:05:09,960 a certain indicator into one of those three categories? 143 143 00:05:09,960 --> 00:05:12,480 Well, they begin by having a good profile 144 144 00:05:12,480 --> 00:05:14,250 of a network or a system. 145 145 00:05:14,250 --> 00:05:17,190 As I said before, if you know what normal looks like, 146 146 00:05:17,190 --> 00:05:19,200 then it's easier to know if something is abnormal 147 147 00:05:19,200 --> 00:05:20,340 when you see it. 148 148 00:05:20,340 --> 00:05:22,290 Using file integrity hashes, 149 149 00:05:22,290 --> 00:05:24,300 understanding your network's baseline activity 150 150 00:05:24,300 --> 00:05:25,740 and knowing what the average memory 151 151 00:05:25,740 --> 00:05:28,410 and system processing resources used by machine are 152 152 00:05:28,410 --> 00:05:30,360 can go a long way in understanding 153 153 00:05:30,360 --> 00:05:33,660 if something is within limits or if it's abnormal. 154 154 00:05:33,660 --> 00:05:35,610 Now remember, no one person 155 155 00:05:35,610 --> 00:05:37,590 can know everything about a system, 156 156 00:05:37,590 --> 00:05:40,410 but an incident handler should be able to know who to call 157 157 00:05:40,410 --> 00:05:43,290 with the right expertise for a certain system. 158 158 00:05:43,290 --> 00:05:45,900 For example, if you're working as an incident handler 159 159 00:05:45,900 --> 00:05:48,300 and you're trying to determine if a particular SQL statement 160 160 00:05:48,300 --> 00:05:50,820 was malicious, suspicious or benign, 161 161 00:05:50,820 --> 00:05:53,580 you might request the assistance of a database administrator 162 162 00:05:53,580 --> 00:05:55,800 who has more specialized knowledge in this area 163 163 00:05:55,800 --> 00:05:58,200 and can help you classify it correctly. 164 164 00:05:58,200 --> 00:06:00,000 Another thing that incident handlers use 165 165 00:06:00,000 --> 00:06:01,620 is event correlation. 166 166 00:06:01,620 --> 00:06:04,230 By correlating an event across multiple systems, 167 167 00:06:04,230 --> 00:06:06,870 services, applications or networks, 168 168 00:06:06,870 --> 00:06:08,880 the incident handler can look at the different logs 169 169 00:06:08,880 --> 00:06:11,250 and determine the exact effects that occurred. 170 170 00:06:11,250 --> 00:06:14,040 For example, maybe a host log show they attempted to connect 171 171 00:06:14,040 --> 00:06:17,310 to a database server to conduct an SQL injection. 172 172 00:06:17,310 --> 00:06:18,660 Well, if you correlate that event 173 173 00:06:18,660 --> 00:06:20,460 with the logs of the database server, 174 174 00:06:20,460 --> 00:06:22,470 you could see if the attack was successful. 175 175 00:06:22,470 --> 00:06:25,260 If it wasn't, then you may just recommend disconnecting 176 176 00:06:25,260 --> 00:06:27,930 and re-imaging the host which tried to do this attack. 177 177 00:06:27,930 --> 00:06:29,820 But if the attack was successful, 178 178 00:06:29,820 --> 00:06:32,160 you may now be launching a full instant response 179 179 00:06:32,160 --> 00:06:34,410 starting with that database server. 180 180 00:06:34,410 --> 00:06:35,700 We're going to dig deeper into this 181 181 00:06:35,700 --> 00:06:37,020 as we cover the later phases 182 182 00:06:37,020 --> 00:06:38,670 of the incident response lifecycle 183 183 00:06:38,670 --> 00:06:40,420 in the next section of this course.