You have probably heard these phrases before. What exactly do they tell us?
Data is sensitive. During data lifetime, it goes through many “hands” and gets seen by many
“eyes”. When we want to protect sensitive data from exposure, we need to understand who we
protect against and what the points of exposure are.
We start with the following use case: we inserted data into a system and our data is saved on the
disk. Who do we not want to see our data and why? First, the malicious outsiders.
data we usually protect are the logins and passwords, because these pieces provide the “keys to
the locks”. We secure them with encryption. If we want to be more cautious, we encrypt all the
sensitive data on the disk – to protect against the case of theft or loss of the storage device itself.
This is especially relevant in light of the BYOD – bring your own device to work – trend. Even
the most cautious among us often leave laptops or tablets in cars unattended. The majority of us
are not intelligence agency operatives and are not trained to never leave a trace behind. The best
protection against a malicious outsider is ENCRYPTION.
However, almost 40% of data fraud happens not with outsiders, but with insiders. These cases
involve people accessing the data across the whole spectrum: from the CxO office with internal
trading cases to unscrupulous or naïve developers. Few developers, of course, are unscrupulous
or naïve. Yet, unfortunately, breaches do happen. All of us are well aware of the latest case of
an “insider threat”: the case of Mr. Snowden.
Regardless of his intentions, he demonstrated that
a developer, bound only contractually, has unrestricted access to data and, as such, can present
a threat. Encryption does not protect against insiders. A CxO sees the data naked because s/
he works with it in production. The developer sees encrypted data be it in production or non-
production. Now, guess, who has the keys to encryption when production data is recreated in
development as necessary in many scenarios? Yes, you guessed it right: the developer does!
The only protection against an unscrupulous CxO is legal recourse. However, there is both legal
recourse and technological protection against an unscrupulous or ‘naïve” developer - DATA
MASKING. Masked data retains the look and functionality of real data. It fits the field size,
passes unit tests and gives real numbers at performance testing - as it would in the production
With data masking, the only data that has real value is data in the production environment. The
environments outside of production have fake data that has significantly less value on the black
market. Data masking is NOT encryption but rather a "one-way street" to removing sensitive information.
The bottom line: fewer people have access to real data when we use data masking.
Developers do not have access to sensitive information, be it encrypted or not.
In the next blog posts, we will be talking about data at rest vs. data in transit, production data
masking scenarios, as well as how we decide on data sensitivity