01 · Questionnaire

Questionnaire

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

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-2.1 · L2
High

Sensor data integrity

Are sonar / acoustic / EM sensor outputs cryptographically bound to their source device?

Evidence required:Device attestation report, signed sensor frames.
Why it matters

Sweep results and contact reports drive operational decisions; a forged sonar frame could falsely declare an area clear. Cryptographically binding sensor frames to the originating device (signed at the sensor, verified at the consumer) prevents in-line tampering.

C-2.2 · L2
Critical

Influence sweep payload command path

Is the magnetic/acoustic generator command path isolated from general IT networks?

Evidence required:Network segmentation diagram, firewall rules, traffic capture.
Why it matters

Influence sweep generators output high-power magnetic/acoustic fields. If their command path is reachable from general IT, a compromised laptop could trigger them at the wrong place or time. Strict network segmentation and one-way data diodes where possible are required.

C-2.3 · L2
Medium

JANUS acoustic channel hardening

Are acoustic comms authenticated, rate-limited, and monitored for injection?

Evidence required:Acoustic protocol spec, anomaly detection logs.
Why it matters

Underwater acoustic channels (incl. NATO JANUS) are inherently broadcast, low-bandwidth and prone to injection. Authentication, rate-limiting and anomaly monitoring prevent an attacker on a small boat from issuing commands or replaying captured frames.

C-2.4 · L2
Medium

LARS / handover safety interlocks

Are launch/recovery and manned↔unmanned handover protected by physical and logical interlocks?

Evidence required:Interlock design, FMEA, operator SOP.
Why it matters

Launch-and-recovery and the manned↔unmanned handover are the moments where a wrong command can injure crew or damage the platform. Physical interlocks (mechanical) and logical interlocks (software state machine) together must make unsafe sequences impossible, not just discouraged.

C-3.1 · L3
High

SBOM completeness

Is a complete SBOM available for every shipped software & firmware artefact?

Evidence required:CycloneDX / SPDX SBOMs per release.
Why it matters

A Software Bill of Materials lists every open-source and third-party component (and version) inside a build. Without it you cannot answer 'are we affected by CVE-X?' in hours. SBOMs must cover firmware and embedded artefacts, not just server software.

C-3.2 · L3
Critical

Signed update chain

Are all firmware and software updates signed, with on-device signature verification?

Evidence required:Code-signing policy, secure boot logs.
Why it matters

Every firmware/software update must be cryptographically signed by a controlled key, and the device must verify the signature before accepting it. This blocks the classic 'malicious update' supply chain attack — the highest-impact path into deployed equipment.

C-3.3 · L3
High

FPGA bitstream provenance

Is bitstream origin verified and locked against unauthorised reconfiguration?

Evidence required:Bitstream signature, lockbit settings, vendor attestation.
Why it matters

FPGAs are reconfigured from a bitstream that defines their hardware behavior. Unverified bitstreams can implement hidden backdoors invisible to software analysis. Origin verification, encrypted bitstreams and lockbit settings make unauthorized reconfiguration practically impossible.

C-3.4 · L3
Medium

Toolchain integrity

Is the build toolchain reproducible and integrity-verified across releases?

Evidence required:Reproducible build report, hash log.
Why it matters

If the build toolchain (compiler, linker, signing tools) is tampered with, every binary it produces is suspect — the classic Ken Thompson attack. Reproducible builds let independent parties verify that source code maps deterministically to the released binary.

C-3.5 · L3
High

AI/ML model provenance

Are ATR / autonomy models tracked with training data lineage and version control?

Evidence required:Model card, dataset hash, training pipeline log.
Why it matters

AI/ML models (automatic target recognition, autonomy) inherit risks from their training data and pipeline. Tracking model versions, dataset hashes and training environment lets you reproduce a model, investigate misbehavior and respond to data-poisoning disclosures.

C-4.1 · L4
Medium

Telemetry to SOC

Does the platform stream signed telemetry to a SOC capable of OT analysis?

Evidence required:Data flow diagram, SOC runbook.
Why it matters

Without telemetry there is no monitoring. The SOC must receive signed (tamper-evident) operational and security telemetry, and must be staffed and tooled for OT analysis — IT-only SOCs miss protocol-level and physical-process anomalies entirely.

C-4.2 · L4
Medium

Cyber Threat Intelligence feed

Is maritime-specific CTI integrated into detection rules and review cadence?

Evidence required:CTI provider contract, rule update log.
Why it matters

