Automated forensic archiving with Wazuh and S3 needs tighter chain-of-custody

At a glance

What this is: This is a Wazuh guide to automating secure forensic archiving into Amazon S3 with Shuffle, focused on immutable evidence handling and chain-of-custody controls.

Why it matters: It matters because evidence integrity depends on identity, access, and retention controls around the archive, not just on detection or storage automation.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Wazuh's full guide to automated forensic archiving with Shuffle and S3

Context

Secure forensic archiving is about preserving evidence so it can survive investigation, audit, and legal scrutiny. In this workflow, the main governance gap is not detection, but whether the alert record can be altered, deleted, or accessed outside a controlled evidence path. The identity angle is real because the archive depends on IAM permissions, bucket policy enforcement, and tightly scoped automated access.

Wazuh frames the problem as a separation between live telemetry and preserved evidence. That separation is operationally useful, but it only works if storage controls, logging, and retention are enforced consistently across the archive lifecycle. For security teams, the starting point is typical: many environments collect alerts well before they define evidence custody rules.

Technical architecture matters because evidence handling is only as strong as the weakest write path, retention policy, or administrative override. The article’s example is useful because it shows how automation can improve consistency, but it also reveals how much trust is being placed in cloud storage and workflow permissions.

Key questions

Q: How should security teams govern automated evidence archiving in S3?

A: Use separate storage for preserved evidence, restrict the writing principal to upload-only access, and enforce immutable retention for the required period. The archive should be auditable, not just encrypted. Teams should also test denial paths so unauthorised principals cannot modify or replace evidence after ingestion.

Q: Why is chain of custody an identity problem as well as a storage problem?

A: Because the archive depends on which human and non-human identities can write, read, or change evidence objects. If a workflow account or admin role is over-scoped, the evidence path itself becomes a tampering surface. Governance must therefore cover principals, permissions, logging, and retention together.

Q: What breaks when Object Lock is used without tight bucket policies?

A: Immutability alone does not stop unauthorised writes, policy changes, or access to the wrong bucket path. If the wrong principal can upload or the bucket can be reconfigured, the archive may still be contaminated before retention begins. The control gap is governance around the write path.

Q: What should organisations do when forensic archives must satisfy compliance requirements?

A: Align retention, logging, and access controls to the longest applicable evidence-preservation obligation, then document how the archive is protected against deletion and alteration. The key is proving that the archive can survive review, audit, and legal challenge without relying on informal operator discipline.

Technical breakdown

How immutable evidence storage works in S3

Amazon S3 can support forensic archiving when versioning, Object Lock, and retention mode are used together. Versioning creates recoverable object history, while Object Lock in compliance mode prevents deletion or overwrite for the retention period. That matters because forensic evidence must remain unchanged from the time of ingestion through review and, where necessary, legal hold. The archive is not secure simply because it is encrypted. Integrity depends on write controls, immutability settings, and restricted administrative paths that prevent a privileged operator from bypassing retention.

Practical implication: treat the evidence bucket as a controlled evidence system and validate that Object Lock and retention cannot be relaxed by routine admins.

Why workflow identity matters for forensic archiving

The Shuffle automation acts as a non-human identity that can write to the archive, so its permissions define the trust boundary. Least privilege is essential here because the workflow only needs to upload evidence and read limited bucket metadata, not administer the bucket or enumerate unrelated storage. If that identity is over-scoped, the archive becomes vulnerable to tampering through the same account meant to protect it. In identity terms, the workflow account is a high-value service identity and should be governed like any other privileged NHI.

Practical implication: isolate the workflow IAM user, scope it to upload-only access, and review its permissions as a privileged NHI.

What logging and access validation add to chain of custody

Server access logging and Block Public Access do not preserve evidence by themselves, but they create the audit trail needed to prove that evidence remained controlled. Logging records requests against the archive bucket, while public access blocks reduce accidental exposure and unauthorised browsing. Together they support chain-of-custody evidence, especially when investigators need to show who could have touched the objects and when. Forensics breaks down when storage is immutable but invisible, because immutability without traceability is incomplete governance.

Practical implication: verify that access logs are written to a separate bucket and that public access controls are tested, not assumed.

Threat narrative

Attacker objective: The objective is to compromise or destroy the integrity of security evidence so investigators cannot trust the archive.

1. Entry occurs when a high-severity alert is generated from repeated failed SSH authentication, creating a forensic artifact that needs protection before the attacker can influence the record.
2. Escalation occurs if the evidence pipeline or archive identity has excessive permissions, allowing a workflow or operator to alter, overwrite, or delete stored alerts.
3. Impact is the loss of evidentiary integrity, which weakens incident response, compliance validation, and any later attempt to reconstruct the attack with confidence.

NHI Mgmt Group analysis

Immutable storage is not the same as governed evidence. Object Lock can preserve bytes, but it does not by itself establish chain of custody, access accountability, or retention policy discipline. The evidence archive is a governance system, not just a storage target, and that distinction matters for incident response and audit defensibility. Practitioners should judge forensic archiving by whether it can prove integrity end to end.

Workflow identities are part of the evidence trust model. The Shuffle integration is only as safe as the IAM user or role that writes into S3, which makes this a non-human identity governance problem as much as a storage problem. A service identity that can upload evidence must be tightly scoped, monitored, and lifecycle-managed like any privileged account. Practitioners should review archive automation as privileged NHI infrastructure.

Chain-of-custody failures often begin with over-broad write paths. This post highlights a specific failure mode we can call evidence-path overexposure, where the system that preserves evidence also has too much freedom to modify the archive. Encryption, versioning, and logging reduce risk, but they do not compensate for weak principal scoping or uncontrolled bucket policy changes. Practitioners should assume the archive itself is an attack surface.

Forensic controls now sit inside broader resilience and compliance programmes. The article’s retention discussion shows why evidence preservation has to align with legal, regulatory, and operational requirements rather than being handled ad hoc. Controls for audit trail retention, immutability, and access logging are becoming part of the same governance conversation as incident handling. Practitioners should align archive design with their existing control framework, not treat it as a one-off workflow.

What this signals

Automated evidence archiving will increasingly be evaluated as a privileged identity workflow rather than a storage convenience. The control question is whether the archive principal can be rotated, scoped, and audited like any other service account, which is why the NHI Lifecycle Management Guide belongs in this design discussion.

Evidence-path overexposure: if the same automation that preserves alerts can also rewrite or delete them, chain of custody becomes fragile no matter how strong the storage encryption looks. Teams should align archive governance with the access review logic in the Ultimate Guide to NHIs , Key Challenges and Risks.

The broader signal is that forensic readiness is moving closer to identity governance, retention policy, and auditability. Security teams that already manage service account lifecycle and privileged access will have the clearest path to making evidence archives defensible.

For practitioners

• Separate evidence storage from operational telemetry Store preserved alerts in a dedicated archive bucket with different access rules from live logging and SIEM data. Use a distinct write path so incident responders and platform admins cannot casually alter evidence objects.
• Treat the workflow account as a privileged NHI Restrict the automated writer to upload-only permissions plus minimal bucket metadata reads. Review the account on the same schedule you would use for privileged service accounts, including key rotation and offboarding.
• Enforce immutable retention on the evidence bucket Enable Object Lock in compliance mode where your legal and operational requirements demand tamper resistance. Test that deletion and overwrite attempts are blocked even for users with broader administrative access.
• Write access logs to a separate bucket Keep server access logs outside the evidence bucket and verify that logging is actually enabled. This creates a second record that supports chain-of-custody review if the primary archive is ever challenged.
• Validate bucket policy restrictions with real attack tests Attempt a manual upload from an unauthorised principal to confirm the deny logic works as intended. Use those tests to prove that only the intended workflow identity can write evidence objects.

Key takeaways

• This workflow shows that forensic archiving is a governance control, not just a storage configuration.
• The main risk is not whether evidence exists, but whether the archive identity and write path can be trusted.
• Teams should align immutability, logging, and least privilege before they rely on automated evidence preservation in production.

Key terms

• Chain of custody: A documented record that preserves the integrity of evidence from the moment an event is detected through investigation and response. In identity and data protection workflows, it helps prove what happened, when it happened, and which actor or session was involved.
• Object Lock: Object Lock is an S3 capability that prevents objects from being overwritten or deleted for a set retention period. In compliance mode, it supports immutable evidence handling by enforcing write-once, read-many behaviour, which is useful when evidence must survive investigation or legal review.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Evidence Path Overexposure: Evidence-path overexposure is a control failure where the automation or identity that preserves evidence also has too much authority over the archive. It creates a tampering risk because the same workflow meant to protect the record can alter, delete, or misroute it.

What's in the full article

Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Shuffle workflow configuration for archiving alerts into S3
• Exact bucket settings for block public access, server access logging, versioning, and Object Lock
• Sample IAM policy and bucket policy definitions for controlled write access
• Console validation steps showing how to confirm immutability and upload restrictions

👉 Wazuh's full post covers the workflow steps, bucket policies, and validation checks in implementation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect privileged workflows like evidence archiving to a broader identity control model.