domain name was all about incident response. It's a discipline of its own.
Each organization is gonna vary a little bit.
This particular tactics that you're going to use their going to be different based on the applications the cloud provider you're using and so forth. But we did talk about a grander framework and that's how we examine this. If this is an area that you're actually working in, highly recommended the NIST 861 revision to specifications.
This is what we followed in our structure.
Says what? The C s a follows in its structure. You don't have to read it for the CCS k exam itself, but it really does provide a thorough perspective on incident management. As we looked at the incident response, Lifecycle started out looking at the preparation phase. It was establishing the S L. A's defining roles and responsibilities.
Importantly, creating and testing a communication plan.
The highlight key points in the detection and analysis phase, setting up alerting and automated responses wherever possible and knowing how to access and interpret the data logs that we were going to be dealing with containment eradication in recovery. Big point clearing the management plane before thwarting the attacker,
then isolating in rebuilding apple, a structure being something we could take advantage of in the cloud world.
Finally, we post incident activity. This is where we're focused on evaluating what we did to respond to the incident, how things went and are there areas for future improvement that we could put in place?
Let's go through some end of module questions here before wrapping everything up. How often should you drill your incident response plans every day, once a month, once a year. Whenever significant changes are made on Lee after you first create them. So there's more than one correct answer to this.
Think about it. We'll walk through it. OK,
so according to see s a guidance, you want to drill your incident response plans once a year. And whenever significant changes are made, that would be C and D. You can do it more frequently, but you may be spending cycles and effort that you don't need to, and certainly only doing it after you first create an incident response plan
is gonna be very inadequate.
Which phase of the incident response lifecycle do you do? The following set A proactive scanning, performed vulnerability assessments and conduct risk assessments,
preparation, phase detection, containment, eradication and recovery or post incident phase.
Only one answer on this and it is a preparation. This is when you're putting together everything in ready detection is when you're receiving the alerts and analyzing the situation and starting to respond
in which service model where you most rely on logging instrumented in your application Also referred to as observe ability, SAS pass I *** infrastructure, apple a structure, meta structure or infrastructure
And the correct answer would be be with sass model. You're not making the application, really? And you don't have control over this logging capability with the past model. A lot of the nuances of the underlying virtual infrastructure are actually abstracted from you and your ability to obtain logs say virtual machine logs aren't gonna be there
in the I s model, you can still have access to the machine log
and after employed the tools that you've used traditionally when handling incident response situations in both structure, apple structure, meta structure and infrastructure are part of the logical stack. These air not part of the different service models,
and that wraps it up for this module on domain nine incident response. So thank you. And look forward to proceeding under the next domain.