ISO 20214:2015

INTERNATIONAL ISO
STANDARD 20214
First edition
2015-08-15
Space data and information transfer
systems — Security architecture for
space data systems
Systèmes de transfert des informations et données spatiales —
Architecture de sécurité pour les systèmes de données spatiales
Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 20214 was prepared by the Consultative Committee for Space Data Systems (CCSDS) (as
CCSDS 351.0-M-1, November 2012) and was adopted (without modifications except those stated in clause 2
of this International Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee
SC 13, Space data and information transfer systems.

Recommendation for Space Data System Practices
SECURITY
ARCHITECTURE FOR
SPACE DATA SYSTEMS
RECOMMENDED PRACTICE
CCSDS 351.0-M-1
MAGENTA BOOK
November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
AUTHORITY
Issue: Recommended Practice, Issue 1
Date: November 2012
Location: Washington, DC, USA
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS documents is detailed in Organization and Processes for
the Consultative Committee for Space Data Systems (CCSDS A02.1-Y-3), and the record of
Agency participation in the authorization of this document can be obtained from the CCSDS
Secretariat at the address below.

This document is published and maintained by:

CCSDS Secretariat
Space Communications and Navigation Office, 7L70
Space Operations Mission Directorate
NASA Headquarters
Washington, DC 20546-0001, USA
CCSDS 351.0-M-1 Page i November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of its members. The Committee meets periodically to address
data systems problems that are common to all participants, and to formulate sound technical
solutions to these problems. Inasmuch as participation in the CCSDS is completely
voluntary, the results of Committee actions are termed Recommendations and are not in
themselves considered binding on any Agency.
CCSDS Recommendations take two forms: Recommended Standards that are prescriptive
and are the formal vehicles by which CCSDS Agencies create the standards that specify how
elements of their space mission support infrastructure shall operate and interoperate with
others; and Recommended Practices that are more descriptive in nature and are intended to
provide general guidance about how to approach a particular problem associated with space
mission support. This Recommended Practice is issued by, and represents the consensus of,
the CCSDS members. Endorsement of this Recommended Practice is entirely voluntary
and does not imply a commitment by any Agency or organization to implement its
recommendations in a prescriptive sense.
No later than five years from its date of issuance, this Recommended Practice will be
reviewed by the CCSDS to determine whether it should: (1) remain in effect without change;
(2) be changed to reflect the impact of new technologies, new requirements, or new
directions; or (3) be retired or canceled.
In those instances when a new version of a Recommended Practice is issued, existing
CCSDS-related member Practices and implementations are not negated or deemed to be non-
CCSDS compatible. It is the responsibility of each member to determine when such Practices
or implementations are to be modified. Each member is, however, strongly encouraged to
direct planning for its new Practices and implementations towards the later version of the
Recommended Practice.
CCSDS 351.0-M-1 Page ii November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommended Practice is therefore subject
to CCSDS document management and change control procedures, which are defined in the
Organization and Processes for the Consultative Committee for Space Data Systems
(CCSDS A02.1-Y-3). Current versions of CCSDS documents are maintained at the CCSDS
Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 351.0-M-1 Page iii November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
DOCUMENT CONTROL
Document Title Date Status
CCSDS Security Architecture for Space Data November Original issue
351.0-M-1 Systems, Recommended Practice, 2012
Issue 1
CCSDS 351.0-M-1 Page iv November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
CONTENTS
Section Page
1 INTRODUCTION . 1-1

1.1 PURPOSE AND SCOPE . 1-1
1.2 DOCUMENT STRUCTURE . 1-2
1.3 GLOSSARY OF TERMS . 1-3
1.4 NOMENCLATURE . 1-3

2 THE CCSDS REFERENCE ARCHITECTURE . 2-1

2.1 INTRODUCTION . 2-1
2.2 BACKGROUND . 2-1
2.3 CCSDS REFERENCE ARCHITECTURE . 2-1

3 GENERAL SECURITY PRINCIPLES . 3-1

3.1 GENERAL . 3-1
3.2 PHYSICAL SECURITY . 3-1
3.3 INFORMATION SECURITY . 3-1
3.4 TRANSMISSION SECURITY . 3-2
3.5 PROCEDURES . 3-2
3.6 MISSION SECURITY DOCUMENTATION . 3-2

4 SECURITY AND THE CCSDS REFERENCE ARCHITECTURE . 4-1

4.1 OVERVIEW . 4-1
4.2 SECURITY AND THE ENTERPRISE VIEW . 4-1
4.3 SECURITY AND THE CONNECTIVITY VIEW . 4-3
4.4 SECURITY AND THE FUNCTIONAL VIEW . 4-5
4.5 SECURITY AND THE INFORMATION VIEW . 4-7
4.6 SECURITY AND THE COMMUNICATIONS VIEW . 4-9

5 SECURITY ARCHITECTURE PRINCIPLES . 5-1

5.1 OVERVIEW . 5-1
5.2 OPEN STANDARDS . 5-1
5.3 PROTECTION THROUGH LAYERED SECURITY MECHANISMS . 5-1
5.4 EXPANDABILITY . 5-1
5.5 FLEXIBILITY . 5-1
5.6 INTEROPERABILITY . 5-1
5.7 KEY MANAGEMENT . 5-2
5.8 ENCRYPTION ALGORITHM SELECTION . 5-2
CCSDS 351.0-M-1 Page v November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
CONTENTS (continued)
Section Page
5.9 KERCKHOFF’S PRINCIPLE . 5-2
5.10 FAULT TOLERANCE . 5-2

6 MISSION PROFILES . 6-1

6.1 OVERVIEW . 6-1
6.2 GENERAL . 6-1
6.3 HUMAN SPACEFLIGHT . 6-1
6.4 EARTH OBSERVATION . 6-2
6.5 COMMUNICATIONS . 6-2
6.6 SCIENTIFIC . 6-2
6.7 NAVIGATION . 6-3
6.8 MULTI-ORGANIZATIONAL SPACECRAFT . 6-4

7 PROPOSED ARCHITECTURE . 7-1

7.1 REQUIREMENTS . 7-1
7.2 SERVICES . 7-1
7.3 PROPOSED SECURITY ARCHITECTURE . 7-2
7.4 CCSDS SECURITY CORE SUITE . 7-3
7.5 SECURITY CORE SUITE CONFIGURATION . 7-6
7.6 EXPANDABILITY . 7-8
7.7 EMERGENCY OPERATIONS . 7-10

ANNEX A SECURITY CONSIDERATIONS (INFORMATIVE) . A-1
ANNEX B INFORMATIVE REFERENCES (INFORMATIVE) .B-1
ANNEX C ABBREVIATIONS AND ACRONYMS (INFORMATIVE) . C-1
Figure
1-1 Relationship between This and Other CCSDS Documentation . 1-2
4-1 Enterprise View . 4-2
4-2 Connectivity View and Example Security Application Points . 4-4
4-3 Example Analysis of the Functional View (Functions with Specific Security
Requirements Shown in Red) . 4-6
4-4 Information View and Security Implications . 4-7
4-5 Communications View and Security Layer Choices . 4-9
7-1 CCSDS Space Mission Protocols and Security Options . 7-4
7-2 CCSDS Security Core Suite . 7-6
CCSDS 351.0-M-1 Page vi November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
CONTENTS (continued)
Figure Page
7-3 Example Security Architecture for ‘Mission 1’ . 7-8
7-4 Security Architecture for a Simple Mission, Which Uses Only the
Network Layer Security Subsystem from the Core Suite . 7-9
7-5 A Simple Mission Using Its Own Transport Layer Security . 7-10

CCSDS 351.0-M-1 Page vii November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
1 INTRODUCTION
1.1 PURPOSE AND SCOPE
1.1.1 PURPOSE
This document is intended as a high-level systems engineering reference to enable engineers
to better understand the layered security concepts required to secure a space system. As such,
this document is a Security Architecture for Space Data Systems (SASDS).
This architecture uses the views described in the Reference Architecture for Space Data
Systems (reference [B1]) developed by the CCSDS Architecture Working Group.
The SASDS will be used:
– to establish an overall CCSDS conceptual framework for the incorporation of security
into the data systems of space missions;
– to define common language and representation so that risks, requirements, and
solutions in the area of security within space data systems can be readily
communicated;
– to provide a source of information for the security architects on a space mission to
use to develop the system security design;
– to facilitate development of standards in a consistent way so that any standard can be
used with other appropriate standards in a system.
1.1.2 SCOPE
This document presents a security reference architecture for space data systems and is
intended to provide a standardized approach for description of security within data system
architectures and high-level designs, which individual working groups may use within
CCSDS.
For further information regarding security’s role in space systems, the reader is directed to
the supporting CCSDS documentation listed in annex B.
CCSDS 351.0-M-1 Page 1-1 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
1.1.3 RELATIONSHIP WITH OTHER CCSDS DOCUMENTS
The relationship between this and other CCSDS documents is shown in figure 1-1 below:

Figure 1-1: Relationship between This and Other CCSDS Documentation
1.2 DOCUMENT STRUCTURE
Section 2 provides an introduction into how the security architecture uses the Reference
Architecture for Space Data Systems (RASDS).
Section 3 discusses the security concepts that need to be addressed by any security architecture.
Section 4 examines the security concepts and shows how the CCSDS architecture outlined in
sections 2 and 3 relate to each other.
Section 5 establishes high-level principles and the scope that the security architecture addresses.
iles which help identify where security is
Section 6 illustrates a series of mission prof
required, what the issues are, and what solutions are applicable.
Section 7 specifies the security reference architecture.
Annex A addresses security considerations pertaining to use of this Recommended Practice
for developing real security architectures for missions.
Annex B lists informative references.
Annex C is a glossary of abbreviations and acronyms used in the document.
CCSDS 351.0-M-1 Page 1-2 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
1.3 GLOSSARY OF TERMS
A full glossary of security terms used within this document is available in reference [B9].
1.4 NOMENCLATURE
1.4.1 NORMATIVE TEXT
The following conventions apply for the normative specifications in this Recommended
Standard:
a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;
b) the word ‘should’ implies an optional, but desirable, specification;
c) the word ‘may’ implies an optional specification;
d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
NOTE – These conventions do not imply constraints on diction in text that is clearly
informative in nature.
1.4.2 INFORMATIVE TEXT
In the normative sections of this document, informative text is set off from the normative
specifications either in notes or under one of the following subsection headings:
– Overview;
– Background;
– Rationale;
– Discussion.
CCSDS 351.0-M-1 Page 1-3 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
2 THE CCSDS REFERENCE ARCHITECTURE
2.1 INTRODUCTION
RASDS (reference [B1]) describes a method for analyzing complex space system
architectures. This section briefly introduces these concepts prior to exploring how they can
be used to address security concerns during system design. Reference [B1] should be
consulted for more information on RASDS.
2.2 BACKGROUND
Today, ubiquitous terrestrial network connectivity among principal investigators and mission
operations has become standard. At the same time, computer processing power and
communication resources have progressed steadily to the point that they are easily accessible
to potential attackers. These two facts put mission operations more at risk than in the past
when operations were carried out over closed, mission-specific networks, and computer and
communication resources were not as powerful or widespread. The security risks to both
spacecraft and ground systems have increased to the point where CCSDS must foster
adoption of specific information security standards (as necessary) in order to protect mission-
critical resources and sensitive mission information.
CCSDS promotes secure interoperability for space missions and the incorporation of security
within the system. This security architecture helps to complete CCSDS’s overall reference
architecture by adding specific guidance for developing the security aspects of a system
architecture. The security architecture for a mission should respond to threats identified via a
risk assessment, which is necessary to provide mission planners with a better understanding
of the risks that they should plan to counter via security technologies.
Key factors to consider for space missions are the vulnerability of sophisticated space or
ground resources to potential attackers the consequences of the malicious use of public
assets, including consequences of public perception. For example, hacking into the
telecommand system of any Mars mission would be extremely visible, extremely
embarrassing, and potentially very costly for affected CCSDS member agencies.
2.3 CCSDS REFERENCE ARCHITECTURE
RASDS employs multiple views to present a space data system architecture. Space data
systems are complex, consist of hardware, software, and organizations, and are frequently
composed of elements belonging to different organizations, some of which are on the ground,
others of which are in space.  Because of the complexity of these systems, it is difficult to
depict all of these various aspects in a single framework. As a result, the system architecture
is described with multiple views, each focusing on different concerns associated with the
system.
CCSDS 351.0-M-1 Page 2-1 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
A view is a form of abstraction achieved by using a selected set of architectural concepts and
structuring rules in order to focus on particular concerns within a space data system. Further
background information is available in RASDS (reference [B1]). Each view is developed in
the context of a specific viewpoint specification.
Five types of viewpoints and associated views are described in RASDS:
1) Enterprise Viewpoint: The motivation for Enterprise Views is that there are complex
organizational relationships involving spacecraft, instruments, ground systems, scientists,
staff, and contractors that are distributed among multiple organizations (space agencies,
science institutes, companies, etc.). The Enterprise View is used to address these
organizational relationship aspects of space data systems. The Enterprise View describes the
organizations involved in a space data system and the relationships and interactions among
them. The relationships are described in terms of the roles, responsibilities, and policies of
the organizations; and the interactions among the organizations are described in terms of
agreements and contracts.
2) Connectivity Viewpoint: The motivation for Connectivity Views is that the physical
deployment and behavior of both ground-based and flight-system elements need to be
considered. The flight elements are in motion through space and consequently cause
network topology and connectivity issues associated with pointing, scheduling, delays due to
round-trip light times, and low signal-to-noise ratios. To deal with these issues, special
protocols and functionality are required. The Connectivity View is used to address these
aspects of space data systems. The Connectivity View describes the physical structure and
physical environments of a space data system.
3) Functional Viewpoint: The motivation for Functional Views is that the behavior of
functional elements and their logical interactions should be considered separately from the
engineering concerns of where functions are housed, how they are connected, which
protocols are used, or what language is used to implement them. The Functional View is used
to address these functional aspects of space data systems. The Functional View describes the
functional structure of a space data system and how functions interact with each other.
4) Information Viewpoint: The motivation for Information Views is that descriptions of
data objects with different structures, relationships, and policies must be provided. These
data objects are passed among the functional elements and managed (that is, stored, located,
accessed, and distributed) by information infrastructure elements. The Information View is
used to address these aspects of space data systems. The Information View looks at the space
data systems from the perspective of the Information Objects that are exchanged among the
Functional Objects.
5) Communications Viewpoint: The motivation for Communications Views is that the
layered sets of protocols used to support communications among the functional elements
must be described. These must meet the requirements imposed by the connectivity and
operational challenges. The Communications View is used to address these aspects of space
data systems. The Communications View describes the protocol stacks and mechanisms of
information transfer that occur among physical entities (i.e., Nodes) in a space data system.
CCSDS 351.0-M-1 Page 2-2 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
3 GENERAL SECURITY PRINCIPLES
3.1 GENERAL
Security aspects of a Space Data System architecture may also be addressed using the same
set of viewpoints as those discussed in section 2. These views can describe the security
aspects from functional, physical, or communications perspectives, and are in line with the
standard approaches used in literature:
– physical security (Enterprise, Connectivity Viewpoints);
– information security (INFOSEC, Connectivity, Communications, Enterprise,
Functional and Information Viewpoints);
– transmission security (TRANSEC, Connectivity, Communications Viewpoints).
3.2 PHYSICAL SECURITY
Physical security is concerned with protecting the actual equipment that makes up a system. It
is often noted that there is little point to having sophisticated firewalls to stop people hacking
into a computer to steal the data stored in it, if they can just walk in, pick up the whole
computer or hard disk(s), and walk out with it. Physical security is concerned with providing
barriers such as guards, fences, locked rooms, etc. While not the primary focus of this
document, physical and personnel security requirements must be considered, and these may be
addressed in a Connectivity View (physical aspects) or in an Enterprise View (personnel).
3.3 INFORMATION SECURITY
INFOSEC is concerned with the protection of information whether ‘at rest’ or in transit from
one place to another. The main principles associated with information security are:
a) authentication of users and computers;
b) confidentiality of data;
c) integrity of data;
d) availability of data.
Authentication is the means by which a computer (or system) verifies the identity of an agent
on the system, be this a person, service, or computer. For example, authentication could
occur when the identities of entities on the ends of a communication channel are verified or
when a user logs on to a system.
Confidentiality is the means by which a system ensures that only authorized users, services,
or systems access controlled data. Confidentiality is often achieved by the use of encryption.
There are many different methods by which encryption can be employed and many different
algorithms can be used. A full discussion of encryption is outside the scope of this
CCSDS 351.0-M-1 Page 3-1 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
architecture, although some aspects will be mentioned later in this document. (See
reference [B2] for more information.)
Integrity is the process of ensuring that data has not undergone an unauthorized change either
in transit or since it was last verified. This can be achieved either as a byproduct of an
encryption process, by using a Message Authentication Code (MAC), or by using a Digital
Signature.
Availability is the means by which the timely accessibility of a system by an authorized
entity is assured. For example, it can be measured in uptime. This issue often manifests in
mitigation against Denial-of-Service attacks, whether intended and malicious or accidental.
3.4 TRANSMISSION SECURITY
TRANSEC provides mechanisms for hiding the presence of the communications link and/or
preventing the link from being jammed. Thus TRANSEC dictates Physical Layer schemes
for securing a link between two points. An example is use of spread spectrum or frequency
hopping on an RF link. This should be addressed in a Communications View.
3.5 PROCEDURES
The System-specific Security Requirements Statement (SSRS) defines the minimum security
requirements necessary for the system to be considered sufficiently secure for the intended
mission. The above schemes describe different techniques and technologies for fulfilling an
SSRS.
The technical implementations must be used in conjunction with written policies, or Security
Operating Procedures (SECOPS) which describe what is required both for the systems and
the people that use them. Procedures, policies, requirements, and other constraints will
typically be addressed in an Enterprise View.
3.6 MISSION SECURITY DOCUMENTATION
3.6.1 GENERAL
Every space mission should develop the following security documents in the order listed:
a) Security Policy;
b) Security Interconnection Policy;
c) Mission Security Risk Assessment;
d) Mission Security Architecture;
e) Security Operating Procedures.
CCSDS 351.0-M-1 Page 3-2 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
3.6.2 SECURITY POLICY
The mission security policy should be observant of any higher-level national or agency
security policies but should clearly state:
a) the confidentiality classification, and therefore level of protection, of all the
information associated with the mission, both live and archive, telemetry,
telecommand, and ground systems;
NOTE – This classification is relevant to all of Confidentiality, Integrity, and
Availability aspects of the information.
b) the roles and responsibilities of those who have access to the system;
c) the integrity requirements of the system;
d) the availability requirements of the system.
3.6.3 SECURITY INTERCONNECTION POLICY
The mission interconnection policy should clearly state;
a) which organizations will be allowed to interconnect to fulfill the mission;
b) the type of connections that will be made, e.g., continuous or intermittent;
c) the interface of these connections, e.g., dedicated link, Internet, or dial up;
d) the classification of the information going over those links.
For further information, the CCSDS Guide for Secure System Interconnection (CCSDS
350.4-G-1, reference [B8]) should be referenced.
3.6.4 RISK ASSESSMENT
The risk assessment considers the type of the mission and the information security risks to
that mission. It is important to consider all parts of the mission architecture during all phases
of the mission because the risk profile will change as the mission progresses. Reference [B7]
contains a more detailed discussion of mission risk assessment.
It should be noted that the threat assessment will use the outputs of the Security Policy and
Security Interconnection documents to help identify attack vectors and the value of the data
and assets to be protected.
CCSDS 351.0-M-1 Page 3-3 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
3.6.5 MISSION SECURITY ARCHITECTURE
The security architecture for the mission is the logical system design with a focus on
security. It should be developed in step with, and as part of, the system architecture.
The security architecture will shape how the system architecture is formed and will need to
be developed and adapted as the system design matures to ensure that the mission goals can
be achieved while maintaining compliance with the Security Policy.
The Security Architecture will use the system security requirements, System Security Policy,
Security Interconnection Policy, and the results of the Risk Assessment as inputs.
NOTE – It is strongly advised that the security architecture be developed in parallel with
the overall system design in order to avoid the possibility of costly and time-
consuming system redesigns which might be necessary to accommodate required
security features. Some system vulnerabilities can be determined only after the
detailed design of key security-related equipment has been submitted to
evaluation. Hence, it is possible that a second iteration may be required.
3.6.6 SECURITY OPERATING PROCEDURES
The SECOPS define how the users of the system are expected to operate it, and what is and
is not allowed. They allow the security designer to consider the use of procedural measures
to protect system security and are an integral part of the system design. The SECOPS form
part of the overall system concept of operations.
Trades-offs between the use of procedures vs. technology allow for more elegant solutions
without the need for resorting to overly complex and costly, purely technological solutions.

