How do you store data in such a way as to make it near impossible, or at least not worth attempting to hack?

Introducing the Quik! Vault to store client, form, rep and any other personal identifiable info (PII).

The Challenge

Storing private and confidential data in a secure manner is the challenge. With all the news and risks of data breaches, Quik! wanted a solution that would ensure data security, data integrity and data access to the owner. While Quik! uses all of the industry standards for securing systems (including things like TLS encryption, least-privilege access, firewalls, etc.) those standards aren’t enough. Eventually people break through those standards and access data. Thus, the real question is, how do you store data in such a way that it becomes secure and nearly impossible to breach beyond those industry standards?

The Solution

This document provides an overview but not all of the details for how the Quik! Vault was implemented to ensure security.

Tokenization Architecture

A key concept of our security model is to tokenize the private data we’re storing. Our team was inspired by other industry leaders including Amazon Web Services and Securosis who both have discussed building a tokenized data mechanism. The primary use-case that you will find tokenization used is with credit card numbers, whereas Quik! is applying this model to all the data that can be stored in the Quik! system.

The concept of tokenization is as follows:

A user enters sensitive, private data (like a credit card number)
The application passes the credit card to another system behind firewalls that stores the value encrypted and assigns a token to represent the value
The token value is stored in the application system instead of the sensitive data

Here’s the architecture diagram published by Securosis.

It’s important to note some key aspects to this architecture that help make it secure, following the numbered steps in the diagram.

The credit card number is passed from the application and not stored by the application - that ensures the sensitive value is essentially offsite from the public-facing application.
The token API must privately authenticate in order to do anything else. This authentication is highly restrictive, not accessible by any outside ports, systems or processes, and is restricted to a single process and/or private network. This means there is only one key that can be used to access the actual data, and that key only works within a specific security framework.
Once authenticated, the token API can communicate with the database to encrypt the data and return a token in it’s place. This is yet another layer of security because the encryption process takes place outside the token database, meaning if the database were breached there’s no way to decrypt the data without having access to the Token API too. Since the Token API and Token Database are on different hardware and different networks, potentially even different data centers, accessing both is exceptionally difficult.
The token database is only storing the token and the encrypted value without context as to what the token represents. If the database were breached and all the data were unencrypted, then what does the data actually represent? Or more importantly, what is the data related to? For example, a credit card without an expiration date, security code, zip code and address isn’t usable.
The token is returned to the application to be stored in the place of the encrypted value. Now, instead of simply encrypting data at rest, the data has been replaced by a token, or a proxy that represents the data but is not useful or meaningful on its own.
Finally, the application database is designed to facilitate finding records but not having access to the private data. In order to retrieve the private value the process must be reversed and all the security checks must be passed.

Thus, if our application is breached and a hacker sees what they think is sensitive data, they’ll be retrieving a token instead of the actual value.

Since a token is not the actual value, it is not an encrypted version of the value, it is useless and can never be converted into anything usable. The only way to get the real value is to know how to access the system that has the real value and to pass the security mechanisms to find the value.

This is an over-simplified explanation of the token architecture as compared to what was implemented at Quik!, however it should give you an idea of how the token architecture works.

Multiple Layers of Security

The data security strategy of Quik! Vault encompasses multiple layers:

Front-end user interface to enter, modify, delete and retrieve data
Front-end API layer to communicate between the front-end application and the back-end system
Internet Firewall between the front-end API and the Application Database
Vault Database to store application data along with tokens
Token API layer to communicate between the application database and the token database
Token Authorization layer to validate and authenticate the Token API to communicate
Token Security Network layer to keep communications between the Token API, Token Authorization and Token Database private and inaccessible via the internet
Token Database to store encrypted data

Quik! Vault Improves On Tokenization

While the exact design of the Quik! Vault architecture will remain private for security reasons, here are several ways in which Quik! improved upon the concepts of tokenization in order to secure data stored by Quik!.

Different Technologies

Each layer is built in a different technology platform requiring different skillsets. In fact, we have three different teams from three different companies that worked on this architecture, none of whom shared the source code with each other. From each team’s perspective, the other team’s work is like a black box with minimally exposed entry points and no knowledge of the inner workings. This approach also resulted in managing these technologies on different systems.

Different Systems

The components in each of the security layers listed above are built into different systems. This includes different servers, services, security groups, virtual private clouds, authentication methods, and data storage systems. By spreading out these components into a variety of distinct systems, Quik! has made it much harder to navigate between the systems and has created unique barriers to entry at each stage.

Different Encryption Methods

While Quik! leverages industry standard encryption methods, the actual encryption technology and protocol differs between these systems. For example, the authentication method for the application API is very different from the token API and there is no continuity between the two systems. As a result, breaking through one layer of security requires starting from scratch on the next layer as the encryption methods are completely different.

