Attacks/Breaches
6/11/2010
02:27 PM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Tech Insight: Working With Law Enforcement After A Breach

FBI-hosted event offers tips on how to interface with the feds, law enforcement

Working with law enforcement in the aftermath of a data breach doesn't have to be scary and one-sided.

Fueled by the fact that many companies are afraid to call in law enforcement at all after they've been hacked, attackers are confident they can break in and steal data without repercussion. But companies not disclosing breaches to law enforcement actually help attackers, acting deputy assistant director for the FBI's Cyber Division Jeffrey Troy told Dark Reading in March. "It's to the advantage of the bad guys if you don't share that information," he said. "We're trying to get people to understand that."

So how can you effectively work with law enforcement agencies? One of the keys is to be prepared with a solid, tested incident-response plan that addresses evidence collection and preservation -- including details such as who liaises with law enforcement. Success goes beyond policy and technical tools: Never underestimate the benefits associated with having a good relationship with local law enforcement agencies prior to an incident, for example. It can ease the process greatly when the players involved already know each other.

The FBI has been touting the changes in how it does business in cybercrime investigations. Troy pointed to how the bureau recently shared some key information with the financial sector information that it had discovered during an investigation. A bank was able to determine it had been breached based on the shared information and then reported back to the FBI. "This two-way sharing has increased. We consider it a critical part of our mission," Troy said.

But knowing when to call in law enforcement -- or whether to at all -- is the biggest issue facing organizations because of concerns of computer equipment seizure and publicity. This is where establishing an incident response plan, procedures, and a relationship prior to an incident is critical. InfraGard is one example of programs started by the FBI to help establish a relationship between the public and private sectors and the FBI, allowing for information sharing in order to protect the nation's critical infrastructure.

The FBI hosted the first Southeast Regional Cyber Threat Cooperative Meeting last week in Florida. It was an informative meeting with speakers from Mandiant, Lockheed Martin, Center for Disease Control, and the FBI. The unclassified event helped advance the FBI's information-sharing efforts and provided an opportunity for attendees from all over the Southeast to network with the FBI's Cyber Division so they would know firsthand who they could call as the need arises -- which it likely will because breaches will happen.

FBI officials explained the bureau's partnership efforts, like log collection and analysis, where companies provide the bureau with logs that the FBI then analyzes for signs of intrusion and attacks. The program has already led to several cases and intelligence that can be used in other cyber-investigations.

The FBI also provided tips on working with the bureau and law enforcement The basic theme: Get to know your local agents.

Following the identification of an incident, in-house first responders can work with their fellow incident response team to gather volatile evidence from running systems. They then can image the drives and provide them to law enforcement. Advancements in Windows memory acquisition and analysis tools have obviated the old methodology of pulling the plug, as tools such as Mandiant's Memoryze, AccessData's Forensic Toolkit, and F-Response enable acquisition of Windows memory, and the latter two can image memory and hard drives over the network. In essence, enterprises could invest $5,000 to $10,000 in software and hardware to have evidence-collection capabilities that could collect volatile data, image memory, and hard drives over the network.

One of the sentiments expressed from several agents at the FBI-hosted meeting last week was that they are not out for publicity. Going public with information from your breach does not gain anything for their investigation. This is similar to what Troy said about how the FBI is focused on identifying and eliminating the threats. "In the past, we'd be talking about the biggest case, how it's going, and if we arrested someone yet, [but now] it's not necessarily, 'Did you put someone in jail?' but, 'Did you do something to reduce the threat?'"

So contacting your local FBI office or law enforcement agency after you detect a breach shouldn't be painful. And odds are, you're eventually going to be faced with the decision of whether to make that call.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

CVE-2014-2392
Published: 2014-04-24
The E-Mail autoconfiguration feature in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 places a password in a GET request, which allows remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer log...

Best of the Web