In our previous post, we discussed the purpose and goals of Assessment & Authorization (A&A) processes for various technologies, specifically with regard to U.S. Government testing. If you haven’t read it, I encourage you to check it out as it provides some valuable context, as in this post we’ll be delving into the specifics regarding the A&A process for cross domain solutions (CDS).
The previous post also described at a high level the “set of security requirements” which are based on the NIST Risk Management Framework (RMF) and CNSS CDS Overlay, as well as the Raise the Bar (RTB) requirements from the National Security Agency’s National Cross Domain Strategy and Management Office (NCDSMO). The NIST RMF was designed as a guideline for Assessment & Authorization processes for U.S. Government IT systems to standardize and structure them according to seven basic “steps”: Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor.
NIST RMF Steps
This process can take months or years to complete (in fact, it never technically completes as the Monitor step is ongoing) and involve countless manhours of design, development, documenting, cataloguing, and testing.
Further complicating an already elaborate process, like many other areas in the U.S. federal government, the domain of technology assessment and authorization is flooded with a jumble of acronyms. Not to worry, we’re here to help! As a trusted advisor to the United States Intelligence Community (IC) and Department of Defense (DoD), we have decades of experience in advising and guiding folks through various A&A processes, including a key element – the Lab-Based Security Assessment (LBSA).
In an effort to help demystify CDS Assessment & Authorization processes, we’ll first part the sea of acronyms involved – prepare yourself, there are a lot of them – and then define and detail the steps of CDS A&A itself, including LBSA.
ATAYCH (All The Acronyms You Can Handle)
At the risk of a slight overstatement, there may be no longer laundry list of acronyms in anything that has ever existed in the history of man than the CDS Assessment & Authorization process. Indeed, nearly every aspect of the process, from the entities to the roles within those entities, to the activities and the technologies themselves is shot through with an alphabet soup of acronyms.
Just to add to the confusion, many of these acronyms change or transition regularly, so while we’ll make every effort to keep this post up to date, just know that they can and do change. As many of the acronyms for processes and principles are defined in context later on, this list is confined to the entities and roles involved in order to provide additional background to the A&A process. Feel free to skip over this section and come back to reference once you have encountered an unfamiliar acronym.
Assessment & Authorization Entities:
- CDTAB – Cross Domain Technical Advisory Board
Acts as an advisory board and Authorizing Official (AO) to the Department of Defense (DoD) to provide recommendations for the CDS risk assessment and decision process. The CDTAB adjudicates all high-risk connection requests within DoD networks, which typically involves a cross domain solution.
- CDSE/O – Cross Domain Support Element/Office
An office within each major DoD/IC organization (e.g., Army CDSE, Air Force CDSE, DIA CDSE, etc.), acts as the CDS principal point of contact for their respective organization. Helps their missions/organizations formulate CDS requirements for their mission, source an appropriate solution, or determine if the mission does not need to use a CDS at all. They are also responsible for managing the policy, practices, and updates for CDSs implemented in their missions/organizations.
- CNSS – Committee on National Security Systems
Sets national-level cybersecurity policies, directives, instructions, operational procedures, guidance, and advisories for U.S. Government departments and agencies for the security of National Security Systems (NSS). It provides a comprehensive forum for strategic planning and operational decision-making to protect NSS and approves the release of INFOSEC products and information to foreign governments.
- DIA – Defense Intelligence Agency
Provides military intelligence to warfighters, defense policymakers and force planners in the Department of Defense and the Intelligence Community, in support of U.S. military planning and operations and weapon systems acquisition, including defense and cybersecurity technologies.
- DSAWG – Defense Security/Cybersecurity Authorization Working Group
Acts as the first authorization review level for the U.S. DoD for the transport, network management, and network segments of the Department of Defense Information Network (DoDIN). The DSAWG acts as AO for DoD assessments (in conjunction with the CDTAB) and adjudicates all high-risk connection requests within U.S. DoD networks (which typically involves a cross domain solution).
- NSA/CSS – National Security Agency/Central Security Service
Leads the U.S. Government in both signals intelligence (SIGINT) and information assurance (now referred to as cybersecurity) products and services, and enables computer network operations (CNO) in order to gain a decision advantage for the United States and its allies under all circumstances. It is also the host organization for the National Cross Domain Strategy and Management Office (NCDSMO)
- NCDSMO – National Cross Domain Strategy & Management Office
Previously the Unified Cross Domain Management Office (UCDMO) and Unified Cross Domain Services Management Office (UCDSMO), both under the Office of Director of National Intelligence (ODNI), the NCDSMO is an office under the NSA tasked with overseeing cross domain solution activities and technologies within the U.S. Government, including ensuring a common approach to their development, assessment, and authorization.
- NIST – National Institute of Standards and Technology
National physical sciences laboratory and a non-regulatory agency of the U.S. Department of Commerce tasked to promote innovation and industrial competitiveness. NIST’s activities are organized into laboratory programs that include nanoscale science and technology, engineering, information technology, neutron research, material measurement, and physical measurement.
Assessment & Authorization Roles:
- AO – Authorizing Official
Previously known as the Designated Accrediting/Approval Authority or Principal Accrediting Authority (DAA/PAA), considers the body of evidence (BOE) resulting from the test activity in the context of mission need and formally assumes responsibility for operating the CDS at an acceptable level of residual risk. This is the person at the end of the line that everyone needs to satisfy in order to finish the process and achieve the desired result – accreditation and Authorization to Operate (ATO).
- ISSM – Information Systems Security Manager
The Information System Security Manager (ISSM) is designated by an organization to manage the organization’s cyber security program. The ISSM establishes, documents, and monitors an operating unit’s cyber security program implementation plan, and ensures compliance with management policies. The ISSM manages the organization’s Information Systems Security Officer (ISSO) personnel.
- ISSO – Information Systems Security Officer
Individual assigned responsibility for maintaining the appropriate operational security posture for an information system or program. Person responsible to the ISSM and AO for ensuring the security of an information system throughout its lifecycle, from design through disposal.
- ISO – Information System Owner / PM – Program Manager
Official responsible for the overall procurement, development, integration, modification, or operation and maintenance of an information system.
As previously mentioned, feel free to come back and reference this list – it’s not easy for even the most practiced to remember – and if you somehow haven’t had your fill of acronyms, you can visit the CNSS glossary (CNSSI 4009) for other terms. Now let’s get to it!
The CDS Assessment & Authorization Process
As mentioned in our previous post in this series, the CDS Assessment & Authorization process follows the NIST RMF, which is divided into seven steps. This covers everything from selecting a solution, to planning and design, to assessment and penetration testing, to implementation (and more testing), all the way through to authorization and upkeep.
The process is, to put it mildly, extremely thorough, and each step includes one or more reviews of various requirements, each gating the next step throughout the phases, through to the ongoing review that goes on even after the CDS is accredited, approved, and in operation.
Step 1 – Prepare
At the beginning of this process, the PM or ISO will engage with their relevant CDSE with an identified potential need for a CDS. The CDSE will determine whether there is an existing CDS that meets the users’ needs or if a CDS is not necessary. In this case, we’ll assume that the CDSE has determined that a new CDS is required. If a suitable existing CDS was identified, the process would usually skip straight to Step 6 (Authorize).
CDS Assessment & Authorization NIST RMF
Step 2 – Categorize
The objective of Step 2 is to get all involved parties (the CDS vendor, AO, the end user/ISO, PM, ISSO, and, crucially, the NCDSMO, among others) to agree on the mission need for the CDS, including the type of CDS required (Access, Transfer, or Multilevel), environment, architecture, information assurance (IA) requirements, certification schedule, level of effort, and resources required to achieve the mission.
Step 3 – Select
In Step 3, the prospective CDS is intricately detailed in a set of security design documents mapped against the NIST RMF, CNSS CDS Overlay, and the NSA Raise the Bar (RTB) requirements. The involved parties begin to look for funding for the assessment fees for service (often paid by a sponsoring agency or DoD branch), and testing plans are developed. The CDS specifications might go through numerous rounds of evaluation, revisions, and further refinement, which is why this is typically the longest phase of the process. The end goal is to ensure that the CDS is designed to achieve all of these requirements before it enters development.
CDS Assessment & Authorization Roles
Once all parties have agreed on the final requirements, specifications, and goals and funding has been established, the design documentation mountain of paperwork is submitted to the NCDSMO for Security Design Review (SDR).
Step 4 – Implement
Typically, by this time, design documentation is completed and submitted, and the CDS device is completed to the current specifications and requirements determined in Step 2. Once it has the blessing of the NCDSMO, the CDS is assigned to a certified testing lab with relevant experience (as CDSs do not all perform the same functions) and availability.
However, that this does not mean that the testing starts immediately, nor does it even mean that it has been scheduled (indeed, the actual device might not yet be quite ready for testing). Other factors may also still be holding up the process, for example, funding may have been approved but not yet in hand. The approval of the SDR simply kicks off the next step, Assessment.
Step 5 – Assess
In the Assessment phase, Software Design Documents (SDDs) are given to the testing lab, the device is delivered by the manufacturer to the laboratory, and a Security Test Preparedness Review (STPR) is performed to ensure that all of the paperwork is in order and the device is operational ahead of the actual testing.
Once the STPR is completed, a Technical Readiness Review (TRR) is performed to determine testing scope, assess availability of appropriate resources for testing, identify potential risks, and ensure fallback plans are in place in case of a potential issue during testing. The TRR acts as the formal entry point into hands-on testing and formally kicks off LBSA testing. Once the TRR is completed, the assessment team is officially “on-the-clock” for the test schedule and actual LBSA testing (finally) begins!
What is a Lab-Based Security Assessment?
The keystone of the modern Assessment & Authorization process for CDSs, a Lab-Based Security Assessment (LBSA) is an incredibly rigorous, months-long assessment process performed by an NCDSMO-approved laboratory, designed to test CDSs against a litany of functional and security assurance criteria. It is unique not only in its thoroughness and complexity, but also its opacity as compared to other A&A processes.
While they have been retired from official designation, there are traditionally two types of certification outcomes in LBSA testing – one for Secret and Below Interoperability (SABI), and one for Top Secret/SCI (TS/SCI) and Below Interoperability (TSABI).
The SABI process involves three primary organizations: the NCDSMO, CDTAB, and DSAWG. The NCDSMO provides personnel to perform the assessment, the CDTAB provides a recommendation to the DSAWG, and the DSAWG makes the ultimate decision to approve Authorization to Operate (ATO) a CDS at a site.
The TSABI process typically involves three primary organizations/entities: the NCDSMO, DIA, and CDTAB (a caveat here, as always in the IC, each agency has their own process and does their own authorization). The NCDSMO provides personnel to perform the assessment, the DIA provides certifiers to support overall assessment of a CDS at a particular site, the authorizing agency maintains a repository of TSABI documentation, and the CDTAB issues the ATO.
The assessment itself is performed over a 6- to 9-month period. LBSA testing outcomes are determined by a testing against Risk Decision Authority Criteria (RDAC) – soon to be replaced by the “Cross Domain Risk Model” (CDRM) – which is based on a combination of the NIST Risk Management Framework (RMF) and CNSS CDS Overlay, as well as the RTB requirements from the NSA/NCDSMO, as well as penetration testing against NSA and DIA standards. The result is a Technical Risk Rating (TRR) which the authorizing authority considers in the context of the Data Risk and Partner Risk to provide their recommendation to the designated AO.
Once the assessment is completed and the AO has the recommendation from the CDTAB, the end-user receives Security Assessment Out-Briefs (SAO) on the assessment and TRR. Regression testing is then performed on the CDS to ensure that the assessment has not affected its functionality or security. The result is the certification of the CDS and its (eventual) listing on the NCDSMO CDS baseline.
Once all of this is settled, the CDS is installed into the end-user’s site in conjunction with the end user’s completion of the Cross Domain Appendix (CDA). The CDA involves identifying the appropriate stakeholders within the end-user’s organization as a Phase 1 effort. Phase 2 activity involves identifying all the applicable information surrounding the use and operation of the CDS. This information is then used by CDSE and appropriate RMF personnel to establish a risk rating for the operational environment and implementation as Phase 3.
Once again, the CDS is submitted to additional testing and assessment, this time while connected and configured to all of the systems in the environment within which it will be operating. This is known as the Site-Based Security Assessment (SBSA). The SBSA provides a more complete picture of the security posture of the CDS and its effect on connected systems within the environment, as compared to the isolated laboratory environment. This also verifies that the CDS is deployed with the approved configuration.
After the SBSA, the final Security Assessment Report (SAR) is produced which analyzes and verifies the accuracy and completeness of the previous reports and whether the security controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting security requirements. A CDS SAR can be based solely on the SBSA or LBSA, but it usually includes both to capture a more holistic view of the entire process. This results in a last stage analysis by the AO to determine if any remaining risk factors need to be mitigated (e.g., Plan of Actions and Milestones or POA&M) before the CDS authorization for use within that organization for that end-user. At this time, the AO can authorize the CDS for operational use within the end-user mission as part of the CDA final Phase 4 activities – Authorization.
Step 6 – Authorize
SAR in hand (assuming all goes well in testing), the AO then formally signs off on the assessment of residual risk in the report and issues the Authorization to Operate (ATO), now often referred to as Cross Domain Solution Authorization (CDSA).
ATO/CDSA is the formal and explicit acceptance of the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation based on the CDS implementation, and approval of its use as such. It’s the end-goal of the Assessment & Authorization process.
At that point, the CDS is accredited for use in the active environment (and usually only for that specific type of implementation). The CDS is then submitted for Baseline listing according to the purpose and usage determined in its assessment.
Step 7 – Monitor
Though the ATO and Approval to Connect (ATC) is the end of the road for getting the CDS out into the field, the A&A process does not end there. Post-accreditation, the ISSO and PM/ISO must continue to monitor CDS software and hardware management and operation to ensure that the acceptable level of residual risk established in the assessment process is preserved. This includes meeting additional requirements as they emerge from the NCDSMO and “Raise the Bar” (RTB) initiative, and any policy requirements of the end user’s organization.
In most cases, this simply involves keeping the software up to date and the device operational, unless a significant shift in the CDS landscape occurs, as it did with RTB. However, we’ll leave that for the next post.
Have questions about CDS Assessment & Authorization or LBSA? Need assistance in navigating the process? Contact us today! We have helped numerous organizations achieve successful accreditation and ATO.
In our final installment, we’ll get into some of the other influential elements around CDS Assessment & Authorization and LBSA, including the role of the “Raise the Bar” initiative, the NCDSMO “Baselines,” and explain the relevance of formal U.S. Government A&A for non-U.S. Government applications.
See you on the next post!
