A Cyber Insurer Put a File Interface Over Forensic Evidence With a Files.com Amazon S3 Mount

A cyber insurance provider underwrites and services cyber policies while running incident response alongside its insurance business. That work includes forensic imaging and handling artifacts that establish how an incident happened.

Forensics produces evidence, and evidence means files. Disk images and attack artifacts accumulate with every engagement, and some of them are enormous. A single forensic archive can run to hundreds of gigabytes in one .tar file. The insurer needed ordinary file access to that evidence without moving it out of Amazon S3 or creating a second copy—and it needed that access governed through Okta. Files.com’s S3 Remote Server integration provided that layer.

An Archive of Hundreds of Gigabytes Rules Out a Second Copy

Amazon S3 gave the insurer object storage independent of any one machine. What S3 does not give a team on its own is a file interface. It is object storage reached through APIs and consoles, not folders a responder browses with permissions tied to the company directory.

Uploading the archive into a file platform’s own storage would have meant copying hundreds of gigabytes per case into a second store and holding the evidence in two places. The answer had to leave the data resident in the insurer’s bucket while giving the incident response team ordinary file operations over the artifacts.

Files.com as the Doorway, S3 as the Storage

The insurer’s IT team tested the Files.com integration against real forensic data before putting it into production. Rather than syncing copies into Files.com, the team settled on mount mode. The folders on the Files.com site are the bucket, and Files.com performs file operations directly against it while the objects stay in Amazon S3.

Today, a responder who needs an artifact opens a folder. A tar of several hundred gigabytes behaves like any other file in that folder, while the evidence remains in the insurer’s bucket.

The site itself is governed from Okta: users and groups are provisioned and deprovisioned automatically over SCIM, sign-in runs through single sign-on, and connections are restricted by IP allowlist. Putting the evidence behind Files.com put it behind that whole stack, with nothing extra to build.

Evidence Access With Minimal Administration

With the mount in production, Files.com became the shared access layer for the insurer’s forensic evidence rather than another storage destination. Responders work with artifacts as files and folders, while account access continues to follow the insurer’s directory.

The access layer also takes almost no effort to operate. The insurer’s IT team reports barely needing to touch the platform once the mount was in place.

A File Interface, Not a Destination

The insurer never migrated its forensic archive onto a file platform. It kept the archive in the Amazon S3 bucket it already used and made that bucket behave like one: folders, directory-governed access, and very large files handled as files.

For evidence this large, the answer was never to move the data. It was to put a file interface in front of where the data already lives.