Space Platform Overlay

1. Characteristics and Assumptions

A space system is a defined set of interrelated processes, communications links, and devices
providing specified products or services to users or customers from a space platform(s), or
directly necessary for the proper operation of the space platform(s). Examples of space system
devices or components are space platforms; payloads; space bus/payload operations centers;
mission/user terminals for initial reception, processing, and/or exploitation; and launch systems.
These devices or components can be categorized into four segments: space segment, launch
segment, ground segment, and user segment. Space platforms and payloads constitute the space
segment. Launch vehicles, launch ranges, launch site services, and payload adapters constitute
the launch segment. Space bus/payload operations centers constitute the ground segment.
Mission terminals constitute the user segment. The life cycle of a space platform consists of the
following phases: on-ground development, on-ground testing, pre-operational testing in space,
operations in space, and decommissioning.

This overlay applies to information technology (IT) components of unmanned space platforms in
the space segment of national security space systems (whether experimental1 or operational).
This overlay does not apply to ground or user segments or to the launch segment, nor does it
address the space platform while it is in development or testing on the ground.2 The assumptions
made in this section about the applicable unmanned space platforms do not necessarily hold true
for manned space platforms or the launch, user, or ground segments.

This overlay does not capture all sources of requirements driving selection of controls. Security
requirements for space systems are contained in Committee on National Security Systems Policy
(CNSSP) No. 12, National Information Assurance Policy for Space Systems Used to Support
National Security Missions, and other issuances such as department- or service-specific
directives and instructions used to implement CNSSP No. 12. Mission-specific technologies,
designs, threats, and concepts of operation (CONOPS) also drive security requirements.

Unmanned space platforms in the space segment differ from ground systems—they do not suffer
the same threats and vulnerabilities as information systems on the ground. The following
describe assumptions made about or characteristics of unmanned space platforms driving the
need to use the Space Platform Overlay (i.e., add or subtract controls):
 Space platforms after launch are impractical to physically access for repairs,
reconfiguration, updates, or maintenance once deployed; therefore, many controls
associated with these activities are not selected or must be implemented differently than
intended by the control text. However, the ability for robotic spacecraft to physically
access current and future space platforms is quickly emerging. This will likely require a

1
The concept of “experimental” may refer to a space platform but more often refers to only a payload on the space platform. Experimental
payloads usually do not have command and control capabilities. The experimental asset may not require full protections, because it is not
supporting real-world operations.
2
Ground-based components of space systems may use other appropriate overlays (e.g., tactical, highly sensitive INTs).

Space Platform Overlay

06/01/2013 1 Attachment 2 to Appendix F
 reevaluation of the controls necessary to enable authorized interactions for repair and
refueling operations and protect friendly space platforms from attacks by adversary
robotic systems.
 Space platforms operate in the harsh environment of space (e.g., high radiation levels,
temperature extremes, vacuum, micro-gravity,); therefore, it is not appropriate to select
controls intended to mitigate risks of natural or man-made disasters (e.g., fire, flood,
earthquake) associated with traditional ground-based systems.
 Space platforms have no external “facility” to house IT components; therefore, the
controls related to providing and protecting the facility and the supporting infrastructure
are typically not applicable (e.g., uninterruptable power; lighting; heating, ventilation, air
conditioning, and humidity control; access control points, fences, and guards; intrusion
monitoring and response; fire detection and suppression; flood or water damage
detection). If some of these controls (e.g., temperature sensing and control) are
applicable, it may not be possible to implement the controls in the same manner as for IT
components in ground-based facilities.
 Space acquisitions focus most energy and funding on getting the development correct,
due to the fact that space systems and sub-systems are typically highly specialized, low
production, and high cost units.
 Space platforms generally have a higher mission and/or monetary value than ground-
based IT; therefore, greater protections are put in place to ensure space platforms are not
disabled or degraded and remain in a secure state once launched.
 Space platforms have a greater time and cost to replace; therefore, it is important to
design and build space platforms to higher standards and assurances to minimize residual
vulnerabilities and potential defects or deficiencies.
 All communications with space platforms is inherently wireless, but not in the sense of
ground-based systems wireless access points. Therefore, controls intended to mitigate
wireless threats and vulnerabilities are not implemented or are implemented differently to
address space-specific threats, vulnerabilities, and technologies.
 Space systems communication architectures drive applicability of controls. Conventional
platforms refer to point-to-point, circuit-based architectures used by the vast majority of
current satellites, while advanced platforms refer to packet-switched or routed
architectures which are increasing in use. Advanced platforms tend to have more
complex communications architectures, rely on a distributed control plane, and
potentially have more vulnerabilities. Controls necessary to mitigate additional risk in an
advanced space platform are often not necessary in a conventional space platform.
 The boundary device for space platforms is the cryptographic interface, which ensures
only authorized entities (i.e., those possessing the correct algorithm implementation and
keys) can communicate.
 Access to space platform payload or bus command and control is restricted to
organizational users either through mission-owned operations centers or mission-
provided user terminals. Non-organizational users have no command and control access.
Therefore, the model for selecting controls related to access is substantially different than
for internet-based information systems on the ground.
 Identification and authentication policies are less applicable, as there is no human user
who formally identifies and authenticates to the space platform in the traditional sense.

2
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 Conventional space platforms do not support user accounts of any form (other than
cryptographic accounts); however, advanced space platforms may support user accounts.
 Access to command the bus may be distinct from access to command specific payloads,
potentially with different personnel security clearance requirements.
 Vulnerability scanning for space platforms from the point of view of external adversaries
is very different than for ground systems. The space platform usually consists of a
mixture of mostly custom and some commercial-off-the-shelf (COTS) and Government-
off-the-shelf (GOTS) hardware and software, so it is not possible to use standard
scanning tools in all cases.
 Accreditation boundaries for space systems are often set at the segment (i.e., space,
ground, user, or launch) boundary, thus creating difficulties in assigning controls to
mitigate risk across the entire space system containing components in all three segments.
It is necessary to indicate in the space platform authorization package (i) if the control is
applicable (i.e., the threat and vulnerability associated with a control can affect the space
platform itself) and (ii) if the control is implemented on the space platform or inherited
from a ground system, as it may not be possible, appropriate, or cost effective to
implement all controls on the space platform due to size, weight, and power (SWaP)
limitations. It is not advisable to separate the analysis of the space platform and
controlling ground systems due to the fact that they impact each other’s overall risk
posture. Also, when a platform contains multiple payloads, consideration should be
given to categorizing and accrediting separately those payloads with distinctly different
risk profiles (e.g., experimental vs. operational assets).
 Inheritance of functional controls is often advantageous in ensuring space platforms
maintain an appropriate risk posture. Conventional space platforms have limited
connections to external networks and information systems; therefore, Type-1 protected
connections to the ground control systems are not external, but instead an extension of
the trusted enclave. Thus, maintaining ground-based boundary protection and a trusted
system operator base allows for inheritance of many functional controls.

The Space Platform Overlay can serve as a reference for other systems, given some similarities.
Developers of remotely controlled and/or operated non-space platforms or systems (e.g.,
unmanned vehicles or robotic systems) may need to implement security controls similar or
identical to those in the Space Platform Overlay; therefore, these developers are encouraged to
use the Space Platform Overlay as appropriate to address their mission security requirements.

2. Applicability

This overlay applies to the space platform portion of all space systems (whether experimental or
operational) that must comply with CNSSP No. 12. The controls specified in this overlay are
intended to apply to the space platform after it is launched and undergoing pre-operational
testing and during operation.3 The overlay does not address the space platform while it is in
development or testing on the ground. Although not captured in this overlay, additional controls

3
Space platforms have a different testing cycle than most IT. Testing is performed during development. Testing is performed on the ground
with physical connections to other systems. Testing is performed once the space platform is launched but before operations with mission data.
This overlay covers the space platform once launched.

3
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
are required during pre-launch ground testing of the space platform. For example, physical
security controls are not needed after the space platform is launched, but those controls are
definitely needed while the space platform is on the ground during development and testing.
This overlay does not apply to manned space platforms or launch vehicles, as the assumptions
made for unmanned space platforms don’t necessarily apply to these other types of systems.

The Space Platform Overlay applies, if the answer to all the following questions is yes:

1. Is the system (or subsystem) a space platform4 as defined in CNSSP No. 12?5
2. Is the system unmanned?

3. Implementation

The Space Platform Overlay was developed based on the following:

 National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53,
Revision 3, Recommended Security Controls for Federal Information Systems and
Organizations, August 2009 with May 2010 errata updates
 Committee on National Security Systems Instruction (CNSSI) No. 1253, Security
