Assumed Breach Simulation: Sicherheit und Compliance für deutsche Unternehmen

Eine Assumed Breach Simulation beantwortet die Frage, die der externe Penetrationstest offenlässt: Was passiert, wenn ein Angreifer schon drin ist. Sie startet von einer kompromittierten Position, einem Arbeitsplatz, einem Benutzerkonto oder einem VPN-Zugang, und belegt Schritt für Schritt, wie weit er von dort kommt. Diese Seite erklärt den Ablauf, grenzt die Simulation von Breach and Attack Simulation ab, zeigt den Nachweis für NIS2, TISAX, ISO/IEC 27001 und DORA, benennt die deutschen Besonderheiten bei Datenhaltung, Mitbestimmung und Zertifizierung und nennt die Anbieter.

Was eine Assumed Breach Simulation ist, und was Breach and Attack Simulation

Der Begriff kommt aus dem Zero-Trust-Modell. Microsoft formuliert dessen dritten Grundsatz als „Annehmen eines Verstoßes“: Sicherheitskontrollen werden mit der Erwartung entworfen, dass Angreifer innerhalb der Umgebung arbeiten können, und konzentrieren sich darauf, die Auswirkungen zu begrenzen und Angriffe schnell zu erkennen. Eine Assumed Breach Simulation prüft, ob diese Annahme im eigenen Netz hält. Sie verzichtet auf den Einbruch von außen, setzt den Tester auf eine Startposition, die ein Phishing-Opfer, ein gestohlenes Notebook oder ein geleaktes Passwort ihm verschaffen würde, und misst Reichweite, Zeit und Lärm: Welche Rechte erreicht er, welche Daten, welche Systeme, und was davon hat die Erkennung gesehen.

Im Markt laufen vier Verfahren unter ähnlichen Namen, die unterschiedliche Fragen beantworten.

Die Verwechslung von ABS und BAS kostet in der Praxis Geld, weil beide „Simulation“ heißen und beide mit MITRE ATT&CK arbeiten. BAS prüft die Erkennung gegen Bekanntes und ist deshalb das Werkzeug des Security Operations Center. ABS prüft die Angriffsfläche von innen und ist das Werkzeug dessen, der Rechte, Segmentierung und Identitäten verantwortet. Beide ergänzen sich; keines ersetzt das andere. Was die Verfahren im Vergleich zum Schwachstellenscan und zum manuellen Pentest leisten, ordnet die Seite Automatisierte Penetrationstests.

Ablauf: von der Startposition zum Nachweis

Ein Lauf folgt acht Schritten, die sich bei einer kontinuierlichen Simulation wiederholen, sobald sich das Netz ändert oder ein Befund behoben ist.

1. Startposition festlegen: ein Standardarbeitsplatz mit Domänenkonto ohne Sonderrechte, ein VPN-Zugang oder ein Dienstkonto, je nach Szenario. Die Position entspricht dem, was ein erfolgreiches Phishing oder ein geleaktes Passwort einem Angreifer verschafft.
2. Regeln vereinbaren: keine destruktiven Verfahren, kein Denial of Service, keine Veränderung von Produktivdaten, Zeitfenster, Ausschlusslisten für sensible Systeme wie Medizintechnik oder Steuerungen, ein Notstopp. Das BSI unterscheidet in seinem Praxis-Leitfaden die Aggressivität eines Tests von passiv scannend bis aggressiv; die Simulation arbeitet in den Stufen vorsichtig und abwägend.
3. Erkunden: Domänenstruktur, Gruppen und Vertrauensstellungen in Active Directory oder Entra ID, Freigaben, Dienste, Zertifikatsdienste, Verwaltungsprotokolle, interne Anwendungen.
4. Rechte ausweiten: lokale Schwachstellen, Fehlkonfigurationen, im Klartext gespeicherte Zugangsdaten, fehlerhafte Delegierungen, Kerberos-Schwächen.
5. Lateral bewegen: von System zu System entlang der gefundenen Rechte und Vertrauensstellungen, über Segmentgrenzen hinweg, wo die Segmentierung es zulässt.
6. Ziel erreichen: Domänenadministration, Zugriff auf die definierten Kronjuwelen (ERP, Dateiablage, Backup, Quellcode), Übergang in OT-Netze, Persistenz.
7. Belegen und bewerten: jeder Schritt mit reproduzierbarem Proof-of-Concept, Zuordnung zu MITRE-ATT&CK-Techniken, Abgleich mit dem, was Erkennung und SOC gesehen haben, Bewertung nach Auswirkung auf das Geschäft.
8. Beheben und wiederholen: Maßnahmenplan mit Verantwortlichen, Re-Test nach der Behebung, Vergleich der Reichweite zwischen zwei Läufen.

