Security Framework Assessments: Interpreting Your Results
Authors: Mark keppler, steve foretCybersecurity Frameworks Series, part 10
Should your organization use a recognized cybersecurity framework such as NIST CSF, ISO27001, or another? I really can’t think of a good reason not to. Now, that’s not to say that security frameworks are a cybersecurity panacea—they aren’t. Nobody should think of a framework as a guarantee that your organization won’t be breached or that your organization will embrace and operate in a secure manner.
Most readers of this blog know that cybersecurity frameworks are a set of practices recommended by industry experts that will make your organization more resilient to attack and better able to respond if you are attacked. Some organizations base their program on a framework such as NIST CSF, NIST 800-53, or ISO27001/2 but others may try to align with a regulatory compliance framework such as PCI or FFIEC.
Framework Assessment
For organizations that align to a framework, periodically self-assessing controls against the framework is a worthwhile exercise. However, at times we are asked to conduct a security framework assessment against NIST CSF for organizations to either benchmark where they are in the process or support a fresh start for those who have not based their program on any cybersecurity framework.
The most current and frequent reason for these reviews is that the Board of Directors asked for an independent opinion on cybersecurity. Boards are hyper-focused on cybersecurity (and rightly so) but often do not have the background or experience to know the state of an organization from a short Board of Directors presentation.
To go even a step further, many Boards also do not understand how to interpret the results of the assessments that are presented to them. This is understandable and it is our job as security professionals to effectively communicates in common sense terms the current state of cybersecurity to the Board and Senior Management.
Assessment Scoring
As an example, we’ll take a look at the NIST CSF, as it the most commonly requested framework to assess or benchmark against. If you are reading this article, you may know that there are six main functions of the CSF and each function has categories with requirements in each category. (If you don’t know that, check out our earlier entries in this series.) An assessment will often provide a functional score of how well an organization meets the CSF requirements. The score is based on NIST’s four implementation tiers:
Tier 1: Partial (Reactive, Ad-hoc, very little cybersecurity risk awareness)
Tier 2: Risk Informed (Threat aware with policies, tends to be decentralized/informal
Tier 3: Repeatable (executive approval, benchmarked (industry), business integrated)
Tier 4: Adaptive (heavy regulated, tuning [policy, tools, teams], automated response)
This is where the confusion and various interpretations start. The reader of a security framework assessment report needs to understand and consider that most organizations are not (and should not) be aiming for the highest tier level. Does a mid-sized manufacturing company need the same level of security as a Fortune 500 financial services company? Clearly not.
For many SMBs, targeting the highest tier (4) through all domains would be difficult to achieve (impossible at current spend and staffing levels) and the cost may outweigh the benefit as a value proposition.
The right tier for your organization is a risk-based question. How much personally identifiable information do you have? How much HIPAA-related protected health information? What is the impact of a breach on your business (in terms of downtime and customer / revenue loss)?
When conducting a NIST CSF assessment, always ask what the goal is and what tier level the organization is targeting. Often, this is not defined. A baseline score of repeatable security processes (Tier 3) is a good goal and result for many organizations.
It also can make sense for an organization to decide on one tier for one set of controls but decide on a different tier for other controls. For example, if an organization prioritizes availability but does not have much personally identifiable information, it could make sense for that organization to shoot for the highest level of backup and redundancy but not implement the top tier of data loss prevention controls.
The main takeaway is cybersecurity teams do not determine these tiers in a bubble but include various leaders throughout the organization (technology, audit, legal, HR, business) to ensure that risk is understood and communicated for consistent awareness.
Beyond Scoring
What boards really want to know from a security framework assessment is simple. How are we doing on cybersecurity? Are we going to be okay in the face of an attack? These are reasonable questions to want to answer, but can a security framework assessment really give you that answer? A cybersecurity framework is an overview and comparison of how well security practices have been designed, operated, managed, governed, and reported with a clear and valuable message compared to their own progress, industry peers, and more.
Scores will tell part of the story. You may also have identified opportunities (gaps) and recommendations to enhance the program. The opportunities should provide a root cause of the issue that may include people, process, and /or technology issues. Did a lack of technology tools impact our score? Do we have enough people? Do we need additional training? Outside resources? Are we well integrated with or have champions in other departments?
Along with opportunities and recommendations some level of risk is presented in the assessment. There should be a “so what?” in the assessment to clearly communicate how the Board / Senior Management can help the Cybersecurity Program, expected benefits of recommended actions, and the ramifications of inaction.
We have experienced, in board and leadership meetings, that when budget or funding is not obtained, it tends to come down to messaging clarity.
Risk and Prioritizing Risk to the Organization
Unfortunately, risk and priority are not clear drivers within frameworks which is why many organizations using them for guidance struggle to determine what to prioritize to improve the security posture of an environment over a multi-year plan. If this concept was better integrated, environments using frameworks would not fall prey to as many cyberattacks as they do. What we coach for many customers is a two-fold overview, one for governance (NIST CSF) and one for operations (CIS Top18) to improve the prioritization, target the prescriptiveness in CIS, but retain the business overview. NIST 2.0 has integrated CIS into much of their standard, further muddying the value of prioritization.
The bigger prioritization is about knowing what you have (assets), who has access (privileges), how access is secured (including vendors, partners, etc), and how defensibility is consistently enforced and monitored.
Peer Comparisons
It is not uncommon to get a request for a comparison to similar organizations when performing a security framework assessment. There is some benefit to this type of comparison, especially in terms of setting the target tier level. However, given the state of cybersecurity, it’s unclear how much comfort an organization should take simply because they compare favorably to their peers. Additionally, when comparing funding or team structure, many organizations are not counting everything the same and they can be apples-to-oranges comparisons.
Prescriptive Action Plans
One concern I have experienced in working with many organizations over the years is establishing a risk reduction action plan with a defensible approach for both finances and resiliency. Every action comes at a cost, a measured complexity, financial investment, and reportable return on effort to secure an environment.
While at the top of the chart, it may say people, policy, practices, technology and integration, that is not the entire story, and it requires more prescriptive action plans under the hood. Within an organization, you have to follow the risk to protect it, but you also have to follow the common path and prevent the non-standard path. Focus on deployment patterns, common runtime environments, focused organization structure to enforce it, security operations and management to fence it in, review and validate the technology enforcement, and track visibility and integration of protective, detective, and responsive capabilities.
In future articles, we will help you prioritize your remediation plans and cover some other common security frameworks. In the meantime, if you are not sure or would like to discuss, please feel free to reach out to SEVN-X. Our goal is to help you Achieve Better Cybersecurity and we’re happy to help!
Previous Blog:
Cybersecurity Frameworks Series part 9, NIST Cybersecurity Framework 2.0: Recover