This chapter covers log preservation and chain of custody, two critical components of digital forensics and incident response (DFIR) that ensure the integrity and admissibility of digital evidence. For the CS0-003 exam, approximately 10-15% of questions in the Incident Response domain (Objective 3.3) test your ability to implement proper evidence handling procedures. Understanding how to preserve logs from tampering, maintain a provable chain of custody, and use cryptographic hashing to verify integrity is essential for passing the exam and performing real-world incident response.
Jump to a section
Imagine a crime scene investigator collects a bloody knife from a murder scene. They place it in a tamper-evident bag, seal it with a numbered evidence tape, and sign and date the seal. They then log the item in a secure evidence locker, recording who had access and when. Every time a detective, lab technician, or prosecutor handles the knife, they must sign a chain-of-custody form, noting the date, time, purpose, and any changes in the evidence's condition. If the seal is broken without proper documentation, the defense can argue the evidence was tampered with and have it excluded from trial. Similarly, in digital forensics, when you collect a log file from a compromised server, you must cryptographically hash it (like sealing the bag), record the hash, store it in a write-once medium (like a locked locker), and document every access. Without this chain, the log's integrity and admissibility in court or incident report are compromised. The hash acts as the tamper-evident seal — if the log changes even by one bit, the hash changes, proving alteration. The chain-of-custody log is the signed evidence tape showing every handler. Just as a crime lab rejects evidence with a broken seal, a court or internal investigation will reject logs without a verifiable chain of custody.
What Are Log Preservation and Chain of Custody?
Log preservation refers to the process of collecting, storing, and maintaining log files in a manner that prevents alteration, deletion, or corruption. Chain of custody is the documented history of who handled the evidence, when, why, and under what conditions. Together, they form the foundation of forensic soundness — the property that evidence is exactly as it was when collected and that its journey from collection to court is fully traceable.
Why They Exist
Digital evidence is inherently fragile. A single bit flip can change a log entry, and metadata such as timestamps can be easily modified. Without preservation, logs can be inadvertently overwritten, intentionally deleted, or corrupted by malware. Chain of custody exists to counter challenges to evidence authenticity. In legal proceedings, the opposing counsel will attack the evidence's integrity and handling. A well-documented chain of custody demonstrates that the evidence was not tampered with, making it admissible under rules like the Federal Rules of Evidence (FRE) Rule 901, which requires authentication.
How It Works Internally
#### Cryptographic Hashing for Integrity
The primary mechanism for log preservation is cryptographic hashing. When a log file is collected, a hash (e.g., SHA-256) is computed and recorded. Any subsequent verification computes the hash again and compares it to the original. If they match, the file has not been altered. The hash is stored in a secure location separate from the evidence. For example:
sha256sum syslog.log > syslog.log.sha256This produces a hash like:
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855#### Write-Once Media and Immutable Storage
Logs should be stored on write-once read-many (WORM) media or in immutable storage buckets. WORM media, such as optical discs (CD-R, DVD-R) or specialized WORM tapes, prevent data from being overwritten. In cloud environments, services like AWS S3 Object Lock with retention mode set to Compliance prevent deletion or modification until the retention period expires. For example:
aws s3api put-object-lock-configuration --bucket my-log-bucket --object-lock-configuration '{"ObjectLockEnabled": "Enabled", "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Days": 365}}}'This ensures that even the root user cannot delete or overwrite logs during the retention period.
#### Secure Logging Protocols
Logs should be transmitted and stored using secure protocols. Syslog with TLS (RFC 5425) encrypts log data in transit. For example, configuring rsyslog to use TCP with TLS:
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /etc/ssl/certs/ca-certificates.crt
$DefaultNetstreamDriverCertFile /etc/ssl/certs/server-cert.pem
$DefaultNetstreamDriverKeyFile /etc/ssl/private/server-key.pem
*.* @@(o)logserver.example.com:6514#### Timestamping and Time Synchronization
Timestamps must be accurate and verifiable. All systems should use NTP (Network Time Protocol) to synchronize clocks. RFC 3164 (syslog) and RFC 5424 (syslog) include timestamps. For forensic purposes, use NTP with authentication (NTPv4 with Autokey or symmetric key) to prevent time spoofing. Example ntp.conf:
server time.nist.gov iburst
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noqueryKey Components, Values, Defaults, and Timers
Hash algorithms: SHA-256 (recommended) or SHA-512. Avoid MD5 and SHA-1 due to collision vulnerabilities.
Retention periods: Vary by regulation (e.g., PCI DSS requires 1 year for logs, HIPAA requires 6 years). Common default: 90-365 days.
Log rotation: Logs should be rotated based on size (e.g., 100 MB) or time (e.g., daily). Old logs should be compressed and preserved.
Access controls: Only authorized personnel should have read access to preserved logs. Write access is strictly prohibited.
Chain of custody forms: Must include: evidence identifier, description, collector name, date/time of collection, location, hash values, and every transfer with signatures.
Configuration and Verification Commands
#### Collecting and Hashing Logs
# Collect logs from /var/log/
cp /var/log/syslog /evidence/syslog_20231001
# Generate hash
sha256sum /evidence/syslog_20231001 > /evidence/syslog_20231001.sha256
# Verify later
sha256sum -c /evidence/syslog_20231001.sha256#### Using a Log Management System (e.g., ELK Stack)
# Filebeat configuration to ship logs securely
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/*.log
output.elasticsearch:
hosts: ["https://logserver:9200"]
protocol: https
ssl.verification_mode: certificate#### Immutable Storage with AWS S3
# Enable versioning
aws s3api put-bucket-versioning --bucket my-log-bucket --versioning-configuration Status=Enabled
# Enable object lock
aws s3api put-object-lock-configuration --bucket my-log-bucket --object-lock-configuration '{"ObjectLockEnabled": "Enabled"}'Interaction with Related Technologies
Log preservation interacts with: - SIEM systems: Logs are ingested into SIEM for correlation. The SIEM must preserve original logs or their hashes to maintain chain of custody. - Endpoint Detection and Response (EDR): EDR agents collect logs and telemetry. These must be preserved in a tamper-proof manner. - CloudTrail / Audit Logs: Cloud providers offer native audit logs (e.g., AWS CloudTrail). Enable log file validation to create a hash chain. - Digital forensics tools: Tools like FTK Imager and EnCase preserve evidence using hashing and write-blockers.
Step-by-Step Process
Identification: Determine which logs are relevant (e.g., auth logs, firewall logs, system logs).
Collection: Copy logs using forensically sound methods (e.g., dd with write-blocker).
Hashing: Compute cryptographic hash of each file.
Documentation: Record all details in chain of custody form.
Storage: Store logs on WORM media or immutable storage.
Verification: Periodically verify hashes.
Access Control: Restrict access and log every access attempt.
Common Mistakes
Not hashing immediately: If you hash after copying to a non-forensic system, the hash may not match the original.
Storing hash with the evidence: An attacker could modify both the evidence and the hash file. Store hash separately.
Using weak hash algorithms: MD5 is not collision-resistant. Use SHA-256 or higher.
Poor time synchronization: Inaccurate timestamps can break the timeline of events.
Identify Relevant Log Sources
Determine which logs are critical for the investigation. Common sources include authentication logs (/var/log/auth.log), system logs (/var/log/syslog), firewall logs, web server access logs, and database logs. Prioritize logs that contain timestamps, user IDs, IP addresses, and event IDs. For example, in a breach investigation, focus on logs from the time of compromise. Document the source system, log type, and time range. Use commands like `last -f /var/log/wtmp` to review login records. Ensure the system clock is synchronized with NTP to avoid timestamp discrepancies.
Collect Logs Using Forensically Sound Methods
Use tools like `dd` or `foremost` to create a bit-for-bit copy of log files. For live systems, use `lsof` to ensure files are not being written during collection. For example: `sudo dd if=/var/log/syslog of=/evidence/syslog.img bs=512 conv=noerror,sync`. For network logs, capture packets using `tcpdump` with a write-blocker. Always use a hardware write-blocker when collecting from storage devices to prevent accidental modification. Label the evidence with a unique identifier, date, and time.
Compute Cryptographic Hashes
Immediately after collection, compute a hash of each log file using SHA-256. Example: `sha256sum /evidence/syslog.img > /evidence/syslog.img.sha256`. Record the hash in the chain of custody form. Store the hash file separately from the evidence (e.g., on a different system or encrypted USB). For large log collections, consider hashing the entire disk image. Verify the hash after any transfer or before analysis. Use `sha256sum -c` to check integrity.
Document Chain of Custody
Create a chain of custody form that includes: evidence ID, description (e.g., 'syslog from server XYZ, collected 2023-10-01 14:30 UTC'), collector name and signature, date/time of collection, hash value, and source location. Every time the evidence is transferred (e.g., to analyst, to lab), record the date/time, purpose, and both parties' signatures. Use a tamper-evident seal on physical media. For digital chain of custody, use a blockchain-based solution or a signed log file. Maintain the form in a secure location.
Store Logs on Immutable Media
Transfer the collected logs to write-once media or immutable cloud storage. For physical media, use CD-R or DVD-R discs, or WORM tapes. Label and store in a secure evidence locker. For cloud, enable object lock with compliance mode. Example AWS CLI: `aws s3api put-object-legal-hold --bucket my-bucket --key logs/syslog.img --legal-hold Status=ON`. Set retention period based on policy (e.g., 1 year). Ensure access is logged and restricted to authorized personnel only.
Verify Integrity Periodically
Schedule periodic hash verification to ensure logs have not been altered. For cloud storage, use AWS Config rules to detect changes. For physical media, re-hash every 6 months and compare to original. Document verification results. If a hash mismatch is found, immediately report and investigate. This step is crucial for maintaining admissibility in court. Use automated scripts to compare hashes and alert on discrepancies.
Control Access and Audit Activities
Implement strict access controls using the principle of least privilege. Only investigators and authorized personnel should have read access to preserved logs. Use multi-factor authentication for access. Enable logging of all access attempts (successful and failed) to the evidence storage. For example, use AWS CloudTrail to log S3 bucket access. Review audit logs regularly. Any access must be documented in the chain of custody form. This creates a complete audit trail.
In a real-world enterprise, log preservation and chain of custody are critical during incident response. Consider a scenario where a financial institution detects unauthorized access to customer data. The incident response team must collect logs from multiple sources: Active Directory authentication logs, database audit logs, firewall logs, and endpoint logs. The team uses a forensic workstation with write-blockers to image servers. Each log file is hashed with SHA-256 and the hash is stored in a secure database. Logs are copied to an AWS S3 bucket with Object Lock enabled in Compliance mode for 7 years (regulatory requirement). The chain of custody is maintained using a digital form that captures every access via CloudTrail. A common problem is that logs from cloud services (e.g., AWS CloudTrail) are already stored in S3, but the team must enable log file validation (which creates a digest file) to ensure integrity. Without this, logs could be modified and the change would go undetected. Another scenario involves a healthcare provider that must comply with HIPAA. They use a SIEM like Splunk to ingest logs, but the original logs must be preserved separately. They configure rsyslog to forward logs to a remote syslog server using TLS, and that server writes logs to WORM optical discs. The chain of custody is maintained manually with paper forms, but they are moving to a digital signature system. A common misconfiguration is setting the retention period too short, causing logs to be deleted before the investigation is complete. Also, if NTP is not configured, timestamps may be off by hours, making correlation impossible. In large environments, log volume can be terabytes per day, so compression and deduplication are used, but care must be taken to preserve original hashes before compression. The key is to automate as much as possible while maintaining forensic soundness.
The CS0-003 exam (Objective 3.3) tests your understanding of log preservation and chain of custody in the context of incident response. Expect 2-3 questions on these topics. The exam focuses on: (1) The importance of cryptographic hashing for integrity verification. (2) The correct order of steps in evidence handling: collect, hash, document, store. (3) The use of write-blockers to prevent modification. (4) The requirement for time synchronization. Common wrong answers include: (a) 'Use MD5 for faster hashing' — MD5 is not collision-resistant and is deprecated; SHA-256 is required. (b) 'Store the hash with the evidence for convenience' — this allows an attacker to modify both the evidence and hash; store separately. (c) 'Chain of custody is only needed for court' — it is also needed for internal investigations to maintain credibility. (d) 'Logs can be collected after analysis' — collection must happen first to preserve original state. The exam may present a scenario where a log file's hash does not match, and you must choose the correct action: reject the evidence and investigate the discrepancy. Numbers to remember: SHA-256 produces a 64-character hex string. Retention periods: PCI DSS 1 year, HIPAA 6 years, SOX 7 years. The exam loves edge cases: what if the system clock was wrong? You must note the discrepancy and adjust timestamps using NTP logs. Another edge case: what if the log file is encrypted? You must preserve the encrypted version and the decryption key separately. To eliminate wrong answers, focus on the mechanism: hashing proves integrity, chain of custody proves handling. If an answer suggests skipping a step or using a weak hash, it is wrong.
Always use SHA-256 or stronger for hashing log files; never use MD5.
Store hash values separately from the evidence to prevent tampering.
Document every transfer of evidence in a chain of custody form with signatures.
Use write-blockers when collecting logs from storage devices.
Synchronize system clocks using NTP to ensure accurate timestamps.
Enable object lock with compliance mode for cloud log storage.
Collect logs before performing any analysis to preserve original state.
These come up on the exam all the time. Here's how to tell them apart.
SHA-256
Produces 256-bit (64 hex char) hash
Collision-resistant (no known practical collisions)
Recommended by NIST and CompTIA
Slower than MD5 but acceptable for forensics
Used in `sha256sum` command
MD5
Produces 128-bit (32 hex char) hash
Collision attacks demonstrated (e.g., 2008 MD5 collision)
Deprecated for security applications
Faster but insecure
Used in `md5sum` command
WORM Storage
Write-once, read-many (cannot be overwritten)
Physical media like CD-R or optical discs
Immutable by design
Slower write speeds
Higher cost per GB
Standard Hard Drive
Read-write capable
Magnetic or SSD storage
Can be overwritten or deleted
Fast read/write speeds
Lower cost per GB
Mistake
MD5 is acceptable for log integrity verification.
Correct
MD5 is cryptographically broken and susceptible to collision attacks. CompTIA CySA+ expects SHA-256 or stronger. Use `sha256sum` not `md5sum`.
Mistake
Storing the hash alongside the log file is fine.
Correct
If an attacker modifies the log file, they can also recalculate the hash and overwrite the hash file. Store the hash in a separate, secure location, such as a different system or a signed document.
Mistake
Chain of custody is only necessary if the case goes to court.
Correct
Chain of custody is essential for any investigation to ensure evidence integrity and credibility. Internal investigations also require it to avoid disputes and maintain trust.
Mistake
Logs can be collected after the system has been analyzed.
Correct
Collection must be the first step. Analyzing a system can alter logs (e.g., by writing to disk). Always collect logs before any analysis to preserve the original state.
Mistake
A write-blocker is only needed for hard drives, not for log files.
Correct
Write-blockers prevent any accidental writes to the source media. Even when collecting specific log files, using a write-blocker ensures the entire filesystem remains unaltered.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
SHA-256 is the recommended hash algorithm. The exam expects you to know that MD5 and SHA-1 are deprecated due to collision vulnerabilities. SHA-256 produces a 64-character hexadecimal hash that is considered cryptographically secure. Use `sha256sum` on Linux or `Get-FileHash -Algorithm SHA256` on PowerShell.
If the hash file is stored with the evidence, an attacker who gains access to the evidence can modify both the log file and its hash, making the tampering undetectable. By storing the hash in a separate, secure location (e.g., a different server, a signed document, or a blockchain), you can independently verify integrity. The exam tests this concept frequently.
Chain of custody is the documented history of who handled the evidence, when, and why. Provenance is a broader term that includes the origin and history of the data. In forensics, chain of custody is a subset of provenance that focuses on custody transfers. Both are important for admissibility, but chain of custody is specifically about handling after collection.
Document the clock skew by comparing the system time to an authoritative NTP source. When analyzing logs, adjust timestamps by the known offset. In the chain of custody, note that timestamps may be inaccurate. The exam may test that you do not discard the logs but rather note the discrepancy and adjust accordingly.
A write-blocker is a hardware or software device that prevents any data from being written to the source drive during collection. This ensures that the original logs are not altered by the collection process. Even if you are only copying specific log files, using a write-blocker is a best practice to maintain forensic soundness.
You should hash the log file before compression. If you compress first, the hash will be of the compressed file, and you must preserve the compressed version. For integrity verification, it is simpler to hash the original uncompressed file and then compress for storage. Document the compression algorithm used.
PCI DSS requires log retention for at least one year, with the most recent three months immediately available for analysis. Other regulations have different requirements: HIPAA requires 6 years, SOX requires 7 years. The exam may test these values.
You've just covered Log Preservation and Chain of Custody — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?