Der Unterschied zwischen einer einmaligen und einer kontinuierlichen Simulation liegt im achten Schritt. Die Rechte- und Vertrauensstruktur eines Unternehmensnetzes ändert sich mit jedem neuen Konto, jeder Gruppe, jeder Freigabe und jedem Dienstkonto; ein jährlicher Lauf beschreibt einen Zustand, der beim Lesen des Berichts nicht mehr existiert. Eine kontinuierliche Simulation läuft auf Abruf oder nach Zeitplan und zeigt die Reichweite als Verlauf, nicht als Momentaufnahme.

Welchen Nachweis die Simulation für NIS2, TISAX, ISO/IEC 27001 und DORA liefert

Kein Regelwerk nennt die Assumed Breach Simulation beim Namen. Alle vier verlangen aber Belege, die genau sie liefert: ob Zugriffsrechte und Authentifizierung halten, ob die Wirksamkeit der Maßnahmen geprüft wurde und ob der Test in regelmäßigen Abständen und nach Änderungen stattfindet.

Für den Auditor zählt die Dokumentation je Lauf: Datum und Startposition, Regeln, jeder Schritt mit Nachweis, erreichte Rechte und Systeme, abgeleitete Maßnahmen mit Verantwortlichen, Ergebnis des Wiederholungstests. Was NIS2 im Wortlaut verlangt, steht auf der Seite NIS2: Wirksamkeit der Sicherheitsmaßnahmen belegen; die Testpflichten für Banken und Versicherer auf der Seite DORA.

Deutsche Besonderheiten: Datenhaltung, Mitbestimmung, Zertifizierung, Behörden

Eine Assumed Breach Simulation verarbeitet das, was ein Unternehmen am wenigsten aus der Hand geben will: Zugangsdaten, Konfigurationen, Rechtebeziehungen und die Karte seiner internen Angriffspfade. Vier Fragen entscheiden deshalb über die Anbieterwahl in Deutschland.

Datenhaltung: Die Simulation ist eine Auftragsverarbeitung nach Art. 28 DSGVO. Laufen Steuerung oder Auswertung über Infrastruktur eines US-Anbieters, kommen eine Übermittlung in Drittländer nach Kapitel V DSGVO und der Zugriff nach dem US CLOUD Act hinzu. Prüfbar sind Betreiber und Standort jedes Rechenzentrums in der Verarbeitungskette und die Frage, ob ein externer KI-Anbieter beteiligt ist.

Mitbestimmung: Berührt die Simulation Konten und Arbeitsplätze von Mitarbeitern, kann sie als technische Einrichtung gelten, die Verhalten oder Leistung erkennen lässt; dann ist der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG zu beteiligen. In der Praxis regelt eine Betriebsvereinbarung Zweck, Umfang, Auswertung und Löschung der Testdaten; die Startposition wird mit einem dafür angelegten Testkonto besetzt, nicht mit dem Konto einer realen Person.

