Technische Beweisfragen
Bei technischen Streitfragen verändert sich die Beweislage häufig schneller als bei statischen Sachverhalten. Systeme werden aktualisiert, Logs rotiert, Cloud-Konfigurationen geändert und Repositories weiterentwickelt. Eine frühe, nachvollziehbare Sicherung kann deshalb entscheidend dafür sein, ob ein späterer technischer Zustand noch untersucht werden kann.
Kurzantwort
Zu sichern sind nicht „möglichst viele Daten“, sondern die für die konkrete technische Frage relevanten Artefakte und Kontextinformationen: Versionen, Dateien, Repositories, Logs, Datenexporte, Konfigurationen, Screenshots und Metadaten. Sicherung bedeutet technische Identifizierbarkeit und dokumentierte Herkunft; sie ersetzt keine rechtliche Beweiswürdigung.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Welche Unterlagen technisch relevant sein können
Die benötigten Unterlagen hängen von der Beweisfrage ab. Bei Softwaremängeln können Anforderungen, Testfälle, Build-Artefakte und reproduzierbare Systemstände wichtig sein. Bei Projektstreitigkeiten kommen Tickets, Änderungsstände und Repository-Historie hinzu. Bei Sicherheitsvorfällen sind Logs, Konfigurationen und Zeitbezüge zentral.
Eine pauschale Sammlung erzeugt dagegen unnötige Datenmengen und kann sensible Informationen einschließen, die für die Frage nicht erforderlich sind. Deshalb wird zunächst bestimmt, welche technische Aussage später belegt oder widerlegt werden soll.
Die Sicherung sollte auch die Beziehungen zwischen Artefakten erhalten: Welcher Build gehört zu welchem Commit? Welcher Log stammt aus welcher Instanz? Welcher Datenexport repräsentiert welchen Zeitpunkt?
2. Zustand, Herkunft und Zeitpunkt dokumentieren
Eine Kopie ohne Kontext ist häufig nur eingeschränkt aussagekräftig. Neben der Datei selbst werden deshalb Quelle, Zeitpunkt, System, Version und Bereitstellungsweg festgehalten. Bei Repository-Daten sind erreichbare Refs und Objekt-IDs relevant; bei Systemlogs Zeitzone, Rotationslogik und Quelle.
Hashwerte können dabei helfen, eine konkrete Bytefolge später wiederzuerkennen. Sie belegen jedoch nicht automatisch, wann oder von wem ein Artefakt erstellt wurde. Solche Aussagen benötigen zusätzliche Evidenz.
Bei dynamischen Systemen sollte dokumentiert werden, ob die Sicherung ein konsistentes Snapshot darstellt oder während laufender Änderungen erfolgte.
3. Original, Arbeitskopie und Auswertung trennen
Für nachvollziehbare technische Arbeit ist es sinnvoll, einen gesicherten Ausgangsbestand von Analyse- und Arbeitskopien zu trennen. Veränderungen durch Tools, Konvertierungen oder Tests lassen sich dann besser vom ursprünglichen Zustand unterscheiden.
Bei Datenbanken oder Cloud-Systemen kann ein vollständiges Original technisch oder organisatorisch nicht verfügbar sein. Dann wird beschrieben, welcher Export oder welche Sicht tatsächlich untersucht wurde und welche Informationen dadurch möglicherweise fehlen.
Auch Screenshots können wertvollen Kontext liefern, ersetzen aber keine maschinenlesbaren Primärdaten, wenn diese für die konkrete technische Prüfung erforderlich sind.
4. Datenschutz, Geheimnisse und Datenminimierung
Technische Sicherung ist kein Freibrief für unbegrenzte Datensammlung. Personenbezogene Inhalte, Zugangsdaten, Tokens und Geschäftsgeheimnisse werden nur im erforderlichen Umfang verarbeitet und geschützt.
Besonders bei Kommunikations- oder Logdaten sollte die Fragestellung die Auswahl steuern. Wo technische Metadaten genügen, müssen nicht automatisch vollständige Nachrichteninhalte übernommen werden.
Der Sachverständige dokumentiert die technische Grundlage und ihre Grenzen. Die rechtliche Zulässigkeit einer Datenerhebung oder Herausgabe ist davon getrennt zu beurteilen.
5. Übergabe an die technische Begutachtung
Vor Beginn der Analyse wird ein Evidenzinventar erstellt. Es benennt Artefakte, Identifikatoren, Herkunft, Zeitraum, gegebenenfalls Hashwerte sowie bekannte Lücken. So lässt sich später nachvollziehen, auf welcher Grundlage ein Befund entstand.
Wesentliche Änderungen oder Nachlieferungen werden als neue Evidenzversion dokumentiert. Dadurch bleibt sichtbar, ob eine spätere Schlussfolgerung auf demselben oder auf einem erweiterten Datenbestand beruht.
Diese Trennung schützt sowohl die Untersuchung als auch die Kommunikation mit Gericht, Rechtsanwälten oder Auftraggebern vor unklaren Behauptungen über einen nicht eindeutig bestimmten Datenstand.
6. Sicherungsplan nach Volatilität und Aussageziel
Ein Sicherungsplan ordnet Quellen nicht nur nach Bequemlichkeit, sondern nach Verlust- und Veränderungsrisiko. Flüchtige Zustände wie laufende Prozesse, temporäre Cloud-Ereignisse oder kurz gehaltene Logs können eine andere Priorität besitzen als versionierte Dokumente oder archivierte Releases.
Die Sicherung sollte zugleich verhältnismäßig zum Aussageziel bleiben. Für die Rekonstruktion eines bestimmten Deployment-Zeitpunkts sind beispielsweise Build- und Deploymentnachweise wichtiger als eine ungezielte Komplettsicherung sämtlicher Unternehmensdaten. Datenminimierung und Beweisrelevanz lassen sich dadurch zusammenführen.
Für die spätere Begutachtung ist außerdem festzuhalten, welche Quelle nicht mehr verfügbar war, wann sie überschrieben wurde oder warum sie nicht gesichert werden konnte. Solche Informationen können die Aussagekraft stärker beeinflussen als die reine Menge der erhaltenen Daten.
Warum ist die Reihenfolge der Sicherung wichtig?
Digitale Quellen besitzen unterschiedliche Volatilität. Ein aktiver RAM-Inhalt kann mit dem Ausschalten verschwinden, während ein archiviertes Dokument langfristig stabil bleibt.
Das BSI empfiehlt bei forensischer Vorsorge, Datenquellen zu identifizieren und die Sicherungsreihenfolge an der Flüchtigkeit auszurichten. Schnell flüchtige Daten sollen demnach zeitnah gesichert werden.
Die konkrete Reihenfolge muss dennoch zur Fragestellung passen und darf nicht blind aus einem generischen Forensikschema übernommen werden.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Ist die technische Beweisfrage vor der Sicherung hinreichend eingegrenzt?
- Sind flüchtige, rotierende oder überschreibbare Quellen identifiziert?
- Ist die Sicherungsreihenfolge begründet und dokumentiert?
- Sind Originalzustand, Export und spätere Arbeitskopien unterscheidbar?
- Sind Prüfsummen und Übergabeinformationen dort dokumentiert, wo sie die Identität der Artefakte absichern?
- Wurde die Datenerhebung auf die erforderlichen technischen Inhalte begrenzt?
- Sind nicht mehr verfügbare oder verspätet gesicherte Quellen als Aussagegrenze erfasst?
Konstruiertes Beispiel
Ein behaupteter Fehler ist nur in einem alten Produktivstand aufgetreten. Noch vor einem Update werden Build-ID, Konfiguration, Logausschnitt und ein reproduzierbarer Testablauf dokumentiert. Nach dem Update ist der Fehler nicht mehr beobachtbar. Die frühere Sicherung ermöglicht dennoch eine technisch begrenzte Aussage zum damaligen Stand.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Amtliche Primärquelle § 403 ZPO zur Bezeichnung der zu begutachtenden Punkte und § 404a ZPO zur Leitung der Tätigkeit. Quelle öffnen.
- Technische Primärquelle Git show-ref dokumentiert vorhandene Referenzen eines Repositories. Quelle öffnen.
- Eigene Methodik Quellen und Methodik. Quelle öffnen.
- Amtliche technische Leitlinie BSI IT-Grundschutz DER.2.2 „Vorsorge für die IT-Forensik“ zur Auswahl, Reihenfolge und Dokumentation forensisch relevanter Daten. Quelle öffnen.
- Amtliche Primärquelle § 404a ZPO zur Leitung der Sachverständigentätigkeit und zum Umfang der Aufklärung der Beweisfrage. Quelle öffnen.
Weiterführende Beiträge
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich Technische Beweisfragen
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
Informationen für Gerichte und Rechtsanwälte