At StoryCloud we’ve designed our platform, policies and procedures from the ground up to ensure the security of content we create, record and administer on behalf of our clients. The over-arching objectives of our information security architecture are captured succinctly by the so-called CIA triad:

  • Confidentiality:  ensuring that data can be accessed only by the people who have a right to do so;

  • Integrity:  ensuring that data is consistent, accurate and trustworthy from the moment it’s created until it’s destroyed;

  • Availability:  ensuring that people who have the right to access data can do so at all times.

To achieve these objectives, in the face of both explicit threats and the challenges of operating a complex technical organization, we must deploy many independent and inter-dependent controls of a technical and procedural nature at the same time. This paper gives an overview of these controls and details of some of the more important ones.

Network Architecture

StoryCloud records depositions on-site on Apple iOS® devices, using a proprietary iOS app. The app records the audio-video content directly to its own local storage first, then uploads the content — in real time if possible — directly to the Amazon Web Services (AWS) Simple Storage Service (S3), via the HTTPS internet protocol.* The app also communicates with StoryCloud application servers using a custom application programming interface (API) over HTTPS.

The StoryCloud servers, which are hosted in the AWS Elastic Compute Cloud (EC2), are responsible for managing the meta-data associated with deposition recordings, and for providing secure access over the web to this content, but not for storing the content itself: this remains on AWS S3 and is accessed directly from there when it needs to be downloaded or played.

The StoryCloud EC2 server instances are situated, behind a firewall and an application load balancer —both of which are distributed, highly available logical instances — within an AWS Virtual Private Cloud (VPC). StoryCloud also operates a separate VPC in order to perform logging and monitoring of the application servers: this operations VPC is accessible via a bastion host running a Virtual Private Network (VPN) server, but otherwise has no interfaces to the public internet.

*If the internet connection fails or the bandwidth is insufficient to keep up with the real-time upload, the app will complete the upload after the recording is over. The recorded content will be stored on the device in the mean time.

Technical Controls


Access to the AWS network infrastructure and the application are both restricted by strong authentication and role-based authorization controls.

All members of our operations group access AWS using individual password-protected AWS user accounts and multi-factor authentication (MFA) hardware devices. These AWS user accounts are assigned to roles that are associated with the minimum AWS access privileges needed to perform a given operations task.

At the application level, access by StoryCloud personnel and our clients to deposition data and metadata over the web is controlled by the StoryCloud servers via user accounts. The application enforces minimum password length and complexity for all user accounts, and optionally can perform multi-factor authentication at login using one-time access codes sent via SMS to the user’s registered mobile device. Users are also automatically logged out after a period of inactivity.

Within an active login session, a configurable authorization scheme restricts what a user can access. The most basic — hard-coded — control restricts a client user to viewing only material recorded for the client organization to which he or she is associated. However, even within a given organization, it’s possible to restrict the material that a given user can access, by creating groups of users and mapping them to groups of cases and/or depositions as required. At the same time, the ability to create, read, update and delete data objects can be controlled separately, so that for example one set of users may be able to view a deposition for a given case, but not set one up.

As mentioned above — assuming a user has permission to view or download a recorded deposition — the audio-video data is downloaded directly from AWS S3 by the user’s web browser. Permission to retrieve the S3-housed content is given by the StoryCloud application server, which constructs a signed URL on-demand for the active user session, providing time-limited access to the specific S3 object.

The StoryCloud API also authenticates and authorizes the iOS recording application before each recording session starts, to reduce the probability that a session or device can be spoofed.


Accesses or attempted accesses of recorded content and meta-data are logged, transferred to secure storage within the operations VPC, and presented for routine automated and manual analysis. This allows for proactive detection of actual unauthorized access, or issues that may lead to unauthorized access, and for estimation of the extent and risk exposed by unauthorized access after the fact.

The StoryCloud application servers record web and API requests, including information about the resources accessed and the user accessing them to local log files. These files are transferred regularly to an ELK stack (Elasticsearch/Logstash/Kibana) in the operations VPC, where the data is indexed and exposed for graphing and manual query.

All attempts to access to the deposition media stored in S3, including the access URL, are recorded by AWS and stored in a dedicated S3 bucket, from which they are regularly transferred for indexing and visualization by the ELK stack.

The application servers also have OSSEC Host Intrusion Detection System (HIDS) software installed. This software actively monitors all aspects of Unix system activity with file integrity monitoring, log monitoring, and process monitoring, and sends alerts to StoryCloud operations staff when it detects unusual activity.


Deposition content and meta-data are encrypted on the network using the Transport Level Security (TLS) protocol, and the content is encrypted at rest with the S3 service. This prevents unauthorized people with access to the physical network or storage devices from viewing or tampering with the data.

TLS is enabled on the upload connection from the recording device to S3, on all application API and web page connections, on S3 download connections when a user views or saves recorded content, and on all upload and download connections between StoryCloud application servers and S3 needed for content reformatting.

While at rest within S3, recorded content is encrypted using the 256-bit Advanced Encryption Standard (AES-256) cipher.

As a standard policy, StoryCloud also requires all employees’ computers to have full-disk encryption enabled, and for all removable devices or media on which deposition content may be stored for transmission to clients to be encrypted at the device or file level.


Recorded content and meta-data are backed up to separate media daily, with an option to ensure that the backup media is transferred to an alternate physical site. This provides for recovery of the data if the primary storage medium or site fails, or is inadvertently deleted at the application level. Amazon S3, the primary storage for recorded content, is itself designed to provide an estimated annual object-loss rate of 0.000000001%. As a further precaution against inadvertent deletion, the S3 data is backed up to the AWS Glacier long-term storage service daily. The Glacier service redundantly stores data in multiple facilities and on multiple archive devices within each facility. Glacier also performs regular, systematic data integrity checks and is built to be automatically self-healing.

Application meta-data is stored in the AWS Relational Database Service (RDS). Daily snapshots of the database contents are recorded daily and retained within RDS for approximately 1 month. As an option, standard database backups can also be taken daily and transferred to an offsite facility via the Secure File Transfer Protocol (SFTP).

As a matter of policy, to ensure that these processes are effective, StoryCloud performs an end-to-end restore-from-backup test for both S3 and RDS data twice per year.

Administrative Controls


StoryCloud performs background and reference checks on all potential hires, including criminal record checks where permitted. Credentials for access to internal systems, with permissions based on job role, are allocated as part of the checklist-based on-boarding process. All access credentials are disabled or removed in the first step of the termination process. Employees are also required to relinquish all company-provided equipment and media, and destroy all company-sourced data on termination.


The company develops and maintains a written security policy, and creates security training course material based on this policy. All employees are required to receive this training within the first month of employment, as well as annually and as needed when security policies or conditions change.