All Encryption is Not the Same when Securing Big Data and IoT

Often we have customers who come to us in need of securing a new Big Data or IoT application, but assume from past experience that all encryption works the same way. And this is largely due to how most have thought about data-at-rest encryption, using AES keys to encrypt block-level storage, in bulk, without as much concern around the nuances of how the data would be used once it leaves a disk repository.

Big DataUsing traditional encryption approaches, there is still an assumption of data being encrypted inbound for storage, but then all bets are off when outbound to an application—the data is unencrypted into the clear to be used by applications. Sure, why not—the application security is some other guy’s problem, right?

But this perspective has a number of obvious problems for big data applications, the first being that the data is only protected at-rest, so what do you do when it needs to be used later? And secondly, while providing the illusion of high performance when storing massive amounts of data, the scalability issues become apparent when attempting to process a vast amount of data later in applications, securely. Is there a better way? Of course there is, that’s why you’re reading this rant.

Unlike typical data at-rest encryption that is used with enterprise key management and storage or server applications, Voltage SecureData enables an end-to-end framework for implementing data encryption with stateless key management—in use, in motion, and indeed, at-rest also. And it does so with high-volume scalability in mind. Unlike solutions that integrate with storage or IT systems, SecureData is data-centric—meaning that encryption is applied at a data field level (examples like a name, address, country ID and similar personal privacy elements in a personal record).

This approach enables flexibility to protect data at-rest, while also allowing for application usability (I’ll explain this more below), the best of both worlds—both storage and application owners can enable a data security scheme that meets both needs. Oh, and the network guys too, as the data protection is preserved as it’s moved around the enterprise network or beyond a firewall, regardless of an encrypted pipe. Nifty!

The integration toolkits for applying SecureData encryption support everything from IoT gateways, data lakes, servers, storage, and so on; however, since it’s data-centric, the encrypted data can also flow into legacy systems (such as mainframes) without any changes to those systems required, as SecureData uses a technique called format-preserving encryption (FPE) to make the data appear the same in structure. To typical applications, the data looks the same, but it operates as a surrogate value. This enables a complete end-to-end solution, in case the data moves in or out of an organization, even up to the cloud.

For SecureData Big Data and IoT applications in particular, there are three notable advantages over typical encryption approaches that you might use for block storage. 1) Format-preserving encryption looks the same as ordinary data, so no changes are required to how the data is processed, 2) Stateless key management is used which offers the massive scalability needed for IoT and big data storage and use, and 3) FPE enables contextual preservation, meaning, organizations are often able to run data analytics on de-identified or partially de-identified data, without the high risk of having a complete record of data elements exposed in the clear. And again, to applications processing the data, it looks the same—no schema updates required.

As an example, if you de-identify a user record, but reveal only a phone number prefix (+1 650 xxx xxxx), you can run analytics to determine the size of a customer base in a geographic region, without identifying individual users. The possibilities for selective exposure are unlimited and risk is greatly reduced, especially when data is exposed outside of an application, it becomes useless once context of use is lost, essentially neutralizing threats.

Many of our customers are now adopting a new model of simply de-identifying sensitive data and keeping it perpetually de-identified, only exposing specific elements on an as-needed basis depending on the application or a highly-targeted use case. Wouldn’t it be great to protect data, send it to the cloud for analytics processing in a protected state, and get back the results on-premise—having only the critical data elements de-identified, if needed, back on premises? That’s happening today with a lower-risk approach than moving between various encryption and decryption systems, some of which are hard to modify for enabling security retro-actively. Or worse, operating across environments where security controls are not in place or untrusted.

Organizations are now solving their Big Data, IoT, and beyond security problems by keeping data protected without gaps—anywhere and everywhere

Businesses are using SecureData for Big Data and IoT, credit card payments applications, and compliance such as GDPR (General Data Protection Regulation) to solve these high scale, high risk, data security problems, as today’s best examples of new challenges that require high scale and high flexibility. With format-preserving encryption having achieved the highest federal validation standard (FIPS 140-2), there’s really no trade-offs in moving to modern approaches that allow data security to persist, regardless of the system access controls that may or may not be in place, or the gaps in protection between on-premise or cloud. A data-centric approach covers all bases no matter where your data is stored or used.

For those organizations looking at their next Big Data or IoT application, the choice is clear—go beyond simply data at-rest to protect data anywhere and everywhere with Voltage SecureData.

The post All Encryption is Not the Same when Securing Big Data and IoT appeared first on Voltage.

*** This is a Security Bloggers Network syndicated blog from Voltage authored by Nathan Turajski. Read the original post at: