Remember that equation.
This we covered in the last episode of the Cybersecurity Architecture series.
Welcome back.
This was about security equals prevention, plus detection, plus response.
This is basically what we're doing in security.
And we talked about at the very beginning of the series some security
principles and roles and things like that, tools of the trade.
Then we moved into prevention and we looked at each of these different domains: identity
and access management and endpoint and network and application and data.
And this is basically that mostly those controls we put in place
are about prevention, trying to prevent someone from breaking in or doing damage to us.
Then in the last video, if you didn't see that, make sure you check it out.
In the last video, we really focused on the detection portion of this.
The thing that's up here that does the monitoring and things of that sort.
Today, we're going to move on over into once we've discovered that, how do we do response?
So that's what we're covering today.
Let's start off with some of the basics of security response.
Well, remember also I talked about this diagram where basically the bad guy comes along and he begins his attack by doing reconnaissance.
That's some number of days where they're basically casing the joint.
They're looking to see where are the weak spots, where can I get in?
Then the attack occurs and this is where the damage begins.
Unfortunately, where the attack occurs and when we're aware of it is separated by a period of time.
And that period of time we call the mean-time-to-identify (MTTI).
And the according to the Ponemon Institute's Cost of a Data Breach survey, which I've mentioned before, this is roughly--
I'm going to make it approximate --roughly 200 days on average
between when the attackers get in and when we're actually aware of it.
Mean-time-to-identify 200 days, the bad guy is sitting in your house
doing who knows what before you finally realize that it's happened.
That's a big problem.
But that's what we covered in the detection portion.
Then what we're going to look at today is this next bit here.
The mean-time-to-contain (MTTC).
How long does it take for us,
once we're aware, to get the damage controlled and the bad guys out and get back to operation?
And it turns out this is on the order of 70 days.
So this is the response portion of all of this. That is clearly not working well.
We in fact, if you look at the numbers over the years, these numbers stay roughly the same.
They don't really change much.
So even though we've had more tooling, we've had more understanding, we've had a lot of things that we've tried to do.
We've not been, as an industry, all that terribly effective at reducing
that mean time to identify and mean time to contain.
So what are we going to do?
We're going to look at this this stuff in the response part and see if we can shrink this 70 days
and make that some number that's shorter than that.
So, for instance, the group that's up here doing this, I talked about this also in the last video.
This is what we know as the SOC, the security operations center.
And it is a centralized team of people whose job it is to monitor and look for across all the different ones--
each one of these domains is sending their information up so that we can see what's going on.
We're going to detect whenever we see anomalous behavior alerts, things like that, we're correlate all of that
and then we're going to respond, which again is the focus of what we're talking about today.
And that response business has traditionally been called incident response or IR.
And one of the big things that can cut the cost of a data breach is having a good incident response capability in place.
Traditionally, again, that's the terminology we've used.
It's not wrong, but that's just where we've come from.
And what it is, is traditionally we've also made this largely a manual process.
It relies on heroes and experts, people who just happen
to have knowledge in their heads and a gut feel on what to do.
And that's how we do this.
Unfortunately, that really doesn't scale well, and it's not necessarily all that repeatable.
But their job is to, first of all, triage.
That is to when we get these alarms that come in, we've got to determine, is that a real attack
or is this just some noise that's out there?
And if it's a real attack, is it a significant attack or is it not so significant?
And which ones?
Because we never have time to respond to everything as quickly as we'd like to.
What's the order of importance?
That's the triage aspect of that.
Looking and figuring out which patients do we need to see first.
That's where that word comes from, is in the health care industry.
And then once we've figured out the pecking order, then we're going to do remediation.
That is, we're going to fix whatever it is, we're going to block.
We're going to shut things down. We're going to apply software patches.
We're going to put in controls so that we're no longer leaking data
or our systems are able to get back up and running again.
Now, the more modern approach that we hear, the terminology is SOAR. And I'm going to do my best
to resort to not using any puns when it comes to a word like this, but it's awfully tempting.
Anyway, source stands for security, orchestration, automation and response.
So it's automation and orchestration.
We'll talk a little bit more about those coming up and the difference between the two.
But just say where this tends to be traditionally much more manual.
The idea with SOAR is that we're going to try to make things as much as possible automated
and that hopefully will help us reduce the time that it takes to contain.
Okay.
Now we've covered the basics of response.
Now let's take a look in a little more detail about cases
and investigations, because that's the thing we're going to do next.
The way this works is we have an attack.
Remember, over here. Well, now I've depicted it here.
And this attack then is going to generate hopefully some sort of alarm, some sort of event, some sort of indication that we have a problem.
And that's going to flow on up here into the SIEM, the security information and event management system,
which makes up this detection portion of our security architecture.
Now, we may also have the SIEM feeding in to an XDR, as I mentioned in the previous video.
Or they may be separate.
You may only have XDR or only SIEM.
So I'm just going to depict it this way for the purpose of this illustration.
What I'd like to do then, if this system is able to identify that we in fact think this is a problem and someone needs to go into more detail
and investigate this, then one of the things I'm going to do is create a case
and I'm going to create that case here.
Either one of these systems could open the case automatically
in our SOAR system, the security, orchestration, automation and response system.
So the SOAR is depicted here.
It's got this case management as one of its components.
We can also use that to modify cases.
We can use it to assign cases.
So I'm going to assign this case over here to this guy right here.
And he's going to be responsible for looking at all the cases that are assigned to him.
And when he does that, one of the things he'll see is that if we've done a really good job, our XDR or our SIEM
not only created the case but also added in these things right here artifacts, indicators of compromise,
useful information that the cybersecurity analyst is going to use later when they start trying to do their investigation.
So we can take that information and add that into the case automatically.
So we enrich the case is another way of looking at it.
And that way this person isn't starting from zero.
They've got some information. There's a problem. Here's where it started.
Here's some information I have about it. Now we can also with this
SOAR case management system track and maybe we have an extra dashboard
that allows us to figure out which cases are open, which ones are high priority,
who's investigating these and even reassign these as we need to and make kinds of adjustments of that sort.
Now, this person is going to need to do this investigation business.
They're going to have to dig in and figure out what's going on.
How do they know what to do? Do they just start guessing?
Do they start poking around where we'd hope that they would have a more
consistent, repeatable way of figuring out what the problems are.
So we'd like to guide their activities, especially if this person is not very experienced and doesn't know where to start first.
So we have these things called dynamic playbooks.
So a dynamic playbook is something where we have gone in--
in advance --and determined when you see this, then run this routine.
If you start here and then you go off and run these two
events, maybe their scripts,
maybe their particular procedures that a person is supposed to go through and they do those.
And based upon the results of those things, then they might do other things.
And depending on the results of that, they do something different.
That's the dynamic aspect of this.
So it's not just a static standard operating procedure
that spells out you to number 1 through 10 statically every single time.
There may be some of those things, but in fact, what we find is that there's a lot of cases where we have to be
more dynamic and more flexible.
And what you get from this step will depend on what you want to do in the next steps.
That's why it needs to be dynamic.
And if we're able to capture that kind of information in a dynamic playbook, we can guide this person.
They don't have to have all of the expertise that knows everything about everything,
but they can follow the playbook and let it guide their activities.
Ultimately, they're going to figure out where the source of the problem is,
and we're going to spell out with the remediation steps they should take.
And then they can go back here to this system and figure out what they need to do in order to get things.
If we're leaking data, stop that hemorrhaging.
If it's a system that's down, how to bring it back up and protect it.
Do the remediation that's necessary with that system.
Okay.
Now, we have gotten an indication that there was a problem.
We created a case, opened it in the case management system, and now we have the cybersecurity analyst
that's going to go off and investigate this, figure out what the problem is and remediate.
Why wouldn't we just automate everything?
Well, I'm going to address that in this next business of automation versus orchestration.
So think about this. Here's the manual approach.
And we can think about everything as being on this spectrum.
Either it's done entirely manually or it's done entirely in an automated way. And as much as possible,
I'd rather do it this way.
The problem is, in security, we see a lot of things that sometimes we refer to as black swan events.
You know, swans are normally white, sometimes they're black.
It's not impossible.
It's just more rare.
And it's not what we expect.
And I can only automate what I've seen before.
Sometimes we even get in security
some of these things we call first of a kind events. And a first of a kind,
okay, I'm probably going to have to figure that out manually because I won't have known how to set up a script to handle that in advance.
But what I'd like to do is, as much as possible, do
as much of this as I can in an automated way and for the things I can't.
I'll stop somewhere along this continuum and we'll do what we call orchestration.
Think of this as sort of like semi-automated, where we have a human
who is directing the system and saying, okay, go, I'm going to push this button.
It's going to go off and do these procedures and I'm going to push this button.
It's going to go off and do these things.
So think of this also another way analogy here is the conductor in an orchestra
who is saying, okay, now I want the violins to come in here and I want the drums to exit there.
And they’re orchestrating what is happening in this case.
So orchestration is a step that's not fully automated, but it's in that direction.
And the whole goal of this modern SOAR capability is to, as much as possible,
move things in that direction where it's more automated and less manual.
And orchestration is a step along that way.
Well, what are the other things that we have to do?
It turns out if someone attacked us and there was data that was sensitive to individuals
that then got breached or got compromised and bad guys got a hold of it,
then we might have a responsibility here for notification.
This whole business of breach notification.
One of the first things we have to ask is what kind of data was involved?
Well, maybe there were names.
There might be Social Security numbers,
if you're in the US, other types of ID numbers, credit card numbers and things of that sort.
That's the kind of information.
So that's the data.
I need to know what kind of data was compromised.
Then I need to know what geography were the people whose data was compromised involved.
So what nation are they in?
Maybe even what state or region within that?
Because it turns out we have different breach notification laws in different countries, in different parts of the world.
And even within a country we have different breach notification rules.
So for instance, one of these major ones is called the Generalized Data
Protection Regulation, GDPR that comes from the European Union.
And GDPR specifies very specific, very heavy penalties.
In fact, if you don't respond within a timely fashion,
the penalties for this can be on the order of 4% of worldwide revenue.
So 4% is a huge number for most organizations.
Or it can be €20 million, whichever is greater.
That's a big penalty if you don't report in a timely way
when consumers data, citizen data has been compromised.
And again, you might say, but I don't care.
I am in the US or I'm in Australia. I don't have EU,
you know, really hanging over my head.
Think again.
If you've got EU citizen data, you might be subject to EU rules and penalties.
So then it's a question of prosecution.
But regardless, there are other types of rules in the US.
Each individual state is kind of coming out with their own sets of rules, with their own set of regulations and so forth.
So there are lots of these, and this is what makes it really complicated
to make sure that you have complied with all of these regulations because there are so many.
It's really good to have a tool-- point being --that would help you with all of this.
Once I realize as part of my investigation that there has been a data breach,
I'd like to go into the tool and say, here are the types of data that were compromised.
Here are the geographies where it was compromised,
and here are the different regulatory requirements that I have to to follow.
And based upon that, the system would come out and tell me exactly who do I need to notify.
And that way I don't end up with a bunch of this because that gets to be very expensive.
I hope you've enjoyed watching this series as much as I've enjoyed making it.
As I told you at the beginning.
This is a condensed version of a course I teach at a local university. So you don't get any college credit.
But on the positive side, you also didn't have any homework and you didn't have to take a final exam.
So good news in that regard.
I hope this also whetted your appetite and increased your desire to learn
more about cybersecurity and that you find this topic as interesting as I do.
What we'd like is to get some feedback from you.
If you can add in the comments. What did you learn?
What was a particular value to you in this series? That helps us know what kinds of things we should be doing in future videos.
So also take a look at in the description below
and you'll see a playlist that shows you all ten videos that were in this series in case you missed one.
You don't want to miss. You want to catch all of them.
So please go take a look at that.
And as always, like subscribe and hit the notify bell so that you're aware of new videos
as they come out.