CCSP Cloud Digital Forensics: Evidence Collection, Preservation and Management

Cloud digital forensics is the identification, collection, acquisition and preservation of digital evidence from cloud services so that it can be analysed and, if needed, presented to a court, a regulator or a disciplinary process. The goals are the same as on premises: capture the evidence before it changes, prove it has not been altered, and record everything done to it. What changes is reach and speed.

• No physical seizure. Customers control virtual resources, not the provider's drives, hosts or network. Evidence is acquired as copies (snapshots, images, log exports) through the provider's interfaces.
• Shared infrastructure. Physical hosts, disks and networks carry many tenants' data, so collection is scoped to the customer's own virtual resources.
• Volatility by design. Auto-scaling, container rescheduling and serverless execution destroy workloads in minutes, and provider logs age out on fixed retention windows.
• Dependence on the provider. Under PaaS and SaaS, most evidence exists only in the provider's logs and APIs, so what is available depends on configuration and on the contract.

CCSP sub-domain 5.4 covers three skills: forensic data collection methodologies, evidence management, and collecting, acquiring and preserving digital evidence. The chain-of-custody record itself and data-event logging are taught in the data event auditability lesson (sub-domain 2.8); responding to the incident and running the SOC belong to sub-domain 5.6; eDiscovery and the wider forensic standards family (ISO/IEC 27041, 27042, 27043, 27050) belong to the legal domain.

ISO/IEC 27037 gives guidelines for the first stage of an investigation: identification, collection, acquisition and preservation of potential digital evidence. It also states the principles that make the handling defensible.

Collection and acquisition are the near-twins: collection takes the device, acquisition takes a copy. Cloud forensics is almost entirely acquisition. Preservation is not a final step; it runs across every activity.

The four principles

The quickest way to separate repeatability from reproducibility is to ask what changed: if nothing but the time changed, it is repeatability; if the tools, lab or operator conditions changed and the method stayed the same, it is reproducibility.

Evidence is collected from the most volatile to the least volatile, so that sources that change or disappear first are captured first. RFC 3227 (Guidelines for Evidence Collection and Archiving) gives the classic order:

1. Registers and cache
2. Routing table, ARP cache, process table, kernel statistics and memory
3. Temporary file systems
4. Disk
5. Remote logging and monitoring data
6. Physical configuration and network topology
7. Archival media

In a cloud VM this means guest memory and live state (process list, connections, loaded modules, secrets in RAM) come first, then temporary file systems, then the attached volumes, and only then the logs the provider holds. Provider audit records and centrally shipped logs sit outside the compromised machine and keep their content regardless of what happens to it, while an attached volume keeps changing as long as the attacker is active. The order is set by volatility, not by which source is quickest to reach. The exception is a retention clock: a log that will be deleted soon is volatile in its own way, and must be preserved before it expires.

Because stopping, rebooting or terminating a cloud instance destroys memory, and stopping or terminating also wipes instance-local ephemeral disks. Memory exists only while the instance runs, so even a reboot clears it. Instance-local ephemeral disks (instance store, temporary or scratch disks on the physical host) generally survive a normal reboot but are wiped when the instance stops or terminates, and they cannot be snapshotted like network-attached volumes. Volumes set to delete on termination vanish with the instance. Network-attached persistent volumes survive a stop and can be snapshotted later.

So stopping a VM to get a quiescent disk image costs everything that exists only in RAM, such as process state, live connections and decrypted secrets (key material may be the only way to read encrypted data), plus anything staged on an ephemeral disk. The sound sequence is: capture memory and copy ephemeral storage live, then snapshot the persistent volumes.

Live acquisition always leaves a footprint

Any tool run on a live system changes some of its memory, so "no footprint" is not an option if memory is needed. Accepted practice is a minimal, documented footprint using trusted tools. The compromised host's own binaries cannot be trusted (an attacker may have replaced them), so the acquisition tool comes from a known-good source; in the cloud that is typically a clean, separately attached tool volume rather than physical media. The responder records what was run, when and what it changed. An approach that avoids the footprint by not touching the live system also gives up the memory it was meant to protect.

Contain it by isolating it while it keeps running, after first taking it out of any automation that would replace it. Terminating or stopping an instance contains the attacker but destroys volatile evidence.

• Detach from auto-scaling and load balancing first. A quarantined instance fails its health checks, and a scaling group terminates and replaces unhealthy or stopped members within minutes. Detaching takes it out of the group's lifecycle management, so isolation no longer triggers termination. Any measure that leaves the instance under the group's health checks still gets it replaced; only removing it from the group's management stops that.
• Isolate at the network layer. Replace the instance's network rules with a quarantine set that admits only the forensic team. Memory and volumes stay intact for acquisition.
• Make sure isolation ends sessions already in progress. Stateful firewall rules (such as typical security groups) track connections, and changing the rules often leaves existing tracked connections alive. To cut an active session, use a stateless control such as a subnet network access list, or a mechanism that drops established flows. Containment that leaves an open session running has not contained anything, so it comes before acquisition when damage is ongoing.
• Revoking credentials is not network containment. Revoking the instance's role or keys stops new API calls with those credentials but does not end a data transfer already flowing over an open connection.
• Containers: freeze rather than end. Pausing a container freezes its processes in place; memory stays allocated and the writable file-system layer stays on the host, so both can be acquired. Any action that ends the processes gives up their memory, whatever it does to the file system.

