-: Incident Response Policies and Procedures.
So, when we talk about an incident response policy,
we are talking about a document
that provides the foundation
of your incident response program.
This is a very high level document,
and it's gonna guide your efforts
at this very high foundational level.
It's gonna provide the authority
for the response efforts.
It's also gonna provide you
who approved this policy,
and the policy is generally gonna be approved
by somebody in your C-Suite.
When I talk about the C-Suite,
I'm talking about your chief security officer,
your chief information officer,
your chief executive officer,
those really, really high paid guys
up at the top levels of your organization.
Now, this should be a fairly timeless document.
You shouldn't be updating your policy
every week,
every month,
or even every year.
Generally, most policies aren't updated
except every three to five years.
Now, when you deal with technology that changes
as fast as the technology we deal with,
how do you have a policy that lasts three to five years?
Well, you keep it very generalized,
and then you specify it with procedures
and guidelines further down,
and that's the way we look at this.
The policy is the framework.
Everything else starts underpinning that
with those specified information
that we're gonna give later on.
So when we talk about the policy,
what are we going to find inside of it?
Well, if you pull up your organization's policy,
you should find many of these things in it.
You should find the statement
of management commitment,
you should find the purposes,
the objectives, and the scope for the policy.
You should find definitional terms,
so what is an event?
What is an incident?
What is a CSIRT?
Those things we've talked about as we go through,
those are gonna be found inside the policy
because those terms may mean
something different to your organization
than it does to the organization down the street.
You're also gonna talk about the roles,
responsibilities, and authorities.
So when we talk about roles,
who is the CSIRT?
Who's the CSIRT leader?
What is their responsibilities?
What is their authority to do stuff?
All of that will go into here.
You'll also talk about your
prioritization scheme for your incidents.
You'll talk about your
measures of performance for the CSIRT team.
You'll talk about reporting requirements,
and contact information.
Now, here's a key.
When you're doing contact information,
do it by position, not by name.
So for instance,
you'll say the CSIRT team lead,
and here's his phone number.
Not, Jason Dion, here's his phone number.
Because if I get fired or I quit,
you don't have to redo the whole policy again.
If you just have that same phone number
that everyone uses,
whoever is the CSIRT team lead,
they have the same cellphone,
that's gonna save you a lot of headache.
Now, when we move down a layer,
we go from this foundational framework of the policy,
we start getting into more specifics
and we start dealing with procedures.
Procedures give you detailed, specific information.
They have step-by-step guidelines here
and they're not a replacement
for your expertise and judgment,
but they do help you remember what to do.
Because in an incident,
things are a little hectic.
People are running around trying to solve a problem
as quickly as possible
and sometimes we'll forget steps.
These procedures will help us remember them.
And often, we'll develop them as a specific playbook
as opposed to a generalized set of advice.
So, what would that look like?
Well, a playbook is gonna describe
a response to a high severity type of incident.
So you may have a playbook on,
what do you do if there's a data breach
of financial information?
What do you do if there's a data breach
of personally identifiable information?
How bout phishing attacks against your customers?
What about the loss of a corporate laptop
or website defacements?
What do you do if there's an intrusion into your network
or you have reset your Windows Golden Ticket?
All of those things may have special playbooks
developed with the specific guidance,
for your systems and the way that you do business.
Those will be updated much more frequently
than the policy,
and they're gonna be much more specific.
Now when we look at the Incident Response Checklist,
this is taking it a step further.
Now, this one is actually very, very generic
because it comes from our instant handling guide,
that government NIST publication that we talked about,
the 800-61.
If you want to download
the entire NIST publication,
you can with that link on the screen.
But this gives you an idea of
what a checklist should look like,
but your checklist may be more specific
based on your systems.
In this case, they've broken it down by phases,
detection and analysis,
containment eradication and recovery,
and they post incident activity,
and then a couple of steps on each one.
Now, if I was the CSIRT lead,
I would like to have these types of checklists
for your system
because it can make sure that
I'm not forgetting steps along the way
as I'm managing my team
and making sure they're going through
the incident response.
Checklists are very helpful,
but they're only as helpful
as the effort you put into making them
and how often you take them out
and run through them
to make sure they work
with the systems that you have.