GSHIPSEarth-first systems for humanity’s longest journey
Menu

Cybersecurity, safety & recovery · Substantive editorial draft

Trust islands and safe conduits

Partition critical services into independently survivable trust islands, constrain their conduits, and preserve local deterministic operation when identity, networks, AI, or governance fail.

Operators isolate control cabinets, use manual panels and recovery media, and coordinate a defensive cyber-physical incident exercise.
Cybersecurity, safety & recovery · Conceptual generated illustration. The scene does not expose a deployable control architecture.

Evidence boundary: Segmentation, least privilege, zero-trust access decisions, redundant control, platform recovery, and delay-tolerant communications are established ideas in present systems. Their coexistence in standards does not demonstrate that they can safely govern a closed habitat for generations. A “trust island” here is a design pattern, not a certified product or a promise that isolation prevents compromise. This lesson is civil-and-defensive. It excludes offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions. Safety-critical architectural changes require two-person review.

Plain-language summary

A ship-wide network that allows every useful system to reach every other useful system is convenient—and dangerous. One mistaken credential, compromised update, faulty time source, or damaged switch could spread failure across air, water, power, medicine, manufacturing, and records.

The alternative is not to disconnect everything. Essential services need carefully designed trust islands that can continue minimum safe operation with outside links unavailable. Safe conduits carry only declared information and commands across island boundaries, under explicit identity, direction, rate, validation, logging, and failure rules.

Segmentation buys time and limits consequences; it does not create truth. A compromised sensor can lie inside an island, an authorized person can misuse a valid role, and a bad policy can pass every technical check. Each island therefore needs independent physical limits, local observability, recovery material, and people able to operate it without a central network or AI assistant.

What makes an island?

A trust island is a bounded set of people, devices, software, data, and physical equipment that can perform a declared minimum mission without depending on continuous trust from the rest of the ship.

Candidate islands might include:

  • local atmosphere and thermal control for a pressure zone;
  • water treatment with local sampling and manual routing;
  • a power microgrid capable of black start;
  • medical records and essential treatment equipment;
  • food-production environmental control;
  • manufacturing release, metrology, and machine control;
  • navigation and vehicle control;
  • identity and civic records;
  • a recovery vault containing known-good software, configuration, keys, documentation, and tools.

These are not necessarily separate networks in a simple one-to-one mapping. Some require multiple independent sub-islands. Others may share physical plant but should not share credentials, administrative consoles, or one unreviewed update path.

For every proposed boundary, write the invariant it protects. “The atmosphere controller shall maintain local safe limits for a declared interval without central identity or analytics” is testable. “Life support is segmented” is not.

A conduit is a contract

Every island must exchange something: power requests, water quality, medical inventory, clock information, maintenance status, navigation state, software updates, or human instructions. Treat each crossing as a contract with at least these fields:

  • source and destination identities;
  • message type and schema;
  • direction of travel;
  • allowed rate, size, and timing;
  • freshness and replay rules;
  • required authorization and separation of duties;
  • physical-range and semantic validation;
  • behavior on missing, contradictory, delayed, or excess data;
  • retained audit evidence and privacy limits; and
  • a tested way to close, degrade, or reopen the path.

A network firewall can restrict addresses and ports, but it cannot decide whether a signed request for a chemically impossible nutrient concentration is safe. Application-level checks and physical interlocks must evaluate meaning. Conversely, a one-way data path may reduce remote control risk but can prevent acknowledgments, maintenance, or safe coordination. Directionality is an engineering trade, not a talisman.

Segmentation and zero trust solve different problems

NIST SP 800-207 states that network location alone should not grant implicit trust. Identity and authorization decisions should focus on the subject, device, resource, and relevant context. That principle complements physical and logical segmentation.

Segmentation limits reach and supports independent survival. Zero-trust principles constrain each requested access even when source and destination appear “inside.” A sound design uses both, but modifies terrestrial assumptions:

  • the policy engine itself can be unavailable or compromised;
  • a root identity authority cannot depend on Earth;
  • emergency access must work during network partition without becoming a permanent master key;
  • privacy and due process constrain continuous inspection;
  • old equipment may lack modern identity mechanisms;
  • secure time may be degraded or disputed; and
  • a safety controller may need deterministic response faster than a remote authorization loop.

Place basic safety below optional policy services where feasible. Hardwired limits, local control loops, and physically bounded modes should not require a ship-wide identity transaction to prevent immediate harm.

Preserve graceful degradation

Isolation is useful only if an island remains understandable and operable. A minimum-safe mode should specify:

  • which functions continue;
  • which conveniences stop;
  • how long local power, storage, consumables, and staffing last;
  • how local measurements are checked;
  • which commands remain possible;
  • how residents receive truthful status;
  • what evidence is preserved; and
  • which conditions demand evacuation, assistance, or carefully controlled reconnection.

