NIST Cybersecurity Framework 2.0: Govern

Cybersecurity Frameworks Series, part 4

Today’s installment of this blog is the start of a deeper dive into the six functions of the NIST Cybersecurity Framework. As stated in Part 2 of our series, there are six main functions of the CSF: GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER. Today, we will take a deep dive into the GOVERN function. (If you missed the earlier blogs, you can find them here.)

How “new” is it?

As many of you likely know, the GOVERN function is new with the NIST 2.0 update. Or is it? It is new in that there was previously no function called GOVERN. However, many of the sub-functions were already included in the framework under other functions. While that could suggest that this is a minor change, making GOVERN a distinct function places additional emphasis on governance functions which are important for the long-term health of a cybersecurity program. Governance practices lead to good decision making and enhanced accountability (this is not limited to cybersecurity).

The NIST CSF GOVERN function addresses an understanding of organizational context; the establishment of cybersecurity strategy and cybersecurity supply chain risk management; roles, responsibilities, and authorities; policy; and the oversight of cybersecurity strategy.

Sub-functions of GOVERN include:

Organizational Context (GV.OC):
The circumstances — mission, stakeholder expectations, dependencies, and legal, regulatory, and contractual requirements — surrounding the organization’s cybersecurity risk management decisions are understood.

The Organizational Context sub-function requires the security team to understand organization goals, legal, regulatory, and contractual requirements of the organization.

The goal of this sub-function is clarity. What does the organization do? How does security align with what the organization is trying to do?

Security teams we work with seem to understand on some level what’s important to the organization. However, there is often a lack of formality. Also, we do not often see a clear identification of customer contractual requirements being communicated effectively to security teams.

Risk Management Strategy (GV.RM):
The organization’s priorities, constraints, risk tolerance and appetite statements, and assumptions are established, communicated, and used to support operational risk decisions.

The Risk Management Strategy sub-function requires a risk management program that includes cybersecurity risk assessments and third-party risk management including mechanisms for risks to “bubble up” to the right people in the organization.

Risk assessment should be the basis for development and implementation of security policy, security strategy, and security spend. Risk assessment should identify risks that you are not thinking about.

So, why is it that so often when we work with organizations, they have not done a risk assessment? Well, not many SMBs have risk teams. The security team is thinking about risk day to day. A mechanism to inform senior leadership / board of directors is not in place. Those conversations are also sometimes difficult as it requires security teams to communicate in a language that senior management and the board understand.

Roles, Responsibilities, and Authorities (GV.RR):
Cybersecurity roles, responsibilities, and authorities to foster accountability, performance assessment, and continuous improvement are established and communicated.

Requirements included are to formally define roles and responsibilities for cybersecurity including leadership and risk management. There are also requirements to ensure proper resources are allocated to cybersecurity and to include cybersecurity in human resource strategy.

To create a culture of accountability in cybersecurity, you must have roles and responsibilities defined. This also leads to sustainability of the program.

Most of what I see are informally defined roles and responsibilities. We all know how hard it is to keep good people. When we inevitably need to replace a resource, we should have those clearly defined roles to ensure critical security tasks do not fall between the cracks.

Policy (GV.PO):
Organizational cybersecurity policy is established, communicated, and enforced.

This is a short sub-function that really just requires us to have cybersecurity policies and periodically update them based on changes to the organization or risk environment.

Policies should be based on reality and applicable to your organization. Downloading a policy from the Internet and calling it yours is not the way to go. As stated above, policies should be based on the organization’s risk and asset profiles.

In working with many organizations, our experience is that most of them have some level of security policy, especially Acceptable Use. The IT and Security policies are often lacking elements we’d recommend documenting (patch and vulnerability management is a good example).

Oversight (GV.OV):
Results of organization-wide cybersecurity risk management activities and performance are used to inform, improve, and adjust the risk management strategy.

Simply put this sub-function requires us to review risk management strategies and update as needed (when they’re not working).

Risk Management should consider organizational change (adding a line of business or acquisitions, etc.). Risk Management should also change course if it ever becomes clear that Risk Management activities are not producing the desired results.

My real-world experience is that this is informally done (if at all). This isn’t that hard to do – just requires a process. I would hope the GOVERN function helps make this happen more consistently.

Cybersecurity Supply Chain Risk Management (GV.SC):
Cyber supply chain risk management processes are identified, established, managed, monitored, and improved by organizational stakeholders.

This sub-function is all about third-party risk. Step one is knowing who your third parties are. Larger organizations may have thousands of vendors or third parties which makes third-party risk management difficult.

If a third party has access to or hosts your data (as a SaaS or cloud provider does), the risk may be obvious. Less obvious may be a third party who has access to your network but should have no access to data (e.g. an HVAC company).

What due diligence of third parties is required? The service provided by the vendor must be part of the evaluation. How critical is the service? How hard would it be to replace the vendor if the vendor goes out of business? What contingency plans do we have if that occurs?

Many organizations struggle with third-party risk. Why? Is third-party risk hard? The subject matter isn’t hard at all. It requires some time and focus. It’s more of a resource issue, a lack of process or tools to make the process efficient, and business unit education (often the business unit does not include security in the onboarding discussions).

That concludes our deep dive into the new GOVERN function. We will take a deeper dive into the IDENTIFY function next. 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 3, NIST Cybersecurity Framework 2.0: What’s New?