The importance of process.
The importance of any process is you have
a planned methodology that produces consistent, repeatable results and that
you can defend both process wise and legally.
Incidents can happen any day at any time.
Compromise crucial business data in terms of both finance and reputation.
We definitely talked about that.
With rapid increase in threats and incidents, the need for effective and
structured incident handling response has become mandatory for every organization.
You need an incident response plan.
Without it, you're dead in the water.
No telling how efficiently you're going to respond to incidents.
This goes a long way in minimizing damage
and not having to make decisions at the time of exploitation.
An overview of the flow.
We're not going to pick this apart too much.
We have a certified incident handler, EC Council, or ECIH course, which is a three
day course that deals specifically with incident handling and response.
Refer to the ECIH course for more on that.
Then, of course, we have the CHFI course,
which is one of my favorite courses to teach, for the forensics side of things,
which we'll be talking about in a later module.
Here's your flowchart.
Step one, preparation for incident handling response, which is again, scope,
management approvals, funding, developing the team.
The incident response plan is again determines the future course of action for
establishing, managing, and strengthening incident response capabilities.
Should address mission and goal statements, meet the goals of the incident
response initiative, comply with statements of senior management strategies
to achieve set goals and timelines, to have an organized approach and incident
response, statements of interoperability, efficient use of all resources, added
value to organizational processes by strengthening the organization's security.
Again, more detail on that in the CIH.
Training and preparing.
Without training and preparation, all of your procedures and policies are useless.
If nobody knows they exist, they're not
familiar with it, they haven't trained on it.
They're just concepts.
It's just writing on paper.
Maintain sufficient overall staff so that
the team members have uninterrupted work time, provide hardware and software
components, provide the team with appropriate
technical references, training, drills and exercises, prepare training budget,
hire external subject matter experts for training, rotate team members.
Really important.
Rotation and having depth in these roles.
You should build these emergency response
functions, disaster recovery, business continuity into job descriptions.
That way, if this individual leaves the company, part of their description ensures
that those responsibilities are handed over or handed off to their replacement.
Develop mentoring program, various scenarios on incident handling, conduct
round table discussions, and training and mock drills and practice sessions.
Monsterously important.
What looks good on paper...
Back when I was playing football in high school and baseball, we'd have chalk talk
day where we go through the plans and everything we're running for whatever team
we're playing that week, which looks great, but unless you go out and practice
it, you're not going to be able to execute effectively.
A plan on paper looks good,
but till it's been validated in the real world, it's not complete.
There's all sorts of things that can go wrong that require modification and
redrapping, so drills are especially important.
If you can do the drills successfully in
the appropriate time frames, you're going to consider your policies to be adequate.
That especially is important for business continuity and disaster recovery.
Step two, incident recording and assignment.
Here's your flowchart for that.
I'll let you produce that.
The incident is recorded, escalated, and
assigned to the incident handling response team.
Incident triage, analysis and validation.
What you think may be happening may not be happening.
Again, verification.
Bob logged in from remote IP at 3 AM on a Saturday morning.
I think it's vacation. It actually was Bob, no big deal.
Or maybe Bob's actually not allowed to log in.
Verification ensures that it's in fact taking place and then it can respond.
Analysis and validation helps determine the effective resources.
The classification identifies the severity.
The severity dictates how quickly you need
to respond and that leads to prioritization.
It determines the sequential process of attending or responding to security
incidents by prioritizing based on severity.
That's again where you say port scan to address or active denial service attack.
Our notification.
Incidents are communicated to different internal and external stakeholders.
Communicating the incident helps reduce the impact by facilitating better
coordination between the stakeholders affected by the incident.
Again, once it's verified, prioritized notification, coordinated response.
Containment.
Your first order of business is to minimize the damage once it's all been
verified, and that generally involves containment.
We've got an intruder on a system, shut
off their connection, shut it down, block the IP at the firewall, whatever.
However, maybe they've been redirected to
a honey pot, and in order to gather more intel about their activities and their
purpose, you may choose to let them continue.
So containment may or may not involve removing access or shutting it down.
But you do want to allow no further damage.
So at this phase, evidence of the incident
is collected, sent to the forensics department for further investigation.
So we'll be talking about forensics, like I said, risk repeating myself.
Again, we'll be talking about that in a later module.
Step six, evidence gathering and forensic analysis.
The organization can use the evidence to
prosecute attackers, claim damages, and claim cyber insurance.
The evidence gathering is very meticulous.
Like I said before, we're going to talk about that in forensics.
You want to properly handle, collect the evidence.
If you don't do it, it's going to be
inadmissible and you're going to hear about it from your superiors.
I guarantee you that.
Step 7, eradication.
In eradication phase, you need to remove the root cause of the incident, close all
attack vectors to prevent similar incidents from occurring in the future.
So how did this happen?
Let's fix it.
Okay, eradication, solved the issue that led to the compromise to begin with.
Those countermeasures would be updating
antivirus, installing patches, compliance checks, security audits, disabling un
necessary services, updating policies and procedures, change
passwords on compromise systems, reinstall compromise systems.
All right, step eight is recovery.
After eliminating the cause of the
incident from all systems, the IH&R team restores the affected
systems, services, resources, and data through recovery.
You want to complete your evidence
collection before you recover because restoring a system to a preexploited state
is going to remove the evidence, clear it off.
Step eight, recovery, restore it to
same or better security part of the incident.
Then step nine, post incident activities.
After eradicating the incident, you're going to perform activities to improve the
response for future attacks, which is basically a review.
How did we do?
Well, we did great on this one, or we got our rear ends kicked on this one.
Holy cow, we got slammed on this one.
What do we do to fix that in the future?
Or we've never seen this before, we need to update the policy to accommodate.
These activities help in evaluating and improving the effectiveness.
Post incident activities would be assessed
lags and security posture settings and configurations.
Suggest measures and security products to harden the security and review the
policies and update the incident response policy.
That's going to wrap us up for our incident response discussion.
We have a huge discussion that's going to be coming out of that in forensics.
That's going to wrap us up for Module 19.
We got a lot to talk about a little bit later in the forensics module.