Securing data at rest and data in motion

Creating a secure application requires many safeguards, but by far the most important are those that secure the data in the application. These are also the most difficult to implement.

When it comes to securing application data, there are two distinct types of data that must be secured:

• Data at rest. This is data that is stored in a datastore, database, cache, file system, or other repository. It includes everything from the application’s database, to log files, to system configuration files, to backups and archives.
• Data in motion. This is data that is being actively accessed and used by the application. It could be data that is being transferred from one part of the application to another part of the application, such as between client and server, or between two different applications or services.

A simple example of data at rest is your user profile in a SaaS application. This profile might include your username, password, profile picture, email address, physical address, and other contact information. It might include application information about how you are using the application. In a more local setting, data at rest includes all of the files stored on your computer—your spreadsheets, Word documents, presentations, photos, videos, everything.

A simple example of data in motion is the same SaaS application when it asks you for your username and password. That information is being transferred from your computer, tablet, or smartphone to the back-end servers of the SaaS application. While the data is being transmitted, it’s in motion. Any data you type on your keyboard, or send in an email, or put into a text message, or send in an API request—all of that is data in motion.

Techniques used for securing data at rest are far different from techniques used for securing data in motion.

Securing data at rest

There are two primary strategies for securing data at rest: Securing the system that stores the data, and encrypting the data itself.

A secured storage system is the least secure model. It involves ensuring that the database or datastore that contains the data is physically inaccessible from bad actors. This usually involves firewalls and other physical restrictions. While these are generally successful in keeping outside bad actors from accessing the data, if a bad actor does infiltrate your system, then all the data stored in the system becomes vulnerable to compromise. This model should only be used for less sensitive data.

A more secure method of storing sensitive data involves encrypting the data as it is stored. That way, if anyone were to attempt to access the stored data—from the inside or the outside—they wouldn’t be able to read or use the information without the proper encryption/decryption keys and permissions.

A critical issue with encrypting stored data is where and how you store the encryption keys. You do not want to store them in the same location as the data itself, as that removes the security advantages of decryption (for the same reason you don’t store the front door key to your home under your doormat). Instead, the keys should be stored in an independent location that is inaccessible to a bad actor if the storage system is breached.

There are many options for storing encryption/decryption keys—some simple and some complex. One excellent option for a cloud application is to use your cloud provider’s key storage service. For example, Amazon Web Services offers the AWS Key Management Service (KMS) for exactly this purpose. In addition to storing your encryption/decryption keys, such services provide assistance in organizing the keys and changing the keys regularly (key rotation) to keep them safe and secure.

Sometimes, securing data at rest is best done by not storing the data at all. A classic example is credit card information. There is little reason for most websites to ever store credit card information—encrypted or not—within the application. This applies to e-commerce stores as well as content subscription sites. Even sites that charge a customer’s credit card a recurring amount do not need to store the credit card information within the application.

Instead of storing credit card info, the best practice is to make use of a credit card processing service and let them store the info for you. Then you only need to store a token that refers to the credit card in order to give your application access to the credit card for a transaction.

There are many credit card processing services, including Stripe, Square, and PayPal. Additionally, some larger e-commerce stores provide credit card processing services, including Amazon and Shopify. These companies provide all the security capabilities and meet all the legal requirements to successfully store and process credit cards. By using tokens, you can still provide an interface to your customers that looks like you are natively processing the credit cards—yet you’ll never store the credit cards and hence never need to worry about their security.

Securing data in motion

Protecting data in motion is the process of preventing data from being hijacked as it is sent from one service to another, one application to another, or between a server and a client. Data in motion includes communications between internal services (such as between a shopping cart and a product catalog), communications between internal services and external services (such as a credit card processing service), and communications between internal services and a customer’s web browser or mobile application.

There are three primary risks for data in motion:

1. Data read. A data read risk means simply having the data viewed by a bad actor would create a compromising situation. Examples of data vulnerable to data read risk include passwords, credit card numbers, and personally identifiable information. When such sensitive data might be exposed, then protecting the data in transit from being read by a bad actor is critical.
2. Data change. A data change risk means sensitive data is vulnerable to being changed by a bad actor while it is being transmitted from one location to another. Changing inflight data could give a bad actor additional access to a system, or could damage the data and the consumer of the data in some manner. Examples include changing the dollar amount of a bank transfer, or changing the destination of a wire transfer.
3. Data origin change. A data origin risk means a bad actor could create data while making it look like the data was created by someone else. This threat is similar to the data change threat, and results in the same types of outcomes, but rather than changing existing data (such as the dollar amount of a deposit), the bad actor creates new data with new meaning. Examples include creating fraudulent bank transfers and issuing illegal or damaging requests on behalf of an unsuspecting victim.

When we think about protecting data in transit, we normally talk about encrypting the data. Encryption protects against both data read attacks and data change attacks. For data origin attacks, additional strategies must be used to ensure messages come from the proper location, such as authentication tokens, signed certificates, and other strategies.

In modern applications, the TLS (Transport Layer Security) and SSL (Secure Sockets Layer) are the primary tools used to protect in-transit data. These security protocols provide end-to-end encrypted communications, along with certificates to ensure proper origination of messages. Today, on-the-fly SSL encryption is so simple and commonplace that almost all web applications make use of SSL (specifically, the HTTPS protocol) for all webpage communications, whether sensitive data is being transferred or not.

Keeping data safe and secure is critical in most modern digital applications. Every modern business requires safe and secure communications in order to provide their business services. Bad actors abound, so keeping applications—and their data—safe and secure is critical to keeping your business operational.