This is an analysis of the impacts and implications on cybersecurity practices, benefits, challenges, and how to deal with the transition to the new NIST CSF 2.0 framework. NIST released an update to its Cyber Security Framework (CSF) in February 2024. Two of the most obvious takeaways from this version are the addition of a new pillar and the expansion of its application beyond critical infrastructure. There is another update in this version which is what we will focus on, and that is the importance of continuous improvement and feedback.
The expansion to cover all industries is a long overdue change as the scope of “critical infrastructure” has grown to include almost nearly every industry these days. Given the current threat landscape and attacker techniques leveraging non-critical infrastructure to access critical infrastructure, the change just makes sense. The addition of the sixth pillar, Govern, and the map for implementing that framework, are where the biggest challenges lie. However, this also provides the greatest opportunities for security posture maturity and increased resiliency.
What is new in the CSF 2.0 framework?
The NIST CSF 2.0 Framework is addressing a long standing cybersecurity gap with the addition of the Govern Function. However, before mapping the new pillar in your organization’s cybersecurity strategy, the framework states that your cybersecurity risk management strategy, expectations, and policy must be established, communicated, and monitored. NIST then defines the following: “The Govern Function provides outcomes to inform what an organization may do to achieve and prioritize the outcomes of the other five Functions in the context of its mission and stakeholder expectations. Governance activities are critical for incorporating cybersecurity into an organization’s broader enterprise risk management (ERM) strategy. Govern 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.”
In short, the NIST CSF 2.0 is defining how to unify cybersecurity policies and responsibilities across an organization continuously instead of in the traditional monolithic fashion the industry is accustomed to. This pillar emphasizes that security risk is significantly impactful on an organization, and should be a consideration alongside other standard enterprise risks such as finances and reputation.
Explanation of the CSF 2.0 framework: It’s not been a sprint
NIST first published CSF v1.0 in 2014 following E.O. 13636, and last updated it in 2018 as v1.1. The recently published version 2.0 takes its cues from a shift in methodologies developers started over 20 years ago, a shift from monolithic waterfall development to lean agile development. Moving to adopt this updated framework means that security will have to move out of its comfort zone and adopt an entirely new (to security) way of thinking about how to improve security processes and procedures. The good news is that the blueprint for this transformation already exists in the development world.
Looking at the recommendations for a continuous improvement model, NIST is advocating for a shift in security practices to embrace a lean agile methodology. Yes, we said it. Security is going to follow the lead of development and embrace its methodology. We promise it will make sense.
Looking at the software development life cycle and overlaying security practices, the case for adopting this framework becomes more compelling. Malicious actors don’t adjust tactics on a semi-annual or yearly basis. They are adapting after every attack, whether successful or unsuccessful. Cybersecurity needs to adjust to new threat tactics and techniques as quickly as malicious actors develop them. Shifting from a reactive to a proactive stance, cyber defenders will be better able to quickly and effectively respond as new attacks are discovered.
Introducing the concept of continuous improvement to cybersecurity, which is a basis of the NIST CSF 2.0 Framework, enables a more dynamic response to addressing issues and shortcomings to incidents. At the same time, it starts covering gaps faster because progress is made towards closing a gap without having to wait for a “complete” policy to be produced, vetted, and finally implemented, which can take as little as a few weeks to as long as several months.
Security Deployment Lifecycle
We are likening the implementation of NIST CSF 2.0 to the well-known Software Development Lifecycle (SDLC). Think of agile security practices as a Security Deployment Lifecycle. Regular evaluations and improvements are done using the concept of profiles. Profiles describe shared interests, goals, and outcomes for reducing cybersecurity risk among a number stakeholders within an organization (or community). Profiles are defined as either current or target profiles. The current profile is the current state of security for an organization. The target profile is a definition of where the organization wants to be after the next iteration of security policy and procedure updates. While the first inclination is to create a target profile that is an all-encompassing monolithic beast reminiscent of today’s security policies, that defeats the purpose of them. Instead, a scoped baseline organizational profile is the expected output of following the NIST CSF 2.0 Framework, and it will provide an enterprise-wide view into the organization’s overall security posture.
You can think of profiles as the shorter-term security policy goals used to make incremental improvements. Much as developers have sprints where parts of a feature get released with each one, setting a target profile and meeting it gets security teams incrementally closer to closing gaps. The question that comes to mind is why would any security team want to only partially close a security gap? The answer is there are benefits to this approach.
The first benefit is that a security policy can fail fast. Instead of developing an entire methodology, purchasing tools, documenting, and training, only to find out that the basis of the policy is flawed, the incremental approach allows for these flaws to be found sooner, encouraging a change in tactics sooner because there is less of an investment in the flawed approach. This has an additional benefit of saving money for organizations as they purchase only the tools and spend the time on efforts that are aligned with the strategy that will end up being utilized.
The second benefit is that waiting for large policy changes and new tools to be implemented to close a gap takes time. The incremental approach may not close the gap entirely, but it also doesn’t leave the gap fully exposed while the final strategy is implemented. This reduces the attack surface incrementally instead of leaving it wide open until a full implementation plan is put in place.
Taking a page from lean agile development, security can become highly adaptable and responsive to attacks with the ability to continuously harden cyber defenses. The key is in understanding how to navigate and implement this change and the challenges that come with it.
What are the challenges?
Let’s break this down. First, let’s acknowledge that the resistance from developers to move from a waterfall approach to a lean, agile one in the early 2000s was massive. Many thought agile was going to lead to the end of stable software – the world as we know it was going to end, and it was the end of an industry. That didn’t happen, and you would be hard pressed to find a purely waterfall driven development shop today. The benefits to a lean agile development methodology have been well documented. Obviously, security will rationally realize this and willingly agree to adopt this new paradigm. You can stop laughing now. We all know security, compliance, and the other related bulwarks will have to be dragged forward kicking and screaming. It’s human nature to resist change.
New tools, new processes, and new ideas need to be embraced for continuous improvement to succeed in cybersecurity. Furthermore, one of the most painful challenges with all of this is the regulations being created forcing security into speedy response and continuous improvement cycles. Regulations were once built to reinforce the monolithic approach to security. Best practice guidelines that once abound with the “yearly or major incident” parameters on when security policies should be reviewed and updated are also now using the words proactive, continuous, etc.
Another challenge is in the changing of the gatekeeper. Traditionally, compliance and senior management drove policy in broad strokes and left directors and managers to manage practitioners to implement the policies as best as possible given toolset, knowledge, technical, and political limitations. New technologies, and ease of access to them, now require compliance to be a whole-organization responsibility. Stories abound of a critical business process being built around some piece of cloud software that someone put on their credit card. This way of thinking where security and compliance is “someone else’s” problem is no longer tenable, nor is the automatic “no” that drove the perceived need to bypass security to get the job done.
And not to be outdone, but us security minded folks will likely be the biggest challenge. Defensive thinking is all about the complete picture. Castles weren’t built by building a section of a wall and then moving on to another section of the castle. But we aren’t building castles to defend unmoving pieces of land anymore. We are defending a landscape that is ephemeral and in constant flux. Our way of defending this landscape has to shift as well.
But what are the opportunities?
It’s not all doom and gloom. This NIST CSF 2.0 change opens up a number of opportunities to better equip defenders and level the playing field, at least a little. Shifting to a continuous improvement model means that as new tools become available, defensive teams can start to test and incorporate them into their arsenal. It offers the opportunity to quickly adapt or discard policies and tools that don’t function as intended or that just aren’t meeting the business needs, and to be able to do it sooner, saving time and money.
Stepping into a role of elevated importance, managers and directors who are closer to the practitioners typically better understand the challenges, and are in a position to quickly identify and prioritize policies and tools most in need of adjusting based on the current situation. Under this model, they not only have the authority to do so, but also the responsibility.
Regulations will move (slowly) towards being truly useful and reduce (it’s too much to hope to eliminate) the “check the box” mentality that leads to meeting requirements while also being ineffective. During the transition, there will be a need to work with regulatory bodies and compliance to build a map that meets the existing requirements, but still allows for movement towards the new continuous improvement model. One way to do this is to leverage “check the box” to provide regulatory cover as policies start to shift. Leveraging the language for reviews to be “at least once a year” puts the goal post at the far end, but also opens up continuous improvement within the review cycle. The use of profiles will help with this as the current profile at the beginning of the compliance cycle will (ideally) always be less secure than the one at the end of the compliance cycle. This noted improvement, while not an exact match to either model, should provide a bridge for organizations to start implementing continuous improvement for security while waiting for the regulatory rules to catch up.
As for the security personnel, this is an opportunity. Continuous improvement removes, or at least minimizes, some of the most painful parts of maturing cybersecurity, That includes implementing policies and tools that are already out of date, the hoops that must be jumped through to get policies updated to reflect the changing threat landscape, and the difficulties in pivoting when looking to add new technology to support business needs. All of these get monumentally easier. If done well, the stigma of security being an impediment to businesses meeting changes in the market will go away. Allowing for targeted, incremental improvements enables security to be more flexible, start closing gaps sooner, identify where policies work or fail sooner, and be better able to prioritize resources to meet rapidly changing business needs.
A step forward for security teams
Developers and security have long been on opposite sides of the business conversation. Development opened a door many years ago and what was first seen as the end of good and stable software, has resulted in accelerated development of quality software where improvements are seen more often, and the ability to add new features and functionality is expected, and not a surprise. Mistakes were made on that journey, but no one is arguing that it wasn’t a good decision. We can learn from their mistakes, build on their successes, and move cybersecurity forward, being able to better meet the challenges of business needs and the ever escalating attacks from malicious actors. NIST adding continuous improvement and feedback mechanisms into the framework is a significant and positive step forward to enabling security teams to adapt to new technologies and threats quickly and effectively.