Gutachten & Methodik
Ein Gutachten kann nur so belastbar sein wie die Untersuchungsgrundlage, auf die es sich stützt. Deshalb werden bereitgestellte Dateien, Repositories, Datenstände, Logs, Screenshots und Dokumentationen nicht nur gesammelt, sondern hinsichtlich Herkunft, Umfang, Integrität und möglicher Lücken beschrieben.
Kurzantwort
Untersuchungsgrundlage bedeutet die konkret verfügbare Evidenz. Sie wird inventarisiert, ihrem Ursprung und Zeitraum zugeordnet und – soweit sinnvoll – gegen Veränderung oder Verwechslung abgesichert. Fehlende, selektiv bereitgestellte oder technisch nicht verifizierbare Quellen sind Teil der Aussagegrenze und dürfen nicht durch Annahmen ersetzt werden.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Welche Evidenz tatsächlich vorliegt
Zwischen „im Projekt vorhanden“ und „für die Untersuchung bereitgestellt“ besteht ein wesentlicher Unterschied. Für die Begutachtung zählt zunächst die tatsächlich zugängliche Grundlage. Dazu können Repository-Klone, Exporte, Tickets, Spezifikationen, Build-Artefakte, Datenbanken, Logdateien, Kommunikationsauszüge oder Systemzugänge gehören.
Die Inventarisierung sollte Quelle, Dateiname oder Identifier, Zeitraum, Versionsbezug und Bereitstellungsweg erfassen. Bei großen Datenmengen genügt häufig ein strukturiertes Verzeichnis mit Hashwerten oder technischen Metadaten, solange die Identifikation später nachvollziehbar bleibt.
Die bloße Existenz einer Datei macht sie noch nicht zur verlässlichen Primärquelle. Relevanz und Nachweisqualität hängen davon ab, wie sie entstanden ist, ob sie den streitigen Zustand abbildet und ob Veränderungen ausgeschlossen oder zumindest erkennbar gemacht werden können.
2. Provenienz und Integrität
Provenienz beschreibt, wie ein Artefakt oder Datenbestand entstanden ist und aus welchen Quellen er abgeleitet wurde. Für Datenflüsse kann ein Provenienzmodell Entitäten, Aktivitäten und beteiligte Akteure unterscheiden; für Software liefern Repository-Historie und Build-Nachweise andere Formen technischer Herkunftsinformation.
Hashwerte sind geeignet, eine konkrete Bytefolge später wiederzuerkennen. Sie beweisen jedoch für sich allein weder Urheberschaft noch den Zeitpunkt der Entstehung. Deshalb werden Integritätsindikatoren immer zusammen mit Herkunft, Kontext und Bereitstellungsweg betrachtet.
Bei laufenden Systemen ist zusätzlich zu klären, ob während der Untersuchung Änderungen erfolgen. Ein späterer Export kann einen anderen Zustand repräsentieren als der ursprünglich streitige Zeitpunkt.
3. Vollständigkeit und Auswahlverzerrung
Eine Untersuchung kann technisch korrekt durchgeführt und trotzdem in ihrer Aussage begrenzt sein, wenn nur ein Ausschnitt der relevanten Daten vorliegt. Typische Beispiele sind fehlende Branches, rotierte Logs, unvollständige Tickets, gelöschte Artefakte oder Datenexporte ohne Transformationshistorie.
Vollständigkeit wird deshalb nicht pauschal behauptet. Stattdessen wird beschrieben, welcher Bestand vorlag und welche Prüfungen zur Reichweite der Daten möglich waren. Bei Git kann etwa die Menge erreichbarer Refs dokumentiert werden; bei Logs Zeitraum und Rotationsregeln; bei Datenbanken Schema, Exportzeitpunkt und Tabellenumfang.
Fehlende Evidenz ist nicht automatisch ein Gegenbeweis. Das Nichtauffinden eines Artefakts innerhalb einer begrenzten Quelle darf nur auf genau diese Quelle und Suchmethode bezogen werden.
4. Datenminimierung und vertrauliche Inhalte
Für die technische Prüfbasis gilt das Prinzip, nur die Informationen zu verarbeiten, die für die konkrete Fragestellung erforderlich sind. Besonders bei personenbezogenen Logs, Kommunikationsdaten oder Repository-Metadaten sollte die Auswahl auf den fachlich notwendigen Umfang begrenzt werden.
Geheimnisse wie Passwörter, Tokens oder produktive Schlüssel gehören nicht in Gutachtentexte. Wenn ihre Existenz technisch relevant ist, können Fundstelle, Typ, Gültigkeitskontext und gegebenenfalls ein sicherer Fingerprint dokumentiert werden, ohne das Geheimnis selbst zu reproduzieren.
Auch im Bericht wird zwischen prüfrelevanter Evidenz und bloßem Datenbesitz unterschieden. Nachvollziehbarkeit verlangt keine unnötige Veröffentlichung vertraulicher Rohdaten.
5. Untersuchungsgrundlage im Bericht dokumentieren
Der Bericht sollte erkennen lassen, welche Quellen für welche Befunde verwendet wurden. Eine allgemeine Unterlagenliste genügt nicht, wenn die Schlussfolgerung auf wenigen spezifischen Artefakten beruht.
Sinnvoll ist eine Evidenzmatrix, die Fragestellung, Quelle, Zustand, Prüfschritt und Ergebnis miteinander verbindet. Damit lässt sich später nachvollziehen, ob eine Quelle nur Kontext lieferte oder tatsächlich einen Befund trug.
Wird nachträglich neue Evidenz bereitgestellt, ist zu prüfen, ob sich dadurch Befund oder Bewertung ändern können. Neue Daten können einen Revisionsanlass darstellen und sollten nicht stillschweigend in einen bereits dokumentierten Prüfstand einfließen.
6. Evidenzregister und nachvollziehbare Übergabekette
Ein Evidenzregister verbindet technische Datei oder Quelle mit ihrer Herkunft. Typische Felder sind Bezeichnung, Quellsystem, bereitstellende Stelle, Übernahmezeitpunkt, Dateigröße, Hashwert, Originalpfad, Exportmethode und Verwendungszweck. Bei Datenbank- oder Cloud-Exporten kommen Abfrage, Filter und Exportparameter hinzu.
Wichtig ist die Trennung zwischen Original oder unverändert übernommenem Export und den für die Analyse erzeugten Arbeitskopien. Analysewerkzeuge können Metadaten ergänzen, temporäre Dateien erzeugen oder Formate konvertieren. Solche Veränderungen sind nicht per se problematisch, müssen aber vom gesicherten Ausgangsmaterial unterscheidbar bleiben.
Fehlende Quellen gehören ebenfalls ins Register. Wenn beispielsweise nur ein Ticket-Export, aber kein Zugriff auf das ursprüngliche System vorliegt, begrenzt dies die Prüfung von Historie, Löschungen und Metadaten. Eine dokumentierte Lücke ist methodisch stärker als eine stillschweigende Annahme von Vollständigkeit.
Wann ist eine forensische Sicherung erforderlich?
Nicht jede technische Begutachtung ist eine IT-forensische Untersuchung. Die Sicherungstiefe richtet sich nach Fragestellung, Veränderlichkeit und Beweisrisiko.
Bei flüchtigen Daten, Sicherheitsvorfällen oder streitiger Integrität können forensische Sicherungsprinzipien erforderlich werden. Das BSI betont für die IT-Forensik unter anderem Arbeitsauftrag, Datenquellen, Reihenfolge der Sicherung, kryptografische Prüfsummen und lückenlose Dokumentation.
Bei weniger volatilen Unterlagen kann ein nachvollziehbarer Export mit dokumentierter Herkunft genügen. Die gewählte Sicherungstiefe ist zu begründen.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind alle tatsächlich verwendeten Quellen in einem Evidenzregister erfasst?
- Ist dokumentiert, wer oder welches System die Quelle bereitgestellt hat?
- Sind Original, Export und Arbeitskopie voneinander unterscheidbar?
- Sind Hashwerte oder andere technische Identifikatoren dort verwendet, wo sie einen Mehrwert liefern?
- Sind Exportfilter, Abfragen und Konvertierungen dokumentiert?
- Sind erwartbare, aber fehlende Quellen ausdrücklich als Lücke erfasst?
- Ist die Sicherungstiefe der Veränderlichkeit und Bedeutung der Quelle angemessen?
Konstruiertes Beispiel
Für die Rekonstruktion eines Projektverlaufs werden ein Git-Repository, ein Ticketexport und ein Build-Artefakt bereitgestellt. Der Repository-Klon enthält nur den Hauptbranch. Im Gutachten wird daher ausdrücklich festgehalten, dass Aussagen zur Historie nur für die erreichbaren Objekte und Refs gelten und nicht ausschließen, dass außerhalb dieses Bestands weitere Entwicklungsstände existierten.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- W3C Recommendation PROV-DM beschreibt das konzeptionelle Datenmodell für Provenienz und Beziehungen zwischen Entitäten, Aktivitäten und Akteuren. Quelle öffnen.
- Technische Primärquelle Git cat-file stellt Inhalte und Eigenschaften von Repository-Objekten bereit. Quelle öffnen.
- Eigene Methodik Quellen und Methodik. Quelle öffnen.
- Amtliche technische Leitlinie BSI IT-Grundschutz DER.2.2 „Vorsorge für die IT-Forensik“, insbesondere zu Datenquellen, Sicherungsreihenfolge, Prüfsummen und Dokumentation. Quelle öffnen.
Weiterführende Beiträge
- Unterlagen bei Individualsoftware
- Git-Historie und Software-Provenienz
- Alle Beiträge in diesem Themenbereich
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.
- Eigenes Fachbuch Kritisches Denken in Data Science mit Python – Vom Beobachten zur verantwortbaren Entscheidung
- Eigenes Fachbuch Von Daten zu Lösungen in Data Science mit Python – Vom Problem zur verantwortbaren Lösung
- Eigenes Fachbuch Von Modellen zu Entscheidungen in Machine Learning mit Python – Vom Modell zur verantwortbaren Entscheidung
- Eigenes Fachbuch Von Code zu Lösungen im Software Engineering mit Java – Vom Problem zur verantwortbaren Lösung
Technische Untersuchung zum Themenbereich Gutachten & Methodik
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
Gutachtendokumentation ansehen