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

Another area of concern centers on network traffic. Organizations need to monitor traffic going in and out. Most times, inbound traffic is the focus, but if an attacker gets past that monitoring, there is nothing watching what goes out. Outbound traffic monitoring might help catch exfiltration, which is the difference between dealing with an incident today, or dealing with it next year when your organization is notified by an external party that you've been compromised for some time, and you're still leaking data.

A few of those we spoke with also stressed the need to have a single point of contact internally during an incident, who will coordinate tasks, and ensure that everyone who needs to be kept in the loops has the information they need. If the incident requires notification, then there needs to be a clearly defined message to customers and partners (or the public at large), and even then, only the company spoke's person (often internal PR or an agency) should speak for the company -- no one else. The point of contact, message, and task delegation will change depending on the incident, so organizations should have a few options in place for such an occasion.

Logging is a process that many of those we spoke with for this article had strong feelings about. If you read the various breach reports, it's often pointed out that evidence of the attack was readily available in the logs, but no one checked them. Worse, in some cases the organization wasn't even aware the logs were there.

The logs that are most important are Syslogs, but IPS/IDS logs are too, as are the logs on any firewall that has been deployed. These will tell you where the attacker came from, what they did, and in some cases how they did it. Theyre not perfect, but they are a tool that can be used. In addition to those, if your organization uses any type of proxy, the logs from it, as well as VPN, DNS, and router logs, are equally as important. In short, logs from any device, service, or application on the network (including Active Directory) should be monitored and checked.

At the same time, logs can be a nightmare, because organizations need to quickly separate the signal form the noise quickly during an incident. There are a few tools, commercially and open source that are available to help with this process -- but not every organization needs them. Sometimes, the organization is small enough that manual filtering and checks are enough. Otherwise, logging and intelligence gathering should be a discussion that is had internally, and if tools are needed they should be vetted and purchased.


Previous Page  1  2  3  4  5  Next Page 

Sign up for Computerworld eNewsletters.