From Ad-hoc to Managed Under NIST CSF 2.0

This article first appeared on Reveal Risk Consultant and author Michael Milroy's LinkedIn.

Compliance frameworks, regulatory requirements, industry best practices - all things that direct organization’s approach to business and security.

However, individual frameworks or requirements all too often become the driving factor; they become the end-all-be-all process rather than the guiding light they should be. Add to this that nobody likes to be wrong, or to fall short of the mark, and you have a recipe for a disastrous security program that either overly focuses on the framework or ignores them all together.

Some frameworks require a third-party attestation or audit to ensure practices are being met, but many are self-attestation. This innately allows for organizations to claim they are aligned to a particular framework, and perform regular assessments to ensure alignment, but this often ends up being a facade in order to dodge customer requirements, gain business they’d otherwise lose, etc.

Security is a scale and works best when balancing the best security possible with the reality of operational needs and helping the business succeed.

Have you ever done a third-party security risk assessment?

You likely asked a couple easy questions to the business requesting the vendor’s product/service. Then you may have sent a questionnaire spreadsheet to the sales team at the vendor (because that’s probably the only contact you have at the company). They may or may not have completed it, and if they did, your team may or may have actually reviewed because your team is already too small and over worked. This is unfortunately the case all too often, and it enables organizations to talk the talk, without being called out for not actually walking the walk. Now, have you ever been that provider that received those questionnaires and responded in kind, or ignored all together?

There is a better way to ensure your organization is truly owning security and protecting your organization’s and customer’s data.

It does start with having a framework to guide your controls and practices, but it also requires an honest, unbiased assessment of the current state, requirements and laws needing to be accounted for, and then appropriately prioritizing and executing improvements. This is where frameworks like NIST Cybersecurity Framework (CSF) come in. It provides a standard approach to fulfilling baseline security controls, from policy and procedures all the way to technical controls and blocks.

Being able to self-assess should not be an easy out that an organization chooses so they can make the claim and save the budget for other things. It should be used to perform an honest assessment, while maintaining the ability to remediate and improve without a public-facing black mark for failing to meet legal and regulatory requirements. This is how organizations start the journey from ad-hoc to managed. This is how they define, maintain, and continuously improve processes. This is how we all get a little better each day, year after year.

Step 1: Get an honest baseline

Frameworks like NIST CSF provide you a solid starting point and set of questions to ask yourself and your organization in order to identify your actual baseline. It splits up the process into logical functions: Govern, Identify, Protect, Detect, Respond, and Recover.

• Govern covers organizational definitions, placement in the industry and supply chain, policy and procedure documentation, clearly defined roles and responsibilities, etc.

• Identify dives into internal assessments and practices geared at identifying risk and performing impact analysis.

• Protect cover proactive controls and practices that help prevent exposure and reduce potential impact of malicious activity.

• Detect includes those technical tools and controls that identify when there is anomalous or malicious activity that deviates from the baseline.

• Respond includes incident response and how the organization reacts/responds to security events and incidents.

• Recover includes restoring normal business operations, learning from the event/incident, and improving processes to reduce the likelihood and/or impact of that particular security event/incident occurring again.

The organization needs to identify the appropriate stakeholders throughout the organization within each of these functions and have open and honest conversations with them. NIST provides a simple maturity scale to initially gauge the state of each control. If the organization has a culture of risk aversion, or worse, lack of willingness to share information and the reality of their processes, then this will prevent true growth and improvement for the organization in the short and long term.

The organization also needs to define what level of “managed” is appropriate for them. Does every organization need every control to be highly matured, optimized, and automated? (Of course not.) Security is not an all or nothing, black or white construct. Security is a scale and works best when balancing the best security possible with the reality of operational needs and helping the business succeed.

Step 2: Define what “managed” means to you

If you work for a 20-person consulting company, you probably don’t need 20 separate policies, loads of automation, and strict remote access policies limited to a single person. On the flip-side, if you are a global pharmaceutical organization regulated by the FDA, various EU regulatory bodies, and support governmental programs, you may most certainly need those things and then some. You know your business, your customers, and the lines you must operate within.

NIST CSF 2.0 includes industry baselines to help organizations see where they may need to be from a benchmarking perspective. It also gives some specific examples of ways to achieve the underlying intent of the controls which gives you multiple options to choose from or use to spark your own ideas. To further expand on the above examples, here are some specific items that help easily identify the varying levels of security needs:

20-person consulting company:

• A single spreadsheet that includes tabs for risk register, change requests, incident management, etc.
• A one-page RACI matrix that covers all the key activities for the organization and people’s roles within them.
• A manual system patching, account provisioning, and access reviews.
• One incident response plan that is used regardless of the type of security incident being faced.
  
  

