SV-SP-2 - Insufficient Testing

Testing only focuses on functional requirements and rarely considers end to end or abuse cases


Informational References

ID: SV-SP-2
DiD Layer: Prevention
CAPEC #:  28 | 214 | 215 | 261
NIST Rev5 Control Tag Mapping:  CA-2(2) | CA-8 | CP-4 | CP-4(5) | PM-32 | RA-5 | RA-5(2) | RA-9 | SA-3 | SA-4 | SA-4(3) | SA-11 | SA-11(1) | SA-11(2) | SA-11(5) | SA-11(7) | SA-11(8) | SA-11(9) | SA-15 | SA-15(7) | SR-11 | SR-11(3)
Lowest Threat Tier to
Create Threat Event:  
II
Notional Risk Rank Score: 19

High-Level Requirements

The Program shall establish robust procedures and technical methods to perform testing to include negative testing (i.e., abuse cases) of the spacecraft hardware and software.

Low-Level Requirements

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)}
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 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} 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)} 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}

Related SPARTA Techniques and Sub-Techniques

ID Name Description
REC-0006 Gather FSW Development Information Threat actors may obtain information regarding the flight software (FSW) development environment for the victim spacecraft. This information may include the development environment, source code, compiled binaries, testing tools, and fault management.

Related SPARTA Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
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-25 AC-3(11) AC-4(23) AC-4(25) AC-4(6) CA-3 CM-12 CM-12(1) PL-8 PL-8(1) PM-11 PM-17 SA-3 SA-3(1) SA-3(2) SA-4(12) SA-4(12) SA-5 SA-8 SA-8(19) SA-9(7) SC-16 SC-16(1) SC-8(1) SC-8(3) SI-12 SI-21 SI-23 SR-12 SR-7 D3-AI D3-AVE D3-NVA D3-CH D3-CBAN D3-CTS D3-PA D3-FAPA D3-SAOR A.8.4 A.8.11 A.8.10 A.5.14 A.8.21 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.27 A.8.28 A.5.33 A.8.10 A.5.22
CM0008 Security Testing Results As penetration testing and vulnerability scanning is a best practice, protecting the results from these tests and scans is equally important. These reports and results typically outline detailed vulnerabilities and how to exploit them. As with countermeasure CM0001, protecting sensitive information from disclosure to threat actors is imperative. AC-3(11) CA-8 CA-8(1) CA-8(1) CM-4 CP-4 IR-3 IR-3(1) IR-3(2) IR-6(2) RA-5 RA-5(11) SA-11 SA-11(3) SA-11(5) SA-4(5) SA-5 D3-AI D3-AVE A.8.4 A.8.9 A.5.29 A.5.30 A.8.8 7.5.1 7.5.2 7.5.3 A.5.37 A.8.29 A.8.30
CM0020 Threat modeling Use threat modeling, attack surface analysis, and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. Reduce attack surface where possible based on threats. CA-3 CM-4 CP-2 PL-8 PL-8(1) RA-3 SA-11 SA-11(2) SA-11(3) SA-11(6) SA-15(6) SA-15(8) SA-2 SA-3 SA-4(9) SA-8 SA-8(25) SA-8(30) D3-AI D3-AVE D3-SWI D3-HCI D3-NM D3-LLM D3-ALLM D3-PLLM D3-PLM D3-APLM D3-PPLM D3-SYSM D3-DEM D3-SVCDM D3-SYSDM A.5.14 A.8.21 A.8.9 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.8 6.1.2 8.2 9.3.2 A.8.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30
CM0022 Criticality Analysis Conduct a criticality analysis to identify mission critical functions, critical components, and data flows and reduce the vulnerability of such functions and components through secure system design. Focus supply chain protection on the most critical components/functions. Leverage other countermeasures like segmentation and least privilege to protect the critical components. CM-4 CP-2 CP-2(8) PL-7 PL-8 PL-8(1) PM-11 PM-17 PM-30 PM-30(1) PM-32 RA-3 RA-3(1) RA-9 RA-9 SA-11 SA-11(3) SA-15(3) SA-2 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(25) SA-8(3) SA-8(30) SC-32(1) SC-7(29) SR-1 SR-1 SR-2 SR-2(1) SR-3 SR-3(2) SR-3(3) SR-5(1) SR-7 D3-AVE D3-OSM D3-IDA D3-SJA D3-AI D3-DI D3-SWI D3-NNI D3-HCI D3-NM D3-PLM D3-AM D3-SYSM D3-SVCDM D3-SYSDM D3-SYSVA D3-OAM D3-ORA A.8.9 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.30 8.1 A.5.8 A.5.8 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 6.1.2 8.2 9.3.2 A.8.8 A.5.22 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.19 A.5.31 A.5.36 A.5.37 A.5.19 A.5.20 A.5.21 A.8.30 A.5.20 A.5.21 A.5.22
CM0004 Development Environment Security In order to secure the development environment, the first step is understanding all the devices and people who interact with it. Maintain an accurate inventory of all people and assets that touch the development environment. Ensure strong multi-factor authentication is used across the development environment, especially for code repositories, as threat actors may attempt to sneak malicious code into software that's being built without being detected. Use zero-trust access controls to the code repositories where possible. For example, ensure the main branches in repositories are protected from injecting malicious code. A secure development environment requires change management, privilege management, auditing and in-depth monitoring across the environment. AC-17 AC-18 AC-20(5) AC-3(11) AC-3(13) AC-3(15) CA-8 CA-8(1) CA-8(1) CM-11 CM-14 CM-2(2) CM-3(2) CM-3(7) CM-3(8) CM-4(1) CM-4(1) CM-5(6) CM-7(8) CM-7(8) CP-2(8) MA-7 PL-8 PL-8(1) PL-8(2) PM-30 PM-30(1) RA-3(1) RA-3(2) RA-5 RA-5(2) RA-9 SA-10 SA-10(4) SA-11 SA-11 SA-11(1) SA-11(2) SA-11(2) SA-11(4) SA-11(5) SA-11(5) SA-11(6) SA-11(7) SA-11(7) SA-11(7) SA-11(8) SA-15 SA-15(3) SA-15(5) SA-15(7) SA-15(8) SA-17 SA-3 SA-3 SA-3(1) SA-3(2) SA-4(12) SA-4(3) SA-4(3) SA-4(5) SA-4(5) SA-4(9) SA-8 SA-8(19) SA-8(30) SA-8(31) SA-9 SC-38 SI-2 SI-2(6) SI-7 SR-1 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-3(2) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5 SR-5(2) SR-6 SR-6(1) SR-6(1) SR-7 D3-AI D3-AVE D3-SWI D3-HCI D3-NNI D3-OAM D3-AM D3-OM D3-DI D3-MFA D3-CH D3-OTP D3-BAN D3-PA D3- FAPA D3- DQSA D3-IBCA D3-PCSV D3-PSMD A.8.4 A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.8.9 A.8.9 A.8.31 A.8.19 A.5.30 A.5.8 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.8.8 A.5.22 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 A.8.28 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.9 A.8.28 A.8.30 A.8.32 A.8.29 A.8.30 A.8.28 A.5.8 A.8.25 A.8.28 A.8.25 A.8.27 A.6.8 A.8.8 A.8.32 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.19 A.5.31 A.5.36 A.5.37 A.5.19 A.5.20 A.5.21 A.8.30 A.5.20 A.5.21 A.5.21 A.8.30 A.5.20 A.5.21 A.5.23 A.8.29 A.5.22 A.5.22
CM0011 Vulnerability Scanning Vulnerability scanning is used to identify known software vulnerabilities (excluding custom-developed software - ex: COTS and Open-Source). Utilize scanning tools to identify vulnerabilities in dependencies and outdated software (i.e., software composition analysis). 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. CM-10(1) RA-3 RA-5 RA-5(11) RA-5(3) RA-7 SA-11 SA-11(3) SA-15(7) SA-3 SA-4(5) SA-8 SA-8(30) SI-3 SI-3(10) SI-7 D3-AI D3-NM D3-AVE D3-NVA D3-PM D3-FBA D3-OSM D3-SFA D3-PA D3-PSA D3-PLA D3-PCSV D3-FA D3-DA D3-ID D3-HD D3-UA 6.1.2 8.2 9.3.2 A.8.8 A.8.8 6.1.3 8.3 10.2 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.8.7
CM0018 Dynamic Analysis 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). Testing should occur (1) on potential system elements before acceptance; (2) as a realistic simulation of known adversary tactics, techniques, procedures (TTPs), and tools; and (3) throughout the lifecycle on physical and logical systems, elements, and processes. FLATSATs as well as digital twins can be used to perform the dynamic analysis depending on the TTPs being executed. Digital twins via instruction set simulation (i.e., emulation) can provide robust environment for dynamic analysis and TTP execution. CA-8 CA-8(1) CA-8(1) CM-4(2) CP-4(5) RA-3 RA-5(11) RA-7 SA-11 SA-11(3) SA-11(5) SA-11(8) SA-11(9) SA-3 SA-8 SA-8(30) SC-2(2) SC-7(29) SI-3 SI-3(10) SI-7 SR-6(1) SR-6(1) D3-DA D3-FBA D3-PSA D3-PLA D3-PA D3-SEA D3-MBT 6.1.2 8.2 9.3.2 A.8.8 6.1.3 8.3 10.2 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.8.7
CM0019 Static Analysis Perform static source code analysis for all available source code looking for system-relevant weaknesses (see CM0016) using no less than two static code analysis tools. CM-4(2) RA-3 RA-5 RA-7 SA-11 SA-11(1) SA-11(3) SA-11(4) SA-15(7) SA-3 SA-8 SA-8(30) SI-7 D3-PM D3-FBA D3-FEMC D3-FV D3-PFV D3-SFV D3-OSM 6.1.2 8.2 9.3.2 A.8.8 A.8.8 6.1.3 8.3 10.2 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.8.28
CM0005 Ground-based Countermeasures This countermeasure is focused on the protection of terrestrial assets like ground networks and development environments/contractor networks, etc. Traditional detection technologies and capabilities would be applicable here. Utilizing resources from NIST CSF to properly secure these environments using identify, protect, detect, recover, and respond is likely warranted. Additionally, NISTIR 8401 may provide resources as well since it was developed to focus on ground-based security for space systems (https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8401.ipd.pdf). Furthermore, the MITRE ATT&CK framework provides IT focused TTPs and their mitigations https://attack.mitre.org/mitigations/enterprise/. Several recommended NIST 800-53 Rev5 controls are provided for reference when designing ground systems/networks. AC-1 AC-10 AC-11 AC-11(1) AC-12 AC-12(1) AC-14 AC-16 AC-16(6) AC-17 AC-17 AC-17(1) AC-17(10) AC-17(2) AC-17(3) AC-17(4) AC-17(6) AC-17(9) AC-18 AC-18 AC-18(1) AC-18(3) AC-18(4) AC-18(5) AC-19 AC-19(5) AC-2 AC-2 AC-2(1) AC-2(11) AC-2(12) AC-2(13) AC-2(2) AC-2(3) AC-2(4) AC-2(9) AC-20 AC-20(1) AC-20(2) AC-20(3) AC-20(5) AC-21 AC-22 AC-3 AC-3(11) AC-3(13) AC-3(15) AC-3(4) AC-4 AC-4(23) AC-4(24) AC-4(25) AC-4(26) AC-4(31) AC-4(32) AC-6 AC-6(1) AC-6(10) AC-6(2) AC-6(3) AC-6(5) AC-6(8) AC-6(9) AC-7 AC-8 AT-2(4) AT-2(4) AT-2(5) AT-2(6) AT-3 AT-3(2) AT-4 AU-10 AU-11 AU-12 AU-12(1) AU-12(3) AU-14 AU-14(1) AU-14(3) AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(1) AU-5(2) AU-5(5) AU-6 AU-6(1) AU-6(3) AU-6(4) AU-6(5) AU-6(6) AU-7 AU-7(1) AU-8 AU-9 AU-9(2) AU-9(3) AU-9(4) CA-3 CA-3 CA-3(6) CA-3(7) CA-7 CA-7(1) CA-7(6) CA-8 CA-8(1) CA-8(1) CA-9 CM-10(1) CM-11 CM-11 CM-11(2) CM-11(3) CM-12 CM-12(1) CM-14 CM-2 CM-2(2) CM-2(3) CM-2(7) CM-3 CM-3(1) CM-3(2) CM-3(4) CM-3(5) CM-3(6) CM-3(7) CM-3(7) CM-3(8) CM-4 CM-5(1) CM-5(5) CM-6 CM-6(1) CM-6(2) CM-7 CM-7(1) CM-7(2) CM-7(3) CM-7(5) CM-7(8) CM-7(8) CM-7(9) CM-8 CM-8(1) CM-8(2) CM-8(3) CM-8(4) CM-9 CP-10 CP-10(2) CP-10(4) CP-2 CP-2 CP-2(2) CP-2(5) CP-2(8) CP-3(1) CP-4(1) CP-4(2) CP-4(5) CP-8 CP-8(1) CP-8(2) CP-8(3) CP-8(4) CP-8(5) CP-9 CP-9(1) CP-9(2) CP-9(3) IA-11 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) IA-2 IA-2(1) IA-2(12) IA-2(2) IA-2(5) IA-2(6) IA-2(8) IA-3 IA-3(1) IA-4 IA-4(9) IA-5 IA-5(1) IA-5(13) IA-5(14) IA-5(2) IA-5(7) IA-5(8) IA-6 IA-7 IA-8 IR-2 IR-2(2) IR-2(3) IR-3 IR-3(1) IR-3(2) IR-3(3) IR-4 IR-4(1) IR-4(10) IR-4(11) IR-4(11) IR-4(12) IR-4(13) IR-4(14) IR-4(3) IR-4(4) IR-4(5) IR-4(6) IR-4(7) IR-4(8) IR-5 IR-5(1) IR-6 IR-6(1) IR-6(2) IR-7 IR-7(1) IR-8 MA-2 MA-3 MA-3(1) MA-3(2) MA-3(3) MA-4 MA-4(1) MA-4(3) MA-4(6) MA-4(7) MA-5(1) MA-6 MA-7 MP-2 MP-3 MP-4 MP-5 MP-6 MP-6(3) MP-7 PE-3(7) PL-10 PL-11 PL-8 PL-8(1) PL-8(2) PL-9 PL-9 PM-11 PM-16(1) PM-17 PM-30 PM-30(1) PM-31 PM-32 RA-10 RA-3(1) RA-3(2) RA-3(2) RA-3(3) RA-3(4) RA-5 RA-5(10) RA-5(11) RA-5(2) RA-5(4) RA-5(5) RA-7 RA-9 RA-9 SA-10 SA-10(1) SA-10(2) SA-10(7) SA-11 SA-11 SA-11(2) SA-11(4) SA-11(7) SA-11(9) SA-15 SA-15(3) SA-15(7) SA-17 SA-17 SA-2 SA-2 SA-22 SA-3 SA-3 SA-3(1) SA-3(2) SA-3(2) SA-4 SA-4 SA-4(1) SA-4(10) SA-4(12) SA-4(2) SA-4(3) SA-4(3) SA-4(5) SA-4(5) SA-4(7) SA-4(9) SA-4(9) SA-5 SA-8 SA-8 SA-8(14) SA-8(15) SA-8(18) SA-8(21) SA-8(22) SA-8(23) SA-8(24) SA-8(29) SA-8(9) SA-9 SA-9 SA-9(1) SA-9(2) SA-9(6) SA-9(7) SC-10 SC-12 SC-12(1) SC-12(6) SC-13 SC-15 SC-16(2) SC-16(3) SC-18(1) SC-18(2) SC-18(3) SC-18(4) SC-2 SC-2(2) SC-20 SC-21 SC-22 SC-23 SC-23(1) SC-23(3) SC-23(5) SC-24 SC-28 SC-28(1) SC-28(3) SC-3 SC-38 SC-39 SC-4 SC-45 SC-45(1) SC-45(1) SC-45(2) SC-49 SC-5 SC-5(1) SC-5(2) SC-5(3) SC-50 SC-51 SC-7 SC-7(10) SC-7(11) SC-7(12) SC-7(13) SC-7(14) SC-7(18) SC-7(21) SC-7(25) SC-7(29) SC-7(3) SC-7(4) SC-7(5) SC-7(5) SC-7(7) SC-7(8) SC-7(9) SC-8 SC-8(1) SC-8(2) SC-8(5) SI-10 SI-10(3) SI-10(6) SI-11 SI-12 SI-14(3) SI-16 SI-19(4) SI-2 SI-2(2) SI-2(3) SI-2(6) SI-21 SI-3 SI-3 SI-3(10) SI-3(10) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(12) SI-4(13) SI-4(14) SI-4(15) SI-4(16) SI-4(17) SI-4(2) SI-4(20) SI-4(22) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-5 SI-5(1) SI-6 SI-7 SI-7 SI-7(1) SI-7(17) SI-7(2) SI-7(5) SI-7(7) SI-7(8) SR-1 SR-1 SR-10 SR-11 SR-11 SR-11(1) SR-11(2) SR-11(3) SR-12 SR-2 SR-2(1) SR-3 SR-3(1) SR-3(2) SR-3(2) SR-3(3) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5 SR-5(1) SR-5(2) SR-6 SR-6(1) SR-6(1) SR-7 SR-7 SR-8 SR-9 SR-9(1) Nearly all D3FEND Techniques apply to Ground 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.15 A.5.31 A.5.36 A.5.37 A.5.16 A.5.18 A.8.2 A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.4 A.5.14 A.8.22 A.8.23 A.8.11 A.8.10 A.5.15 A.8.2 A.8.18 A.8.5 A.8.5 A.7.7 A.8.1 A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.7.9 A.8.1 A.5.14 A.7.9 A.8.20 A.6.3 A.8.15 A.8.15 A.8.6 A.5.25 A.6.8 A.8.15 A.7.4 A.8.17 A.5.33 A.8.15 A.5.28 A.8.15 A.8.15 A.8.15 A.5.14 A.8.21 9.1 9.3.2 9.3.3 A.5.36 9.2.2 A.8.9 A.8.9 8.1 9.3.3 A.8.9 A.8.32 A.8.9 A.8.9 A.8.9 A.8.9 A.8.19 A.8.19 A.5.9 A.8.9 A.5.2 A.8.9 A.8.19 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.8.6 A.5.30 A.5.30 A.5.29 A.7.11 A.5.29 A.5.33 A.8.13 A.5.29 A.5.16 A.5.16 A.5.16 A.5.17 A.8.5 A.5.16 A.6.3 A.5.25 A.5.26 A.5.27 A.8.16 A.5.5 A.6.8 7.5.1 7.5.2 7.5.3 A.5.24 A.7.10 A.7.13 A.8.10 A.8.10 A.8.16 A.8.10 A.7.13 A.5.10 A.7.7 A.7.10 A.5.13 A.5.10 A.7.7 A.7.10 A.8.10 A.5.10 A.7.9 A.7.10 A.5.10 A.7.10 A.7.14 A.8.10