Today’s article is all about understanding how to create disaster recovery and incident response plans – very important from security, audit and compliance points of view.
Remediating cyber incidents should start from the basics of creating a disaster recovery plan and an incident response plan.
For any security solutions engineer creating security solutions for clients to improve their security posture is of utmost importance.
The incident response effort helping mitigate incidents in client networks or the security and audit compliance team.
So assuming quick definitions that need to be gone.
So what is a disaster recovery plan?
Disaster recovery plans are exactly what they say they are.
They’re the backbone of a planned, predictable and controlled reaction to a disaster, and mind you, disasters happen. But disaster recovery plans are what makes them less terrifying.
It doesn’t try to overcomplicate a disaster recovery plan.
Their response to disasters applicable to your organization, so don’t try to plan for everything that could ever happen, but plan through it slightly and substitute as needed.
What should be covered in a Disaster Recovery Plan?
DRPS a disaster recovery plan. You will hear me say DRP disaster recovery plan and IRP instant Response plan is accurate.
DRP can be broken down into covering three main topics.
- What to recover?
- Who and how’s being recovered?
- What your recovery objectives are?
Now, the challenge of writing a good DRP is perfectly capturing those in details.
What is incident response?
incident response plan is the systematic and layered approach to how your organization will respond to cyber incidents, whether that be hackers, infections, or just general failures.
IR plans are a lot like your disaster recovery.
The goal of an IRP is to respond to cyber events or incidents, and like a Disaster Recovery Plan, you can’t plan for everything.
So these should include the broad stroke responses that can tailor to situations as they arise.
Incident Response Plan has three main components
- Who is involved?
- What are our objectives?
- And how are they going to be accomplished?
I know that I’ve said these things and I’ve made them seem fairly similar similar.
What is the difference between Disaster Recovery Plan and Incident response plan?
And really, that’s that’s kind of a tough question as the two are intertwined.
But the key difference is actually in the goal of the two separate plan.
What is the Goal Objective of Disaster Recovery Plan?
It’s ensuring business continuity,
What is the goal and objective of an incident response plan?
It is aimed at protecting your sensitive data.
And really, while the two often will follow a similar path to achieve that goal, ensuring business continuity or protecting your sensitive data, that’s really the key difference.
One aims to keep to keep your business operating while the other key aims to keep your sensitive data secure.
Why IR Plan and cyber disaster recovery (DR) program are needed?
Reason #1: The Security audit and Compliance Department
Starting here is an associate auditor.
The most major regulations, GDPR, HIPAA, PCI DSS, required ERP or IRP.
So if you deal with any type of control data, most likely, you’re going to need these kinds of plans.
Reason #2: Client Relationship
But the plan also serves the age or organization and maintaining health and strong relationships with your partners. You can ask questions like:
- What kind of backups do we have?
- How often do we do backups?
- Water are our Recovery Time Objective (RTO)?
- Where are our Recovery Point Objective (RPO) etc.?
But most importantly it’s reality.
Means there’s a famous Robert Muller quote that states that cyber attacks are not a matter of if but when?
DRPs and IRPSs are what prepare you for that when.
That we’ve established what they are and what they need to do that’s already go ahead and start building DRP and IRP.
Creating a DRP
So remember, both of these cover essentially the same base.
Three ideas what how into what goal, right?
That doesn’t mean that they’re really still simple. Building both of these will take a decent amount of time in all honesty, but I’ve tried to to condense them into the major focuses and if work by removing some of the repeatedly.
| Incident Response Plan | Disaster Recovery Plan |
| Define your assets | Define your assets |
| Define importance of your assets | Define importance of your assets |
| Determine your team | Determine your disasters |
| Define events | Define Recovery Time Objective (RTO) and Recovery Point Objective (RPO) |
| Determine SLAs | Determine ‘how’ |
| Create a Guide | Communicate to your organization and its partners |
| Integrate your DRP | Document everything |
| Test | Test |
It it’s more important for your organization to go ahead and establish that for whatever reason.
So as you can see, I’ve already gone ahead and highlighted the similar steps between the two processes, so I’m going to go ahead and address those first two similar steps.
How to create incident response plan?
Step #1: Define your assets
Now when you’re creating a DRP or an IRP, the importance of a thorough asset inventory program really shine.
It’s really hard to define what you need to recover or what you need to protect if you don’t know what it is.
So what do you do?
Complete an Asset Inventory
Take stock of everything and I mean take stock of everything and assess its value.
And then you need to repeat that process.
Don’t have asset inventory be a one time thing?
Review of data importance
Turn it into a program with multiple heads reviewing data to ensure you properly covered everything.
And as a reminder, just a complete reminder here. Everyone has what I like to call the business plans.
An example is someone in HR might not see the need for something like production SQL Server.
To them it’s just a bunch of random uses down.
Or as an IT guy guy might not see the need for something like a sales playbook.
I’ll be honest, I was the IT guy that didn’t see the need for a sales playbook until it became part of my everyday business process.
So, from that you can learn that everybody has blind spots and that’s why asset inventory should include those multiple eyes and a continuous process to ensure that you can capture that in every piece or every asset behavior.
Step #2: Define the importance of your assets
Now there are some key questions to ask here:
- What does this asset do?
- What’s the business value of this asset?
- What’s the impact of losing this asset
- How have I protected this asset?
These questions are a hallmark of determining what IR plan needs to protect and what your disaster recovery plan needs to recover.
Neither plan can be complete without asking these questions.
And in reality, these questions are simply signing value to an asset and are reviewing the protection surrounding the asset itself.
By doing this, you end up defining the most important assets in your environment and where you should focus your DRP or your IRP.
How to determine value of assets and impact?
No, if you’re having problems assessing the value of your assets, that’s perfectly OK.
You can utilize something like:
Baseline risk assessment.
Side note, free insured audit lessen.
The risk is defined as the probability that adverse event will occur and its impact to your business, which is exactly what these questions are asked.
To put it simply, just as what do you think the likelihood is that an adverse event will occur, and how would this affect the asset?
Or more specifically, what is the business impact associated with this? This is how you determine risk.
And once risk has been determined, you can create a risk prioritized plan to really drive your IRP DRP creation.
What simple steps to see why this is a good step?
It’s an accident is at low risk of being affected during a disaster, you don’t really need to plan as much for it. Or if you if you’re at low risk of having that exposed, if an asset is affected, you don’t need a plan so much.
The goal of this risk prioritization process is to free up time that you would have otherwise spent arrived writing an overly complex disaster recovery or incident response plan.
Step #3: Determine Incident Response team
Think back to your assets
When dealing with incident response think about how you need to protect those assets and what needs to be done in the response process.
That’s really gonna be the defining factor of who’s included in your team.
Why? Because once you’ve defined what, it becomes a lot easier to define.
It’s essentially becoming the question of who can do what as supposed to who needs to do what.
And then always remember it’s important to include the leadership in this process.
Ensure you have an app to enable Team who can read your response who can coordinate your effort and who is experienced in the incident response process.
Include third parties in IR plan
A good example of this is if you have data stored in an offsite data center like theologically cloud, you’re going to need to include that team in your plan.
Or if you utilize this specialty or niche application, you should involve their support team.
Step #4: Define Events
Key question:
- What is an event?
- What is an incident?
- What about severity?
So there’s a couple of things that we’re going to need to define right off the bat.
Events happen all the time, right?
Step #5: Define SLAs
And specifically, it’s just an occurrence in your IT infrastructure.
A security event, however, is anytime something may have affected the security of your data.
Security events also happen all the time, but it’s the few that actually expose data or damage or infrastructure that become an incident.
Then the final thing that we’re going to need to define directly is severity, or at least degrees of severity.
Now, this is normally done during impact assessment.
Security Incident Severity Level Classification
Understanding incident severity levels helps in quick responses. Before that, it’s important to identify and prioritize incidents.
An easy example is
Low impact
is going to be defined as severity 1.
Moderate impact
would be a severity 2.
High Impact
Will have severity 3.
It is dependent on your business. You can also break that last category into severity 4 with a severe impact.
That’s entirely up to your business needs and your IT needs.
What you need to do here is state the impact an incident is going to have on your business.
If one person can’t reach the email Will not a big deal that’s going to be considered a low impact,. Whereas if multiple users can’t reach their email, or even worse, you haven’t entirely encrypted mail server, Well, that’s a high impact and thus a higher severity.
You’ve probably realized that we’re building towards is that you can define these few things that you can use these defined severity levels, that security 123, and possibly 4 to create SSL lands, and these are just how quickly somebody needs to begin working or responding to an event or incident, after the alert is made.
For example, if you have a low severity event, don’t go waking somebody up at 2:00 AM, set your Escalade for next business day or 8 to 12 hours.
That way you’re not bothering anybody, routine life, and you’re giving them time to properly adjust while still responding within a fair winner.
Whereas on the other hand, if it’s mission critical like that, mail server has gone down, or you’re seeing an active Cryptolocker in your environment, then there’s no time like ASAP.
That is a 15 minute SLA if possible.
Step #6 – Create a Guide for Scenarios
Now that we have who wouldn’t, how fast the next real thing to do is to create a small plan.
One of the best things to do is to create guides for comment or possible scenarios and then to go through how the team should respond to these scenarios and write down every step.
- Imagine common scenarios
- Use these scenarios to build a guide
- Apply this to both low and high severity cases
- Try to cover all nooks and crannies
- Involve the team
This is going to be the bread butter backbone of your IRP.
When you’re doing this. Make sure you include the easy and the hard stuff. Don’t just do all the set for stuff, and none of the severity will . make sure you do some of the severity 1 and some of the severity 4.
And then once you have that, you can use those guides to deal with a greater breadth of incidents and events ’cause your team can just tweak them as they’re needed.
It guides us through numerous scenarios and incident response is by simply altering it to fit the unique case that’s placed.
A lot of crypto lockers are extremely similar to, Instead of having a response directly for say, Oct 2.0 or NACDA, we can have a response for Cryptolcokers
And also remember to include your team. That way you’re not forgetting those small details within the response process that may be needed.
Step #7 : Integrate your DRP
And now we’re going to start integrating that DRP again. And so here’s where they start to get a little intertwined.
- Your DRP should have the details you need
- Don’t waste time refining what has already been done
Response plans revolve around protecting your data and a lot of times the best way to protect your data is to restore your infrastructure to its base, and that’s why your incident response plan is going to need to incorporate your DRP to some extent.
Now, there’s a big note here. You may not always need to reference your PR and and IR scenario, your disaster recovery plan and its incident performance scenario.
However, it’s a lot easier to reference it when you need it than to read a book or complete work that you’ve already done. If you need to restore a server it’s probably already dictated in your DRP or at a minimum who and what they are going to do.
How to write a Disaster Recovery Plan?
The first step you need to define your disasters.
DRS Step #3: Define Your Disasters
What you’re trying to do here is you’re going to define the disasters or company will face.
I mean, for this think like:
Are you going to experience a hurricane in Montana?
Think of the basics: Displacement, natural disaster and cyber.
Probably not. Are you likely to face natural disasters or cyber incidents? Probably so you need to make sure that you’re including that.
Really, there’s kind of just three major simple scenarios that all DRPs should cover.
A good three being what happens in the case of a natural disaster. This can be hurricanes, floods, etc. Tailor it to fit your environment.
Then maybe one could be over one like you can’t go up to the office because it was a super virus.
Or once again, cyber incidents like a malware infection. Those are the three disasters that you should go ahead and define right off the bat when you’re creating your DRP.
SRS Step #4: Define RTO and RPO.
Just like your answer response plan. You’ve got a few things to define. And in this case it’s your RTO in your RPM.
Recovery Point Objective and Recovery Point Objective
It’s verified your RTO is your recovery time objective, whereas your RPO is your recovery point objective.
In a good way to think about these is to do a little Greek.
Think of your assets and then ask questions.
RTO – think revenue loss vs time
RPO- think data loss and revenue loss
I personally like to defined RTO in terms of revenue Vs and time aka,
how long can I sustain the loss of an asset financially?
Really, this is where the risk assessment process from earlier really comes in handy.
A good example, if you can’t continue business and you suffer major revenue losses from
Having an asset, you may want to have a short party a, whereas in contrast if revenue isn’t at all effective or effective minimally, then it might be OK to have a longer RTO.
Remember,it’s a balance. Just how long can you sustain that loss? Financial?
So you could think of it this way.
And the Recovery Point Objective can also be reviewed in a similar way.
It’s data loss versus revenue loss. For example, if you have a lot of data flowing through your environment, say you have new data entries happening every minute, every hour, every day, and you want you may want to have a short RPO because the loss of that data is going to be a pretty big chunk of revenue.
But if you rarely see data change in your environment, or most of your data isn’t the physical path then you can probably set your RPO for a snapshot for the month prior. In reality, both of these given the respective scenarios, kind of even out to be the same financial impact.
DRP Step 5: Determine How
So we’re going to go ahead and do a little flashback. It’s the IRP’s at 5. Remember your IR team and how you define what needs to be done.
Who was the best to do that task?
And then you assign them roles and responsibilities based on that.
Just in this case, your SLAs are going to be defined by RPOs and RPOs as opposed to severity and impacts.
DRP Step #6: Communication To Your Organization/Partners
You need to ensure you communicate in roles and responsibilities to the staff involved in the process, but also make sure everyone is aware that there is a process that they too will play a part in if disaster occurs.
Just a reminder, everybody in a disaster recovery scenario does play a part.
Then once again, make sure you involve your partner organizations.
Like cloud or that niche specialty app.so that they can properly support their DR process.
And finally, get C-Suite or leadership by adding a member of the C-Suite champion. Your DRP will aid in ensuring that the DRP is effectively incorporated into your organization and that you receive organization abide by it.
If it’s just some side task that a small team of individuals is trying to champion, it might not good so far but if you have somebody on the speed, like a CEO or CEO, champion it or even better as CS CIS over CS, so then it’s probably going to facts and everybody is going to be able to.
And then finally, once again, the auditor shining through ERP steps has been documented, everything.
And really, you need to ensure that you can properly address all actions taken in your three scenarios.
The definitions that you’ve made within those scenarios, the RTOs andRPOs as they apply to those scenarios.
Who’s doing what for each disaster scenario, and then finally, you’re gonna need to sign off.
Your DRP can take it back until it’s signed off by the person responsible for affecting the DRP itself.
Finally, Test, Test and Test
An IRP and then DRP without testing, it’s just a sheet of paper.
Source: Logically
