Monday, March 24, 2014

The Price for Non-Compliance



The homepage of the Catholic Archdiocese of Seattle is the last place one might expect to see the phrase “IRS TAX FRAUD SCAM” in a bright red box.  The conspicuous red box, which links to a legal notice in four languages and a letter straight from the Archbishop himself, is just one of many painful steps the Archdiocese has had to take in the week following the discovery of a data breach.  The breach exposed social security numbers and other sensitive personal information of some of the Archdiocese’s 90,000 employees and volunteers.

As the bright red notice demonstrates, the Archdiocese must now fulfil mandates from the scary side of legal compliance: what to do after sensitive data has already been compromised.  In some circumstances, the notice and reporting requirements, invasive legal investigations, fines, penalties, and sanctions have driven organizations into bankruptcy.

State and Federal agencies, like the IRS, are on the lookout for signs of data breaches such as the fraudulent tax returns that resulted from the Archdiocese breach.  However, organizations that control sensitive data like identity, financial, or health information are often subject to stringent requirements, like a duty to discover and report data breaches as early as possible.  Some of these requirements vary by state, but they generally involve massive fines that increase with the scale of the breach and any delays in discovering and reporting the breach.  The legal requirements also vary by industry.  For example, financial institutions subject to GLBA must provide their customers with notice every time their privacy policy changes, while schools subject to FERPA stand to lose all Federal funding if they divulge confidential student records to the wrong person.

The costly effects of a data breach do not end there.  Notification requirements can lead to negative media exposure and customer outrage.  Expenses, both voluntary and mandatory, often include legal fees, public relations costs, extra security, and programs aimed at restoring customer goodwill (like Target’s credit monitoring program).  If the Target breach is any example, blaming your organization’s contractors or service providers will do nothing to stem the tide of expenses after your sensitive data is compromised.

In data privacy compliance, an ounce of prevention is often worth a pound of cure.  If your organization deals with sensitive personal data, make sure you are aware of the compliance requirements for your industry and jurisdiction.  Having the right technological solutions in place to protect your data might just make the difference between profit and bankruptcy.

 By Harris Buller, J.D.
This article contains a general discussion and does not constitute legal advice.  If you encounter any of the issues discussed in this article, consult with an attorney.

Saturday, March 1, 2014

Masking? Encryption? Confusion of Sorts.

Masking is NOT encryption. Encryption is NOT enough.  

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.
The very first

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

environment.

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