DraftSpecification Concerning
Space Data System Standards
MAGENTA BOOK
Issue 3.0 Draft
Jan 2009
CCSDS Security Working Group
Security Architecture for Space Data Systems
AUTHORITY
Issue: / Magenta Book, Issue 3.0 DraftDate: / Jan 2009
Location: / Leatherhead, UK
(When approved) 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 Recommendations is detailed in Procedures Manual for the Consultative Committee for Space Data Systems, and the record of Agency participation in the authorization of this document can be obtained from the CCSDS Secretariat at the address below.
This Recommendation is published and maintained by:
Nick Shave / Gordon Black / Gavin Kenny
Logica (on behalf of BNSC)
Keats House
Leatherhead
Surrey
UK
Statement of Intent
The Consultative Committee for Space Data Systems (CCSDS) is an organisation 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 Recommended Standards and are not considered binding on any Agency.
This Recommended Practice is issued by, and represents the consensus of, the CCSDS members. Endorsement of this Recommended Practice is entirely voluntary. Endorsement, however, indicates the following understandings:
- Whenever a member establishes a CCSDS-related Practice, this Practice should be in accord with the relevant Recommended Practice. Establishing such a Practicedoes not preclude other provisions which a member may develop.
- Whenever a member establishes a CCSDS-related Practice, that member will provide other CCSDS members with the following information:
--The Practiceitself.
--The anticipated date of initial operational capability.
--The anticipated duration of operational service.
- Specific service arrangements shall be made via memoranda of agreement. Neither this Recommended Practice nor any ensuing Practiceis a substitute for a memorandum of agreement.
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 cancelled.
In those instances when a new version of a Recommended Practice is issued, existing CCSDS-related member Practiceand implementations are not negated or deemed to be non-CCSDS compatible. It is the responsibility of each member to determine when such Practiceor implementations are to be modified. Each member is, however, strongly encouraged to direct planning for its new Practice and implementations towards the later version of the RecommendedPractice.
FOREWORD
Through the process of normal evolution, it is expected that expansion, deletion, or modification of this document may occur. This Recommended Practiceis therefore subject to CCSDS document management and change control procedures, which are defined in the Procedures Manual for the Consultative Committee for Space Data Systems. Current versions of CCSDS documents are maintained at the CCSDS Web site
Questions relating to the contents or status of this document should be addressed to the CCSDS Secretariat at the address indicated on page i.
At time of publication, the active Member and Observer Agencies of the CCSDS were:
Member Agencies
–Agenzia Spaziale Italiana (ASI)/Italy.
–British National Space Centre (BNSC)/United Kingdom.
–Canadian Space Agency (CSA)/Canada.
–Centre National d’Etudes Spatiales (CNES)/France.
–Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
–European Space Agency (ESA)/Europe.
–Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
–Japan Aerospace Exploration Agency(JAXA)/Japan.
–National Aeronautics and Space Administration (NASA)/USA.
–Russian Federal Space Agency (FSA)/Russian Federation.
Observer Agencies
–Australian Space Office (ASO)/Australia.
–Austrian Space Agency (ASA)/Austria.
–Belgian Science Policy Office (SPO)/Belgium.
–Centro Tecnico Aeroespacial (CTA)/Brazil.
–ChineseAcademy of Space Technology (CAST)/China.
–Communications Research Laboratory (CRL)/Japan.
–Danish Space Research Institute (DSRI)/Denmark.
–European Organization for the Exploitation of Meteorological Satellites (EUMETSAT)/Europe.
–European Telecommunications Satellite Organization (EUTELSAT)/Europe.
–Hellenic National Space Committee (HNSC)/Greece.
–Indian Space Research Organization (ISRO)/India.
–Industry Canada/Communications Research Centre (CRC)/Canada.
–Institute of Space and Astronautical Science (ISAS)/Japan.
–Institute of Space Research (IKI)/Russian Federation.
–KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
–MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
–Ministry of Communications (MOC)/Israel.
–National Oceanic & Atmospheric Administration (NOAA)/USA.
–National Space Program Office (NSPO)/Taipei.
–Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.
–Swedish Space Corporation (SSC)/Sweden.
–United States Geological Survey (USGS)/USA.
DOCUMENT CONTROL
Version / Date / Status/Remarks / Author1.0 / Nov 2004 / First Issue
1.1 / Nov 2004 / Update for comments
1.1 / April 2005 / Update to include Key Man
1.2 / Sept 2005 / Update for new RASDS doc.
1.4 / May 2006 / Review and updates
1.5 / June 2006 / Updates
1.6 / January 2007 / Updates
1.7 / January 2007 / Updates
2.0 / Sep 2008 / Incorporates updates agreed at Mar08 Washington meeting. Produced for Oct08 Berlin meeting review. / Gordon Black
3.0 / Jan09 / Incorporates updates agreed at Oct08 Berlin meeting. Produced for Apr09 Colorado Springs meeting review. / Gordon Black
CONTENTS
1.Introduction
1.1.Purpose
1.2.Document Structure
1.3.Glossary of Terms
2.THE CCSDS REFERENCE ARCHITECTURE
2.1.Background
2.2.CCSDS Reference Architecture
3.General Security Principles
3.1.Physical Security
3.2.Information Security
3.3.Transmission Security (TRANSEC)
3.4.Procedures
3.5.Document Focus......
3.6.Mission Security Checklist
4.Security and the CCSDS Reference Architecture
4.1.Security and the Enterprise View
4.2.Security and the Connectivity View
4.3.Security and the Functional View
4.4.Security and the Information View......
4.5.Security and the Communications View
4.6.Physical Security
5.SECURITY Architecture Requirements
5.1.Open-standards based
5.2.Protection through security mechanisms
5.3.Expandability
5.4.Flexibility
5.5.Key Management
5.6.Algorithm Selection
5.7.Fault Tolerance
6.MISSIOn PROFILES
6.1.Manned Space
6.2.Earth Observation
6.3.Communications
6.4.Scientific
6.5.Navigation
6.6.Multi-organisational Spacecraft
7.Proposed Architecture
7.1.Requirements
7.2.Services
7.3.Proposed Security Architecture
7.4.CCSDS Security Core Suite
7.5.Security Core Suite Configuration......
7.6.Expandability
7.7.Emergency Operations
8.References and Further Information
1
Security Architecture for Space Data Systems
1.Introduction
This document presents a Security Architecture for Space Data Systems, which is hereafter referred to as‘SASDS’.
This architecture (SASDS) is based on the Reference Architecture for Space Data Systems [Ref 1] developed by the CCSDS Architecture Working Group.
1.1.Purpose
This security architecture (SASDS) will be used for the following purposes:
a)To establish an overall CCSDS framework for the incorporation of security into the data systems of space missions;
b)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;
c)To provide a source of information for the security architect’s on a space mission to use to develop the system security design;
d)To facilitate development of standards in a consistent way so that any standard can be used with other appropriate standards in a system.
1.2.Document Structure
Section 2 provides an introduction into how the Security Architecture will co-exist with the work being carried out by the CCSDS Architecture working group.
Section 3 discusses the security concepts that need to be addressed by the security architecture.
Section 4 looks at how the security concepts and the CCSDS architecture outlined in sections 2 and 3 relate to each other.
Section 5 sets some high level principles and the scope that the security architecture must address.
Section 6 develops a series of mission profiles that are used to help identify where security is required, what the issues are and what solutions are applicable.
Section 7 introduces the proposed security architecture and shows how this fulfils the requirements developed in the proceeding sections.
1.3.Glossary of Terms
The following terms are defined within the security context that they are used within this document.
Term / MeaningAuthentication / The process for verifying that a user, computer, service, data or process is who or what it claims to be.
Availability / Prevention of unauthorized withholding of information
or resources
Confidentiality / Prevention of unauthorized disclosure of information
Integrity / Prevention of unauthorized modification of information
Security Architecture / The framework which will supply the design structure needed to ensure the systems developed will meet their security and mission requirements.
Security Design / The specific security components selected and combined to meet the mission’s security needs.
System / A physical instantiation of a design.
2.THE CCSDS REFERENCE ARCHITECTURE
2.1.Background
Today, ubiquitous 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 accessible to potential attackers. Thesetwo facts make mission operations more dangerous than in the past when operations were carried out over closed, mission-specific networks and computer and communication resources were not powerful and widespread. The security risks to both spacecraft and ground systems have increased to the point where CCSDS must adopt existing or develop specific (as necessary) information security standards in order to protect mission critical resources and protect sensitive mission information.
CCSDS needsa Security Architecture to make complete its overall System Architecture. CCSDS must promote secure interoperability for space missions, and the incorporation of security within the system. Also, a mission risk assessment statement is required in order to allow mission planners to better understand the risks that they should plan to counter via security technologies. In due course, information security standards should be developed or as an accompaniment to its communications and mission operations standards.
Key factors to consider for space missions are the vulnerability of sophisticated resources to potential attackers and the increased awareness of the public opinion about the consequences of the malicious use of public assets. For example, hacking into the telecommand system of any Mars mission would be extremely visible, extremely embarrassing, and potentially very costly for any of the CCSDS member Agencies.
2.2.CCSDS Reference Architecture
The CCSDS Reference Architecture (RASDS) uses multiple views to present space data systemsarchitectures. Since space data systems have various aspects and it is not easy to depict these various aspects in a single framework, the architecture of a space data system is described with multiple views, each focusing on different concerns associated with the system.Note that this is equally true of ground systems.
A view is a form of abstraction achieved 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 [1].
Five different, basic Views are described in [1]. Theyare:
1) Enterprise View: The motivation for the Enterprise View is that we have complex organisational 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 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 among the organisations are described in terms of the roles, responsibilities and policies of the organisations; and the interactions among the organisations are described in terms of agreements and contracts.
2) Connectivity View:The motivation for the Connectivity View is that we have both ground-based systems and flight system elements that are in motion through space and consequently an evolving network topology and connectivity issues associated with pointing, scheduling, long round trip light times, and low signal-to-noise ratios, all of which require special protocols and functionality to deal with. 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 View: The motivation for the Functional View is that we have functional elements and their logical interactions that are separate 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 View: The motivation for the Information View is that we have data objects with different structures, relationships, and policies that 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 View:The motivation for the Communications View is that we have layered sets of communications protocols to support communications among the functional elements that need to 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 mechanisms of information transfer that occurs among physical entities (i.e., Nodes) in a space data system.
3.General Security Principles
The ‘security view’ of the world is similar to what has been outlined in chapter 2 above. The security world is also split into different views but there are various differentsecurity aspects of space systems that need to be considered:
- Physical Security
- Information Security (INFOSEC)
- Transmission Security (TRANSEC)
3.1.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 having sophisticated firewalls to stop people hacking into a computer to steal the data stored in it, if they can just walk in and pick up the whole computer and walk out with it. Physical security is concerned with providing physical barriers such as guards, fences, locked rooms, etc. Whilst not core to this document, physical and personnel security needs must be considered.
3.2.Information Security
INFOSEC is concerned with the protection of information as it travels from one place to another and when it resides in a location. The main principles that are associated with information security are:
- Authentication of Users and Computers
- Confidentiality of the Data
- Integrity of the Data
- Availability of the 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 this could be when the two ends of a communication channel verify the identity of the entity at the other end of the channel or when a user logs on to a system.
Confidentiality is the means by which a system ensures that only those authorised users, services or systemsaccessescontrolled 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 this is outside the scope of this architecture, although some aspects will be mentioned later in this document.
Integrity is the process of ensuring that data has not changed either in transit or since it was last verified. This can either be achieved as a by-product of an encryption process or by using a Message Authentication Code (MAC).
Availability is the means by which the timely accessibility of a system 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.3.Transmission Security (TRANSEC)
TRANSEC is concerned with moving data between two points in a secure fashion. It 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 and an example is use of spread spectrum or frequency hopping techniques on an RF link.
3.4.Procedures
The above schemes describe different techniques and technologies that can be used to protect information, however all these must be used in conjunction with written policies such as System Operating Procedures, also known as Standard Operating Procedures (SOP), and a System Security Procedures (SSP) which describe what procedures are required both for computer systems and the people that use them.
3.5.Document Focus
While both physical security and procedural security are essential elements of any security system they are not the focus of this document and will not be discussed any further. Both will be unique to any system implemented and must be developed by experienced security practitioners specifically for that enterprise, system and mission.
This document is principally focussed on the combination of technology, barriers and protocols plus their support systems that are needed to protect space missions and their data.
3.6.Mission Security Checklist
Every space mission should develop the following security documents in the order listed:
- Security Policy
- Security Interconnection Policy
- Mission Security Risk Assessment
- Mission Security Architecture
- Security Operating Procedures
3.6.1.Security Policy
The mission security policy should be observant of any higher level national or agency security policies but should clearly state: