|
The Program shall protect against supply chain threats to the system, system components, or system services by employing [institutional-defined security safeguards] {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-1}
|
During SCRM, criticality analysis will aid in determining supply chain risk. For mission critical functions/components, extra scrutiny must be applied to ensure supply chain is secured.
|
|
The Program shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design. {SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4} {SR-1,RA-9,SA-15(3),CP-2(8)}
|
The intent of this requirement is to address supply chain concerns on hardware and software vendors. Not required for trusted suppliers accredited to the Defense Microelectronic Activity (DMEA). If the Program intends to use a supplier not accredited by DMEA, the government customer should be notified as soon as possible. If the Program has internal processes to vet suppliers, it may meet this requirement. All software used and its origins must be included in the SBOM and be subjected to internal and Government vulnerability scans.
|
|
The Program shall request threat analysis of suppliers of critical components and manage access to and control of threat analysis products containing U.S. person information. {SV-SP-3,SV-SP-4,SV-SP-11} {SR-1}
|
This could include tailored acquisition strategies, contract tools, and procurement methods.
|
|
The Program shall employ the [Program-defined] approaches for the purchase of the system, system components, or system services from suppliers. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-5}
|
Examples include: (1) Transferring a portion of the risk to the developer or supplier through the use of contract language and incentives; (2) Using contract language that requires the implementation of SCRM throughout the system lifecycle in applicable contracts and other acquisition and assistance instruments (grants, cooperative agreements, Cooperative Research and Development Agreements (CRADAs), and other transactions). Within the DOD some examples include: (a) Language outlined in the Defense Acquisition Guidebook section 13.13. Contracting; (b) Language requiring the use of protected mechanisms to deliver elements and data about elements, processes, and delivery mechanisms; (c) Language that articulates that requirements flow down supply chain tiers to sub-prime suppliers. (3) Incentives for suppliers that: (a) Implement required security safeguards and SCRM best practices; (b) Promote transparency into their organizational processes and security practices; (c) Provide additional vetting of the processes and security practices of subordinate suppliers, critical information system components, and services; and (d) Implement contract to reduce SC risk down the contract stack. (4) Gaining insight into supplier security practices; (5) Using contract language and incentives to enable more robust risk management later in the lifecycle; (6) Using a centralized intermediary or “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary;
|
|
The Program shall maintain documentation tracing the strategies, tools, and methods implemented to the Program-defined strategies, tools, and methods as a means to mitigate supply chain risk . {SV-SP-3,SV-SP-4,SV-AV-7} {SR-5}
|
|
|
The Program shall employ [Selection (one or more): independent third-party analysis, Program penetration testing, independent third-party penetration testing] of [Program-defined supply chain elements, processes, and actors] associated with the system, system components, or system services. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-6(1)}
|
Penetration testing should be performed throughout the lifecycle on physical and logical systems, elements, and processes including: (1) Hardware, software, and firmware development processes; (2) Shipping/handling procedures; (3) Personnel and physical security programs; (4) Configuration management tools/measures to maintain provenance; and (5) Any other programs, processes, or procedures associated with the production/distribution of supply chain elements.
|
|
The Program shall perform penetration testing/analysis: (1) On potential system elements before accepting the system; (2) As a realistic simulation of the active adversary’s known adversary tactics, techniques, procedures (TTPs), and tools; and (3) Throughout the lifecycle on physical and logical systems, elements, and processes. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SA-11(5)}
|
Examples of security safeguards that the organization should consider implementing to limit the harm from potential adversaries targeting the organizational supply chain, are: (1) Using trusted physical delivery mechanisms that do not permit access to the element during delivery (ship via a protected carrier, use cleared/official couriers, or a diplomatic pouch); (2) Using trusted electronic delivery of products and services (require downloading from approved, verification-enhanced sites); (3) Avoiding the purchase of custom configurations, where feasible; (4) Using procurement carve outs (i.e., exclusions to commitments or obligations), where feasible; (5) Using defensive design approaches; (6) Employing system OPSEC principles; (7) Employing a diverse set of suppliers; (8) Employing approved vendor lists with standing reputations in industry; (9) Using a centralized intermediary and “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary Employing inventory management policies and processes; (10) Using flexible agreements during each acquisition and procurement phase so that it is possible to meet emerging needs or requirements to address supply chain risk without requiring complete revision or re-competition of an acquisition or procurement; (11) Using international, national, commercial or government standards to increase potential supply base; (12) Limiting the disclosure of information that can become publicly available; and (13) Minimizing the time between purchase decisions and required delivery.
|
|
The Program shall employ [Program-defined] techniques to limit harm from potential adversaries identifying and targeting the Program supply chain. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-3(2),SC-38}
|
* The Program should also consider sub suppliers and potential sub suppliers.
* All-source intelligence of suppliers that the organization may use includes: (1) Defense Intelligence Agency (DIA) Threat Assessment Center (TAC), the enterprise focal point for supplier threat assessments for the DOD acquisition community risks; (2) Other U.S. Government resources including: (a) Government Industry Data Exchange Program (GIDEP) – Database where government and industry can record issues with suppliers, including counterfeits; and (b) System for Award Management (SAM) – Database of companies that are barred from doing business with the US Government.
|
|
The Program shall use all-source intelligence analysis of suppliers and potential suppliers of the information system, system components, or system services to inform engineering, acquisition, and risk management decisions. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {RA-3(2)}
|
|
|
The Program (and Prime Contractor) shall conduct a supplier review prior to entering into a contractual agreement with a contractor (or sub-contractor) to acquire systems, system components, or system services. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-6}
|
Ideally you have diversification with suppliers
|
|
The Program shall maintain a list of suppliers and potential suppliers used, and the products that they supply to include software. {SV-SP-3,SV-SP-4,SV-SP-11} {PL-8(2)}
|
OPSEC safeguards may include: (1) Limiting the disclosure of information needed to design, develop, test, produce, deliver, and support the element for example, supplier identities, supplier processes, potential suppliers, security requirements, design specifications, testing and evaluation result, and system/component configurations, including the use of direct shipping, blind buys, etc.; (2) Extending supply chain awareness, education, and training for suppliers, intermediate users, and end users; (3) Extending the range of OPSEC tactics, techniques, and procedures to potential suppliers, contracted suppliers, or sub-prime contractor tier of suppliers; and (4) Using centralized support and maintenance services to minimize direct interactions between end users and original suppliers.
|
|
The Program shall employ [Program-defined Operations Security (OPSEC) safeguards] to protect supply chain-related information for the system, system components, or system services. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-7,SC-38,CP-2(8)}
|
|
|
The Program shall develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including support tamper resistance and provide a level of protection against the introduction of malicious code or hardware. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-11}
|
|
|
The Program shall report counterfeit information system components to [Selection (one or more): source of counterfeit component; [Program-defined external reporting organizations]; [Program-defined personnel or roles]]. {SV-SP-4} {SR-11}
|
|
|
The Program shall develop and implement anti-counterfeit policy and procedures, in coordination with the [CIO], that is demonstrably consistent with the anti-counterfeit policy defined by the Program office. {SV-SP-4,SV-SP-11} {SR-11}
|
|
|
The Program shall report counterfeit information system components to the [CIO]. {SV-SP-4} {SR-11}
|
|
|
See threat ID number SV-SP-3 for information on software development requirements. In general terms threat ID SV-SP-4 applies from a generic sense since software reuse or COTS usage is a supply chain concern. The Program shall ensure that software planned for reuse meets the fit, form, and function, and security as a component within the new application. {SV-SP-6,SV-SP-7,SV-SP-11} {CM-7(5)}
|
|
|
Watchdog timers can be implemented via hardware of software. See threat ID SV-SP-3, SV-SP-4, and SV-SP-5 for information on SW, supply chain, and tainted hardware requirements. The watchdog timer is likely considered mission critical/cyber critical therefore requirements from threat ID SV-MA-3 may come into play. Since this threat can be either HW or SW, view the other threat IDs for requirements/controls to mitigate this threat but it is imperative to synchronize system clocks within and between systems and system components.. {SV-AV-3} {SC-45,SC-45(1),SC-45(2)}
|
|
|
Nothing specific to eliminate the availability threat of TT&C failing over time. Requirements are covered under threat ID SV-SP-3, SV-SP-4,SV-MA-3 and SV-AV-Strong fault management and redundancy also helps mitigate threats against TT&C. {SV-AV-7}
|
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)}
|
Source code should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally source code would be rated SECRET or higher and stored on classified networks. NIST 800-171 is insufficient when protecting highly sensitive unclassified information and more robust controls from NIST SP 800-53 and CNSSI 1253 should be employed. Greater scrutiny must be applied to all development environments.
|
|
This is not a cyber control for the spacecraft, but these controls would apply to ground system, contractor networks, etc. where design sensitive information would reside. NIST 800-171 is insufficient to properly protect this information from exposure, exfiltration, etc. See threat ID SV-SP-1, SV-SP-3, and SV-SP-4 for information on secure SW and supply chain protection. Should require contractors to be CMMC 2.0 Level 3 certified (https://www.acq.osd.mil/cmmc/about-us.html). The Program shall ensure [Program defined] security requirements/configurations are placed on the development environments to prevent the compromise of source code from supply chain or information leakage perspective. {SV-SP-10} {SA-15}
|
|
|
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}
|
|