So in this lesson,
we are going to talk about "Handling Data Spill".
We're going to start off
by explaining what data spill actually is,
then we're going to talk about some mitigation strategies.
So we're going to look at risk identification,
we're going to look at avoidance,
and then we're going to talk a little bit about repair.
But first, let's talk about what data spill actually is.
The National Institute of Standards and Technology
defines it as a "security incident that results
"in the transfer of classified information
"onto an information system
"not authorized to store or process that information".
That's a super complicated way of saying,
"Well, someone breached your defenses and took some data
and moved it where it shouldn't be moved."
That's essentially what data spill is.
And if you remember, we talked about defense in depth
a couple of lessons ago,
and data spill is just a breach
in one of those defense in depth circles.
And so here's that slide again.
So basically, a data spill would be a breach
of your firewall, which is your perimeter,
security layer 3.
Or a breach of your identity and access.
So, someone got their password stolen
and we have a breach on security layer 2.
So essentially, that's what a data spill is.
Someone has breached one of your defense layers.
Well, now that we know that, what do we do about it?
Well, it all starts with risk identification.
That's why establishing a baseline is so important.
And we do that by having monitoring in place.
For instance, if we know how much data is moving
in or out of your system, as a baseline,
if we see a big spike in data moving out of your system,
that could be a really big clue
that we have a breach somewhere.
Or if we see activity in a database,
way outside of the normal hours,
or from a region that we don't normally see movement in,
those are all things that a baseline
would help us to pick up.
The next is, know your golden goose.
We talked about the golden goose being your data.
You need to know what is valuable in your data.
If you were going to go into your system,
what would be of value?
What would you want to have?
Is it going to be customer passwords?
Is it going to be credit card information?
Is it going to be valuable IP information on your business?
I don't know, but you probably do
if you spend some time thinking about it.
You need to know what that is,
because that's going to help you to understand
what you need to protect
and where the vulnerabilities lie.
Next, you need to understand your regulatory requirements.
You need to know how long you need to store data.
You need to know how that data needs to be separated.
It may be that you need to have multiple subscriptions.
And to be fair, you need to have multiple subscriptions
for your environment anyways, just as a best practice,
but there may be additional regulatory requirements
beyond that as well.
And then, know your likely vulnerabilities.
Once you have all of this information together,
you can kind of map out where those vulnerabilities lie
and look at ways to shore up those areas,
whether that be through additional monitoring,
whether that be through additional security,
or multifactor authentication,
or a whole host of different things
that you could do to fix those vulnerable areas.
Next, the mitigation strategy of avoidance.
And when I say avoidance,
I'm not meaning from a project management sense,
that we are trying to avoid the risk by getting insurance
or passing the risk off to somebody else.
Instead, I'm thinking about avoidance
in: how do we decrease the risk of breach?
This is through our leveraging defense in depth.
If we have multiple layers,
we are going to make it much less likely
that your environment is going to be breached.
This is helping us to avoid a breach,
which is what we need to do.
You also need to isolate and minimize your breach risk.
I talked about multiple subscriptions;
this is a good way to do that.
If you have a subscription for marketing,
and a subscription for your dev,
and a subscription for your accounting environment,
that's going to help if there is a breach,
that maybe it's just contained in your dev environment,
and it doesn't bleed into all areas of your business.
So make sure that you look at ways
to isolate or minimize a breach risk.
Use RBAC. We talked about roles
and how important those roles are.
If we have roles defined
and what you should be able to access with those roles,
shutting a role off or shutting access
to an individual role for a contractor
becomes much more easy,
and it becomes much easier to manage
and understand who has access to what.
So make sure that you're using RBAC.
Also, use keys.
I've talked about not storing passwords.
Not storing passwords, certainly, hardcoded
into your scripts or code.
So make sure that you're using keys
because that's going to help you, again, to manage access.
And then, if you've had a breach, what do we do?
How do we repair the damage?
Well, we need to first close the vulnerability.
So, do an assessment and figure out what has been breached.
See if you can understand, and if you have a good baseline,
that shouldn't be too hard to do.
Make sure that you close that vulnerability.
If you have RBAC, great.
Shut those roles off, shut those keys off, close the loop.
Once you've done that,
you want to go back through audit and assess.
So this is a longer, deeper assessment
to make sure that you understand:
first, that the vulnerable areas really are protected;
and then second, you understand where your risk lies.
So you want to reassess that risk.
What's changed? Have you really closed the things
that you needed to close, and fixed the areas
that had breaches or were at risk?
Next, you need to implement those new procedures.
So from your auditing and assessing,
you should have a plan that you've built in place
that you can present and say,
"Hey, look, this is what happened.
"We got breached, or we have a risk,
"here's the risk and what it is.
"These are the procedures that we're going to do
"to fix that risk and make sure
"that it doesn't happen in the future."
If you've done all that,
we are down to a few key points to remember.
First, smoke alarms.
They are almost never used,
but they are very important.
When we talk about security and we talk about these things,
the hope is that you never have a breach.
The hope is that you never need to use
some of those tool sets,
because no one tries to break into your environment.
Just like the hope with a smoke alarm in your house
is that you never have a fire.
You hope that that thing never goes off.
But if it does, it is very important.
Same thing for your security and your defense in depth.
Having those layers built,
having that monitoring in place,
is incredibly important in case anything ever does happen.
This is a great place for real-world application.
This lesson, specifically, is good for that.
So take a few minutes and just think about your environment.
Think about where you work,
or think about your home computer that you're studying on.
This is a great way to think
about that defense in depth
and put some actual practical application
to this lesson and this environment.
And I'll give you an example.
So it's been a couple of years now,
but there was a major breach
of a retailer in the United States.
And what happened was they had the environment secure,
with the exception of an air conditioning service.
They had air conditioning vendors
that were coming in and interacting with their environment,
because they needed to access the AC units.
Well, someone figured out that, from that access point,
you could get into the entire system of that retailer.
And so what they did is they actually breached
through the air conditioning service,
which, who would've thought that, right?
But they breached through that third-party contractor,
and once they got in through the contractor's portal,
they didn't have layers set up properly,
and they were able to get to the golden goose.
They were able to get to the data that they needed.
And there was a massive breach because of that.
If you had had layers set up like you were supposed to,
if you had had your roles defined
more appropriately for contractors,
something like that may never have happened.
So, good real-world application.
And also, take some time to look at your phone,
or your computer, or your work,
and just kind of think through where those risks lie
and what you would do to fix it.
As far as the DP-203, the application really here lies
in thinking about the environment,
and being able to think through a problem.
There's probably not going to be a ton of questions
on the specifics of defense in depth,
but it's more being able to think
through a problem like this
that may help you on some questions for the DP-203.
I hope this lesson has been helpful,
not just for the DP-203, but for your career.
And with that, let's jump on to the next lesson.