>> Again, harping on the policies.
Your policy should state what to do, when and by whom.
So what actions and what authority,
are the incident response team members
authorized to take.
Essentially and looking at that policy,
there should be a prioritization of actions and
incidents that coincide with
your organization, your company's goals.
Ideally what should happen is that
they should do the thinking for you.
They should take the guesswork out
of responding to those incidents where you're
just able to go in and perform your work functions
as required and not have to
ask for a lot of mother may eyes,
in these particular instances.
They should have the granularity
enough to highlight details
of actions that you should take while still
providing this very fine details
of an incident response plan.
You want to be able to look at this and
>> essentially have a playbook per se
>> when you come across this type of incident,
you know exactly what to do and exactly
how to handle this incident,
because it's documented in
some type of policy and procedure manual.
Also in conjunction with the policy you want to look
at what is and what is not allowed within your network.
Going back to that policy,
it's not technically an incident
unless it violates your security policy.
In conjunction with that CIA triad of
confidentiality, integrity, and availability,
although it may touch on some of those actions
>> that may potentially violate the CIA triad.
>> If you have a very good policy and procedure guideline,
unless it violates something
within your organization's policies and procedures,
it may not necessarily be an incident.
Again, your policies should look
at all aspects that
could essentially impact the organization's operations.
Those policies and procedures essentially want to have
a no or no-go list for what's allowed on
your network traffic, your protocol matrices.
What is allowed for host applications and services?
What type of web,
email or FTP processes
are you allowed to have on your network?
Lot of organizations are going to cloud-based services.
So what type of traffic is or is not permitted
on your network that your employees can use?
If you start seeing a lot of email or my email traffic,
but if you see a lot of traffic going
up to an FTP servers,
that's something that's allowed.
Are you losing large amounts of
data to that foreign uploaded side?
User account activity or users following the policies
>> and procedures that are prescribed
>> for that acceptable use policy.
If they're doing something that generally
falls outside of an acceptable use
if they're going to websites that they shouldn't go to,
if they're sending emails to foreign email addresses,
does that violate that user account of activity?
Also you need to look at the administrator accounts.
Are individuals assigned administrator roles
that necessarily shouldn't be,
or administrators taking actions
that they necessarily should not take?
Then guest and other account activity.
Disabling guest accounts on
computers or ensuring they don't have them,
or the creation of
guest accounts where they shouldn't be,
and other types of activity which would essentially
violate your organization's security policies.
Knowing essentially if there's
a problem is very important,
knowing what right looks like,
it is important that way
>> you know what wrong looks like,
>> and you're able to investigate
and remediate those incidents.
Again, policy will help us discover essentially
>> what is permitted and what is not permitted.
>> But what if there's a lack of policy?
If you notice something on the network
that essentially violates that CIA triad,
but there's not necessarily
a policy or something that's codified,
providing guidance on what to do,
one of the first steps that you should take is
to notify senior management of,
hey, I've noticed that there's this type of problem.
Here's the type of impact that it
could have on the organization,
and asking them for guidance on
that situation once you've
provided them all of the facts,
or the what ifs that could occur.
Another step that might be taken is to form
essentially an ad hoc incident response teams.
Essentially this part of that team
you're going to want to have a director,
probably someone who is from
senior management or at least is
able to report to senior management,
an investigator who is technically savvy,
who understands essentially what is occurring,
what that incident,
and then the other staff roles that we've talked
about in this class is appropriate.
Then once you've essentially form that team,
you're going to want to follow those react
>> principles and procedures in order to help resolve
>> that incident and prevent it from getting worse.
>> Then lastly, if you don't have
policies and procedures or you don't
have a lot of
experience within that incident response team,
the most important thing that you're going to
want to do is get help,
be it internal or external help.