BreachBytes

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

Breach Security Labs released a report containing some interesting statistics about web attacks in 2007. The entire report can be found in the Breach Security Network website (unfortunately, free registration is required). Dark Reading also has a summary of the report, although they felt 67% didn’t sound as good as 70% so they rounded up in the article title.

This report backs up what we have been reporting on in BreachBytes: more and more hacks and breaches are motivated by money. Andy weighed in on this trend with his excellent write up on the rise of organized crime in cybersecurity. I wrote about the subject most recently in my post on the motivations of modern hackers. Danny Quist from Offensive Computing noted in a comment that I should have had money as the #1 motivation and not #2. He was right.

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

If you have the money ($75K+) and a big data center moving a lot of data, Cisco’s Nexus 7000 series switch offers wickedly fast processing power and a lot of compelling security features. Hopefully this signals an increased interest in network security by the switch vendors.

Running NX-OS version 4.0, the Nexus 7000 switch supports a wide variety of useful security features you’d expect from a high-end switch: 802.1x, RADIUS, MAC-based ACLs for policy enforcement, etc. More important to us at BreachBytes is the native hardware support for NetFlow. I commented Monday on the fact that sFlow is generally more prevalent in switches than NetFlow, however Cisco seems to be challenging this assertion with their OS upgrade and supporting products like the Nexus 7000.

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