4 Tips to Give You Greater Network Visibility and Prepare You to Survive a Breach

Companies can take several proactive steps to reduce the long-term costs of a data breach. Not every organization will have a breach, but most will. Given that reality, the action item for IT managers is to establish practices that give them insights into network activities — before the breach happens — so that they can understand, remediate, investigate and attribute the breach as quickly and fully as possible.

Here are four specific steps the tech team will want to take to speed recovery when the inevitable happens.

No. 1: Ensure that you have logs, and that they are protected.

Breach recovery cannot start until two important questions are answered: Which systems are affected? How did this happen? Answering these questions means being able to look back in time to see what was happening in the network at the time of the breach.

Log data (including firewall traffic logs, system event logs and message files) and NetFlow information will all be critical in determining the next steps after a breach is discovered.

In a perfect world, all of this information flows to an enormous security information and event management system (SIEM) with terabytes (or petabytes) of disk space that can filter through the information and respond to searches in real time.

Many IT managers often discover that the cost of these systems at such high capacity levels is prohibitive. If a SIEM is not available, or can’t handle all log data, set up a log server with plenty of disk space that can at least stage all logs for 30 to 90 days so that they are available when needed.

SOURCE: SANS Institute, “Ninth Log Management Survey Report,” October 2014

No. 2: Keep your database of systems and applications up-to-date. 

Configuration management databases (CMDB) have become quite popular lately, especially as organizations try and implement IT Infrastructure Library and similar service delivery systems.

A CMDB is a store of information about all running systems and applications — and their relationships. Most organizations use a combination of systems to create their CMDB, whether they call it a CMDB or not. This approach is invaluable in any post-breach cleanup.

The database should have information including the applications running on every system in the data center, contact information for system and application managers, and some sort of risk information — whether the system has critical data or not.

After a breach, when you’re trying to figure out exactly what “i-40ca81c1.inst” does and how that’s related to “ismtpd0003p1iad1” (yes, those are real systems out there on the internet), the CMDB will be important. Just as important is the contact information, which can help identify critical people in the organization who can help evaluate what happened and what data might be affected.

No. 3: Have a method to capture network traffic and to send alerts.

In the immediate aftermath of a breach, IT managers need confidence that they’ve patched the holes and the intruders no longer have a foothold. While firewall logs (especially in the outgoing direction) are a start, it’s often extremely useful to be able to look at a connection to determine whether this is an intruder exfiltrating data or just a system doing a normal version update check. Firewalls can’t tell you that, but packet analyzers can.

Some organizations have the ability to run network packet capture all the time, which is a fantastic forensic resource. In most environments, however, it’s sufficient to be able to enable packet capture very quickly at any point in the network. In fact, temporary flexible capture can be better than permanent network packet capture because networks are so highly switched that capturing all packets can be extremely difficult.

The ability to turn on packet capture at any point in the network (without making a trip to the data center or calling in an expert) is a great tool to have ready for breach management, and even general troubleshooting. A little homework by the IT team and some well-documented processes are all that it takes to get this ready for emergencies ahead.

No. 4: Make a plan for responding to a data breach and write it down. 

If — check that, when — a breach happens, it’s not going to happen in the middle of the day when everyone is free and your entire management team is available. It’s going to happen outside of business hours, when a senior manager is on a diving vacation in Australia, and a critical system administrator is at the hospital with a broken arm.

A plan detailing what to do in the case of a major breach will save valuable time, especially during the first moments when everything is chaotic and the extent of the problem is not yet understood. The plan doesn’t have to be hyperdetailed, but at minimum it should identify the major players, everyone’s areas of responsibility, how communications will occur and what actions are preapproved without seeking OKs up the food chain. A solid plan will put you way ahead of the game.