Cross Domain Solution Assessment & Authorization: Part 1 – What is A&A?

Cross Domain Solution Assessment & Authorization: Part 1 – What is A&A?


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:

  • DoDDITSCAP/DIACAP & DoDI 8510.01
  • IC (primarily the U.S. ODNI & NSA) – DCID 6/3, ICD 503 , NISCAP/NIACAP, & CNSSI-1253F Attachment 3
  • and Civilian GovernmentNIST 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.

Insights to your Inbox

Stay informed with the latest cybersecurity news and resources.

Shawn Campbell Product Manager - Government Solutions

A Brief Note on Raise the Bar and One-Way Transfer

This past year’s publication of the National Cross Domain Strategy and Management Office (NCDSMO) “Raise the Bar” (RTB) mandate is causing a positive transformation of the cross dom...
September 18, 2019
Dave Britton Vice President, Assured Collaboration Systems

Building the Future of Cross Domain Security

In early January, Owl Cyber Defense announced the acquisition of the Assured Collaboration Systems (ACS) product line from Trident Systems Incorporated. This acquisition brings together t...
January 12, 2021

Cross Domain Solutions vs Firewalls

Transferring data securely between networks or systems with different security requirements is one of the fundamental challenges of cybersecurity. For a typical organization, the solution...
November 10, 2020