Security Posture

ABSTRACT

The Quantum Audit CLI runs entirely inside the customer's firewall, reads scheduler logs locally, generates a PDF report on the head node, and never opens an outbound connection unless the customer explicitly types a consent flag. The only artifact that crosses the trust boundary is a hashed, aggregated JSON manifest that the customer reviewed in full before upload. This document specifies the threat model, sanitization treatment, control mappings against [NIST SP 800-53], [ISO/IEC 27001], and [SOC 2 TSC 2017], and the incident-handling protocol adopted from [NIST SP 800-61].

Principles

Four invariants. Every section below is a consequence of one of these.

1. 1.1
   On-prem only. The CLI is a signed single binary or Docker image. No outbound connection is opened by default. Air-gapped environments are supported.
2. 1.2
   Customer-typed consent. Before the sanitized manifest is uploaded, the CLI prints it in full and requires the customer to type --i-have-reviewed-this. No silent transmission, ever.
3. 1.3
   Methodology hash on every artifact. The PDF report, the manifest, and every Latency Index publication carry the hash of the methodology version that produced them. Tampering breaks the seal.
4. 1.4
   Open compliance. Controls are mapped to [SOC 2 TSC 2017], [ISO/IEC 27001], [GDPR Art. 32], [HIPAA §164.312]. Mappings are reproduced in §4 and disclosed in the engagement SOW.

Threat model

2.1 Adversaries

The audit CLI defends against the following adversary classes, in order of effort required:

• A1: Curious insider. An employee of the customer who is authorized to run the CLI but not authorized to see other customers' data. Mitigated by §3 sanitization; no cross-customer data exists in the customer's manifest.
• A2: Network observer. An in-network attacker observing traffic between the customer head node and the Latency Index ingest endpoint. Mitigated by TLS 1.3 plus signed-URL upload; the payload is already sanitized at the customer's consent step.
• A3: Q-Intercept staff. Engineering staff at Q-Intercept attempting to learn customer-identifiable details from manifests. Mitigated by sanitization at the source; identifying fields never enter the ingest pipeline.
• A4: Compromised methodology. A modified CLI distributed to customers without sign-off. Mitigated by signature verification at install time plus methodology-hash provenance carried on every report page.

2.2 Trust boundary

The boundary runs through the manifest-upload step. Everything left of the boundary stays inside the customer's network. Only the sanitized manifest crosses.

   CUSTOMER INFRASTRUCTURE  (firewalled)                    │   Q-INTERCEPT
                                                            │
   ┌──────────────────────────────────────────┐             │
   │  qintercept-audit CLI                    │             │
   │                                          │             │
   │   sacct / kube-state-metrics / qstat ────┤             │
   │              │                           │             │
   │              ▼                           │             │
   │   ┌─────────────────────┐                │             │
   │   │  Workload classifier│                │             │
   │   │  (15 archetypes)    │                │             │
   │   └──────────┬──────────┘                │             │
   │              ▼                           │             │
   │   ┌─────────────────────┐                │             │
   │   │  PDF report + QSS   │ stays local    │             │
   │   └─────────────────────┘                │             │
   │              │                           │             │
   │              ▼                           │             │
   │   ┌─────────────────────┐                │             │
   │   │  manifest.json      │                │             │
   │   │  (sanitized, hashed)│                │             │
   │   └──────────┬──────────┘                │             │
   │              │                           │             │
   │  customer types: --i-have-reviewed-this  │             │
   │              │                           │ HTTPS       │  ┌────────────────┐
   │              └──────────────────────────────signed PUT─┼─►│ Latency Index  │
   │                                          │             │  │ ingest         │
   └──────────────────────────────────────────┘             │  └────────────────┘
                                                            │
   ── trust boundary ─────────────────────────────────────  │
                                                            │

2.3 Out of scope

Endpoint compromise of the customer's head node is out of scope; the CLI inherits the operating system's trust model. Side-channel attacks against the local PDF artifact are out of scope; the customer is responsible for the PDF's local storage. Quantum-cryptographic attacks against TLS are out of scope until fault-tolerant hardware credibly threatens the underlying primitives; see §5.3 for the policy on methodology revisions triggered by the threat landscape.

Sanitization

3.1 Field-level treatment

The following table is the full schema of what the CLI may include in a manifest. Anything not in this table is dropped before the customer is even shown the manifest preview.

3.2 Customer consent flow

The upload step is gated on a typed consent flag. The CLI prints the manifest in full and waits.

$ qintercept-audit submit

  Reviewing manifest before upload...
  ---
  scheduler:        slurm
  cli_version:      1.0.0
  archetype_counts:
    optimization:   12
    simulation:      4
    search:          2
    linear-algebra:  6
    ...
  cost_buckets:     [<$10K, $10K-$100K, $100K-$1M, >$1M]
  customer_hash:    <opaque>
  ---

  Type --i-have-reviewed-this to upload, or Ctrl-C to abort.

3.3 Methodology-hash provenance

Every report PDF, every manifest, and every published Latency Index edition carry the methodology hash that produced them on the page footer. A reviewer can pin a report to an exact methodology revision and audit the lineage. Methodology updates never silently revise downstream artifacts; old reports continue to cite the version that produced them.

Compliance

4.1 Mapped controls

The audit CLI distribution, the ingest endpoint, and the Latency Index publication pipeline carry the following control mappings. Full mapping spreadsheet provided with the engagement SOW.

4.2 Distribution security

The CLI is distributed as a PyInstaller binary signed with our distribution key, with SHA-256 digests published alongside every release. The Docker image is signed with cosign and pushed to a registry whose provenance attestation is verifiable against SLSA level 3.

Installation instructions verify the signature before running. A modified binary installed without verification will continue to function but will not produce reports that authenticate against the public methodology hash; the seal breaks silently and is detectable on review.

4.3 Third-party review

The audit CLI source, the sanitization layer, and the manifest schema are open to inspection under mutual NDA during engagement scoping. Independent code review by a customer-nominated firm is supported and is the only path to certifying that the deployed binary matches the published source.

Incident response

The protocol below follows the lifecycle defined in [NIST SP 800-61]: Preparation, Detection & Analysis, Containment, Eradication & Recovery, Post-incident.

5.1 Customer-side incidents

The CLI is the customer's. Incident response on the customer head node is owned by the customer. Q-Intercept is available within 24 hours of notification to assist with manifest re-validation, methodology re-pinning, and engagement re-issue at no charge if the cause is traced to the CLI distribution.

5.2 Q-Intercept-side incidents

An incident is declared when any of the following are detected: ingest endpoint compromise, methodology-key compromise, accidental disclosure of customer manifest data, or distribution-key compromise. Notification is sent to all affected customers within 72 hours per [GDPR Art. 32] and is prepared for sign-off by the technical advisor on file.

Recovery includes re-keying of the methodology signature, re-issue of affected report PDFs with a new methodology hash, and a public post-mortem published on this page within 30 calendar days.

5.3 Threat-landscape revisions

When the cryptographic primitives this document relies on become credibly threatened, the methodology version increments and a migration plan is published. The plan is reviewed by the technical advisor on file and any affected customer under active engagement receives the migrated artifact at no charge.

Publication

6.1 Versioning

This document is versioned independently of the methodology PDF. Both are hashed and signed. The version + hash + date triple is the canonical reference for any audit, response, or compliance evidence.