Evidence Quarantine System

Overview#

When an investigator uploads a folder of files seized from a suspect's device, those files may contain ransomware, trojans, or other malicious code. Admitting them directly into the evidence repository without scanning creates a genuine risk: malware can spread to other evidence, corrupt files the forensic team depends on, or in the worst case compromise the systems analysts use to examine it. The Evidence Quarantine System intercepts every incoming file before it reaches the evidence store, scans it against multiple detection engines, and isolates any item that raises a concern until it is properly assessed.

The system acts as a mandatory gateway between the outside world and the evidence repository. Forensic integrity is preserved throughout quarantine and release: every scan result, isolation decision, and clearance action is documented with actor identity and timestamp, maintaining the chain of custody even for files that never pass the security check. Criminal investigation units, digital forensics labs, and corporate security teams all depend on this kind of automated screening to protect the integrity of their evidence holdings.

Key Features#

• Automated malware scanning with rapid processing for every incoming evidence file, triggered at the point of submission before admission to the repository
• Suspicious content analysis using multiple detection engines in parallel for broader coverage than any single scanner provides
• Threat intelligence integration for known malware signature matching against continuously updated threat feeds
• Automated isolation protocols that quarantine detected threats immediately, without waiting for analyst intervention, while preserving the forensic chain of custody
• Forensic integrity preservation throughout quarantine and release: original file hashes are computed and locked before any scanning occurs
• Quarantine lifecycle management covering detection, isolation, analyst review, resolution, and either clearance or retention as threat evidence
• Release workflow for cleared files with verification documentation confirming the file passed all checks before admission
• Reporting and metrics on threat detection rates, quarantine volumes, and resolution timelines for operational oversight

Use Cases#

• Scanning all incoming evidence uploads for malware before admitting them to the evidence repository, protecting forensic integrity of the broader collection
• Automatically isolating suspicious files while preserving the forensic chain of custody, so the file can still be examined as evidence even if it is malicious
• Integrating current threat intelligence feeds to detect known malicious signatures in evidence, including files from targeted intrusion cases where specific malware families are expected
• Managing quarantine release workflows with proper verification documentation for files that pass post-isolation review

Integration#

The Evidence Quarantine System connects with evidence management, threat intelligence feeds, and security monitoring systems.

Open Standards#

• FIPS 180-4 (SHA-256 / SHA-512 / SHA3-256): Every file is hashed using NIST-standardised SHA-256 as the primary integrity digest before quarantine processing, with SHA-512 and SHA3-256 recorded as backup hashes to satisfy chain-of-custody requirements and future-proof the integrity record.
• RFC 7693 (BLAKE2b): BLAKE2b is computed alongside the SHA-2 family as a performance-optimised secondary integrity hash, with all four digests stored in the evidence integrity record and verified on each custody transfer.
• FIPS 197 (AES-256): Quarantined objects are stored with AES-256 server-side encryption at rest, and evidence documents use AES-256-GCM as their declared encryption algorithm, consistent with the NIST block-cipher standard.
• OASIS STIX (Structured Threat Information Expression): The threat intelligence domain models Indicators of Compromise using STIX-aligned observable types (IP address, domain, URL, file hash, YARA rule, CVE), and enriches them from abuse.ch and AlienVault OTX feeds before the quarantine threat-assessment step.
• YARA: The IOC type catalogue explicitly includes yara_rule as a first-class indicator type, allowing YARA-format signatures from integrated threat feeds to be matched against files held in quarantine during the suspicious-content analysis phase.
• GraphQL (June 2018 specification): The full quarantine lifecycle, including listing quarantined files, approving or deleting items, and reading scan verdicts, is exposed through a GraphQL API using the Strawberry schema library, consistent with the GraphQL specification.
• MIME (RFC 2045 / 2046): Uploaded files carry MIME type metadata that is recorded in the evidence integrity record and used during quarantine triage to route files to the appropriate scanning and thumbnail pipelines.

Last Reviewed: 2026-02-09 Last Updated: 2026-04-14