Categorization and Control Selection for National Security Systems, March 15, 2012

Any of the baselines defined in CNSSI No. 1253 can be selected for a space system. Addition of
security controls are documented from the Low-Low-Low (LLL) baseline, while any
subtractions of security controls are documented from the High-High-High (HHH) baseline.
This overlay does not require any other overlays to provide the needed protection for most
applicable space platforms; however, a specific space platform’s mission or type of information
may drive additional requirements necessitating the application of other overlays.

As noted throughout the Space Platform Overlay, some modifications to the set of selected
security controls will be necessary for the ground and user segments to support or be compatible
with security controls implemented in the space platform.

4. Table of Overlay Controls

The table below contains the security controls (identified with a +) generally always applicable
to space platforms beyond the controls required in the LLL baseline. The table also identifies
those controls generally not applicable (identified with a “--") to space platforms, that are
required by the HHH baseline.

4
Per CNSSP No. 12, a space platform is defined as: A satellite, spacecraft, or space station developed, launched, and operated for purposes of
providing specified products or services to users or customers. A space platform operates at an altitude greater than 100km and typically
consists of a bus and one or more payloads
5
Must the system comply with CNSSP No. 12?

4
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 Table 1: Space Platform Overlay Security Controls
SPACE SPACE SPACE
CONTROL PLATFORM CONTROL PLATFORM CONTROL PLATFORM
OVERLAY OVERLAY OVERLAY
AC-6(6) -- IA-2(4) -- PE-15 --

AC-11(1) -- MP-2 -- PE-16 --

AC-14(1) + MP-2(2) -- PE-17 --

AC-17 -- MP-3 -- RA-5(5) --

AC-17(1) -- MP-4 -- SA-4(1) +

AC-17(2) -- MP-4(1) -- SA-4(2) +

AC-17(3) -- MP-5 -- SA-4(3) +

AC-17(4) -- MP-5(2) -- SA-4(5) +

AC-17(5) -- MP-5(4) -- SA-5(4) +

AC-17(6) -- MP-6(3) -- SA-5(5) +

AC-17(7) -- PE-2 -- SA-10(2) +

AC-17(8) -- PE-2(1) -- SA-11(1) +

AC-18(5) -- PE-2(3) -- SA-11(2) +

AC-19 -- PE-3 -- SA-11(3) +

AC-19(1) -- PE-3(1) -- SC-3 +

AC-19(2) -- PE-3(2) -- SC-3(4) +

AC-19(3) -- PE-3(3) -- SC-6 +

AC-19(4) -- PE-3(4) -- SC-7(7) --

AC-22 -- PE-3(6) -- SC-7(8) --

AT-3(2) -- PE-4 -- SC-7(14) --

AU-6(1) -- PE-5 -- SC-7(15) +

AU-7 -- PE-6 -- SC-8(1) +

AU-7(1) -- PE-6(1) -- SC-12(3) +

AU-9(2) -- PE-7 -- SC-13(2) +

AU-12(1) -- PE-7(1) -- SC-15 --

CP-6 -- PE-8 -- SC-15(1) --

CP-6(1) -- PE-8(2) -- SC-15(2) --

CP-6(2) -- PE-10 -- SC-15(3) --

CP-6(3) -- PE-11 -- SC-19 --

CP-9 -- PE-11(1) -- SC-23(2) --

CP-9(1) -- PE-11(2) -- SI-3(4) +

CP-9(2) -- PE-12 -- SI-4(7) --

CP-9(3) -- PE-12(1) -- SI-8 --

CP-9(5) -- PE-13 -- SI-8(1) --

CP-10(2) -- PE-13(1) -- SI-8(2) --

5
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 SPACE SPACE SPACE
CONTROL PLATFORM CONTROL PLATFORM CONTROL PLATFORM
OVERLAY OVERLAY OVERLAY
CP-10(4) + PE-13(2) -- SI-10 +

CP-10(5) + PE-13(3) -- SI-13 +

IA-2(3) -- PE-13(4) -- SI-13(4) +

5. Supplemental Guidance

The supplemental guidance in this section elaborates on the supplemental guidance in NIST SP
800-53 for only those controls and enhancements listed in the table of security controls in
Section 4.6 More general supplemental guidance for all controls (by control family) is provided
in Section 8.

AC-6, LEAST PRIVILEGE

Control Enhancement: 6

Space Supplemental Guidance: Command and control of the space platform (bus and
payloads) is often restricted to operations centers operated by mission organizations or
user equipment provided by mission organizations. As such, there is no non-
organizational user access, and thus the threat/vulnerability addressed by this control does
not exist. Note that this control could be interpreted as applying to the situation where
multiple hosted platform payloads, potentially from different organizations, have access
to the shared platform bus. This control could be interpreted as restricting those payloads
from having privileged access to the bus. In such situations, it might be reasonable to
include this control as part of the control set; alternatively, restricting access to the bus
could be done through combination of AC-6(1) and AC-3.

AC-11, SESSION LOCK

Control Enhancement: 1

Space Supplemental Guidance: A publically viewable pattern placed over a display (e.g.,
screen saver), is not necessary on space platforms as there are no human readers.

AC-14, PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION

Control Enhancement: 1

Space Supplemental Guidance: For the space platform, the commands that can be
performed without identification and authentication fall into two groups: (i) those

6
This limitation is not imposed by CNSSI 1253 or the overlay template; however, this overlay’s team of authors chose to limit detailed
supplemental guidance in this manner for the sake of relative brevity.

6
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 commands issued over the cryptographic channel but do not require authentication, and
(ii) commands issued when the platform is in crypto-bypass mode. Due to the value and
difficulty of replacing the space platform, the actions permitted that do not require
authentication should be minimized at all impact categories to only those necessary to
support emergency mission/business operations. In the case of the crypto bypass mode,
there should be a clear understanding of the conditions that may be in place when that
mode is active and the actions that may be required to return the space platform to normal
operation as soon as it is safe to do so. As required by AC-14, if there are any actions
that can be performed without identification and authentication, the organization must
document the rationale for the set of selected commands in system design documentation,
justifying that the set of commands available without authentication are only those
necessary to support mission/business operations.

AC-17, REMOTE ACCESS

Space Supplemental Guidance: Space platform access does not fall into the definition of
remote access. Space platforms are commanded or directed (as opposed to passive
receipt of information, which is broadcast) from a ground system that has encryption keys
for just that space platform. This makes the space platform communication case
analogous to the VPN. The definitions explicitly state that a virtual private network,
when adequately provisioned with appropriate security controls, is considered an internal
network (i.e., the organization establishes a network connection between organization-
controlled endpoints in a manner that does not require the organization to depend on
external networks to protect the confidentiality or integrity of information transmitted
across the network).

Control Enhancements: 1, 2, 3, 4, 5, 6, 7, and 8

Space Supplemental Guidance: Access to the space platform does not fall under the
definition of remote access, as discussed in AC-17.

AC-18, WIRELESS RESTRICTIONS

Control Enhancement: 3

Space Supplemental Guidance: This control addresses the vulnerability that wireless
capability may be enabled without the user’s knowledge. The term wireless is not
restricted to the typical 802.11x and can be applied to the concept of wireless
communications with a space platform; therefore, both scenarios are addressed here. In
the case of wireless communications with a space platform in space, this control is
generally not applicable, as wireless capabilities are always required to communicate
with the space platform and it is not advisable to disable wireless communications to the
space platform, as there would be no means to command or control the space platform.
In the case of 802.11x wireless, if a space system integrates a COTS module or
component, any wireless capability within the module or component that is not needed to
support the mission or functionality of the space platform should be removed or disabled.

7
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
Control Enhancement: 5

Space Supplemental Guidance: Wireless capabilities are always required to

communicate from the ground to the space platform; therefore, it is not possible to
confine wireless communications to organization-controlled boundaries as in the sense of
ground-based wireless communications. However, on the space platform, control of
emanations within the system (such as TEMPEST protections between components) is to
be considered to ensure data is not leaked.)

AC-19, ACCESS CONTROL FOR MOBILE DEVICES

Space Supplemental Guidance: The supplemental guidance of this control defines

mobile devices as including portable storage media (e.g., USB memory sticks, external
hard disk drives) and portable computing and communications devices with information
storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular
telephones, digital cameras, and audio recording devices). Although technically a space
platform could be construed as satisfying these examples, it is clear the intent was that
this control applies to mobile devices that could be moved around by human users. Space
platforms are not mobile in that sense.

Control Enhancements: 1, 2, and 3

