Let’s have a candid discussion about rogue devices, shall we? You know, the unauthorized access point plugged into a port in a conference or under someone’s desk. Or maybe the network behind the off-shore contractors you have maintaining legacy applications. Perhaps someone is running a side business during work hours on a device they bring from home ON YOUR NETWORK.
Each of these scenarios (regardless of how contrived) happen each day. And every new device presents a significant risk to your environment. Which means you need to be constantly watching for these devices and make sure they are not wreaking havoc. In fact, this is one of the key use cases for network access control (NAC). Of course, that technology is struggling, but it’s not because of the lack of a problem to solve.
So if you are looking at a log management or security information and event management (SIEM) product, won’t that tell you about new devices? Won’t it see something funky and flag it? Well, actually no it doesn’t. Log Management requires logs and your typical rouge device isn’t too interested in forwarding its logs to much of anything. That’s right, each managed device needs to be configured to push log files to the log management product. If that doesn’t happen, the SIEM is blissfully unaware anything is going on – until a number of managed devices are compromised – which is too late.
Yes, network devices (at least the right ones) can detect rogue devices and potentially quarantine those until the proper authorization is presented. But what if you don’t have NAC or can’t afford to upgrade your entire switching infrastructure? That’s right, you need to go beyond log data.
As mentioned in reason #4 about network flows, the network never lies. So we’ve got to look for new network devices and then kick off a scan to figure out what it is and whether it’s authorized. eIQ SecureVue makes that pretty simple. You can set a policy to check for any new IP addresses within a specific time period. Then from right within SecureVue, you can kick off a vulnerability scan to figure out what is the story with that device. Once you figure out what it is, then you can understand whether it should be there.
Additionally, you can set network flow policies to check for traffic leaving the network from unmanaged devices. This kind of extrusion monitoring will tell you if a device is moving data off the network. Maybe they should be, maybe not. But the point is to gain situational awareness of what’s happening in your environment. And just looking at the log data is not going to get you there.
Ten Reasons Log Data is Not Enough: #4. Network Blind Mice
September 17, 2009
As we discussed in the last post in the Ten Reasons Log Data is Not Enough series, configuration data provides an important additional set of information to help pinpoint potential attacks and make sure that in the absence of log data (if logging is turned off, for example) attacks can still be detected.
Network flow data is another data type that can yield important and interesting corroborating data to go Beyond Security Information and Event Management (SIEM) and Log Management. First what is network flow data? Basically, every network device tracks some simple information about who is talking to whom and what protocols they are using. Cisco’s data is called NetFlow. Juniper has a format called (surprisingly) JFlow and there is a more standard format called cflowd.
Regardless, this network flow data comes in fast and furious, with millions of flow records being generated every second. So scaleability is a key requirement if you are planning to analyze and correlate network flows, along with everything else.
Why is being blind to network flows a huge problem for security professionals? Basically, the network sees everything, at one point or another. In the event of an attack, the attacker needs to move data either within the environment or outside of the environment. Typically you wouldn’t see huge amounts of data moving to a server in Eastern Europe. Or an open FTP server in Brazil. Or in a government processing center in China. So these are good indications that something may be a bit funky.
Now to be clear, network flow data is not going to be a definitive answer to the presence of an attack, which is probably why the network behavior analysis (NBA) market never really took off, especially for the security use case. But the data can tell you what isn’t normal and give you some more information to analyze and correlate. It’s really about having another data source to provide additional corroborating evidence to the potential presence of an attack.
As a bit of a unplanned benefit, your network operations folks could be very interested in building their own alerts based on network flows because not only can flow data detect attacks, it also pinpoint network performance issues pretty effectively. So here is yet another reason that log data is not enough, and security professionals need to go Beyond Log Management to keep pace with today’s attacks.
