Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Understanding incident response: 5 tips to make IR work for you

Steve Ragan | Aug. 2, 2013
Incident response is a plan that evolves over time to keep your organization best prepared against likely threats. CSO talked to industry experts at Black Hat about the ups and downs of IR, and how to develop a plan that's right for you

Eric Fiterman, the founder and CEO of Spotkick, a SaaS platform for security analytics and intelligence, told CSO during an interview that incident response will often depend on the size of the organization itself. His point being that no two plans are alike.

"Because some enterprises and organizations are large enough that they can spend time tracking things down; and then there are a lot of IT departments where that's not the main concern. The main concern is making things reliable and getting systems recovered and up as quickly as possible," he said.

The key, Fiterman added, is that organizations understand that incidents will happen.

"You're going to have some type of malicious activity that's going to impact what you're doing," he said, so organizations need to have a plan in place to deal with the various circumstances as they arise.

According to the Black Hat attendees that CSO spoke with, there are a few common problems when it comes to incident response, and unless plans were developed and tested beforehand, then these common problems show themselves at the worst possible time; during an actual incident.

"What IT gets right is that they know their infrastructure. They know where their data of value is, they know ingress points [and] they know egress points. It's their network, they understand how it works. What they get wrong is they don't use the working knowledge that they have of the network to understand how and incident would occur," Chris Pogue, the Director of Trustwave's SpiderLabs, told CSO in an interview.

"Attackers are there for a reason, not for fun and games. They're there to steal something, so that they can extract it and monetize it. So if [IT] would integrate the knowledge that they already have into their incident response capabilities, they'd be so much better off; because they'd know the targets, they could defend the targets, [and] they would know their ingress points, and their egress points."

One of the often repeated problems with incident response is that organizations rarely understand those who are attacking them, what the attacker is looking for, and how they are trying to get it.

This means understanding what's valuable to an attacker, and where it lives on your network. As mentioned by Pogue, knowing all the routes and access points to the critical data is a must, so that when something happens you can accurately flag the incident and deal with it appropriately.

The key though, is to apply this line of thinking to incidents other than vulnerability exploitations and malware, because there needs to be plans and processes in place to deal with lost or stolen laptops, accidental data disclosures, and malicious staffers who abuse their access. Further, there should be plans in place to cover incidents where an outsider is abusing an insider's access, which is the case for many persistent attacks, which often happen in smaller stages and rarely all at once.

 

Previous Page  1  2  3  4  5  Next Page 

Sign up for Computerworld eNewsletters.