Space Supplemental Guidance: Space platforms do not provide writable, removable

media.

Control Enhancement: 4

Space Supplemental Guidance: AC-19 defines mobile devices as including portable

storage media (e.g., USB memory sticks, external hard disk drives) and portable
computing and communications devices with information storage capability (e.g.,
notebook/laptop computers, personal digital assistants, cellular telephones, digital
cameras, and audio recording devices). Although technically a space platform could be
construed as satisfying these examples, it is clear the intent was that this enhancement
applies to mobile devices that could be moved around by human users. Space platforms
are not mobile in that sense.

AC-22, PUBLICLY ACCESSIBLE CONTENT

Space Supplemental Guidance: Space platforms provide publically accessible

information (e.g., global positioning system (GPS) signals). However, this information is
determined algorithmically and specified as part of the design process. There is no ad-
hoc posting of information and subsequent review; thus, there is no threat that un-
reviewed information may be posted in a publically-accessible location.

AT-3, SECURITY TRAINING

8
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
Control Enhancement: 2

Space Supplemental Guidance: There are no physical controls (e.g., guards, guns,
physical access control lists) applicable to the space platform. The focus of this overlay
is on unmanned space platforms in space, with no physical access for repairs.

AU-6, AUDIT REVIEW, ANALYSIS, AND REPORTING

Control Enhancement: 1

Space Supplemental Guidance: This is an information system (not an organizational)

control that should be implemented in the ground segment due to SWaP considerations.

AU-7, AUDIT REDUCTION AND REPORT GENERATION

Space Supplemental Guidance: Audit review and reduction is not performed directly on
the space platform; rather, it is performed on audit data off-loaded to the ground segment.
Reduction of audit data may occur on the space platform within the telemetry stream
between the space platform and the ground. During anomaly resolution, this audit data
can be modified to delve into specific points of interest within the space platform to aid in
determining, identifying, and correcting system failures.

Control Enhancement: 1

Space Supplemental Guidance: Audit review and reduction is not performed directly on
the space platform; rather, it is performed on audit data off-loaded to the ground segment.
Space platforms only do pre-selection of audit events; therefore, it is not possible to
identify events of interest.

AU-9, PROTECTION OF AUDIT INFORMATION

Control Enhancement: 2

Space Supplemental Guidance: With respect to the space platform, it is important to

understand the distinction between backup and off-load. Backup makes a copy of the
data to a secondary location, retaining the audit data at the original location until it is
purged. Off-loading, on the other hand, moves the data from the primary to the
secondary location. Space platforms off-load audit data; they do not copy. Activity to
backup any offloaded audit data will occur in the ground segment.

AU-12, AUDIT GENERATION

Control Enhancement: 1

9
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 Space Supplemental Guidance: Devices on a space platform must capture data elements
consistent with Annex J of CNSSI 1253. Correlation and compilation of audit records is
a ground segment function. Space platform payloads are monitored separately,
separately owned, and conceivably transmit their payload audit to the payload owners.
Even in fractionated space platforms, audit data would be sent bent pipe (i.e., opaquely
encrypted for that payload) to the payload owner.

CP-6, ALTERNATE STORAGE SITE

Space Supplemental Guidance: Alternate storage is not applicable to the space platform.
On the space platform, there is no user data in long term storage; user data is only
transitory. System data exists, but it is not subject to backup; rather, a master system
image is maintained on the ground and uploaded when required. Space platform data
stored in the ground system is subject to this control and satisfaction of the control is the
responsibility of the ground system.

Control Enhancements: 1, 2, and 3

Space Supplemental Guidance: Same as for the base control CP-6

CP-9, INFORMATION SYSTEM BACKUP

Space Supplemental Guidance: This control is not applicable to the space platform, but
to the supporting ground system. On the space platform, there is no user data in long
term storage; user data is only transitory, or if stored, is stored temporarily and forwarded
to the ground. System data exists, but is not subject to backup; rather, a master system
image is typically maintained on the ground and uploaded when required (and thus, that
master system image is the backup). Documentation is maintained on the ground as part
of the ground segment. Backup of space platform information stored in the ground
system is the responsibility of the ground system.

Control Enhancements: 1, 2, 3, and 5

Space Supplemental Guidance: Same as for the base control CP-9.

CP-10, INFORMATION SYSTEM RECOVERY AND RECONSTITUTION

Control Enhancement: 2

Space Supplemental Guidance: There are no transaction-oriented databases in the space

platform.

Control Enhancement: 4

Space Supplemental Guidance: It is not advisable to reload individual software

components on an operational space platform without extensive testing of the complete

10
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 software image, because unintended consequences could result in the loss or disabling of
the space platform. For a space platform, the operational image is prepared and fully
tested on the ground and then uploaded as the complete image to the space platform.

Control Enhancement: 5

Space Supplemental Guidance: It is not practical to repair or replace space platform

components; therefore, redundancy and failover capabilities must be built into the space
platform when needed to meet mission requirements. For some critical missions
requiring mission assurances beyond what internal redundancy can provide, failover to
other operational space platforms, launch on demand space platforms, or non-space
systems (where possible) should exist.

IA-2, IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS)

Control Enhancements: 3 and 4

Space Supplemental Guidance: Although advanced space platforms may have user
accounts, the access for those accounts is not considered to be “local access” and would
be addressed by the network access controls on the ground segment.

MP-2, MEDIA ACCESS

Space Supplemental Guidance: There is no need to control physical access to remote and
static media. The space platform does not have removable media, and access to static
media is prevented by the physical environment of space. Logical access is addressed not
through this control, but through AC-3.

Control Enhancement: 2

Space Supplemental Guidance: Space platforms do not have any portable digital media
or devices. Some space platforms in the past did have ejectable film canisters, but that
technology is no longer in use.

MP-3, MEDIA MARKING

Space Supplemental Guidance: There is no need for human readable markings, as there
are no humans accessing the space platform in the environment of operation, no
removable media or removable media devices, and no display or print devices. However,
for reusable space platforms, such controls may be needed to support ground recovery
and refurbishment.

MP-4, MEDIA STORAGE

Space Supplemental Guidance: Space platforms have no portable media or media

devices requiring control or secure storage.

11
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
Control Enhancement: 1

Space Supplemental Guidance: Same as for the base control MP-4.

MP-5, MEDIA TRANSPORT

Space Supplemental Guidance: Space platforms have no portable media or media

devices. Launch of a space platform might be viewed as media transport, but the nature
of launch makes it distinctly different than human transport.

Control Enhancements: 2 and 4

Space Supplemental Guidance: Same as for the base control MP-5.

MP-6, MEDIA SANITIZATION

Control Enhancement: 3

Space Supplemental Guidance: The space platform does not support removable media.

PE-2, PHYSICAL ACCESS AUTHORIZATIONS

Space Supplemental Guidance: Unmanned space platforms after launch are physically
inaccessible to personnel; therefore, physical access authorizations are not necessary.

Control Enhancements: 1and 3

Space Supplemental Guidance: Same as for the base control PE-2.

PE-3, PHYSICAL ACCESS CONTROL

Space Supplemental Guidance: Unmanned space platforms after launch are physically
inaccessible to personnel and have no facility, access points, or access control
mechanisms; therefore, physical access control is not necessary.

Control Enhancements: 1, 2, and 6

Space Supplemental Guidance: Same as for the base control PE-3.

Control Enhancement: 3

Space Supplemental Guidance: Same as for the base control PE-3

Control Enhancement: 4

12
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 Space Supplemental Guidance: Same as for the base control PE-3. Due to the SWaP
constraints, lockable casings are not practical on a space platform.

PE-4, ACCESS CONTROL FOR TRANSMISSION MEDIUM

Space Supplemental Guidance: The threat addressed by this control is physical access to
wired information system distribution and transmission lines. Such lines do not exist for
the space platform; all communication is wireless.

PE-5, ACCESS CONTROL FOR OUTPUT DEVICES

Space Supplemental Guidance: Space platforms do not have output devices in the sense
used by this control.

PE-6, MONITORING PHYSICAL ACCESS

Space Supplemental Guidance: Unmanned space platforms after launch are physically
inaccessible to personnel; therefore, physical access monitoring in the sense intended by
the control is not necessary. Objects in the space domain are monitored and tracked
using other systems not directly tied to the space platform.

Control Enhancement: 1

Space Supplemental Guidance: Same as for the base control PE-6.

PE-7, VISITOR CONTROL

Space Supplemental Guidance: Unmanned space platforms after launch are physically
inaccessible to personnel; therefore, visitor control is not necessary.

Control Enhancement: 1