Generic IT threat intelligence misses maritime-specific actors, malware families and TTPs. Maritime-focused CTI fed into detection rules at a defined cadence keeps detections relevant against the actual threat environment.

C-4.3 · L4
High

Cyber incident as mission event

Are cyber compromise events declared and handled as mission-assurance events?

Evidence required:Incident playbook, exercise after-action report.
Why it matters

A cyber compromise is not only an IT incident; it is a mission-assurance event that can affect whether the platform can complete its task safely. The incident playbook must include mission-side decisions (continue / abort / hand back) alongside technical containment.

C-5.1 · L5
Critical

Right to audit

Do contracts grant the buyer enforceable right to audit suppliers and sub-suppliers?

Evidence required:Contract clauses, audit schedule.
Why it matters

Without an enforceable right-to-audit clause that flows down to sub-suppliers, security claims are unverifiable. The clause must allow on-site visits, document inspection and follow-up audits, not just self-attestations.

C-5.2 · L5
High

Evidence delivery obligation

Are vendors contractually required to deliver SBOMs, test reports and attestations?

Evidence required:Evidence register, delivery acceptance records.
Why it matters

If suppliers are not contractually required to deliver SBOMs, test reports and attestations at defined milestones, you will not receive them. The evidence register lists exactly what is due, by when, and the acceptance criteria.

C-5.3 · L5
High

Sovereignty & substitution plan

Is there a substitution / second-source plan for components from high-risk jurisdictions?

Evidence required:Component origin matrix, substitution roadmap.
Why it matters

If a critical component comes from a jurisdiction that becomes hostile (export ban, sanction, sabotage risk), the platform is grounded unless a substitution plan exists. The plan names alternatives, qualification effort and lead-time per component.

C-5.4 · L5
High

Right to patch & re-flash

Does the buyer retain technical and legal rights to patch firmware independently?

Evidence required:Escrow agreement, signing key custody plan.
Why it matters

If only the original vendor can sign firmware, and that vendor disappears or refuses to patch a vulnerability, the buyer is stuck. Source escrow plus custody of signing keys (or a co-signing arrangement) preserves the buyer's ability to patch.

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.

C-2.5 · L2
High

Mechanical sweep equipment control isolation

Are mechanical sweep actuators driven via an isolated control path with independent emergency stop?

Evidence required:Wiring diagram, E-stop test, segmentation proof.
Why it matters

Even mechanical sweep equipment (cable cutters, paravanes) is now electrically actuated. A dedicated control path with an independent emergency-stop that physically breaks power ensures the equipment can be stopped even if the main control computer is compromised.

C-2.6 · L2
Critical

Mine setting / target simulation safeguards

Are mine-setting, target-simulation and mine-jamming modes protected by signed mission profiles and operator dual-control?

Evidence required:Mission profile signature, dual-control SOP.
Why it matters

Mine-setting, target-simulation and mine-jamming are operations with strategic consequences if misused. Signed mission profiles ensure only authorized parameter sets run, and dual-operator approval prevents a single rogue or coerced operator from issuing them.

C-2.7 · L2
Medium

Post-mission data integrity

Is collected mission data (sweep tracks, contacts, sensor logs) sealed and chain-of-custody preserved on return?

Evidence required:Hash manifest, transfer log, custody form.
Why it matters

Mission data (sweep tracks, sonar contacts, sensor logs) is evidence — both for operational debrief and for any later forensic or legal review. Sealing with hashes on return and maintaining chain-of-custody prevents undetected modification or accusations of tampering.

C-2.8 · L2
Medium

Degaussing / signature management control

Is the degaussing / magnetic signature subsystem isolated from external networks and tamper-monitored?

Evidence required:Isolation diagram, tamper alarm log.
Why it matters

Degaussing and magnetic-signature management subsystems both influence the platform's own detectability and are attractive sabotage targets. Network isolation plus tamper sensors ensure changes are intentional and detected.

C-3.6 · L3
High

Tier-2/3 sub-supplier disclosure

Are Tier-2 and Tier-3 sub-suppliers disclosed for safety- and mission-critical components?

Evidence required:Supplier tree, country-of-origin matrix.
Why it matters

Risk is rarely at the integrator level — it is in the chip foundry, the sensor crystal supplier, the open-source library two layers deep. Disclosure of Tier-2/3 sub-suppliers for safety- and mission-critical parts lets the buyer assess country-of-origin and concentration risk.

C-3.7 · L3
High

Vulnerability management & re-validation

Is there a defined SLA for CVE triage, patching and incident-triggered re-validation of firmware?

