Posts

Charlie Waters
, ,

Business Continuity or Else! A Practical Guide to Developing a Business Continuity and Disaster Recovery Plan

A continuation of sorts…

Credit: N. Hanacek/NIST

As we further consider the elements of the NIST CyberSecurity Framework (CSF) from Michael’s multi-part series, it is helpful to perform a deeper dive into the ideas of Respond and Recover (the last two elements of NIST CSF). If you haven’t read that series, you may want to check that out first: https://choosetcs.com/2022/01/19/nist_csf_guide/.

Business Continuity spans both Respond and Recover while, as its name suggests, Disaster Recovery is the plan to be used in the “worst day ever” type scenarios and lives in the Recover CSF category. Before we go further, I want us to stop for a second and nail down some basic terminology. You may be thinking at this point, “What is the difference between Business Continuity and Disaster Recovery?” Glad you asked. We often hear these used almost interchangeably, but they are distinct concepts. Even so, they are somewhat like peanut butter and jelly as BCDR is to PBJ. We think of them as one thing. Using the definitions from FEMA, Business Continuity as “The ability of an organization to provide service and support for its customers and to maintain its viability before, during, and after a business continuity event.” Further, it defines the Business Continuity Plan as “Process of developing and documenting arrangements and procedures that enable an organization to respond to an event that lasts for an unacceptable period of time and to return to performing its critical functions after an interruption.”


And since we will later address Disaster Recovery, let’s consider the following definitions. A Disaster is “A sudden, unplanned calamitous event causing great damage or loss. In the business environment: any event that creates an inability on an organization’s part to provide essential products and/or services for an indefinite period of time.” And a Disaster Recovery Plan is defined as “The management approved document that defines the resources, actions, tasks, and data required to manage the technology recovery effort.”

If you are a regulated business, you must have these plans in place. If you are non-regulated (does that even exist these days?), you would be well served to have these plans in place anyway. Increasingly, TCS is seeing these requirements called for in underwriting Cyber Insurance policies, so this and other security & compliance risk reduction measures are not viewed as optional in today’s cyber threat landscape. And unless you are just looking for a different career path altogether, we cannot emphasize enough the necessity to invest the time to get this right. The oft quoted statistic of “40%-60% of small businesses never reopen after a disaster” applies here.

The first step in solving any problem is recognizing there is one.

Your organization is at risk and you may not even know it. Do you have an up to date and tested Business Continuity Plan? If not, you may be missing critical details to keep your business running through a disaster. This is not a technology problem and is not the responsibility of your IT department (on staff or outsourced). This is a strategic imperative which much be owned from the top down. In short, it’s a business problem and risk reduction initiative.


The good news is if you are reading this, you are most likely not trying to restore order from chaos due to a disaster. But this doesn’t mean you should be comfortable with the status-quo. The calm BEFORE the storm is the best time to prepare. We often don’t see the disasters coming miles ahead.


TCS is not only experienced in developing and testing these plans, but in managing its clients through the worst possible events that can easily cripple a business – pandemics (we’ve got the t shirt), ransomware/crypto locker (check), server room floods, power outages, you name it. And believe it or not, you don’t have to reinvent the wheel to put your plan together. That said, your plan will not be cookie-cutter and must address your specific requirements. TCS recommends taking advantage of our Compliance as a Service (CaaS) program to provide fixed-fee consulting support for this and other regulatory compliance needs.


Whether you engage with TCS or do this yourself, be sure to allocate regularly scheduled time week over week. This is not something that will be assembled in a day and the effort will become part of your ongoing business process, not simply a dusty document in a binder on the shelf. It could take a few months the get through this the first time, but the important thing is to make steady progress and not think of business continuity planning as a box to check. It will be an iterative process and you will revisit, test, and update the plan at least annually. So put on a pot of coffee, roll up your sleeves, and let’s go.

I’m from the Government, and I’m here to help!