Furthermore, when a value is encrypted to be stored in the token database, each value is encrypted with it’s own unique encryption key. This means that if someone were to unencrypt a value without using the encryption method (i.e. having the source code to decrypt), they would not be able to unencrypt any further values with the keys they used for the first value - each value would take the same amount of effort to decrypt.

What Quik! Encrypts

The data being stored in Quik! is related to filling out forms. In essence, Quik! is storing individual fields of data that were entered onto a form (e.g. first name, last name, date of birth, etc.). What makes Quik! unique in the form of security is that every data point, every field value, is stored independently.

Let’s say a user saves a form they’re working on that has 100 fields on it. The Quik! Vault will store 100 unique records with one value per record. That means that each value on the form has it’s own record, it’s own token AND it’s own encryption. What makes this even more difficult is that the data is stored in a non-relational manner that makes it exceptionally difficult to know which fields belong together.

Ultimately, nobody knows whether the data in Quik! is of any value; the data stored in the Vault has no transactional history. Even if someone got to all the data, there is no proof that the data is real or valid because there is no information in Quik! that indicates if the data was successfully used in a transaction.

NOTE:

As mentioned, there are additional details in how the Quik! Vault was implemented that makes assembling data even harder to accomplish than what is described here. These steps will remain private to ensure this document doesn’t become a roadmap for breaching the Quik! system.

How Quik! Makes Data Available

All of the architecture and security in the world may only be as strong as the methods in which someone can access the data. The architecture of the Quik! Vault is designed to make breaching the system near impossible, and certainly not worth the effort to achieve. What about breaching the system by simply stealing a user’s password and impersonating a user? Certainly users can see their private data, so what’s protecting the user?

User Level Security

In order to use the Quik! Vault, users are required to use multi-factor authentication (MFA). While not fool-proof, MFA, coupled with the user’s password, makes accessing a user account very difficult. Since user passwords are not stored in Quik! the only way to get a user’s password is by breaching the user’s own password management system. Having done that, the hacker would also need the user’s MFA device or to intercept their MFA codes somehow, in order to gain access to the Quik! Vault.

User Segregation

Quik! users are naturally segregated from other users by the Quik! App and underlying system design. No user can log into their own account and access another user’s data. All data is segregated by users and their accounts. Unless the Quik! engineers introduce a bug that breaks this separation of users and their respective data (which is a rather difficult bug to create accidentally given the system’s design), there’s no possible way for a user to see another user’s records.

Viewing Data

Accessing the secure data using the Quik! App can be done in a few ways:

Open the Vault feature and view one client record at a time.

Notice the blue Quik! Vault icon. This will be your entry point to the feature.
Generate a form with selected records from the Vault to prefill onto the form.

These methods of access do not provide the user with a way to see all the details of all their records at once. Thus using screens in Quik! to view data is cumbersome and slow, yet effective and efficient for the purpose of choosing clients and filling out forms.

Exporting Data

If the Quik! Vault allows for data to be exported, that export is done in a few manners.

API access to Vault data is secured by digital certificate authentication between the API caller and the Quik! system. Setting up this authentication is a manual process between the API caller and the Quik! team that requires exchanging security credentials. Thus there is mutual trust established before the API can be called.
1. Vault API calls are restricted and rate limited.
Export functions in Vault requires certain user privileges, the user must re-enter their MFA code for each export request, and the export process is not instant and notifies the user when their data is ready, again requiring MFA to perform the final download.

Summary

The Quik! team has gone to exceptional lengths to ensure the Quik! Vault is the most secure place to store sensitive, private data. While there is always something more that can be done to improve upon security, this architecture balances Quik!'s need for speed, access to data and security when storing and retrieving data.

The executive team at Quik! understands the impact a data breach can have on customers and ultimately on the Quik! company itself. To put it in the words of our CEO, we all have to be able to sleep at night knowing our data is safe.

In 20 years of service, Quik! has never had a data breach. Should an attempt occur to gain access to our client’s sensitive data, we believe we have gone above and beyond in mitigating such a risk and creating sufficient deterrents and obstacles to make a breach near impossible and certainly not worth completing.

A Word of Caution

Our team welcomes feedback, comments and suggestions. However, we don’t welcome hackers, attacks or for anyone to try and prove themselves against our architecture. The purpose of this document is to give our customers and partners the same sense of security we have for the Quik! products, not to invite attempts to break our systems. Any such attempts to harm our systems will be responded to swiftly in all appropriate methods available to us to prosecute such attempts.

WHITE PAPER Quik! App Security

Client Data Security - Quik! Vault