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

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
Dark Reading, September 16, 2014
Malicious software is morphing to be more targeted, stealthy, and destructive. Are you prepared to stop it?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3090
Published: 2014-09-23
IBM Rational ClearCase 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 allows remote attackers to cause a denial of service (memory consumption) via a crafted XML document containing a large number of nested entity references, a similar issue to CVE-2003-1564.

CVE-2014-3101
Published: 2014-09-23
The login form in the Web component in IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 does not insert a delay after a failed authentication attempt, which makes it easier for remote attackers to obtain access via a brute-force attack.

CVE-2014-3103
Published: 2014-09-23
The Web component in IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 does not set the secure flag for the session cookie in an https session, which makes it easier for remote attackers to capture this cookie by intercepting its transmission within an http...

CVE-2014-3104
Published: 2014-09-23
IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 allows remote attackers to cause a denial of service (memory consumption) via a crafted XML document containing a large number of nested entity references, a similar issue to CVE-2003-1564.

CVE-2014-3105
Published: 2014-09-23
The OSLC integration feature in the Web component in IBM Rational ClearQuest 7.1 before 7.1.2.15, 8.0.0 before 8.0.0.12, and 8.0.1 before 8.0.1.5 provides different error messages for failed login attempts depending on whether the username exists, which allows remote attackers to enumerate account n...

Best of the Web
Dark Reading Radio