Evidence required:VM policy, patch SLA, re-validation records.
Why it matters

New vulnerabilities are disclosed daily. A defined SLA for triage (is this CVE applicable?), patching, and re-validation (does the patched firmware still meet safety requirements?) prevents both 'unpatched for years' and 'rushed patch breaks the platform' failure modes.

C-3.8 · L3
High

Build & engineering toolchain isolation

Are build servers, signing infrastructure and engineering workstations isolated from general IT and internet?

Evidence required:Network diagram, access policy, audit log.
Why it matters

Build infrastructure and signing keys are the crown jewels. If a build server is on the corporate intranet with email access, a phishing email can compromise every product the company ships. Isolation, MFA, and audit logging are non-negotiable.

C-3.9 · L3
High

AI/ML adversarial robustness

Are ATR / autonomy models tested against adversarial inputs, sensor evasion and data poisoning?

Evidence required:Adversarial test suite, red-team report.
Why it matters

ATR and autonomy models can be fooled by inputs crafted to evade detection (adversarial patches, acoustic shapes) or by long-term data-poisoning of public training sets. Red-team testing against these attack classes must happen before deployment, not after an incident.

C-3.10 · L3
Medium

Payload interface trust

Are third-party payload interfaces (data + power) gated by an authenticated, schema-validated bridge?

Evidence required:Interface spec, schema validator, gateway logs.
Why it matters

Third-party payloads (additional sensors, communication modules) plug into the platform. Without an authenticated, schema-validated bridge, a malicious or buggy payload can inject commands, exfiltrate data, or cause faults in the host platform.

C-4.4 · L4
High

OT-aware detection rules

Do detection rules cover OT-specific anomalies (protocol misuse, set-point drift, unexpected mode change)?

Evidence required:Rule catalogue, tuning log, false-positive rate.
Why it matters

OT anomalies look different from IT anomalies — a valid-looking command at the wrong time, a slow set-point drift, an unexpected mode change. Detection rules must encode operator and process knowledge, not just signature matching.

C-4.5 · L4
Medium

Operator alerting and response workflow

Is there a documented operator alerting workflow with defined escalation, acknowledgement and mission-abort criteria?

Evidence required:Workflow diagram, exercise log, abort criteria.
Why it matters

An alert with no defined escalation path or abort criteria is noise. Operators need a clear workflow: who acknowledges, who escalates, at what threshold the mission is aborted, and how that decision is recorded.

C-4.6 · L4
Medium

Detection coverage exercise cadence

Are purple-team / detection-coverage exercises run at least annually against maritime scenarios?

Evidence required:Exercise schedule, after-action reports.
Why it matters

Detections that have never been tested against a realistic attacker are assumptions. Annual purple-team or detection-coverage exercises against maritime scenarios are the only way to know whether the SOC actually sees what it claims to see.

C-5.5 · L5
High

Flow-down to sub-suppliers

Are security clauses contractually flowed down to all relevant Tier-2/3 sub-suppliers?

Evidence required:Flow-down clause, sub-supplier acknowledgements.
Why it matters

Security clauses written between the buyer and Tier-1 do nothing if Tier-1's contracts with Tier-2/3 are silent. Mandatory flow-down with sub-supplier acknowledgements is the only way to extend the security regime to the actual risk locations.

C-5.6 · L5
High

Source code & key escrow

Is critical source code, build toolchain and signing key material held in escrow with defined release triggers?

Evidence required:Escrow agreement, release-trigger list.
Why it matters

Source code escrow without the build toolchain and signing keys is often useless — you cannot reproduce the binary the device accepts. Escrow must cover all three, with documented release triggers (vendor bankruptcy, refusal to patch, etc.).

C-5.7 · L5
High

Incident disclosure obligation

Are suppliers contractually obliged to disclose security incidents and vulnerabilities within a defined window?

Evidence required:Disclosure clause, notification log.
Why it matters

Suppliers learn about incidents and vulnerabilities affecting their products before customers do. A contractual disclosure window (e.g. 72 hours for incidents, defined CVE disclosure rules) ensures the buyer can act before exploitation spreads.

C-5.8 · L5
Medium

End-of-life and component obsolescence

Is there a contractual EOL / obsolescence plan including last-time-buy, re-design and security-patch tail?

Evidence required:EOL plan, obsolescence register.
Why it matters

Electronics have shorter lifecycles than platforms. Without a contractual EOL plan (last-time-buy notice, re-design support, security-patch tail beyond active production), the platform becomes unmaintainable and insecure mid-life.