Attacks/Breaches
1/24/2012
01:48 PM
Connect Directly
RSS
E-Mail
50%
50%

9 Ways To Minimize Data Breach Fallout

Symantec just revealed that attackers stole source code to its flagship Norton software in 2006, highlighting today's array of sharply different approaches to owning up to data breaches. Consider these essential policies.

What's the best way to mitigate the fallout from a data breach?

Data breaches are a fact of business life. But beyond keeping a data breach response plan at the ready, how can IT departments best prevent and mitigate data breaches? Start here:

1. Put a good information security program in place. According to a recent study from the Identity Theft Resource Center, the greatest number of 2011 data breaches were triggered by hackers, and in the first month of 2012, new breaches appear to be following suit.

2. Enforce strong passwords Earlier this month, shadowy hacktivist group TeaMp0isoN uploaded to Pastebin a list of about 80 T-Mobile employees' usernames, passwords, email addresses, phone numbers and passwords. Interestingly, many of the T-Mobile passwords, if they were actual passwords, were simply "112112" or "pass." In its Pastebin post, TeaMp0isoN--which reportedly worked with Anonymous on the recent credit-card wealth-redistribution scheme known as Operation Robin Hood--called out the apparent password non-variety. "Look at the passwords, epic fail. All the passwords are manually given to staff via an admin who uses the same set of passwords."

3. Hide breaches at your peril. Symantec this month confirmed that Norton source code leaked earlier this month by hackers was genuine. But Symantec downplayed the incident, saying the code, from two of its older products--Endpoint Protection 11.0 and Antivirus 10.2--had been stolen from a third party. In other words: it was old code, there's nothing to see, everyone move along.

Except that just two weeks later, Symantec came clean, and admitted that the code to its flagship Norton product had been stolen back in 2006, reported Reuters. That raises the possibility that anyone in possession of the source code back then may have found ways to use Symantec's security software to compromise users' machines.

4. Gauge breach-notification speed carefully. After discovering a breach, businesses must balance the need to gather as much information as possible, with issuing a timely and clear notification. "Transparency is key to maintaining relationships with customers and regulators, be certain you understand the scope of the breach before making an announcement," said Ted Kobus, national co-leader of the privacy, security, and social media team at law firm Baker Hostetler, in a blog post.

5. Expect data to be breached. Why not plan for this worst-case scenario: all data stored by your business gets exposed. So, what should happen next, and how can that scenario be best prevented? "There is no silver bullet for security, so you need to plan for the eventuality of a data breach, and it's going to be critical how you respond to it afterwards--and not just with legal indemnifications and credit monitoring," said Lawrence Pingree, research director at Gartner, in an interview. "Most companies are offering credit monitoring after these data breaches, but most of these only last a year or two--and who's to say the data will be gone in a year or two?"

6. Encrypt all sensitive data. Data breach notification laws exempt businesses from having to issue notifications, if the exposed data was encrypted. Accordingly, whenever possible, encrypt all data in transit, as well as at rest. "Encryption is not only a safe harbor, it is expected by customers and regulators," said Kobus at Baker Hostetler.

7. Expire your own data. If stolen data has no expiration date, then it's up to businesses to delete their own data. Both Honda Canada and Sony were caught last year after hackers stole outdated customer information that each company had failed to delete. The breach at Honda appeared to put the company in violation of Canadian privacy law, which requires companies to delete any personal information that's no longer required. Arguably, however, all businesses should follow that practice.

8. Beware social engineering. When it comes to low-cost, high-impact strategies for stealing sensitive data, attackers have become well-versed in the art of the social engineering attack. "Social engineering tools are being used creatively to gain access to personal information," said Kobus. Accordingly, keep training all employees who handle sensitive information in the art of detecting and resisting scam phone calls and emails--including spear-phishing attacks.

9. Demand data discovery services. Breached data has a habit of ending up everywhere from black market carding sites to peer-to-peer networks. While the data could theoretically be expunged, first it must be found. Accordingly, expect related, commoditized services to follow soon. "The strategy moving forward ... is to have services that will go after that data, and provide insight into where the data is located," said Pingree.

"Even Google could get into this sort of technology. They have the search capability, they just need to start looking at data and indexing data with the ability to compare host data and Web data, and include P2P networks in their indexing," he said. While such services aren't yet available, with data breaches showing no signs of abating, expect to see such services emerge soon.

The right forensic tools in the right hands are just a start. The new Digital Detectives issue of Dark Reading shows you how to better apply the lessons they teach. (Free registration required.)

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2595
Published: 2014-08-31
The device-initialization functionality in the MSM camera driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, enables MSM_CAM_IOCTL_SET_MEM_MAP_INFO ioctl calls for an unrestricted mmap interface, which all...

CVE-2013-2597
Published: 2014-08-31
Stack-based buffer overflow in the acdb_ioctl function in audio_acdb.c in the acdb audio driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to gain privileges via an application that lever...

CVE-2013-2598
Published: 2014-08-31
app/aboot/aboot.c in the Little Kernel (LK) bootloader, as distributed with Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to overwrite signature-verification code via crafted boot-image load-destination header values that specify memory ...

CVE-2013-2599
Published: 2014-08-31
A certain Qualcomm Innovation Center (QuIC) patch to the NativeDaemonConnector class in services/java/com/android/server/NativeDaemonConnector.java in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.3.x enables debug logging, which allows attackers to obtain sensitive disk-encryption pas...

CVE-2013-6124
Published: 2014-08-31
The Qualcomm Innovation Center (QuIC) init scripts in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.4.x allow local users to modify file metadata via a symlink attack on a file accessed by a (1) chown or (2) chmod command, as demonstrated by changing the permissions of an arbitrary fil...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.