Prometheus
EN DE
EN DE

Dokumentation · 05 / 09

Threat-Model — Prometheus v2

STRIDE über die vier Erfassungsmodi und die föderierte Mirror-Architektur, samt Restrisiken.

Status Pivot abgeschlossen 2026-05-26Quelle concept/threat-model.mdZielgruppe Security · Architektur · Mirror-BetreiberLesezeit ~5 Min.

STRIDE-basierte Bedrohungsanalyse für die vier Erfassungsmodi und die föderierte Mirror-Architektur. Pro Komponente werden Bedrohungen identifiziert, Mitigationen genannt und ihre Wirkung auf Restrisiko (siehe 03-risikoprofil.md) verlinkt.

1. Trust-Boundaries#

Trust-Boundaries T1, T2, T3 in der Prometheus-Federation: T1 zwischen Endnutzer-System und Public Internet, T2 zwischen Submitter und Mirror, T3 zwischen unabhängigen Mirror-Betreibern Trusted Zone · Endnutzer-System Mirror-Betreiber Andere Mirror-Betreiber T1 T2 T3 HTTPS / mTLS Gossip A · OSS-Lib mit SDK in-process · Maintainer-DID B · Endnutzer-Agent Phase 2 · lokaler Daemon C · Hybrid-Aggregator Phase 2 · bündelt A + B Roh-Events: nur RAM oder tmpfs. Über T1 geht ausschließlich das signierte Aggregat. Submission-Validierung Signatur · Schema · k-Anon Public Audit Log Sigstore-Rekor-Hash-Chain Aggregate-Store ClickHouse · Snapshots · API D · Registry-Scraper Mirror-intern, öffentliche Quellen Mirror 2 · Phase 2 eigener Betreiber, eigenes Recht Mirror 3+ · Phase 3 Threshold-Konsens Kein Mirror vertraut dem anderen: Divergenz zeigt sich als abweichender audit_log.head und wird offengelegt.
Drei Trust-Boundaries — T1 (Endnutzer ↔ Internet) · T2 (Submitter ↔ Mirror) · T3 (Mirror ↔ Mirror)
  • T1 — Trust-Boundary zwischen Endnutzer-Prozess (OSS-Lib mit SDK, Endnutzer-Agent, Hybrid-Aggregator) und der externen Welt.
  • T2 — Trust-Boundary zwischen Submitter (lokaler Aggregator) und Mirror-Operator. Die signierten Aggregate queren hier HTTPS / mTLS.
  • T3 — Trust-Boundary zwischen unabhängigen Mirror-Betreibern (Gossip / Pull-Federation). Ab Phase 2+ relevant.

2. STRIDE pro Komponente#

2.1 OSS-Lib mit Self-Instrumentation (Modus A)#

BedrohungBeispielMitigation
S SpoofingBösartige Lib-Version baut SDK ein, fälscht Reach für pkg:npm/example-libDID-Bindung an Maintainer-Schlüssel; Mirror prüft Signatur. Risiko: I-2-1 (Library-Spoofing).
T TamperingEndnutzer manipuliert SDK-State, erzeugt fake-runtimek-Anon-Guard greift erst ab k_min; Sybil mit einem Host nutzlos. Risiko: M-2-1.
R RepudiationSubmitter behauptet, nie eingereicht zu habenSignatur + Audit-Log unveränderlich.
I Information DisclosureSDK leakt PII aus Drittprozessen (Bug)Schema-Reject-PII (Stufe 6) + Mirror-seitige Validierung (Stufe 9). Risiko: D-2-2.
D Denial of ServiceSDK fluted Aggregator mit EventsLokaler Backpressure + Rate-Limit; bei Überlast Drop-Sample (nicht Submission-Loop).
E Elevation of PrivilegeSDK eskaliert Host-Prozess-PrivilegienSDK läuft im Lib-Kontext, ohne Sonderrechte; OS-Sandboxing (z. B. seccomp) empfohlen für sensible Hosts.

2.2 Endnutzer-Agent (Modus B)#

BedrohungBeispielMitigation
I Information DisclosureAgent liest unabsichtlich ~/.git/, lokale Pfade, Klartext-Repo-NamenStufe 2 (Sanitize) + Schema-Reject-PII. Risiko: D-2-3.
T TamperingSchadcode tauscht Agent-BinaryOS-Paket-Signatur, Reproducible Builds; Verteilung über etablierte Paket-Manager.
D DoSAgent verbraucht CPU/RAM in Host-SystemFootprint-Budget K7 + Hard-Limits.
E EoPAgent läuft als root für Dep-Tree-ScanEmpfehlung: User-Mode + read-only-Mount; root nur für System-weite Discovery.

2.3 Lokaler Aggregator (Modus C)#

BedrohungBeispielMitigation
I DisclosureRAM-Dump enthält Roh-EventsRoh-Events nur in RAM/tmpfs; Disk speichert ausschließlich anonymisierte Aggregate (Stufe 8).
T TamperingAggregator-Manipulation senkt k_effectivePhase 1: Mirror prüft k_effective >= k_min deklarativ. Phase 2: ZK-SNARK-Attestation (siehe 05-zero-knowledge-vorschlag.md, Baustein B).
D DoSSubmission-Queue-OverflowEgress-Buffer mit 30-min-Verlustgrenze (K5), exponential backoff.

2.4 Registry-Scraper (Modus D)#