DHS has a government produced Ready.gov site with a useful Business Continuity Planning Suite.  It can be downloaded here: https://www.ready.gov/business-continuity-planning-suite.  When I first found this tool my thoughts turned to the famous President Ronald Regan quote, “The nine most terrifying words in the English language are, ‘I’m from the Government, and I’m here to help.’” In this case the government is quite helpful.  This is a simple and effective tool and my next few articles will walk you through the process of developing your own Business Continuity Plan.

Now you could stop reading here and simply follow the steps outlined in the software.  It’s actually a straightforward, but lengthy, process, so plan to do this in bite-sized chunks and not all in one week.  The more thought and consideration paid to your business functions/data, personnel, and technology, the better aligned your plan will be with your needs when things hit the fan.  This series of articles will highlight where to slow down and pay attention and where shortcuts can be made.

There Is No “I” In Team

The steps for building your own Business Continuity and Disaster Recovery plans will be covered in more detail in upcoming posts.  A good idea for now is to assemble a small team for developing your plan and then you can divide and conquer the various tasks which we will outline later.  Also, a smaller organization will end up with more overlap of roles and fewer teams defined within the plan, but to get things started, a small group with an Executive/Owner sponsor should lead the effort.  This is a top-down strategic (company-wide) initiative and not something to be led from your IT group.  They will be instrumental from an operations standpoint, and will need to be involved in development and (ultimately) executing the plan, but they will not have a complete view of your organization’s priorities, critical functions, and workflows. 

Next week we will move on to installing the tool and familiarizing ourselves with the application so we can start making progress on developing the plans.

/by
m.a.collins
, , ,

Respond – The Fourth Function of CSF

Krakenimages by Shutterstock

The next logical step in the NIST CyberSecurity Framework is Respond.  In other words, how are you planning to respond when a threat to your organization is detected or realized?  The Respond function essentially sets forth the processes and procedures enacted for incident response, who will own the issue and oversee its execution, who will be engaged to perform the forensics to determine how the threat gained a foothold in the environment, and what steps should be taken correlative to the risk inherent to the threat.

There are four aspects to the Respond function of CSF:

1. Response Planning

The goal in response planning is to enhance your business or organizational resiliency.  Here are some scenarios to consider that we hope would never occur but are likely enough to consider for planning.  We’ll start with a very likely incident.  What happens if your company loses power?   How long can the company network sustain a power outage before it becomes a critical incident?  What would happen if your major Cloud provider (Office365, QuickBooks Online, Kronos, etc.) went offline for a month or longer?  How would your organization respond?  Do you have a Business Continuity plan to cover instances like that?

How would your company be affected by a fire, flood, or tornado?  Would your clients and branches be able to maintain communications and business basics?  Do you have a Disaster Recovery plan that can cover that?

Of course, some these issues are tertiary to cybersecurity – they impact cybersecurity but may or may not be directly related.  What happens if an employee is tricked into opening an attachment that introduces ransomware to the entire network?  Or, what happens if one of your security controls indicates a persistent attack from a particular source? What happens if a disgruntled employee attacks the network from within the company?  Who is notified, who is responsible for mitigation and remediation, who needs to be alerted and when?  What is your Security Incident Response plan?  These are all things you need to consider.

Smaller organizations have the benefit of being able to pivot quickly and adjust to unforeseen situations.  Larger organization require more thorough planning to survive and adapt to such events.  However, we all know that planning ahead of time makes these situations less stressful and easier to overcome.  If that weren’t true, EMA and the Military wouldn’t invest so much time in training and preparing their personnel for disaster response.  Be sure your response planning includes Business Continuity, Disaster Recovery, and Security Incident Response plans.

2. Communications

This article has already hinted at communications, but it is the key to overcoming any crisis.  Technology can help us here, since we all have a smartphone in our pockets; but how will you leverage those technologies in response to an emergency?  What do your personnel need to know and expect when normal avenues of communication are not an option?  How will you respond in such a way to maintain business as usual while not destroying evidence necessary for the authorities to forensically investigate the incident?  Who is going to notify the authorities and what authorities should be notified?  How will your clients get in contact with you?  How often will you test these plans to ensure you aren’t overlooking a critical roadblock?  When do you need to contact your cyber-insurance provider?

