m.a.collins
, ,

Recover – The Final Function of CSF

Blue Coat Photos - Flickr

In wrapping up our series on the NIST CyberSecurity Framework (CSF), we come to the final of the five functions – Recover.  Just like the rest of these functions, the Recover function involves creating policies and procedures around recovering from a cybersecurity event.  In other words, when a cybersecurity event happens within your organization, how will your team restore normal operations?  The goal is to have a recovery playbook before an event occurs, so you can recover quickly and efficiently without stepping on forensics.

Having performed the first four functions, you’ve done most of the legwork already.  As such, your Recover function’s success will directly correlate to how well you’ve identified mission-critical resources in your business (Identify), defined how you will protect them (Protect), defined what mechanisms you will put in place to detect threats (Detect), and how you will respond to various threats (Respond) when they occur.

There are four steps to fulfilling the Recover function of CSF:

1. Planning for CyberSecurity

In the planning phase, it’s helpful to think about your company or organization in terms of function.  For instance, most companies have communications, production, administration, operations, etc.  By breaking down the company into those categories and subcategories, it’s easier to plan for recovery for each category.  This will also help you identify which personnel need to oversee the various categories of Recovery.  Naturally, a smaller organization may only have one or a small handful of people.  Larger organizations will want to be specific regarding which personnel have access and control over appropriate Recovery controls.

Due to the sensitive nature of the Recover process, you must take care to keep those plans and procedures confidential only to those who are responsible for implementing recovery procedures in response to events.  You don’t want your recovery procedures to get into the wrong hands only to have them work against you in the middle of a crisis.

Once you document your plan for recovering each function, and who will own the recovery process, your users will have an easy-to-reference guide for how to start recovery procedures.  Did the cybersecurity event impact communications?  If so, then proceed here.  Did it impact production?  Then proceed there.  Management should catalog these categories of business by priority, so the recovery plans and procedures leave no question regarding order of importance.

2. Commit to Continuous Improvement

While it’s important to be as thorough as possible on the first run, you must see the Recover function as something that gets refined over time.  Not only will your company and organization leverage new technologies to fulfill the mission of the organization, but you are likely to miss or overlook a critical procedures on the first few attempts. The best way to overcome this is to schedule times when your organization will focus on reviewing your recovery plans.  Maybe you can incorporate reviewing those plans in your regular admin meetings.

At TCS, we often refer to a client’s operational or security maturity level.  That should be how we approach security.  There is a maturation process that occurs with time, as business owners and managers grow in their understanding of threats and how best to perform all the functions of CSF.  Performing security drills to simulate common threats is helpful for learning where gaps exist between where you are versus where you ought to be (or even thought you were).  Then, plans can be made to close those gaps over time.

Here is a helpful illustration from NIST 800-184 regarding how the Recover phase helps inform and refine the previous functions of CSF:

Figure 3-1: NIST SP 800-184 Guide for Cybersecurity Event Recovery Relationship with the NIST CSF

3. Define Your Recovery Metrics

Recovery metrics are helpful for framing business resilience discussions.  One of the primary metrics is Recovery Time Objective (RTO).  How much time can your company afford to down without causing significant negative impact upon the business?  Testing those recovery time objectives will be key to determining if you have the right solutions in place.

Another metric with regard to data recovery is Recovery Point Objective (RPO).  While the Protect function should have already defined this, your Recovery drills will identify if your desired RPO and RTO are achieved by the technologies you are currently leveraging to minimize them.

Another example of a recovery metric is one that we hope we never have to confront – the point of no return.  At what point will your system be so compromised that it is beyond recovery?  When should you forklift the system and start over?  Defining that point could be the difference between surviving an event and completely folding.

Finally, what Service Level Agreements (SLAs) and Insurance policies do you have in place to protect your organization?  Where would one go to get that information?  Is it organized and catalogued into a single, accessible location?  Who has access to that location?  Who is responsible for ensuring SLAs are being achieved?  Is that data being reported to Management on a regular basis?  These are all questions you need to consider regarding recovery metrics.

4. Build Your Recovery Playbook

The Recovery Playbook is the result of all the Recovery planning.  Here is a summary of the tactical recovery plans that should be included in your Recovery playbook:

  • Defined mission-critical company assets (both personnel and technology)
  • Categorizations of all assets and their interdependencies
  • Identification and documentation of key personnel responsible for overseeing the recovery process
  • Protective measures to ensure an effective recovery, including how to identify the root cause of the threat to ensure false assumptions are not overlooked
  • Defined conditions under which the recovery process is initiated and by whom
  • Tactical plans for restoring in a clandestine way that doesn’t give away information to the adversary or destroy critical evidence
  • Examination plans for how the threat will be addressed by the appropriate personnel
  • Vetted and tested recovery capabilities
  • Scheduled time post-incident (as immediate as possible) to document lessons learned and how to better protect against similar threats in the future

Any time gaps are identified, either in response to a threat or in response to a simulated threat, you should update your Plan of Actions and Milestones document (PoAM) to determine how best to close those gaps and create timetables by which those gaps will be closed.  Performing a hotwash immediately following a security event will ensure key details concerning the threat will be considered in the PoAM.

Conclusion:

As you can see, there are a lot of details and moving parts to the Recover function.  The planning will not be wasted time, though, especially if your business were to face a significant security event.  The goal, though lofty and unobtainable in today’s world, is to go through these exercises to eliminate (best case) all security incidents or (most likely) mitigate them when they do occur.  The time invested in these exercises of planning and documenting could very well determine whether your organization survives when an event occurs.

If you should need assistance with any of these security efforts, TCS would be honored to assist you.  Please contact us today, if you would like to discuss how we can bolster your security or operational maturity levels.  We can also help provide a second opinion regarding your current efforts to help you identify gaps to schedule on your PoAM document.  Either way, TCS would be thrilled to assist in any way possible.

Note:  This article was based upon the NIST 800-184 special publication.

/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