616 lines
18 KiB
Markdown
616 lines
18 KiB
Markdown
---
|
|
title: "Digital Evidence Chain of Custody: Lückenlose Beweisführung in der digitalen Forensik"
|
|
description: "Umfassender Leitfaden für die rechtssichere Dokumentation digitaler Beweise von der Sicherstellung bis zur Gerichtsverhandlung. Praktische Umsetzung von ISO 27037, Dokumentationsstandards und häufige Fallstricke."
|
|
author: "Claude 4 Sonnett (Prompt: Mario Stöckl)"
|
|
last_updated: 2025-08-10
|
|
difficulty: advanced
|
|
categories: ["standards", "documentation", "legal-compliance", "case-management"]
|
|
tags: ["chain-of-custody", "iso-27037", "court-admissible", "audit-trail", "hash-verification", "tamper-evidence", "legal-compliance", "documentation", "process-management", "evidence-handling"]
|
|
published: true
|
|
---
|
|
|
|
# Digital Evidence Chain of Custody: Lückenlose Beweisführung in der digitalen Forensik
|
|
|
|
Die **Chain of Custody** (Beweiskette) ist das Rückgrat jeder forensischen Untersuchung und entscheidet oft über Erfolg oder Misserfolg vor Gericht. Dieser Leitfaden erklärt die rechtssicheren Verfahren für die lückenlose Dokumentation digitaler Beweise von der Sicherstellung bis zur Gerichtsverhandlung.
|
|
|
|
## Warum ist die Chain of Custody entscheidend?
|
|
|
|
In der digitalen Forensik können Beweise innerhalb von Sekunden manipuliert, gelöscht oder verfälscht werden. Eine ordnungsgemäße Chain of Custody gewährleistet:
|
|
|
|
- **Gerichtliche Verwertbarkeit** der Beweise
|
|
- **Nachweis der Authentizität** und Integrität
|
|
- **Schutz vor Manipulationsvorwürfen**
|
|
- **Rechtssicherheit** für alle Beteiligten
|
|
- **Compliance** mit internationalen Standards
|
|
|
|
> **Warnung**: Bereits kleine Fehler in der Beweiskette können zur kompletten Verwerfung der Beweise führen und jahrelange Ermittlungsarbeit zunichte machen.
|
|
|
|
## Rechtliche Grundlagen und Standards
|
|
|
|
### Internationale Standards
|
|
|
|
**ISO/IEC 27037:2012** - "Guidelines for identification, collection, acquisition and preservation of digital evidence"
|
|
- Definiert Best Practices für digitale Beweismittel
|
|
- International anerkannter Standard
|
|
- Basis für nationale Implementierungen
|
|
|
|
**ISO/IEC 27041:2015** - "Guidance on assuring suitability and adequacy of incident investigative method"
|
|
- Ergänzt ISO 27037 um Qualitätssicherung
|
|
- Fokus auf Angemessenheit der Methoden
|
|
|
|
### Nationale Rahmenwerke
|
|
|
|
**Deutschland**:
|
|
- § 81a StPO (Körperliche Untersuchung)
|
|
- § 94 ff. StPO (Beschlagnahme)
|
|
- BSI-Standards zur IT-Forensik
|
|
|
|
**USA**:
|
|
- Federal Rules of Evidence (Rule 901, 902)
|
|
- NIST Special Publication 800-86
|
|
|
|
**EU**:
|
|
- GDPR-Compliance bei der Beweissicherung
|
|
- eIDAS-Verordnung für digitale Signaturen
|
|
|
|
## Die vier Säulen der Chain of Custody
|
|
|
|
### 1. Authentizität (Echtheit)
|
|
**Definition**: Nachweis, dass die Beweise tatsächlich von der behaupteten Quelle stammen.
|
|
|
|
**Praktische Umsetzung**:
|
|
```bash
|
|
# Cryptographic Hash Generation
|
|
sha256sum /dev/sdb1 > evidence_hash.txt
|
|
md5sum /dev/sdb1 >> evidence_hash.txt
|
|
|
|
# Mit Zeitstempel
|
|
echo "$(date -u +%Y-%m-%dT%H:%M:%SZ): $(sha256sum /dev/sdb1)" >> chain_log.txt
|
|
```
|
|
|
|
### 2. Integrität (Unversehrtheit)
|
|
**Definition**: Sicherstellung, dass die Beweise seit der Sicherstellung unverändert geblieben sind.
|
|
|
|
**Maßnahmen**:
|
|
- **Write-Blocker** bei allen Zugriffen
|
|
- **Hash-Verifizierung** vor und nach jeder Bearbeitung
|
|
- **Versionskontrolle** für alle Arbeitskopien
|
|
|
|
### 3. Nachvollziehbarkeit (Traceability)
|
|
**Definition**: Lückenlose Dokumentation aller Personen, die Zugang zu den Beweisen hatten.
|
|
|
|
**Dokumentationspflicht**: Wer, Was, Wann, Wo, Warum
|
|
|
|
### 4. Nicht-Abstreitbarkeit (Non-Repudiation)
|
|
**Definition**: Verhinderung, dass Beteiligte ihre Handlungen später abstreiten können.
|
|
|
|
**Technische Lösung**: Digitale Signaturen, Blockchain-Timestamping
|
|
|
|
## Praktische Implementierung: Schritt-für-Schritt
|
|
|
|
### Phase 1: Vorbereitung der Sicherstellung
|
|
|
|
**Equipment-Check**:
|
|
```checklist
|
|
□ Kalibrierte Write-Blocker
|
|
□ Forensische Imaging-Tools
|
|
□ Chain of Custody Formulare
|
|
□ Tamper-evident Bags/Labels
|
|
□ Digitalkamera für Dokumentation
|
|
□ Messgeräte (falls erforderlich)
|
|
□ Backup-Ausrüstung
|
|
```
|
|
|
|
**Dokumentation vor Ort**:
|
|
1. **Umgebungsfotografie** (360°-Dokumentation)
|
|
2. **Hardware-Identifikation** (Seriennummern, Labels)
|
|
3. **Netzwerkzustand** (aktive Verbindungen)
|
|
4. **Bildschirmzustand** (Screenshots vor Herunterfahren)
|
|
|
|
### Phase 2: Sichere Akquisition
|
|
|
|
**Write-Blocker Setup**:
|
|
```bash
|
|
# Hardware Write-Blocker Verification
|
|
lsblk -o NAME,SIZE,RO,TYPE,MOUNTPOINT
|
|
# RO sollte "1" anzeigen für geschützte Devices
|
|
|
|
# Software Write-Blocker (Linux)
|
|
blockdev --setro /dev/sdb
|
|
blockdev --getro /dev/sdb # Should return 1
|
|
```
|
|
|
|
**Imaging mit Integrity Check**:
|
|
```bash
|
|
# dd mit Hash-Berechnung
|
|
dd if=/dev/sdb | tee >(sha256sum > image.sha256) | dd of=evidence.dd
|
|
|
|
# Oder mit dcfldd für bessere Forensik-Features
|
|
dcfldd if=/dev/sdb of=evidence.dd hash=sha256,md5 hashlog=hashlog.txt bs=4096
|
|
```
|
|
|
|
### Phase 3: Dokumentation und Versiegelung
|
|
|
|
**Chain of Custody Form - Kernelemente**:
|
|
|
|
```
|
|
DIGITAL EVIDENCE CUSTODY FORM
|
|
|
|
Fall-ID: _______________ Datum: _______________
|
|
Ermittler: _______________ Badge/ID: _______________
|
|
|
|
BEWEISMITTEL DETAILS:
|
|
- Beschreibung: ________________________________
|
|
- Seriennummer: _______________________________
|
|
- Hersteller/Modell: ___________________________
|
|
- Kapazität: __________________________________
|
|
- Hash-Werte:
|
|
* SHA256: ___________________________________
|
|
* MD5: _____________________________________
|
|
|
|
CUSTODY CHAIN:
|
|
[Datum/Zeit] [Übernommen von] [Übergeben an] [Zweck] [Unterschrift]
|
|
_________________________________________________________________
|
|
_________________________________________________________________
|
|
|
|
INTEGRITÄT BESTÄTIGT:
|
|
□ Write-Blocker verwendet
|
|
□ Hash-Werte verifiziert
|
|
□ Tamper-evident versiegelt
|
|
□ Fotos dokumentiert
|
|
```
|
|
|
|
**Versiegelung**:
|
|
```
|
|
Tamper-Evident Label Nummer: ______________
|
|
Siegeltyp: _______________________________
|
|
Platzierung: _____________________________
|
|
Foto-Referenz: ___________________________
|
|
```
|
|
|
|
### Phase 4: Transport und Lagerung
|
|
|
|
**Sichere Aufbewahrung**:
|
|
- **Klimakontrollierte Umgebung** (15-25°C, <60% Luftfeuchtigkeit)
|
|
- **Elektromagnetische Abschirmung** (Faraday-Käfig)
|
|
- **Zugangskontrolle** (Biometrie, Kartenleser)
|
|
- **Überwachung** (24/7 Video, Alarme)
|
|
|
|
**Transport-Protokoll**:
|
|
```
|
|
TRANSPORT LOG
|
|
|
|
Von: ______________________ Nach: ______________________
|
|
Datum/Zeit Start: _____________ Ankunft: _______________
|
|
Transportmittel: ___________________________________
|
|
Begleitpersonen: ___________________________________
|
|
Spezielle Vorkehrungen: ____________________________
|
|
|
|
Integrität bei Ankunft:
|
|
□ Siegel unversehrt
|
|
□ Hash-Werte überprüft
|
|
□ Keine physischen Schäden
|
|
□ Dokumentation vollständig
|
|
|
|
Empfänger: _________________ Unterschrift: _____________
|
|
```
|
|
|
|
## Digitale Chain of Custody Tools
|
|
|
|
### Laboratory Information Management Systems (LIMS)
|
|
|
|
**Kommerzielle Lösungen**:
|
|
- **FRED (Forensic Recovery of Evidence Device)**
|
|
- **CaseGuard** von AccessData
|
|
- **EnCase Legal** von OpenText
|
|
|
|
**Open Source Alternativen**:
|
|
```python
|
|
# Beispiel: Python-basierte CoC Tracking
|
|
import hashlib
|
|
import datetime
|
|
import json
|
|
from cryptography.fernet import Fernet
|
|
|
|
class ChainOfCustody:
|
|
def __init__(self):
|
|
self.evidence_log = []
|
|
self.key = Fernet.generate_key()
|
|
self.cipher = Fernet(self.key)
|
|
|
|
def add_custody_event(self, evidence_id, handler, action, location):
|
|
event = {
|
|
'timestamp': datetime.datetime.utcnow().isoformat(),
|
|
'evidence_id': evidence_id,
|
|
'handler': handler,
|
|
'action': action,
|
|
'location': location,
|
|
'hash': self.calculate_hash(evidence_id)
|
|
}
|
|
|
|
# Encrypt sensitive data
|
|
encrypted_event = self.cipher.encrypt(json.dumps(event).encode())
|
|
self.evidence_log.append(encrypted_event)
|
|
|
|
return event
|
|
|
|
def calculate_hash(self, evidence_path):
|
|
"""Calculate SHA256 hash of evidence file"""
|
|
hash_sha256 = hashlib.sha256()
|
|
with open(evidence_path, "rb") as f:
|
|
for chunk in iter(lambda: f.read(4096), b""):
|
|
hash_sha256.update(chunk)
|
|
return hash_sha256.hexdigest()
|
|
```
|
|
|
|
### Blockchain-basierte Lösungen
|
|
|
|
**Unveränderliche Timestamps**:
|
|
```solidity
|
|
// Ethereum Smart Contract Beispiel
|
|
pragma solidity ^0.8.0;
|
|
|
|
contract EvidenceChain {
|
|
struct CustodyEvent {
|
|
uint256 timestamp;
|
|
string evidenceId;
|
|
string handler;
|
|
string action;
|
|
string hashValue;
|
|
}
|
|
|
|
mapping(string => CustodyEvent[]) public evidenceChain;
|
|
|
|
event CustodyTransfer(
|
|
string indexed evidenceId,
|
|
string handler,
|
|
uint256 timestamp
|
|
);
|
|
|
|
function addCustodyEvent(
|
|
string memory _evidenceId,
|
|
string memory _handler,
|
|
string memory _action,
|
|
string memory _hashValue
|
|
) public {
|
|
evidenceChain[_evidenceId].push(CustodyEvent({
|
|
timestamp: block.timestamp,
|
|
evidenceId: _evidenceId,
|
|
handler: _handler,
|
|
action: _action,
|
|
hashValue: _hashValue
|
|
}));
|
|
|
|
emit CustodyTransfer(_evidenceId, _handler, block.timestamp);
|
|
}
|
|
}
|
|
```
|
|
|
|
## Häufige Fehler und Fallstricke
|
|
|
|
### Kritische Dokumentationsfehler
|
|
|
|
**1. Unvollständige Handler-Information**
|
|
```
|
|
❌ Falsch: "IT-Abteilung"
|
|
✅ Richtig: "Max Mustermann, IT-Administrator, Badge #12345, Abteilung IT-Security"
|
|
```
|
|
|
|
**2. Unspezifische Aktionsbeschreibungen**
|
|
```
|
|
❌ Falsch: "Analyse durchgeführt"
|
|
✅ Richtig: "Keyword-Suche nach 'vertraulich' mit EnCase v21.2,
|
|
Read-Only Zugriff, Image Hash vor/nach verifiziert"
|
|
```
|
|
|
|
**3. Lückenhafte Zeiterfassung**
|
|
```
|
|
❌ Falsch: "15:30"
|
|
✅ Richtig: "2024-01-15T15:30:27Z (UTC), Zeitzone CET+1"
|
|
```
|
|
|
|
### Technische Fallstricke
|
|
|
|
**Hash-Algorithmus Schwächen**:
|
|
```bash
|
|
# Vermeide MD5 für neue Fälle (Kollisionsanfällig)
|
|
❌ md5sum evidence.dd
|
|
|
|
# Verwende stärkere Algorithmen
|
|
✅ sha256sum evidence.dd
|
|
✅ sha3-256sum evidence.dd # Noch sicherer
|
|
```
|
|
|
|
**Write-Blocker Bypass**:
|
|
```bash
|
|
# Prüfe IMMER Write-Protection
|
|
blockdev --getro /dev/sdb
|
|
if [ $? -eq 0 ]; then
|
|
echo "Write protection AKTIV"
|
|
else
|
|
echo "WARNUNG: Write protection NICHT aktiv!"
|
|
exit 1
|
|
fi
|
|
```
|
|
|
|
### Rechtliche Fallstricke
|
|
|
|
**GDPR-Compliance bei EU-Fällen**:
|
|
- **Datenschutz-Folgenabschätzung** vor Imaging
|
|
- **Zweckbindung** der Beweiserhebung
|
|
- **Löschfristen** nach Verfahrensabschluss
|
|
|
|
**Jurisdiktionsprobleme**:
|
|
- **Cloud-Evidence** in verschiedenen Ländern
|
|
- **Verschiedene Beweisstandards** (Common Law vs. Civil Law)
|
|
- **Internationale Rechtshilfe** erforderlich
|
|
|
|
## Qualitätssicherung und Audit
|
|
|
|
### Peer Review Verfahren
|
|
|
|
**4-Augen-Prinzip**:
|
|
```
|
|
Imaging-Protokoll:
|
|
Techniker A: _________________ (Durchführung)
|
|
Techniker B: _________________ (Verifikation)
|
|
Supervisor: __________________ (Freigabe)
|
|
```
|
|
|
|
**Hash-Verifikation Zeitplan**:
|
|
```
|
|
Initial: SHA256 bei Akquisition
|
|
Transport: Hash-Check vor/nach Transport
|
|
Labor: Hash-Check bei Laborankunft
|
|
Analyse: Hash-Check vor jeder Analyse
|
|
Archiv: Hash-Check bei Archivierung
|
|
Vernichtung: Final Hash-Check vor Vernichtung
|
|
```
|
|
|
|
### Continuous Monitoring
|
|
|
|
**Automated Integrity Checks**:
|
|
```bash
|
|
#!/bin/bash
|
|
# integrity_monitor.sh
|
|
|
|
EVIDENCE_DIR="/secure/evidence"
|
|
LOG_FILE="/var/log/evidence_integrity.log"
|
|
|
|
for evidence_file in "$EVIDENCE_DIR"/*.dd; do
|
|
stored_hash=$(cat "${evidence_file}.sha256")
|
|
current_hash=$(sha256sum "$evidence_file" | cut -d' ' -f1)
|
|
|
|
if [ "$stored_hash" != "$current_hash" ]; then
|
|
echo "ALERT: Integrity violation detected for $evidence_file" | \
|
|
tee -a "$LOG_FILE"
|
|
# Send immediate alert
|
|
mail -s "Evidence Integrity Alert" admin@forensics.org < \
|
|
"$LOG_FILE"
|
|
fi
|
|
done
|
|
```
|
|
|
|
## Internationale Gerichtspraxis
|
|
|
|
### Deutschland - BGH Rechtsprechung
|
|
|
|
**BGH 1 StR 142/18** (2018):
|
|
- Digitale Beweise müssen **nachvollziehbar erhoben** werden
|
|
- **Hash-Werte allein** reichen nicht aus
|
|
- **Gesamter Erhebungsprozess** muss dokumentiert sein
|
|
|
|
### USA - Federal Courts
|
|
|
|
**United States v. Tank (2018)**:
|
|
- **Authentication** unter Federal Rule 901(b)(9)
|
|
- **Best Practices** sind nicht immer **rechtlich erforderlich**
|
|
- **Totality of circumstances** entscheidet
|
|
|
|
### EU - EuGH Rechtsprechung
|
|
|
|
**Rechtssache C-203/15** (2016):
|
|
- **Grundrechte** vs. **Strafverfolgung**
|
|
- **Verhältnismäßigkeit** der Beweiserhebung
|
|
- **GDPR-Compliance** auch bei strafrechtlichen Ermittlungen
|
|
|
|
## Fallstudien aus der Praxis
|
|
|
|
### Case Study 1: Ransomware-Angriff Automobilhersteller
|
|
|
|
**Szenario**:
|
|
Ransomware-Angriff auf Produktionssysteme, 50+ Systeme betroffen
|
|
|
|
**CoC-Herausforderungen**:
|
|
- **Zeitdruck** durch Produktionsstillstand
|
|
- **Verschiedene Standorte** (Deutschland, Tschechien, Mexiko)
|
|
- **Rechtliche Anforderungen** in 3 Jurisdiktionen
|
|
|
|
**Lösung**:
|
|
```
|
|
Parallel Teams:
|
|
- Team 1: Incident Response (Live-Analyse)
|
|
- Team 2: Evidence Preservation (Imaging)
|
|
- Team 3: Documentation (CoC-Protokoll)
|
|
|
|
Zentrale Koordination:
|
|
- Shared CoC-Database (Cloud-basiert)
|
|
- Video-Calls für Custody-Transfers
|
|
- Digital Signatures für Remote-Bestätigung
|
|
```
|
|
|
|
**Lessons Learned**:
|
|
- **Vorab-Planung** für Multi-Jurisdiktion essentiell
|
|
- **Remote-CoC-Verfahren** erforderlich
|
|
- **24/7-Verfügbarkeit** der Dokumentationssysteme
|
|
|
|
### Case Study 2: Betrugsermittlung Finanzdienstleister
|
|
|
|
**Szenario**:
|
|
Verdacht auf Insiderhandel, E-Mail-Analyse von 500+ Mitarbeitern
|
|
|
|
**CoC-Komplexität**:
|
|
- **Privacy Laws** (GDPR, Bankengeheimnis)
|
|
- **Privileged Communications** (Anwalt-Mandant)
|
|
- **Regulatory Oversight** (BaFin, SEC)
|
|
|
|
**Chain of Custody Strategie**:
|
|
```
|
|
Segregated Processing:
|
|
1. Initial Triage (Automated)
|
|
2. Legal Review (Attorney-Client Privilege)
|
|
3. Regulatory Notification (Compliance)
|
|
4. Technical Analysis (Forensik-Team)
|
|
|
|
Access Controls:
|
|
- Role-based Evidence Access
|
|
- Need-to-know Principle
|
|
- Audit Log for every Access
|
|
```
|
|
|
|
## Technologie-Trends und Zukunftsausblick
|
|
|
|
### KI-basierte CoC-Automatisierung
|
|
|
|
**Machine Learning für Anomalie-Erkennung**:
|
|
```python
|
|
from sklearn.ensemble import IsolationForest
|
|
import pandas as pd
|
|
|
|
# CoC Event Anomaly Detection
|
|
def detect_custody_anomalies(custody_events):
|
|
"""
|
|
Detect unusual patterns in custody transfers
|
|
"""
|
|
features = pd.DataFrame(custody_events)
|
|
|
|
# Feature Engineering
|
|
features['time_delta'] = features['timestamp'].diff()
|
|
features['handler_changes'] = features['handler'].ne(features['handler'].shift())
|
|
|
|
# Anomaly Detection
|
|
model = IsolationForest(contamination=0.1)
|
|
anomalies = model.fit_predict(features.select_dtypes(include=[np.number]))
|
|
|
|
return features[anomalies == -1]
|
|
```
|
|
|
|
### Quantum-Safe Cryptography
|
|
|
|
**Vorbereitung auf Post-Quantum Era**:
|
|
```
|
|
Current: RSA-2048, SHA-256
|
|
Transitional: RSA-4096, SHA-3
|
|
Future: Lattice-based, Hash-based Signatures
|
|
```
|
|
|
|
### Cloud-Native Evidence Management
|
|
|
|
**Container-basierte Forensik-Pipelines**:
|
|
```yaml
|
|
# docker-compose.yml für Forensik-Lab
|
|
version: '3.8'
|
|
services:
|
|
evidence-intake:
|
|
image: forensics/evidence-intake:v2.1
|
|
volumes:
|
|
- ./evidence:/data
|
|
environment:
|
|
- AUTO_HASH=true
|
|
- BLOCKCHAIN_LOGGING=true
|
|
|
|
chain-tracker:
|
|
image: forensics/chain-tracker:v1.5
|
|
depends_on:
|
|
- postgres
|
|
environment:
|
|
- DATABASE_URL=postgresql://user:pass@postgres:5432/custody
|
|
```
|
|
|
|
## Best Practices Zusammenfassung
|
|
|
|
### Präventive Maßnahmen
|
|
|
|
**1. Standardisierte Verfahren**
|
|
```
|
|
□ SOPs für alle Custody-Schritte
|
|
□ Regelmäßige Team-Schulungen
|
|
□ Tool-Kalibrierung und -Wartung
|
|
□ Backup-Verfahren für Ausfälle
|
|
```
|
|
|
|
**2. Technische Safeguards**
|
|
```
|
|
□ Redundante Hash-Algorithmen
|
|
□ Automated Integrity Monitoring
|
|
□ Secure Transport Protocols
|
|
□ Environmental Monitoring
|
|
```
|
|
|
|
**3. Rechtliche Compliance**
|
|
```
|
|
□ Jurisdiction-spezifische SOPs
|
|
□ Regular Legal Updates
|
|
□ Attorney Consultation Process
|
|
□ International Cooperation Agreements
|
|
```
|
|
|
|
### Reaktive Maßnahmen
|
|
|
|
**Incident Response bei CoC-Verletzungen**:
|
|
```
|
|
1. Immediate Containment
|
|
- Stop all evidence processing
|
|
- Secure affected items
|
|
- Document incident details
|
|
|
|
2. Impact Assessment
|
|
- Determine scope of compromise
|
|
- Identify affected cases
|
|
- Assess legal implications
|
|
|
|
3. Remediation
|
|
- Re-establish chain where possible
|
|
- Alternative evidence strategies
|
|
- Legal notification requirements
|
|
|
|
4. Prevention
|
|
- Root cause analysis
|
|
- Process improvements
|
|
- Additional controls
|
|
```
|
|
|
|
## Fazit
|
|
|
|
Die Chain of Custody ist mehr als eine administrative Pflicht - sie ist das **Fundament der digitalen Forensik**. Ohne ordnungsgemäße Beweiskette können selbst die stärksten technischen Beweise vor Gericht wertlos werden.
|
|
|
|
**Schlüsselprinzipien für den Erfolg**:
|
|
|
|
1. **Vorbereitung ist alles** - SOPs und Tools vor dem Incident
|
|
2. **Dokumentation über alles** - Im Zweifel mehr dokumentieren
|
|
3. **Technologie als Enabler** - Automatisierung wo möglich
|
|
4. **Menschen im Fokus** - Training und Awareness entscheidend
|
|
5. **Kontinuierliche Verbesserung** - Lessons Learned Integration
|
|
|
|
Die Investition in robuste Chain of Custody Verfahren zahlt sich langfristig aus - durch höhere Erfolgsraten vor Gericht, reduzierte Compliance-Risiken und erhöhte Glaubwürdigkeit der forensischen Arbeit.
|
|
|
|
> **Merksatz**: "Eine Kette ist nur so stark wie ihr schwächstes Glied - in der digitalen Forensik ist das oft die menschliche Komponente, nicht die technische."
|
|
|
|
## Weiterführende Ressourcen
|
|
|
|
**Standards und Guidelines**:
|
|
- [ISO/IEC 27037:2012](https://www.iso.org/standard/44381.html) - Digital Evidence Guidelines
|
|
- [NIST SP 800-86](https://csrc.nist.gov/publications/detail/sp/800-86/final) - Computer Forensics Guide
|
|
- [RFC 3227](https://tools.ietf.org/html/rfc3227) - Evidence Collection Guidelines
|
|
|
|
**Training und Zertifizierung**:
|
|
- SANS FOR500 (Windows Forensic Analysis)
|
|
- SANS FOR508 (Advanced Incident Response)
|
|
- IACIS Certified Forensic Computer Examiner (CFCE)
|
|
- CISSP (Chain of Custody Domain)
|
|
|
|
**Tools und Software**:
|
|
- [FTK Imager](https://www.exterro.com/digital-forensics-software/ftk-imager) - Free Imaging Tool
|
|
- [Autopsy](https://www.sleuthkit.org/autopsy/) - Open Source Platform
|
|
- [MSAB XRY](https://www.msab.com/) - Mobile Forensics
|
|
- [Cellebrite UFED](https://www.cellebrite.com/) - Mobile Evidence Extraction |