Preserving evidence and limiting damage are rarely in real conflict: isolating the running workload serves both. The conflict appears only when containment is achieved by stopping or terminating the workload.

Disk evidence is acquired by snapshotting the virtual volume through the provider's API. A snapshot is a block-level, point-in-time copy of the volume, including previously written blocks the file system has since freed, so deleted-file remnants can often be carved from volumes created from it (blocks that were never written simply read as zeros). Methods that copy files rather than blocks miss freed space and file-system metadata, and any image taken before the incident cannot show it.

Copy the evidence out of the compromised account

When the attacker may still hold administrator rights in the production account, anything left there (the snapshot, an analysis workstation, a volume) can be read, altered or deleted. The snapshot is shared or copied into a separate forensic account, volumes are created from the copy there and attached to a forensic workstation. The original snapshot stays untouched as the master. No step of the analysis should rely on the compromised system's own tools or kernel, because they cannot be trusted.

Multi-volume consistency

When data is spread across several volumes, each volume's state only makes sense relative to the others. Separate snapshots capture separate moments, and the reassembled data can be inconsistent. Most providers offer multi-volume, crash-consistent snapshots that capture every attached volume at the same instant without stopping the instance. Stopping the VM would also give consistency, but at the cost of memory.

Proving integrity without a hardware write blocker

In IaaS there is no physical drive to put a write blocker in front of, so the same assurance comes from process and cryptography:

• The acquired snapshot is a point-in-time copy that is never mounted for writing; analysis uses volumes created from it.
• Derived volumes are attached read-only, and the protection sits at the block-device level. Some providers offer no read-only attachment, and a file-system read-only mount of a journaling file system (ext4, for example) can still replay its journal and change the volume. The examiner disables automatic mounting on the forensic workstation and sets the device itself read-only before anything touches it.
• Hashes are recorded at acquisition for the master copy and re-verified before analysis. A working copy is proven identical by comparing its hash with the recorded master hash. The reference value must be fixed at acquisition: a source that keeps changing cannot serve as one, and attributes other than a cryptographic hash of the content can match while the content differs.

Hash comparison detects a change after it happens; read-only handling prevents it. Both are needed. Encryption is not an integrity control: it protects confidentiality (who can read the evidence), not whether it was altered, and it does not stop writes to a volume that is mounted and unlocked.

Forensic reach follows the shared-responsibility split: the customer can acquire evidence from the layers it manages and depends on the provider for everything below.

Act inside the retention window

PaaS and SaaS evidence lives in provider logs with fixed retention. If a tenant audit log is kept for a set number of days, the first action in a late-starting investigation is to export and hash the records before they age out. Automated deletion is stopped only by copying the records out, so the export comes first and everything else can follow.

Point-in-time state in managed services

In a managed service the state at the moment of an attack is usually gone by the time anyone looks, because the service has kept changing, and the provider will not image its shared servers. Where the service keeps its own point-in-time recovery, restoring to the relevant moment into an isolated forensic instance recovers that historical state while keeping the copy away from the compromised environment.

Ephemeral and serverless workloads

Containers, auto-scaled instances and functions are disposable: when one is rescheduled or scaled in, its memory, ephemeral disk and delete-on-termination volumes go with it. What survives is what left beforehand, chiefly logs shipped continuously to a central, separately protected store (container output, runtime security events, orchestrator audit logs). Anything kept on the short-lived infrastructure itself shares its fate, so the durable answer is shipping evidence off the workload continuously, not keeping more of it on the workload. For a compromised function, the evidence is the deployed package and version with its configuration, plus the provider's invocation logs. The source repository is not proof of what ran, because dependencies are resolved at build time and the repository may differ from the release.

Physical resources in a public cloud hold many tenants' data at once, so providers do not hand customers host memory, physical disks or shared network captures; doing so would disclose other customers' processes and data. The customer collects from its own virtual resources instead, which usually provides what is needed:

• Memory: acquired from inside the customer's own VM, not as a host dump. Guest memory is part of host memory, which is exactly why the host dump is refused.
• Deleted files: carved from a block-level snapshot of the customer's virtual volume, not from an image of the host's physical disks.
• Packet payloads: obtained by mirroring the VM's virtual interface traffic to a customer-owned capture appliance. Flow logs and DNS query logs are metadata (who talked to whom, which names were resolved) with no payloads. Promiscuous mode does not help, because a virtual switch delivers only the frames addressed to that VM.
• Provider-side logs: when host-level logs mix tenants, the workable route is an extract the provider filters to the customer's own resources.