NIST SP 800-160 describes diversity, redundancy, segmentation, substantiated integrity, and predefined safe states as cyber-resiliency techniques or approaches. On a ship, diversity should not mean arbitrary complexity. Two controllers that use different code but share the same sensor design, compiler, specification error, or power bus may still fail together. Independence must be demonstrated across the relevant cause.

Manual fallback also needs precision. A handwheel is not a fallback if nobody can reach it in protective equipment, interpret its position, or sustain the required workload. A paper checklist is not sufficient if it assumes unavailable instrumentation. Local drills should measure time, staffing, error rates, and physiological burden.

Recovery vaults and roots of trust

An island needs a path from “we no longer trust the running system” to “we can establish a bounded trusted state.” NIST SP 800-193 frames platform resiliency as protection, detection, and recovery for firmware and critical data. A ship-scale recovery vault might hold:

  • immutable or tightly controlled boot material;
  • multiple verified versions of firmware, operating systems, compilers, and configuration;
  • source code and reproducible build instructions where practicable;
  • cryptographic inventories and migration procedures;
  • calibration references and equipment;
  • offline documentation readable without a proprietary service;
  • spare controllers and interface adapters;
  • signed incident and change records; and
  • exercises showing that ordinary mixed teams can use the contents.

“Air-gapped” is not synonymous with trustworthy. Media ages, keys are lost, readers become obsolete, insiders gain access, and restored code can be incompatible with changed hardware. Vaults require periodic read tests, controlled refresh, cross-generation training, and recovery rehearsals. Multiple vaults should not silently share one administrative or manufacturing failure mode.

Communications under delay and partition

Inter-island and inter-vehicle communications may face disruption, low bandwidth, and long delay. The IETF Bundle Protocol defines store-and-forward delivery across intermittently connected networks, while Bundle Protocol Security defines integrity and confidentiality services for that environment. These are relevant building blocks, not proof of a safe ship architecture.

BPSec does not define key establishment, exchange, revocation, or a complete security policy, and it does not protect an implementation already compromised through shared software or hardware. Each trust island therefore needs explicit key-custody succession, algorithm migration, policy ownership, implementation assurance, and recovery tests. RFC 9173 supplies default security contexts for interoperability; it is not a turnkey key-governance system.

CCSDS 350.0-G-3 describes security concepts and implementation options for CCSDS mission protocols, primarily across space-ground links. Its own scope states that it is an informational guide rather than a Recommended Standard and that detailed security analysis and risk assessment are outside its boundary. An abstract-only NASA CryptoLib conference record says the actively developed project aims at CCSDS Space Data Link Security compliance and reports selected frame cryptography functions. That public description does not establish conformance, secure implementation, deployment, flight qualification, key governance, or multigenerational maintainability.

Queued data raises questions that continuous terrestrial services often hide. When does an old command expire? Which observation is authoritative after clocks diverge? Can a revoked identity’s delayed message still arrive? How are duplicates handled? Which emergency message displaces routine traffic? The conduit contract must make these rules explicit and test them during partition.

The role of LLMs

An offline LLM could summarize island status, search controlled manuals, translate a conduit alarm into operator language, or compare the current configuration with an approved baseline. It should not be a conduit’s policy authority or a safety actuator.

Model and retrieval data can be poisoned. A model can confabulate a nonexistent bypass, omit a dependency, or make an unsafe reconnection sound routine. Operators may defer to it during fatigue. Controls should require exact citations to local controlled records, label uncertainty, log model and retrieval versions, and route every proposed high-consequence action to deterministic checks and two qualified people. A model must not approve its own update, change its evidence store, revoke identities, or bridge islands. Each drill should include an AI-off phase and occasional deliberately misleading advisory output.

Design and test sequence

For each island:

  1. Declare the essential function and minimum-safe envelope.
  2. Inventory dependencies and common-mode failures.
  3. Define conduits as explicit contracts.
  4. Establish local control and physical safety limits.
  5. Define identity, emergency authority, expiry, and appeal.
  6. Prepare recovery material and readable procedures.
  7. Isolate the island under realistic load.
  8. Introduce contradictory sensors, unavailable specialists, damaged links, stale messages, and a suspect update.
  9. Restore from known-good material.
  10. Reconnect through staged observation and renewed attestation.

Passing once is not enough. Tests must cover changing crews, replaced hardware, old and new cryptography, different social conditions, and loss of central services. The result should be measured in safe service delivered and recovery evidence—not the number of security products installed.

