Instructor: SIEM dashboards. 2 2
Now, in the previous sections, 3 3
I showed you a couple of different SIEM solutions 4 4
and the related dashboards. 5 5
In this section, we're going to dive a little deeper into SIEMs 6 6
and learn how we can analyze and query logs 7 7
and SIEM data within them. 8 8
In this particular lesson, 9 9
we're going to start with another look 10 10
at those SIEM dashboards. 11 11
Now, cybersecurity analysts are usually going to work 12 12
in a SOC or a CSIRT 13 13
and they're going to perform a lot of different functions. 14 14
These functions include things 15 15
like performing triage on alerts, 16 16
being able to escalate true positives for instant response 17 17
and dismissing away the false positives. 18 18
They're also going to review security data sources 19 19
and check that log collection 20 20
and information feeds are functioning as they're supposed to 21 21
to make sure all that data is getting into the SIEM. 22 22
Additionally, 23 23
they're going to review cyber threat intelligence. 24 24
This way they can identify what the priorities are 25 25
or the potential impacts 26 26
from different events that are happening 27 27
across their network and across their company. 28 28
Another thing they're going to work on 29 29
is performing vulnerability scanning 30 30
and vulnerability management. 31 31
This way they can understand their vulnerability posture 32 32
within the organization and what threats 33 33
outside the organization may try to attack them. 34 34
Also, they're going to identify opportunities 35 35
for threat hunting. 36 36
As they're going through their SIEM, 37 37
they're going to be able to start seeing 38 38
different opportunities for threat hunting 39 39
based on different cyber threat intelligence 40 40
and overall alerts and incidence status 41 41
that they're going to be identifying. 42 42
As they start seeing what alerts are being triggered, 43 43
they can also see what patterns there are. 44 44
And based on that, they can find opportunities 45 45
for going after those patterns by using threat hunting. 46 46
Now, one of the big things you have to remember 47 47
with security incidents is that they are identified 48 48
and interpreted differently 49 49
based on the overall threat level. 50 50
Every organization is different 51 51
and the overall threat level is different 52 52
based on your organization. 53 53
For example, if you work in the Department of Defense 54 54
and you work for the US military, 55 55
you might have top secret information. 56 56
That is a much bigger area 57 57
that has a bigger threat base going towards it 58 58
than say, my small company. 59 59
Now, alternatively, 60 60
my small company may have some other threats 61 61
that we are vulnerable to 62 62
that they're not vulnerable to, 63 63
and so depending on these type of things 64 64
are going to change your overall threat level, 65 65
and that is going to have to be identified 66 66
and interpreted based on the events you're seeing 67 67
and the threats to your organization. 68 68
Now, another great example of this 69 69
is the open SSL vulnerability 70 70
that happened a couple years ago. 71 71
This was known as Heartbleed. 72 72
Now, this was a zero day vulnerability 73 73
that affected everybody's websites if they used open SSL 74 74
to do their encryption. 75 75
Now, if you're an e-commerce site, 76 76
you're going to have a really high threat level with that 77 77
because that means your e-commerce is vulnerable. 78 78
If you were just running a site for your personal amusement, 79 79
well, you might not have been as worried about it 80 80
because you weren't transmitting information back and forth 81 81
to the server over an SSL connection. 82 82
And so based on whether or not you are vulnerable to this, 83 83
whether or not you had a business case that relied on SSL, 84 84
all these things are going to go into your analysis 85 85
and to determine how you're going to interpret 86 86
that security incident and what you should do about it. 87 87
Now, the reason we're talking about all of this 88 88
is because when you build out your dashboard, 89 89
you're going to build it to present information. 90 90
When we talk about a SIEM dashboard, 91 91
this is a console that presents selected information 92 92
in an easily digestible format, such as using visualization. 93 93
Now, when we talk about visualization, 94 94
this is where you can take a widget 95 95
and it can show you different records 96 96
or metrics in a visual format, 97 97
such as a graph or a table. 98 98
For example, on your dashboard, 99 99
you can have all sorts of different kinds of visualizations. 100 100
Here's an example from an elastic stack dashboard. 101 101
Now here you can see it's running on top of security onion 102 102
and we have all sorts of different data 103 103
that is relevant to this particular use case. 104 104
Now, inside here, 105 105
we can see on the bottom right we have a pie chart. 106 106
Inside that pie chart, we can see the relative balance 107 107
of the different classifications, 108 108
without seeing the overall level. 109 109
So for example, I see there's a lot of red there. 110 110
In fact, it's over 75% red, 111 111
and as I look up to the legend, 112 112
I see that is a classification of 2. 113 113
And so that tells me that this is a 2 severity level 114 114
and that's where we're seeing most of our activity. 115 115
Next, we also have things like line graphs 116 116
and line graphs are going to show the level 117 117
over a given time period. 118 118
So here on the top, you can see the counts, 119 119
the number of log counts over time 120 120
as we went throughout the day. 121 121
Now, pie charts and line graphs aren't the only ways 122 122
that we can display information. 123 123
For instance, if I go over to my Splunk dashboard 124 124
I can see many different formats. 125 125
Here, for example, I have a bar graph 126 126
and this is going to compare the levels 127 127
between different classifications. 128 128
You can see here the critical, the high, the medium 129 129
and the low urgency, and the number of counts going across. 130 130
This shows me that my medium emergency is the most common 131 131
that I'm using. 132 132
In addition to that, I might have gauges. 133 133
Now, these gauges can be done in lots of different ways. 134 134
I've seen a lot of them that look like speedometers, 135 135
or in the case of Splunk, 136 136
they like to use these trending graphs 137 137
with the up and down arrows and a big number there. 138 138
These gauges show you the level 139 139
that has defined limits with it. 140 140
So in this case, we have a different thing 141 141
like access notables, endpoint notables, network notables 142 142
identity notables, audit notables, threat notables 143 143
and EUBA notables. 144 144
And all these have a number associated with it 145 145
and a trend over time 146 146
that can be very quickly looked at and observed. 147 147
The final thing you'll see on a lot of dashboards is tables 148 148
and tables are going to give you a lot more information. 149 149
A lot of times these will be the top events 150 150
or the bottom events. 151 151
In this case, you can see these are the top 10 events 152 152
that are being displayed across our entire Splunk system 153 153
which is acting as our SIEM. 154 154
Now, all these dashboards have something in common. 155 155
They display metrics, 156 156
and it's important for you to select the right metrics 157 157
for your dashboard. 158 158
This is critical 159 159
because if you're selecting the wrong information 160 160
you're not really presenting what you want 161 161
and it's not going to be useful to your analyst 162 162
or to your manager or whoever's looking at this dashboard. 163 163
Now, speaking of that, 164 164
one of the big things we have to think about is metrics 165 165
and metrics are also known as key performance indicators 166 166
or KPIs. 167 167
Now, this is a quantifiable measure 168 168
that's used to evaluate the success of an organization, 169 169
an employee or other element 170 170
in meeting objectives for performance. 171 171
Now, this is a generic business definition, 172 172
but when we we start looking at it 173 173
in terms of our systems, we have KPIs too. 174 174
For instance, we have key performance indicators 175 175
for the processor utilization on your server. 176 176
We have it based on the disk space that's being used. 177 177
We may have it on the bandwidth that's being used. 178 178
There are lots of different measures 179 179
and metrics that we can create 180 180
for all these different numbers. 181 181
Now, we're not going to go into a ton of detail 182 182
in the terms of metrics here, 183 183
because as an analyst, 184 184
it's not our job to define those metrics. 185 185
Instead, that's the cybersecurity engineers 186 186
and the cybersecurity architect's job, 187 187
to figure out what we should be measuring. 188 188
That is something that is done at the management level, 189 189
the executive level and at that engineering 190 190
and architecture level. 191 191
Our job as an analyst is to be able 192 192
to understand these numbers and use them in the real world. 193 193
Now, if you're interested to go beyond the CYSA plus exam 194 194
and learn more about measures and metrics, 195 195
I have a course dedicated just to measures and metrics 196 196
which is for my service management students 197 197
because it plays such a big important key in their world. 198 198
But for the rest of this lesson, 199 199
we are going to talk about measures and metrics, 200 200
and it is important for you to understand 201 201
the basics of them. 202 202
Now, when we talk about measures and metrics 203 203
what kind of things should we be measuring? 204 204
Well, we might want to measure the number of vulnerabilities. 205 205
By measuring the number of vulnerabilities, 206 206
we might know what type of service was being affected 207 207
and when these things were discovered 208 208
and remediated over time. 209 209
We also might want to be able to capture the number 210 210
of failed log ons 211 211
because if we have failed log ons 212 212
or unauthorized access attempts, 213 213
that could be an indicator 214 214
of somebody trying to break into our network 215 215
by trying to do password guessing, 216 216
brute force attack or something like that. 217 217
We also might want to capture the number 218 218
of vulnerable systems. 219 219
When you do your vulnerability assessments 220 220
across your network and you scan a host 221 221
and you figure out that it is missing a bunch 222 222
of critical patches, what do you do with that information? 223 223
Well, if you know the number of vulnerable systems, 224 224
we can remediate those 225 225
and figure out which systems are in compliance 226 226
and which ones are out of compliance. 227 227
Then we might want to also capture the number 228 228
of security incidents. 229 229
How many incidents do we have? 230 230
How many are reported in a given period of time, 231 231
maybe in the last week, the last month, or the last year? 232 232
Are we on an upward trend or a downward trend? 233 233
Are things getting better or are they getting worse? 234 234
If you don't capture these numbers, 235 235
you'll never be able to know. 236 236
Then we'll also want to think about the average response time. 237 237
When we identify a security incident, 238 238
how long does it take for us to fix that problem? 239 239
How long does it take for us to re-image that machine? 240 240
How long does it take for us to get that employee back 241 241
to working order and back to a known good state? 242 242
These are all things we want to capture. 243 243
We also might want to capture the average time 244 244
to resolve a ticket. 245 245
Now, this might sound more like a service management issue 246 246
but it does affect the cybersecurity world too 247 247
because if we have a help desk ticket 248 248
and it's not being resolved, 249 249
a lot of times our users are going to find a workaround 250 250
to get their job done. 251 251
For instance, in one organization I was in, 252 252
we had a closed network and an open network. 253 253
The open network connected to the internet. 254 254
The closed network did not. 255 255
And if we wanted to get information from the open network 256 256
to the closed network, 257 257
we had to put in a ticket with the help desk. 258 258
Then a technician would take that information, 259 259
burn it to a cd, move it over to the closed network 260 260
and then allow us to use it. 261 261
Now, if they weren't going to do do that for us, 262 262
and it took them three weeks to do that, 263 263
and I have a presentation to make in three hours, 264 264
that can become a problem. 265 265
And so your average time to resolve tickets 266 266
does affect your security, so keep that in mind. 267 267
Another metric we might look at 268 268
is the number of outstanding issues. 269 269
How many things are sitting in queue 270 270
that haven't been done yet? 271 271
Again, people will find a way to get the work done. 272 272
So if you have an access request 273 273
or you have a port open request or something like that 274 274
and it sits in queue for 6 months or 12 months, 275 275
people will find a way to get their job done 276 276
and that may break your security. 277 277
Another thing we might look at is the number 278 278
of employees who are trained. 279 279
For instance, 280 280
does your organization do annual security training? 281 281
Do they learn about threats? 282 282
Do they learn about vulnerabilities? 283 283
Do they learn about how to have long, strong passwords? 284 284
Do they learn about two-factor authentication? 285 285
Do they learn about phishing attacks and what to look for? 286 286
All of these things are things 287 287
that can be part of your training, 288 288
and if you know the number of employees who are trained, 289 289
you know you have a better security posture, 290 290
so tracking that might be useful as well. 291 291
And finally, we might also want to capture the percentage 292 292
of testing completed. 293 293
When you build a new application, 294 294
does it get put online immediately 295 295
or does it go through testing first? 296 296
Well, if it should go through testing first, 297 297
and if it does, 298 298
you should be tracking that as it's going through. 299 299
This way, you know how many applications you have, 300 300
how may have been tested, and how may have been released. 301 301
All of these are just some metrics 302 302
that you can think about and there can be a lot more. 303 303
This is not an exhaustive list. 304 304
This is just something to get you started 305 305
in thinking about it. 306 306
Now, one of the important things 307 307
is when you're configuring your dashboard, 308 308
you need to display the needed information 309 309
based on that user's role. 310 310
For example, if I'm an analyst, 311 311
do I care as much about the number of employees trained? 312 312
Probably not. 313 313
But if I'm the manager who's in charge 314 314
of training the entire staff 315 315
to minimize our vulnerabilities, I probably do care. 316 316
And so the great thing is with a lot of these dashboards, 317 317
they use widgets to pull that information in from the SIEM. 318 318
Now, by doing that, you can put in different dashboards 319 319
and create different dashboards 320 320
based on the employee who's looking at it. 321 321
In my company, we have several different dashboards 322 322
and based on your position in the company, 323 323
you have access to some, all or none of those 324 324
depending on what you need. 325 325
For instance, I own the company, 326 326
and I have access to every single dashboard. 327 327
That doesn't mean I look at every one 328 328
on a daily basis though. 329 329
For instance, 330 330
I don't look at the dashboard for our ITSM system 331 331
which is where we get all of our support tickets 332 332
in from our students 333 333
and seeing what the resolution times are. 334 334
I look at that once a week 335 335
to make sure my customer service manager is doing her job 336 336
but I don't look at it every single day, 337 337
because I have somebody who does that. 338 338
That's her role. 339 339
Now, on the other hand, 340 340
I do look at our security dashboard every day 341 341
with my tech team because I'm a technical guy 342 342
and I care about that information, and so does my tech team 343 343
and I actually lead up my tech team. 344 344
So in my role as the tech team lead, 345 345
I'm going to be looking at that information. 346 346
So you want to make sure you're building your dashboards 347 347
based on the user's role 348 348
and only bringing the information that they need to see. 349 349
Otherwise, it's useless information 350 350
and it's just distracting to the user.