1. Web-Beweise 2026 – warum ISO 27037 zum Goldstandard wurde
Bei den meisten digitalen Streitigkeiten, die 2026 zu einem Rechtsstreit führen, lebt der entscheidende Beweis auf einer Webseite. Ein verleumderischer Social-Media-Beitrag, ein gefälschtes Angebot auf einem Online-Marktplatz, die Marketingseite eines Wettbewerbers mit einer problematischen Behauptung, eine außerhalb offizieller Kanäle geführte Finanzkommunikation, eine Aussage einer Führungskraft, die einer eidesstattlichen Erklärung widerspricht – all dies ist Webinhalt. Die technische und rechtliche Herausforderung ist über diese Szenarien hinweg identisch: Wie sichert man einen dynamischen, flüchtigen, von Dritten kontrollierten Inhalt so, dass er einer gegnerischen Prüfung vor Gericht standhält?
Der Instinkt vieler Praktiker ist, einen Screenshot aufzunehmen. Der Screenshot befriedigt das unmittelbare Bedürfnis, etwas zu erfassen, und für Zwecke mit geringem Einsatz (interne Aufzeichnungen, Due Diligence, Journalismus) ist er oft angemessen. Doch für Beweise, die auf eine bestrittene Zulässigkeit stoßen könnten – Zivilprozess, aufsichtsrechtliche Durchsetzung, Strafverfahren, internationale Schiedsverfahren –, versagt ein reiner Screenshot bei praktisch jedem Test, den ein erfahrener gegnerischer Anwalt aufwirft. Er trägt kein kryptografisches Siegel, das den visuellen Inhalt mit etwas Überprüfbarem verknüpft. Er trägt keinen qualifizierten Zeitstempel eines Vertrauensdiensteanbieters. Er enthält keine Metadaten über den Server, der den Inhalt erzeugt hat. Er lässt sich mit Verbrauchersoftware in Sekunden verändern. Er kann von einem unabhängigen Sachverständigen nicht reproduziert werden.
ISO/IEC 27037:2012 ist der internationale Standard, der diese Lücken behandelt. 2012 gemeinsam von ISO und IEC veröffentlicht, legt er Leitlinien für die Identifizierung, Sammlung, Erfassung und Aufbewahrung potenzieller digitaler Beweise fest. Er gilt gleichermaßen für physische Geräte und für Live-Webumgebungen und ist zum meistzitierten internationalen Standard für die Zulässigkeit digitaler Beweise in der europäischen und amerikanischen forensischen Fachliteratur geworden. Gerichte und gerichtliche Sachverständige erwarten zunehmend, dass digitale Beweise in einer mit dem Standard vereinbaren Weise erfasst werden, und Gegner führen die ISO-27037-Konformität zunehmend als Maßstab an, wenn sie die Methodik gegnerischer Beweise anfechten.
ISO 27037 auf Web-Beweise anzuwenden, ist keine triviale Übersetzungsübung. Der Standard wurde mit Blick auf eine Festplatte geschrieben – ein statisches physisches Medium, das abgeschaltet, schreibgeschützt und Bit für Bit abgebildet werden kann. Eine Live-Webseite ist das Gegenteil davon. Sie existiert nur als Live-Interaktion zwischen Client, Server, Netzwerkinfrastruktur, Content Delivery Network, Zertifizierungsstellen, JavaScript-Laufzeit und Nutzerzustand. Es gibt nichts abzuschalten, nichts physisch zu beschlagnahmen, und der Inhalt kann sich ändern, bevor Sie die Erfassung abgeschlossen haben. Dieser Leitfaden zeigt, wie sich die Kernprinzipien des Standards 2026 in die operative Praxis für Web-Beweise übersetzen.
Wer diesen Leitfaden zu Ende liest, weiß genau, was ISO 27037 für die Erfassung von Web-Beweisen verlangt, welche konkreten technischen Elemente erfasst werden müssen, um den Standard zu erfüllen, warum Screenshots versagen und was sie ersetzt, wie der dreiphasige forensische Ablauf umzusetzen ist und wie sich qualifizierte eIDAS-Zeitstempel mit Bitcoin-OpenTimestamps-Verankerung für Beweise kombinieren lassen, die über EU- und globale Rechtsordnungen hinweg Bestand haben. Für eine tiefere Behandlung der zugrunde liegenden Kategorie der digitalen Beweisplattform siehe unseren vollständigen Leitfaden zu digitalen Beweissystemen und unsere Analyse, warum Screenshots nicht ausreichen.
2. ISO/IEC 27037:2012 – Anatomie des Standards
ISO/IEC 27037:2012, förmlich betitelt „Informationstechnik – Sicherheitsverfahren – Leitlinien für die Identifizierung, Sammlung, Erfassung und Aufbewahrung digitaler Beweise“, wird gemeinsam von der Internationalen Organisation für Normung und der Internationalen Elektrotechnischen Kommission herausgegeben. Der Standard umfasst etwa 40 Seiten normativer Leitlinien und stellt über ein Jahrzehnt Konsensarbeit unter forensischen Sachverständigen, Strafverfolgungsbehörden und gerichtlichen Praktikern aus mehreren Rechtsordnungen dar.
Die vier operativen Prozesse
Der Standard strukturiert den Umgang mit digitalen Beweisen in vier verschiedene Prozesse, die nacheinander ablaufen. Die Identifizierung ist der Prozess, potenzielle digitale Beweise an einem Tatort zu erkennen, einschließlich der Bewertung von Priorität und Verlustrisiko. Die Sammlung ist der Prozess, physische Gegenstände zu erlangen, die digitale Beweise enthalten können. Die Erfassung ist der Prozess, digitale Kopien zu erstellen, die für eine Untersuchung geeignet sind. Die Aufbewahrung ist der Prozess, die Integrität des Beweises über seinen gesamten Lebenszyklus zu wahren. Für Web-Beweise verschwimmen die Grenzen zwischen diesen Prozessen – es gibt keinen physischen Gegenstand zu sammeln, und Identifizierung und Erfassung geschehen oft gleichzeitig –, doch die zugrunde liegenden Prinzipien gelten weiterhin.
Umfang und Grenzen des Standards
ISO/IEC 27037 legt fest, was getan werden soll, nicht wie es mit bestimmten Werkzeugen zu tun ist. Er schreibt Prinzipien wie Nachprüfbarkeit und Reproduzierbarkeit vor, überlässt aber die Umsetzungsentscheidungen dem Praktiker. Dies ist beabsichtigt – Forensiktechnik entwickelt sich schneller, als internationale Standards überarbeitet werden können –, doch es bedeutet, dass zwei Praktiker, die dem Standard folgen, unterschiedliche Artefakte und Prozesse erzeugen können. Der Maßstab für Konformität ist nicht, ob die Artefakte einer Referenzimplementierung entsprechen, sondern ob die Arbeit die Prinzipien in einer Weise erfüllt, die ein unabhängiger Dritter überprüfen kann.
Verwandte und unterstützende Standards
ISO/IEC 27037 steht innerhalb einer breiteren Familie forensischer Standards. ISO/IEC 27041:2015 behandelt die Gewährleistung von Methoden zur Vorfalluntersuchung. ISO/IEC 27042:2015 befasst sich mit der Analyse und Auslegung digitaler Beweise. ISO/IEC 27043:2015 behandelt Prinzipien und Prozesse der Vorfalluntersuchung. ISO/IEC 27050 (mehrere Teile) befasst sich mit der elektronischen Beweiserhebung. Für die langfristige Web-Archivierung legt ISO 28500:2017 das WARC-Format fest, das das Internet Archive und andere Bewahrungsinstitutionen verwenden. Ein ausgereifter forensischer Betrieb verweist typischerweise auf ISO 27037 als den zentralen Erfassungsstandard und zieht die anderen für verwandte Prozesse heran.
Anerkennung durch Gerichte und Aufsichtsbehörden
Auf ISO/IEC 27037 wird in der forensischen Praxis in den meisten EU-Mitgliedstaaten, dem Vereinigten Königreich, Australien, Kanada und einer wachsenden Zahl bündnisfreier Rechtsordnungen verwiesen. Die Education-for-Justice-Module des Büros der Vereinten Nationen für Drogen- und Verbrechensbekämpfung (UNODC) führen ihn als den am häufigsten zitierten internationalen Standard für die Zulässigkeit elektronischer Beweise an. Obwohl nicht alle Gerichte den Standard ausdrücklich zitieren, sind die von ihm vorgeschriebenen Methoden – insbesondere die Dokumentation der Beweiskette und kryptografische Integritätskontrollen – zu faktischen Erwartungen an ernsthafte digitale Beweise in streitigen Verfahren geworden. Ein Rechtsbeistand, der die ISO-27037-Konformität seiner Beweiserfassung nachweisen kann, hat bei Authentizitätsanfechtungen einen erheblichen Verteidigungsvorteil.
3. DEFR und DES – die zwei forensischen Operatorrollen
ISO/IEC 27037 führt zwei spezifische Operatorrollen mit unterschiedlichen Verantwortlichkeiten und Qualifikationen ein. Diese Rollen zu verstehen und zu wissen, welche Rolle für eine bestimmte Aufgabe gilt, ist grundlegend für die Organisation einer verteidigungsfähigen Erfassung von Web-Beweisen.
DEFR – der Digital Evidence First Responder
Der Digital Evidence First Responder (DEFR) ist der geschulte, befugte Operator, der als Erster an einem Tatort tätig wird, an dem digitale Beweise vorhanden sein können. Zu den Verantwortlichkeiten des DEFR gehören die Identifizierung potenzieller Beweise, die Sicherung des Tatorts, die Wahrung der Beweisintegrität und die Dokumentation erster Handlungen. Für Web-Beweise ist der DEFR typischerweise die erste Person, die erkennt, dass eine Webseite Material enthält, das in nachfolgenden Verfahren benötigt werden könnte – oft ein Anwalt, eine Rechtsanwaltsfachangestellte, ein Compliance-Verantwortlicher, ein Ermittler oder ein technischer Mitarbeiter, der auf einen Vorfall reagiert. Der DEFR benötigt keine fortgeschrittene digitalforensische Expertise, muss aber geschult und befugt sein, eine Erst-Erfassung durchzuführen, und muss dokumentierte, seiner Schulung angemessene Verfahren befolgen.
DES – der Digital Evidence Specialist
Der Digital Evidence Specialist (DES) ist der leitende Experte mit fortgeschrittenen Fähigkeiten in Betriebssystemen, Netzwerktechnik, Anwendungsforensik und den für den Fall relevanten spezifischen Technologien. Der DES bearbeitet komplexe Erfassungs- und Analyseaufgaben, die die Schulung des DEFR übersteigen, führt die technische Verifikation erfasster Beweise durch, erstellt technische Berichte und kann in Verfahren als Sachverständiger auftreten. Für Web-Beweise ist der DES typischerweise ein zertifizierter Digitalforensiker, ein gerichtlich bestellter technischer Sachverständiger oder eine interne forensische Kapazität mit den entsprechenden Qualifikationen.
Wie sich die Rollen in der modernen Web-Beweisarbeit teilen
In der traditionellen Forensik physischer Geräte ist die Teilung zwischen DEFR und DES unkompliziert: Der DEFR sichert das Gerät, der DES führt die eingehende Untersuchung durch. Für Web-Beweise ist die Teilung oft weniger klar. Ein geübter DEFR, der eine moderne forensische Erfassungsplattform nutzt, kann eine vollständig ISO-27037-konforme Erfassung ohne DES-Beteiligung durchführen, weil die Plattform die technische Komplexität (Serialisierung des gerenderten DOM, MHTML-Verpackung, SSL-Zertifikatserfassung, Hash-Berechnung, Anwendung des qualifizierten Zeitstempels) automatisch bewältigt. Die DES-Rolle kommt dann für Verifikation, sachverständige Berichterstattung und gegnerische Reaktion ins Spiel – nicht für die routinemäßige Erfassung selbst. Dies ist eine erhebliche operative Effizienz für Rechtsteams und Compliance-Organisationen.
Dokumentation der Rollenzuweisung in der Beweiskette
Wer jeden Schritt durchführt, muss in der Dokumentation der Beweiskette benannt werden. Das Erfassungsprotokoll sollte den Namen des Operators, die Rolle (DEFR oder DES), die Qualifikationen oder Schulung und die konkret ergriffenen Handlungen festhalten. Wenn ein DEFR eine automatisierte Plattform nutzt, sollte das Protokoll dennoch den für die Auslösung und Überwachung der Erfassung verantwortlichen menschlichen Operator benennen. Wenn ein DES für Verifikation oder Analyse hinzugezogen wird, sollte seine Beteiligung gesondert dokumentiert werden. Diese Aufteilung der Verantwortung wird in streitigen Verfahren besonders wichtig, in denen die Gegenseite die Qualifikationen jeder Person prüfen kann, die den Beweis gehandhabt hat.
4. Die vier Kernprinzipien – Nachprüfbarkeit, Wiederholbarkeit, Reproduzierbarkeit, Begründbarkeit
Die Abschnitte 5.3 und 5.4 von ISO/IEC 27037 legen vier Kernprinzipien fest, die bei jeder Erfassung digitaler Beweise erfüllt sein müssen. Dies sind keine anzustrebenden Ziele oder bewährten Verfahren – es sind normative Anforderungen. Wenn auch nur ein Prinzip versagt, weist der resultierende Beweis eine strukturelle Schwäche auf, die die Gegenseite ausnutzen kann. Die Prinzipien gelten für die Erfassung von Web-Beweisen mit voller Wirkung.
Nachprüfbarkeit – jede Handlung nachvollziehbar
Die Nachprüfbarkeit verlangt, dass jede während der Erfassung ergriffene Handlung durch einen unabhängigen Dritten nachvollziehbar und überprüfbar ist. Für Web-Beweise bedeutet dies ein vollständiges Protokoll der Erfassungssitzung: wer sie ausgelöst hat, wann, mit welchem Werkzeug, gegen welche URL, mit welcher Konfiguration und mit welchen Zwischenergebnissen. Das Protokoll muss manipulationssicher sein und über den gesamten Beweislebenszyklus aufbewahrt werden. Ein bloßer Screenshot versagt bei der Nachprüfbarkeit vollständig – es gibt kein Protokoll darüber, wie der Screenshot erstellt wurde, von wem oder in welcher Umgebung. Eine moderne forensische Erfassungsplattform erfüllt die Nachprüfbarkeit, indem sie ein Append-Only-Register jeder Erfassung mit kryptografischem Schutz gegen nachträgliche Veränderung führt.
Wiederholbarkeit – gleiche Verfahren ergeben gleiche Ergebnisse
Die Wiederholbarkeit verlangt, dass dieselben Verfahren, die an denselben Daten unter denselben Bedingungen durchgeführt werden, dieselben Ergebnisse liefern. Für Web-Beweise ist dies vielschichtiger als für physische Medien – das Live-Web sind nicht zweimal dieselben Daten –, doch das Prinzip gilt weiterhin für das erfasste Artefakt. Das erfasste DOM, MHTML, Zertifikat und die Metadaten müssen, einmal erfasst und versiegelt, aus dem versiegelten Beweis reproduzierbar sein. Wenn das Beweisbündel beschädigt oder das kryptografische Siegel gebrochen ist, versagt die Wiederholbarkeit. Die Verwendung standardisierten Hashings (SHA-256), offener Archivformate (MHTML, WARC) und dokumentierter Serialisierungsverfahren unterstützt die Wiederholbarkeit.
Reproduzierbarkeit – unabhängige Untersuchung ergibt dieselben Schlüsse
Die Reproduzierbarkeit verlangt, dass ein anderer Untersucher mit anderen Werkzeugen zu denselben Schlüssen gelangt, wenn er von denselben Ausgangsdaten ausgeht. Für Web-Beweise bedeutet dies, dass ein Sachverständiger eines Dritten, dem die ursprüngliche Ziel-URL und der Erfassungszeitpunkt vorliegen, einen unabhängigen Prüfprozess durchführen und zu konsistenten Schlüssen darüber gelangen könnte, was die Seite anzeigte. Dies ist für Live-Webinhalte schwierig (die Seite kann sich geändert haben), doch das erfasste Artefakt sollte in Formaten vorliegen, die jeder qualifizierte Untersucher mit Standardwerkzeugen analysieren kann – nicht in proprietären Containerformaten, die den Beweis an die Software eines bestimmten Anbieters binden.
Begründbarkeit – jede technische Entscheidung verteidigungsfähig
Die Begründbarkeit verlangt, dass jede während der Erfassung getroffene technische Entscheidung verteidigungsfähig ist – dass der Praktiker erklären kann, warum jeder Schritt unternommen wurde und warum der gewählte Ansatz angemessen war. Für Web-Beweise bedeutet dies, dokumentierte Gründe für das konkret verwendete Werkzeug, die gewählten Erfassungsparameter, die gewählte Zeitstempelquelle, den angewandten Hash-Algorithmus und das verwendete Speicherformat zu haben. Die Gegenseite kann jede dieser Entscheidungen in der Kreuzbefragung oder in technischen Einwänden prüfen. Ein Praktiker, der eine Entscheidung nicht verteidigen kann – selbst wenn die Entscheidung vernünftig war –, hat Munition für eine Authentizitätsanfechtung geliefert.
Wie die Prinzipien in der Praxis zusammenwirken
Die vier Prinzipien verstärken einander, können aber auch Spannungen erzeugen. Maximale Nachprüfbarkeit kann detaillierte Protokolle erfordern, die den Ablauf verkomplizieren. Maximale Reproduzierbarkeit kann offene Formate erfordern, denen einige Funktionen proprietärer Alternativen fehlen. Der geübte Praktiker balanciert diese Spannungen durch dokumentierte Entscheidungen aus: Er wählt nach Möglichkeit standardisierte offene Formate, akzeptiert Leistungseinbußen zugunsten der Beweisintegrität und führt Protokolle in der angemessenen Granularität. Der Maßstab ist nicht die Perfektion bei jedem Prinzip einzeln, sondern eine kohärente, verteidigungsfähige Methodik, die alle vier zusammen erfüllt.
5. Warum Screenshots jeden ISO-27037-Test nicht bestehen
Es lohnt sich, ausdrücklich zu benennen, warum gewöhnliche Screenshots – erstellt mit der PrintScreen-Funktion des Betriebssystems oder einem Bildschirmaufnahmewerkzeug – die Anforderungen von ISO 27037 nicht erfüllen. Jedes der vier Kernprinzipien erzeugt einen gesonderten Versagensmodus für screenshotbasierte Beweise.
Screenshots versagen bei der Nachprüfbarkeit
Ein Betriebssystem-Screenshot erzeugt eine Bilddatei mit minimalen Metadaten: Dateiname, Erstellungszeitstempel aus dem lokalen Dateisystem, Bildabmessungen und möglicherweise Daten im EXIF-Stil. Es gibt kein manipulationssicheres Protokoll darüber, wie der Screenshot erstellt wurde. Es gibt keine Aufzeichnung der URL, die auf dem Bildschirm war, des verwendeten Browsers, des Nutzerkontos, des Netzwerkpfads oder des Servers, der den angezeigten Inhalt erzeugte. Die Bilddatei selbst kann je nach Veränderung in jedem Bildeditor verändert werden, ohne eine forensisch erkennbare Spur zu hinterlassen. Die Nachprüfbarkeit versagt, weil der Prüfpfad nicht existiert.
Screenshots versagen bei der Wiederholbarkeit
Ein Screenshot erfasst die visuelle Darstellung in einem Moment, ohne Aufzeichnung der zugrunde liegenden Daten, des Netzwerkzustands oder der Umgebungsbedingungen. Es gibt keine Möglichkeit für dieselbe Person, die Erfassung an denselben Daten zu wiederholen – der Screenshot ist auf keine reproduzierbare Weise an den Ausgangsinhalt gebunden. Wenn die ursprüngliche Seite verschwunden ist, ist der Screenshot das einzige Artefakt, ohne Weg zur Verifikation. Die Wiederholbarkeit versagt, weil es nichts zu wiederholen gibt.
Screenshots versagen bei der Reproduzierbarkeit
Ein unabhängiger Untersucher kann einen Screenshot nicht nutzen, um zu überprüfen, was die Seite tatsächlich enthielt. Das Bild zeigt Pixel, doch diese Pixel könnten von jeder Rendering-Engine mit jeder Eingabe erzeugt worden sein. Es gibt kein SSL-Zertifikat zur Überprüfung der Serveridentität. Es gibt kein DOM zur Bestätigung der zugrunde liegenden Struktur. Es gibt keinen Netzwerkmitschnitt zur Bestätigung, dass der Inhalt tatsächlich von der behaupteten Domain ausgeliefert wurde. Ein Untersucher, der gebeten wird, einen Screenshot zu überprüfen, kann nur bestätigen, dass die Bilddatei bestimmte Pixel enthält – nicht, dass diese Pixel den historischen Zustand einer Webressource genau wiedergeben.
Screenshots versagen bei der Begründbarkeit
Wenn ein Praktiker zur Entscheidung befragt wird, einen Screenshot statt einer forensischen Erfassung zu verwenden, hat er begrenzte verteidigungsfähige Antworten. Die Entscheidung tauscht beweisrechtliche Strenge gegen Bequemlichkeit ein, und dieser Kompromiss ist 2026 zunehmend unhaltbar, da forensische Erfassungswerkzeuge weithin verfügbar, gut dokumentiert und nicht wesentlich teurer sind als die rechtlichen Kosten einer einzigen Authentizitätsanfechtung. Die Begründbarkeit versagt, weil die Methodik sich nicht aus ihrer Sache heraus verteidigen lässt – nur mit dem Verweis auf bisherige Praxis, was eine schwächer werdende Verteidigung ist, während sich die Standarderwartung weiterentwickelt.
Was den Screenshot ersetzt
Die ISO-27037-konforme Erfassung von Web-Beweisen ersetzt den Screenshot durch eine strukturierte forensische Erfassung mit mehreren Elementen. Der nächste Abschnitt beschreibt die sieben Elemente im Detail, die jede ISO-27037-konforme Web-Erfassung enthalten muss. Dies ist kein optionales bewährtes Verfahren – es ist die operative Basislinie für Beweise, die 2026 einer gegnerischen Prüfung standhalten.
6. Die sieben wesentlichen Elemente der forensischen Web-Erfassung
Eine an ISO/IEC 27037 ausgerichtete forensische Web-Erfassung umfasst sieben verschiedene technische Elemente. Jedes schließt eine bestimmte Angriffslinie, die die Gegenseite andernfalls ausnutzen könnte. Keines kann ein anderes ersetzen – sie wirken als gestaffelte Verteidigung, in der jedes Element ein anderes beweisrechtliches Risiko behandelt.
Element 1 – Das gerenderte DOM
Das Document Object Model (DOM) ist die im Arbeitsspeicher liegende Darstellung der Seite, nachdem der Browser das HTML geparst und etwaiges JavaScript ausgeführt hat. Für moderne Webseiten – insbesondere Single-Page-Anwendungen, Marktplätze mit dynamischen Angeboten, Social-Media-Feeds und interaktive Anwendungen – ist das gerenderte DOM das, was der Nutzer tatsächlich sieht, und unterscheidet sich oft stark vom rohen HTML, das der Server ursprünglich sendete. Eine forensische Erfassung serialisiert das gerenderte DOM (typischerweise über outerHTML des Dokumentwurzelelements) nach Abschluss des Renderings. Dies wird in Abschnitt 7 im Detail behandelt.
Element 2 – Das MHTML- oder WARC-Archiv
Das MHTML-Archiv (MIME HTML) verpackt die Seite zusammen mit allen abhängigen Ressourcen – CSS, Bildern, JavaScript, Schriftarten und eingebetteten Medien – in eine einzige, in sich geschlossene Datei, die ein Untersucher noch Jahre später offline wieder öffnen kann. WARC (ISO 28500:2017) ist das alternative Archivformat, das große Web-Archivierungsinstitutionen verwenden. Beide Formate sind offen und standardisiert. Die Wahl zwischen ihnen hängt vom Anwendungsfall ab (behandelt in Abschnitt 8). Für die ISO-27037-Konformität kommt es darauf an, dass die erfasste Seite als in sich geschlossenes, überprüfbares Artefakt unabhängig von der Live-Quelle existiert, die sich ändern oder verschwinden kann.
Element 3 – Das SSL/TLS-Zertifikat
Das serverseitige SSL/TLS-Zertifikat ist das X.509-Dokument, das der Server während des kryptografischen Handshakes präsentiert. Die Erfassung dieses Zertifikats samt seiner vollständigen Vertrauenskette bis zu einer anerkannten Wurzelzertifizierungsstelle (Root CA) bindet den erfassten Inhalt kryptografisch an die verifizierte Identität der Domain, die ihn ausgeliefert hat. Ohne dieses Element kann die Gegenseite argumentieren, die Seite sei von einem Man-in-the-Middle-Angreifer, einem Klon-Server mit gekapertem DNS oder einer für den Anlass eingerichteten Entwicklungsumgebung ausgeliefert worden. Mit diesem Element wird die Serverzuordnung zu einer kryptografischen Tatsache statt zu einer verbalen Behauptung.
Element 4 – Server-IP und DNS-Auflösung
Die DNS-Auflösung im Moment der Erfassung – A- und AAAA-Einträge, CNAME-Ketten, NS-Einträge und, wo relevant, ein WHOIS-Schnappschuss – beweist, dass die Domain in diesem konkreten Augenblick auf eine bestimmte IP-Adresse und damit auf eine bestimmte Maschine an einem bestimmten geografischen Ort zeigte. Dies wird entscheidend, wenn eine Domain später übertragen, beschlagnahmt oder bereinigt wird. Für die Durchsetzung gegen Fälschungen, Phishing-Ermittlungen und koordinierte Verleumdungskampagnen bestimmen der aufgelöste Serverstandort und die ASN oft die Zuständigkeit und die verfahrensrechtliche Strategie. Die Erfassung des DNS zum Erfassungszeitpunkt friert Informationen ein, die innerhalb von Tagen verschwunden sein könnten.
Element 5 – HTTP-Header und Netzwerkmitschnitt
Über die aufgelöste IP hinaus verlangt die ISO-27037-Konformität die Erfassung der HTTP-Anfrage- und Antwort-Header (die die Serversoftware-Identifikation, Caching-Direktiven, Sicherheits-Header und Antwortcodes tragen) sowie des Live-Netzwerkmitschnitts der Erfassungssitzung (aufgezeichnet über einen Paketanalysator oder forensischen Proxy). Der Netzwerkmitschnitt dient einem bestimmten beweisrechtlichen Zweck: Er beweist das Fehlen unerwarteter Weiterleitungen, JavaScript-Einschleusungen oder Veränderungen während der Übertragung im Verlauf der Erfassung. SWGDE 21-F-001 verlangt dieses Element ausdrücklich für eine verteidigungsfähige Web-Erfassung.
Element 6 – SHA-256-Hash-Manifest
Jedes erfasste Artefakt muss einzeln mittels SHA-256 gehasht werden, und es muss ein Manifest erstellt werden, das alle Artefakte mit ihren Hashes auflistet. Das Manifest selbst wird dann gehasht und liefert einen kryptografischen Fingerabdruck des gesamten Beweisbündels. Dies ist der Grundpfeiler der Integritätsprüfung – zwei Parteien, die einen einzigen Hash-Wert vergleichen, können mit mathematischer Gewissheit bestätigen, ob sie identische Bündel besitzen. Element 6 wird in Abschnitt 11 weiter ausgeführt.
7. Gerendertes DOM – erfassen, was Nutzer tatsächlich sehen
Unter den sieben Elementen verdient das gerenderte DOM eine gesonderte Behandlung, weil es sowohl das technisch subtilste als auch das von Praktikern mit unzureichenden Werkzeugen am häufigsten falsch behandelte ist. Ein Versäumnis, das gerenderte DOM korrekt zu erfassen, bedeutet, eine Seite zu erfassen, die nicht dem entspricht, was der Nutzer tatsächlich sah – was den gesamten beweisrechtlichen Zweck vereitelt.
Was das DOM ist und wie es sich vom rohen HTML unterscheidet
Wenn ein Browser eine Webseite lädt, erhält er rohes HTML vom Server. Für statische Seiten der späten 1990er- und frühen 2000er-Jahre war dieses rohe HTML im Wesentlichen das, was der Nutzer sah. Moderne Webanwendungen funktionieren sehr anders. Der Browser parst das HTML und führt dann etwaigen im oder mit der Seite referenzierten JavaScript-Code aus. Das JavaScript verändert das DOM – fügt Elemente hinzu, entfernt Elemente, ruft Daten von APIs ab, rendert Inhalte aus internen Datenstrukturen und reagiert auf Nutzerinteraktionen. Das endgültige DOM, nachdem alles JavaScript ausgeführt wurde, ist die im Arbeitsspeicher liegende Darstellung der Seite, die das erzeugt, was der Nutzer auf dem Bildschirm sieht. Das rohe HTML und das gerenderte DOM können radikal verschieden sein.
Warum dies für rechtliche Beweise von Bedeutung ist
Betrachten Sie eine typische moderne Marktplatzseite, die ein gefälschtes Produkt anzeigt. Das rohe HTML kann nur eine Navigationsleiste, ein Produktcontainer-Element und JavaScript enthalten, das die Produktdaten von einer internen API abruft. Keine der eigentlichen Produktinformationen – Titel, Beschreibung, Preis, Verkäuferangaben, Bilder – erscheint im rohen HTML. All dies wird erst nach der Ausführung des JavaScripts in das DOM gerendert. Eine forensische Erfassung, die nur das rohe HTML speichert, erfasst im Wesentlichen nichts von beweisrechtlichem Wert. Eine Erfassung, die nur einen Screenshot speichert, erfasst das Erscheinungsbild, aber nicht die zugrunde liegende Struktur, die beweist, was tatsächlich da war. Nur eine Erfassung des gerenderten DOM verbindet strukturelle Treue mit inhaltlicher Vollständigkeit.
Die technische Mechanik der DOM-Erfassung
Die Erfassung des gerenderten DOM erfordert das Laden der Seite in einer kontrollierten Browserumgebung, das Abwarten des Renderingabschlusses (einschließlich etwaiger von JavaScript ausgelöster Netzwerkanfragen) und dann die Serialisierung des DOM durch Zugriff auf die outerHTML-Eigenschaft des Dokumentwurzelelements. Das Ergebnis ist ein HTML-Dokument, das den Zustand der Seite nach dem Rendering widerspiegelt. Das SHA-256-Hashing wird unmittelbar nach der Erfassung auf das serialisierte DOM angewandt und bindet den Hash an diesen konkreten Seitenzustand. Die Serialisierung sollte in einem forensischen Browser erfolgen, der in einer isolierten Umgebung läuft, nicht im täglichen Browser des Operators – der tägliche Browser trägt Cookies, Erweiterungen, Anmeldezustand und Cache, die beeinflussen, was der Server zurückgibt.
Randfälle – Infinite Scroll, Lazy Loading, Modals
Moderne Seiten weisen mehrere Randfälle auf, die die DOM-Erfassung erschweren. Infinite-Scroll-Feeds (Social Media, Marktplatzangebote) laden Inhalte, während der Nutzer scrollt; die Erfassung des DOM in einem Moment erfasst nur das, was zu diesem Moment geladen wurde. Lazy-geladene Bilder sind möglicherweise nicht heruntergeladen, wenn das DOM serialisiert wird. Modale Dialoge, Cookie-Zustimmungsbanner und Benachrichtigungs-Overlays können je nach Nutzerinteraktionszustand im DOM sein oder nicht. Der forensische Praktiker muss auf Grundlage dessen, welche Beweise der Fall erfordert, entscheiden, ob er die Seite scrollt, Banner schließt, Modals aufklappt oder die Seite in ihrem Ausgangszustand erfasst. Welche Entscheidung auch getroffen wird, sie sollte in der Aufzeichnung der Beweiskette dokumentiert werden.
8. MHTML und WARC – Archivformate im Vergleich
Sobald das DOM erfasst ist, lautet die nächste Frage, wie die gesamte Seite – einschließlich aller abhängigen Ressourcen – in einem in sich geschlossenen Format bewahrt wird, das ein Untersucher offline wieder öffnen kann. Zwei offene Standards dominieren diesen Bereich: MHTML und WARC. Sie dienen sich überschneidenden, aber nicht identischen Zwecken, und die Wahl zwischen ihnen beeinflusst die langfristige Verteidigungsfähigkeit.
MHTML – praktisch und nativ unterstützt
MHTML (MIME HTML) verpackt das HTML-Dokument samt aller abhängigen Ressourcen – Stylesheets, Bilder, Skripte, Schriftarten, eingebettete Medien – in eine einzige MIME-kodierte Datei. Das Format wird von Chromium-basierten Browsern (Chrome, Edge, Brave) nativ unterstützt und kann von diesen Browsern offline geöffnet werden. Das Einzeldateiformat macht MHTML leicht handhabbar, teilbar und in Beweispakete integrierbar. Für die episodische, gerichtstaugliche forensische Erfassung einzelner Seiten ist MHTML typischerweise ausreichend und deutlich einfacher zu handhaben als WARC.
WARC – der Archivstandard
WARC (Web ARChive), spezifiziert durch ISO 28500:2017, ist das Format, das das Internet Archive, die Library of Congress, die British Library und andere große Bewahrungsinstitutionen für die groß angelegte Web-Archivierung verwenden. WARC speichert HTTP-Anfrage- und -Antwort-Transaktionen in einem sequenzierten, für langfristige Archivierung und Massenverarbeitung optimierten Format. WARC-Dateien können große Mengen an Seiten effizient erfassen, und das Format ist der faktische Standard für die institutionelle Web-Bewahrung. Für umfangreiche, strukturierte forensische Vorgänge oder die langfristige Beweisaufbewahrung durch Unternehmen ist WARC oft die bevorzugte Wahl.
Die Wahl zwischen den beiden Formaten
Für die meiste Erfassung rechtlicher Beweise – einzelne Seiten oder kleine Seitensätze, erfasst als Reaktion auf konkrete Vorfälle oder für konkrete Rechtsstreitigkeiten – ist MHTML die praktische Wahl. Es erzeugt eine einzige Datei, die sich leicht an Schriftsätze anhängen, mit Mitanwälten teilen und vor Gericht präsentieren lässt. Für laufende Markenschutzprogramme, regulatorische Archivierung oder die unternehmensweite Web-Bewahrung kann WARC wegen seiner archivischen Robustheit und Massenverarbeitungseffizienz vorzuziehen sein. Eine forensische Plattform, die beide Formate unterstützt, bietet die größte Flexibilität. Welches Format auch verwendet wird, die Aufzeichnung der Beweiskette sollte die Formatwahl und den Grund dafür dokumentieren (das Begründbarkeitsprinzip).
Formatunabhängige bewährte Verfahren
Unabhängig vom Format gelten bestimmte Verfahren universell. Das Archiv sollte unmittelbar nach der Erstellung gehasht werden (SHA-256), wobei der Hash im Manifest festgehalten wird. Das Archiv sollte auf Vollständigkeit geprüft werden – gebrochene externe Verweise, fehlende Medien oder unvollständiges CSS deuten auf Erfassungsfehler hin, die möglicherweise erneut zu versuchen sind. Das Archiv sollte manipulationssicher gespeichert werden (typischerweise, indem es Teil eines hash-verketteten Beweisregisters ist oder mit einer qualifizierten elektronischen Signatur versiegelt wird). Und das Archiv sollte über den gesamten beweisrechtlichen Lebenszyklus aufbewahrt werden, mit regelmäßiger Prüfung, dass das Archiv lesbar bleibt und der Hash weiterhin verifiziert.
9. SSL/TLS-Zertifikatserfassung und Vertrauenskette
Das SSL/TLS-Zertifikat ist eines der am häufigsten übersehenen Elemente der forensischen Web-Erfassung und eines der wichtigsten, wenn es darum geht, den Beweis gegen Zuordnungsanfechtungen zu verteidigen. Ein ordnungsgemäß erfasstes Zertifikat verwandelt die Frage „welcher Server hat diesen Inhalt erzeugt“ von einer anfechtbaren Behauptung in eine kryptografische Tatsache.
Was das Zertifikat beweist
Wenn ein Browser sich mit einer HTTPS-Website verbindet, präsentiert der Server während des TLS-Handshakes ein X.509-Zertifikat. Das Zertifikat enthält den Domainnamen, den mit dem Server verknüpften öffentlichen Schlüssel, die ausstellende Zertifizierungsstelle (CA), den Gültigkeitszeitraum und eine digitale Signatur der CA, die all dies zusammenbindet. Der Browser validiert das Zertifikat, indem er die Signaturkette bis zu einer vertrauenswürdigen Wurzel-CA in seinem Vertrauensspeicher prüft. Gelingt die Validierung, akzeptiert der Browser, dass die Verbindung zum legitimen Server der benannten Domain besteht. Die Erfassung des Zertifikats zum Erfassungszeitpunkt friert diesen Nachweis ein: Im Moment der Erfassung betrieb die benannte Domain das erfasste Zertifikat, signiert von der erfassten CA-Kette.
Die vollständige Vertrauenskette
Die forensische Erfassung sollte nicht nur das Blattzertifikat (das der konkreten Domain ausgestellte) aufzeichnen, sondern die gesamte Vertrauenskette bis zur Wurzel-CA. Dies umfasst typischerweise das Blattzertifikat, ein oder mehrere Zwischen-CA-Zertifikate und die Identifikation der Wurzel-CA (die Wurzel selbst ist üblicherweise in Vertrauensspeichern vorinstalliert und wird nicht in der Kette übertragen). Die Fingerabdrücke aller Zertifikate der Kette sollten als SHA-256-Hashes erfasst werden. Diese vollständige Kette ist es, die eine spätere Verifikation ermöglicht – ein Untersucher kann unabhängig validieren, dass die erfasste Kette einen gültigen Signaturpfad zu einer anerkannten Wurzel-CA in seinem eigenen Vertrauensspeicher erzeugt.
OCSP- und CRL-Prüfung
Die moderne Zertifikatsvalidierung umfasst oft OCSP-Prüfungen (Online Certificate Status Protocol) oder CRL-Abfragen (Certificate Revocation List), um zu überprüfen, dass das Zertifikat nicht widerrufen wurde. Eine gründliche forensische Erfassung zeichnet die OCSP-Antwort oder den CRL-Status im Moment der Erfassung auf. Dies wird mitunter als OCSP-Staple erfasst – eine aktuelle, von der CA signierte OCSP-Antwort, die vom Server zusammen mit dem Zertifikat ausgeliefert wird. Der OCSP-/CRL-Nachweis beweist, dass das Zertifikat im Moment der Erfassung nicht nur formal gültig war, sondern auch nicht widerrufen worden war.
Abwehr von Zuordnungsanfechtungen
Ohne Zertifikatserfassung kann die Gegenseite mehrere Zuordnungsanfechtungen erheben, die schwer zu widerlegen sind. Die Seite könnte von einem Man-in-the-Middle-Angreifer ausgeliefert worden sein. Das DNS könnte gekapert worden sein und den Browser des Operators auf einen bösartigen Server gelenkt haben. Eine Test- oder Entwicklungsumgebung könnte unter einer ähnlichen URL eingerichtet worden sein. Mit Zertifikatserfassung fallen all diese Anfechtungen weg – die kryptografische Vertrauenskette bindet den Inhalt mit mathematischer Gewissheit an den legitimen Domaininhaber. Deshalb ist die Zertifikatserfassung keine optionale Verfeinerung, sondern eine strukturelle Anforderung für verteidigungsfähige Web-Beweise.
10. Netzwerkforensik – DNS, IP, Paketmitschnitt
Über das Zertifikat hinaus verlangt die ISO-27037-konforme Web-Erfassung die Bewahrung der Beweise auf Netzwerkebene, die belegen, dass der Inhalt tatsächlich vom behaupteten Server ausgeliefert wurde, ohne Veränderung während der Übertragung. Dies ist die Rolle der DNS-Einträge, der IP-Erfassung und des Paketmitschnitts.
DNS-Auflösungsnachweis
Im Moment der Erfassung sollte der Praktiker die DNS-Auflösung der Ziel-Domain aufzeichnen: A-Einträge (IPv4-Adressen), AAAA-Einträge (IPv6-Adressen), CNAME-Ketten (kanonische Namensaliase) und NS-Einträge (autoritative Nameserver). Für risikoreiche Fälle sollte ein WHOIS-Schnappschuss gesondert erfasst werden, der die Domainregistrierungsdaten einschließlich Registrant, Registrar, Registrierungsdatum und Ablauf aufzeichnet. Dieser DNS-Nachweis beantwortet die Frage, wohin die Domain im Moment der Erfassung zeigte – eine Information, die sich nach Beginn eines Rechtsstreits häufig ändert.
Server-IP-Zuordnung und ASN
Die aufgelöste IP-Adresse ist mit einer bestimmten Maschine, einem bestimmten Hosting-Anbieter (über Reverse DNS und die Abfrage der Autonomous System Number) und einem bestimmten geografischen Ort verknüpft. Für Durchsetzungsmaßnahmen gegen Fälschungen bestimmt dies oft, welche Rechtsordnung Autorität über den Serverbetreiber hat, welche rechtlichen Verfahren für Takedown oder Beschlagnahme gelten und welche internationale Zusammenarbeit (Budapester Übereinkommen, Rechtshilfeersuchen) nötig sein könnte. Die ASN der IP-Adresse identifiziert häufig den Hosting-Anbieter, was wiederum die Kundenbeziehung identifiziert, die einer Herausgabeanordnung unterliegen kann.
Live-Netzwerkmitschnitt
SWGDE 21-F-001 verlangt ausdrücklich, dass die Erfassung von Web-Beweisen eine Aufzeichnung des tatsächlichen Netzwerkverkehrs während der Erfassungssitzung umfasst. Dies wird typischerweise über einen Paketanalysator (wie tcpdump oder Wireshark) im Aufzeichnungsmodus oder über einen forensischen Proxy erreicht, der die HTTP-Transaktionen aufzeichnet. Der Netzwerkmitschnitt dient einem bestimmten beweisrechtlichen Zweck: Er beweist, dass der erfasste Inhalt tatsächlich vom Netzwerkendpunkt an der erfassten IP-Adresse ausgeliefert wurde, ohne unerwartete Weiterleitungen, ohne JavaScript-Einschleusung durch zwischengeschaltete Parteien und ohne Veränderung während der Übertragung durch die Netzwerkinfrastruktur. Für risikoreiche Fälle sollte der vollständige Paketmitschnitt in das Beweisbündel aufgenommen werden.
HTTP-Header und Sicherheitsindikatoren
Die HTTP-Anfrage- und -Antwort-Header tragen bedeutende forensische Informationen. Der Server-Header kann die Webserver-Software identifizieren. Cache-Header geben an, ob die Antwort vom Ursprung oder aus dem Cache kam. Sicherheits-Header (Content-Security-Policy, Strict-Transport-Security, X-Frame-Options) dokumentieren die Sicherheitshaltung der Quelle. Der Date-Header des Servers liefert eine zusätzliche Zeitreferenz (die mit der Lokalzeit und dem qualifizierten Zeitstempel auf Unstimmigkeiten verglichen werden kann, die auf eine Uhrmanipulation hindeuten). All dies sollte als Teil des forensischen Bündels erfasst werden.
11. SHA-256-Hashing-Strategien – Manifest, pro Datei und Append-Only-Kette
Kryptografisches Hashing ist der mathematische Kern des Integritätsschutzes nach ISO 27037. SHA-256, spezifiziert von NIST in FIPS 180-4, ist der branchenübliche Algorithmus und wird in Beweisrahmen praktisch jeder Rechtsordnung anerkannt. Die Frage für die forensische Web-Erfassung ist nicht, ob SHA-256 zu verwenden ist, sondern wie das Hashing über das Beweisbündel mit mehreren Elementen zu organisieren ist.
Hashing pro Datei
Jedes einzelne Artefakt im Beweisbündel sollte seinen eigenen, zum Erfassungszeitpunkt berechneten SHA-256-Hash haben. Dies umfasst die Serialisierung des gerenderten DOM, das MHTML- oder WARC-Archiv, jedes erfasste Zertifikat, die Netzwerkmitschnittdatei, den Screenshot, das Beweisketten-Protokoll und jede weitere Komponente. Hashes pro Datei ermöglichen die Verifikation einzelner Komponenten, ohne das gesamte Bündel neu zu hashen, und sie ermöglichen die Erkennung lokaler Beschädigung oder Veränderung.
Manifest-Hashing
Alle Hashes pro Datei sollten in einer Manifest-Datei zusammengeführt werden – einem strukturierten Dokument, das jedes Artefakt, seinen Dateinamen, seine Größe und seinen SHA-256-Hash auflistet. Das Manifest selbst wird dann gehasht und erzeugt einen einzigen SHA-256-Wert, der das gesamte Beweisbündel repräsentiert. Zwei Parteien, die identische Bündel besitzen, erzeugen denselben Manifest-Hash; jede Abweichung zeigt an, dass sich die Bündel unterscheiden. Der Manifest-Hash ist der Wert, der in qualifizierte elektronische Zeitstempel, signierte Quittungen und Beweisketten-Aufzeichnungen eingebettet werden sollte.
Append-Only-Hash-Kette
Für laufende forensische Vorgänge – bei denen neue Erfassungen im Laufe der Zeit einem Beweisspeicher hinzugefügt werden – ist der verteidigungsfähigste Ansatz eine Append-Only-Hash-Kette. Der Manifest-Hash jeder neuen Erfassung wird mit dem vorherigen Spitzen-Hash der Kette kombiniert, um einen neuen Spitzen-Hash zu erzeugen. Das Ergebnis ist eine Struktur, in der jede Veränderung oder Einfügung in der Kettenhistorie jeden nachfolgenden Hash ungültig machen würde. Dies ist dasselbe architektonische Prinzip, das Blockchains, Certificate-Transparency-Protokollen und Git-Repositorys zugrunde liegt. Für Unternehmen, die laufende Web-Beweisvorgänge unterhalten (Markenschutzprogramme, Compliance-Archive), bietet die Append-Only-Kette weit stärkere langfristige Integritätsgarantien als Hashes pro Erfassung allein.
Algorithmusauswahl und vorausschauende Planung
SHA-256 ist der aktuelle Standard, doch kryptografische Algorithmen werden schließlich schwächer oder veralten. Forensische Vorgänge mit langen Aufbewahrungshorizonten (Versicherungsstreitigkeiten über Jahrzehnte, laufende Durchsetzung geistigen Eigentums, regulatorische Archivierung) sollten die künftige Notwendigkeit eines Algorithmuswechsels berücksichtigen. Die Strategie besteht typischerweise darin, die ursprüngliche SHA-256-Hash-Kette zu behalten und das Bündel regelmäßig mit neueren Algorithmen (SHA-3, BLAKE2 oder Nachfolgealgorithmen) neu zu hashen und eine parallele Hash-Kette zu erstellen. eIDAS 2.0 (Verordnung (EU) 2024/1183) führte qualifizierte elektronische Archivierungsdienste speziell ein, um diese Herausforderung der langfristigen kryptografischen Bewahrung zu bewältigen.
12. Doppelte Verankerung – qualifizierte eIDAS-Zeitstempel und Bitcoin OpenTimestamps
Kryptografisches Hashing allein liefert Integrität, aber keine Chronologie. Um zu beweisen, dass ein bestimmter Manifest-Hash zu einem bestimmten Zeitpunkt existierte – und daher nicht nachträglich als Reaktion auf einen Rechtsstreit erzeugt wurde –, muss die forensische Erfassung an eine externe Zeitreferenz verankert werden, die die gegnerischen Parteien nicht manipulieren können. Hier kommt die doppelte Verankerung ins Spiel: die Kombination qualifizierter elektronischer eIDAS-Zeitstempel mit Bitcoin OpenTimestamps für Beweise, die Anfechtungen sowohl in EU- als auch in globalen Rechtsordnungen standhalten.
Qualifizierte eIDAS-Zeitstempel nach Artikel 41 und 42
Die Verordnung (EU) Nr. 910/2014 (eIDAS) bestimmt, dass qualifizierte elektronische Zeitstempel, ausgestellt von auf der EU-Vertrauensliste geführten qualifizierten Vertrauensdiensteanbietern (QTSPs), die gesetzliche Vermutung der Richtigkeit des von ihnen angegebenen Datums und der Uhrzeit sowie der Integrität der Daten, mit denen sie verknüpft sind, genießen. Diese Vermutung gilt in Verfahren vor den Gerichten aller 27 EU-Mitgliedstaaten sowie der EWR-Länder. Die technischen Anforderungen (Artikel 42) legen eine an UTC gekoppelte Quelle, eine manipulationssichere Verknüpfung und eine Signatur oder ein Siegel des QTSP fest. Für Web-Beweise, die vorrangig innerhalb von EU-Rechtsordnungen erfasst und verwendet werden, ist der qualifizierte eIDAS-Zeitstempel der Goldstandard als Zeitanker.
Bitcoin OpenTimestamps als globaler vertrauensfreier Anker
OpenTimestamps ist ein offener Standard (Protokoll im BIP-Stil), der beliebige Datenhashes über einen deterministischen Merkle-Baum-Aggregationsprozess an die Bitcoin-Blockchain verankert. Sobald ein Hash verankert ist, bestätigt der entsprechende Bitcoin-Block seine Existenz zum Zeitstempel des Blocks. Bitcoins verteilter Proof-of-Work-Konsens macht den Zeitstempel im Wesentlichen unmöglich rückwirkend zu manipulieren – den Zeitstempel zu verändern, würde erfordern, die gesamte Blockchain von diesem Block an neu zu schreiben, was rechnerisch nicht durchführbar ist. Die OpenTimestamps-Verankerung ist kostenlos, dezentral und global überprüfbar. Für Beweise, die in Nicht-EU-Rechtsordnungen verwendet werden sollen, oder für Fälle, in denen die Beweiskette langfristige Änderungen bei Vertrauensdiensteanbietern überdauern muss, bietet OpenTimestamps einen unabhängigen Zeitanker, der nicht davon abhängt, dass eine einzelne Organisation im Geschäft bleibt.
Warum beide kombinieren
Die beiden Verankerungsmechanismen haben ergänzende Eigenschaften. Qualifizierte eIDAS-Zeitstempel bieten eine automatische gesetzliche Vermutung in EU-Rechtsordnungen, hängen aber davon ab, dass bestimmte Vertrauensdiensteanbieter weiterhin tätig sind, dass die institutionelle Kontinuität der EU besteht und dass der Anerkennungsrahmen in Kraft bleibt. Bitcoin OpenTimestamps bieten einen kryptografischen Nachweis, der jede institutionelle Änderung überdauert, aber in keiner Rechtsordnung eine automatische gesetzliche Vermutung hat. Die Kombination beider erzeugt Beweise, die sowohl den verfahrensrechtlichen Vorteil der gesetzlichen Vermutung (eIDAS) als auch die institutionelle Unabhängigkeit des verteilten Konsenses (Bitcoin) besitzen. Für risikoreiche oder grenzüberschreitende Fälle bietet diese doppelte Verankerung Verteidigungsfähigkeit über EU- und globale Rahmen hinweg. Für eine tiefere Behandlung, wie qualifizierte Zeitstempel in der Praxis funktionieren, siehe unseren vollständigen Leitfaden zu qualifizierten eIDAS-Zeitstempeln.
Der technische Ablauf
Operativ funktioniert die doppelte Verankerung wie folgt. Nachdem der Manifest-Hash berechnet ist, übermittelt die Plattform den Hash an einen QTSP, der ein qualifiziertes Zeitstempel-Token zurückgibt (eine signierte Struktur, die den Hash an die zertifizierte Zeit des QTSP bindet). Der Hash wird dann an einen OpenTimestamps-Kalenderserver übermittelt, der ihn mit anderen Übermittlungen zu einem Merkle-Baum aggregiert, einen Wurzel-Hash berechnet und diesen Wurzel-Hash in eine Bitcoin-Transaktion einbettet. Sobald die Bitcoin-Transaktion bestätigt ist (typischerweise innerhalb einer Stunde, doch der Nachweis reift über nachfolgende Bestätigungen), kann der OpenTimestamps-Nachweis abgeleitet werden: eine Folge von Merkle-Hashes, die, auf den ursprünglichen Manifest-Hash angewandt, den Wurzel-Hash erzeugt, der im benannten Bitcoin-Block erscheint. Beide Nachweise – das eIDAS-Token und der OpenTimestamps-Nachweis – werden zusammen mit dem Beweisbündel gespeichert und können von jeder Partei mit geeigneten Werkzeugen verifiziert werden.
13. Der dreiphasige forensische Ablauf
Die Kombination all des Vorstehenden zu einem kohärenten operativen Prozess ergibt den dreiphasigen forensischen Ablauf: Vorbereitung, Erfassung und Versiegelung. Jede Phase hat konkrete Anforderungen, die sich aus ISO 27037 ableiten, und das Überspringen oder Verkürzen einer Phase untergräbt den resultierenden Beweis.
Phase 1 – Vorbereitung der Umgebung
Bevor eine URL berührt wird, bereitet der Operator die Erfassungsumgebung vor. Das bedeutet die Nutzung eines dedizierten forensischen Browsers oder einer isolierten Sitzung – nicht des täglichen Browsers des Operators, der Cookies, Anmeldezustand, zwischengespeicherte Antworten, Browser-Erweiterungen und personalisierte A/B-Test-Zuweisungen trägt, die beeinflussen, was der Server zurückgibt. Die Systemuhr muss gegen eine autoritative NTP-Quelle synchronisiert werden (typischerweise time.cloudflare.com, pool.ntp.org oder ein nationaler Zeitdienst). Browsersprache, Zeitzone, Viewport-Abmessungen und User-Agent-Zeichenkette müssen aufgezeichnet werden. Jede VPN-, Proxy- oder Tunneling-Konfiguration muss ausdrücklich dokumentiert werden. Der ACPO Good Practice Guide for Digital Evidence (Version 5), auf den in der europäischen und Commonwealth-Praxis neben ISO 27037 verwiesen wird, kodifiziert diese Vorbereitungsprinzipien.
Phase 2 – Erfassung mit Beweiskette
Die zentrale Erfassungsphase erfasst alle sieben Elemente (DOM, MHTML/WARC, SSL-Zertifikat, IP/DNS, Netzwerkmitschnitt, HTTP-Header, Screenshot) parallel, alle zum Erfassungszeitpunkt durch SHA-256-Hashing gebunden. Jedes Element landet in einem strukturierten, signierten Protokoll mit einem präzisen Zeitstempel. Die Aufzeichnung der Beweiskette beginnt in diesem Moment und setzt sich über den gesamten Beweislebenszyklus fort. Erforderliche Informationen in der Beweiskette umfassen: wer den Beweis erfasst hat (mit Rolle und Qualifikationen), wann (mit NTP-synchronisiertem Zeitstempel), mit welchem Werkzeug (mit Version), gegen welches Ziel (URL, mit vollständiger Kodierung), mit welcher Konfiguration (Browserumgebung, Viewport, User-Agent) und die resultierenden Hashes. Das Beweisketten-Protokoll selbst muss manipulationssicher sein – typischerweise dadurch, dass es in ein Append-Only-Register aufgenommen oder mit einer qualifizierten elektronischen Signatur versiegelt wird.
Phase 3 – Versiegelung mit Hash, qualifiziertem Siegel und Zeitstempel
Die letzte Phase erzeugt die kryptografischen Siegel, die die erfassten Artefakte in rechtlich entgegenhaltbare Beweise verwandeln. Das vollständige Beweisbündel (alle Artefakte plus Manifest) wird mit SHA-256 gehasht und erzeugt den Manifest-Wurzel-Hash. Ein qualifiziertes elektronisches Siegel nach Artikel 35 eIDAS wird aufgebracht (das eine Vermutung von Integrität und Ursprung liefert). Ein qualifizierter elektronischer Zeitstempel nach Artikel 41 wird aufgebracht (der eine Vermutung der Richtigkeit von Datum und Uhrzeit liefert). Der Bitcoin-OpenTimestamps-Anker wird initiiert. Das Beweisbündel wird dann in einem manipulationssicheren Archiv gespeichert, wobei das Archiv selbst an der Append-Only-Hash-Kette des Operators teilnimmt. All diese Vorgänge sollten von der Plattform automatisch durchgeführt werden – die manuelle Aufbringung kryptografischer Siegel in dieser Phase führt ein Risiko menschlicher Fehler ein, das dem Wiederholbarkeitsprinzip von ISO 27037 zuwiderläuft.
Dokumentation und Berichterstellung
Über alle drei Phasen hinweg wird eine umfassende technische Dokumentation erstellt. Der forensische Bericht – typischerweise ein signiertes PDF/A-Dokument – beschreibt die Methodik, den Operator, die Umgebung, das Ziel, die erfassten Elemente mit ihren Hashes, die Zeitstempel und etwaige bedeutsame Beobachtungen während der Erfassung. Dieser Bericht ist das, was Schriftsätzen, regulatorischen Einreichungen oder Schiedsdokumenten beigefügt wird. Die Qualität des Berichts wirkt sich unmittelbar auf die Fähigkeit des Praktikers aus, die Methodik in der Kreuzbefragung zu verteidigen. Bewährte Praxis ist die Verwendung standardisierter Berichtsvorlagen, die sicherstellen, dass alle erforderlichen ISO-27037-Elemente bei jeder Erfassung behandelt werden.
14. Häufige Fehler bei der Umsetzung von ISO 27037 für Web-Beweise
Forensische Web-Erfassungen, die vor Gericht zusammenbrechen, brechen typischerweise aus vorhersehbaren Gründen zusammen. Diese Versagensmuster im Voraus zu erkennen, ist der einfachste Weg, einen verteidigungsfähigen Prozess aufzubauen. Die folgende Liste erfasst zwölf wiederkehrende Fehler, die in der Praxis beobachtet werden.
- **Nur einen Screenshot ohne das gerenderte DOM erfassen.** Ein Screenshot erfasst Pixel, keine Struktur. Ohne das DOM kann der Beweis nicht in einer Weise belegen, welcher Inhalt tatsächlich angezeigt wurde, die einer technischen Prüfung standhält. Eine verteidigungsfähige Erfassung erfordert beides – den Screenshot für die visuelle Darstellung und das DOM für die strukturelle Treue.
- **Rohes HTML statt des gerenderten DOM speichern.** Für moderne JavaScript-lastige Seiten kann rohes HTML nahezu keinen substanziellen Inhalt enthalten. Rohes HTML für eine Single-Page-Anwendung zu speichern, erfasst im Wesentlichen nichts von Wert. Die Erfassung muss den Renderingabschluss abwarten und das DOM im Zustand nach dem Rendering serialisieren.
- **Die SSL/TLS-Zertifikatserfassung auslassen.** Ohne die Zertifikatskette kann die Verteidigung argumentieren, die Seite sei von einem unbefugten Zwischenglied ausgeliefert worden. Dies ist einer der einfachsten zu schließenden Angriffsvektoren (jeder forensische Browser erfasst das Zertifikat automatisch), aber einer der am häufigsten übersehenen.
- **Mit einer nicht auf NTP synchronisierten Systemuhr arbeiten.** Lokale Computeruhren driften, manchmal um Minuten pro Tag. Ohne NTP-Synchronisierung kann der lokale Zeitstempel so weit abweichen, dass chronologische Unstimmigkeiten entstehen, die die Gegenseite ausnutzen kann. Die NTP-Synchronisierung ist eine einzeilige Konfigurationsänderung, die diese ganze Klasse von Anfechtungen verhindert.
- **Den SHA-256-Hash nur auf den Screenshot berechnen, nicht auf das Bündel.** Nur den Screenshot zu hashen, lässt DOM, MHTML, Zertifikat und andere Elemente unauthentifiziert. Das vollständige Beweisbündel muss gehasht werden, wobei jedes Element seinen eigenen Hash hat und das Manifest einen kryptografischen Fingerabdruck des Ganzen liefert.
- **Eine kontaminierte Browserumgebung verwenden.** Cookies, Erweiterungen, Anmeldezustand und zwischengespeicherte Antworten beeinflussen, was der Server zurückgibt. Eine mit einem täglichen Browser durchgeführte Erfassung ist von einem unabhängigen Untersucher mit einer anderen Browserkonfiguration nicht reproduzierbar. Eine saubere, isolierte forensische Umgebung ist für die Wiederholbarkeits- und Reproduzierbarkeitsprinzipien zwingend.
- **Die Beweiskette nicht dokumentieren.** ISO 27037 verlangt eine vollständige Aufzeichnung darüber, wer den Beweis gehandhabt hat, wann, mit welchem Werkzeug, wo er gespeichert wurde und wer darauf zugegriffen hat. Ein unvollständiges Protokoll unterbricht den Prüfpfad und untergräbt die Zulässigkeit. Die Beweiskette ist kein bürokratischer Aufwand – sie ist das strukturelle Rückgrat verteidigungsfähiger Beweise.
- **Den Netzwerkverkehr während der Erfassung nicht protokollieren.** SWGDE 21-F-001 verlangt die Aufzeichnung des Netzwerkmitschnitts, um das Fehlen von Weiterleitungen, JavaScript-Einschleusung und Veränderung während der Übertragung zu belegen. Diesen Schritt zu überspringen, bietet der Gegenseite eine klare Angriffsfläche, um die Integrität des erfassten Inhalts anzufechten.
- **Sich allein auf den lokalen Zeitstempel ohne qualifizierten Zeitanker verlassen.** Der lokale Systemzeitstempel ist selbst deklariert und anfechtbar. Ein qualifizierter elektronischer Zeitstempel nach Artikel 41 eIDAS liefert eine gesetzliche Vermutung, die der lokale Zeitstempel nicht bietet. Für Beweise, die für ernsthafte Rechtsstreitigkeiten bestimmt sind, ist die qualifizierte Zeitverankerung zwingend, nicht optional.
- **Für dynamische Seiten Werkzeuge verwenden, die für statisches HTML konzipiert sind.** Viele ältere Web-Archivierungswerkzeuge wurden für statisches HTML gebaut und können JavaScript-gerenderten Inhalt nicht bewältigen. Solche Werkzeuge auf modernen Seiten zu verwenden, erzeugt unvollständige Erfassungen, die falsch wiedergeben, was Nutzer tatsächlich sahen. Die Werkzeugauswahl sollte zum erfassten Inhaltstyp passen.
- **Annehmen, die Beweisaufbewahrung sei automatisch.** Erfasste Beweise müssen aktiv bewahrt werden, mit regelmäßiger Prüfung, dass die kryptografische Integrität intakt bleibt, das Speichermedium lesbar ist und die Zeitanker weiterhin überprüfbar sind. Die langfristige Aufbewahrung ist ein operatives Programm, keine passive Tätigkeit. Die qualifizierten elektronischen Archivierungsdienste von eIDAS 2.0 formalisieren diese Anforderung auf EU-Ebene.
- **Die Erfassung verzögern, nachdem der Beweis identifiziert wurde.** Webinhalte können sich innerhalb von Stunden ändern oder verschwinden. Das Intervall zwischen der Feststellung, dass ein Inhalt bewahrt werden muss, und seiner tatsächlichen Erfassung ist ein Fenster nicht reduzierbaren beweisrechtlichen Risikos. Bewährte Praxis ist, unmittelbar bei Identifizierung zu erfassen, selbst wenn das rechtliche Verfahren zur Verwendung des Beweises noch geplant wird.
15. Häufig gestellte Fragen und Fazit
Die folgenden Fragen behandeln die häufigsten praktischen Anliegen, die Anwälte, Compliance-Verantwortliche und forensische Praktiker bei der Umsetzung von ISO 27037 für die Erfassung von Web-Beweisen aufwerfen.
Was verlangt ISO/IEC 27037 tatsächlich für die Erfassung digitaler Beweise?
Ist ein Screenshot jemals als rechtlicher Beweis vor Gericht ausreichend?
Was ist der Unterschied zwischen DEFR und DES, und welche Rolle sollte Web-Erfassungen durchführen?
Was ist das gerenderte DOM und warum ist es für die forensische Erfassung wichtig?
Was ist der Unterschied zwischen den Archivformaten MHTML und WARC?
Warum ist die Erfassung des SSL/TLS-Zertifikats so wichtig?
Was ist der Unterschied zwischen einem qualifizierten eIDAS-Zeitstempel und einem gewöhnlichen Zeitstempel?
Was ist OpenTimestamps und wie steht es mit Beweisen in Zusammenhang?
Kann ich einen normalen Chrome-Browser für die ISO-27037-Erfassung von Web-Beweisen verwenden?
Was ist serverseitige forensische Erfassung und wie unterscheidet sie sich von einer Browser-Erweiterung?
Wie lange sollten forensische Web-Beweise nach ISO 27037 aufbewahrt werden?
Wird die ISO-27037-Konformität außerhalb der Europäischen Union anerkannt?
Was ist mit den SWGDE Best Practices for Acquiring Online Content?
Wie behandelt die forensische Web-Erfassung authentifizierte Inhalte?
Was ist das praktische Kosten-Nutzen-Verhältnis der ISO-27037-Konformität für typische Rechtsteams?
ISO/IEC 27037 ist zur operativen Basislinie für die verteidigungsfähige Erfassung digitaler Beweise geworden, und sie korrekt auf Webinhalte anzuwenden, ist nun eine wesentliche Fähigkeit für Rechtsteams, Compliance-Organisationen, Programme zur Durchsetzung geistigen Eigentums und forensische Praktiker. Die sieben wesentlichen Elemente (DOM, Archiv, Zertifikat, Netzwerk-Metadaten, Header, Screenshot, Hashes), die vier Kernprinzipien (Nachprüfbarkeit, Wiederholbarkeit, Reproduzierbarkeit, Begründbarkeit) und der dreiphasige Ablauf (Vorbereitung, Erfassung, Versiegelung) bilden zusammen eine Methodik, die einer gegnerischen Prüfung in praktisch jeder Rechtsordnung standhält. Der Ansatz der doppelten Verankerung – qualifizierte eIDAS-Zeitstempel für die gesetzliche EU-Vermutung, Bitcoin OpenTimestamps für die globale kryptografische Unabhängigkeit – bietet Verteidigungsfähigkeit über regionale und weltweite Kontexte hinweg.
GetProofAnchor ist speziell für die ISO/IEC-27037-konforme Erfassung von Web-Beweisen gebaut, wobei alle sieben wesentlichen Elemente parallel von einem serverseitigen forensischen Browser erfasst, mit SHA-256-Manifest-Hashing versiegelt, in eine Append-Only-Hash-Kette eingebunden, mit qualifizierten elektronischen eIDAS-Zeitstempeln eines auf der EU-Vertrauensliste geführten qualifizierten Vertrauensdiensteanbieters versehen, optional mit Bitcoin OpenTimestamps verankert und über einen vollständig offenen öffentlichen Verifikationsendpunkt verifizierbar sind. Jede Erfassung erzeugt einen vollständigen forensischen Bericht, der an den Dokumentationsanforderungen von ISO 27037 ausgerichtet ist und für Rechtsstreitigkeiten, regulatorische Verfahren und internationale Schiedsverfahren über EU-, US-, UK- und globale Rechtsordnungen hinweg geeignet ist.
Ob Sie sich für GetProofAnchor oder eine andere Plattform entscheiden, der wichtigste Schritt ist, die ISO-27037-konforme forensische Erfassung jetzt in Ihren Standard-Beweisablauf zu integrieren, bevor die nächste streitige Angelegenheit auftritt. Die Kosten sind gering; der Schutz ist erheblich; und die rechtliche Landschaft begünstigt eindeutig Prozessparteien, die mit förmlich authentifizierten Beweisen statt mit unauthentifizierten Screenshots vor Gericht erscheinen. Für eine tiefere Behandlung verwandter Themen siehe unseren vollständigen Leitfaden zu digitalen Beweissystemen und unsere Analyse, warum Screenshots allein nicht ausreichen.
Verwandte Leitfäden
-
Warum Screenshots 2026 als Beweis nicht ausreichenWarum Gerichte und Aufsichtsbehörden (SEC, FINRA, MiFID II, DSGVO, eIDAS) einfache Screenshots zunehmend als Beweis ablehnen.
-
Digitales Beweissystem im Jahr 2026Was ist ein modernes digitales Beweissystem im Jahr 2026?
-
eIDAS-qualifizierte Zeitstempel für digitale BeweiseUmfassender Leitfaden zu qualifizierten Zeitstempeln nach Artikel 41 eIDAS für digitale Beweise.
-
Die Wayback Machine als Gerichtsbeweis 2026Vollständiger Leitfaden 2026 zur Nutzung von Wayback-Machine-Schnappschüssen als Gerichtsbeweis.
-
NIS2 – Beweise bei CybersicherheitsvorfällenMeldefristen nach Artikel 23, Schwellenwerte für schwerwiegende Vorfälle, forensische Beweissicherung und Haftung der Geschäftsleitung unter NIS2.
ISO-27037-konforme forensische Web-Erfassung – DOM, MHTML, SSL, doppelte Verankerung, alles an der Quelle versiegelt.
Serverseitiger forensischer Browser, SHA-256-Manifest, Append-Only-Hash-Kette, qualifizierter elektronischer eIDAS-Zeitstempel, optionale Bitcoin-OpenTimestamps-Verankerung und ein offener öffentlicher Verifikationsendpunkt. Verteidigungsfähige Beweise für Rechtsstreitigkeiten, regulatorische Verfahren und internationale Schiedsverfahren.
7 Tage kostenlose Testphase · Jederzeit kündbar