BSFG Security Model

Overview

Industrial environments require strict security controls due to network segmentation, regulatory requirements, and safety risks. BSFG deployments must enforce:

• Zone isolation: Each trust boundary (Enterprise, Plant, IDMZ) remains independent
• Authenticated communication: Only authorized BSFG peers can exchange facts
• Tamper-resistant transport: Data cannot be modified in transit
• Immutable history: Facts remain authoritative and audit-compliant
• Artifact confidentiality: Binaries stored in zone-local stores with access control

This document explains how BSFG achieves these guarantees architecturally.

Core Security Principles

Principle 1: Zones Remain Isolated

Each zone (Enterprise IT, Plant OT, IDMZ) is an independent trust domain. Zones do not share durable infrastructure, databases, or storage. Each zone owns its facts, artifacts, and operational state.

Principle 2: Boundary Infrastructure is Stateless

The network boundary (firewalls, routers, VPN terminators) contains no durable middleware. No Kafka, no PostgreSQL, no shared message broker. Only connectivity infrastructure and BSFG RPC endpoints are exposed across zone boundaries. See ADR-0001.

Principle 3: All Communication is Authenticated

Every cross-zone RPC call is authenticated via mutual TLS (mTLS). BSFG nodes present certificates identifying their zone. Peer zones verify certificate identity before accepting connections.

Principle 4: Data is Tamper-Resistant

Facts are immutable once appended. Artifacts are immutable once referenced. Transport uses authenticated encryption (TLS 1.3+). Message integrity is enforced via idempotent append semantics.

Principle 5: Audit Trail is Authoritative

The append-only fact log is the source of truth. There is no mutable state at the boundary. All cross-zone synchronization is explicit and traceable through the fact history.

Trust Boundaries

BSFG deployments define explicit trust boundaries — zones that operate independently and require authentication to communicate.