BedrohungBeispielMitigation
S SpoofingManipulierte Registry-ResponseHash der Manifest-Quelldatei in Provenienz-Stempel; Cross-Registry-Plausibilität (npm-Download-Stats vs. GitHub-Stars).
T TamperingMirror-Operator manipuliert eingelesene ManifesteOpen-Source-Scraper-Code; jeder Mirror kann eigenen Scraper betreiben und Aggregate cross-checken (Gossip).
I DisclosureScraper liest private GitHub-ReposWhitelist-only auf öffentliche Endpoints + Token-Scoping.
D DoSRegistry-API rate-limitsBackoff + cached Manifeste; Risiko: S-2-3.

2.5 Mirror#

BedrohungBeispielMitigation
S SpoofingAngreifer registriert „Pseudo-Mirror" mit gefälschten AggregatenFederation-Registry mit Signatur-Bestätigung; bei Eclipse-Verdacht Disclosure im eigenen Status-Endpoint. Risiko: M-2-2.
T TamperingInsider verändert Aggregate retroaktivAppend-Only-Log (Sigstore-Rekor); Manipulation würde Hash-Chain brechen und ist cross-mirror sichtbar.
R RepudiationMirror behauptet, Submission nicht erhaltenSubmitter behält submission_hash lokal; Gossip-Diff zeigt Eclipse.
I DisclosureForschungsangriff: Mosaic-Re-Identifikation aus Aggregatenk-Anon-Schwellen (k=5, k=25), DP-Noise in Phase 2 (siehe ZK-Baustein), Cohort-Mindestgröße. Risiko: D-2-1.
D DoSSybil-Submission flutet MirrorRate-Limit pro DID am Ingress (ADR-v2-0007: ≤ 24 Submissions/DID/24 h für Modi A/B/C); Überschreitung → 429 vor der Annahme, kein Audit-Log-Eintrag, das Aggregat bleibt im Egress-Buffer des Submitters und wird erneut gesendet. Dazu Cross-Mode-Plausibilität (Track A vs. D) und Burn-In für neue DIDs. Proof-of-Work ist in ADR-v2-0007 begründet verworfen. Risiko: M-2-1.
E EoPSchadcode in Mirror-Stack erlangt Aggregate-Store-SchreibrechtContainer-Isolation, signierte Releases, regelmäßige Audits (Apache-2.0 Open-Source-Stack).

2.6 Cross-Mirror-Federation (T3)#

BedrohungBeispielMitigation
Eclipse-AttackAngreifer trennt Mirror-A von Mirror-B durch BGP-Hijack o. ä.Gossip-Diff zeigt divergierende audit_log.head; Phase 3 Threshold-Konsens (≥ 2 von 3 Mirrors müssen Aggregat bestätigen).
Sybil-FederationAngreifer betreibt mehrere „unabhängige" MirrorsGeographische / Organisations-Diversität in Federation-Registry-Audits; in 06-offene-punkte.md als P1-Block.
Konsens-DriftMirrors haben unterschiedliche submission_hash-SichtPhase 2: bidirektionales Gossip + Diff-Resolution; Phase 3: Threshold-Konsens entscheidet kanonisch.

3. Re-Identifikations-Risiko (Quer)#

Auch ohne PII-Felder können Aggregate Personen identifizieren — Mosaic-Inferenz ist der primäre Angriffsvektor:

  • Nischenprojekt + kleine Kohorte: pkg:npm/sehr-spezifisches-tool hat nur 3 Maintainer; selbst k=5 Runtime-Sessions deuten plausibel auf eine Person.
  • Korrelations-Angriff: Hersteller mit eigenen CRM-Daten kann Reach-Snapshot mit seinen Kundenmetriken kreuz-referenzieren, um einzelne Endnutzer zu de-anonymisieren.

Mitigationen:

  • k_min = 5 als Untergrenze, k_min = 25 für Modi B/C wegen Endnutzer-Tiefe.
  • Verbot von kombinierten cohort_id-Mehrfachachsen, die effektiv k=1 ergäben (z. B. region × OS × runtime-band).
  • DP-Noise (Laplace-Mechanismus, ε ≤ 0.5) für besonders sensible Metriken in Phase 2.
  • Forschungs-Disclosure-Policy: jede Open-Data-Veröffentlichung mit Statement zum Re-Identifikations-Risiko.

4. Was Prometheus nicht gegen schützt#

Bewusst out-of-scope:

  • Endgerät-Kompromiss: Ist der Host bereits malware-infiziert, sind Modi A/B ohnehin nicht vertrauenswürdig. Endgerät-Schutz ist OS-/AV-Sache.
  • Maintainer-Identitäts-Diebstahl: Wer den Maintainer-Schlüssel besitzt, kann signieren. Schlüssel-Rotation und Hardware-Key (YubiKey o. ä.) sind Maintainer-Pflicht.
  • Lieferketten-Angriff stromaufwärts: Wenn npm install bereits manipuliertes Binary ausliefert, ist das ein SBOM-/Supply-Chain-Problem, nicht Prometheus-Scope.

5. Querverweise#

  • 03-risikoprofil.md — quantifizierte Risiken D/I/M/S-Familien
  • 05-zero-knowledge-vorschlag.md — ZK-Härtung (SNARK, Public Audit Log, Mix-Net, Threshold-Konsens)
  • data-flow.md — Stufen-Sicht der Anonymisierung
  • ADR-v2-0001 — Submission-Protokoll
  • 06-offene-punkte.md — Anti-Sybil-Strategie, Eclipse-Disclosure-Format