Data comes in many forms, but all data needs protection — and at all times. You need end-to-end encryption to secure your data, whether at rest, in transit or in use.
People love their Ring doorbells, and with good reason — the popular internet of things (IoT) device allows you to see who is on your porch and communicate with them in real time from your phone or other devices.
But until recently, Ring systems had a vulnerability. Bad actors could physically break into the device mounted outside the home with two screws and steal your home’s network password. That gave them the keys to your virtual kingdom. In fact, data thieves could even access your network password without breaking into the device itself.
That’s because when the doorbell first connected to your home Wi-Fi, the connection provided an access point that did not rely on an HTTP address. In addition to stealing your network key, stories have circulated of troublemakers stealing videos from people’s Rings, inserting false people into their Ring videos, and other mischief.
What went wrong? While the Ring system and its predecessor, DoorBot, encrypted the video collected by the doorbell’s camera (is data), its storage location and when it moved within your secure home network, it had not encrypted the data while in use (watching the video).
Ring solved the problem by locking down data from start to finish with end-to-end encryption (E2EE). However, criminals exploit similar open doors every day.
Thinking Beyond Data at Rest and Data in Transit to Data in Use
Think of data flow like your mail: Your friend drops a sealed letter into a mailbox, which only the postal service can access. Then you both trust the postal service to carry that mail securely to its destination – your mailbox. But what happens once it’s in your mailbox ready for you to read? Unless your mailbox requires a key, it’s vulnerable to theft or abuse.
Data, like your mail, needs protection at every point, whether at rest (in the post office box), in transit (on the truck), or in use (while you are reading it). Like protecting online identities, endpoints and apps, E2EE is essential for protecting your or your company’s data.
The good news? There are tools available to help at all three stages. The bad news? Most people only think of data security in terms of storage (at rest) or moving within a network (in transit), forgetting about the vulnerabilities that can exist when data is in use.
This post in our Zero-Trust Architecture series will look at the products and techniques that can protect your data at all times, wherever it is.
Data at Rest
Various technologies can act like a secure envelope around your data. Typically, they use a form of transparent data encryption (TDE). TDE relies on a database encryption key (DEK) to protect data and log files. An additional layer of protection, known as a certificate, secures the DEK. Microsoft 365 Purview provides this level of protection for your data at rest.
You can apply even more security for personal identification information (PII) and personal/protected health information (PHI). You can base this additional protection on other factors, such as the endpoint you’re using or its geographic location.
Data in Transit
Most people are familiar with in-transit data protection. Tools such as transit layer security (TLS), TLS handshakes, one-time passwords (OTP), secure sockets layer (SSL) certificates, the advanced encryption standard (AES) and secure file transport protocol (SFTP) have been around for a while. In addition, Microsoft Outlook users may recognize Outlook Mail Encryption (OME).
Despite the flurry of abbreviations, these tools perform a similar task: acting like that secure mail truck when data is moving from one place to another. However, they all rely on solid identity and data governance. For example, you should require users to enable expiration dates on OTPs or external links to ensure they only access that data for the time needed.
Data in Use
Protecting data when in use, residing in RAM or being used to perform computations is the final point of end-to-end encryption. One tool is trusted execution environment (TEE) security. The TEE is an already secure portion of your computer’s main processor that protects data in use, but you can strengthen the TEE’s security with software that allows you to case the code on an individual user or at higher levels of privilege.
Other in-use protections available in the world of “confidential computing” are still emerging. One is homomorphic encryption (HE). It allows a user to use encrypted data without decrypting it first. HE has promise in fields such as healthcare, where PHI requires protection moving between a healthcare provider and an insurer.
For users of the Azure cloud, multiple TEE-based protections are available while others confidential computing tools are still in development. The AWS cloud’s Nitro System offers similar protections, but no matter the cloud, all these tools are committed to securing data as you are retrieving and using it — not just when it is in storage or moving within your system.
Conclusion
End-to-end encryption builds trust in data because it reduces the likelihood someone can steal or corrupt that data. It is like placing your mail in a safety deposit box inside your home rather than your vulnerable mailbox on the curb.
It is also another critical component of your Zero-Trust Architecture. To have a true Zero-Trust environment, you need not only a trusted person but also trusted apps, endpoints and data, all working within an allowed infrastructure and a defined network. In the final two posts in this series, we will explore infrastructure and network security, the backbone of Zero-Trust Architecture.