There are a lot of questions to consider, which is why leadership must make it a priority to plan out these scenarios.  Attempting to make these decisions on the fly will generate incredible chaos and likely will miss better options that would save the company time and money.  There are a lot of moving parts to cybersecurity incidents, and the more you plan before you need them, the better your organization will weather the storm of an attack.  Defining who communicates with whom and by when will mitigate a lot of unnecessary stress and chaos.

3. Analysis

It’s difficult to talk about one aspect of Response without alluding to others.  We’ve mentioned forensics already, but forensics needs to be planned for in the communications stage of an incident response plan.  Additionally, forensics needs to be performed and executed. 

If you have a cyber-insurance policy, today’s policies often cover forensics up to a certain amount.  Depending on your insurance provider, they may want you to notify them (communications again) before doing anything; because they want to ensure the proper authorities are involved before you make changes that will negatively impact their ability to forensically identify how the attack occurred, who was responsible for it, and what can be done to mitigate that threat in the future.

If you have an IT department, you need to have some means for them to perform their analysis from a read-only snapshot archive.  This enables analysis to be performed without tampering or contaminating digital evidence.  This is where your Protect function comes into play.  Those enhanced logging and archiving measures developed and implemented will help both internal and external sources get to the bottom of the issue.

4. Mitigation

Finally, once you’ve identified various threats, it is important to have a plan for isolating those threats from doing any further damage to your organization.  For instance, TCS has the ability to immediately isolate a computer from the network as soon as ransomware is detected on it.  This effectively enables us to limit the threat exposure to our clients, but ransomware is only one of many threats to our clients.

Different kinds of threats pose different mitigation complications depending on the type of threat.  Planning ahead to determine how different threats can be isolated and contained as quickly as possible will help you recover faster with less negative impact to your organization.

Conclusion:

As you can see, the further we get into the functions of CSF, the easier they get.  All that front-loading work at the beginning to identify the various types of threats, perform risk analyses, implement protection measures, develop policies and procedures for how personnel will perform critical tasks, makes it much easier to respond to emergent issues.

That being said, there are a lot of moving parts to the incident response plan. If you find that you are overwhelmed by the magnitude of incident response planning and need some consulting or even compliance assistance, please reach out to TCS today!  We’d be honored to help you work through these issues and have the best plan possible for your organization to weather just about any storm short of a zombie apocalypse.

Note: This article was based on the resources available at https://www.nist.gov/cyberframework/respond

/by
m.a.collins
,

Detect – The Third Function of CSF

Thinkstock

Continuing our series of the NIST CyberSecurity Framework (CSF), we now come to the Detect function.  The Detect function is the simplest and most straightforward function within the CyberSecurity Framework.  The work of this function is to create an Information Security Continuous Monitoring (ISCM) program.  The NIST 800-137 publication is helpful for explaining the best process for creating and executing an ISCM for your organization.

Here are the six steps to building an effective ISCM as outlined in that document:

1. Define the ISCM strategy

A proper ISCM starts with the leaders of the organization.  If the leaders do not take security seriously, it’s likely that no one else in the organization will see it as important either.  What does it look like for leaders to take security seriously?  The best way is for leaders to inform and shape the narrative of what information is important to the organization, what levels of risk they deem acceptable and unacceptable, and to engage with management and IT to develop appropriate risk governance policies and procedures to protect the organization. 

Simply put, the leaders define the key performance indicators (KPIs) for security, along with the policies and procedures necessary to ensure the best outcomes possible with relation to those performance indicators. Naturally, the leaders will leverage input of from the rest of the organization to help them in this strategic process, but the responsibility of defining these key security performance indicators and governance policies falls on the leadership itself.

Here is a helpful diagram from NIST 800-137 illustrating how the entire organization should be involved in this process:

Figure 2-1. Organizational-wide ISCM from NIST 800-137

