阅读中文版本

Security Log Integrity Verification Workflow

Verify that security logs are complete and tamper-evident so investigations can trust the record.

Overview

Ensure security logs are complete, time-consistent, and tamper-evident.

This workflow is reusable across teams and environments; adapt the commands to your tooling while keeping the sequence and checkpoints intact.

Environment and prerequisites

• Central log storage
• Integrity mechanisms
• Clock synchronisation

Procedure

1. Check completeness

Verify expected sources are reporting and gaps are explained.

Expected state: No expected source is silently missing.

2. Verify tamper evidence

Confirm logs are write-once or hashed so alterations are detectable.

Expected state: Tampering would be evident.

3. Check time consistency

Confirm sources are time-synchronised and offsets are within tolerance.

Expected state: Correlation across sources is reliable.

4. Test the audit trail

Run a controlled action and confirm it appears in the central store.

Expected state: The pipeline from source to store works.

# confirm a controlled action reaches the central store
query-central-logs --filter 'action=test_probe' --since 5m

Verification

Confirm a controlled action is logged centrally, tamper evidence is in place, and time offsets are within tolerance.

Decision points

Trust the source or the central store?

• Verify end to end
• Trust the collector

Recommendation: Verify end to end; gaps often appear between the source and the store.

Immutability or hashing?

• Immutable storage where feasible
• Hashing chains

Recommendation: Prefer immutable storage; hashing chains are a lighter alternative.

Common failures

• Unnoticed log gaps hide malicious activity.
• Mutable logs lose evidentiary value.
• Clock skew breaks correlation.