SD Elements | 
Research
Upcoming Events
Resources
On February 26, 2024, the US-based National Institute of Standards and Technology (NIST) released a highly anticipated update to the Cyber Security Framework (CSF). The NIST CSF includes several changes from the prior version, including implications for security by design and secure SDLC.
What is the Cyber Security Framework (CSF)?
CSF is a voluntary framework initially designed for critical infrastructure organizations to measure, manage, and improve their cybersecurity posture. Its flexibility, breadth, and conceptual simplicity, along with having the backing of NIST, means that many organizations across all verticals and around the globe have adopted the CSF as a primary tool to communicate cybersecurity posture and priorities.
A common use of NIST CSF is for technology executives such as CISOs and CIOs to report to boards of directors on current and target states related to cybersecurity posture. According to IDC, over half of Fortune 500 companies with US headquarters have adopted the NIST CSF as their primary control framework for cybersecurity. Many international brands have cited NIST CSF in their annual reports or other public documents, including T-Mobile, Nielsen, Blackrock, TransUnion, Thompson Reuters, and Petrobras. Global consultancies such as PriceWaterhouseCoopers (PWC) offer guidance to boards on the CSF, and the National Association of Corporate Directors (NACD) cites CSF in its Cyber Risk Oversight Handbook.
While many other frameworks and control catalogs exist, the CSF is unique in its widespread acceptance across regions and industries by non-technical stakeholders.
The CSF’s Role in Shaping Cybersecurity Programs
Cybersecurity has an ongoing and often heated debate about the value of compliance vs. mitigating risk. Security practitioners often bemoan focusing on “checking the box” of compliance vs. spending time and effort on the organization’s most significant areas of risk. The debate will likely continue forever, but one thing is clear: compliance will always be a substantial driver of cybersecurity programs.
Finding the appropriate spend of time and effort in cybersecurity is no simple task. Leadership teams in any organization often seek concrete, measurable goals to help allocate resources for domains like cybersecurity. Measuring against an internationally recognized and credible framework like the NIST CSF can often have the additional benefit of satisfying many stakeholders, including auditors, regulators, and shareholders. Moreover, it creates a defensible position in the event of a security incident – a major topic of conversation at boards due to the SEC’s new rules on incident disclosure.
Organizations that adopt CSF often use Profiles that measure the current state across the various control categories, define a target state, and then use the delta to help build a roadmap for their security program. CISOs or other senior executives are often asked to periodically report progress to the board on that roadmap against the CSF target state.
The high-level visibility of the CSF often means that the entire cybersecurity program and budget are heavily influenced by the roadmap to achieving the target state. While the CSF is flexible and not prescriptive, the reality is that for many organizations, CSF creates a world of haves and have-nots for cybersecurity: anything described in the CSF Core and on the roadmap to target state is a priority. Anything that does not help achieve target state compliance is a lower priority unless it is a critical (i.e., imminently exploitable) risk or leaves the organization in non-compliance with regulatory requirements.
The CSF and Software Security
Partially because it was developed for critical infrastructure organizations rather than software manufacturers and partially because widespread awareness and acceptance of the importance of secure software development practices was relatively low compared to today, the NIST CSF 1.0 and 1.1 core did not contain many explicit references to software security. Many categories and subcategories could be interpreted to include software. For example: “ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk“ or “PR.IP-12: A vulnerability management plan is developed and implemented”. However, in most cases, the scope was broader than software. Moreover, the concept of security by design and integrating software at the beginning of the development process was not mentioned.
Secure SDLC and security-by-design are large programs that require organization-wide support and executive buy-in to be successful. When deciding which programs to fund and allocate headcount to, many organizations decided that the cost/benefit of investing in an extensive program like this was simply not worth it if it wasn’t on the CSF target state roadmap.
The Importance of Secure Software Development in Today’s Cybersecurity Landscape
In 2021, after many high-profile incidents, the president of the United States issued an executive order on cybersecurity that specifically called out software supply chain security. This was followed by a wave of government actions related to software security, including:
- Cybersecurity and Infrastructure Security Agency (CISA) and other governments around the world began to push the importance of secure by design software,
- NIST published the Secure Software Development Framework
- The Federal Communications Commission (FCC) established the Cyber Trust Mark program
- The Food and Drug Administration (FDA) pushed to improve product security of medical devices
- The European Union introduced the Cyber Resilience Act and proposed changes to liability to include software vulnerabilities
Spotlight on Platform Security: A New Paradigm in NIST CSF 2.0
One of the most significant changes to NIST CSF was its intended scope. Instead of focusing primarily on critical infrastructure, NIST CSF 2.0 is now designed for any organization.
NIST introduced the Platform Security category under the “Protect” function: “The hardware, software (e.g., firmware, operating systems, applications), and services of physical and virtual platforms are managed consistent with the organization’s risk strategy to protect their confidentiality, integrity, and availability.” Under platform security, NIST added a subcategory that specifically references secure software development: “Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle.” Including this subcategory means anyone who builds software and wants to implement a secure SDLC program can do so knowing it will align with CSF.
Assessing Secure Software Development Current State
CSF defines four tiers for assessing the current and target states:
(Source: NIST CSF 2.0)
Most organizations looking to improve platform security will likely target Tier 3 or 4 in their end state. The NIST SSDF provides a comprehensive set of controls specific to secure development. In our experience, many organizations have implemented security testing and/or scanning and developer education but have not otherwise broadly rolled out secure SDLC activities such as threat modeling, defining security requirements, ensuring code integrity in the build process, etc. These organizations will likely self-assess as Tier 1 or Tier 2 in this category.
Next Steps: Achieving the Target State
Organizations looking to Target 3 or 4 for secure development should consider building a roadmap based on the NIST SSDF. We have published a guide to help you comply with the SSDF.
This is an excellent opportunity to build broad support for security by design. We recommend adopting the 3E framework to help ease the organization into the cultural change necessary: Educate development teams, Embed security ownership within the teams, and then Empower the teams to integrate security by design.
Conclusion: The Future of Software Security with CSF 2.0
The global influence of NIST CSF is unparalleled. Combined with the regulatory changes and other government actions related to software security, integrating security into the SDLC will no longer fall into the “have-nots” of a cybersecurity program. Practitioners who have seen their initiatives shelved year after year will finally have the organizational backing to push for fundamental changes in software development.
The downstream impact of software product manufacturers building more secure software will be felt by everyone. Fewer patches involving known, preventable security defects will lead to fewer incidents and increase public trust in technology. This is the very vision of Security Compass.
Contact us if you want to learn more about secure software development and how to start your program.