flowchart TD
  subgraph ENT["Enterprise IT Zone"]
    ENT_APPS["ERP, Analytics, Cloud APIs"]
    ENT_NODE["BSFG Node (enterprise-bsfg)
JetStream + Object Storage"]
    ENT_APPS --> ENT_NODE
  end

  subgraph IDMZ["IDMZ (optional)"]
    IDMZ_NODE["BSFG Node (idmz-bsfg)
(connectivity only)"]
  end

  subgraph OT["Plant OT Zone"]
    OT_APPS["MES, PLC, Historians"]
    OT_NODE["BSFG Node (plant-a-bsfg)
JetStream + Object Storage"]
    OT_APPS --> OT_NODE
  end

  ENT_NODE <-->|"mTLS"| IDMZ_NODE
  IDMZ_NODE <-->|"mTLS"| OT_NODE

Zone Independence

Each zone operates independently:

• Each zone has its own JetStream domain (no shared streams across zones)
• Each zone has its own object storage (no shared buckets)
• Each zone has its own NATS accounts (scoped, not globally shared)
• Each zone operates autonomously when boundaries are unreachable (network partition tolerance)

Cross-Zone Communication

Communication between zones is explicit:

• Enterprise BSFG initiates or receives RPC calls from Plant BSFG
• All calls use mTLS with zone certificate authentication
• Firewall rules explicitly permit zone-to-zone ports
• No implicit data sharing or automatic replication

Authentication: Mutual TLS (mTLS)

All BSFG nodes use mutual TLS (mTLS) for authentication. This means:

• BSFG node presents a certificate to peers (client auth)
• BSFG node verifies peer certificates (server auth)
• Certificate CN (Common Name) identifies the zone
• Peer zones verify CN matches expected identity

Certificate Structure

Authentication Flow

sequenceDiagram
  participant Plant as Plant A BSFG
  participant Ent as Enterprise BSFG

  Plant->>Ent: 1. TLS ClientHello + cert
  Note right of Ent: verify cert CN = plant-a-bsfg
  Ent-->>Plant: 2. TLS ServerHello + cert
  Note left of Plant: verify cert CN = enterprise-bsfg
  Plant->>Ent: 3. Encrypted connection established
  Plant->>Ent: AppendFact / FetchFacts
  Ent-->>Plant: RPC responses

Certificate Requirements

• Key Usage: Both TLS Server Auth and TLS Client Auth
• Subject Alternative Name (SAN): FQDN and/or IP address of BSFG node
• Validity: 1 year recommended, with renewal 30 days before expiry
• CA Chain: Must be complete and trusted by all peers
• Rotation: Expired certificates must be rotated without service interruption

Authorization: Zone-Based Access Control

Authorization in BSFG is zone-level, not per-message. The security decision is: "Does this authenticated zone have permission to perform this RPC call?"

Authorization Policy

A typical authorization policy defines:

Authorization Enforcement

Authorization is enforced via:

• Firewall rules: Only permitted source/destination IP pairs + ports
• Certificate validation: CN must match expected zone identity
• BSFG peer policy: Explicit per-zone connection rules (allowed RPC operations)

Transport Security: mTLS + Connect RPC

All BSFG cross-zone communication occurs over authenticated, encrypted channels:

• Protocol: Connect RPC over HTTP/2
• Encryption: TLS 1.3 minimum (negotiated during handshake)
• Authentication: Mutual TLS with certificate verification
• Integrity: AEAD cipher ensures messages cannot be tampered with

What Remains Zone-Local (Never Exposed)

The following are never exposed across zone boundaries:

Data Integrity

BSFG prevents data corruption through multiple mechanisms:

Idempotent Append

Producers append facts with a stable message_id. The BSFG boundary enforces idempotent semantics:

• If the same message_id is appended twice, only one fact is stored
• Retries with identical payloads are safe and result in no duplication
• This prevents data corruption from producer crashes and retry scenarios

Stable Message ID

Producers derive message_id from business data, not random values:

• Good: SHA256(order_id + timestamp) — stable, deterministic
• Bad: random() or sequence counter — loses idempotency on restart

Canonical JSON

Fact objects are serialized in canonical JSON format (deterministic, field-ordered). This ensures:

• Same object always hashes to same value (integrity check)
• No whitespace or field reordering changes the meaning
• Consumers can verify object authenticity via digest

Immutable Facts and Artifacts

Once appended, facts are immutable:

• Facts cannot be modified or deleted
• Corrections are new facts, not modifications
• Audit trail is complete and tamper-evident

Once referenced, artifacts are immutable:

• Producer uploads artifact, then appends fact referencing it
• Artifact digest is recorded in the fact (content hash)
• Any modification to artifact breaks the digest and is detected

Artifact Security

Binary artifacts (PDFs, batch records, test results) may contain sensitive information. Security measures:

Zone-Local Storage

All artifacts are stored in zone-local object stores:

• Enterprise artifacts stay in Enterprise S3
• Plant artifacts stay in Plant NAS or local storage
• No artifact replication across zones

Access Control

Artifact access is controlled via BSFG node authentication:

• Consumers retrieve artifacts through authenticated BSFG RPC (PutObject, GetObject)
• Direct access to object storage (S3, NAS) is restricted to BSFG node identity
• Bucket-level access control enforces per-subject-kind policies (batch-files vs. asset-files)

Immutability and Referential Integrity

Artifacts are content-addressed and immutable:

• Fact includes artifact digest (SHA256)
• If artifact is modified, digest no longer matches (detectable corruption)
• Producer cannot overwrite artifact; new version requires new fact with new digest

Threat Model and Mitigations

This section addresses common threats and how BSFG mitigates them.

Threat: Man-in-the-Middle (MITM) Attack

Scenario: An attacker intercepts RPC traffic between enterprise-bsfg and plant-a-bsfg, modifying fact data in transit.

Mitigation: All cross-zone traffic uses mTLS with authenticated encryption (TLS 1.3 AEAD). Attacker cannot decrypt, forge certificates, or modify ciphertext without detection.

Threat: Unauthorized Zone Access

Scenario: A compromised plant tries to access another plant's BSFG node (plant-a-bsfg attempts to pull from plant-b-bsfg).

Mitigation: Firewall rules explicitly forbid plant-to-plant connections. Even if plant-a-bsfg has a valid certificate, firewall drops the packet. Certificate validation is necessary but not sufficient; network topology enforces the policy.

Threat: Fact Tampering

Scenario: An attacker modifies a fact in the JetStream store (e.g., changes order quantity).

Mitigation: Facts are append-only. Once appended, they cannot be modified or deleted. JetStream enforces immutability at the storage layer. Audit logs record all append operations and cannot be altered retroactively.

Threat: Duplicate Fact Injection

Scenario: An attacker or buggy producer causes the same fact to be appended multiple times, creating duplicate orders or measurements.

Mitigation: BSFG enforces idempotent append: facts with the same message_id are deduplicated. Producers derive message_id from business data (order ID, timestamp), making duplicates impossible if the producer follows the contract.

Threat: Artifact Substitution

Scenario: An attacker replaces a batch record PDF with a different file, and a fact references the old digest.

Mitigation: Once a fact references an artifact by digest, that artifact becomes immutable. If the artifact is modified or replaced, the digest no longer matches. Consumers verify digest; mismatch signals tampering or data loss.

Threat: Unauthorized Cross-Zone Replication

Scenario: A rogue process in Plant A attempts to replicate sensitive data to Plant B without authorization.

Mitigation: Facts are pulled by the receiving zone, not pushed by the sending zone. Plant B controls what it fetches. Additionally, firewall rules prevent direct plant-to-plant connections; cross-zone traffic must go through the authorized boundary (e.g., via IDMZ or Enterprise).

Operational Hardening

Beyond architectural security, operational practices strengthen the defense posture:

Certificate Rotation

• Rotate BSFG node certificates annually or when compromise is suspected
• Plan rotation to avoid service interruption (rolling update across HA instances)
• Monitor certificate expiry and alert 30 days before expiration
• Immediately rotate if private key is compromised

Least-Privilege Network Rules

• Firewall rules permit only necessary source/destination pairs
• Use zone names and IPs, not wildcards (enterprise-bsfg → plant-a-bsfg:9443 only)
• Deny by default; whitelist specific connections
• Review rules quarterly and audit for stale entries

Audit Logging

• Log all RPC operations: AppendFact, FetchFacts, ConfirmReceipt, PutObject
• Log authentication events: TLS handshake success/failure, certificate validation
• Log authorization decisions: which zone accessed which operations
• Retain audit logs for compliance period (typically 3–7 years)

Anomaly Detection

• Monitor replication lag for sudden spikes (indicates network issues or attacks)
• Alert on unusual append rates (producer anomaly)
• Alert on TLS handshake failures (certificate issues or unauthorized access)
• Monitor buffer fill anomalies (consumer failures or backlog buildup)

Secure Deployment Practices

• Run BSFG nodes in isolated network segments with no unnecessary egress
• Use container security standards (read-only root filesystem, non-root user, resource limits)
• Regularly patch NATS and Go runtime for security vulnerabilities
• Perform security testing and penetration testing before production deployment

Compliance Alignment

BSFG's security model aligns with industrial compliance standards:

• ISA-95: Zone separation (Levels 1–4) with explicit boundaries
• IEC 62541-14 (OPC UA): mTLS authentication, confidentiality, integrity
• IEC 61508 (Safety): Immutable audit trail, tamper-resistant design
• NIST Cybersecurity Framework: Identify, Protect, Detect, Respond, Recover

Security Checklist

Before deployment, verify:

• ☐ All BSFG nodes have valid mTLS certificates with correct CN (zone identity)
• ☐ Certificate CA trust chain is installed on all peers
• ☐ Certificate expiry alerts are configured (30 days before expiration)
• ☐ Firewall rules explicitly define source/destination zones and ports
• ☐ No cross-zone firewall rules that bypass authorization (e.g., plant-to-plant direct connections)
• ☐ JetStream and object storage are zone-local (no cross-zone replication)
• ☐ NATS accounts are zone-scoped (no shared credentials across zones)
• ☐ Audit logging is enabled for all RPC operations
• ☐ Monitoring and alerting are configured for security events
• ☐ Least-privilege network policies are documented and approved
• ☐ Incident response procedures for certificate compromise are documented
• ☐ Security testing has been completed (penetration testing, threat modeling)

Cross-Links to Related Documentation

• Message Model — Canonical JSON and message structure
• Replay Model — Idempotent append semantics
• Artifact Handling — Immutable artifact storage and referential integrity
• Network Policy — Firewall rules and connectivity
• Identity Model — Zone identity and mTLS certificates
• Integration Contract — Producer and consumer obligations
• Architecture Map — System-level design principles