Regeln für das Vorgehen und die Produktionssicherheit bei institutionellen Blockchain-Penetrationstests

Die ersten beiden Artikel dieser Serie haben dargelegt, warum Krypto-Institutionen Blockchain-Penetrationstests benötigen (Teil 1) und was diese Disziplin umfasst (Teil 2). Dieser Artikel widmet sich der Frage, wie ein institutioneller Auftrag vorbereitet und sicher durchgeführt wird: die Einsatzregeln (Rules of Engagement), die Schutzmaßnahmen für die Produktionssicherheit sowie Behebung und Nachtest, die aus Befunden Korrekturen machen – der unten dargestellte Lebenszyklus des Engagements.

Web3 erhöht die Einsätze bei Produktionstests auf eine besondere Weise: On-Chain-Aktionen sind in der Regel unumkehrbar, Testaktivitäten sind oft öffentlich auf der Chain sichtbar, und die betroffenen Systeme können echte Gelder bewegen. Die nachfolgenden Schutzmaßnahmen gewichten daher die Wahl der Umgebung, Wertlimits, den Umgang mit Schlüsseln und den Abgleich stärker als ein herkömmliches Engagement.

RoE als operative Grundlage

Laut dem US National Institute of Standards and Technology (NIST) legen die Einsatzregeln (RoE) die Richtlinien und Einschränkungen für Sicherheitstests fest [1]. Bei einem institutionellen Engagement wird dadurch aus einer Testentscheidung ein autorisiertes Mandat: ein definiertes Ziel, ein definierter Umfang und eine benannte Handlungsbefugnis.

Dieses Mandat ist wichtig, weil ein Testteam seine Befugnis nicht sicher aus einem Vertrag oder einer Vermögensliste ableiten kann. Ohne eine gemeinsame Entscheidung darüber, welches Risiko bewertet wird, welche Systeme betroffen sind und wer dafür verantwortlich ist, könnte das Team den falschen Pfad testen, eine kritische Abhängigkeit ausschließen oder nicht befugt sein, einen wesentlichen Befund zu validieren.

Ausgangspunkt ist die Geschäftsentscheidung, die der Test unterstützen soll. Ein Ziel kann die öffentliche Exponierung vor dem Launch betreffen. Es kann sich auf die Autorisierung von Kunden und Programmierschnittstellen (APIs) konzentrieren oder auf die Erreichbarkeit privilegierter Cloud- und Betriebssysteme. Es kann auch einen Signatur- oder Auszahlungsworkflow testen oder eine Drittanbieterintegration bewerten. Dieses Ziel bestimmt die relevanten Systeme, das zu mindernde Risiko und das Ergebnis, das das Management für eine Entscheidung benötigt.

Das Ziel sollte sich in einen Umfang übersetzen, der dem Betriebsmodell folgt. Bei einer Krypto-Institution umfasst dies üblicherweise kundenorientierte Web-, Mobil- und Programmierschnittstellen-Dienste (APIs); Cloud-Konten sowie Identitäts- und Zugriffsmanagement (IAM); Systeme und Geheimnisse für kontinuierliche Integration und kontinuierliche Auslieferung (CI/CD); Betriebskonsolen; Wallets und Genehmigungsworkflows; Signatursysteme; Ledger- und Auszahlungsdienste sowie die verbindenden Anbieter. Zusammen bestimmen diese Komponenten, wie Kunden und interne Teams fondsbezogene Aktionen initiieren, genehmigen, signieren, freigeben und abgleichen. Die Institution und das Testteam sollten sich außerdem auf die relevante Perspektive einigen: einen externen Angreifer, einen normalen Nutzer, einen Partner, einen Mitarbeiter mit geringen Rechten oder eine als kompromittiert angenommene Identität.

Jedes System, Konto, jede Schnittstelle und Aktivität im Umfang sollte einen benannten Verantwortlichen und einen klaren Autorisierungsweg haben. Dasselbe gilt für Abhängigkeiten von Drittanbietern, einschließlich Verwahrungsanbieter, Wallet-Schnittstellen, Remote-Procedure-Call-(RPC-)Anbieter, Software-as-a-Service-(SaaS-)Plattformen, Identitätsanbieter, Code-Hosting-Dienste und verwaltete Dienste. Das Testen einer vom Anbieter betriebenen Umgebung erfordert dessen schriftliche Genehmigung; die Autorisierung der Institution allein autorisiert möglicherweise keine Aktivität gegen die Systeme des Anbieters.

