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

At a glance

What this is: Wazuh describes an automated workflow that turns high-severity alerts into immutable S3 evidence objects while validating logging, access restrictions, and retention controls.

Why it matters: This matters because forensic integrity fails if evidence is writable, deletable, or poorly audited, and IAM teams need the archive path governed as carefully as the detection path.

Context

Automated forensic archiving is a governance problem before it is a storage problem. If evidence can be overwritten, deleted, or written by the wrong principal, the forensic record stops being reliable even when detection itself is sound. In this workflow, the key control question is not how alerts are generated, but how their payload is preserved with traceable custody and restricted write access.

The article sits at the intersection of incident response, cloud storage governance, and identity control. It makes that intersection explicit through least-privilege IAM access, bucket policy enforcement, access logging, and Object Lock, all applied to evidence retention rather than production telemetry. That is a typical problem pattern for teams trying to move from ad hoc preservation to defensible evidence handling.

Key questions

Q: What breaks when forensic evidence is written to cloud storage without immutable controls?

A: The chain of custody breaks because evidence can be overwritten, deleted, or altered after collection, which weakens later investigation and compliance validation. Immutable retention, restrictive write access, and access logging are what preserve evidentiary value. Without those controls, the archive becomes a convenience copy rather than a defensible record.

Q: Why do cloud evidence archives need identity and accountability controls?

A: Because the archive is only trustworthy if you can show which principal wrote the object, who could change the bucket policy, and whether access was logged. In practice, chain of custody depends on identity scope and auditability as much as on storage durability. If accountability is missing, evidence integrity is hard to defend.

Q: How should teams implement immutable forensic archiving in S3?

A: Use a dedicated bucket for evidence, restrict upload rights to a single automation identity, enable Object Lock in compliance mode, and send access logs to a separate logging bucket. Encrypt the objects, then verify that public access is blocked and write permissions cannot be expanded casually.

Q: Should organisations preserve alerts in the detection platform or in separate evidence storage?

A: Separate evidence storage is better when the goal is forensic defensibility. Detection platforms are optimised for analysis and response, while evidence repositories need immutability, traceability, and retention enforcement. Keeping those functions distinct reduces the risk that operational access or retention changes compromise the record.

Technical breakdown

Why evidence archiving needs a separate trust boundary

Forensic archiving only works when preserved evidence is separated from live telemetry and from day-to-day operational access. Live SIEM or XDR streams are designed for correlation and response, not immutable custody. Once alerts are copied into archival storage, the archive needs its own access model, logging path, and retention rules so the evidence object can be treated as a record rather than a mutable file. In the article’s pattern, the controlled S3 bucket becomes the custody boundary, while the detection platform remains the source of truth for alert generation.

Practical implication: define a distinct evidence repository with different access controls from your operational security platform.

How S3 controls support chain of custody

Amazon S3 can support evidence integrity when three controls work together: restrictive bucket policy, server access logging, and Object Lock retention. A bucket policy limits which principal can write objects. Access logging records who attempted to interact with the archive, which matters for auditability. Object Lock in compliance mode makes the object WORM, meaning it cannot be modified or deleted during the retention window. Encryption adds confidentiality, but immutability and traceability are what make the archive useful for later investigation or legal review.

Practical implication: treat immutability and audit logging as required evidence controls, not optional hardening.

Why automation can improve evidence handling but also widen control dependence

Automation removes manual steps that often break chain of custody, such as copying alerts by hand, renaming files inconsistently, or storing evidence in shared locations. But the trade-off is that the workflow itself becomes a trusted control path. If the IAM user, webhook, or storage policy is too broad, the automation can silently become a privileged write channel. That makes identity-scoped permissions, object-level restrictions, and integrity checks part of the evidence model, not just implementation details.

Practical implication: harden the workflow identity and validate the archive controls every time the pipeline changes.

Threat narrative

Attacker objective: The simulated attacker objective is to trigger a high-severity alert pattern that tests whether forensic evidence can be preserved without tampering or unauthorized overwrite.

1. Entry occurs through repeated SSH authentication failures that Wazuh correlates into a high-severity brute-force alert.
2. Credential abuse is prevented from becoming evidence tampering because only the workflow principal can upload to the archive bucket.
3. Impact is reduced because the alert payload is stored as an immutable object with logs that preserve custody and traceability.

Breaches seen in the wild

• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Chain-of-custody is an identity and governance problem, not just a storage feature. The article shows that evidence integrity depends on who can write, who can read, and who can alter retention settings. That puts IAM, logging, and immutability at the center of forensic readiness, not at the edge of it. Practitioners should treat the archive bucket as a governed control surface.

Immutability without custody controls is only partial protection. Object Lock protects stored objects, but the archive still depends on the identity of the workflow principal, the bucket policy, and the logging configuration. If those are mis-scoped, the forensic record can still be undermined before immutability even matters. Practitioners should validate the full evidence path, not only the storage setting.

Automated evidence handling creates a privileged machine identity that must be managed like any other NHI. The workflow user that writes to S3 is a non-human identity with meaningful authority over forensic records. That makes secret handling, least privilege, and offboarding of the workflow credential part of incident response governance. Practitioners should inventory evidence-automation identities with the same care used for other high-trust NHIs.

Forensic archiving exposes a useful control concept: evidence-plane hardening. The article’s value is not the use of S3 alone, but the idea that evidence storage needs its own hardening profile, separate from the telemetry pipeline. That is a practical extension of chain-of-custody thinking into cloud operations, where storage, logging, and access enforcement must remain inseparable. Practitioners should design a dedicated evidence plane and govern it explicitly.

What this signals

Evidence-plane hardening: teams should think about forensic archives as a dedicated control boundary with its own identity, logging, and retention rules. That separation matters because the same privileges that help automate response can also undermine custody if they are not tightly scoped.

The practical risk is not merely weak storage. It is an evidence workflow that behaves like a privileged write path without the governance discipline normally applied to high-trust machine identities, so organisations should inventory and review it with the same rigour as any other privileged service account.

For practitioners

• Define a separate evidence plane Isolate forensic storage from operational telemetry so preserved alerts are governed by different access and retention rules than live detections.
• Restrict writes to a single workflow principal Use bucket policy and IAM scoping so only the automation identity can upload evidence objects, and deny all other principals.
• Enable immutable retention on evidence buckets Apply Object Lock in compliance mode with a retention period aligned to investigation and regulatory needs so evidence cannot be altered or deleted.
• Turn on access logging for custody verification Send evidence-bucket access logs to a separate log bucket and review them as part of chain-of-custody validation.
• Treat the workflow identity as a privileged NHI Track the credentials, scope, and lifecycle of the automation user that writes evidence so it can be rotated or revoked like any other high-trust service account.

Key takeaways

• Automated evidence archiving only strengthens incident response if the archive is governed as a separate custody boundary, not as a storage afterthought.
• The article’s core controls are least-privilege write access, access logging, encryption, and immutable retention on the evidence bucket.
• The strongest control lesson is that the workflow identity itself is a privileged NHI and must be managed like one.

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.
• Evidence Plane: An evidence plane is a dedicated storage and control boundary for preserved security records. It separates forensic artifacts from operational telemetry so that access, retention, and audit rules can be stricter than those used for live incident response data.
• Privileged Automation: Privileged automation is any scripted or integrated process that can create, modify, or delete production assets with elevated authority. It reduces manual effort, but it also expands blast radius if the script, input data, or credentials are compromised. Governance must therefore cover both code and the credential behind it.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, to strengthen the identity controls behind automation-heavy security workflows.