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