Gemeinsam legen Ziel, Umfang und Autorisierungsweg fest, was das Team bewerten darf. Der nächste Schritt hält fest, wie das Team diese Bewertung durchführen darf.

Betriebsgrenzen

Betriebsgrenzen sind die schriftlichen Einschränkungen, die die Durchführung regeln, nachdem das Mandat vereinbart wurde. Sie unterscheiden zwischen dem, was im Umfang liegt, und dem, was an Aktivität erlaubt ist: Ein Produktions-Auszahlungsdienst kann für die Validierung des Autorisierungswegs im Umfang liegen, während tatsächliche Kundenauszahlungen, die Extraktion privater Schlüssel, Änderungen an der Persistenz und lastgenerierende Angriffe untersagt bleiben.

Diese Unterscheidung verhindert, dass Unsicherheit zu einem operativen Risiko wird. Während eines Produktions-Engagements müssen die Institution und das Testteam im Voraus wissen, welche Techniken erlaubt sind, wann Aktivitäten gestoppt werden müssen, wer diese Entscheidung treffen kann und wie Beweise gehandhabt werden dürfen. Andernfalls kann selbst ein autorisierter Test vermeidbare Auswirkungen auf Dienste oder Kunden verursachen.

Die RoE sollten diese Entscheidungen festhalten, bevor der Test beginnt. Zudem sollte das Dokument präzise genug sein, damit beide Parteien handeln können, ohne grundlegende Fragen während des Engagements erneut aufwerfen zu müssen.

Die folgende Tabelle überführt das oben festgelegte Testmandat in einen praktischen RoE-Eintrag. Sie gruppiert die Entscheidungen, die vor dem Testen geklärt sein müssen: was bewertet wird, wer autorisiert ist, welche Aktivitäten und Grenzen gelten, wie sich die Parteien abstimmen und wie Beweise gehandhabt werden. Es handelt sich nicht um eine generische Checkliste, die unverändert übernommen werden soll; die erfassten Werte sollten das Betriebsmodell der Institution, die Testperspektive und das Produktionsrisiko widerspiegeln.

Sobald die Ausführungsgrenzen vereinbart sind, kann die Institution die eingesetzten Systeme und Betriebsbedingungen vorbereiten, auf die der Test treffen wird.

Betriebsumgebung und Schutz von Live-Diensten

Die Betriebsumgebung ist das eingesetzte System und die Geschäftsaktivität darum herum: Vertrauensgrenzen, Geldflüsse, Dienstabhängigkeiten, Betriebsworkflows und die für jede Komponente verantwortlichen Personen. Sie ist der Kontext, in dem ein Testbefund seine tatsächliche Bedeutung erhält.

Dieser Kontext ist entscheidend, da dieselbe technische Schwachstelle sehr unterschiedliche Folgen haben kann. Ein API-Problem, eine Cloud-Berechtigung oder eine Schwachstelle im Genehmigungsworkflow kann Kundendaten, interne Abläufe, Signaturbefugnisse, Guthabenänderungen oder Auszahlungen betreffen. Bei einer aktiven Börse, einem Zahlungsunternehmen, einem Verwahrer oder einem Wallet-Anbieter muss das Testen auch mit Handel, Zahlungen, Einzahlungen, Auszahlungen, Abwicklung und Support-Betrieb koexistieren.

Ein aktueller Überblick sollte das Vermögens- und Dienstinventar, Architektur und Integrationspunkte, das Cloud- und Identitätsmodell, Betriebsworkflows sowie Drittanbieterabhängigkeiten umfassen. Die Planung sollte außerdem relevante Geschäftsfenster, geplante Releases, Änderungssperren, Hochvolumenzeiten, Hot-Wallet-Aktivitäten und andere betriebliche Ereignisse identifizieren. Während des Tests beobachtete Dienstgesundheitssignale sollten Transaktions- und API-Volumen, Antwortzeiten, Fehlerraten, Warteschlangentiefe, den Zustand des Signaturdienstes und die Verfügbarkeit des Wallet-Dienstes umfassen. Die Betriebsumgebung umfasst die Produktionsdienste, Identitäten, Betriebsworkflows und externen Abhängigkeiten, die zur Initiierung und Steuerung von Transaktionen verwendet werden. Die RoE halten die genehmigte Testumgebung, Testidentitäten, zulässige Schritte innerhalb eines Signatur- oder Auszahlungsworkflows sowie die für jedes kontrollierte Validierungsszenario geltenden Schutzmaßnahmen fest. Diese Parameter sorgen dafür, dass sich die Bewertung auf die Kontrollen der Institution konzentriert und gleichzeitig die normale Kunden- und Betriebsaktivität schützt.

