I think this is module two of the
Security Operation Center introduction to case an incident management,
we're going to get right into it. I do recommend highly that if you have not seen module one of this program that you go and actually check that out before continuing module two.
There's a lot of stuff in module one that we're gonna refer to in this module. So it will just help you out
anyway, for those of you that have done Mantra one and are now starting out Montreuil, too, and you're ready to go. Let's not hold things up any longer and let's get started.
So let's talk about the birth of an issue. We talk about issues and incidents in the last module on the differences between them. So we know now that most things we deal with are going to be issues, and we really want that to be the case.
But there's basically four ways that we're going to learn about an issue. One is gonna be through some form of an automated system like a sim and I. D. S or some other security management platform.
The second way is going to be a user, right? They're going to either call us or send us an email or a tax. Or some way we're gonna have an encounter with an end user that's going tiu form of a similar or alarm or some type of security risk. And then the third will be a co worker difference with your co worker
for user's their co workers, typically somebody who works in the I T security team with us
and they may bring to our attention activities that would constitute it being classified as an issue
and in a case being opened and then lastly, we may, we may see something that we believe warrants us raising an alarm on alert and creating an issue. So those air basically the four ways now these four ways can give us very vital cruise clinical, cruel clues into
what is happening, and we can use that for triage
and we'll talk about that in the moment.
But we can also
take inappropriate action
based on the information that we're seeing in these four different channels reporting channels, and so it's really important that as we're looking at information, regardless of how it's gone happening or coming inbound to us that we step back and kind of think about our emotional context, right? If you see something
in an automated system that says there's a brute force attack underway, there's a command and control process has been established. Reverse shell has been established. Malware has been deployed.
You may get all ramped up, and we need you to stay calm, Right? We talked about being the ability to stay calm and have attention to detail and lead some of the basic skills in the first module. Now you. Hopefully you start understanding why that's important. You could get a phone call from a user who's panicked and freaking out and saying they're certain
that they've clicked on a link and that there machine is under attack
or their machines being encrypted. You need to be able to perform triage very quickly, But to do that, there's a few things you need to really think about. Right and remember, slow is smooth, smooth stats. You want to be as fast as you can be accurate on and not go quicker. That kind of
you get all ramped up and you start becoming part of the problem rather than part of the solution.
So to do this, we need to gather facts. We talked about these fax in the last module, but we're gonna reiterate him here, right? We're basically looking to see what behaviors being visitor, where we actually seeing. So we see something on the screen that's telling this is a brute force attack or whatever. It may be your user on the phone or a panicky email that we get from someone.
What is the behavior? We need to go back to the source and start thinking about
what's the behavior I'm seeing? It doesn't really support the information that is being reported. Support will be told. When did it start? What's the timeline? We talked about that who and what's involved, what assets And then what was happening prior to this issue. And has anything actually
been done since this issue came about? So these were kind of some of the basic facts that we need to gather
pretty straightforward, and like I said, we covered them in Module one, but this helps us with initial triage. We talked about the rapid triage assessment, a rapid re triage workflow in the last module here I'm trying to get you to start thinking a little deeper, right? We're not just gonna categories the alarm.
We're gonna categorize it using a little bit more advanced skill set at this point. Now we're starting to think about the behavior we're seeing. We're trying to rule out false positives. We're trying to understand if the assets affected
should exhibit that behavior or not. Right. There are cases where sometimes you will see things categorized as alarms, but it's actually appropriate. And I'll explain some of that in some other modules. But I want you to get used to looking at the behavior, thinking about what assets are affected and then making a decision point. And that decision point
is really setting prayer. When we talked about that last Montreuil.
Now I'm gonna show you how that's kind of done.
It's done through triage categories. Basically a triage category just says, How much attention should I give this this issue? This, this case, this problem
and so there are four categories immediate means I give it my immediate attention.
Moderate means that, you know, I give it most of my attention.
Minimal means I give it some of my attention and concerning says, Hey, I'm gonna be able to deal with this on my own schedule. I'm gonna deal with the other things first. This can wait until I've dealt with anything that's minimal. Modern immediate. Now, each one of these has symptoms to kind of help. You know, these aren't exact and you need to adjust these for your organization and
kind of what you're working on.
But immediate basically says, Hey, we're under attack, and that's gonna have a critical priority. And you're going to declare This is an incident. Remember, if you declare something as an incident, it's going to end up requirement incident response team.
So those those are kind of your immediate critical issues, right? Moderate means you're gonna give it a moderate attention. And these air, typically your critical assets, those assets. In the last video we talked about last module, we talked about assets on a scale from 1 to 5 and five being the most critical assets. That this is a level 45 asset
and then minimal is going to be your 123 assets. Now the only thing that overrides that
which isn't here on the slide, is that if you have an attack or something, a situation that's a severity five or severity four, right, Because we also have points for severe areas. We talked about that module one.
Then you need to up the triage category so you could have a asset level one, which is non critical, but a severity five situation. And at that point, you're gonna have to make a judgment call. That says, Oh, yeah, this is a moderate category triage category issue priorities. Hi.
Either way, you're going to start thinking about containment.
But the point here is your deal with your moderate issues before minimal, and then your concerning issues there anything else right that doesn't have a high C barrier is not a high critical asset, And that's gonna be an issue prior to low. And you're just gonna investigate. You're not gonna think about containment or other things. Hopefully just made sense to you. It's not that difficult. Just, you know,
replay this if you get it inside you. If it didn't make sense on the first pass, the idea here is you want to just categorize things in terms of how much time you're going to spend and make sure that then you assign a priority to the issue.
So once we have this triage completed, we know what we're dealing with. 1st 2nd 3rd and fourth. What's gonna be dealt with immediately with the high A critical priority? What's a high priority? Medium and low. We need to come up with a plan. A plan? I don't mean a big project plan. This is something that should take you 1 to 2 minutes, right?
Especially when you're doing your initial triage rapid triage assessment.
You're gonna kind of come up with your first plan. Sometimes it'll be wrong. That's okay. You can evolve and change it as you get more intelligence. But based on what you know, the facts that you've gathered and the level of priority that you've assigned, you're gonna then kind of say, Okay, I need to put up a plan, and that plan is gonna be
based on your bet. Your evidence and evidence comes from the facts together. The investigation you've done
that evidence is gonna point you to some objectives. Objectives is basically what am I going to do next, what I want to accomplish and then reasons for that objective. Now, the reason for that is that your ability to state reasons you're going to need to explain it to someone else. Remember,
cybersecurity is not really something you do in a vacuum. There will be other people involved in there. Then you need to understand why you're doing what you're doing or why you're doing
why you're asking what you're asking, why you need what you need. So be able to state your reasons and then be able to outline the steps that are gonna be taken in order for you to achieve your objectives. Right. So, evidence and investigation, Dr Objectives, objectives should be backed up by reasons and reasons
should lead you to clear some next steps.
Hopefully, that makes sense. And again, this is something you do very quickly, minute or 2 to 3. This is not a two week planning process is very quick. Hence why you need to be able to lead and have an analytical mind and do research. Speaking of research, let's talk about some of the tools that you can use
is part of your investigation again, This is gonna be done rather quickly,
especially if you're dealing with a high priority
or medium priority
issue. Right? So you're going to use the alarm data if you have it right? Things like raw log data network traffic analysis,
One of the things that you could do that's extremely helpful is taking any of the information you have, like three i p. Address the port number, the malware name, whatever it may be that you're looking at and put that into Google and being and search,
you'll be surprised how many times you'll get insights into what you're actually seeing. The types of situations that you're looking at by actually just doing a search. So it's a really powerful to just go out and say, Has anybody else seen this I p address? Is anybody else seeing this behavior before anybody? What's this man? We're actually do? What's this Command and controls
What is this? Okay, use Google on day,
and then there's other things you can use like and map. One ability assesses rope tax, and that craft showed an certain C C I C groups. If you don't know what those things are, I implore you really need to go learn what they are and how to use them. It's beyond the scope of this video, but you need to understand that a variety of tools,
others that may not even be on listless. We certainly use others in our work,
but you need to have a tool kit of things you're going to use. But regardless of that tool kit, I want you to understand that at this stage you're not performing. Forensics security analyst typically doesn't do. Forensics is handed off to a forensics team that will do that after the attack has been contained. But in this case, you're really just doing an investigation
to try to prove that whatever issue you're seeing is either a false positive
or is an incident. Okay, so that's what we're really doing here. At the end of the day, we're gathering. All these facts were performing triage or developing a plan. We're doing investigations
all for the simple fact of trying to determine
if what we're looking at. If the issue we're dealing with is a false positive meaning, Hey, that issue really isn't an issue or it's an incident meeting. We have an attack, and we gotta escalate this and an instant response team has to be called out. Okay? Makes sense. It is an issue. Obviously. Want to document it? You wanna talk about the resolution? And how
have you You
You closed it out.
But you're actually like I said on Lee. One question you're trying to answer Is this an incident or not? You want to do that as quickly and accurately as possible.
Now all your cases air going to have notes. The notes need to be concise, clear, accurately. Time We got to keep him up. You don't want things to fall through the cracks, and many times you may have to hand your notes off to someone else. So that's why they have to be legible. You want to help them so that you should pretend
that when you're managing your notes that you're doing this as if you had to read them blindly. Meaning you were just dropped into this case and you didn't know anything about it, and all you could do is read the notes. If you can write it that way, it'll help everybody else who has to actually use your notes to do their job
so you could use things like screenshots links attachments.
That's always great to happen. Your notes. You should have in your notes, the progress and the results of your investigation. What you've done, where you're going, who you spoke with, Why did you speak to him and when and what did you learn and then what you did when, why and what you learned. So
basically, the notes just need to be kind of a chronology. A timeline of everything you've done
and supported by screenshots results of your findings of your tools, whatever you can provide to help keep the cases, the case notes. And the collateral is Richard's possible so that others can determine what we were doing without having to come speak to you.
Now. One thing that you got to keep in mind, and this is why working a case is so important and bring it to resolution as quickly as possible is that until the case is closed, it's a risk. If we're trying to determine that something is a false positive or an incident isn't an attack or not. Well, then it
anything else is a risk to the organization until we resolve it.
That's really important to understand. A lot of security analysts failed to realize that you are kind of on the front lines of risk management. So if it's not an attack, you really need to think about, Okay, so then what are we doing about this? Because obviously something is coming up. There's some type of suspicious behavior that's occurring
not necessarily by 1/3 party actor,
but something in the system of configuration issue infrastructure, something that needs to be addressed and that risk needs to be shut down.
So in the next things to keep in mind about this is you need to understand how an issue originates and why it's important. Understand that
that you need to focus on the fax from the very beginning of the case and not let your emotions get in the way. That initial triage or rapid triana should lead to case priority, and we talked about how this priorities a set.
You should understand the categories of issues from a triage perspective.
You need to think about what investigative tools will help you to continue to triage and perform your investigation, and to develop a plan
and your notes or your reputation. You got great notes. People are going to really love working with you Be about lousy, crappy notes. You're gonna have a really bad reputation in terms of being an analyst
in the next module. Module three, we're gonna really talk about incident management planning.
without any further ado, I'll see you in Montreuil three.