CA Community






This Blog

The Data Breach PR Disclosure Recipe: 4 Simple Steps

Published: July 21 2010, 09:02 AM
by Merritt Maxim

People in Infosec are getting increasingly jaded (myself included) when we hear about yet another data breach.  Given the vast amounts of sensitive electronic data and continued operational lapses on handling sensitive data, the unfortunate reality is that data breaches are with us to stay.

I initially viewed yesterday's reported data breach at the South Shore Hospital in Quincy, MA as the latest breach du jour until I read and heard the local reporting on the story.  You can read the hospital's official press release here.

I soon realized organizations learn from prior breaches and follow a very simple script when announcing a breach.  There are four key components to this script.

  1. Always Refer to Breach in Hypothetical Terms-Usage of terms of "may" or "possibly" are essential here.  This means it is important to announce the breach early on. This enables the organization to shift the messaging from a breach to "potentially missing" which is usually deemed less serious. This same rule applies to describing the data itself.  Thus, you will see yesterday's press release comment that the data "may" have contained sensitive info like social security numbers and other medical related data.  As someone who has spent time in hospitals, I challenge you to find any piece of documentation that does NOT have your medical record number, SSN or diagnosis on it!  Leaving the data description vague enables organizations to avoid directly claiming that anything  sensitive was disclosed.
  2. Emphasis Data is Old- In addition to noting that the data may or may not have been sensitive, organizations should emphasize that the data is old.  The implication is that old data is less risky.  This may hold true for credit cards which are changed at normal intervals, but last time I checked, your social security number or medical record number stays with you for your entire life.  So the fact that the data is old should be of no comfort to anyone.
  3. Defer Blame Whenever Possible-While usage of other contractors and third parties is a reality in today's business environment, usage of 3rd parties does not completely absolve an organization.  In the South Shore breach, data was shipped off-site to another provider who did not provide timely assurances of the destruction.  Credit should be given to South Shore to request documentation of the destruction, but the four month lag between sending the data off and finally announcing the data is missing is still concerning.  But the delay and lost data allows the organization to deflect the blame.
  4. State that Cracking the Data would be Very Difficult-Hence, the release states, "...specialized software, hardware, and technical knowledge and skill would be required to access and decipher information on the files."  That may sound good, until you realize that the people with the most to gain from this data (identity thieves) are very talented and likely possess (or have access to) specialized software, hardware and technical skills.  That argument is not reassuring, but stating the scale of difficulty can placate the public.

I realize that data breaches now involve regulatory issues, civil lawsuits and other expenses, and organizations are often limited in what they can disclose, so I do not mean to trivialize this process.  I also do not mean to call out the hospital; as I stated up front, this recipe is followed by most organizations when a breach occurs.  But, understanding these steps should help you understand and properly interpret any future data breach announcement.  I think that you'll see that they will follow this recipe.

Share this post:  

 

By: Merritt Maxim
Merritt Maxim has 15 years of product management and product marketing experience in the information security industry, including stints at RSA Security, Netegrity and CA Technologies. In his current role at CA Technologies, Merritt handles product marketing for CA's identity management and cloud...
Read More..

Comments:

No Comments

Leave a Comment

* An asterisk indicates a required field

* :  

:

* :  

 Submit