Data Security Policy

Introduction

Our platform delivers services to enterprise users to access their internal data using proprietary AI softwares. Each Enterprise customer will benefit from an L7-isolated environment that we call their vault, bringing a high-level of security while still benefiting from sharing underlying resources. Everything that is company-related will be stored inside this vault, encrypted at rest and in transit.

Security Principles

One vault per tenant

Each tenant has what we call a dedicated vault, which materialized as an L7-isolated environment using a unique Kubernetes namespace. In this unique namespace we deploy a dedicated:

Database & Message Bus
Private API
Private Workers
Dedicated disk partitions for all persistent data

Enterprise customers can request from us that we physically isolate the underlying compute — often called Secure-Compute in IaaS — this option comes at a premium since we won’t be able to share the underlying machines anymore.

Defense-in-Depth with the Onion model

Our security strategy employs a Defense-in-Depth approach, layering multiple security controls across the depth and breadth of our IT infrastructure just like the layers of an onion. This methodology ensures that if one control fails, others are in place to mitigate threats.

You can picture this strategy as the layers of an onion (see the following picture).

Security Onion Model

Network Security

We use enterprise-grade countermeasures against distributed denial of service attacks (DDoS), and application firewall policies (WAF) to reduce our surface of attack from the outside world.

Endpoint Security

We use a zero-trust policy to secure all our endpoints — external and internal ones. Our service mesh enforces this security policy at the cluster level, ensuring that all our internal and external services are communicating using secured channels. If one of our services tries to communicate in clear text, our service mesh will not allow it and terminate the communication before it even starts sending packets.

Application Security

Each tenant has an isolated namespace in which Documentalist code runs, which leads to a L7 network segmentation between tenants. This policy is enforced by our service mesh, restricting cross-namespace communications and volume attachments.

Our container security strategy has multiple measures to reduce our surface of attack:

Using minimal base docker images
Non-root user when running containers
Scanning our production containers against known vulnerabilities
Scanning our code base for known dependencies vulnerabilities

Data Security

Data is stored in per-tenant isolated volume claims in Kubernetes, these storage volumes are also bound to the tenant namespace and cannot be attached to another tenant by design. Data is encrypted at rest using AES-256 encryption, ensuring that stored information is secure against unauthorized access, and in the future our Enterprise customers will be able to request the use of their own encryption keys — a.k.a. Bring Your Own Key (BYOK). For data in transit, we use TLS 1.3 encryption and certificates issued by a trusted CA (Let’s Encrypt), protecting data as it moves inside your vault and also between our servers and user devices.

Physical Security

Our IaaS subprocessor (Scaleway) is securing its data-centers using the same approach of the Onion Model, limiting access to critical elements of its data-center to a short-list of employees. In all cases, since we encrypt data at rest, customers’ data are protected even in case of a data breach at the data-center level.

Access Control

At the Documentalist level, access controls are enforced through industry renown identity and access management (IAM) providers like Google Workspace, Microsoft Active Directory, Okta, JumpCloud, to name a few. The choice of IAM is made by the customer deploying a Documentalist vault.

Internally, access control is handled using the principle of least privilege, ensuring individuals have access only to the data and resources necessary for their role.

Employee security training

Regular security training for staff, coupled with a culture of security awareness, reinforces our human layer of defense to further increase our resilience against evolving cyber threats.

Contractor Access Policies

We operate all our operations on Scaleway — certified ISO-27001 — on their French data-centers.

Incident Response and Breach Protocol

Preparation

Training for responding quickly to an incident is critical, just like fire-escape drills in offices. We are going to dedicate one entire week per semester to practice just that, breaking parts of our platform intentionally. More technically, we will use our service mesh to intentionally trip circuit breakers inside our mesh of services and study our detection plan and mitigation plan.

Detection

Our detection strategy consists of relying on Cloudflare best-in-class security tools, a leader in cybersecurity practices. In addition, we will continuously monitor our infrastructure, looking for odd patterns in the usage of our kubernetes resources.

As soon as the security team reaches a size of two employees, we will use the concept of a blue and red team — where the blue team defends and the red team attacks.

Mitigation

For each identified risk — from our threat model — we develop and implement mitigation strategies to defend our service against the most important threats.

Notification

In case of a breach of data, we take the engagement to:

Notify all affected parties in less than 72-hours after the beginning of the incident;
Provide a transparent and non-technical summary of what happened;
Explain our immediate response and mitigation plan;
Guide users with actions to protect their accounts if necessary.

Post-mortem Analysis

Once the vulnerability has been mitigated and our impacted users notified, we can start the systematic process of writing a post-mortem report: a best practice of technical teams to collect all the storyline and evidence that led to the incident and learn from these mistakes.

A post-mortem document often led to the implementation of new security layers, by collaborating between the security team and the product team.

Continuous improvement

We will perform internal penetration testing audits on a regular basis, to proactively detect and fix security issues.