Cross domain solutions (CDS) are network security devices which are designed to control and filter content (data) transferred between the most sensitive and classified networks within the U.S. Department of Defense (DoD) and intelligence community (IC). As these networks are among the most secure in the world, CDSs must go through an incredibly thorough and rigorous security assessment and authorization process to ensure that they are as secure as possible. Unfortunately, that process can be difficult to follow for even those familiar with the entities and roles involved.

Further complicating an already elaborate process, like many other areas in the U.S. federal government, the domain of technology assessment and accreditation is flooded with a jumble of acronyms. There are acronyms for each of the various entities, roles, and processes, not to mention the technologies themselves – even the subject of assessment and authorization itself has its own acronym! (It’s A&A).

The final layer of confusion stems from the fact that the A&A process has evolved significantly over time through:

• DoD – DITSCAP/DIACAP & DoDI 8510.01
• IC (primarily the U.S. ODNI & NSA) – DCID 6/3, ICD 503 , NISCAP/NIACAP, & CNSSI-1253F Attachment 3
• and Civilian Government – NIST Risk Management Framework, SP 800-53 & SP 800-37.

Today, the process is more unified via the NSA’s National Cross Domain Strategy & Management Office (NCDSMO), but still varies slightly depending on the intended implementation of the CDS and the security level for which it will be accredited. The keystone of the modern CDS A&A process is known as a “lab-based security assessment” (LBSA).

What Exactly is Assessment & Authorization?

As defined by the U.S. National Institute of Standards and Technology (NIST), assessment and authorization “involves the testing and evaluation of the technical and nontechnical security features of an IT system to determine its compliance with a set of specified security requirements. Accreditation is a process whereby a Designated Approval Authority (DAA) other Authorizing Official (AO) authorizes an IT system to operate for a specific purpose using a defined set of safeguards at an acceptable level of risk.”

It may be equally as important to define what A&A is not. For example, it is often confused with a related process – evaluation. Evaluation is an assessment of a vendor’s claims against defined information assurance criteria. In other words, rather than assessing the device against an exhaustive list of security requirements, the device is evaluated only to assure that it achieves the both the functional claims of the vendor and a relatively minimal set of requirements established by a governing body, typically the Common Criteria (CC). The product is assessed in an independent lab outside of its environment and certified – in the case of CC, with an “Evaluation Assurance Level” (EAL) – without any situational factors or interoperability testing.

We’ll cover it more in the next section, but it’s important to remember that in the case of devices such as cross domain solutions, the device is developed based primarily on a detailed set of functional and security requirements for a specific use, rather than a set of vendor-derived features for general purposes. It is reviewed at every stage of the design and development process and constantly refined to ensure that it meets the mission’s security and functional requirements. Once developed, it is tested both in an independent lab and on-site in the active environment to ensure that it meets the operational requirements of the user organization’s architecture without introducing an unacceptable level of risk.

This is another point at which the focal point of cross domain cybersecurity within the defense and intelligence context diverges from most standard commercial or industrial applications. Whereas in the private sector, adding security systems is generally viewed to increase security, in the defense and intelligence community, any added system is another potential vulnerability, even if it is a cybersecurity system. One might view this as a policy-based manifestation of the maxim, complexity is the enemy of security. Another way to put it is, “If you want information insurance, get a firewall. If you want information assurance, get a CDS.”

Why Conduct Assessment & Authorization?

The purpose of A&A is to mitigate threats and vulnerabilities in information systems to the greatest degree possible. Threats are actors or processes that, intentionally or unintentionally, attempt to do harm to a system and/or its users. Vulnerabilities are weaknesses in a system that can be exploited to potentially allow harm to the system and/or its users. The combination of threats and vulnerabilities creates risk.

Ideally, you’d want your security system to completely eliminate risk, but the reality is that threats will always be present and as long as systems are designed by and for humans, there will always be potential for vulnerabilities. Any system that has no vulnerabilities is likely so limited that it cannot do useful work. However, as far as one can cost-effectively (all costs – human, strategic, and monetary) mitigate risk, it should be done so. The residual risk that cannot be cost-effectively mitigated must be assessed before approving a system for operation.

That’s the end goal of the A&A process – to design, approve, implement, and accredit a system in order to achieve a specific mission at an acceptable (or acceptably low) level of risk.

How Does the A&A Process Work with Cross Domain Solutions?

The A&A process in cross domain solutions is typically defined by the lab-based security assessment (LBSA) process. This is where it can become confusing, so first, let’s map LBSA against the NIST definition:

The “IT system” is the cross domain solution, the “set of specified security requirements” are the NIST Risk Management Framework and CNSS CDS Overlay, as well as the Raise-the-Bar (RTB) requirements from the NSA/NCDSMO, and the “Designated Approval Authority” will typically either be the DSAWG and CDTAB or IC AO depending on whether it is going through a DoD- or IC-led accreditation, respectively. Once approved, the CDS goes on to the user organization where it will be tested again in the operational site infrastructure, the result of which is the basis for authorization by the organization’s AO.

Simple!

Not really.

Straightforward!

Huh?

Ok, to help explain the CDS A&A process in greater detail, in our next post, we’ll further break down how the LBSA process works and lay out the various entities, roles, and procedures involved. Stay tuned.