Securing Data at Rest and in Motion

Bad actors abound. It's a fact of life. Your application is constantly under attack. While there are many reasons why a bad actor might attack your application, a common reason is to get access to your data. Data breaches are expensive, trust destroying company ending tragedies. So keeping data safe is absolutely critical to the successful operation of your business. But keeping data that's at rest, safe and secure is entirely different than keeping data that's in motion safe. Let's take a look at some of the ways applications can keep sensitive data safe while the data is stored in the database or is being transported over a network. Are you ready? Let's go. Creating a secure application requires many actions, but by far the most important are those that involve securing the data in the application. These are the most difficult actions. When it comes to securing application data there are two unique and distinct types of data that must be secured. The first is data at rest. This is data that is stored in a data store, database, cache, or other mechanism. This includes data anywhere from the applications database to log files to application and system configuration files. The second is data in motion. This is data that is being actively accessed and used by the application. Typically, from a security standpoint, it refers to data that is being transferred from one part of the application to another part of the application, or between two different applications or services. Let's take a look at some examples of each kind. An example of data at rest is your user profile on an online applications website. This might include things like your username, password, profile picture, email address, physical address and other contact information. It might include application information about how you're using a given application. In a more local setting, data at rest is all the files on your computer, your spreadsheets, word documents, presentations. Any file or document that you are storing on your computer. Data in the database is considered data at rest because it's being stored. It's not currently being used or transmitted anywhere. It's just sitting available in the database ready to be used. A simple example of data in motion in the same online application is when the application asks you to log in using your username and password. That information is being transferred from your computer, tablet, or phone to the backend servers of the web application. While it is being transmitted, the data is said to be 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. The key is this: the techniques you use to secure data at rest are very different than the techniques you use to secure data that's in motion. Let's take a look at each turn. First, data at rest. There are two primary strategies for securing data at rest, securing the storage mechanism used to store the data and encrypting the data itself. A secured storage mechanism is the least secure model. It involves ensuring that the database or data store that contains the data is physically inaccessible from bad actors. This usually involves firewalls and other physical restrictions. This works fine to keep outside bad actors from accessing the data, but if a bad actor is able to infiltrate your system, all data at rest stored this way is now vulnerable and can be compromised. 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 data from the inside or the outside, they won't be able to read and leverage the information without the proper encryption and decryption keys and permissions. A critical issue with encrypting stored data is where and how do 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 your front door key to your home, under your door mat. Instead, the key should be stored in an independent location that is inaccessible to a bad actor if the data at rest is compromised. There are many options, some simple and some complex. One excellent option for a cloud application is to use your cloud provider's key storage service. For example, AWS offers the AWS KMS, or key management service for exactly this purpose. In addition, destroying your encryption and decryption keys, such services provide assistance, and organizing the keys and changing the keys regularly. Sometimes securing data at rest is best done by not storing the data at all. A classic example is credit card information. There is very little reason for most modern websites to ever store credit card information encrypted or not anywhere within the application. This applies to e-commerce stores as well as things like content subscription sites. Even sites that charge a customer's credit card on a recurring amount do not need to store the credit card information within the application. Instead, the best practice is to make use of a credit card processing service, a third party service, and let them store the credit cards for you. Then you only need to store a token given to you by the processor that refers to the credit card in order to give your application access to the credit card for a given transaction. There are many credit card processing services including Stripe, Square and PayPal. Additionally, large e-commerce stores provide credit card processing services such as Amazon and Shopify. These companies provide all of the security requirements and meet all the legal restrictions 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 for yourself. Yet you'll never store the credit cards and hence never need to worry about their security. Now let's talk about data in transit. Protecting data and transit is the process of preventing data from being hijacked as it is sent from one service to another, one application to another, or to and from a customer. Data in transit involves both communications internally between internal services as well as communications externally between unrelated services or directly with a customer's web browser or mobile application. Here there are three primary risks for data in transit. The first data read. A data read threat is when sensitive data is sent between services. If data is useful or sensitive, if exposed, then protecting the data from being read by a bad actor in transit is critical. Data read risk means simply having the data read by a bad actor would be sufficient to generate a compromising situation. Examples of data read vulnerabilities include reading passwords, credit card numbers, and other personally identifiable data. The second risk is data change. A data change threat is when sensitive data is vulnerable for being changed by a bad actor, while it is being transmitted from one location to another. The bad actor changes in flight data. This could be used to give the bad actor additional access or could damage the data and the consumer of the data in some manner. Examples of data change vulnerabilities include changing the dollar amount of a bank transaction that's in transit, or the destination where a wire transfer is being sent. Such a change made in transit could positively impact the bad actor and negatively impact the proper recipient. The third risk for data in transit is data origin change. A data origin threat is when a bad actor can generate data and make it look like the data was created by someone else. This is similar to the data change threat and results in the same types of outcomes. But rather than simply changing data such as changing the dollar amount of a deposit, the bad actor can actually create new messages with new meanings. Examples of data origin vulnerabilities include creating fraudulent bank transfers from scratch, or 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. We do this to prevent 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, TLS and SSL are the primary tools to protect in-transit data. These 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 using the HTTPS protocol for all webpage communications, whether sensitive data is being transferred or not. Sites often do this to prevent data origin attacks. Keeping data safe and secure is critical in most modern digital applications. Virtually 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. Thank you for tuning into Modern Digital Business. We release new episodes every other Monday. We also occasionally release short topic episodes on Tuesdays, which we call Tech Tapas Tuesday. To make sure you get every new episode when they become available, click subscribe in your favorite podcast player or go to mdb.fm/listen. If you want to learn more from me than check out one of my books, courses, or articles by going to leeatchison.com and sign up for emails from me at mdb.fm/follow. Thank you for listening and welcome to the modern world of the modern digital business.