jump to navigation

“You Can’t Unring That Bell!” – What is a”Data Breach” and When Should I Notify? August 21, 2012

Posted by Chris Mark in cybersecurity, Data Breach.
Tags: , , , , , , , , , , , ,
add a comment

There are currently over 45 state breach notification laws, several data protection laws, and numerous regulations including PCI DSS, HIPAA/HITECH, FISMA, and more.  I frequently find myself working with companies on data breach notification plans.  One of the more interesting (and heated) discussions comes when I ask them to define a “data breach” or “data compromise”.  More interesting is when I ask them to define a “suspected data breach”.  Visa’ rules state that “suspected” breaches must be reported within 24 hours of identification or there could be penalties. Consider the following example.  You, as CSO, are informed of a malicious software outbreak in the customer service department. Does this require notification under the state breach notification laws, or relevant regulatory regimes?  Maybe, maybe not.  It is dependent upon a number of factors including access to data, data protections (ie. encryption), segmentation, the various laws etc.  In short, it is not easy to decipher yet it is critical to be as accurate as possible.

Understanding what is, and what is NOT, a data breach or data compromise is the first step in defining your company’s data breach notification plan.  The reason it is so critical is in the titled of this article.  Once you notify that your company has been ‘breached’ you cannot ‘unring that bell’.  The genie is out of the proverbial bottle and things start moving quickly.  Most company’s would absolutely hate to make an announcement only to find that, while they may have experienced a security incident, it did not impact sensitive data (PII, CHD, NPI, PHI, etc.).   It is important that you work with your compliance group, legal (don’t forget legal!), and the infosec & risk department to ensure you have a solid understanding of when, and under what conditions your company is required to notify of a breach or suspected breach.  Here are some basic definitions to use as a starting point.  (check with your legal council and don’t simply use these…there..that should protect me!;)

Security Incident/Event – Any event that compromises the availability, accessibility, or integrity of any asset.  This includes systems, personnel, applications, services, etc.

Data Breach – Any exposure of or unauthorized access of sensitive and/or protected data to include PHI, PII, CHD, and NPI.

Suspected Data Breach– In the absence of  direct evidence (identified fraud, or misuse of data, for example), any Security Incident in which it can be reasonable assumed that sensitive and/or protected data was exposed or accessed without authorization.

Remember, some state breach notification laws do not consider a breach of encrypted data as a trigger for notification…others do 😉  If you need help unraveling these issues (insert shameless marketing plug)…contact Mark Consulting Group…www.MarkConsultingGroup.com

graphic by Hippacartoons.com

“Are You Eating a Rotten Apple?” – Personal Data May have Been Exposed in Global Payments Breach July 9, 2012

Posted by Chris Mark in cybersecurity, Data Breach, Industry News, InfoSec & Privacy, PCI DSS, Risk & Risk Management.
Tags: , , , , , , , ,
add a comment

Let me preface this post by saying this is not intended to take shots at either Global Payments or the PCI DSS.  Rather, this post is intended to generate discussion and discourse on the topic of compliance and risk management.

According to reports, it seems that the Global Payments data breach may have exposed more than payment card data.  n a June 12 update posted to its breach microsite, Global says hackers may have gained access to servers containing personal information collected from a subset of merchant customers.

“The company will notify potentially affected individuals in the coming days with helpful information and make available credit monitoring and identity protection insurance at no cost,” Global says. “The notifications are unrelated to cardholder data and pertain to individuals associated with a subset of the company’s U.S. merchant applicants.”

Based upon this statement it seems fair to assume that Personally Identifiable Information (PII) such as Social Security number and Bank Account information may have been exposed, as well.

This situation exposes the danger of using a narrowly focused, static standard as a baseline of security management rather than adopting a risk based approach to data security.   I have personally conducted over 100 PCI DSS audits and have seen first hand the resources consumed by the standard.  Companies often appear so laser focused upon protecting payment card data that other systems and data may take a back seat in the pursuit of “PCI DSS compliance.”  As there are significant penalties associated with non-compliance that it is difficult to blame the merchant or service provider. The penalties are designed to compel compliance with the standard.  As such, companies are going to give precedent to the PCI DSS over any other standard that does not have equivalent penalties associated with non compliance.

As a reminder, the PCI DSS is ONLY focused protection of Cardholder Data.  Surely some are going to say that the PCI should be applied across all systems etc.etc.  This is great in theory but does not happen in practice.  Companies take great pains to minimize their cardholder data environment specifically to lessen the compliance burden.

I am sure we will continue to see breaches of payment card companies having PII exposed as companies focus on PCI to the exclusion of risk based security management.

%d bloggers like this: