Annex 6.5.1
Mapped SPARTA techniques (9)
Techniques referencing this article
Security-testing policies should exercise sensor-fusion sanity checks and outlier-rejection logic; the proximity-sensor deception this technique describes exploits gaps in those onboard fusion mechanisms.
Security-testing procedures (integration testing, behavioural testing across module boundaries) are the procedural mechanism that surfaces collusive component interactions before they reach production.
Security-testing policy and procedures (static analysis, fuzzing, integration testing) are the procedural mechanism that surfaces code flaws before they reach production.
Security-testing policy and procedures (static analysis, fuzzing of command parsers and table loaders, integration testing on flatsats) are the procedural mechanism that surfaces flight-software flaws before flight.
Security-testing policies (fuzzing of telecommand parsers and bus-message decoders) surface the parser fragility erroneous-input flooding exploits, before flight.
Security testing of estimation pipelines, sensor-fusion sanity checks and outlier-rejection logic surfaces fragility that fabricated sensor data exploits.
Security-testing policy and procedures (static analysis, taint analysis, behavioral testing of authentication paths) are the procedural mechanism that surfaces backdoors before they reach production.
Security-testing procedures (static analysis, taint analysis, integration-level authentication tests) surface software backdoors before they reach production.
Security-testing tools and policies are exactly what the implementing regulation requires the entity to formalize; the same policy that codifies what is tested also codifies what knowledge of testing must remain confidential.