Evidence ledger

  • L11-02-A — Critical services benefit from boundaries that preserve minimum local operation during network or trust failure. Basis: normative synthesis from cyber-resiliency and OT guidance. Readiness: operational in bounded systems; major scale-up for a closed habitat. Confidence: supported.
  • L11-02-B — Segmentation does not replace per-request identity, authorization, semantic validation, or physical limits. Basis: normative synthesis from NIST zero-trust and OT guidance. Readiness: operational as design practice. Confidence: strong.
  • L11-02-C — Platform protection, detection, and recovery mechanisms exist, but century-maintained recovery vaults do not. Basis: observed. Readiness: operational for current platforms; early research for multigenerational local recovery. Confidence: strong.
  • L11-02-D — Delay-tolerant networking and bundle-layer security are standardized for disrupted communications. Basis: demonstrated and standardized. Readiness: operational in bounded uses; integration remains unproven. Confidence: strong.
  • L11-02-E — An island must be tested with central identity, communications, specialists, and AI unavailable. Basis: normative. Readiness: proposed for generation-ship assurance. Confidence: supported.
  • L11-02-F — Disconnected trust fabrics, update airlocks, recovery vaults, and cyber ranges have Earthside relevance for remote and critical infrastructure. Basis: proposed extrapolation. Readiness: early research to operational by component. Confidence: tentative for net benefit until representative trials.

Linked corpus claims: claim-12-01, claim-12-02, claim-12-03, claim-12-05, claim-12-08, and claim-12-10. See the claim registry for each record's current evidence grade and independent-review state.

Assumptions and limits

  • “Island” describes a survivability boundary, not a claim of complete isolation.
  • No topology, vendor, protocol suite, population, or required outage duration is prescribed.
  • Terrestrial zero-trust guidance assumes institutions and infrastructure that may not be available onboard.
  • Manual operation is counted only when access, measurement, staffing, duration, and training are demonstrated.
  • Cryptographic checks do not establish physical truth or legitimate policy.
  • LLMs remain offline-capable, evidence-linked, non-authoritative, logged, and physically unable to bridge trust zones or actuate safety systems.
  • No offensive technique or weapon integration is in scope.

What would change this conclusion?

Confidence would rise after repeated whole-system exercises in which independently instrumented zones maintain minimum safe service while central identity, networking, vendor support, and AI are absent; then recover and reconnect without hidden shared-state corruption or rights violations. If isolation predictably causes unsafe workload, loss of medical or civic access, unrecoverable trust, or larger physical hazards, the proposed boundaries must change. Inability to rebuild and rejoin a compromised zone is a wait/do-not-launch result.

Sources and locators

Editorial record

  • Prepared by: GShips Project
  • Last edited: 2026-07-26
  • Status: Substantive editorial draft
  • Independent domain review: Pending; high-consequence cyber, safety, identity, and dual-use claims require explicit two-person review before publication
  • Required review: cybersecurity architecture, operational technology, safety engineering, networks, identity, human factors, governance, and AI/autonomy
  • Reviewer: No independent reviewer assigned
  • Conflicts: Maintainer intends to explore a commercial venture based on some GShips work; no entity, funding, customer, sponsor, or partner relationship currently exists
  • Relationship boundary: Independent educational synthesis; citations do not imply affiliation, endorsement, partnership, or adoption by NASA, NIST, IETF, or any named organization
  • Scope boundary: Civil and defensive resilience only; offensive intrusion, autonomous weapons, weapon integration, and actionable exploitation instructions are excluded
  • Corrections: Suggest a correction

Substantive editorial draft; cited calculations have not received independent domain review · Last edited 2026-07-26 · Suggest a correction

Accountability record

How to inspect this page

Scope: Academy lesson lesson-11-02

Page citations and accountability links

  • claim-12-01
    Linked stable claim record with claim-specific citations and locators · internal accountability record
  • claim-12-02
    Linked stable claim record with claim-specific citations and locators · internal accountability record
  • claim-12-03
    Linked stable claim record with claim-specific citations and locators · internal accountability record
  • claim-12-05
    Linked stable claim record with claim-specific citations and locators · internal accountability record
  • claim-12-08
    Linked stable claim record with claim-specific citations and locators · internal accountability record
  • claim-12-10
    Linked stable claim record with claim-specific citations and locators · internal accountability record

Assumptions and limits

  • The lesson's explicit Assumptions and limits section governs its scope.
  • Linked claim records remain independently unreviewed unless their own review record says otherwise.

What would change this page?

The lesson's explicit What would change this conclusion section lists the evidence, demonstrations, standards, and counterexamples that would trigger revision.

People, review, and conflicts

Prepared by
GShips Project
Editorial status
substantive-editorial-draft
Editorial reviewer
GShips Project editorial synthesis
Last editorial review
No editorial-review date recorded
Independent review
pending
Independent reviewer
No independent reviewer assigned
Last independent review
No independent-review date exists
Last content edit
2026-07-26

Declared conflicts

  • The maintainer intends to explore a commercial venture based on some GShips work. No entity, outside funding, customer, sponsor, or indexed-organization relationship currently exists.

Suggest a correction to this page