Space Supplemental Guidance: Same as for the base control PE-7.

PE-8, ACCESS RECORDS

Space Supplemental Guidance: Unmanned space platforms after launch are physically
inaccessible to personnel; therefore, access records are not necessary.

Control Enhancement: 2

Space Supplemental Guidance: Same as for the base control PE-8.

PE-10, EMERGENCY SHUTOFF

13
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 Space Supplemental Guidance: Unmanned space platforms after launch have no
facilities or personnel; therefore, a manually-activated emergency power shutoff is not
necessary.

PE-11, EMERGENCY POWER

Space Supplemental Guidance: As addressed in the control, power for emergencies to

shut down components or to provide long-term alternate power sources until it is possible
to return to the primary power source are not desired space platform capabilities.
Provision of redundant power supply, if warranted based on mission, would be achieved
through controls CP-10(5) and SI-13.

Control Enhancements: 1 and 2

Space Supplemental Guidance: Same as for the base control PE-11.

PE-12, EMERGENCY LIGHTING

Space Supplemental Guidance: Unmanned space platforms after launch have no

personnel to evacuate; therefore, there is no need to light emergency evacuation routes.

Control Enhancement: 1

Space Supplemental Guidance: Same as for the base control PE-12.

PE-13, FIRE PROTECTION

Space Supplemental Guidance: Fire is not possible in the vacuum of space, as there is no
oxygen to burn. The control references features (e.g., smoke detectors, sprinklers, fire
extinguishers) necessary for manned facilities on the ground or in space (i.e., where
oxygen is present). These features are not necessary for completely self-contained,
unmanned space platforms. Concerns about overheating are addressed in PE-14.

Control Enhancements: 1, 2, 3 and 4

Space Supplemental Guidance: Same as for the base control PE-13.

PE-15, WATER DAMAGE PROTECTION

Space Supplemental Guidance: Unmanned space platforms do not include water-based

mechanisms; therefore, water damage protection is not necessary.

PE-16, DELIVERY AND REMOVAL

Space Supplemental Guidance: Unmanned space platforms after launch are physically
inaccessible to personnel, have no facility with entry/exit points, and have no components

14
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 entering or exiting the space platform; therefore, there is no need to authorize, monitor,
control, or record components in this manner.

PE-17, ALTERNATE WORK SITE

Space Supplemental Guidance: Unmanned space platforms after launch are physically
inaccessible to personnel; therefore, an alternate work site (e.g., telework location) is not
required or possible.

RA-5, VULNERABILITY SCANNING

Control Enhancement: 5

Space Supplemental Guidance: Providing privileged access would be equivalent to

providing access to the encrypted commanding channel and any command access
required for space platforms. Privileged access for vulnerability scanning (a potentially
intrusive function) creates the possibility of accidentally damaging or disabling critical
functions. This creates significant mission risk for an asset that cannot be replaced or
repaired after launch. Conversely, there are very few benefits from scanning due to the
unique nature of space platform operating systems, since they don’t suffer from the same
types of vulnerabilities as Internet-based ground systems. Other forms of mitigation are
sufficient, such as checking the integrity of the flight software.

SA-4, ACQUISITIONS

Control Enhancement: 1

Space Supplemental Guidance: Experience with space platforms has shown that software
and hardware assurance is critical to mission success. Failure of a software or hardware
component can result in the loss of a very expensive asset. Complete understanding of
the functional properties of the implemented security controls is critical at all integrity
impact levels to ensure there are no flaws in the space platform hardware and software
mechanisms.

Control Enhancement: 2

Space Supplemental Guidance: Experience with space platforms has shown that software
and hardware assurance is critical. Failure of a software or hardware component has
significant recovery costs and can result in the loss of a very expensive asset. Complete
understanding of the design and implementation details of security controls is critical at
all integrity impact levels to ensuring the reliability of the flight software and hardware.
Every effort should be made to incorporate this control into the statement of work
requirements for existing bids.

Control Enhancement: 3

15
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 Space Supplemental Guidance: The emphasis of space platform development is on
minimization of flaws in flight software and hardware. Reuse of successful software is
considered a state-of-the-practice approach for space systems takes advantage of the
extensive testing already performed on the software. However, software reuse and
development is also affected by control SA-11(1), which requires the use of code analysis
tools. These tools should be run against reused software as well to ensure newly
identified common weaknesses are uncovered. For truly experimental payloads which
are not intended or allowed to be used to support real-world operational missions, the
authorizing official may be more risk tolerant and may not require the full set of controls.

Control Enhancement: 5

Space Supplemental Guidance: The program office (i.e., the organization responsible for
development or acquisition) will specify the requisite delivered security configuration for
the space platform. It is essential space platforms are delivered in a securely configured
state, because it is more difficult to correct deficiencies on the space platform after it is
launched; and, such delivery ensures that what was delivered is in the same configuration
as when tested.

SA-5, INFORMATION SYSTEM DOCUMENTATION

Control Enhancement: 4

Space Supplemental Guidance: Space platforms require additional analysis and testing of
the low-level design in order to understand and prevent anomalies before launch of the
space platform, and so that if anomalies occur after launch, the analysis is available to
repair the anomalies.

Control Enhancement: 5

Space Supplemental Guidance: This control is always applicable for anything other than
an experimental payload—the higher risk tolerance for some experimental payloads may
mean source code analysis is not essential. The space platform requires additional
analysis of source code in order to both understand and prevent anomalies before launch
of the space platform, so that if anomalies occur after launch, the analysis is available to
repair the anomalies. Satisfying this control may be a challenge for commercial space
platforms supporting national security missions—in such cases, use of proprietary
information protections (e.g., non-disclosure agreements, special handling requirements)
may be required in order to have the source code available for anomaly analysis.

SA-10, DEVELOPER CONFIGURATION MANAGEMENT

Control Enhancement: 2

Space Supplemental Guidance: This control should be implemented to provide

mitigation only if the Authorizing Official accepts the risk of the developer not having a

16
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 configuration management process and there are no viable alternatives (e.g., the
developer is the only source for a mission critical component).

SA-11, DEVELOPER SECURITY TESTING

Control Enhancement: 1

Space Supplemental Guidance: Static code analysis is required to ensure software

reliability, because space platform functionality must be confirmed before launch. After
launch, there is little or no opportunity to correct malfunctions. Static code analysis
should be applied to all software code, even that which is being reused, in order to ensure
current common weaknesses are addressed. Use of code analysis tools is one example of
state-of-the-art techniques to reduce software flaws, as discussed in control SA-4(3).

Control Enhancement: 2

Space Supplemental Guidance: Vulnerability analysis is required to ensure reliability,

because space platform functionality must be confirmed before launch. After launch,
there is little or no opportunity to correct vulnerabilities. The developer is in the best
position to understand the nuances of the hardware and software design of the space
platform and to identify potential vulnerabilities.

Control Enhancement: 3

Space Supplemental Guidance: Space platforms are costly and difficult to repair or
replace; therefore, all vulnerabilities must be well understood before placing space
platforms in operation. Use of independent verification and validation agents to witness
the security test and evaluation executed against a security assessor-approved plan is
required to ensure impartial testing results (with all identified vulnerabilities) are
conveyed to the authorizing official for an informed authorization decision.

SC-3, SECURITY FUNCTION ISOLATION

Space Supplemental Guidance: Isolating security functions from non-security

functions—in fact, isolation in general—needs to be implemented in the space platform
at all impact levels, due to the critical functions performed by various components of the
space platform. When multiple payloads reside on one space platform’s bus, payload
security and non-security functions must be appropriately separated from the hosting
bus’s security and non-security functions.

Control Enhancement: 4

Space Supplemental Guidance: This control is applicable for the security functionality
implemented on the space platform, and strongly encouraged for other mission functions.
Implementing largely independent modules reduces the risk that an anomaly in one

17
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 module will impact another module. As such, this supports both good engineering design
and mission assurance.

SC-6, RESOURCE PRIORITY

Space Supplemental Guidance: This control is required for all space platform buses to
ensure high priority functions are carried out, but it is particularly important when there
are multiple payloads sharing a bus providing communications and other services, where
bus resources must be prioritized based on mission.

SC-7, BOUNDARY PROTECTION

Control Enhancement: 7

Space Supplemental Guidance: Space platforms do not use strict tunneling in the sense
intended by this control. However, when the ground system is communicating with the
space platform, other network communications from the ground segment may not be
routed through the space platform. Measures to ensure appropriate separation (e.g., on a
multi-payload hosting bus) must be considered on a case-by-case basis; however,
examples of measures to consider include cryptographic isolation, TEMPEST mitigation,
logical separation of information flows, etc.

