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…)

In a previous post I gave a rundown of various software tools for collecting NetFlow data for use in network security incident response. NetFlow is pervasive in routers but another technology, sFlow, is nearly as prevalent in routers and can be collected from switches — an arena that NetFlow does not play in very much as of yet. sFlow is a packet sampling technology and can provide a depth of network visibility — a key component of network forensic and incident response — even beyond what NetFlow can offer. For more information on sFlow check out sflow.org.

There is not as much activity in free software with sFlow compared to NetFlow, however InMon has a great suite of tools that can help enterprises leverage sFlow data from routers and switches. Their sFlow Agent software can sniff packets off a network interface card and convert them into sFlow packets if you do not have a sFlow enabled switch or router but want to test what sFlow can bring to the table.

(more…)

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…)