Welcome to the cyber. A video. Siri's for security plus 5 +01 Certification and exams.
I'm your instructor. Wrong, Warner,
This is part two of section 5.4 on incident response
In part one, I talked about the importance of an incident response plan.
Part two is about the incident response process.
As I mentioned in part one, you should refer to the nous documentation on incident handling SP 861
on your screen. You'll see their process very well defined in that document
process is actually very well laid out. Starting out with preparation
in the incident detection analysis of the incident,
containment of the potential issue eradication,
recovery, getting back to business operation and then, lastly, post incident activity.
Let me talk about each item in detail.
Creating your incident response plan.
Every organization should have an I. R. P should be in a readily
because when you're going through an incident, you wanna wanna have to be searching for your i r p. Where did we put those documents?
This step talks about how to create the ai RP, which I covered in Part one.
How do you initiate those communications howto be prepared.
Do you have your hardware ready? So, for example, you have a hard drive failure, A system failure. Do you have that hardware available
or those applications? If you need to conduct digital forensics, you have the applications to do that readily available
your communications plan.
Many organizations may have a jump kit.
Basically, this is your preparation taken from the military. It's you're ready back.
I need this. Also for your i R P. It could be on the thumb drive, by the way, that you store in a safe,
fireproof safe. Preferably
this way. You have your plan and all of your tools at the ready.
You want to go through your testing, evaluation and exercises as discussed in Part one.
Then you need to use checklists.
Checked technical checklists for your help desk. What steps to date do they go through?
Technical checklist for your systems and network administrators
procedures for anybody who may be involved in your C E R, T or C I R T
and then contact lists,
who do you call when there's an incident?
Have all of those at the ready and make going through an incident so much easier.
We talked about in part one. What is an incident? And I
recommend you define an incident for yourself within your organization
just then. Based on that definition, how do you detect that incident?
Is it through alerting of some type with logs? You could have your network logs and intrusion detection system or Security incident Event Management system or A s I. E. M.
Anti virus may also alert you to a potential issue.
Humans are also often part of that alert chain. They'll call into the help desk with an issue
you don't know. It's really an incident until you begin to investigate.
Why you also want to go through your incident triage, where you identify and analyze what happened, where it happened. Who had happened to
potential impact. We're having experience. An incident response is very valuable.
What is the incident? Risk Ope.
Who is involved?
What systems are affected? Is it limited to just say one computer? Or is it a group of systems? Is its servers?
Where does it happen? Document all of this in your tracking system.
The number of systems
what data was affected, who was affected in terms of personnel
document document, document. And then you analyze what is the impact of the event and then recommendations for recovery.
How do you recover? Do you track the incident?
How do you escalate?
These are all part of incident detection, identification and analysis
planned for your incident. Document your steps.
Makes life so much easier.
Okay, so you're going through an incident. Say you have a data breach from somewhere outside your network.
Maybe that's where you want to contain it.
You put those systems in quarantine. Often, an anti virus will do this as part of its service.
The idea is to ensure the incident doesn't continue or spread
ransomware. Great example. You quarantine those systems? Maybe by pulling the plug,
you secure the scene, you limit the access and this could be done physically
through networks through access control.
Then you gather the evidence.
What systems were affected? Maybe that's where we're talking about digital forensics. You make a copy of the image
to be able to investigate for later on you. If you
if it's an internal employee who has been doing things they shouldn't. Maybe you're taking their computer from that,
making sure the evidence stays Perse T.
This is all part of the incident. Containment
Getting rid of whatever is causing the problem. It could be virus clean up. It could be someone who, externally, is accessing your systems. Who shouldn't be
By removing their access,
you find the root cause. You eliminate the root cause,
removing elements of the incidents such as malware. So the midget auto,
as I mentioned, different ways to do this antivirus cleanup,
patching or updating the software So it's known vulnerability You playa patch may be a way to eradicate the issue,
re imaging the systems often the quickest, easiest way, particularly with workstations
then restoring from a backup.
going back to a known good state, these were all different ways of eradicating
the issue is part of incident response.
The whole idea of having a good incident response process to go back to business as usual.
That's the idea with incident recovery. It's the process of restoring and returning affected systems and devices
back into your business environment again in case of malware,
eradicating the malware, getting back into production as quickly and easily as possible,
mentioned in the previous life, different methods to do this including restoring from backup
using anti virus patching,
hardening the system through baselines.
Access control. So someone who's externally accessing your systems. Who shouldn't
strengthening access control from the exterior of your network
than authentication? Maybe changing passwords is another way to respond to the incident
could include also procedural changes
through all of this, though, make sure you're documenting the steps that you are taking an including part of your incident response process
after your incident.
You shouldn't just stop. You should take the opportunity to learn from the incident, creating this lessons learned document. Improve your incident response plan.
Walk through what went well with the incident where you stand for improvement
and then other types of lessons learned.
Haven't after actions meeting with anybody involved
when you capture actions such as the cause of the incident costs associated with recommendations to prevent future types of incidents.
If you have any regulatory or legal requirements that may also be include included with this post incident report.
Taking the time to think about and learn from your incident will greatly ease the next time. A similar type of incident may occur
in part one, and part two of this video on section 5.4 incident Response. We went through the incident Response Plan. An incident response process.
Let's work through some sample test questions.
According to Gnashed, which is not not a listed step in the incident response process
preparation, documentation, eradication or detection.
The answer is B documentation
after be included in every step.
Question two on incident response
The following is n'est ce definition of what term?
An occurrence that actually are potentially jeopardizes the confidentiality, integrity or availabe availability of an information system where the information the system processes stores or transmit
the answer is D
This concludes part one and part two of section 5.4.
Given a scenario, follow incident response procedures.
Walk through these not only to help you when you're walking
this concludes section 5.4 Given a scenario, follow incident response procedures recovered insert response planning and then the steps you should include in your written incident response procedure.
This is Ron Warner