Control Enhancement: 8

Space Supplemental Guidance: Space platforms do not route internal communications

traffic to external networks—all recipients of official traffic are pre-coordinated and
considered internal users in this respect. Also, the traffic is not the traditional internet-
based traffic. Therefore, the space platform does not use proxy servers.

Control Enhancement: 14

Space Supplemental Guidance: Unmanned space platforms after launch are not
accessible to personnel, and this precludes malicious actors from making surreptitious
physical connections to bypass components after launch. Before launch, unauthorized
physical connections are prevented through rigorous systems engineering and design
processes to attain and maintain a secure configuration and by physical security
protections for the facilities housing the space platform before launch.

Control Enhancement: 15

Space Supplemental Guidance: For the space platform, this capability is provided by a
dedicated encryption device for the control plane. This is the approach commonly taken
on space platforms, where command and control typically uses a different algorithm and
encryptor from the algorithm and encryptor used for the data plan. NOTE: This control
is arguably not required for truly experimental space platforms.

18
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
SC-8, TRANSMISSION INTEGRITY

Control Enhancement: 1

Space Supplemental Guidance: Use of cryptographic mechanisms is the only option, as

space platforms do not have physical protection for integrity due to the wireless nature of
communications with the space platform.

SC-12, CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT

Control Enhancements: 3

Space Supplemental Guidance: The key management approach must be National

Security Agency (NSA) approved, as dictated by CNSSP No. 12. NOTE: Selection of
SC-12(3) precludes selection of SC-12(2).

SC-13, USE OF CRYPTOGRAPHY

Control Enhancement: 2

Space Supplemental Guidance: The cryptography for space systems must be National
Security Agency (NSA) approved, as dictated by CNSSP No. 12. NOTE: CNSSP No.
12 requires NSA-approved cryptography at all classification levels. This doesn’t
necessarily mean NSA will require NSA-certified Type-1 encryption for all applications
requiring encryption.

SC-15, COLLABORATIVE COMPUTING DEVICES

Space Supplemental Guidance: The space platform does not provide collaborative
computing devices or support instant messaging clients.

Control Enhancements: 1, 2, and 3

Space Supplemental Guidance: Same as for the base control SC-15.

SC-19, VOICE OVER INTERNET PROTOCOL

Space Supplemental Guidance: Although VoIP traffic might go through the payload and
bus of space platforms, there are no VoIP client connections to space platform
components.

SC-23, SESSION AUTHENTICITY

Control Enhancement: 2

19
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 Space Supplemental Guidance: Although advanced space platforms may support user
sessions, termination of a session is through commanding or closure of an access
window, not through a “logout” button on a graphical user interface.

SI-3, MALICIOUS CODE PROTECTION

Control Enhancement: 4

Space Supplemental Guidance: Grave damage could result to expensive and

irreplaceable assets due to malicious code protection mechanisms being incorrectly
installed or updated on unique space platform components (i.e., non-standard operating
systems and software), such that the mechanisms fail to identify and appropriately
respond to malicious code attacks. Therefore, the space platform must be designed to
allow only privileged users to perform those malicious code protection mechanism
updates for space platform-specific software.

SI-4, INFORMATION SYSTEM MONITORING

Control Enhancement: 7

Space Supplemental Guidance: The space platform does not have the capability to notify
specific personnel. The goal of the notification is to identify broad-based attacks. For
the space platform, this is addressed better through the coordination of space platform
monitoring and ground system monitoring provided through controls SI-4 and SI-4(16).
As for actions to terminate suspicious events, typically the decision to terminate is made
on the ground and the action is performed via the command uplink. However, automated
termination of processes or selected sessions is plausible, if the implications are well
thought out in advance.

SI-8, SPAM PROTECTION

Space Supplemental Guidance: The space platform does not serve as the terminus of
electronic messages, where spam would have an adverse effect. If the space platform
mission supports messaging, any spam protection mechanisms are implemented either in
the user segment or in the point of connection to the source of the messages.

Control Enhancements: 1 and 2

Space Supplemental Guidance: Same as for the base control SI-8.

SI-10, INFORMATION INPUT VALIDATION

Space Supplemental Guidance: At a minimum, validation of commands (which

constitute space platform input) is an essential part of the command authentication
process. Additionally, if a space platform is designed to store data for retransmission

20
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 over certain areas, it is important to prevent bogus data from being accepted; otherwise,
valid data might be denied storage space.

SI-13, PREDICTABLE FAILURE PREVENTION

Space Supplemental Guidance: Security component failure on a space platform could

provide unauthorized control of the space platform (an expensive, irreplaceable national
asset); therefore, mean time to failure for security components (and other critical
components) must be commensurate with the authorizing official’s acceptable risk
tolerance level. Substitution, with respect to the space platform, refers to transfer of the
function to a redundant component designed into the space platform. Given SWaP
constraints, redundancy has its limits.

Control Enhancement: 4

Space Supplemental Guidance: On the space platform, the transition might not be fully
transparent, as space platform operators must be aware of the state of the space platform
and must often initiate the transition after careful consideration, so as not to jeopardize
operations. The assignment values are based on mission specifics.

6. Specific Value Parameters

Table 2 contains specific parameter values unique to the Space Platform Overlay.

Table 2: Values for Parameters

CONTROL PARAMETER VALUES

AU-2 The assignment values in CNSSI 1253 paragraph a. are applicable.

However, certain aspects of the assignment values are not applicable for
conventional space platforms—items (b), (d), and (e), all deal with logins
and sessions. For advanced space platforms supporting logins and
sessions, items (b), (d), and (e) are applicable. Additionally, for
conventional and advanced space platforms, the following activities
should be included in the assignment for this control:
 Auditing commands sent to the space platform.
 Auditing state-of-health for security mechanisms implemented on the
space platform.
 Auditing privileged activities (e.g., cryptographic key changeover).
SC-13(4) The assignment value is “NSA-approved.”

7. Regulatory/Statutory Controls

None of the security controls in the Space Platform Overlay are required for regulatory or
statutory purposes.

21
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
8. Tailoring Considerations

This section provides general considerations when tailoring the set of security controls for a
space platform, followed by more specific considerations relevant to each family of security
controls. The set of security controls resulting from application of overlays may need some
modification to address mission-specific technologies, designs, threats, and concept of
operations. Such modifications are permitted with the authorizing official’s approval on a case-
by-case basis.

Space systems have constraints—some security controls could be implemented on the space
platform, but it is often better or only possible to implement them on the ground. The ground vs.
space platform tradeoff must be examined as part of the SA-8 systems engineering process. For
example, Account Management, Individual Identification and Authentication, Authorization,
Auditing, Configuration Management, and similar controls are often better implemented within
ground-based systems and inherited by the space platform. Robust systems engineering limits
the impacts due to SWaP, complexity, technology, and cost constraints, while enabling assured
implementations from ground-based systems, which often offer cost-competitive and
continuously improving designs.

When tailoring security controls, consider all connections and interfaces with other external
systems to address system-of-systems security challenges. Modifications may be required to
address special or more stringent mission or enterprise needs to detect, defend against, survive,
and operate through or quickly recover from attacks. Consideration should be given to any
likely changes in mission operations or concept of operations (e.g., degree of interconnectivity
with other domains, size and composition of the communities of interest, inclusion of coalition or
civil entities as users) to minimize future security risks without incurring additional costs.

Additional controls beyond those selected in the integrity baseline may be necessary for the
space platform. Unless it is data upon which no decisions or actions will be based (e.g.,
entertainment purposes only), the integrity of all data processed, stored, and received or
transmitted by space platforms is critical. Corrupting the integrity of commands or software
uploads to space platforms can lead to loss of the space platform and/or damage to other space
platforms or missions. Corrupting the integrity of telemetry generated onboard a space platform
can degrade or deny the ability of operators to monitor and maintain the space platform in a safe
and secure state. Corrupting the integrity of data generated or received by payloads onboard the
space platform may result in mission failure, depending on how much data is corrupted and also
on whether or not the data is easily identified as corrupted. Therefore, controls selection shall
take into account the impact that a loss of integrity has on space platforms.

All wireless links are susceptible to electromagnetic interference, SIGINT collection/exploitation

and spoofing. Attacks on the wireless links of space platforms can result in severe and
widespread consequences. For example, jamming the uplink of a geosynchronous space
platform has the potential to deny services to users on 1/3 of the earth's surface. Similarly,
covert operators would be in danger from detection and geo-location threats that can lead to loss
of life. If unprotected, these links are relatively easy to detect, collect, analyze and purposefully
interfere with. In the absence of transmission security (TRANSEC) controls, satellite terminals