Global organization with 10,000 employees:

• A holistic GRC platform with separate modules and teams focused on Risk Management, Change Management, Incident Response.
• Each department or business unit maintains their own RACI matrices with key roles and responsibilities, as well as escalation paths based on different use-cases.
• A third-party managed service providing automate patch management, and a million dollar per year Identity Governance platform for account provisioning, management, and de-provisioning.
• An overarching incident response plan with several runbooks/playbooks for specific incident types, location of the incident (US, EU, etc.), and type(s) of data impacted.

Step 3: Pareto principle

Once it is determined the current state of the organization’s security posture, as well as the definition of “managed” given the organization’s business needs, then remediation must be itemized and prioritized.

Every gap and finding is not equal. Lacking a RACI matrix in the 20-person company doesn’t have the same impact that is has for the global organization. Throw in the regulatory frameworks and legal requirements, and now you have a highly detailed level of needs to prioritize against. Security often enables remediation of multiple gaps through a single activity or control implementation.

The Pareto principle tells us that roughly 80% of our output is driven by 20% of the inputs. Often times, defining 2-3 key processes well will have a great impact on the overarching security of the organization than trying to define 10-12 processes up front.

If you can stand up a steering committee for security, along with a chart for the committee, that will innately drive multiple governance needs through their regular discussions and actions. Setting up a security risk management process will enable risk identification, analysis, management, and remediation. Creating a change management process will identify potential negative consequences before the change is ever actually implemented, resulting in less pain and spend in the long run. With NIST CSF you are able to update your responses and scores immediately to see the actual impact, as well as model out impact based on desired activities.

With all of this comes a need for some baseline metrics. It is important to measure progress over time in order to identify pain points, ineffective activities, misalignment, etc. Set up some baseline metrics like on-time patches pushed, % of systems with security monitoring tools installed and active, and accounts de-provisioned within the SLA defined in policy. These will increase adherence and shed light on key issues, new issues, etc. which will increase the organization’s posture over time.

Step 4: Build a roadmap

Once the 20% is covered, you still need to address the other 80%…

You don’t need to action remediation on all 80%, but you do need to know what you can accept risk on, what you need to action, and in what order they should be addressed. Building a program roadmap enables your organization to perform the right activities, in the right order, at the right time. Things that impact the roadmap include budget, staffing, external resources, etc.

Just because you build a roadmap does not mean that you must stick to it without changes. If you have a roadmap, and the budget suddenly changes, you are prepared to explain what impact it has on security, what things can shift or not, and how you can best accommodate the new situation. If your team has the opportunity to hire additional key resources, you may be able to pull things forward, shift things back, in-source things you’ve historically out-sourced, etc. The roadmap also can explicitly flag activities that are “low-hanging fruit” and can be pulled in when capacity allows but are not urgent for immediate action.

A roadmap shouldn’t be thought about in days or weeks, but rather months or quarters. Often times a program will have a 12-18-month roadmap while specific teams will have monthly or quarterly roadmaps that support it. The goal is to bucket things in a manageable way to ensure progress without becoming overwhelmed and falling behind.

Conclusion

Compliance does not equal security. Following a single framework does not protect your organization from getting hacked, ransomware, breached, etc. Approaching security in a way that is driven by actual security, then aligning that approach to multiple frameworks and understanding the connections and differences enables staying ahead of changes to those frameworks without dismantling your program and security. Focusing on security rather than specific controls allows you to collect evidence once and apply it to multiple frameworks, without having to pull the same evidence 10 times for 10 different frameworks. NIST CSF provides direct mapping of their controls to other common frameworks across the US and international communities. This provides a solid foundation for aligning to an initial framework and already being well on the way to proactively determining alignment to other potential frameworks, at a control-by-control level.

• Without an honest baseline, it will be tremendously difficult to improve in meaningful ways. Doing all of this allows your organization to increase its security posture, genuinely inform your customers that you take security of their data seriously, and that you have an actual grasp on how you are protecting it.

• Without knowing your “managed” means to your organization, you will likely be following someone else’s path and spinning your wheels trying to make it fit your organization.

• Without metrics to monitor performance and program, you won’t be able to effectively enact meaningful change.

• Without understanding the most impactful changes to make, you will likely try to change as many things as possible as quickly as possible, and fail to make real progress.

• Without a proper roadmap to guide your program, teams will likely not support the program in the best way possible and your organization will be less effective as responding to change and spend more time reacting in the midst of chaos.

Looking for a conversation about assessments, strategy, or roadmapping? Book time with an expert now.