Commercial Solutions for Classified (CSfC) – A primer

March 11, 2021

By Jonathan Kline, Star Lab (a Wind River Company)

The National Security Agency’s (NSA’s) Commercial Solutions for Classified (CSfC) program enables integrators to leverage two distinct CSfC-approved commercial off-the-shelf (COTS) components to protect classified data at rest or in transit. Prior to the introduction of CSfC, programs with classified data requirements had to either develop or use an existing Type-1 solution.

Type-1 solutions for meeting requirements for classified data introduce various controlled cryptographic item requirements (for example, force-specific handling, tracking, reporting, and protection requirements); they also require classified facilities/employees for implementation and integration. Type-1 also has its own its own certification process, which adds to schedule and cost pressures and is definitely a large hurdle to overcome if you’ve never completed it before. While traditional Type-1 solutions may be the only viable approach in many cases, in some instances the Commercial Solutions for Classified (CSfC) program provides an alternative, enabling integrators to take advantage of commercial cost, performance, and other benefits.

Most of the approved components on the CSfC products list are focused on protecting data in transit. These components are usually focused on using multiple VPNs [virtual private networks] nested within each other.

It’s implied through threat enumerations, but not required, that both components be provided by separate vendors. However, there is established precedent for both components being provided by a single vendor, generally with separate development/integration teams and cryptographic components.

Fewer components are found for use in protecting data at rest, and most of the registered components are application- or platform-specific. They are generally not intended to be used as general-purpose solutions.

The path to CSfC

For a component to be added to the CSfC components list, it’s necessary to undertake a certification effort, similar to Type-1 solutions. Generally, certification requires compliance with one or more National Information Assurance Partnership (NIAP) protection profiles, compliance with the NSA CSfC capability package (CP), and registering the component with the NSA (Figure 1). Achieving compliance with the protection profiles requires the use of an accredited lab to perform the NIAP/Common Criteria testing.

[Figure 1 | Component certification – file encryption.]

The choice of lab will, in part, dictate how long the certification and accreditation process will take. Additionally, the NSA CSfC CP is used to restrict and/or reinforce protection profile requirements (generally these are related to specific requirements for algorithm selection mostly aligned with NSA Suite B and NIST guidelines). For example, the NSA CSfC CP specifies minimums for key sizes and specific algorithms/modes used for encryption and authentication. The CP provides both a minimum threshold and an objective threshold.

As part of the certification process, the cryptographic algorithms/implementations used in the component must be verified, either as part of a Federal Information Processing Standard (FIPS) 140/ACVP module or National Information Assurance Partnership (NIAP) testing. It’s generally more cost-effective to do it as part of a FIPS module. Both FIPS and NIAP require various self-tests and known-answers test to be completed during cryptographic module initialization/power-on and before use, which may guide where the cryptographic validation occurs.

Once a component has been added to the approved products list, it is usable by a trusted integrator as part of a CSfC solution. Trusted integrators also must be registered and accredited with the NSA; the integrators’ accreditation process is like the components themselves. It should be noted that a product generally cannot be added to the approved products list until, at a minimum, it has entered formal test with NIAP.

The certification for a component is valid for two years before needing maintenance. After a component enters the maintenance window, the certification can be renewed before it must be restarted from “ground zero.” Additionally, non-security-relevant changes such as the addition of additional processors and some hardware/operating system (OS)-level changes can be made by updating the NIAP certificates without requiring additional formal evaluation. These are so-called “vendor affirmed” changes and are required to be non-security-relevant. In the event that security-relevant changes are required, a delta-certification and update process must be used.

Integrating CSfC components

An approved CSfC system uses two different components in one the approved configurations (Figure 2).

[Figure 2 | Approved configurations.]

In order to have an approved CSfC solution, the use of a trusted integrator who integrates both layers of the CSfC solution is required. One of the more subtle points of this integration is providing a level of interaction and integration with both components specifically related to providing the authorization factors for both layers. The authorization factors enable an authorized user of the system to “unlock” the encryption key(s) for each layer. Each layer or component must use a unique authorization factor, making integration challenging for most situations or environments.

Depending on how the data at rest solutions are used, this level of integration may be required to occur in a preboot environment. Some of the specific requirements in the Authorization and Authentication protection profile, specifically for software full disk encryption, implicitly assume this scenario.

What’s the story?

Let’s look at some common questions:

1. Can an open source solution be certified?
   Nothing in the protection profiles or the NSA capability package prohibits it. In fact, most of the data at rest or data in transit solutions are based on open source software with modifications to meet the protection profiles and CP. The real hurdle is the cost of accreditation and needing to address very specific requirements which can be a challenge for non-purpose-built solutions.
2. When do components get added to the approved components list?
   Components are eligible to be added to the approved components list after they have entered formal testing and pending award of the final certification documents.
3. What is the timeline for achieving CSfC?
   Assuming no new development or tailoring at the component level, it would be three to six months depending on the lab’s experience with the specific protection profiles and solution space. It should be expected to take from one to six months for integration of the individual components, mostly dependent on the vendor and the complexity of the integration effort.
4. Do you have to certify a purpose-built solution?
   No. Pre-existing, non-purpose-built components that met or exceeded the protection profile requirements can be certified; however, that does alter the way certain operations are performed, and it may take a bit of back-and-forth with the certifying lab to find a solution that meets the protection profile requirements while not reducing the overall security of the components. The protection profiles assume particular use cases/scenarios, making it challenging to meet all requirements (to the letter of the protection profiles) without purpose-built solutions.

Certification update

Two components of the Wind River Titanium Security Suite for Linux, developed by Wind River’s technology protection and cybersecurity group Star Lab, are currently undergoing NIAP accreditation for use in general-purpose data at rest scenarios: FortiFS file-based data at rest encryption, and FortiFDE (software) full disk encryption (including authorization and authentication).

FortiFS and FortiFDE are not intended to be used together to provide both CSfC layers of protection; however, there is some precedent for similar solutions from the same vendor being used together (such is the case with the solution Curtiss-Wright has developed and certified). The solutions are intended to provide programs different Linux-based options for meeting their CSfC data at rest requirements. Both components within the Wind River Titanium Security Suite are on track to be added to the NSA CSfC component list during 2021.

Jonathan Kline is a Principal Architect and Solutions Engineer at Wind River’s Cybersecurity and Technology Protection Group, Star Lab. Jonathan has 20+ years’ experience with offensive and defensive security (including vulnerability assessments, kernel and hypervisor development on Linux/Unix/VxWorks, trusted boot systems, and the development of software protection/anti-reverse-engineering capabilities) across a broad range of platforms.

Star Lab, a Wind River company • https://www.starlab.io/