Der Digital Operational Resilience Act (DORA) der Europäischen Union bietet einen nützlichen Referenzpunkt für stark regulierte Bereiche. Für Finanzunternehmen, die für bedrohungsorientierte Penetrationstests ausgewählt wurden, verlangt Artikel 26, dass der Test kritische oder wichtige Funktionen abdeckt und auf den Produktionssystemen durchgeführt wird, die diese unterstützen, einschließlich relevanter ausgelagerter Dienste im Bereich Informations- und Kommunikationstechnologie (IKT) [2]. Dies ist keine generelle Genehmigung für Produktionstests; jede Institution benötigt weiterhin ihre eigene Befugnis, Schutzmaßnahmen sowie die anwendbaren rechtlichen und vertraglichen Genehmigungen.

Diese Produktionsbasis erlaubt es der Institution, spezifischere Schutzmaßnahmen auf die Workflows anzuwenden, die direkte Auswirkungen auf Gelder oder den Kundenzugang haben können.

Grenzen für sensible Workflows

Sensible Workflows sind die Systeme und Aktionen, deren normaler Betrieb direkte Auswirkungen auf Gelder, den Kundenzugang oder die Integrität von Aufzeichnungen haben kann. Dazu gehören Signatur- und Auszahlungsworkflows, privilegierter Produktionszugriff, der Umgang mit Kundendaten und Ledger-Operationen.

Diese Workflows benötigen strengere Grenzen, da ein realistischer Test sonst von der Validierung einer Kontrolle zur Veränderung eines Kunden- oder Finanzergebnisses übergehen kann. Das Risiko ist nicht nur technischer Natur: Es kann unbefugte Geldbewegungen, falsche Guthaben, die Offenlegung sensibler Daten oder eine Verwechslung von Testaktivität mit einem tatsächlichen Vorfall umfassen. Wenn ein Kontrollversagen Gelder betreffen kann, ist eine Rückgängigmachung möglicherweise schwierig oder unmöglich, weshalb diese Grenzen verhindern müssen, dass ein Test unbeabsichtigte oder nicht autorisierte Geldbewegungen verursacht.

Signatur- und Auszahlungsworkflows erfordern kontrollierte Szenarien, die validieren, wie die Institution eine Anfrage authentifiziert, Richtlinien anwendet, Genehmigungen weiterleitet und das Ergebnis abgleicht. Die RoE identifizieren designierte Testkonten, autorisierte Teilnehmer, das erwartete Richtlinienverhalten, ein Obergrenze für das Szenario sowie die zur Validierung des Workflows erforderlichen Beweise. Sie halten dann den weitestmöglich zulässigen Workflow-Schritt fest: Anfrageerstellung, Richtlinienentscheidung, Anzeige der Genehmigung, Signaturanfrage, Freigabeentscheidung oder Abgleich. Testidentitäten werden über den vereinbarten Zugriffsprozess bereitgestellt, verwendet und außer Betrieb genommen. Dieselbe Disziplin gilt für privilegierten Zugriff, Kundendaten und Ledger-Operationen: Das Zugriffsmodell, das erwartete Systemverhalten und die Beweisgrenzen werden vor Testbeginn vereinbart; auf Kundendaten wird nur zugegriffen, wo nötig, sie werden in den Beweisen minimiert und geschwärzt und innerhalb des genehmigten Beweisarchivs aufbewahrt.

Diese Kontrollen ermöglichen es, sensible Pfade in der Produktion zu testen, ohne sie wie gewöhnliche Anwendungsfunktionen zu behandeln. Sie geben dem Betrieb und dem Testteam außerdem eine gemeinsame Grundlage für die Koordination von Live-Aktivitäten.

Testen und Koordination

Testen und Koordination bilden das Live-Betriebsmodell für das Engagement. Sie verbinden den Diensteigner, das Security-Operations-Team, die Funktion für Vorfallreaktion und den Testleiter, während der Test läuft.

