When running a network I’m a big believer that you should try and manage it a certain way. The three ways are, proactively, automatically, re-actively,
The best way is to be proactive. What I mean is as much as you can do to avoid problems you should do. Lately the best example is with IPv6. Now not many people are ready to run IPv6 everywhere and there are legitimate concerns about some systems trying to do IPv6 but not having any security controls around it. I say if you aren’t ready for it, don’t allow in on the network. This is easy to do with Enterasys policy and I’m assuming can be done with other vendors.
DISCLAIMER: I’m not a competitive analysis guy so when it comes to what someone else does, I’m probably guessing or at best basing it on what someone else said. In summary your mileage may vary.
Now not everything can be done proactively. Problems occur and being able to automatically take action is key. Zero day exploits are a good example. You can’t have an IPS signature for something you don’t know about yet, but when the IDS sees something causing havoc on the network, like doing a scan, or using up a ton of flows, it should automatically take action to almost immediately resolve the issue.Automatic response is the second best way to manage a network.
The last option is to react as quickly as humanly possible. Frankly this is the last resort option since if you need to react, someone already was impacted. Also humans react slower than machines so the impacted users are impacted longer than if an automatic response is possible.
The key with this last option though is to be able to quickly figure out the problem and resolve it. I heard a quote that 90% of the time to resolve an issue is finding what the issue is. This makes sense to me. I remember when we used to have rogue DHCP servers (We proactively stop them now though). It could take us hours to figure out what was going on, find the MAC address and then correlate that to a port and user. Once we did that, it was seconds to unplug the cable, or turn off the service.
This is where visibility is so key. If you can globally view all the network conversations in one tool, sort on the application and then easily find the port that is causing the issue, the time to resolve is reduced drastically.
So using that rogue DHCP server example. How would you find it. I’ll show how this is done in “OneView” which is a product we make. I’m assuming other tools exist, but I also want to point back to my disclaimer….
OK so we figured out that there is a rogue DHCP server because users are getting duplicate IP addresses. To figure out who is doing it you can on a windows machine run “ipconfig /all” and get the IP address of the DHCP server that gave out the address. In OneView, though, you can also just see who is running DHCP everywhere in the network.
By going into OneView and selecting Flows then “Latest Flows” you can filter on any machines who have a source port of bootps.
Once you find the rogue DHCP server you can easily search for offending server in the NAC tab under “End-Systems” Again there is an easy search box where you can type in the IP address (or MAC address, username, etc)
You can also simply double-click the machine and add it to the “Blacklist” without even needing to get out of your chair.