Security

We believe in security by design. Read about the steps we take to keep your data safe.

Data storage

Before we start with the technical stuff, here are a few remarks about data. Unless is geographically distributed across 75 edge locations, to guarantee a consistent performance rate across the globe. However, all data that we collect about visitors and customers is strictly separated from the rest of the application and services, and exclusively stored in Ireland, in the EU. See a full overview of all data points and their locations here.

So, all visitor data that Unless collects is stored electronically in Ireland, Europe, on the Amazon Web Services infrastructure, in their Eu-West-1 datacenter cluster. Our application servers and database servers run inside a Virtual Private Cloud. The database containing visitor and usage data is only accessible from the application servers and no outside sources are allowed to connect to the database. Our data retention times are no longer than 365 days.

Data collected through Unless is exclusively reserved for use by our users and customers. Unless does not make use of the data collected in any form or way unless consent is officially given by an admin of the Unless account, clearly outlining what the data will be used for.

Architecture

We believe in security by design. Consequences of this paradigm are for example that live mode operation is typically read-only and served from static data, and entirely hidden behind CDN network endpoints for DDOS protection. Edit mode controls are provided from an API which uses the same DDOS protection from an internal CDN distribution.

This architecture leads to the following.

  • DDoS mitigation systems that are integrated with edge services, reducing time-to-mitigate from minutes to subsecond.
  • Stateless SYN Flood mitigation techniques that proxy and verify incoming connections before passing them to the protected service.
  • Automatic traffic engineering systems that can disperse or isolate the impact of large volumetric DDoS attacks.
  • Application layer defense combined with firewalls.

The application layer itself is very hard to penetrate due to its serverless nature. Our infrastructure contains no OS maintenance, scaling responsibility or direct use of physical, virtual or cloud server instances - it's called a "serverless architecture", based on separate Lambda functions. Lambda functions are atomic blocks of code that fire on demand only, and do not exist when idle - which is why they are much harder to penetrate than traditional cloud server instances which have to be up and running at all times.

All data at rest is encrypted using FIPS 140-2 validated hardware security modules. Data transits over TLS using SHA-256 with RSA Encryption. In process (while being processed by a Lambda function), data is protected in the shielded Lambda container.

Development

Unless is a SaaS provider. This means that we do not ship new versions like software vendors do. We have one version, which is the service. This version is constantly the focus of our security protocols and efforts. Software developers are using secure coding standards, code is subject to reverse reviews and we perform automated unit tests continuously. Our software is tested internally, and critical features are released in beta to a select number of test customers for live field testing.

Live service

Once code passes formal code review, all further deployment procedures are automated and require no human intervention, with the exception of user testing. We monitor performance, availability and security continuously, using automated procedures as well as randomized manual checks.

Additional firewalls are in place exposing only the necessary ports through the internet and between different servers. Intrusion protection system (IPS) software is in place as a second layer of security, which will block access as soon as any suspicious login activity is detected. We use a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect our accounts and workloads.

Only Unless engineers which require such access to perform their job efficiently are given access. Different engineers are given different access rights on different system components as well depending on what their job requires. Engineers who do have access, have their own credentials. SSH Key-Based authentication is used for server access. Security access rights and privileges are reviewed monthly.

Patch management does not introduce additional vulnerabilities. We use a micro-services architecture that consists of replaceable components that can be updated without interdependency. This way we can apply very specific patches with bug-fixes to a specific function of the system, following our strict security policies.

On top of that, we use continuous data backups to keep your data safe in the case of system failure, offering point-in-time recovery (PITR). Full database backups are taken continuously, and are kept for thirty five days as an electronic copy. Databases are encrypted at rest and data is encrypted at transport. There is a retention policy, personal data is deleted, including data on paper, electronic files, databases and from backups. We encrypt data using 256-bit Advanced Encryption Standard (AES-256).

Organizational aspects

We allow customers to further improve their organizational security, by offering different user access levels.

  • Admins: all rights within a customer account
  • Publishers: everything except user management
  • Editors: only content editing, but no publishing.

The customer has the sole right of granting access to anyone. Unless employees have no access by default. Passwords are always hashed and salted using bCrypt. Additionally, data at rest and in motion is always encrypted by using TLS with at least 128-bit AES encryption. Data transport is over TLS using SHA-256 with RSA Encryption.