NIST Cybersecurity Framework: Core functions and best practices

The United States National Institute of Standards and Technology (NIST) is part of the US Department of Commerce. Its goal is to promote innovation and industrial competitiveness, allowing the US to better compete with other nations.

A brief history of NIST

NIST was formed in 1901 and at the time was called the National Bureau of Standards. The original purpose was to provide standards for weights and measures. Members of the US government recognized that when organizations across the country used different standards of measurements – where one company had one weight for a pound and another had a slightly different weight, also called a pound – such companies could not be competitive and could lose money selling their products overseas where the products might measure in at a lower weight. 

NIST was created to help provide a standard that all companies could use for each measure, such as pound or kilogram, and feet or meters.

Soon after NIST was created, it expanded beyond just weights and measures to owning a broader set of standards across different industries. NIST created its own labs to conduct tests and to publish standards such as building codes, fire safety, and eventually entered into computers and information technology. One of the most important standards NIST has implemented – that most of us rely on without even realizing it – is the atomic clock, which is used to align the date and time on computers and phones. Imagine a scenario where you pay your credit card bill online moments before midnight to avoid a late fee. Yet the credit card company’s clocks are 15 minutes ahead of your own, and you get hit with a late fee anyway. Now imagine the flip side, where you’re the CTO of said company. You’re unaware that your clocks are ahead, and soon your company gets hit with a major lawsuit for charging thousands of customers inappropriate late fees. Standards matter.

What is the NIST cybersecurity framework?

In 2013, NIST began work on a cybersecurity framework, with its goal being to publish several documents offering guidance on how to implement security best practices and protocols. This was the result of Executive Order 13636, signed in 2013, which was designed to harden the US’s digital infrastructure against foreign influence and attacks. The US government recognized that a) most digital infrastructure is owned and operated by private organizations, b) the leaders at these organizations lacked critical cybersecurity knowledge, and c) these systems were all connected through the internet.  That meant that it would likely be easy for a foreign adversary to gain access through a small, insecure system, and potentially use that intrusion to connect to much larger systems for malicious purposes.  Thus the first version of the Cybersecurity Framework (CSF) was released in 2014 to counteract this reality The current version of CSF 2.0, was released in February of 2024, and it contains significant framework updates designed to address modern technological changes from the past decade.

CSF 2.0 core principles and best practices

CSF 2.0 includes six core principles, outlined in its primary document. 

1. Govern

In the world of IT, the term “governance” refers to centralized organizational policies that all employees and technologies must follow. In the context of CSF, this involves setting the overall strategy and rules for an organization’s cybersecurity strategy, building a risk management strategy that includes documenting stakeholder expectations, and ensuring adherence to legal and regulatory requirements.

2. Identify

Identifying risk is a complex process. It starts with enumerating all the assets, including physical and digital. This can mean all the physical hardware in the organization, the facilities storing the hardware and the facilities where the people work, as well as all the software used, and even the data, both what it contains and how it’s stored. NIST CSF 2.0 includes an entire list of such resources that need to be identified, such as hardware inventory, software and service inventory, and inventories of supplier-maintained services.

From there, you need to assess the risks. NIST CSF 2.0 provides a list called Risk Assessment, which lists the type of risks to look for, such as identifying and recording vulnerabilities in software and hardware. Then, each risk is assigned a severity level. For example, a low risk might be if intruders get hold of an internal document listing the same financials that are available on the SEC website. A high risk might be if intruders find a document listing payroll information along with direct deposit information.

3. Protect

This is the action level, whereby companies implement safeguards to protect their critical assets like intellectual property. For example, when using a cloud computing service, you would set up the cloud firewall correctly so that only users from certain IP addresses can log directly into a cloud server.

Another example is developers using the latest versions of software that include the latest available patches for libraries that are core to their products..

4. Detect

Far too often intruders go unnoticed. Only after data is leaked do many organizations even know something happened. It’s important to have a policy in place whereby incident response teams in your organization will be immediately notified once a cybersecurity event occurs. These notifications should take place for all incident severity levels, whether it’s an intrusion into your servers, or a phishing problem, or a virus that was unleashed on your employees’ computers. This usually involves working with private IT security firms to make sure you have the right software installed, and that the members of your IT team are appropriately trained on how to detect malicious events as quickly as possible.

5. Respond

As much as we don’t want cybersecurity events to happen, we have to be ready for them if they do. You don’t want to be scrambling to figure out what to do at this stage; you should already have a plan of action in place on how to resolve an incident. 

Responses can include immediately locking out an intruder and detecting if the intruder managed to steal anything or install any malicious software; or it can mean sealing off files that were infected from a virus an employee accidentally installed, and so on.

As with the Detect stage, having an appropriate response will require personnel training as well as leveraging the right software.

6. Recover

After a cybersecurity event occurs, is detected, and an appropriate response occurs, your organization also needs a recovery plan. Determining the appropriate recovery plan means putting together a way to restore systems to their previous state before the damage was done, as well as learning from the event and upgrading software and processes to mitigate future incidents; this will likely also mean updating the previous steps list above.

Chainguard helps address the most important NIST principles

Container images are critical for effectively deploying applications in the cloud. But all too often companies are unaware of the risks sitting in those images. Typically, teams pick Docker images based on traditional linux distributions like Ubuntu without recognizing these images haven’t been updated with the latest security patches. It’s common for most open source container images to include CVEs that haven’t been fixed with patches and excess components that increase the attack surface of containerized applications. Relying on open source container images threatens a company’s security posture and compliance capabilities. 

These issues often go unnoticed until a company has implemented a vulnerability scanner, which then drowns engineering and security teams in mountains of vulnerability alerts. Companies will then likely spend hundreds of hours trying to patch the software, which can be incredibly time-consuming, as the patches need to be manually identified and implemented. 

Then, after the patches are installed, the developers need to run the full set of tests to make sure their software still works. And too often the initial patch will break your software, and more time will be required for those fixes and refactors. Vulnerability management tends to be a huge drain on developer productivity, diverting previous engineering resources away from revenue-generating product development.

Having the right container images starts with implementing rules during the Govern stage. For example, one rule might be that all Docker containers must start with a hardened and proven container image with minimal security risks. That means starting with images built for speed, security, and efficiency,  with minimal Common Vulnerabilities and Exposures (CVEs).

Chainguard builds minimal, zero-CVE container images entirely from source, providing developers a clean and secure base to deploy their cloud-native applications. You’re welcome to get in touch with our experts to see how our low-to-zero CVE images can reduce vulnerabilities and save engineering time.