BreachBytes

An article written by my partner Ben Uphoff has been published by (IN)SECURE Magazine. Scroll down to page 68 for the full text of the article.

Ben has done a great job of outlining what it takes to perform effective incident investigation using Net/FSE for in-depth alert analysis. I’d like to outline some of the snippets from the article that support the point that network intrusions, breaches and incidents are inevitable and the only way to perform proper incident investigation is to “keep it all.”

A core belief at Packet Analytics is that despite the best efforts of security vendors and practitioners, incidents are inevitable. There are simply too many threats and too many angles of attack. Technology on enterprise networks evolves so quickly that it is nearly impossible to keep up with the ever-changing threat landscape. For this reason, network breaches and security incidents must be seen as part of doing business in a connected world. Enterprises can mitigate the risk of a breach by following best practices and preparing a comprehensive incident response and recovery plan.

One challenge with working with network event data is that you can never be sure what event information is relevant until after the fact. For example, enterprises did not see value in storing DNS logs until DNS exfiltration attacks started appearing. With no historical log of DNS activity, those that fell victim to such attacks had no way of definitively knowing the extent of the data leakage resulting from the breach.

Contrary to the “keep it all” approach, SIMs try to reduce data volume at the collection points by aggregating similar events into statistical summaries that are then fed into the correlation engine, losing potentially valuable information in the process. Summaries are useful for the correlation engine but not for deep analysis of network events

We look forward to starting a dialog on the “keep it all” strategy and how we can improve the effectiveness of security and network operations in performing Network Event Analysis. Please post a comment.

Incident response (IR) is a critical responsibility for network security analysts and system administrators. Anyone operating a network should have an incident response plan in place so that when a network breach occurs everyone involved knows their roles and responsibilities. If a plan is not in place (or nearly as bad, the employees have not been trained to execute the plan) a simple incident can quickly be blown out of proportion and cause damage to the reputation of the organization and its employees.

To most people, IR means a call to action when a new threat emerges or the network is breached (broken in to). Most people think of IR solely in this capacity but responding to an event or incident is too complex to lump into a single category. This article extends the IR concept by breaking the traditional “response” component into three separate areas:

1. Response: the initial set of actions taken by system administrators and security analysts to asses the situation and stop the incident from spreading.
2. Recovery: this step involves getting effected machines back online and returning to regular operations.
3. (Public) Relations: even after the incident is contained and corrected, there may be PR fallout from the incident. This step is overlooked almost universally.

(more…)

Most of my posts on BreachBytes are about using flow data, primarily NetFlow, for network security, incident response and network forensics on enterprise networks. I also tend to get rather technical most of the time. For this post I want to take a step back and answer the following question: what’s the big deal about network flow data? Let me try to answer this question in a single sentence:

“Network flow data, which can be generated by all enterprise routers, provides security analysts with real-time, long-term network visibility that can be used to prevent data leakage, defend against the insider threat and enhance incident response effectiveness.”

Key Points:

1. Generated by all enterprise routers: The technology is in place, your network can generate flow data in some form.
2. Real-time: Flow reporting can be near-real time depending on configuration.
3. Network visibility: Most enterprises are essentially blind to their internal network (the Soft Gooey Center — good in candy, bad in networks).
4. Long-term: Disk is cheap and flows are small, while still providing adequate information for a variety of network security tasks.

(more…)

NetFlow data remains a largely untapped resource for network security professionals. All modern routers support it yet in most cases, NetFlow is used for network operations management and QOS and then discarded. This is very unfortunate for security analysts who need flow data for a variety of security and compliance reasons. Good flow data is a fundamental aspect of any network forensics investigation. NetFlow data is appealing in that — for networks with routers that support it — it is free and easy to collect.

Luckily, there are several free NetFlow tools available to collect and store NetFlow data, often in a highly efficient compressed binary format. These tools vary greatly in terms of quality and support. The table below summarizes the free NetFlow tools available to network security analysts.

From personal experience, I have found SiLK, flow-tools and nfdump to be excellent solutions to capturing flow data. It is interesting to note that only two of the eight tools above have been updated in the last year. Future posts in BreachBytes will cover some of these tools in depth as well as look into performance comparisons of the tools.

The security industry today is making big money on forensics. SANS alone has three different courses on the subject. Guidance Software has built a highly successful company by focusing solely on computer forensics. This is great but anyone that has ever done a computer forensic investigation knows that it is a time consuming, tedious process that is prone to human error. They also know that computer forensics is often not the end of an investigation but the beginning of a larger incident.

Often a computer forensic investigation will yield evidence showing that the compromised host was not an isolated compromise but part of something larger and nastier. This is where computer forensics meets network forensics. Surprisingly, the security industry is lagging far behind when it comes to network forensics. The focus has been on computer forensics but a shift towards network forensics in the industry is inevitable.

(more…)