Contract terms that make provider-side evidence available

Evidence the customer cannot collect itself must be secured in the contract, before an incident. The useful terms are:

• Retention of named logs (hypervisor, host network, management plane) for a contracted period long enough to cover how late incidents are typically discovered.
• Preservation on request: the provider freezes relevant data once the customer asks.
• Log access and supply: which logs will be provided, in what format, within what timeframe.
• Tenant-scoped extracts of shared logs, so the provider can disclose them without breaching other tenants' confidentiality.
• Investigative assistance and response times for forensic support.

Retention and preservation-on-request are near-twins that fail differently: preservation only protects what still exists when the request arrives. Where discovery typically lags behind the default retention period, a preservation request arrives after the data is gone, so only contracted retention closes that gap.

Several familiar terms do not produce case evidence. Breach notification triggers awareness, not access. SOC 2 Type II reports and right-to-audit clauses give assurance that controls work, not the records of a specific incident. Any arrangement that gives the customer sight of other tenants' records, however it is controlled, meets the same multitenancy objection.

Forensic readiness is everything put in place before an incident so that evidence exists and can be collected quickly and defensibly. Anything done after an incident has started, however necessary, is response rather than readiness.

• Logging and retention first. Enable provider audit logs, network flow records and operating-system and application logs, and ship them to a separate protected store with retention long enough for the organisation's typical dwell time. Nothing recovers a log that was never written, whatever tools or skills the team has, so logging is the foundation every other readiness investment depends on.
• Isolated forensic accounts with prepared workstations, tool volumes and evidence storage.
• Pre-provisioned, tested collection roles. A role scoped to collection actions (snapshot, copy, tag, read logs), approved and tested in advance, lets responders act in minutes without broad rights. Readiness here means speed and least privilege together: the access already exists, is narrow, and has been proven to work before anyone needs it.
• Agreed provider support and contract terms (previous section), plus documented procedures that reflect each service model.

Evidence is stored so that it stays authentic, available and demonstrably handled, and it is managed from acquisition until authorised disposal.

Storage

• A dedicated evidence account, separate from the compromised environment.
• Write-once (WORM) retention so evidence cannot be altered or deleted. Many stores offer two modes: one that privileged users can bypass and a strict lock that no principal, including administrators, can shorten or lift before it expires. Choose the mode by asking who must be unable to delete: if that includes administrators of the evidence store, only the strict lock qualifies, because a protection an administrator can configure is one an administrator can undo.
• Least-privilege, logged access, which supports the chain of custody.
• Encryption keys controlled outside the compromised environment. Immutable ciphertext is useless if the key is disabled or scheduled for deletion. Where the key lives matters as much as where the data lives: evidence protected by a key the attacker could administer is re-encrypted under a key controlled in the forensic account.

A store chosen for convenience usually delivers one of these properties; evidence storage needs all four together.

Identification and inventory

Every item gets its own unique identifier at acquisition, recorded in an evidence inventory with its source resource, acquisition time, who acquired it, its hash and its storage location. Identification must tell every item apart: a label shared by several items is not an identifier, however consistently it is applied. The inventory is the anchor the chain-of-custody record (sub-domain 2.8) builds on.

Retention, legal holds and disposition

Closing an investigation does not end the evidence's legal life: appeals, litigation, regulatory inquiries and legal holds can require it long afterwards. Disposal is tied to confirmation, usually from counsel, that retention duties and legal holds have ended, and the disposal itself is authorised and recorded.

A legal hold suspends normal disposal. When a data subject asks for erasure of personal data held in evidence under a hold, GDPR Article 17(3)(e) exempts data needed for the establishment, exercise or defence of legal claims. The evidence stays intact, because a held item must remain exactly as acquired, and the controller still answers the request within the GDPR deadline, explaining the exemption. The hold changes what is erased, not whether the data subject gets a timely reply.

Moving evidence across borders

Evidence that contains personal data carries that data's legal obligations with it, so the deciding question is legal: which data protection law governs the records, and whether it permits them to leave their jurisdiction. A snapshot copied from one region to another is a transfer of every record on it.

• Preserve and analyse in-region while counsel decides. Where the source jurisdiction restricts transfers, a forensic environment in the same region keeps the investigation moving without making an unlawful transfer.
• Use a lawful transfer mechanism. Under GDPR Chapter V, sending personal data to any recipient in a third country without an adequacy decision, an outside investigator included, needs an approved mechanism: standard contractual clauses for an outside firm, binding corporate rules only for transfers within the organisation's own corporate group, or a narrow derogation. Forensic images are not exempt because they are evidence. Security safeguards protect data in transit but do not create a legal basis for moving it, so counsel confirms the mechanism before the images leave.