Field level encryption and apps’ re-engineering

One of the most common concerns security engineers hear sounds like “field level encryption is awesome, but alas we can not afford it because we will need to completely rewrite the code and encryption will make everything slow”. 

I fully agree with the first part, field level encryption is awesome. As for the latter, literally, it could be translated as “we need help since our software development team has lots of other tasks to deal with and they are not experts in security and cryptography”. When the situation is taken in such a way, it’s no more a deadlock but a starting point for searching for appropriate teams, tools and solutions. 

First, it can be hard to believe, but in various cases, you can skip full re-engineering when implementing field level encryption. Let me explain this idea.

Quite often, the need for mitigating new threats or being compliant with some new regulatory requirements in terms of data security arrives out of the blue with strict deadlines. Your development and operations team can be unequipped for such abrupt changes.

Say, you’re a fintech company with a huge infrastructure and lots of apps operating customers’ data which was re-qualified as highly sensitive data. You must take immediate actions to protect this data across your numerous applications and in a rather tight timeframe. What can you do then?

In the first stage, the engineering team has to think of the security design under the new requirements and existing constraints. Think about how to change the dataflows and APIs to incorporate encryption. Here you pay attention to security policies (what fields are not considered sensitive and should be encrypted) and designing a key lifecycle (what apps should have access to plaintext fields, and how the data will look like for non-authorized apps). 

This exercise logically leads to a creation of a test environment where you can see how data security controls and configurations work in various circumstances. The most common pattern I usually see is building a data security layer – for example, adding a database encryption proxy or standalone encryption API service.

Search for appropriate tools and don’t roll your own cryptography. Field level encryption, data masking, data tokenization, etc. are available these days for any project’s needs. Technologies develop fast, and you can find vendors providing various sophisticated security tools or database security suites that require no changes in application code.

Typically, developers are not cryptography gurus, so select tools and vendors wisely – you don’t want to become a hostage of your own system. For example, with properly chosen tooling, you can encrypt large amounts of sensitive data “on a fly” with the API service, or put SQL proxy encryption service before MySQL databases for encryption, SQL firewalling, IDS, audit logging, etc. Choose that looks good to your scale, budget, and demands.

When everything is fine-tuned, it’s time for a smooth migration to the new deployment. Backup your data and ensure that migration scripts work won’t lose any rows. Do several rehearsals, and explicitly verify that data from the backup could be restored without issues (you will thank me later).

So, you can have the necessary elements for starting with field level encryption pretty close, with modern technologies allowing you to implement it with minimal changes in your code. Mainly, it takes more commitment to data protection than re-engineering.