Perimeter
1/20/2012
06:23 PM
Commentary
Commentary
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Breach Notification: Know The Rules

State and federal laws require notification when a breach of protected information occurs. You need to know which laws apply and how to comply

The vast majority of states and territories in the United States have rules requiring organizations managing personal information to notify affected parties if their private information has been breached.

However, the laws differ from state to state in the way they define personal information, the requirements for who needs to be notified, and how notification must take place. Add to this the fact that federal laws also require breach notification, and we see that organizations caring for personal identifying data have their work cut out for them in understanding which rules apply and how they can ensure they’ll comply in the event of a breach.

Which Rules Apply?
The key point to remember when determining which laws apply to your organization is that state laws are written to protect the residents of a state. This means you need to comply with the state laws applying to the people whose data you manage. In other words, if you have customers or employees from Massachusetts, then even though your business is located in New Hampshire, you need to comply with the Massachusetts data protection and breach notification laws.

If it seems like it a difficult task to understand and comply with upward of 50 different state and territorial laws, you get the message. It should also be clear why every year the U.S. Congress attempts to define federal data protection laws that would supersede these state laws. For better or worse, efforts at the national level have not succeeded, and we are left with the laws of the various states (in addition to the federal laws applying to financial and health information).

State breach notification laws have more in common than not. For example, these laws define personal information as a person’s first and last name, or first initial and last name, together with one or more other pieces of sensitive information. The obvious ones are Social Security number, driver’s license number, and credit card numbers. One area where differences tend to occur is banking information. For example, Massachusetts considers a bank account number (again, with a name) a piece of personal identifying information, even if there is no PIN or password that would allow a perpetrator to use the account. California, on the other hand, requires the presence of a PIN or password to make the account number a piece of protected data.

The first step in ensuring compliance with breach notification laws is knowing whose data you have. That means keeping accurate records of whose data you store, where they live, and where the data resides. Once you understand that, you can identify the laws that apply. Next, you can identify the particular pieces of information that you need to protect and understand the kind of breaches that would require you to notify the victims as well as state authorities.

In the next posting, I’ll talk about what constitutes a breach (and what doesn’t) and the mechanics of notification.

Richard Mackey is vice president of consulting at SystemExperts Corp.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.