Dieses Modell ist notwendig, weil erwartete Testaktivität und ein tatsächlicher Sicherheitsvorfall ähnlich aussehen können. Wenn Überwachung, Benachrichtigungen oder Pause-Entscheidungen unklar sind, kann das Testen die Vorfallreaktion verzögern oder Unsicherheit darüber schaffen, ob eine Produktionsmaßnahme erforderlich ist.

Das Kommunikationsmodell legt fest, wer den vollständigen Testplan kennt, wer zeitkritische Mitteilungen erhält und wer Aktivitäten pausieren oder fortsetzen kann. Es variiert je nach Ziel: Manche Tests erfordern eine enge Abstimmung mit dem Security Operations Center (SOC) rund um sensible Systeme, während Tests mit eingeschränkter Offenlegung bewerten, ob die Überwachung die Aktivität erkennt und die Eskalation die richtigen Personen erreicht. Wenn ein kontrolliertes Szenario einen transaktionsbezogenen Workflow durchspielt, deckt der Plan auch relevante Benachrichtigungen und erwartete Alarme von Verwahrungs-, Wallet-, Transaktionsprüfungs- und Überwachungsanbietern ab. Ein separater Sicherheitskontakt und eine benannte Pause-Befugnis sind jederzeit erreichbar. Der Diensteigner und das Testteam vereinbaren messbare Stopp-Kriterien, wie etwa Abweichungen vom Fehlerbudget, unerwartete Anstiege der Antwortzeit im 95. Perzentil (p95) oder der Warteschlangentiefe, verdächtige Konto- oder Wallet-Aktivitäten, wesentliche Abgleichsabweichungen oder einen ungeplanten Sicherheitsalarm.

Diese Vorbereitung stärkt auch die operative Resilienz. Die Hong Kong Securities and Futures Commission (SFC) erwartet von Betreibern von Handelsplattformen für virtuelle Vermögenswerte, dass sie eine 24/7-Überwachung und dokumentierte Eskalationsverfahren aufrechterhalten und Notfall- und Geschäftskontinuitätsübungen mit relevanten Drittparteien durchführen [3]. Diese regulatorischen Verweise dienen der Veranschaulichung und stellen keine Rechtsberatung dar; die Anwendbarkeit ist jurisdiktionsspezifisch und sollte mit Rechtsbeistand bestätigt werden.

Das Diagramm zeigt die Kontrollschleife, die während des laufenden Tests gilt. Ihr zentraler Punkt ist, dass RoE-Grenzen nicht mit der Autorisierung enden: Überwachung und der Sicherheitskanal verwandeln diese Grenzen in Entscheidungen zum Fortsetzen, Pausieren, Eindämmen oder zur Übergabe eines verifizierten Befunds an die Behebung. Sie erscheint an dieser Stelle, weil diese Entscheidungen zur Live-Koordination gehören und nicht zur früheren Definition des Umfangs oder der Produktionsvorbereitung.

Dasselbe Modell regelt kritische Befunde: einen nachgewiesenen Pfad zu unbefugter Geldbewegung, die Kompromittierung von Signaturbefugnissen oder einer Produktions-Kontrollebene, die Offenlegung hochsensibler Kundendaten oder ein wesentliches Risiko für einen kritischen Dienst. Der Reaktionspfad sollte den Eskalationsschwellenwert, die Personen, die den Befund klassifizieren, die Befugnis zur Pausierung der betroffenen Aktivität sowie den Prozess für Eindämmung, Behebung und Validierung festlegen. Das Penetrationstest-Team demonstriert und meldet das Problem; die Institution behält die Befugnis für Produktionsentscheidungen, Kundenkommunikation und Behebung. Eine Benachrichtigung über einen wesentlichen Befund sollte zunächst über den geschützten Sicherheitskanal erfolgen, gefolgt von einer vereinbarten schriftlichen Aufzeichnung, die keine unnötigen Exploit-Details offenlegt.

Sobald ein Befund eingedämmt und zugewiesen ist, hängt der Wert des Engagements davon ab, ob die Institution dieses Ergebnis in eine verifizierte Kontrollverbesserung umsetzen kann.

Behebung, Nachtest und Rückkehr zum Normalzustand

