Preparation inside of our networks is a key for determining or for incident response.
We need to understand that the key concept of preparation is preparing for the worst case scenario.
We often see this in different aspects of policies and procedures, but the technical and non-technical
steps we take now could save us a lot of time, effort and energy, as well as costs for future problems.
Preparation is truly key in our security industry.
An Incident Response Plan, or IRP, serves as a central document for managing the entire incident response
process within an organization.
Its policies outline the requirements for the plan and assigns roles, responsibilities, and typically
remains concise.
Establishing an internal governance necessary for building the incident response capabilities within
our organization.
An incident response plan should be broad enough to where it impacts the entire organization as a whole,
identifying key roles without identifying people.
We want our IRP to say the director of blank or this technical department does this, or you get the
picture.
We won't want to identify that.
John Smith, the director of engineering, is going to do this.
That sets us up for failure and is broad enough in scope yet singular and notion to where we can quickly
identify the person or persons responsible within the incident response plan to accommodate for what
we're trying to achieve.
It's important that the process developed during the incident response plan is communicated properly
and deemed to be vital and executing effectiveness and the incident response teams at a variety of team
members and stakeholders involved to ensure that it's adequately.
We're providing the specific needs of the industry or of the enterprise environment.
This makes it more manageable, it has more effective communication processes, and it's best to have
an internal and external stakeholders involved throughout the entirety.
Effective internal communication is critical and often facilitated through a command center.
This serves as a hub for decision makers and stakeholders and provides updates and feedbacks to response
activities.
If you're in the middle of a disaster recovery plan and your workers don't know whether to communicate
or to facilitate communication transparently, that can lead to some real problems during a hurricane.
One time, I was out in the middle of the field fixing telecommunication equipment, only to find out
that there was no command and control infrastructure in place that I was aware of.
I contacted my manager, but obviously his cell phone didn't work.
I had to call all the way to Georgia, only to find that Georgia had no idea what I was talking about.
All they knew was that half our systems were offline and they had no idea what was going on.
Having an effective communication and command and control outline for internal communications is paramount
to making sure that we have an incident response plan focused with precise Communication.
We also have to have alternate communication needs because of that problem that we faced during that.
During that telecommunications issue, we were all assigned satellite telephones with known command
and control lines that we could communicate up the line if one of the, uh, one of the tracks of communication
were no longer available.
We need to have external communication both during the incident response and after the incident response.
And this needs to be managed by trained professionals to avoid misleading information and ensure compliance
with regulatory bodies.
Again, while I was with the telecommunications industry, we had a problem where telecommunications
and 911 services weren't operating properly that needed to be properly communicated via external communication
up the line, so that the FCC was aware of our issues.
We had a fiber line cut one time between Phoenix and Flagstaff, where served all the communication
needs for northern Arizona.
The FBI needed to be involved as well as some other agencies to investigate the problem.
However, as a member of the telecommunications industry, we were responsible for actually fixing the
issue.
Those external communications need to go through the right offices at the right time to report properly
for compliance and regulatory needs.
Training is often overlooked and is the groundwork for effective response.
Regardless of where it's coming from.
You need to understand that it's not enough just to have an incident response plan in a bookshelf somewhere
collecting dust.
I can't tell you how many organisations I've been with where I go in through the onboarding process,
and I'm looking around and they're like, oh, read all these documentations about our different policies,
but there's no incident response plan on file when you finally ask for one, it's pulled out of some
shelf out in the middle of nowhere, and no one even knows what you're talking about.
It hasn't been updated in over a decade.
This is quite often a problem, especially with large enterprise environments that don't have a lot
of incidents occurring throughout the years.
And in many cases, non-technical staff make up the majority of an organization, and invariably these
users will be the ones who are exposed to the signs of potential security incidents.
We need them to be aware of our security incidents and how to evaluate or how to report those incidents
up.
It's not unforeseen for a user to click on a phishing link, and as soon as they click on it to realize
they made a mistake, it happens all the time.
We need to be aware of those issues and train them properly so that they can report up the chain and
effectively communicate that they actually screwed up, and we need to fix it.
It's far better for an employee to report it right away than for us to get it after the fact 3 or 4
days later, because our systems weren't picking it up properly, and incident response plan must be
tested and it must be tested at least annually throughout your entire organization.
This is critical for developing proficiency and dusting off the book to make sure that everything is
up to date, that the organization hasn't changed since the incident response plan was put into motion.
We need to provide exercises to evaluate the plan, the procedures and the personnel readiness, and
these exercises should include document reviews to make sure they're set up properly.
We should be able to do tabletop exercises where the team gets together and they simulate responses
to hypothetical situations.
We can do walkthroughs where participants familiarize themselves with response steps and roles without
involving the actual equipment or data.
And finally, we can do full scale exercises where we literally shut down machines to see what happens.
When I again, when I was in telecommunications, we would often shut off a power to a facilitating
site to see if the generator would kick in.
And we were required to do this for some sites at least every 30 days.
If the generator failed to kick on, our battery backup system should, if they didn't kick on the site,
would just go dead.
But you get my point.
We sometimes need to do a full scale exercise to ensure that everything is working properly and the
way that we identified it or managed it.
Disaster Recovery Plan, or a DRP, is a structured approach aimed to swiftly restoring IT systems,
data and infrastructure.
Post a disruptive event to minimize downtime and maintain business continuity.
We're going to talk about a business continuity plan in a second, but you need to understand that a
disaster recovery plan is not the same as business continuity plan.
Well, yes, a disaster recovery plan can be utilized in a business continuity plan.
A disaster recovery plan is of its own making.
This identifies the different recovery strategies that we can utilize, how we can utilize different
resources, and acquisition of parts and even labor if needed.
Once we've identified a disaster recovery plan, it goes through a risk assessment identifying the different
risks that we expect to see within our own environment.
When I was in Phoenix, Arizona, we weren't worried about hurricanes or tornadoes.
It wasn't something that our disaster recovery plan really planned for.
Yes, there was a side note in there that basically said we would follow the overall arching plan that
the organization had set forth, but I can't tell you the last time we actually looked at that plan
because we haven't had a tornado or a hurricane ever in Phoenix, Arizona.
However, one thing that we did have was a heat disaster recovery plan.
We identified very strategically if the temperatures inside of our internal server room reached a certain
temperature and the systems did not work properly, the exact details of what we were supposed to do
in that event, and we went through the entire process on a day to day basis, especially during the
summer, to make sure we were aware of those plans.
I remember every May before the summer started to get really hot, that we would make sure that our
AC repair guy was on the line and realized that our SLA was one hour for specific sites.
We need a business impact analysis.
What is the impact of this critical function going down?
If I have an interior server room going down, the impact could be very high.
We need to understand the business impact and identify which prioritization takes precedence in a real
disaster.
If you have a hurricane hitting Florida, there's going to be certain points that are more important
and have a higher priority because of business impact than others.
It's just a matter of doing business.
We need to have recovery point objectives.
What if this happens?
How often should we or how soon should we recover from this issue?
If I have a hurricane in Florida, we expect the server room to go down.
How long should it stay down before we go over and and fix the issue?
That's a recovery point objective.
We need to have data backups and recovery in place.
When I say data backups, what I'm talking about is how often do we backup our systems.
Sometimes those backups are nightly, sometimes they're weekly, sometimes they're monthly.
It really depends on what data we're storing and how important that data is to the system overall.
And how do we recover from that data.
We've gone over this in Security+ many, many times, so I'm really not going to go that into depth
with it.
Just understand that data backup and recovery is a real thing when it comes to disaster recovery.
We need to have response procedures and reduce allocation or resource allocation if something occurs
within our systems.
If I have a hurricane that's expected to hit the Florida line.
I need to have resources on standby to fly into Florida if flooding takes place.
How are those resources coming to play?
How am I going to get those resources if the roads are closed down?
What happens if air flight isn't available?
The overall resource allocation needs to not just be assets, but people.
They need to be identified ahead of time.
If Florida is going to get hit by a major hurricane, it's not behooves us as an organization to say,
hey, let's pull from Alabama and Georgia, maybe even New York or Phoenix to facilitate having more
resources on the ground to bring those systems back online sooner rather than later if something were
to occur.
And finally, training.
We need to understand that people need to be trained.
Nothing's worse than having a bunch of professionals that have no idea what they're doing, even though
in a normal day to day occurrence, they would have no problem operating at peak performance.
Training is vital to make sure that people know what they're doing, who they're communicating with,
and what their expected actions are.
In a disaster recovery.
Are we expecting people in the Florida area to come into the office next day?
I was an organization to where if we had a disaster, an environmental disaster take place, we were
required within two hours to call into an 800 line to let the company know that we were available and
that we were safe.
Once they identified that, they'd maybe hit us up and say, are you able to come to work?
That was part of our training and our response plan.
I was further responsible for many disaster recovery aspects, in which case, if something occurred,
I was expected to go fix the issue and be able to stand by myself without direct communication within
the department and fix any various issues that I may identify.
This is part of our disaster recovery plan, and you need to be trained properly to be able to take
those actions.
What are you allowed to do?
What aren't you allowed to do, and what are your expectations?
A business continuity plan refers to an organization's ability to continue its essential job functions
and operations during and after any disruptive incident or crisis.
This isn't just a disaster.
We're not talking about hurricanes or tornadoes.
This could mean a terrorist attack.
It could mean the servers drop off air because of a patching problem.
It can mean any number of things, but a business continuity plan is very broad in its scale, but details
very specific incidents that are occurring.
Within that we could see notions of technology failures, cyber attacks, or even disasters because
disaster recovery is part of business continuity.
While disaster recovery plan is specific to disasters.
A business continuity plan is more designed around an overarching structure.
We can use a lot of the same resources that have been allocated for a DRP within a business continuity,
with the expectation that both aren't going to occur simultaneously, and this happens quite a bit.
However, the main goal of a BCP is to minimize downtime and protect the organization's reputation and
thereby its finances.
We need to maintain consumer confidence and ultimately ensure the organization's survival.
If it's faced with an adversity action.