22
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
are also vulnerable to traffic analysis, radio fingerprinting and other threats. In view of the
above, all space systems are required to determine what TRANSEC controls are necessary for
their mission and concept of operations. These controls must be implemented to adequately
protect the links over the life of the system.

Use of commercial space services for launch, communications, remote sensing, etc., to support
national security system (NSS) missions and the use of commercial space platforms to host NSS
payloads will likely require tailoring of the set of selected security controls in order to provide
the appropriate level of protections otherwise not provided for in a commercial best practice
scenario. Provision of protections may have to be negotiated with the commercial provider
and/or the authorizing official may be asked to assume higher residual risk due to many controls
being absent in a specific service provider’s system.

The following guidance must be considered when performing system-specific tailoring or

supplementing of controls and enhancements within the specified families:

Access Control (AC Family)

 For the space platform, the commands that can be performed without identification or
authorization fall into two groups: (i) those commands issued over the cryptographic
channel but do not require authentication, and (ii) commands issued when the platform is
in crypto-bypass mode. The organization must determine actions permitted in each case;
none or all commands may be appropriate.
 If the bus and payload are managed by different organizations or have different user
bases requiring a separation based on need to know, access control is especially important
within the space platform. Special attention must be applied to separation of access to the
bus, payload, and privilege management. Space-specific access control policies must
address access between platform components based on component functions and need to
access (provides additional resiliency for critical components), in addition to more
traditional separation based on classification.
 In terms of user accounts, conventional space platforms do not support accounts of any
form (other than cryptographic accounts); however, advanced space platforms may
support user accounts. If such accounts are used, they may be the more traditional login-
oriented accounts, or they may be accounts associated with digitally-signed commands.
In the case of digitally-signed commands, the account associated with the signer would
be used to determine the authorizations and the commands permitted. For advanced space
platforms, login-oriented accounts are more appropriate for the payloads of the space
platform, as opposed to the command bus. Additionally, the payload might support
device accounts for authorized terminals. Space platforms supporting more advanced
access control concepts will require additional design and security-supporting code,
which in turn will increase size, weight, and power (SWaP) as well as overall cost. In
addition, the increased design may bring with it an increase in risk, which may require
virus software monitoring and other oversight. This may be very difficult for the small
systems that have limited SWaP.
 For space platforms, wireless access is different than for ground-based systems. There
are two types of wireless communication with space platforms: communication is simply
relayed through space platforms without processing and communications processed
23
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 and/or generated by the space platform, such as commands and telemetry. Commanding
is not the form of wireless access as seen in modern networks, where one has networks
being used via wireless access points by external users. However, the underlying
principle of protecting wireless access is important for the space platform. Controls in
this family require a program to (i) establish the usage restrictions for communication
with the space platform and provide implementation guidance regarding space platform
communications; and (ii) to monitor for unauthorized access attempts. Authorization of
wireless access would relate to provision of the appropriate cryptographic commanding
keys and communication parameters, which would also serve to enforce the requirements
for connecting to the space platform. For space system communications, the policies in
CNSSP 12 take precedence.

Security Awareness Training (AT Family)

 Training policies relate to ground-based administration of the space platform.
 Most facility-based aspects of training are not applicable, as there is no facility in space.
 For Communications Security (COMSEC) devices, training should focus on COMSEC
doctrine.
 The space platform may drive some unique security awareness training to address
identification of attacks in space (e.g., anti-satellite attacks, signal jamming, etc.).
 Training on environmental controls may take a different or specialized form than for
ground-based controls (e.g., extreme temperature ranges, radiation, lack of humidity).

Audit and Accountability (AU Family)

 Many aspects of audit are inherited from the ground segments and are focused on human-
based actions.
 Space platforms may be incapable of identifying the user/subject associated with events,
depending on the space platform’s age/architecture and whether it supports user accounts.
 Monitoring of physical access does not apply, as the space platform is not accessible.
 The nature of real-time is different, and can involve both transmission delays and
communication windows associated with the space platform’s orbit.
 SWaP restrictions on the space platform may be a factor in determining the events to be
audited and may also determine whether the events are stored on the platform or
offloaded, mechanisms for offloading (e.g., in the telemetry downlink), and how often
audit information must be offloaded to the ground segment. Audit data is not generally
stored long term on the space platform; audit storage on the space platform is likely to be
transitional storage, intended to record events until the space platform can resume contact
with a ground station and off-load the audit data with the telemetry string. As such,
sizing of audit capacity is for that transitional case, with provisions for longer out-of-
contact periods (which may include temporary failure to communicate with the ground
arising from failures on the ground).
 Review and processing of the audit stream is performed on the ground on off-loaded data.
 There may be distinct audit for payload activities versus bus activities. In response to
alerts, for a payload within a multi-payload space platform, specific payload services
theoretically could be shut down in the event of an attack (so long as they can be returned
to health), but the overall bus should never be shut down, as this would result in loss of
control of the space platform.
24
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
Security Assessment and Authorization (CA Family)
 Assessment and authorization processes are ground-based, but the control set for the
space platform must include the CA family, as assessment activities are performed on the
space platform prior to and after launch.
 Assessment of information system connection controls should especially focus on space
platform connections to ground control systems outside the organizational purview of
space platform operators. There is no way to control unencrypted broadcast connections,
and for encrypted connections, authorization is required in the form of cryptographic
keys. Similar to interconnections of ground-based systems, cross links between space
platforms owned by different organizations must also be assessed, or otherwise be
covered by a memorandum of agreement.
 Given the inaccessible nature of space platforms after launch, automated assessments
(especially assessments after the initial authorization) are desirable for the space
platform, assuming SWaP considerations permit.

Configuration Management (CM Family)

 Configuration management for the space platform is performed by ground personnel.
 The period for review of the baseline configuration of the space platform may be longer
than for ground-based components.
 Approaches to automated mechanisms to maintain a current and accurate baseline
configuration could include a hash of the space software to ensure no unauthorized code
has been introduced, or a space-segment based mechanism providing a report back on the
software on the platform.
 The space platform is an extremely focused component, less subject to arbitrary
installation of commercial-off-the-shelf (COTS) or government-off-the-shelf (GOTS)
components. Therefore, it is appropriate to develop a defined list of authorized software
programs and employ a deny-all, permit-by-exception authorization policy, as opposed to
the opposite approach of developing a list of software programs not authorized to execute
and an allow-all, deny-by-exception approach.

Contingency Planning (CP Family)

 Available contingency planning alternatives differ greatly from those of ground-based
facilities. There may not always be a space platform in a suitable orbit to provide
alternative support to the mission, and components may truly be unique.
 Contingency planning for space platforms is achieved in a number of ways: alternate
space platforms in the same constellation; redundant components and capabilities on the
primary space platform; alternate processing capabilities as secondary payloads on other
space platforms; graceful degradation of capabilities, or launch-ready replacement
platforms on the ground.
 Space platforms in a given orbit are subject to similar hazards, as they are all in the same
environment. However, the nature of the hazard is such that all space platforms in the
environment will not be affected equally. For example, orbital debris will only affect a
small subset of space platforms. What is required for the space platform is that the
alternate processing approach (which could be component redundancy) is sufficient to

25
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 reduce the risk of the primary and the alternate being disabled by the same hazard in a
narrow time frame.
 The potential avenues of single-point-of-failure must be identified when considering
ground-to-space platform communications. One concern is the network connecting to a
range tracking station (such as the Air Force Satellite Control Network (AFSCN)).
Because all communications are over-the-air, they all have similar failure modes
depending on their frequency or spectrum.
 Continuity of Operations Plans must take a holistic view, addressing loss of the space
platform, loss of ability to communicate with the space platform, and loss of various
components of the ground and user segments. Consideration should be given to the
impact on all missions, whether directly or indirectly supported, resulting from the loss of
a space platform.
 Aspects of contingency planning are inherited from ground segments. Table-top
exercises or simulations are preferred methods of testing contingency plans.

Identification and Authentication (IA Family)

 Identification and authentication policies—especially those focused on password-based
authentication—are less applicable to the space platform, as there is no human user who
formally identifies and authenticates to the device in the traditional sense. However,
individual authentication in the general sense may be applicable, both in terms of digital
signatures used to authenticate the origin of the commands themselves as well as
authentication of the actual commands. There may also be identification and
authentication of terminals. Also, some advanced space platforms might actually
implement login accounts.
 Current space platform technology focuses on authenticated bulk encryption, which
