On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code
| Requirement | Rationale/Additional Guidance/Notes |
|---|---|
| The Program shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes]. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9} {SA-3,SA-4(3)} | Select the particular subcontractors, software vendors, and manufacturers based on the criticality analysis performed for the Program Protection Plan and the criticality of the components that they supply. |
| The Program shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes]. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9} {SA-3,SA-4(3)} | For the spacecraft FSW, the defined security configuration could include to ensure the software does not contain a pre-defined list of Common Weakness Enumerations (CWEs)and/or CAT I/II Application STIGs. |
| The Program shall require the developer of the system, system component, or system service to deliver the system, component, or service with [Program-defined security configurations] implemented. {SV-SP-1,SV-SP-9} {SA-4(5)} | |
| The Program shall require the developer of the system, system component, or system service to use [Program-defined security configurations] as the default for any subsequent system, component, or service reinstallation or upgrade. {SV-SP-1,SV-SP-3,SV-SP-9} {SA-4(5)} | |
| The Program shall review proposed changes to the spacecraft, assessing both mission and security impacts. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-10,CM-3(2)} | |
| The Program shall perform configuration management during system, component, or service during [design; development; implementation; operations]. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-10} | |
| The Program prohibits the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {CM-7(8)} | |
| The spacecraft shall prevent the installation of Flight Software without verification that the component has been digitally signed using a certificate that is recognized and approved by the Program. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9} {CM-14} | |
| The Program shall perform and document threat and vulnerability analyses of the as-built system, system components, or system services. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(2)} | |
| The Program shall use the threat and vulnerability analyses of the as-built system, system components, or system services to inform and direct subsequent testing/evaluation of the as-built system, component, or service. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(2)} | |
| The Program shall perform a manual code review of all flight code. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(4)} | |
| The Program shall conduct an Attack Surface Analysis and reduce attack surfaces to a level that presents a low level of compromise by an attacker. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(6),SA-15(5)} | |
| The Program shall use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(2),SA-15(8)} | The security assessment plan should include evaluation of mission objectives in relation to the security of the mission. Assessments should not only be control based but also functional based to ensure mission is resilient against failures of controls. |
| The Program shall create and implement a security assessment plan that includes: (1) The types of analyses, testing, evaluation, and reviews of [all] software and firmware components; (2) The degree of rigor to be applied to include abuse cases and/or penetration testing; and (3) The types of artifacts produced during those processes. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11,SA-11(5),CA-8} | * The frequency of testing should be driven by Program completion events and updates. * Examples of approaches are static analyses, dynamic analyses, binary analysis, or a hybrid of the three approaches |
| The Program shall verify that the scope of security testing/evaluation provides complete coverage of required security controls (to include abuse cases and penetration testing) at the depth of testing defined in the test documents. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(5),SA-11(7),CA-8} | The depth needs to include functional testing as well as negative/abuse testing. |
| The Program shall perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Program-defined depth and coverage]. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11} | |
| The Program shall maintain evidence of the execution of the security assessment plan and the results of the security testing/evaluation. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11,CA-8} | The verifiable process should also include a cross reference to mission objectives and impact statements. Understanding the flaws discovered and how they correlate to mission objectives will aid in prioritization. |
| The Program shall implement a verifiable flaw remediation process into the developmental and operational configuration management process. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11} | Flaws that impact the mission objectives should be prioritized. |
| The Program shall correct flaws identified during security testing/evaluation. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11} | |
| The Program shall perform vulnerability analysis and risk assessment of [all systems and software]. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15(7),RA-5} | |
| The Program shall identify, report, and coordinate correction of cybersecurity-related information system flaws. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SI-2} | * Although this requirement is stated to specifically apply to cybersecurity-related flaws, the Program office may choose to broaden it to all SV flaws. * This requirement is allocated to the Program, as it is presumed, they have the greatest knowledge of the components of the system and when identified flaws apply. |
| The Program shall correct reported cybersecurity-related information system flaws. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SI-2} | This requirement is focused on software and firmware flaws. If hardware flaw remediation is required, refine the requirement to make this clear. |
| The Program shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects on mission systems in a separate test environment before installation. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SI-2,CM-3(2),CM-4(1)} | On-orbit patching/upgrades may be necessary if vulnerabilities are discovered after launch. The system should have the ability to update software post-launch. |
| The Program shall release updated versions of the mission information systems incorporating security-relevant software and firmware updates, after suitable regression testing, at a frequency no greater than [Program-defined frequency [90 days]]. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {CM-3(2),CM-4(1)} | |
| The spacecraft shall be capable of removing flight software after updated versions have been installed. {SV-SP-1,SV-SP-9} {SI-2(6)} | Component/Origin scanning looks for open-source libraries/software that may be included into the baseline and looks for known vulnerabilities and open-source license violations. |
| The Program shall ensure that vulnerability scanning tools and techniques are employed that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: (1) Enumerating platforms, custom software flaws, and improper configurations; (2) Formatting checklists and test procedures; and (3) Measuring vulnerability impact. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {RA-5} | The prioritized list of CWEs should be created considering operational environment, attack surface, etc. Results from the threat modeling and attack surface analysis should be used as inputs into the CWE prioritization process. There is also a CWSS (https://cwe.mitre.org/cwss/cwss_v1.0.1.html) process that can be used to prioritize CWEs. The prioritized list of CWEs can help with tools selection as well as you select tools based on their ability to detect certain high priority CWEs. |
| The Program shall create prioritized list of software weakness classes (e.g., Common Weakness Enumerations) to be used during static code analysis for prioritization of static analysis results. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(1),SA-15(7)} | |
| The Program shall perform static source code analysis for [all available source code] looking for [Select one {Program-defined Top CWE List, SANS Top 25, OWASP Top 10}] weaknesses using no less than two static code analysis tools. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(1),SA-15(7),RA-5} | |
| The Program shall perform component analysis (a.k.a. origin analysis) for developed or acquired software. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15(7),RA-5} | |
| The Program shall analyze vulnerability/weakness scan reports and results from security control assessments. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {RA-5} | |
| The Program shall determine the vulnerabilities/weaknesses that require remediation, and coordinate the timeline for that remediation, in accordance with the analysis of the vulnerability scan report, the Program assessment of risk, and mission needs. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {RA-5} | |
| The Program shall ensure that the vulnerability scanning tools (e.g., static analysis and/or component analysis tools) used include the capability to readily update the list of potential information system vulnerabilities to be scanned. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {RA-5} | |
| The Program shall ensure that the list of potential system vulnerabilities scanned is updated [prior to a new scan] {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {RA-5(2)} | |
| The Program shall define acceptable coding languages to be used by the software developer. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15} | |
| The Program shall define acceptable secure coding standards for use by the developer. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15} | Manual review cannot scale across the code base; you must have a way to scale in order to confirm your coding standards are being met. The intent is for automated means to ensure code adheres to a coding standard. |
| The Program shall have automated means to evaluate adherence to coding standards. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15,SA-15(7),RA-5} | Fuzzing and/or dynamic analysis with abuse cases is important to flush out edge cases and how malicious actors could affect the spacecraft's FSW. Not all defects (i.e., buffer overflows, race conditions, and memory leaks) can be discovered statically and require execution of the software. This is where space-centric cyber testbeds (i.e., cyber ranges) are imperative as they provide an environment to maliciously attack components in a controlled environment to discover these undesirable conditions. Technology has improved to where digital twins for spacecraft are achievable, which provides an avenue for cyber testing that was often not performed due to perceived risk to the flight hardware. |
| The Program shall employ dynamic analysis (e.g., using simulation, penetration testing, fuzzing, etc.) to identify software/firmware weaknesses and vulnerabilities in developed and incorporated code (open source, commercial, or third-party developed code). {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(5),SA-11(8),CA-8} | The intent is for multiple checks to be performed prior to executing these SV SW updates. One action is mere act of uploading the SW to the spacecraft. Another action could be check of digital signature (ideal but not explicitly required) or hash or CRC or a checksum. Crypto boxes provide another level of authentication for all commands, including SW updates but ideally there is another factor outside of crypto to protect against FSW updates. |
| See threat IDs SV-SP-1,SV-SP-3,SV-SP-4, and SV-SP-10 for general supply chain protections. But any SW update should have two-man rule enacted. The spacecraft shall require multi-factor authorization for all SV [applications or operating systems] updates within the spacecraft. {SV-SP-9,SV-SP-11} {AC-3(2)} | |
| This would be similar to inserting malicious logic into the spacecraft during the development (HW and SW supply chain which are covered under SV-SP-5, SV-SP-3, and SV-SP-4)or via SW update process once launched which is covered under threat ID SV-SP-9. Depending on the implementation of the payload/component the controls would be different therefore specific requirements are not generated for this particular threat but are covered by other threats. Additionally, EPS related requirements/controls were also mentioned with SV-MA-3. {SV-MA-8} {SC-6} | |
| This would be similar to inserting malicious logic into the spacecraft during the development (HW and SW supply chain which are covered under SV-SP-3, SV-SP-4, SV-SP-6, and SV-SP-7)or via SW update process once launched which is covered under threat ID SV-SP-9. Depending on the implementation of the SDR the controls would be different therefore specific requirements are not generated for this particular threat but are covered by other threats. {SV-SP-11} |
| ID | Name | Description | |
|---|---|---|---|
| IA-0001 | Compromise Supply Chain | Threat actors may manipulate or compromise products or product delivery mechanisms before the customer receives them in order to achieve data or system compromise. | |
| IA-0001.01 | Software Dependencies & Development Tools | Threat actors may manipulate software dependencies (i.e. dependency confusion) and/or development tools prior to the customer receiving them in order to achieve data or system compromise. Software binaries and applications often depend on external software to function properly. SV developers may use open source projects to help with their creation. These open source projects may be targeted by threat actors as a way to add malicious code to the victim SV's dependencies. | |
| IA-0001.02 | Software Supply Chain | Threat actors may manipulate software binaries and applications prior to the customer receiving them in order to achieve data or system compromise. This attack can take place in a number of ways, including manipulation of source code, manipulation of the update and/or distribution mechanism, or replacing compiled versions with a malicious one. | |
| IA-0007 | Compromise Ground Station | Threat actors may initially compromise the ground station in order to access the target SV. Once compromised, the threat actor can perform a multitude of initial access techniques, including replay, compromising FSW deployment, compromising encryption keys, and compromising authentication schemes. | |
| IA-0007.01 | Compromise On-Orbit Update | Threat actors may manipulate and modify on-orbit updates before they are sent to the target SV. This attack can be done in a number of ways, including manipulation of source code, manipulating environment variables, on-board table/memory values, or replacing compiled versions with a malicious one. | |
| IA-0009 | Trusted Relationship | Access through trusted third-party relationship exploits an existing connection that has been approved for interconnection. Leveraging third party / approved interconnections to pivot into the target systems is a common technique for threat actors as these interconnections typically lack stringent access control due to the trusted status. | |
| EX-0010 | Inject Malicious Code | Threat actors may rely on other tactics and techniques in order to inject malicious code into the victim SV. This can be done via compromising the supply chain or development environment in some capacity or taking advantage of known commands. However, once malicious code has been uploaded to the victim SV, the threat actor can then trigger the code to run via a specific command or wait for a legitimate user to trigger it accidently. The code itself can do a number of different things to the hosted payload, subsystems, or underlying OS. | |
| EX-0012 | Modify On-Board Values | Threat actors may perform specific commands in order to modify onboard values that the victim SV relies on. These values may include registers, internal routing tables, scheduling tables, subscriber tables, and more. Depending on how the values have been modified, the victim SV may no longer be able to function. | |
| EX-0012.01 | Registers | Threat actors may target the internal registers of the victim SV in order to modify specific values as the FSW is functioning or prevent certain subsystems from working. Most aspects of the SV rely on internal registries to store important data and temporary values. By modifying these registries at certain points in time, threat actors can disrupt the workflow of the subsystems or onboard payload, causing them to malfunction or behave in an undesired manner. | |
| EX-0012.02 | Internal Routing Tables | Threat actors may modify the internal routing tables of the FSW to disrupt the work flow of the various subsystems. Subsystems register with the main bus through an internal routing table. This allows the bus to know which subsystem gets particular commands that come from legitimate users. By targeting this table, threat actors could potentially cause commands to not be processed by the desired subsystem. | |
| EX-0012.03 | Memory Write/Loads | Threat actors may utilize the target SV's ability for direct memory access to carry out desired effect on the target SV. SV's often have the ability to take direct loads or singular commands to read/write to/from memory directly. SV's that contain the ability to input data directly into memory provides a multitude of potential attack scenarios for a threat actor. Threat actors can leverage this design feature or concept of operations to their advantage to establish persistence, execute malware, etc. | |
| EX-0012.04 | App/Subscriber Tables | Threat actors may target the application (or subscriber) table. Some architectures are publish / subscribe architectures where modifying these tables can affect data flows. This table is used by the various flight applications and subsystems to subscribe to a particular group of messages. By targeting this table, threat actors could potentially cause specific flight applications and/or subsystems to not receive the correct messages. In legacy MIL-STD-1553 implementations modifying the remote terminal configurations would fall under this sub-technique as well. | |
| EX-0012.05 | Scheduling Algorithm | Threat actors may target scheduling features on the target SV. SV's are typically engineered as real time scheduling systems which is composed of the scheduler, clock and the processing hardware elements. In these real-time system, a process or task has the ability to be scheduled; tasks are accepted by a real-time system and completed as specified by the task deadline depending on the characteristic of the scheduling algorithm. Threat actors can attack the scheduling capability to have various effects on the SV. | |
| EX-0012.07 | Propulsion Subsystem | Threat actors may target the onboard values for the propulsion subsystem of the victim SV. The propulsion system on SVs obtain a limited supply of resources that are set to last the entire lifespan of the SV while in orbit. There are several automated tasks that take place if the SV detects certain values within the subsystem in order to try and fix the problem. If a threat actor modifies these values, the propulsion subsystem could over-correct itself, causing the wasting of resources, orbit realignment, or, possibly, causing detrimental damage to the SV itself. This could cause damage to the purpose of the SV and shorten it's lifespan. | |
| EX-0012.08 | Attitude Determination & Control Subsystem | Threat actors may target the onboard values for the Attitude Determination and Control subsystem of the victim SV. This subsystem determines the positioning and orientation of the SV. Throughout the SV's lifespan, this subsystem will continuously correct it's orbit, making minor changes to keep the SV aligned as it should. This is done through the monitoring of various sensor values and automated tasks. If a threat actor were to target these onboard values and modify them, there is a chance that the automated tasks would be triggered to try and fix the orientation of the SV. This can cause the wasting of resources and, possibly, the loss of the SV, depending on the values changed. | |
| EX-0012.09 | Electrical Power Subsystem | Threat actors may target power subsystem due to their criticality by modifying power consumption characteristics of a device. Power is not infinite on-board the SV and if a threat actor were to manipulate values that cause rapid power depletion it could affect the SV's ability to maintain the required power to perform mission objectives. | |
| EX-0012.10 | Command & Data Handling Subsystem | Threat actors may target the onboard values for the Command and Data Handling Subsystem of the victim SV. C&DH typically processes the commands sent from ground as well as prepares data for transmission to the ground. Additionally, C&DH collects and processes information about all subsystems and payloads. Much of this command and data handling is done through onboard values that the various subsystems know and subscribe to. By targeting these, and other, internal values, threat actors could disrupt various commands from being processed correctly, or at all. Further, messages between subsystems would also be affected, meaning that there would either be a delay or lack of communications required for the SV to function correctly. | |
| EX-0012.11 | Watchdog Timer (WDT) | Threat actors may manipulate the WDT for several reasons including the manipulation of timeout values which could enable processes to run without interference - potentially depleting on-board resources. For spacecraft, WDTs can be either software or hardware. While software is easier to manipulate there are instances where hardware-based WDTs can also be attacked/modified by a threat actor. | |
| EX-0012.12 | System Clock | An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, such as forcing execution of stored commands in an incorrect order. | |
| EXF-0009 | Compromised Partner Site | Threat actors may compromise access to partner sites that can be used for future campaigns or to perpetuate other techniques. These sites are typically configured for communications to the primary ground station(s) or in some cases the SV itself. Unlike mission operated ground systems, partner sites may provide an easier target for threat actors depending on the company, roles and responsibilities, and interests of the third-party. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration. | |
| PER-0001 | Memory Compromise | Threat actors may manipulate memory (boot, RAM, etc.) in order for their malicious code and/or commands to remain on the victim SV. The SV may have mechanisms that allow for the automatic running of programs on system reboot, entering or returning to/from safe mode, or during specific events. Threat actors may target these specific memory locations in order to store their malicious code or file, ensuring that the attack remains on the system even after a reset. | |
| PER-0002 | Backdoor | Threat actors may find and target various backdoors, or inject their own, within the victim SV in the hopes of maintaining their attack. | |
| PER-0002.02 | Software | Threat actors may inject code to create their own backdoor to establish persistent access to the SV. This may be done through modification of code throughout the software supply chain or through modification of the software-defined radio configuration (if applicable). | |
| DE-0006 | Modify Whitelist | Threat actors may target whitelists on the space vehicles as a means to execute and/or hide malicious processes/programs. Whitelisting is a common technique used on traditional IT systems but has also been used on space vehicles. Whitelisting is used to prevent execution of unknown or potentially malicious software. However, this technique can be bypassed if not implemented correctly but threat actors may also simply attempt to modify the whitelist outright to ensure their malicious software will operate on the space vehicle that utilizes whitelisting. | |
| IMP-0001 | Deception (or Misdirection) | Threat actors may seek to deceive mission stakeholders (or even military decision makers) for a multitude of reasons. Telemetry values could be modified, attacks could be designed to intentionally mimic another threat actor's TTPs, and even allied ground infrastructure could be compromised and used as the source of communications to the SV. | |
| IMP-0002 | Disruption | Threat actors may seek to disrupt communications from the victim SV to the ground controllers or other interested parties. By disrupting communications during critical times, there is the potential impact of data being lost or critical actions not being performed. This could cause the SV's purpose to be put into jeopardy depending on what communications were lost during the disruption. This behavior is different than Denial as this attack can also attempt to modify the data and messages as they are passed as a way to disrupt communications. | |
| IMP-0003 | Denial | Threat actors may seek to deny ground controllers and other interested parties access to the victim SV. This would be done exhausting system resource, degrading subsystems, or blocking communications entirely. This behavior is different from Disruption as this seeks to deny communications entirely, rather than stop them for a length of time. | |
| IMP-0004 | Degradation | Threat actors may target various subsystems or the hosted payload in such a way in order to rapidly increase it's degradation. This could potentially shorten the lifespan of the victim SV. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0000 | Countermeasure Not Identified | This technique is a result of utilizing TTPs to create an impact and the applicable countermeasures are associated with the TTPs leveraged to achieve the impact | None | None | ||
| CM0001 | Protect Sensitive Information | Organizations should look to identify and properly classify mission sensitive design/operations information (e.g., fault management approach) and apply access control accordingly. Any location (ground system, contractor networks, etc.) storing design information needs to ensure design info is protected from exposure, exfiltration, etc. Space system sensitive information may be classified as Controlled Unclassified Information (CUI) or Company Proprietary. Space system sensitive information can typically include a wide range of candidate material: the functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, CUI, proprietary, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission. Sensitive documentation should only be accessed by personnel with defined roles and a need to know. Well established access controls (roles, encryption at rest and transit, etc.) and data loss prevention (DLP) technology are key countermeasures. The DLP should be configured for the specific data types in question. | AC-3(11) AC-4(23) AC-4(25) CM-12 CM-12(1) PM-11 PM-17 SA-3(1) SA-3(2) SA-4(12) SA-5 SA-9(7) SI-21 SI-23 SR-12 SR-7 | A.8.4 A.8.11 A.8.10 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.10 A.5.22 | ||