Learning to play the safe harbor card properly
Many readers will be well aware of the NIST approval process around FFX Mode AES - Format Preserving Encryption. Due to the cryptanalysis, proofs and research behind it, it’s considered strong cryptography and will soon be part of a NIST AES mode standard – we suggest to people to check in with NIST if there are any doubts. Any vendors interested in learning more about using AES FFX in products or services should contact us here
With the recent spate of breaches in the news this week – TD Bank's unfortunate backup tape loss and disclosure to US MA and NH State Attorney General's offices, and the UK Manchester Police's stolen USB sticks, the following question often comes up which is worth examining more closely:
If regulations like MA State Privacy Laws only apply to unencrypted personal data when there's no ability to access the key, what happens to Safe Harbor provisions when the method of encryption is not a recognized mode or has no real evidence of proof of security?
For instance, there are a few different tokenization and format preserving encryption methods floating around – none of which are going through a NIST standards process, have no security model, no proofs, and no evidence of a sound basis for the claims of protection. What happens if those are used?
The good news is the facts are clear- so it’s an easy decision on choosing the right data protection method. Use only methods which have independent analysis and visible proof – proof you can ask for independent opinion on from experts. Voltage customers will already be familiar with this.
The bad news is that – as you would expect – accepting a vendor’s claim of “secure” without proofs and public scrutiny is very risky. Indeed, it might be even more difficult for a CISO to "please explain" to the board of directors about why such an approach was taken in the first place knowing such high stake risks. If there is a breach, and the method used does not have any meaningful evidence of security then claiming safe harbor is going to be very difficult, and probably impossible.
Lastly, watch out for smoke and mirrors – claims about vaguely related “approval” processes that to the uninitiated it may sound good, but don't actually have any tangible meaning when it comes to being provably secure. The evidence has to be relevant and meaningful, and the validation appropriate and recognized for its intended purpose. For example, FIPS 197 validation means the method is implemented to the AES spec, that’s all – not that the system is even secure or meets the stated vendor claim.
Here’s what do to: follow accepted cryptography best practice:
- Ask for the method specification and proofs, and where it can be reviewed and understood and who has validated it.
- Ask to see the cryptographic basis for the security model and evidence of independent cryptanalysis.
- Ensure the proof is about what you are asking for and by the right experts, not an unrelated but convincing looking report, and by people who aren’t qualified.
- Don't accept anything else. Trusted providers won’t dodge these very serious and valid questions with letters or stories to sidestep fact. Proof is proof. Evidence is evidence.
Breaches can happen to the best companies with the best intentions, but best practice always wins in mitigating risk. Due diligence and choosing wisely is a corporate duty of care. Choose your data protection weapons wisely, and don’t be caught off guard after its too late.
Lastly – about those backup tapes and USB drives – if data was encrypted at source already in the applications and databases, the tape or USB stick would contain encrypted data only – nothing more, nothing less. Under the plain and simple to understand MA regulation this would not be considered personal data and safe harbor would apply – reducing the disclosure burden dramatically for the bank and avoiding stress for the hundreds of thousands of people affected.
To learn more about how to protect your data at source to avoid data breaches using proven, provable "ace card" techniques click here and don't hesitate to get in touch.
Disclaimer: I’m not a lawyer and this is not legal advice – if you need advice on legal compliance matters, consult your counsel.