provides some level of authentication of the sending ground system as a whole, but not
individual authentication. However, it is conceivable advanced space platforms might
either use digital signing approaches or actual user login to have authenticated users
associated with commands.
 Although space platform communication does not constitute “remote access,” it is a form
of wireless access. As such, within the space platform, device identification and
authentication would refer to using cryptographic approaches to authenticate the ends of a
bidirectional connection. This is achieved as an artifact of the symmetric encryption
used; without the same keys, communication is not possible.
 Space systems generally echo commands (or other inputs) via the telemetry stream.
Some U.S. government agencies require encryption of telemetry downlinks to sufficiently
protect any command or authentication.

Incident Response (IR Family)

 In general, the nature of incidents is very different for the space platform, focusing more
on attacks and anomalies. The incident response policy for space must determine the
applicable incidents unique for space and the indicators of attack. It would also need to
define the appropriate response to those attacks so as to provide appropriate resiliency.
 With respect to the space platform, the nature of dynamic reconfiguration must be
carefully considered, especially for the bus, as an inappropriate reconfiguration may

26
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 result in loss of control of the entire space platform. Dynamic reconfiguration capability
in a specific payload may be more practical operationally.

System Maintenance (MA Family)

 Given the inability to physically access space platforms, maintenance is performed
remotely. As such, aspects of maintenance related to physical access are not applicable
(e.g., sanitizing removed components). However, the remote access aspects of
maintenance (centered on software) are applicable. Also applicable would be preemptive
maintenance of hardware, such as switching to redundant components before failures.
 Although maintenance tools are not “brought in” to the space platform, they are often
either installed before launch or used remotely. In such cases, the tools should undergo
appropriate inspection and approval before installation and use.
 Remote maintenance is distinct from non-local maintenance. On the ground, non-local
maintenance refers to contractors establishing a maintenance session on the mission
system from facilities not under the control of the mission organization. A parallel
concept for the space platform would be a contractor establishing a maintenance window
with the space platform directly from contractor facility, as opposed to the satellite
operations center controlled by the mission organization. A maintenance session is
analogous to a maintenance window.

Media Protection (MP Family)

 Media protection policies are different for the space platform, which does not have
removable media. The policies are focused on static storage on the platform and the
disposal issues related to that media.
 The physical environment (i.e., space) precludes unauthorized access to physical media.
 For any given space platform, there must be careful consideration of the extent to which
sanitization is required. For deorbit, consider whether components would survive reentry
with recoverable information. For movement to parking or disposal orbit, consider the
extent to which there is the threat of physical recovery of the space platform.
Implementation of any specific features to actively sanitize information needs to be
balanced against the risk of that feature being inadvertently or intentionally activated,
which could have significant mission impact. If components could survive reentry,
operational and/or technical controls need to be in place to determine if recovery
operations are required and, if practical, facilitate recovery of sensitive media.

Physical and Environmental (PE Family)

 The controls in this family are often intended to apply to a facility providing certain
capabilities or protections to the hosted information systems. The space platform can be
viewed as a “facility” of sorts, in that it suffers similar, but not necessarily identical,
threats and vulnerabilities that must be mitigated. However, the nature of physical and
environmental protection is very different for the space platform than for the ground
segments. Space platforms after launch are in an environment that is inherently difficult
to access. As such, the physical access to the space platform is precluded by the nature of
the environment. Further, it is presumed intrusion alarms and equivalent mechanisms are
not required for space platforms. The normal monitoring of space activities via the Space

27
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 Surveillance Network provides a level of space situational awareness, such that the
controls dealing with “gates, guards, and guns.”
 Some aspects of environmental controls remain of concern for the space platform, such as
power, temperature, and radiation. Other aspects of the environment are not relevant to
the vacuum of space, such as fire protection or water protection. In general, engineering
for the space environment is already a part of space system engineering; therefore, the
controls in this family are often redundant with existing space system design standards.
 Although humidity is not a concern in the vacuum of space, temperature is a concern.
Space platform design includes temperature sensors and systems designed to keep the
space platform components within operating temperature ranges. As such, temperature
controls are addressed by standard space platform engineering and no additional
mechanisms are required. Still, ground operators need training in understanding
temperature readings and how to address them when they go out of range.
 Space platform power distribution is focused on moving power from the solar arrays or
batteries to the bus, and from the bus to the payloads. The protection of these distribution
mechanisms from the hazards of the environment is critical, and a standard part of space
platform system design. Ground-based aspects of power distribution tend not to apply to
the space platform, such as the provisions for uninterruptable power supplies (the space
platform is essentially its own self-contained generator, by definition).
 Emanations leakage concerns exist between multiple payloads and between payloads and
the bus within a single space platform.

Security Planning (PL Family)

 System security planning could conceivably relate to the restoration priority of specific
payloads on the space platform in relationship to the bus.
 The focus for rules of behavior is on the ground support personnel responsible for
commanding the space platform.

Personnel Security (PS Family)

 The focus is on the ground support personnel supporting space platform commanding.
As those personnel may be congruent with the personnel supporting the ground segment,
satisfaction of these controls may be inherited from the ground segment.
 The access requirements for the space platform may differ based on the component being
commanded, and may take into account the fact that the ability to command the space
platform does not give the ability to access the information the entire space platform is
handling. For example, the clearance required to access and command the space platform
bus may be lower than the clearance required to access and command specific payloads
on the space platform.

Risk Assessment (RA Family)

 Analysis of the space platform is performed by personnel on the ground.
 Vulnerability scanning for the space platform from the point of view of external
adversaries is very different than for the ground system (the sole exception might be
space platforms implementing a true unencrypted network interface). Ground system
scanning focuses on running components of common tool packages against the network
interfaces in order to map out a system and determine vulnerabilities. In contrast, space
28
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 platform scanning would start with frequency scanning to determine if any response can
be obtained; from that point, it would be determined if any protocols can be exploited.
 Where the space platform software is unique to the mission and capabilities of that space
platform or payload, the standard approach of signature-based vulnerability scanning is
not appropriate. Specialized scanning tools may be required, and the scanning may need
to be focused on checking the integrity of the flight software. However, where more
advanced space platforms make use of COTS products, signature-based vulnerability
scanning may be appropriate.

System and Services Acquisition (SA Family)

 Space acquisitions focus most energy and funding on getting the development correct, as
there is not a multiple item production post development. Space acquisitions may also be
subject to specific processes and standards dictated by the acquiring organizations.
 Common Criteria aspects rarely apply, as space platforms rarely make use of validated
COTS components. The Federal Information Processing Standard (FIPS) aspects,
however, are significant. CNSSP No. 12 requires all cryptography used be approved by
NSA, and NSA tends to require FIPS cryptography, at minimum, for those components
using FIPS algorithms. It may also apply to cryptography acquired through the
Commercial Solutions Partnership Program (CSPP) of NSA.
 A public domain binary cannot run unmodified on a space platform. Note that control
SA-5(5) is always applicable for the space platform, mandating source code be delivered.
 The space platform is extremely unlikely to provide the ability to install user software,
thus controls relating to this capability would not be applicable.
 Spares are built into the space platform as a redundant component.
 Supply chain protections must be considered as part of the overall comprehensive,
defense-in-depth information security strategy in the space systems acquisition and
system life cycle. Space systems, subsystems and components typically have stringent
reliability requirements, often are highly specialized, low production and high cost units.
Supply chain protections should address authenticity (counterfeit parts may be less
reliable), integrity (counterfeit parts may have undesirable undocumented functionality)
and availability (low production units can become unavailable as the technology becomes
obsolete). Supply chain protection measures may include stockpiling of parts and
provisioning for on orbit or on ground spares.

System and Communications Protection (SC Family)

 The space platform communications infrastructure is more limited than that of the ground
segment. Current space platforms rarely have wide-open TCP/IP connections found on
ground-based networks, although that may change with future space platforms.
 Application partitioning could apply to separation of the payload from the bus, the data
from the control planes, or isolation of functions to specific fractionated space platforms.
Within the space platform, it is extremely unlikely either the bus or a hosted national
security payload will be publically accessible.
 Denial-of-service attacks in the space domain are different than in ground networks.
Normal denial-of-service threats are not present for conventional space platforms, and
non-compliance with related controls doesn’t introduce significant risk. However, on
advanced fully-networked space platforms, or in fractionated designs, it may be
29
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 appropriate to use network access control lists (ACL) or other techniques to limit
(presumably authorized) users’ ability to launch denial-of-service attacks from
components of the space platform.
 The boundary device for space platforms is the cryptographic interface, which ensures
