Liability of Working with Customer Data
Another incident reported in the press highlighted the need for developers, consultants and analysts to be careful with client data containing sensitive data like names, addresses, SSN, and credit/financial information in order to minimize your financial liability.
A Sungard consultant had a laptop stolen recently that contained sensitive data from Connecticut Universities from an old project done years ago. The Connecticut Attorney General is investigating this so the situation is both legal and political. Sungard didn't report the potential identity theft issue immediately which has exacerbated the situation.
The risk here for any company or individual handling sensitive data as part of a project for a client is that if there is a breach, the client nowadays has a substantial unplanned expenditure to notify affected persons and impose credit protection. It is a sure bet that they will come after you fto recover their cost if you are responsible.
I work extensively with clientsensitive data and recommend the following:
- Keep all sensitive data on client servers. No exceptions.
- Process sensitive data on client servers. No exceptions.
- Never do or keep any sensitive data on a non-customer PC or laptop.
- Mask sensitive data in development.
- Make sure you connect to the client using VPN.
- Require the client to move data outside their environment.
- Advise the client on bad security practices when identified.
The guidelines are not convenient, but they can eliminate your exposure to liability. The most common form of identity breaches is a stolen laptop or thumb drive with unencrypted data as what happened to Sungard. If the data was never on the laptop, the problem would not have happened. Even with the best of intentions, how many of us remember to remove every bit of data from a laptop including all those places we have forgotten we put it? Well, I can't so the best practice is to never get into that situation.
Data processing can also be a challenge. I have found that with JDeveloper and locally executed middleware apps like BPEL, they can execute off a laptop. This means not only exposure outside the customer environment, but also logs files generated may contain sensitive data. BPEL Will definitely do this - inspect the audit trails and you will see the data in the XML. Again, the best approach is to deploy to the customer server and execute remotely.
What happens if the customer wants you to do the project remotely. First off, you should talk to your contracts lawyer to make sure your liability is defined in any contract. If you don't have a lawyer, get one and don't fly blind here since liability can potentially be in the millions of dollars. If you go forward with an appropriate contract, all sensitive data should be appropriately masked when provided from the client and you should have a well defined data retention policy so that you can easily find and remove the sensitive data at the end of the project.
Finally, demos out of a dev environment are very common. My clients generally prefer the sensitive data to be masked. That way, you don't have the problem of showing real SSN numbers for instance, to potentially unauthorized users. Developers don't need the actual SSN, but theydo need consistency, so masking should be consistent across all data sources so masked SSNs will match.
Being prudent with sensitive data is also good business. Imagine the damage to you or your company's reputation if you are the cause of a breach and the complexity if getting that next contract.
How extensive is this problem. I would like to think that most of you who read my guidelines would say Duh! Yet I have seen bad practices by consultants and there are a steady report of breaches in the press, with consequences. So, it is something we all need to be diligent.