Lesson 4.3 Incident response. Taxonomy and triage The objectives for this lesson, our understanding, the differences between a sock and assert
and how they complement each other.
We'll discuss work flows and processes for triaging cyber incidents and alerts, and also identifying how to handle multiple simultaneous alerts defining an incident that should look a little bit familiar to you.
Remember that there's an event that something that happens on an information system, but not necessarily malicious, and it doesn't require an investigation.
There's an alert, something potentially malicious, but you need to take some action to, or at least take a look at it. Probably not a full investigation, at least initially, but it could be notification of Mao on a device that you need to go take a look at. Then you've got incident with a small I that's usually
a single host or a couple of hosts, but there's not any business or mission impact. Then you have capital. I incident, and that is true mission or business impacting. It's ah, significant intrusion or incident that is being investigated,
and then you've got a breach, and this is where you have loss of specific regulated information, whether it's P II, HIPPA data, ph I, the health information
or any other type of legal obligations. Maybe it's financial data, etcetera that you might be bound to report if in fact, it is outside of your control or it has been breached to an adversary. A sock and an I R team are not the same thing. We have been talking through this course about
a few of the differences Security Operation Center and a certain Remember when I talked about
the organizational charts and I showed a lot of times those two organizations being separate sometimes is peer organisations and some of the reasons for that, but also how cross training was important and certainly good collaboration and communications is important as well, but they do have two different missions.
Also, just a reminder. If you have
all of your incident handlers also being sock analysts, then as soon as there is an incident and they jump off of watching the screens and go to handling that incident, you may in fact have nobody watching the door and who knows what's going to get in. So you want to make sure you've got a clear delineation between
people watching like a sock
and then people responding to events and alerts. Here's an example of alert triage that you could look at within an organisation, and I'll just run through this flow chart that I put together for you. So at the top, we haven't alert.
And as we look at that alert, remember, from the refresher on the taxonomy and alert is something that
requires some action. But it's not necessarily militias. So
we have on one side, it's a known bad. Now this is an incident. Whether it's a little I or big guy is yet to be determined. But we need to take action and investigate.
Or it's a routine event or a warning, and there's no further action. Sometimes we get alerts on hard disk might be almost full or some sort of advisory notification. You don't need to investigate it, but it is technically an alert.
And then in the middle you've got it's unknown. We're not quite sure yet what it is, and we need to do further investigation.
So let's start on the left hand side. It's known bad. It's an incident. Next thing we have to do is verify its impact and prioritise Is this a single system is at multiple systems. Maybe we don't know. Is it a domain controller or is it a desktop? Is that the CEO Oh's desktop? Is it somebody else's desktop
that maybe doesn't have sensitive information?
This is all part of that high value asset training and discussion that we've already had. So keep that in mind to as we go through here and then it once you have a now done this analysis, it goes to the I. R team, and they're the ones that are going to be doing the investigation.
I will go to the middle.
We have unknown issues or status. We need to do an investigation. So at this point, the sock might do a little bit of investigating just to get some more information, and they found out. Actually, this is fine. It's not a problem. So we're done. It's still unknown, so they need to continue to investigate
or once they've determined. Yes, this is in fact, malicious or it's bad in some way.
It again goes to the I R team
if it is good. So we essentially had a false positive. There was an alert. We investigated it. We found out it was nothing or it does not qualify. Shouldn't have been on alert to begin with. That's where you get that Sim owner involved. You tune that so it doesn't happen again or you confirm. In fact, it was a false positive
or it wasn't and take the appropriate action.
And then when we go on the far right side of the slide again, if it's just routine or a warning, it's not a false positive. It's actually it was a legitimate
event. But it's not something that really needs any action from the sock with assert. Now, if you have multiple incidents at once, which is not uncommon, there's a couple things to consider. One is the potential impact to see I ate the confidentiality, integrity or availability
and also safety. This is another component to cybersecurity that we didn't really think of
years ago, but it certainly is now. Physical safety could be in jeopardy as a result of a cyberattack. Think about dams and power grids and H V, A C systems, traffic control lights or other sensors or things that could put people's lives in jeopardy. So we need to think about what is the potential impact?
Is there a system
we have to alerts? One system fits shut down. Nobody would care about, and it has no information on it that anyone would care about, either.
The 2nd 1 is a critical asset. Well, this is a no brainer. We're going to investigate the critical asset first, but unless you know what your critical assets are, that's not an easy decision to make. And by the time you figure that out, you you just wasted a lot of time.
What's the sensitivity of the data involved? Do you have one server that's got P II and another server that just has routine? Actually, it's your public facing Web server, and everything's already public anyway. That's another thing toe look at. What's the reputational risk? Is this a system that, if compromised, would
be a problem for your organization if it was to get out into the media, or if the data on that system were to become public through some sort of a breach,
So make sure to keep in mind the reputational harm of a breach or an intrusion as well.
How about regulatory risk?
Do you have, you get multiple alerts. One system has health information on it. One system doesn't and you know your regulated to report health information. So you're clearly going to investigate that first, to see what's going on. And then again, the criticality of the asset and how critical it is, is it to the organization.
All right, quiz question for this lesson. What is not a consideration when determining what order alerts should be investigated?
A. Whether the investigation can be done before the end of work
be the impact to confidentiality, integrity or availability,
or c the sensitivity of the data involved.
The answer to this is a
You shouldn't determine what you're going to investigate based on whether or not you can get it done by the end of the day before you go home and probably happens in some cases. But
it's definitely not best practice, so we're gonna focus on what
can impact C I. A. And remember safety and also the sensitivity of the data involved.
Second question. True or false, I. Our teams should have documented flow charts and processes for handling frequent alerts.
The answer to this is, of course true, the more you can create ah flow chart. Like I showed you earlier in this slide on Here's the things to do for a phishing email. Here's the things to do for this kind of an alert malware that post came up on an E D r tool.
It just helps take the guesswork out. Help specially junior analysts in how to
handle these situations, and it gives you some consistency in a level of professionalism that's extremely beneficial. So in summary in this lesson, we talked about the differences between a sock and assert and how they can complement each other. We talked about work flows and processes and triaging cyber alerts,
and also how to handle multiple alerts at the same time.