Die ersten beiden Artikel dieser Serie legten dar, warum Krypto-Institutionen Blockchain-Penetrationstests benötigen (Teil 1) und was diese Disziplin ausmacht (Teil 2). Dieser Artikel widmet sich der Frage, wie ein institutioneller Einsatz vorbereitet und sicher durchgeführt wird: die Einsatzregeln (Rules of Engagement), die Sicherheitsvorkehrungen für den Produktivbetrieb sowie die Behebung und der Retest, die aus Befunden Korrekturen machen — der unten dargestellte Lebenszyklus des Einsatzes.
Web3 erhöht die Anforderungen an Produktivtests auf 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 reale Gelder bewegen. Die nachfolgenden Sicherheitsvorkehrungen gewichten daher die Wahl der Umgebung, Wertgrenzen, den Umgang mit Schlüsseln und den Abgleich stärker als bei einem herkömmlichen Einsatz.
RoE als operative Autorität
Laut dem US-amerikanischen National Institute of Standards and Technology (NIST) legen die RoE die Richtlinien und Einschränkungen für Sicherheitstests fest [1]. Bei einem institutionellen Einsatz wird daraus aus einer Testentscheidung ein autorisiertes Mandat: ein definiertes Ziel, ein definierter Umfang und eine benannte Handlungsbefugnis.
Dieses Mandat ist wichtig, weil ein Testteam die Befugnis nicht sicher aus einer Vertrags- oder Assetliste 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 auslassen 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 einem Launch betreffen. Es kann sich auf die Autorisierung von Kunden und Application Programming Interfaces (APIs) konzentrieren oder auf die Erreichbarkeit privilegierter Cloud- und Betriebssysteme. Es kann auch einen Signatur- oder Auszahlungs-Workflow testen oder eine Drittanbieter-Integration bewerten. Dieses Ziel bestimmt die relevanten Systeme, das zu reduzierende 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 kundenseitige Web-, Mobil- und Application Programming Interface (API)-Dienste; Cloud-Konten sowie Identity and Access Management (IAM); Continuous-Integration- und Continuous-Delivery (CI/CD)-Systeme und Secrets; Betriebskonsolen; Wallets und Genehmigungs-Workflows; Signatursysteme; Ledger- und Auszahlungsdienste; sowie die Anbieter, die diese verbinden. Zusammen bestimmen diese Komponenten, wie Kunden und interne Teams fondsbezogene Aktionen initiieren, genehmigen, signieren, freigeben und abgleichen. Institution und Testteam sollten sich zudem auf die relevante Perspektive einigen: ein externer Angreifer, ein normaler Benutzer, ein Partner, ein Mitarbeiter mit geringen Rechten oder eine als kompromittiert angenommene Identität.
Jedes System, Konto, jede Schnittstelle und Aktivität im Umfang sollte einen benannten Eigentümer und einen klaren Autorisierungspfad haben. Dasselbe gilt für Drittanbieter-Abhängigkeiten, einschließlich Custody-Anbieter, Wallet-Schnittstellen, Remote-Procedure-Call (RPC)-Anbieter, Software-as-a-Service (SaaS)-Plattformen, Identitätsanbieter, Code-Hosts und verwaltete Dienste. Das Testen einer vom Anbieter betriebenen Umgebung erfordert die schriftliche Genehmigung dieses Anbieters; die Autorisierung der Institution allein genügt möglicherweise nicht, um Aktivitäten gegen die Systeme des Anbieters zu autorisieren.
Zusammen legen Ziel, Umfang und Autorisierungspfad fest, was das Team bewerten darf. Der nächste Schritt hält fest, wie das Team diese Bewertung durchführen darf.
Betriebliche Grenzen
Betriebliche Grenzen sind die schriftlich festgehaltenen Einschränkungen, die die Durchführung nach Vereinbarung des Mandats regeln. Sie unterscheiden zwischen dem, was im Umfang liegt, und der Aktivität, die zulässig ist: Ein produktiver Auszahlungsdienst kann für die Validierung des Autorisierungspfads im Umfang liegen, während reale Kundenauszahlungen, das Extrahieren privater Schlüssel, Persistenzänderungen und lastgenerierende Angriffe verboten bleiben.
Diese Unterscheidung verhindert, dass Unsicherheit zu operativem Risiko wird. Während eines Produktiveinsatzes müssen Institution und Testteam im Voraus wissen, welche Techniken erlaubt sind, wann die Aktivität gestoppt werden muss, wer diese Entscheidung treffen darf und wie Beweise gehandhabt werden dürfen. Andernfalls kann selbst ein autorisierter Test vermeidbare Auswirkungen auf Service 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 Einsatzes erneut aufzuwerfen.
Die folgende Tabelle überträgt das oben festgelegte Testmandat in einen praktischen RoE-Eintrag. Sie gruppiert die Entscheidungen, die vor dem Testen getroffen werden müssen: Was wird bewertet, wer ist autorisiert, welche Aktivitäten und Grenzen gelten, wie koordinieren sich die Parteien und wie werden Beweise gehandhabt. Es handelt sich nicht um eine generische Checkliste, die unverändert übernommen werden soll; die festgehaltenen Werte sollten das Betriebsmodell der Institution, die Testperspektive und das Produktivrisiko widerspiegeln.
| RoE-Thema | Vor dem Testen festzuhaltende Entscheidung |
|---|---|
| Ziel und Umfang | Die Geschäftsentscheidung, die betroffenen Systeme und Schnittstellen, Eigentümer und die zu testenden Angreiferperspektiven. |
| Autorisierung | Schriftliche Befugnis, Testidentitäten, genehmigte Zugangspfade und Anbietergenehmigungen für Drittanbieter-Umgebungen. |
| Testmethode und Abschluss | Zulässige Techniken und der Punkt, an dem das Team aufhören muss, etwa nachgewiesener Zugriff, Rechteausweitung oder eine kontrollierte Workflow-Simulation. |
| Betriebsgrenzen | Testfenster, Grenzen für Anfragerate und Parallelität, Grenzen für Kontooperationen, Datenzugriffsgrenzen, Change-Freeze-Zeiträume und, wo ein genehmigtes Szenario eine Transaktion verwendet, das zulässige Netzwerk, Testadressen, Transaktionstypen, maximaler Testwert und Gas-Budget. |
| Verbotene Aktivitäten | Beispiele sind Denial-of-Service-Tests, Social Engineering, reale Kundenvermögensbewegungen, Export privater Schlüssel, Persistenz oder nicht genehmigte Produktivänderungen. |
| Sensible Workflows | Vorgesehene Wallets und Konten, freigegebene Zieladressen (Allowlist), maximaler Testwert, Genehmigungsteilnehmer, erwartetes Richtlinienverhalten, Abgleichschritte sowie der weiteste Punkt in der Transaktionskontrollkette, den die Validierung erreichen darf. |
| Kommunikation und Pause | Modell für Routinemitteilungen, geschützter Sicherheitskanal, Eskalationskontakte, Schwellenwert für wesentliche Befunde, benannte Befugnis zum Pausieren oder Fortsetzen des Tests sowie erwartete Beobachtbarkeit und Alarmbehandlung für eine genehmigte öffentliche Transaktionsübertragung. |
| Umgang mit Beweisen | Minimal notwendige Beweise, Datenminimierung und Schwärzung, Verschlüsselung, genehmigte Empfänger, Aufbewahrungsfrist, Bestätigung der Vernichtung sowie Transaktions-Hash und Netzwerkmetadaten, verknüpft mit der internen Genehmigung und dem Ledger-Nachweis für eine genehmigte Testtransaktion. |
Nach Vereinbarung der Durchführungsgrenzen kann die Institution die eingesetzten Systeme und Betriebsbedingungen vorbereiten, auf die der Test treffen wird.
Betriebsumgebung und Schutz laufender Dienste
Die Betriebsumgebung ist das eingesetzte System und die Geschäftsaktivität rund um dieses System: Vertrauensgrenzen, Geldflüsse, Diensteabhängigkeiten, Betriebsabläufe und die für jede Komponente verantwortlichen Personen. Sie ist der Kontext, in dem ein Testbefund seine eigentliche Bedeutung erhält.
Dieser Kontext ist wichtig, weil dieselbe technische Schwachstelle sehr unterschiedliche Folgen haben kann. Ein API-Problem, eine Cloud-Berechtigung oder eine Schwachstelle im Genehmigungs-Workflow kann Kundendaten, interne Abläufe, Signaturbefugnis, Guthabenänderungen oder Auszahlungen betreffen. Bei einer laufenden Börse, einem Zahlungsunternehmen, einem Verwahrer oder Wallet-Anbieter muss der Test zudem parallel zu Handel, Zahlungsverkehr, Einzahlungen, Auszahlungen, Abwicklung und Support stattfinden.
Ein aktueller Überblick sollte das Asset- und Diensteinventar, Architektur und Integrationspunkte, das Cloud- und Identitätsmodell, Betriebsabläufe und Drittanbieter-Abhängigkeiten umfassen. Die Planung sollte zudem relevante Geschäftsfenster, geplante Releases, Change-Freezes, Zeiten hohen Volumens, Hot-Wallet-Aktivität und andere betriebliche Ereignisse identifizieren. Während des Tests beobachtete Signale zur Diensteintegrität sollten Transaktions- und API-Volumina, Antwortzeiten, Fehlerraten, Warteschlangentiefe, den Zustand des Signaturdienstes und die Verfügbarkeit des Wallet-Dienstes umfassen. Die Betriebsumgebung umfasst die Produktivdienste, Identitäten, Betriebsabläufe und externen Abhängigkeiten, die zur Initiierung und Kontrolle von Transaktionen verwendet werden. Die RoE halten die genehmigte Testumgebung, Testidentitäten, zulässige Schritte innerhalb eines Signatur- oder Auszahlungs-Workflows sowie die Sicherheitsvorkehrungen fest, die für jedes kontrollierte Validierungsszenario gelten. Diese Parameter halten die Bewertung auf die Kontrollen der Institution fokussiert und schützen gleichzeitig die normale Kunden- und Betriebsaktivität.
Das Digital Operational Resilience Act (DORA) der Europäischen Union bietet einen nützlichen Referenzpunkt für einen hoch regulierten Bereich. 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 zugrunde liegenden Produktivsystemen durchgeführt wird, einschließlich relevanter ausgelagerter Informations- und Kommunikationstechnologie (IKT)-Dienste [2]. Dies ist keine allgemeine Genehmigung für Produktivtests; jede Institution benötigt weiterhin ihre eigene Befugnis, Sicherheitsvorkehrungen sowie die geltenden rechtlichen und vertraglichen Genehmigungen.
Diese Produktivbasis erlaubt es der Institution, spezifischere Sicherheitsvorkehrungen auf die Workflows anzuwenden, die sich direkt auf Gelder oder den Kundenzugang auswirken können.
Grenzen für sensible Workflows
Sensible Workflows sind die Systeme und Aktionen, deren normaler Betrieb sich direkt auf Gelder, den Kundenzugang oder die Integrität von Aufzeichnungen auswirken kann. Dazu gehören Signatur- und Auszahlungs-Workflows, privilegierter Produktivzugriff, der Umgang mit Kundendaten und Ledger-Operationen.
Diese Workflows benötigen strengere Grenzen, weil 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, kann eine Rückabwicklung schwierig oder unmöglich sein. Daher müssen diese Grenzen verhindern, dass ein Test unbeabsichtigte oder unbefugte Geldbewegungen verursacht.
Signatur- und Auszahlungs-Workflows erfordern kontrollierte Szenarien, die validieren, wie die Institution eine Anfrage authentifiziert, Richtlinien anwendet, Genehmigungen weiterleitet und das Ergebnis abgleicht. Die RoE benennen vorgesehene Testkonten, autorisierte Teilnehmer, erwartetes Richtlinienverhalten, eine Obergrenze für das Szenario und die zur Validierung des Workflows benötigten Beweise. Sie halten dann den weitesten zulässigen Workflow-Schritt fest: Erstellung der Anfrage, Richtlinienentscheidung, Anzeige der Genehmigung, Signaturanfrage, Freigabeentscheidung oder Abgleich. Testidentitäten werden über den vereinbarten Zugriffsprozess bereitgestellt, genutzt und stillgelegt. Dieselbe Disziplin gilt für privilegierten Zugriff, Kundendaten und Ledger-Operationen: Das Zugriffsmodell, das erwartete Systemverhalten und die Beweisgrenze werden vor Testbeginn vereinbart; auf Kundendaten wird nur zugegriffen, wo dies notwendig ist, sie werden in den Beweisen minimiert und geschwärzt und innerhalb des genehmigten Beweis-Repositorys aufbewahrt.
Diese Kontrollen ermöglichen es, sensible Pfade im Produktivbetrieb zu testen, ohne sie wie gewöhnliche Anwendungsfunktionen zu behandeln. Sie geben Betrieb und Testteam zudem eine gemeinsame Grundlage für die Koordination von Live-Aktivitäten.
Testen und Koordination
Testen und Koordination bilden das operative Live-Modell für den Einsatz. Sie verbinden den Diensteigentümer, das Sicherheitsbetriebsteam, die Incident-Response-Funktion und den Testleiter, während der Test läuft.
Dieses Modell ist notwendig, weil erwartete Testaktivität und ein tatsächliches Sicherheitsereignis ähnlich aussehen können. Wenn Überwachung, Benachrichtigungen oder Pausenentscheidungen unklar sind, kann das Testen die Incident-Response verzögern oder Unsicherheit darüber schaffen, ob eine Produktivmaßnahme erforderlich ist.
Das Kommunikationsmodell legt fest, wer den vollständigen Testplan kennt, wer zeitkritische Mitteilungen erhält und wer die Aktivität pausieren oder fortsetzen darf. 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 Aktivität erkennt und die Eskalation die richtigen Personen erreicht. Wo ein kontrolliertes Szenario einen transaktionsbezogenen Workflow ausübt, deckt der Plan zudem relevante Benachrichtigungen und erwartete Alarme von Custody-, Wallet-, Transaktionsüberwachungs- und Monitoring-Anbietern ab. Ein separater Sicherheitskontakt und eine benannte Pausenbefugnis sind jederzeit erreichbar. Diensteigentümer und Testteam vereinbaren messbare Abbruchkriterien, etwa Abweichungen vom Error-Budget, unerwartete Anstiege der 95.-Perzentil (p95)-Antwortzeit oder Warteschlangentiefe, verdächtige Konto- oder Wallet-Aktivität, wesentliche Abgleichsabweichungen oder einen ungeplanten Sicherheitsalarm.
Diese Vorbereitung stärkt zudem die betriebliche Resilienz. Die Hongkonger Securities and Futures Commission (SFC) erwartet von Betreibern virtueller Vermögenswert-Handelsplattformen eine 24/7-Überwachung und dokumentierte Eskalationsverfahren sowie die Durchführung von Notfall- und Business-Continuity-Übungen mit relevanten Dritten [3]. Diese regulatorischen Verweise dienen der Veranschaulichung, nicht als Rechtsberatung; die Anwendbarkeit ist rechtsraumspezifisch und sollte mit Rechtsbeistand bestätigt werden.
Das Diagramm zeigt die Kontrollschleife, die gilt, während der Test läuft. Der zentrale Punkt ist, dass die RoE-Grenzen nicht mit der Autorisierung enden: Überwachung und der Sicherheitskanal verwandeln diese Grenzen in Entscheidungen, einen verifizierten Befund fortzusetzen, zu pausieren, einzudämmen oder in die Behebung zu überführen. Es erscheint an dieser Stelle, weil diese Entscheidungen zur Live-Koordination gehören und nicht zur früheren Festlegung des Umfangs oder zur Produktivvorbereitung.
Dasselbe Modell regelt kritische Befunde: einen nachgewiesenen Pfad zu unbefugter Geldbewegung, die Kompromittierung von Signaturbefugnis oder einer Produktiv-Kontrollebene, die Offenlegung hochsensibler Kundendaten oder ein wesentliches Risiko für einen kritischen Dienst. Der Reaktionspfad sollte den Eskalationsschwellenwert festlegen, die Personen, die den Befund klassifizieren, die Befugnis zur Pausierung der betroffenen Aktivität sowie den Prozess für Eindämmung, Behebung und Validierung. Das Penetrationstest-Team weist das Problem nach und meldet es; die Institution behält die Entscheidungsbefugnis für Produktivmaßnahmen, Kundenkommunikation und Behebung. Eine Benachrichtigung über einen wesentlichen Befund sollte zunächst den geschützten Sicherheitskanal nutzen, gefolgt von einem vereinbarten schriftlichen Bericht, der keine unnötigen Exploit-Details offenlegt.
Sobald ein Befund eingedämmt und zugewiesen wurde, hängt der Wert des Einsatzes davon ab, ob die Institution dieses Ergebnis in eine verifizierte Kontrollverbesserung umwandeln kann.
Behebung, Retest und Rückkehr zum Normalbetrieb
Behebung und Retest bilden den Abschlussprozess, der eine nachgewiesene Schwachstelle in eine validierte Verbesserung umwandelt. Die Rückkehr zum Normalbetrieb ist Teil desselben Prozesses: Testzugriff, kontrollierte Szenarien und gesammelte Beweise dürfen nicht zu neuen, dauerhaften Risiken werden.
Diese letzte Phase entscheidet darüber, ob der Einsatz Risiken tatsächlich reduziert oder lediglich einen Bericht erzeugt. Ein Befund ohne Eigentümer, Behebungspfad und Validierungsbedingung kann offen bleiben, während derselbe Angriffspfad im Produktivbetrieb weiterhin besteht.
Bevor der Test beginnt, sollte festgelegt werden, wie Befunde in Engineering-, Cloud-, Wallet-Betriebs- oder Geschäftskontroll-Workflows einfließen; wer die Behebung verantwortet; und welche Befunde einen Retest erfordern. Zum Abschluss werden temporäre Testidentitäten, Berechtigungen und kontrollierte Szenarien in ihre vorgesehene Konfiguration zurückversetzt, und die Diensteigentümer bestätigen, dass relevante Integritätsindikatoren innerhalb des erwarteten Bereichs bleiben. Der Abschlussbericht verknüpft jeden Befund mit seinem Nachweis, seiner Auswirkung, seinem Eigentümer, dem Behebungsplan und der Retest-Bedingung. Für ein kontrolliertes transaktionsbezogenes Szenario verknüpft er zudem den Workflow-Verweis, die Testidentität, den Zeitstempel, den Genehmigungsnachweis und den resultierenden Ledger-Eintrag; jeglicher temporäre Zugriff, jede Genehmigung oder Testkonfiguration, die für das Szenario erstellt wurde, wird stillgelegt. Beweise werden nur für den vereinbarten Zeitraum aufbewahrt und anschließend sicher vernichtet oder zurückgegeben.
Das Ergebnis ist keine Schwachstellenliste, sondern ein getestetes, behobenes und erneut getestetes Set an Kontrollen, das die nächste Betriebsentscheidung der Institution unterstützen kann.
Fazit
Die Vorbereitung von Blockchain-Penetrationstests ist eine institutionelle Aufgabe. Die Institution definiert Ziel, Betriebskontext, Befugnis, Dienstbeschränkungen und Reaktionsmodell; das Testteam wendet auf diese vorbereitete Umgebung eine gegnerische Validierung an.
Mit diesen Elementen wird ein Penetrationstest-Einsatz zu mehr als einer technischen Übung. Er wird zu einem kontrollierten Weg, um zu verstehen, wie die eingesetzten Systeme, Personen und Prozesse der Institution einem Angriff standhalten.
BlockSec unterstützt Institutionen dabei, diesen Prozess vorzubereiten und durchzuführen: den Umfang festlegen, die Betriebsumgebung kartieren, die RoE und Produktivsicherheitsvorkehrungen etablieren und Befunde in behobene und erneut getestete Kontrollen umwandeln. Um die Einsatzregeln und Produktivsicherheitskontrollen für Ihren nächsten Test zu planen, fordern Sie ein Scoping-Gespräch an; weitere Informationen sind auf Anfrage erhältlich.
Weiter geht es mit der Serie:
Ebenfalls in dieser Serie, demnächst veröffentlicht:
- Teil 5: Autorisierungs- und Signatursicherheit: Web, dApps und
- 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 Börsen-Ledgern: Diebstahlpfade und Datenebenen-Logik
Die Themenseite Blockchain Penetration Testing bietet die Übersicht auf Einsatzebene.
Quellen
Nummeriert in der Reihenfolge des ersten Auftretens.
- National Institute of Standards and Technology, Rules of Engagement (ROE), CSRC-Glossar.
- Europäische Union, Verordnung (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Artikel 26.
- Hong Kong Securities and Futures Commission, Circular to Licensed Virtual Asset Trading Platform Operators on Custody of Virtual Assets (15. August 2025).