It’s important for the leaders of the organization to view the ISCM as an ever-evolving approach to securing the organization.  Subordinates (Tier 2 and Tier 3) should regularly report back relevant data to the leaders (Tier 1) of the organization, so that policies and procedures can be updated for better efficiency, accuracy, and effectiveness.  The security posture of the organization, thus, should improve continuously over time.

2. Establish your ISCM program

Once the leaders of the organization define the ISCM program, managers (Tier 2) of the organization should leverage tools to automate the data collection and sort data into digestible formats for review.  The aim here is to develop the mechanisms by which data will be collected (automatically and/or manually) and how often that data will be reported back to the leaders of the organization. The leaders should maintain some sort of dashboard to actively monitor the key security performance indicators, so they are aware when security-related events are occurring within the organization.

Once managers establish the tools and mechanisms for monitoring and maintaining security KPIs, then they should define the metrics for how often IT will monitor and assess the data, how often that data gets updated to the leadership of the organization, and how often the mechanisms will be reviewed for best results.  Finally, checklists for IT should be created to ensure that IT is following the policies and procedures defined by leadership.

3. Implement the ISCM program

Implementation simply is executing the plan and program established in Steps 1 and 2.  This should be performed in a checklist format that is consistent with the strategic policies and procedures defined by organizational leadership.  The IT representative should sign and date the checklist to inform management who performed the work and when.  This provides assurance and accountability for implementation. 

4. Analyze and Report the findings of your program

The first data collection serves as a security baseline for where the organization is currently.  Comparisons back to the baseline over time can indicate when abnormal activity or changes are occurring within the organization.  Gradually, the baseline can grow to become more informative.

As abnormalities appear in the reporting and analysis process, those findings are submitted to authorities according to the defined policies and procedures for them to make decisions regarding the risks associated with that abnormality.  Early on in this process, there can be a lot of noise generated; but as the reporting and analysis window grows, IT can identify abnormalities with greater accuracy.

5. Respond to those findings

Knowing how to respond to security events is more of an art than a science, because every environment is different.  Every organization, even within the same industry, has a different approach and perspective on risk tolerance and mitigation.  The policies and procedures created in the strategic phase of the ISCM will guide IT on how to respond appropriately to security events. 

There will be times when a security event exposes a weakness overlooked in the initial strategic planning process.  This should be expected.  Technology is ever-changing.  Hardly ever is the first attempt perfect.  There is not a perfect approach to security, so when a weakness is detected, avoid the temptation to point fingers and assign blame.  Then, proceed to step 6.

6. Review and Update your ISCM strategy and program

As stated above, going through the exercises of analyzing and reporting will inevitably expose weaknesses in your ISCM.  The important point here is that the organization is growing and maturing with relation to its security posture and awareness.  What are new ways to detect abnormalities which would be more efficient?  What new ways has IT discovered to monitor for security-related abnormalities?  What new policies and procedures could be adopted to mitigate the associated risk of this new weakness?  These questions, and ones like them, can help you refine your ISCM over time.

Here is another helpful illustration from NIST 800-137 for how this process should look:

Illustration 3-1. ISCM Process from NIST 800-137

Conclusion:

Creating and performing an ISCM is something like learning any new skill. It will take a while before you become adept at identifying security risks within your organization and mitigating them to an acceptable level.  At first, it can feel awkward, and it’s easy simply to procrastinate.  The important thing is that you start and stick with it. Over time, you will grow and become more adept.

Sometimes, it’s helpful to have someone assist you in these exercises.  That’s where TCS can help.  We support and manage security for various regulated industries (health, finance, defense, local government, and beyond).  We use that collective experience to create a unique, client-focused approach to security.  TCS can work with you to grow your security posture over time by road-mapping solutions on a scheduled timetable and performing routine security assessments both to demonstrate your past growth and effectively plan for better security where weaknesses are identified. Contact us today, if you would like to know more about how TCS can assist your organization with its cybersecurity needs.

Note: This article was written from resources found at the following site:  https://www.nist.gov/cyberframework/detect

/by