1 hour 27 minutes
welcome to module to How do you seem? Tools?
In the last video we discussed seemed tools what they are and why they should be used
in this video. We'll expand on this and discuss further end up. How do you seem tools for logging and other activities
for your next pre assessment question.
True or false, you need an understanding of the incident response process and order to effectively use seem tools.
If you enter. True, you're correct
on understanding of the incident response processes Pair Mountain Using seem tools. It's important to be able to discern which logging data matters and when something doesn't look quite right.
Learning to apply the cyber killed shade and encouraging organization to establish triage stops are some critical steps in utilizing Seems effectively.
So how do I you seem? Tools.
It's important to know which data matters. If all operational data is collected, we'd have an information overload consisting of hundreds of thousands of events per second.
This would be exhausting and nearly impossible to sift through.
Therefore, wanting to determine what assets are critical that we need to pull Information from.
This can include different servers, routers and switches, firewalls, anti virus intrusion detection systems. Active directory logs, et cetera,
seems typically offer customized dashboards per analyst. Ah, good habit is to create a view that suits your needs.
Avoid the common pitfall of becoming a log report depository for your organization.
Another important part of knowing how do you seem tools is to know when certain data is generated. This is understanding patterns and the impact that there might have on your organization. It's important to be able to discern whether a piece of log data is benign, a threat or an incident.
When you encounter a piece of log data, it will often be tagged with an event coat and have other information included, such as time frequency, user information, etcetera.
Based on this information, you should be able to look back through log activity and determine whether this is normal activity for the network or user or process, or if it's unusual.
If it's unusual activity he needs surrounding logs and data to gather clues and evidence to further investigate
logging events in temporal proximity of events of interest is extraordinarily helpful when needing to escalate events, Most seems support base lines, which can be helpful in identifying event that do not occur frequently but do occur consistently
seems often include alarms and alerts that can also be configured to alert on key events. For example, if a administrator log in and a production machine happens at an unusual time outside of what normally happens, get old set off an alarm or you can configure it to set an alarm off so that you're notified.
More complex events and related events can be condensed into correlated events, which will discuss leader on in some of the labs.
Another important part of knowing how to use seem tools is understanding the incident response process.
This is a process that begins with preparation and has six steps that lead the lessons learned.
Preparation is where most of the legwork needs to be done when responding to an incident,
a lot of incident responses and making sure that employees and staff are trained to handle when an incident arises. For example, if a person on a surgical table in a hospital setting where the code, then you would want the doctors and nurses to be trained in resuscitation, right
information security response is very much the same. Ah, well documented plan and trained team will make a huge impact.
Identification will be how you determine whether or not you have been breached. The stage relies largely largely on asking questions and gathering relevant information in order to determine the scope and kind of white systems might have been affected by the breach.
The third step containment is to keep the scope of the breacher attack as small as possible.
This could include removing connected devices, updating and patching systems, reviewing remote access protocols, changing user and admin credentials and just general system hardening as well. Anything that could be dying in order to mitigate what is going on with the breach of the attack, etcetera
is going to be helpful in the stage.
Number four Eradication is where the action kind of happens. This is once the issue is contained. The root cause of the breach needs to be explored, and it needs to be removed in all pieces of this need to be removed. Think of it as cancer in your system minutes.
It just every piece needs to be gone, or else it's gonna continue to grow and spread and just disease your system. So, um,
entire removal of anything that is lending itself to the breach or the attack, etcetera is going to be necessary of the stage.
Number five recovery is the practice of returning systems to production and receiving businesses usual once the threat is eliminated.
And finally, number six is lessons learned. This is so important. It's so important to analyze and document what was learned during the breach as well. A CZ to review plans and revise them is needed to make sure that future responses air just as, if not more efficient.
I am a firm believer that something can be learned from every incident response. Rarely is anything foolproof.
And now, for a brief summary in today's lecture, we discussed, How do you seem tools and the importance of which dated a target and one certain types of data are generated.
We also discussed the steps of this incident response process and how it relates to seem tools