only authorized entities (i.e., those possessing the correct algorithm implementation and
keys) can communicate. More advanced space platforms (e.g., those supporting
advanced networking) may implement mechanisms such as firewalls above and beyond
the cryptography. Note that for cryptographic boundary devices, the space platform does
not monitor the traffic in the same way a firewall monitors traffic, especially with respect
to the production of audit.
 Space platforms may support “bypass mode,” which permits communications with the
ground when the cryptographic mechanisms on the space vehicle fail. This is an
emergency mode, and is considered an explicitly authorized communication.
 Space platforms have supplemental considerations, dictated by policies such as CNSSP
No. 12, requiring use of encryption and TRANSEC for specific functions. The
encryption used for confidentiality may also provide integrity protection. For space
systems, selection of the appropriate strength of encryption algorithm and
implementation must be in accordance with CNSSP No. 12.
 Implementation of an NSA-certified and/or approved cryptographic device is the only
approved method for the protection of the confidentiality of classified or sensitive
transmitted (uplink, downlink) information to/from a satellite. The protection of the
transmitted data may be achieved through a combination of COMSEC for confidentiality
and TRANSEC for Low probability of Intercept (LPI) and/or Low probability of
detection (LPD). TRANSEC techniques to provide resilience against jamming, known as
anti-jam (AJ) may not apply here since AJ is used for protection against denial of service.
 Trusted path should provide assurance the space-based end of the wireless connection is
the specific space platform component (bus, hosted payload) is truly what it claims to be.
A ground-based user must not talk to a payload believing it to be the bus.
 Session authenticity controls are only appropriate for advanced space platforms
supporting sessions. Although the communications window for a conventional space
platform might be considered a “session,” it does not have the relevant characteristics of
a session: there is no initiation point, and more importantly there is no termination of the
session that closes the window. This relates to how the command sequence numbers
work. Although it is possible to view sequence numbers as analogous to a web session
identifier, they are distinctly different in that the sequence does not become invalid at the
end of a communications window. As such, they serve more to address preventing
command replay than the validity of a session.
 For controls relating to non-modifiable executable programs, a space platform does not
have the ability to support removable read-only media, but they do have the ability to
store platform executable images on read-only memory (ROM) for emergency reloading
and recovery when an uploaded image becomes corrupted.

System and Information Integrity (SI Family)

 Integrity for space components has different policies than ground components. Physical
intrusion is of no concern post-launch due to inaccessibility in space; physical intrusion

30
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 prior to launch occurs prior to authorization to operate but must be addressed through
assignment and implementation of controls for that portion of the life cycle.
 Logical intrusion has a different focus, as space platforms rarely provide general-purpose
operating systems or publically available interfaces.
 Frequency of scanning on space platforms can be less than for ground-based systems, due
to infrequent changes to system components or less accessibility to the space platform.
Further, the nature of the scanning may be different, looking more at software versions as
opposed to patches applied, due to the way software is loaded into the space platform.
Processes and procedures need to be in place to assure all software uploaded to the space
platform—either by organizational users or non-organizational users with hosted
payloads—is appropriately scanned. Arbitrary code cannot be uploaded onto space
platforms; therefore, scanning for malicious code is performed by ground personnel
before any code is uploaded to the space platforms. Although a space platform could
perform malware scanning, the overhead of this scanning combined with the fact that
space platforms do not use susceptible commodity operating systems make ground-based
scanning more effective.
 There are no direct non-privileged users on the space platform. However, the threat to be
addressed is that hosted payload software might bypass malicious code detection.
 Monitoring of events is not the traditional network or host-based intrusion detection
system (IDS), but rather looking at space platform-specific attack patterns (e.g. jamming)
and geolocation of attackers. This could conceivably include examination of
communications to the space platform, both before decryption and after decryption. The
nature of the sensors might thus include both traditional software monitors as well as
specialized detectors.
 The nature of testing—and more importantly, the frequency of testing—will be different,
because most space platforms do not use traditional network communications, and thus
commodity test packages would be inappropriate. Further, the nature of space platform
software means there is less capability for the tools to change, meaning that testing could
be restricted to known maintenance windows. The decision depends on the specific
mission of the space platform, the ease of testing, and the volatility of the mechanism.
 The VPN traffic concern does not apply to the space platform—note the distinction
between information transmitted to the space platform, as opposed to information
transmitted through the space platform. For the latter, intrusion detection is best provided
on the ground, as the traffic is treated as opaque blocks by the space platform. For traffic
terminating on the space platform, this is a valid concern. Space platform
communications are encrypted, and the intrusion monitoring must look for anomalous
patterns after the traffic is decrypted.
 Generally, rogue wireless devices have the implication of traditional Internet wireless
communications (“Wi-Fi”), not the type of wireless device. There might be a similar risk
in fractionated space platform constellations (i.e., of a rogue fraction attempting to enter
the constellation); however, the nature of space is such that such a space platform would
be easily identified through monitoring of space objects and launches. There is, however,
the possibility a rogue space platform might have more than one mission, which may not
be discernible through normal space monitoring.
 Information Assurance Vulnerability Alert (IAVA) would rarely be issued on software
used in conventional space platform. There are a number of reasons for this:
31
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 conventional space platform software tends to be unique to the space platform, and space
platform software is rarely reused as a single component. Reuse remains a concern: the
operating organization should be on alert for IAVAs related to third-party components or
modules integrated into the space platform software. For more advanced space platforms
using COTS products, IAVAs may be issued, and the space platform must be designed
such that IAVAs could be implemented.
 Predictable failure prevention addresses proactive transfer to a spare in the space segment
based on statistical mean time to failure (MTTF) analysis (i.e., before a component is
expected to fail). However, redundancy has its limitations; the space platform cannot
carry an unlimited number of spares. Given this and that (i) components often run longer
than their MTTF before failure, and (ii) transfer to the redundant component carries its
own risks of failure, it is more appropriate for space platforms to transfer when the
component fails, and not before. Although there have been cases where a spare was used
and an older asset was put in an inactive state and used for another purpose or as a spare,
this is not done in a proactive fashion based on MTTF. There are risks associated with
transferring space platform components; therefore, it makes more sense to transfer only
when needed to maintain service rather than perform transfers on a routine schedule.

Information Security Program (PM Family)

 These controls are normally met through programs and processes defined by upper levels
of the organization, and inherited by the specific program.
 The program may need to implement programmatic measures to support the control.

9. Duration

The Space Platform Overlay should be reviewed and updated whenever:

 Overarching or space-specific policy or instructions (e.g., CNSSP No. 12) are revised,
replaced, or terminated
 New space-specific threat assessments are issued by appropriate authorities
 There are significant changes in space system or cyber security technology
 There are significant changes in the space
operational concepts or architectures.

10. Definitions
This overlay uses terms in NIST SP 800-53, Rev. 3, CNSSI No. 4009, National Information
Assurance (IA) Glossary, or CNSSP No. 12. The following space-unique terms are defined in
CNSSP No. 12: bus, launch vehicle, NSA-approved cryptographies, payload, space platform,
and space system. Terms unique to this overlay and not defined elsewhere are defined below.

Advanced platform An advanced platform is a space platform that may be networked using a
network protocol stack (such as IP protocols); may require relatively
powerful on-board processors; in addition to simple command
authentication, may support asymmetric encryption for authentication/
signatures (in addition to symmetric encryption); may use digitally-signed
32
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F
 commanding; may support multiple communities of interest; may support
user accounts (with unique login); may have relatively high on-board
storage requirements; in terms of communications, may support more
advanced interfaces, such as a flexible/adaptable bit rate interface; may be
capable of supporting packet-based encryption for commands, telemetry, or
data; and may use both switchable and routable relaying.

Conventional platform A conventional platform is a space platform that is not networked; uses
command authentication for access control (that is, verification the
command is valid as opposed to verification of the source of the
command); has a serial/constant bit rate (CBR) interface; uses link
encryption for commands, telemetry, and data; and may use a bent-pipe
approach to relaying.

Ground segment That portion of a space system used to command and control space
segment components. The ground segment consists of mission operations
centers, tracking stations, and relay stations.

Launch segment That portion of a space system that launches a space platform into space. It
consists of launch vehicles, launch range, payload adapter, and launch site
services (such as range safety and payload integration and processing).

Space segment That portion of a space system consisting of the primary mission space
platforms, mission payloads flown on other space platforms, and any relay
satellites necessary for mission operations.

User segment That portion of a space system consisting of land, sea, air, and/or space-
borne terminals used by those in the field to carry out the mission of the
space system.

33
Space Platform Overlay
06/01/2013 Attachment 2 to Appendix F