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

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all languages in p
Keep reading

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 »