Zertifizierung: Software für Angriffssimulationen zertifiziert niemand. Das BSI zertifiziert IT-Sicherheitsdienstleister für IS-Penetrationstests und Personen als Penetrationstester; Anbieter können selbst nach ISO/IEC 27001 zertifiziert sein oder ein TISAX-Label tragen. Für Behörden und Betreiber kritischer Anlagen gilt zusätzlich der Praxis-Leitfaden des BSI für IS-Penetrationstests mit seinen Vorgaben zu Vorbereitung, Durchführung und Dokumentation; eine Simulation, die diesem Leitfaden folgt, lässt sich in Verfahren nach IT-Grundschutz einordnen.

Ansprechpartner: Die Ergebnisse einer Simulation sind erklärungsbedürftig, weil sie Rechtebeziehungen und Angriffspfade zeigen, die so in keinem Scan stehen. Ein fester Ansprechpartner mit Pentest-Qualifikation, der die Befunde mit dem Team durchgeht, gehört deshalb zur Leistung, nicht zum Support.

Anbieter in Deutschland

Auswahl: acht Fragen an den Anbieter

1. Von welcher Startposition aus arbeitet die Simulation, und lässt sie sich je Szenario ändern (Arbeitsplatz, VPN, Dienstkonto, Gast-WLAN)?
2. Erarbeitet die Simulation den Angriffspfad selbst, oder spielt sie eine Bibliothek bekannter Techniken ab?
3. Ist jeder Schritt mit reproduzierbarem Proof-of-Concept belegt und einer MITRE-ATT&CK-Technik zugeordnet?
4. Welche Verfahren sind in der Produktion ausgeschlossen, wie werden Ausschlusslisten und Notstopp umgesetzt, und steht das im Report?
5. Wo laufen Betrieb und Datenhaltung, wer betreibt die Rechenzentren, und ist ein US-Anbieter oder ein externer KI-Anbieter in der Verarbeitungskette?
6. Ordnet der Report die Befunde § 30 BSIG, dem VDA ISA, ISO/IEC 27001 und DORA zu, oder entsteht die Zuordnung erst im eigenen ISMS?
7. Wie oft kann die Simulation laufen, sind Re-Tests nach der Behebung enthalten, und zeigt der Report die Reichweite im Verlauf?
8. Wer bespricht die Ergebnisse mit dem Team, mit welcher Qualifikation, und ist der Preis je Zielsystem und Jahr vor dem Vertrag bekannt?

Was VORNAC dazu beiträgt

Die VORNAC GmbH, Heidelberg, betreibt eine Plattform für kontinuierliche, autonome Penetrationstests und Assumed Breach Simulationen. Die Simulation startet von einer vereinbarten Position im internen Netz, erkundet Domäne, Rechte und Dienste, weitet Rechte aus und bewegt sich lateral bis zum definierten Ziel, mit realen Techniken und ohne destruktive Schritte; jeder Schritt kommt mit reproduzierbarem Proof-of-Concept, Business-Impact und Maßnahmenplan, nach der Behebung folgt der Re-Test. Die Reports ordnen die Befunde NIS2 (§ 30 BSIG), DORA, KRITIS, TISAX, VAIT/BAIT und ISO/IEC 27001 zu; für TISAX gibt es eine eigene Reportansicht entlang der Kontrollfragen des VDA ISA.

Betrieb und Datenhaltung liegen ausschließlich in deutschen Rechenzentren deutscher Betreiber, ohne US-Cloud-Anbieter und ohne externen KI-Anbieter in der Verarbeitungskette. Fester Ansprechpartner ist ein Pentester mit OSCP- und CISSP-Zertifizierung, der die Ergebnisse mit dem Team bespricht. VORNAC ist Mitglied im TeleTrusT mit dem Zeichen IT Security made in Germany und Partner der Allianz für Cyber-Sicherheit. Abgerechnet wird im Jahresmodell je Zielsystem, Re-Tests eingeschlossen. Mehr zum Ablauf steht auf der Seite Pentesting, zu Produktionsnetzen auf der Seite OT-Pentesting, zu Zulieferern mit TISAX-Label auf der Seite Automotive.

Häufige Fragen