Demystifying the CNSSP-12 with Andrew D’Uva of Providence Access Company

The United States military has long enjoyed a tactical advantage from space. SATCOM, GPS and other satellite services and capabilities have given our warfighters an edge on the battlefield. But this hasn’t gone unnoticed by our adversaries.

One of the military’s largest concerns today involves the space domain. Space is increasingly congested and our adversaries are becoming increasingly capable of compromising and attacking our satellites. With many military IT capabilities, applications and services traveling over satellites, cybersecurity is becoming increasingly essential.

One of the policies that the government has put in place to ensure the security of the satellites the military is utilizing in-theater is Committee on National Security Systems Policy 12 (CNSSP-12). That policy is currently being reevaluated and refreshed, and new standards and requirements are scheduled to be released shortly.

To learn more about CNSSP-12, its history and its impact on the satellite industry, we sat down with Andrew D’Uva, the President of Providence Access Co. and the U.S. Industry Liaison on the Commercial Space Infosec Working Group (CSIWG), which is giving the satellite industry a voice in the CNSSP-12 refresh process.

During the first part of a two-part interview with Andrew, we define CNSSP-12, explore how it’s evolved over time, and how it helps the Commercial Satellite Communication or COMSATCOM industry serve the federal government. Here is what Andrew had to say:

Government Satellite Report (GSR): What is the CNSSP-12? Why is a review and update currently being done? What is the status of the CNSSP-12 review/update right now?

Andrew D’Uva: The CNSSP-12 is effectively the CNSS policy number twelve. It’s a formal policy of the CNSS, which is the Committee on National Security Systems – a U.S. government interagency committee comprised of the DOD, National Security Agency (NSA), Central Intelligence Agency (CIA), Defense Intelligence Agency (DIA), FBI, the branches of the military, and other national security-focused government agencies and entities.

The CNSS puts out policies and implementation guidance on a variety of information security issues by developing operating policies, procedures, guidelines, directives, instructions and standards. Issues can range from the use of cryptography, secure modes of communications and other security challenges facing the nation.

CNSS Policy 12 is the evolution of an earlier set of policies designed to apply to the cybersecurity of space systems used to support national security missions.

This policy isn’t new, although it periodically gets updated. In the past, it applied to the U.S. government at large. However, about ten years ago, it was updated to clarify that its requirements would apply to foreign and commercial systems used to support national security missions. That was the first time that the government said, “Here is a set of government requirements that apply to COMSATCOM operators and solution providers serving national security missions.”

In the past, COMSATCOM providers wouldn’t have to worry about a policy like this – they would just provide a commercial solution to the government. But the new, updated policy implied a number of cyber security requirements needed to be added to these systems due to their critical role in national security missions.

The policy was updated as part of a normal review process that is supposed to occur every few years. That review process is occurring again right now, with a new update anticipated to be released in early 2018. These updates and reviews are necessary because threats change, and the government’s approach to vulnerabilities has to change and evolve with them.

GSR: You mentioned that CNSSP-12 has been updated and changed over time. What has changed and what new requirements have been added?

Andrew D’Uva: CNSSP-12 levied a requirement in the past stating COMSATCOM systems that served national security missions would have to use what is called NSA-approved cryptography and cryptosystems to protect the satellite command uplink between the ground and satellite. That meant that satellite operators had to design, equip, and operate their satellites using a system that had been reviewed and approved by the NSA on their spacecraft that would apply an approved cryptographic system implementation to secure the commands between the ground and the satellites.

NSA-approved solutions protect the confidentiality and integrity of the commands, preventing third parties from seeing or altering commands in transit to the satellite. This was a requirement that applied to government systems in the past, but the CNSSP-12 policy effectively extended it to commercial systems.

As a result, almost all communications satellite companies that want to do business with the military have worked this into their satellites. It costs them more money and there’s more security involved, but it’s been largely accepted by industry. It has largely been a policy success for the government.

The policy change and update in 2012 involved a new requirement for securing the telemetry – the information traveling from the satellite to the ground regarding its health, safety and monitoring.

The update called for similar NSA-approved systems to be used to protect that information in the downlink direction. That has been slower to be adopted by industry because of a lack of available systems. However, we’re starting to see that get worked into COMSATCOM systems that are used for national security missions.

GSR: How does the CNSSP-12 enable commercial operators to better serve government needs?

Andrew D’Uva: Ultimately, all of these policies and policy changes are all about reliability and robustness. The government wants to use COMSATCOM and commercial imagery, but they want to be sure that those solutions are of high quality and available when needed. CNSSP-12 improved that resilience posture and made them more robust.

A satellite with these solutions – in contrast to one without them – is less vulnerable to being impacted by adversaries. With space becoming an increasingly contested environment, and with our adversaries recognizing the advantage that the U.S. military gains from its satellite infrastructure, this is an increasingly realistic concern for today and into the future.

GSR: How are the commercial operators participating in the CNSSP-12 refresh effort? How has this matured over time?

Andrew D’Uva: Up until this last refresh cycle, the government was the sole driver of the refresh activities. However, in the last refresh cycle, the government – specifically the NSA and DISA – established a working group called the Commercial Space Infosec Working Group (CSIWG), which was open to U.S. industry and designed to look at information security issues, including policy issues.

I serve as the U.S. Industry Liaison, and I lead the CSIWG with two other leaders from the NSA and DISA, respectively, along with a steering committee of industry executives. The CSIWG meets a couple of times a year at various sites, and – through the efforts of the NSA – they work to inform industry about the policy review process and get industry comments.

Through the CSIWG, industry leaders have authored a series of inputs and comments for the government. These comments specifically addressed the current policy, the role of commercial providers, the applicability of CNSSP-12 to commercial systems, as well as some technical issues with downlink telemetry and transmission security and how it is applied. The NSA then took these comments and inputs into the process for consideration.

The government hasn’t shared this revised CNSSP-12 yet with industry, but there are indications that some of that input was taken into account and worked into this guidance.

In part two of our two-part Q&A interview with Andrew D’Uva, he shares his predictions for what will change in the refreshed CNSSP-12, discusses how it will impact space policy for the military, and talks about the impact of CNSSP-12 on the SATCOM industry.

Share the Post: