Instructor: Security Data Collection. 2 2
In this lesson, we're going to talk about all that data 3 3
that you're collecting inside your SIEM. 4 4
Now, a lot of this can become intelligence, 5 5
but intelligence loses its value over time. 6 6
So when you're dealing with this, you need to make sure 7 7
that you're capturing and analyzing the information 8 8
in real time or as close to real time as possible. 9 9
The sooner you can find out 10 10
about a bad guy intruding into your network, 11 11
the quicker you can get them out, right? 12 12
And so intelligence needs to be current and relevant. 13 13
Now, as we talked about the intelligence process earlier, 14 14
we talked about the fact that we have five different stages. 15 15
We start out with Requirements, 16 16
we move into Collection & Processing, 17 17
then Analysis, then Dissemination, and then Feedback. 18 18
Here on the screen, 19 19
you can see the fact that I've highlighted 20 20
Collection & Processing, Analysis, and Dissemination. 21 21
The reason for that 22 22
is this is what we're focusing on right now. 23 23
When we're talking about a SIEM, 24 24
this is where a SIEM operates. 25 25
It helps you collect the information. 26 26
It helps you process that information and normalize it. 27 27
It helps you analyze that information. 28 28
And then you can even run reports 29 29
or send information out to others as part of dissemination. 30 30
And so a SIEM really does fit 31 31
into these three phases of the intelligence lifecycle. 32 32
Now, one of the things your SIEMs can do for you is, 33 33
you can actually configure them 34 34
to automate much of the security intelligence lifecycle, 35 35
especially when it comes 36 36
to gathering and collecting that data. 37 37
I don't want to have to go out to all these different systems 38 38
across my network and grab their logs 39 39
and start analyzing them, but using a SIEM, 40 40
I can make all those systems feed me that data, 41 41
and it can go into that central repository 42 42
that we can later analyze. 43 43
Now, one of the big things you have to consider 44 44
when you're configuring your SIEMs is, 45 45
what do you want to collect? 46 46
Because some people have a tendency 47 47
to just try to collect everything, 48 48
they dump all the data into the system. 49 49
But the problem with that 50 50
is it can end up overloading your system. 51 51
All this data has to be stored, 52 52
it has to be processed, and it has to be normalized. 53 53
And if I'm sending it in with millions of endpoints, 54 54
that can really quickly overwhelm my systems. 55 55
So instead, you should spend some time upfront 56 56
doing your planning based on the requirements 57 57
and determining exactly what you need to collect. 58 58
Remember, while your SIEM could collect all the logs 59 59
across all of your systems, this isn't a good idea. 60 60
Instead, you need to configure your SIEM to focus 61 61
on the events related to the things that you need to know. 62 62
Not everything is important, 63 63
so you need to identify what is and collect on that. 64 64
Now, one of the biggest features of a SIEM 65 65
is the ability to process data 66 66
and then look for different trends and alert on those. 67 67
Now, just like all alerting systems, 68 68
it does suffer from the problems 69 69
of false positives and false negatives. 70 70
When we talk about the problem with false negatives, 71 71
this is when security administrators are exposed 72 72
to a threat without being aware of them 73 73
because your system falsely categorized it as negative 74 74
instead of alerting that there was something bad there. 75 75
Now, on the other hand, we also have issues 76 76
when we have false positives. 77 77
If our system starts having a lot of positives 78 78
but they aren't real, 79 79
we're going to overwhelm our analysis and response resources 80 80
because some person has to look at that 81 81
and analyze it and determine, 82 82
was there really an event that happened? 83 83
So we want to make sure we are tuning our systems 84 84
to make sure that we don't have 85 85
a lot of false negatives or false positives. 86 86
To help us do that, we develop what's called a use case. 87 87
By developing use cases, 88 88
we can mitigate the risk of these false indicators. 89 89
Now, when I talk about a use case, 90 90
this is a specific condition that should be reported, 91 91
such as a suspicious log on, 92 92
or a process executing from a temporary directory, 93 93
or something like that. 94 94
Essentially, we want to think about what is this bad thing 95 95
that we want to collect on? 96 96
And then we develop this use case around it. 97 97
Based on that use case, 98 98
we can then configure our SIEM to collect the relevant data. 99 99
Now, what we want to do here is essentially 100 100
develop a template for each of these use cases. 101 101
And as we do that, 102 102
they're going to contain a couple of different things. 103 103
We're going to contain things like the data sources 104 104
with the indicators that we want to collect on. 105 105
It's going to contain the query strings 106 106
that we're going to use to correlate those different indicators 107 107
across different systems. 108 108
We want to make sure we have the actions 109 109
that are going to occur when the event is triggered. 110 110
Essentially, what are we going to do to respond 111 111
when we see this bad thing happen? 112 112
And then by having those three things 113 113
as part of our use case template, 114 114
that tells us that this set 115 115
is what is known as this bad thing. 116 116
And so eventually, we would write a rule 117 117
or a query to be able to identify 118 118
all of those things across our systems. 119 119
In addition to providing those three things in the use case, 120 120
we also need to make sure that each use case 121 121
captures the 5Ws when we're dealing with an event. 122 122
This would be things like when, when did this event start? 123 123
And when did this event end, if it's already ended? 124 124
We also want to figure out who, 125 125
who was involved in this event, which user or which system? 126 126
And then we want to figure out what, what happened 127 127
and what is the specific details of this event? 128 128
Essentially, did somebody try to run a program 129 129
and there was malware in it? 130 130
Did somebody try to attack our network from the outside? 131 131
What happened? We need those specific details. 132 132
Then we go and figure out where, where did the event happen? 133 133
Was it on a host, a server, a file system, the network? 134 134
Where is this issue? 135 135
And then we want to also figure out where, 136 136
where did the event originate from? 137 137
Did it come from the inside 'cause it was an insider threat? 138 138
Did it come from the outside 139 139
because there was an external hacker? 140 140
This is an important piece of information 141 141
for us to know too. 142 142
So by knowing those 5Ws, 143 143
we're going to be able to better understand 144 144
what happened and then how we can respond to it.