It seems pretty obvious that implementing solid security practices, such as encryption, is a guaranteed way to protect your company secrets. Or is it?
As a data protection and privacy professional, I feel even the best cryptographic algorithms are useless when the secret guarding the secret is commonly available.
Think about this for a moment. How are your secrets being protected?
If you or your company are using encryption, did you implement it correctly?
Seriously. Drop the ego for a moment and think about the potential flaws in your own best practices. Before going live, did you get the software manufacturer or a security consultant involved to point out any potential pitfalls?
For example, where are your keys stored? Wait, let’s back up for a second. Did you implement symmetric or asymmetric cryptography?
If symmetric, how are the Data Encryption Keys (DEK) protected from unauthorized distribution and copying?
If asymmetric, how is the master key protected from unauthorized access and distribution? How many people have access to the the recovery password and how many pieces is it in?
Hopefully you feel confident with your responses, but that’s not all it takes to keep secrets safe. It’s a good start.
Do you know Google’s mission statement?
They’re doing an amazing job “…to organize the world’s information and make it universally accessible and useful.” By no fault of their own, sometimes they are doing too good of a job.
For instance, I was generating some PGP keys at this website I found called iGolder.
iGolder puts up a page to communicate securely with them, a site member or your friend. How nice of them to provide key generation for the netizen masses!
Out of curiosity, I decided to execute a Google web search on "BEGIN PGP PRIVATE KEY BLOCK" which finished with about 29,500 results.
On the first page of results, six out of ten results pointed to a rendered webpage or an ASCII Armor (.asc) file (5 results) with the private key block exposed. I didn’t want to assume that fifty percent of the 29,500 results pointed to ASC files.
Refining the Google search to "BEGIN PGP PRIVATE KEY BLOCK filetype:asc" resulted in 21,300 results.
I thought, “Seriously folks? Have that many entities implemented PGP and left their PRIVATE key block to be readable on their PUBLIC web site?”
In an attempt to rationalize this, I skipped to the last page results Google would let me click on. I found that the majority of the ASC files are actually PUBLIC ASC key blocks. That’s better.
Wanting to clearly understand how many PUBLIC ASC key blocks are being indexed by Google, I refined the search further still ("BEGIN PGP PRIVATE KEY BLOCK filetype:asc -public"), and finished with 122 results.
From a percentages standpoint, that’s slightly more than one half of one percent of all the ASC keys indexed by Google are actually private keys.
From a data protection standpoint, that’s still 122 too many. Even if it’s a test key.
I’ve worked with organizations before where test environments have eventually become production. I only know of some that told me they changed the master password.
Those 122 entities went through the process of implementing PGP as their form of encryption to protect their secrets, but the secret to their secrets is public.
Any of them having a data breach will feel 100% exposed, and ramifications will quickly follow.
My advice is to review your organizations practices for securing data, even if already implemented. Dropping the ego and not resting on laurels is always a good first start.
Look at how and where the master and recovery keys are stored. Make sure that the keys to your secrets are protected with another layer of security. Such as, a symmetric DEK being protected with a Key Encryption Key (KEK) which is accessible with only certificate based authentication. Of course, implement what makes sense for your organization.
The moral of the story is an old one which dates back to medieval times. Even pretty good privacy is not enough when it’s implemented pretty damn poorly.
Until next time, keep it safe and secure online.
Leave a reply
