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
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3341
Published: 2014-08-19
The SNMP module in Cisco NX-OS 7.0(3)N1(1) and earlier on Nexus 5000 and 6000 devices provides different error messages for invalid requests depending on whether the VLAN ID exists, which allows remote attackers to enumerate VLANs via a series of requests, aka Bug ID CSCup85616.

CVE-2014-3464
Published: 2014-08-19
The EJB invocation handler implementation in Red Hat JBossWS, as used in JBoss Enterprise Application Platform (EAP) 6.2.0 and 6.3.0, does not properly enforce the method level restrictions for outbound messages, which allows remote authenticated users to access otherwise restricted JAX-WS handlers ...

CVE-2014-3472
Published: 2014-08-19
The isCallerInRole function in SimpleSecurityManager in JBoss Application Server (AS) 7, as used in Red Hat JBoss Enterprise Application Platform (JBEAP) 6.3.0, does not properly check caller roles, which allows remote authenticated users to bypass access restrictions via unspecified vectors.

CVE-2014-3490
Published: 2014-08-19
RESTEasy 2.3.1 before 2.3.8.SP2 and 3.x before 3.0.9, as used in Red Hat JBoss Enterprise Application Platform (EAP) 6.3.0, does not disable external entities when the resteasy.document.expand.entity.references parameter is set to false, which allows remote attackers to read arbitrary files and have...

CVE-2014-3504
Published: 2014-08-19
The (1) serf_ssl_cert_issuer, (2) serf_ssl_cert_subject, and (3) serf_ssl_cert_certificate functions in Serf 0.2.0 through 1.3.x before 1.3.7 does not properly handle a NUL byte in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Dark Reading continuing coverage of the Black Hat 2014 conference brings interviews and commentary to Dark Reading listeners.