{"id":6365,"date":"2025-05-27T10:00:37","date_gmt":"2025-05-27T10:00:37","guid":{"rendered":"https:\/\/www.urudata.com\/?p=6365"},"modified":"2026-01-08T16:53:36","modified_gmt":"2026-01-08T16:53:36","slug":"analizando-datos-sensibles","status":"publish","type":"post","link":"https:\/\/urudata.com\/en\/analizando-datos-sensibles\/","title":{"rendered":"Analyzing Sensitive Data"},"content":{"rendered":"

Although we create a secure environment when analyzing our clients' data \u2014 both from a technological standpoint (data encrypted at rest and in transit, hardened devices, perimeter security, and DLP tools, among others) and a legal one (NDAs with the company and involved technicians) \u2014 there are additional science- and technology-based measures that provide extra layers of security, and those are the ones we propose to review in this article.

The advice is to always remember the city of Gondor and its \"rings of defense\": if one barrier is breached, there must be another containment barrier ready to stop the attack or leak.

The great promise for protecting this type of data is \u201chomomorphic encryption\u201d (encryption that allows performing operations on encrypted data and then decrypting the result), but it is far from being usable beyond some specific cases with algorithms that are only partially homomorphic. Therefore, we don\u2019t use it nor waste time trying to use it.

The first practical case I want to discuss with you is differential privacy. Suppose we are analyzing very sensitive data, like a non-anonymous survey, or data that can be deanonymized with a correlation database.

A small correlation database, as simple as an old bank statement or phone data (in my case, I worked a long time with tokenized phone data), are good candidates for deanonymizing data. Just creating a recognizable pattern in the data is enough; for example, calling a number every 2 hours and hanging up after the first 5 seconds \u2014 doing this four times creates a pattern that surely allows individualizing that number in a tokenized (anonymized) database and from there triggering a network effect (who the person calls the most, and so on).

So, just tokenizing and adding some entropy to the data is not enough, but fortunately, we can apply differential privacy.
Let\u2019s suppose a very simple case: survey analysis. Suppose the worst case \u2014 the surveys, although made anonymous, have been deanonymized. How do we protect ourselves?

We will protect the question \u201cDo I feel comfortable with my boss?\u201d, which has yes or no answers. So, we take the survey data and leave half of it as it is. For the other half, for each answer, we flip a coin: if it\u2019s heads, we leave the data as is; if it\u2019s tails, we invert the value.<\/p>\n\n\n\n

This way, someone studying the survey knows that 75% of the data is true and 25% is inverted. The statistical result remains significant, but if someone takes a survey, deanonymizes it, and says \u201cThis answer is Pablo\u2019s!!\u201d they won\u2019t know my real answer, since the data is true with a 75% probability and false with a 25% probability. In this way, we have protected the privacy of the person who completed the survey.

Now, let\u2019s analyze another technique, and for that, let\u2019s take this to the extreme: suppose two rival companies competing \u2014 say, two local banks \u2014 competing but facing a shared challenge: stopping credit card fraud. It is obvious that if someone has data from both banks, they can train a better fraud detection algorithm, and the customers of both banks would be happier, freer, and would trust both banks more (this is a clear indicator that what we want to do is ethical since it increases customers\u2019 trust in banks and their well-being and freedom).

So, how can we train a fraud detection algorithm between Bank A and Bank B when they don\u2019t trust each other even a little?

We previously talked about encryption at rest (encrypted disk) and in transit (encrypted transport with TLS, Transport Layer Security), but there is a third type of encryption: encryption of the computer\u2019s memory and graphics card, known as encrypted processing, technically called a \u201csecure enclave.\u201d

The process works like this:<\/p>\n\n\n\n