Stories detailing the theft of personal information from enterprise databases have filled our news for years and are reaching almost unbearable intensity and frequency. Even back in 2005, it was reported that more than 55 million Americans had their personal data exposed in more than 130 major security breaches. A more recent survey found that nearly 90 per cent of Fortune 500 companies and government agencies have experienced security breaches (that they know of!)

Consider the infamous TJX breach. The US-based retail giant discovered more than a year ago -- and much too late -- that its computer systems were compromised because of an unsecured wireless network and that sensitive customer data was stolen. It wasn't until later that the owners of T.J. Maxx publicly announced the breach, and even when they announced the breach, they were unaware of the full extent of the damage. Later, TJX made public that the number of affected customers had reached 94 million. Even today, years after the breach, there are reports of the company's security not being up to the Payment Card Industry Data Security Standard (which is not, to put it mildly, overly stringent). Similarly, another recent intrusion at Hannaford Bros. highlighted the fact that even complying with PCI does not guarantee that a damaging breach won't happen.

In the wake of each breach came public outcry about corporate responsibility for not only ensuring the security of customer data but also for proper notification of those affected. Compliance mandates such as PCI provide system and information security requirements for companies. Still, as the Hannaford example shows, a compliant firm can still be successfully compromised and have information stolen. And always, the remaining question is: What are the guidelines for breach notification, the other half of the corporate security responsibility story?

The first security breach notification law (enacted in 2003 and called the California Data Security Breach Notification Law, or CA 1386) requires companies to give individuals early warning in the event that their unencrypted personal information is "accessed by an unauthorized person" (which is nothing but an euphemism for "stolen"). The idea was that with knowledge of a breach, affected people can lessen the effects of the crime by taking steps to protect themselves against further identity theft. In reality, these laws work mostly through forcing the companies to safeguard information because of fear of public embarrassment, which essentially becomes mandatory. CA 1386 gives companies permission to delay notification only if it would impede a criminal investigation.

At that time, California was the only state with legislation requiring the disclosure of security breaches involving personal information. Since then, more than 40 states have passed data security breach disclosure laws, each with unique notification mandates, but all modeled after CA 1386. A national notification law, rather than disparate state laws, would help unify corporate reaction to and notification of security breaches; several bills currently making their way through Congress detail potential requirements. Some countries are also considering such laws, including the UK, Australia and New Zealand.

For those of you familiar with my writing, you are probably waiting for logs to make their grand entrance. After all, what data security discussion would be complete without mentioning the topic of logs? Indeed, logging requirements are hidden in many regulatory mandates that do not mention "logs" by name. Breach-disclosure laws are a primary example.

I have always championed log data as one of the cornerstones of IT security and one of the best ways to detect unusual activity as well as audit normal user and system activities. Log data is also useful for mitigating the fallout from security breaches since it reveals who accessed confidential customer data, when access occurred and by what methods.