MSCS logo
MSCS Console
Minesweeping Supply Chain Security
01 · Questionnaire

Questionnaire

Answer per control. Each answer feeds the evaluation and the traceability chain Actor → Vector → Component → Effect → Audit.

Filter by layerAll layersL1Mission Control, Navigation & Fail-StateL2Cyber-Physical Mission FunctionL3Software, Firmware, Update & SupplierL4Monitoring, CTI & ResponseL5Procurement Enforceability
C-1.1 · L1
Critical

GNSS spoofing resilience

Does the platform detect and reject spoofed GNSS signals and fall back to INS / alternative navigation?

Evidence required:Test report from spoofing range, INS holdover budget, alt-nav switchover logs.
Why it matters ▾

GNSS receivers can be tricked by counterfeit satellite signals broadcast from nearby transmitters, causing the platform to believe it is in a different place or time. A resilient design detects anomalies (signal strength, RAIM, multi-constellation cross-check) and falls back to inertial navigation (INS) or alternative sources without aborting the mission silently.

C-1.2 · L1
Critical

C2/OCS link authentication

Are control links mutually authenticated with replay protection and key rotation?

Evidence required:Crypto design doc, key management policy, pen-test results.
Why it matters ▾

The command-and-control link is the most direct path to take over a USV. Mutual authentication (both sides prove identity), replay protection (recorded packets cannot be reused), and scheduled key rotation prevent hijack even if an attacker records traffic for later attack.

C-1.3 · L1
High

Safe fail-state on loss of comms

Does the USV enter a defined, predictable fail-state when C2 is lost?

Evidence required:Fail-state matrix, HIL test, mission rehearsal logs.
Why it matters ▾

When the C2 link drops, the USV must enter a predictable, pre-rehearsed state — e.g. hold position, return to recovery point, or surface and beacon — rather than continue the last command or behave unpredictably. The matrix should cover every fail trigger and be verified on hardware-in-the-loop.

C-1.4 · L1
High

Time synchronisation integrity

Is time sync hardened against GNSS-borne attacks (holdover, monitored drift)?

Evidence required:Oscillator spec, drift logs, alarm thresholds.
Why it matters ▾

Many subsystems (crypto, logging, sensor fusion) depend on accurate time. GNSS-borne time attacks can desync subsystems and break replay protection or correlation. Holdover oscillators, drift monitoring and alarms ensure the platform can detect and tolerate time tampering.

C-1.5 · L1
High

Alternative navigation availability

Are alternative navigation sources (INS, terrain/bathymetric, celestial, visual) available and rehearsed for GNSS-denied operation?

Evidence required:Alt-nav design doc, rehearsal logs, accuracy budget.
Why it matters ▾

If GNSS is denied or spoofed, the mission must continue safely. Alternative navigation (INS holdover, bathymetric matching, celestial, visual landmarks) must be designed in, sized for realistic mission length, and rehearsed by operators — not added as an afterthought.

C-1.6 · L1
Critical

Secure boot and root of trust

Do mission-critical compute nodes enforce hardware-anchored secure boot with measured boot logs?

Evidence required:TPM/SE attestation logs, boot policy, key custody.
Why it matters ▾

Secure boot anchored in hardware (TPM, secure element) ensures that only signed firmware/software runs from the very first instruction. Measured boot logs allow detection of tampering after the fact. Without this, an attacker with brief physical access can persist below the OS.

C-1.7 · L1
High

Controlled degradation policy

Is there a documented controlled-degradation policy covering nav loss, comms loss and partial sensor failure?

Evidence required:Degradation matrix, FMEA, mission rehearsal evidence.
Why it matters ▾

Real missions degrade gradually — one sensor fails, comms drop, a node reboots. A documented degradation policy defines what capabilities remain, what is suspended, and when human intervention is required, so the platform behaves predictably instead of crashing or pushing through unsafely.

C-1.8 · L1
High

Power / blackout recovery

Does the platform recover deterministically from total power loss without dropping safety interlocks?

Evidence required:Blackout test report, recovery runbook.
Why it matters ▾

A total power blackout must not leave the platform in an undefined state where safety interlocks are bypassed or actuators driven uncontrolled on restart. Recovery is deterministic, repeatable and tested, with state-of-charge accounted for.