7 hours 35 minutes
Hey, guys. Welcome to domain four of the S S C P Exam prep. I'm your host, Peter Sip alone.
This is domain for lesson one
incident response. So
in this domain, specifically, this lesson will be taking a look at incident handling, which is on the way An organisation handles an incident when it occurs. It's very important for an organization to respond to any breaches or system incidents in a very organized and concise manner.
Let's get started.
This is how the incident response process works. The first step is always preparation. Always prepare for an incident response, even if you don't think an incident will actually happen because you will always need to be prepared because eventually an incident will happen.
It's better to have something and not need it than to need something and not have it.
You could prepare for any incidents with an incident response policy.
From there, When you're going through any type of scanning, penetration, testing or anything, you might detect it an incident
and you might detect an event. And once that event is detective, you might want to a little bit deeper and analyze that event and then you realize OK, This is a security incident
from at that point you want to go to containment eradication and recovery. You want to contain the incident so it can't do any more damage than it already has. Your system, you want to remove the incident and then you want to restore business functions as normal.
After that is done, you can go back to detection and analysis that to determine whether or not there any more incidents. If there are more incidents, go back to the containment and eradication step and repeat this process until there are no more security incident.
From there. You want to go to the post incident activity, which is really just the process of going through reviewing the incident and implementing any countermeasures applying any patches do. It needs to be done to make sure the incident can happen again.
Once that's done, you go all the way back to preparation and prepare for the next time your organization might be breached.
We're gonna look at the incident response steps in a little bit more detail.
So the first step is going to be prop oration, right? This this is a foundation combined is comprised of a corporate incident handling every sponsor policy and procedure. This is how you prepare. You prepare by creating a policy and a procedure. You want to document
what you're going to do in an incident
on what matters and city one. Make sure you identify all of your critical systems and have a plan in place.
Incident response policy is establishes a based approach to instant response, Right. Like I said, you want to make sure you have all of the details on how to handle the incident. And you also want to have an incident response team in place.
couple aspects, which is security practitioners, should be familiar with when it comes to incident. Response. One. Management support. You always wanna have the support of upper management. You want to make sure that they know what they're supposed to be doing. When an incident happens,
you want to make sure the policy is lined with the goals of the organization. You want to make sure that the policy matches the organization strategy, mission vision objectives just to prevent as much damage as possible.
You want to make sure your objectives are off the policy or listed, and you wantto definitely include all what the policy might cover.
You want to define any and all terms in the policy, so everyone, even if they're not a very tech oriented person, you want everyone to understand the policy and what they need to do.
You also want to make sure you document the roles responsibilities of the policy, who was responsible for doing what, and you want to have a prioritization off risk. Obviously the most mission critical systems. You want to protect them as best you can. And any type of high risk
is what you might want to investigate first during an incident
you want if we wanna have metrics and performance to determine how how effective your incident policy is, and you always want to be talking and planning with other members of the Incident Response team.
Also, you want to make sure that everyone adheres to the policy. Everyone falls along on the same page, and they must comply with the posse regardless if they like it or not.
So I mentioned Incident Response team a couple of times, but who necessarily isn't the incident response team.
Well, the Incident Response team consists of all these different groups of people. For the first group, we're going to start here at the top in the 11 o'clock position is going to be customers, constituents and media. These are all people that have a
A something to lose a new organization. They'll have a specified interest in the organization, whether it be shareholders, people who own different stock or any media companies who might want to document follow along as the organization happens.
Other Incident Response Team's. These are people who may be a part of your organization or they may not be a part of your organization. You might want to bring them in. If an incident happens in your organization, they might be considered like third party professional.
Your Internet service providers, right? These are the people who provide network access Internet to your organization. You definitely want to make sure that in the terms of an incident, they can isolate your Internet access or organization to prevent the incident from becoming worse, You have incident reporters,
which are people who track and follow, and maybe the ones who even discovered the incident.
You have all enforcement agencies, right? This is really you know, the police or any type of law enforcement who might need to come in and assist with the incident,
depending on how bad it may be and your software and support vendors, right? If these people could even be part of the reason why you were your organization, had incident to begin with. So you want to make sure they're on the same page with what you're doing,
especially since the organise the incident could have came from
one of your software or support vendors.
So the second step and the incident handling is detection and analysis.
Detection of events. This could be very difficult, considering they're just loads and loads and loads and defends happening in the organization all the time and a force. There's many false positives, right? There's a lot of times when people think there's an incident or event that occurred that's really just
normal. Everyday trafficker operations
intrusion systems use the following techniques to determine any type of incidents. Right, there's a signature or pattern matching systems, which is, you know, a snippet of code that identifies the system. This is how vulnerabilities pick up on them. You have protocol, anomaly based system. So if
there is a protocol or
something in the system that's working a little bit weird.
Let's put his way. If it's working
different than how it normally works, we might want to take a look at that and statistically anomaly based systems. You definitely want to establish a baseline of like normal traffic patterns over time. So any time there's a deviation all of a sudden from this normal baseline,
you might want to look at that a little closer.
Instant analysis focuses on what constitutes an incident in the organization, right? Most events are not incidents, so since it could be difficult to determine
what an incident actually is, you want us to closer look at things that might seem weird events that might seem weird. And if you deem it to be an incident that you want to raise it to the level of an incident, and that will trigger the next step, which is containment eradication and recovery.
Like I said, containment limit the damage caused by the security incident. This might be in the form of isolating certain networks or shutting down certain systems or unplugging computers from the Ethernet just to keep the damage is minimal as possible
your medication. This is performed to remove any type of malicious toad tools or back doors that may have been used. Right. This is where you find the malware. You delete the malware, you remove it or you re image the computer. Something like that.
This may or may not happen, depending on the incident. Sometimes re imaging is quicker and more reliable.
So once all that is done and all of the incidents have been discovered, contained and eradicated,
you want to have the post incident activity.
Post incident activities consist of two different areas. The first is implementation of countermeasures, right. You want to figure out what the heck happened, and how can we prevent this from happening again? Usually good countermeasures are increasing fuser awareness and risk improvements.
Um, this incentive for bad behavior, lot more use your training and to help people just understand technology and how it works. The other type of post incident activity is forensics. This is where the S s c p practitioner kind of digs through the evidence
and tries to piece to gather the attack to figure out exactly what happened
in today's lecture. We discussed the incident response process.
intrusion systems. Use the following techniques to determine attacks except
a signature pattern based matching systems. Be protocol anomaly based systems. See statistically anonymously based systems
or D network anomaly basis.
If you said D network anomaly based systems, then you are correct. Remember, signature pattern matching protocol anonymously and statistically, non li are all different ways and intrusion detection system can determine whether or not an incident
he is actually happening.
Thanks for watching guys. I hope you learned a lot in this lesson, and I'll see you next time.