Understanding the Beachhead of the Incident

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

5 hours 19 minutes
Video Transcription
Well, can you believe it? We've made it to the final module module six. In this module. We're going to be talking about recovering from a cyber incident.
So we have been through how to prepare an organization for an incident. How Teoh identify your assets and risks how to protect an organization from an incident. How to detect an incident, how to respond to one. And now, finally, how are we going to recover after an incident has occurred?
So the first lesson here, less than 6.1, is understanding. The beach head of the incident,
in the lesson for the objectives will discuss why it is important to identify the beachhead of a cyber incident and will understand the planning and procedures necessary to appropriately restore an organization after a cyber attack
will attempt to determine the entry point, which is often called the beach head of a cybersecurity incident. This is really where the attacker's first landed on a system or a network and where they used as a jumping off point to potentially go somewhere else.
It's normally fragile and not persistent, so oftentimes Attackers will get on to a system that's the beachhead they will move laterally somewhere else, and they may try and gain persistence as they move laterally. But often we see the entry point is not where they spend a lot of their time.
Not always, but
that's usually the case. It's important to try and identify this, though, because it does help answer some of those questions we've talked through already. Let the executives may ask, like, How did they get here? And
who were they and what were they trying to take? What was their motivations?
This may help on. It also may help answer the question of What can we do to prevent this in the future, depending on how they were able to get into your networks or systems
when we restore systems? There's a number of things to keep in mind, and I have seen some bad situations in the restoration process that I'm going to talk talk you through. Hopefully, you don't make the same mistakes.
First of foremost, we want to make sure we're
restoring systems from known good backups. If you remember from previously in this course, I talked about having configuration files and gold images hashed and secured, so we know that when we restore from one of those
known good images, we don't have to worry about those being compromised.
We also want to make sure that I, T and cybersecurity are in lockstep during the restoration process
and you do not want to restore an infection. This is why those three bullets and left go hand in hand. So I have seen in the past where an I T organization was compromised and it wasn't found by cybersecurity. Four months after the initial compromise occurred
in the time period between when the initial beachhead was compromised and then it moved to when they caught it and restored, they had backed up all of that information and even used some of that to create their restore points.
So instead of working together, cybersecurity would say, OK, I think we're clean. I t would restore these backups that they thought were in fact, good to go. But all they would do every single time was restore the infection because their backups were all compromised.
So there's a lot of things wrong with this story and certainly not following best practices. But the reason it's so important to scan for IOC's to develop IOC's and to work with I t is to prevent this very thing from ever happening. So in a perfect world,
you wouldn't want to make sure you conduct coordinated restoration with
cyber and I t. So we should already know our backups air good to go there clean because the process I've already explained we should have them secure.
And when we start deploying them, they should be done in a phased approach. And cybersecurity should be closely monitoring the restoration. And they've already should have put in place alerts within their SIM tool or their other tools that they have available for any notifications for IOC's involved in the incident that were actively working.
So if a new host goes online and that host starts beacon ing to a
an I. P address that's known to be part of this attack, we should immediately get a hit on that and start looking. But that's why we want to go phased. Put a put a couple of systems online, make sure we don't see any of those things happening, but a couple more systems online and continue to monitor it that way.
If in doubt, conduct forensics on your backups have t restore the virtual machine or the physical machine for you. Do forensics on that? Look for those indicators of compromise to see if they're present on the backup
and have those config. Files encrypted and hashed. And the hash is recorded, as we've already talked about previously in this course.
Quick question for this section. The beachhead oven incident can be defined as a where the incident responders go. If they fail at appropriately handling an intrusion,
be the intrusion point for an organization.
See the second device infected after lateral movement.
The answer here is be the intrusion point foreign organization. It's where the Attackers were able to get their first foothold in the investigate or in their incident within the organization.
So in summary, we've talked about why it is important to identify the beachhead of a cyber incident, and we've also talked about the planning and procedures necessary to appropriately restore an organization after a cyber attack
Up Next