Wie PaSBaT funktioniert

Kurz gesagt: anonymisieren → hochladen → analysieren → audit-fähigen Report erhalten.

Überblick

  • PaSBaT automatisiert Security- & Compliance-Audits.
  • Die öffentliche Demo ist absichtlich „Overkill“: große, realistische Multi-Site-Topologien (inkl. MPLS), Analyse und Original-/anonymisierte Reports.
  • Produktiv ist der Ablauf schlanker: Anonymisieren → Hochladen → Analysieren → Report.

Warum die Demo komplexer ist als die Realität

  • Realistische Testdaten: keine frei verfügbaren, großen, realitätsnahen Config-Datensätze – daher Demo-Netzgenerierung als Skalierungs-Beweis.
  • „Worst-Case“-Simulation: Wenn Multi-Site/MPLS automatisiert klappt, funktionieren kleinere Umgebungen erst recht.
  • Produktiv schlanker: echte Netze sind vorhanden – Netzgenerierung & Orchestrierung entfallen.

Produktivablauf (so läuft es später beim Kunden)

1) Lokal anonymisieren

Leichtgewichtiges Tool läuft lokal über Gerätekonfigurationen.
Ergebnis: anonymisierte .cfgs (keine sensitiven Daten).

2) Upload

Die anonymisierten Dateien werden in PaSBaT hochgeladen.

3) Analyse

Bewertung gegen Policies/Frameworks (z. B. NIS2/ISO), Findings, Prioritäten, GAP-Analysen.

4) Report

Audit-fähige Reports (HTML/PDF) inkl. Evidenzen und Remediation-Hinweisen – optional mehrsprachig.

Kein Live-Zugriff, keine Agenten, kein Vendor-Lock-in.

Demo-Ablauf (öffentlicher PoC)

  • Frontend (VM 1, statisch): UI & Auslieferung, kein Compute-Zugriff.
  • Orchestrator (VM 2): validiert Formulardaten, startet die Pipeline, einzige Brücke zwischen Frontend & Backend.
  • Backend (VM 3, Container):
    • NetGen erzeugt vollständige, realistische Konfigurationen.
    • Analyzer bewertet gegen Regel-Sets/Frameworks.
    • Report-Generator erstellt den Original-Report.
    • Anonymizer erzeugt DSGVO-konforme, anonymisierte Artefakte + Report.
    • Delivery stellt Ergebnisse lesend für den Orchestrator bereit.
  • Rückgabe: Orchestrator liefert Topologie, Dateien und Reports ans Frontend.

Hinweis: Die Live-Demo wird aktuell nur auf Anfrage freigeschaltet, um Ressourcen zu schonen.

Sicherheitsprinzipien

  • Strikte Netztrennung: Drei isolierte VMs (Frontend / Orchestrator / Backend).
  • Least Privilege: Frontend ohne Backend-Zugriff; Orchestrator als klare, begrenzte Brücke.
  • UFW/Firewall: Whitelists, keine seitlichen Kanäle.
  • Keine Kundendaten in der Demo: ausschließlich generierte Testdaten.
  • Automatisierung: Jeder Reportlauf ist reproduzierbar; keine manuellen Eingriffe nötig.

Was wird im Report belegt?

  • Run-Metadaten: Timestamp, Run-ID, Build-Version.
  • Nachvollziehbarkeit: Evidenzen pro Finding, klare Zuordnung zu Controls (z. B. NIS2-Domänen, ISO-Kapitel).
  • Remediation-Pfad: Umsetzbare Schritte, Prioritäten, ggf. Referenz-Hardening.

Häufige Fragen (kurz)

Ist die Demo gleich Produktiv?

Nein. Die Demo ist bewusst komplexer (Multi-Site/MPLS). Produktiv entfällt die Netzgenerierung – es bleibt Analyse & Report.

Wie werden Daten geschützt?

Produktiv werden nur lokal anonymisierte Konfigurationen hochgeladen; keine sensitiven Klartextdaten.

Welche Hersteller werden unterstützt?

PoC-Fokus aktuell auf Cisco; weitere Vendoren modular erweiterbar (Roadmap nach Nachfrage).

Nächste Schritte