Behebung und Nachtest sind der Abschlussprozess, der eine nachgewiesene Schwachstelle in eine validierte Verbesserung umwandelt. Die Rückkehr zum Normalzustand ist Teil desselben Prozesses: Testzugriffe, kontrollierte Szenarien und gesammelte Beweise dürfen nicht zu neuen, langlebigen Risiken werden.

Diese letzte Phase entscheidet darüber, ob das Engagement das Risiko verringert oder nur einen Bericht erzeugt. Ein Befund ohne Verantwortlichen, Behebungsweg und Validierungsbedingung kann offen bleiben, während derselbe Angriffspfad in der Produktion weiterhin besteht.

Bevor der Test beginnt, sollte festgelegt werden, wie Befunde in Engineering-, Cloud-, Wallet-Betriebs- oder Geschäftskontroll-Workflows einfließen; wer für die Behebung verantwortlich ist; und welche Befunde einen Nachtest erfordern. Beim Abschluss werden temporäre Testidentitäten, Berechtigungen und kontrollierte Szenarien in ihre vorgesehene Konfiguration zurückversetzt, und die Diensteigner bestätigen, dass relevante Gesundheitsindikatoren innerhalb ihres erwarteten Bereichs bleiben. Die abschließende Aufzeichnung verknüpft jeden Befund mit seinem Nachweis, seiner Auswirkung, dem Verantwortlichen, dem Behebungsplan und der Nachtestbedingung. Bei einem kontrollierten transaktionsbezogenen Szenario verknüpft sie außerdem die Workflow-Referenz, die Testidentität, den Zeitstempel, den Genehmigungsnachweis und den resultierenden Ledger-Eintrag; jeder für das Szenario geschaffene temporäre Zugriff, jede Genehmigung oder Testkonfiguration wird außer Betrieb genommen. Beweise werden nur für den vereinbarten Zeitraum aufbewahrt und anschließend sicher vernichtet oder zurückgegeben.

Das Ergebnis ist keine Liste von Schwachstellen, sondern ein getesteter, behobener und erneut geprüfter Satz von Kontrollen, der die nächste Betriebsentscheidung der Institution unterstützen kann.

Fazit

Die Vorbereitung auf Blockchain-Penetrationstests ist eine institutionelle Aufgabe. Die Institution definiert das Ziel, den Betriebskontext, die Befugnis, die Dienstbeschränkungen und das Reaktionsmodell; das Testteam wendet adversariale Validierung auf diese vorbereitete Umgebung an.

Mit diesen Elementen an Ort und Stelle wird ein Penetrationstest-Engagement zu mehr als einer technischen Übung. Es wird zu einer kontrollierten Möglichkeit zu verstehen, wie die eingesetzten Systeme, Mitarbeiter und Prozesse der Institution einem Angriff standhalten.

BlockSec unterstützt Institutionen bei der Vorbereitung und Durchführung dieses Prozesses: Umfang definieren, Betriebsumgebung kartieren, RoE und Produktionsschutzmaßnahmen festlegen und Befunde in behobene und erneut getestete Kontrollen umwandeln. Um die Einsatzregeln und Produktionssicherheitskontrollen für Ihren nächsten Test zu planen, fordern Sie ein Scoping-Gespräch an; weitere Informationen sind auf Anfrage erhältlich.

Weiter mit der Serie:

• Teil 4: Web3-Angriffsflächen: Ein Überblick über Penetrationstests

Ebenfalls in dieser Serie, erscheint in Kürze:

• Teil 5: Autorisierungs- und Signatursicherheit: Web, dApps und Mobil
• Teil 6: Cloud- und CI/CD-Sicherheit: Angriffsflächen automatisierter Abläufe
• Teil 7: Sicherheit der Treasury-Kontrollebene: Signatur- und Auszahlungsgenehmigungen
• Teil 8: Sicherheit von Exchange-Ledgern: Diebstahlpfade und Datenebenen-Logik

Die Themenseite Blockchain Penetration Testing bietet die Sicht auf Engagement-Ebene.

Referenzen

Nummeriert in der Reihenfolge des ersten Erscheinens.

1. National Institute of Standards and Technology, Rules of Engagement (ROE), CSRC Glossary.
2. Europäische Union, Verordnung (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Artikel 26.
3. Hong Kong Securities and Futures Commission, Circular to Licensed Virtual Asset Trading Platform Operators on Custody of Virtual Assets (15. August 2025).