CCSDS 351.0-M-1 Page 3-4 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
4 SECURITY AND THE CCSDS REFERENCE ARCHITECTURE
4.1 OVERVIEW
This section introduces a series of recommendations for describing the security aspects of
system design for each of the viewpoints identified in the CCSDS Reference Architecture. It
also provides guidance on how to analyze the system design from each of these viewpoints.
4.2 SECURITY AND THE ENTERPRISE VIEW
4.2.1 GENERAL
Security within the Enterprise View is concerned with the concept of policies and trust
between organizations, particularly where cross support and interoperability are required.
Many different organizations may be involved in developing and supporting a space mission.
In order to ensure that a consistent approach to security is applied across these organizations,
a Security Policy should be established explaining the high-level security requirements,
roles, and responsibilities for the mission.
Some form of agreement must exist between participating organizations within the mission.
This may take the form of, for example, a Memorandum of Understanding (MoU), a
Memorandum of Agreement (MoA), a contract, or a teaming agreement. These agreements
should refer to the Security Policy for the mission and state that all participants must adopt
and enforce the policy. The means for doing governance and for assessing compliance must
also be clearly articulated.
There may be conflicts between organizations with regard to security policy enforcement. To
reduce the impact of problems associated with security conflicts, the lead agency must work
with its partners to ensure that the security policy is adopted and enforced by all
organizations involved.
An example of a security consideration within the Enterprise View, as illustrated in
figure 4-1, is the use of an agency’s Telemetry, Tracking, and Control (TT&C) network by
another agency. The owning agency is likely to have network security requirements that
other organizations must adhere to when connecting to its network. Furthermore, the agency
offering TT&C support services may also have access to mission data as part of a quid-pro-
quo arrangement (e.g., the science team in the example below).  These interfaces and
technical data exchange points should be defined and documented; agreements should be
established regarding their management and implementation (for example, the use of security
mechanisms relating to access control, authentication, and confidentiality). All of these
interfaces and security requirements must be captured within the contract or service
agreement between Agencies.
CCSDS 351.0-M-1 Page 4-1 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
Operations
Domain
Agency QRS
Agency ABC
Mission Q
Mission Q
Support Organizations
Organizations
SciScieencncee
Tracking
SpSpaaccececrrafaftt
Plan
Team
Team
GrGrououndnd SpSpacacee
Tracking Tracking
Tracking Tracking
NeNetwotworrkk NetNetwworkork
Organization Organization Support Instrument
Organization Organization
Control
Agreement
Tracking
Team
Configuration
Observation
OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOObbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssseeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaattttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiioooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooonnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
S/C Control
PlPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPllllllllllllllllllllllllllllllllannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnssssssssssssssssssssssssssssssssss
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPlllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaannnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
Team
Science Science
Team
Team
Data
Access
Agreement
Figure 4-1: Enterprise View
4.2.2 SECURITY RISKS HIGHLIGHTED BY THE ENTERPRISE VIEW
The Enterprise View illustrates where information needs to go in order to be useful and
which organizations need to communicate in order for a mission to be a success.
There are two distinct trust relationships that need to be considered by the security
architecture:
a) If all of the agencies involved in a mission trust each other (at least at a system level)
then the entire security of the system is as robust as the weakest agency and the risks
associated with interconnected systems. In this scenario all the agencies must agree
to a specific level of security and trust each other to abide by that policy.
b) If the agencies do not fully trust each other, there are two methods for interacting
(assuming the agencies still need to cooperate in order to complete the mission). The
first is for them to concentrate on the infrastructure and the second is for them to
concentrate on the data. When an agency concentrates on infrastructure, it isolates all
the systems that must deal with an untrusted entity from all its other systems. In this
way it limits the damage that can be caused by a security breach such as a virus. This
is expensive, as it tends to replicate existing systems and limits how information for
that mission can be processed and compared or combined with other information.
When an agency concentrates on the data, it places strong barriers between itself and
the untrusted entity so that it can check all communications between itself and the
other enterprise.
The type of relationship between the organizations will influence the nature of the
interactions they will have and how they ensure security. Another factor to consider is where
CCSDS 351.0-M-1 Page 4-2 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
they interact. This can be on the ground, in space, between spacecraft, or in the case of the
multi-mission spacecraft as discussed in 6.8, onboard a spacecraft.
Examining the mission structure through the Enterprise View reveals what Security Policies
need to be developed, and identifies where the trust relationships will lie. For example, this
approach should help identify agreements that must be reached between agencies. The
technical system and security architecture should seek to enforce the Security Policies and
agreements wherever possible.
4.3 SECURITY AND THE CONNECTIVITY VIEW
4.3.1 GENERAL
The Connectivity View, as illustrated in figure 4-2, reflects the physical nodes that compose
the space mission operations data network, where the nodes are located, and how the nodes
communicate.
In traditional terrestrial communication systems, full-period connectivity is assumed to be
available between nodes at all times. This is not the typical case when dealing with
spacecraft.
With the exception of geostationary missions, orbital mechanics will result in the disruption
of line-of-sight communications from any given ground station. For deep-space missions,
power must be conserved, and communications systems may need to be deactivated for
periods of time. Spacecraft science observational schedules may result in pointing that
precludes concurrent communications, or planetary bodies may obscure the radio link as the
spacecraft passes behind them. In addition, space communications links are often
asymmetric, with two or more orders of magnitude difference in forward data rates versus
return data rates.
Any security enforcing system applied to the communications link must be able to cope with
breaks in communications, both expected and unexpected, and communications asymmetries,
and must be able to recover gracefully without rendering a node inactive.
Breaks in communications are not the only factor introduced by the Connectivity View.
Speed and quality of communications are also issues. While not a major problem for ground-
based systems and near-Earth missions, communications from deep-space missions will
encounter speed-of-light communications delay and often reduced link quality. Delays due
to communications paths may range from a second or less to many tens of minutes or even
hours for outer planets missions. For this reason, many connection-oriented protocols used
in terrestrial environments will not work in space systems without modification (for example,
if a handshaking process is used during the establishment of a communication session).
What is true of all missions is the tradeoff of security overhead against the mission’s ability
to achieve its goal. All security mechanisms add overhead, but in bandwidth-limited space
environments, overhead must be reduced to the absolute minimum required for security. A
CCSDS 351.0-M-1 Page 4-3 November 2012
SECURITY ARCHITECTURE FOR SPACE DATA SYSTEMS
security system that uses 90% of the available communications re
...