Tokenization, Encryption and Compensation Controls

Security Matters. How do you know you are secure? One of the many practices is to run Threat Analysis considering attacking vectors. Threat Modeling should be a continuous activity. Movements like DevSecOps aim to put security on the day-to-day work. Cybersecurity Ventures predicts costs will grow 15% per year over the next five years reaching 10.5 Trillion USD by 2025. Security is a never-ending game. Security is something companies will need to do forever. IF they cost more and more, maybe we should get better and learn more about security. Lack of security can destroy a brand, and damage the customer's trust and relationship with your solutions. Security is difficult because it cannot be fixed in a central place with one tool, it requires principles and continuous fighting. There are infinite amounts of attack vectors. Common attacking vectors include compromised credentials: users/passwords, weak credentials: low entropy passwords, Insider Threats: from bad actors,  Misconfiguration: default configs, default users, Phishing: Social engineering attacks, Vulnerabilities: often in libraries, that trigger migrations, DDOS: hitting servers hard and limiting availability or even creating outages,  SQL Injection: Lack of sanitization and prepared statements results in disasters, Cross Site Scripting (XSS), Session Hijacking, Trojans, Man in the Middle, Ransomware: which is growing a lot, Missing or Poor encryption. Let's understand some options related to encryption.

Encryption

PII is often encrypted with a symmetrical key. Encryption requires a key an algorithm like AES, and some data points (cleartext). Using the Key + AES you can encrypt cleartext resulting in ciphertext. Using AES + Key and passing the ciphertext results in a cleartext decrypted. Sounds simple and straightforward right? No. Encryption is Hard. Symmetrical encryption has many challenges:

  • How many keys should we have? 
  • What systems should have access to what keys?
  • How often the keys will be rotated?
  • Where will the encryption happen?

Encryption often has performance implications. Basically, we can encrypt on the datastore side (if such a feature is available) or we can do it on the application side, also known as application-side encryption.

Application side encryption vs. Datastore side encryption

Datastore side encryption: Has some benefits, for instance, it is transparent for the application. What happens when multiple applications are accessing the shared database, well, Will all see the same data. Considering a Distributed monolith is datastore side encryption can be very problematic. Our main benefit here is that we can use the datastore in the full set of features. For instance, for a relational database, we can do joins and it is good that we can do engineering as usual.

Application side encryption: While it will be more secure, we can have more keys and different applications can use different keys, even with a distributed monolith we can reduce the blast radius, but only to some degree. For instance, if we have 5 applications that need to access the same table, there is nothing we can do, we need to share the same 5 across all 5 applications. The benefit comes as you dont need to share the same tables or different applications use different tables. Now the big drawback is that you can't use a bunch of features on the datastore, and joins might be completely lost. Full-text search is over, considering Redis, a bunch of commands will not work. Another drawback would be, what if engineers forget to encrypt data before sending it to the DB? 

Compensating Controls

Compensating control can be used instead of encryption or even as a solution to reduce the number of migrations. However, the best thing to do from a security perspective would be to use encryption alongside compensation controls.

Compensating Controls

Some examples of compensating controls are: segregating responsibilities, segregating environments, having strong logging and monitoring to be able to detect attacks and anomalies very fast, applying the last privilege principle consistently: only giving access to the exact roles needed, avoiding resource *, wide open permissions, sharing super users like admin or root, etc... A simple form of compensating control besides AWS IAM, is security groups, they are simple and effective.

Compensating controls might be the only measure in old and legacy systems where you might not have the source code and therefore might not have a better way to protect the application from within. One good thing about compensating controls is that often they can be applied on the infrastructure side, instead of the application side. Depending on your team topology, compensating controls might be on DevOps / Infosec teams instead of the service teams. PCI environments are a classical example of compensating controls.

Tokenization

Tokenization is a very interesting alternative to encryption and compensating control.Tokenization requires encryption and compensating controls as well. However, encryption tends to be centralized on the tokenization server or vault. 

Tokenization

Tokenization is growing nowadays, and there are open-source solutions like Open Privacy Vault and startups like Skyflow. It is not hard to build a tokenization solution. Not so easy to certify a PCI environment. However building the solution is not so complex, you have a token, which could be a simple UUID and that token is linked to a PII data point which should be encrypted. Using the token we can decrypt the data. 

Tokenization shines when we do not need to detokenize very often. IF your use cases require constant detokenization, classical encryption would be a better fit. Tokenization will require compensating controls as well. Tokenization also makes a lot of sense for Big Data. Tokenization requires compensating controls otherwise it would not be secure. Tokenization also needs to be approached with caution, for instance, if you have a shared tokens database where all services have read/write there you can create a Distributed Monolith.

Wrapping up

Security should be part of software architecture and should be a continuous practice not only a remediating act. We do have options depending on the use case. Encryption, Compensating controls, and Tokenization can be combined. All solutions have benefits and drawbacks, and tradeoff analysis alongside threat analysis is very important. Every time you have a new database, you need to be concerned with access and sharing, not only from the security perspective but also from the coupling perspective. 

Cheers,

Diego Pacheco

Popular posts from this blog

Kafka Streams with Java 15

Image
Kafka Streams is a Streaming library similar to Spark and Flink which works with Apache Kafka. Kafka stream can be useful to process historical and near-real-time big data workloads but also for non-realtime analytical computations at scale for the online world as well. Kafka-Streams is elastic, highly scalable, fault-tolerant, and fully integrated with Kafka. You can use Kafka Stream with Java, Scala, Kotlin JVM applications and also have exactly-once processing semantics. Kafka-Streams is being used by the New York Times, Pinterest, Line, Trivago, Zalando, and many other companies. Today I want to share a video of Kafka-Streams running with Kafka 2.6 and Java JDK 15. So Let's get started. 
read more »

Rust and Java Interoperability

Image
Rust does not stop for one second to amaze me. It looks like Rust was designed to talk to every other language so easily. No kidding, it's clear way Web Assembly and rust have lots in common. Java is never an easy lang to interop with. Today I will show how easily we can interop Java & Rust. In order to do so, we will need to use the Java and Rust compilers. For Java, we will not require any other lib than the standard JDK. For Rust, we will need to create a lib project in cargo and we will need to use the crate JNI. I love this feature because java does not allow low-level code on the main language. So if we need to do something low level, efficiently Rust is my first choice, not only for safety reasons but because is really fast.  Let's get started.
read more »

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail
read more »