August 4, 2003
(Computerworld)
My company has good security, but at times it's too good. Occasionally users complain that the level of security is too high. When that happens, we try to work with them to find a way that they can still get their jobs done. But despite our best efforts, we can't always find a solution. When that happens, either we in the IT security group have to bite the bullet and accept the risk, or the users must accept the fact that they can't do what they wanted.
Recently, however, we were on the receiving end, when a security project was derailed by product limitations and the policies of our networking team.
The problem came up as we began outfitting and configuring a new data center. It's always a pleasure to work on a "greenfield" IT project because you can avoid compromises made by others in the past. It seemed the perfect time to update and deploy improvements to our monitoring infrastructure.
We currently run host-based intrusion detection on all desktops and critical servers, and we run network-based intrusion detection at our perimeter entry and exit points. Although Gartner Inc. analysts recently predicted the imminent demise of intrusion-detection systems (IDS), they have worked very well for us, and we're sticking with them in our new data center. We do see a threat from the increase in encrypted network traffic that's blinding our IDSs. Despite this, our experiences tell us that a network IDS will continue to be valuable.
We know that our IDSs would work even better if we included them on internal network segments. That would provide protection against insider threats, in addition to what we get from our host-based IDS.
Until now, we've limited our IDSs to the perimeter networks because the devices could only handle those low-bandwidth segments and because we have a relatively small number of external points. But our newer IDS products support gigabit speeds. Coping with high traffic volumes isn't an issue, although we do have to conquer the complexity of getting the data to our sensors.
Switch Disconnect
Many years ago, we helped push the deployment of a switched Ethernet LAN. With properly configured switches, data goes only to those systems involved in the conversation. Traditional managed hubs, in contrast, send a copy of the data to every system in a LAN segment and only the intended recipient reads it.
Switches are great for performance and for protecting data in transit, but we need centralized access to all the data in transit so we can monitor it. In the old days, we could configure an IDS server's network adapter to run in promiscuous mode and search the traffic for bad behavior. This doesn't work when connecting to a switch.
Network managers need to see traffic in order to troubleshoot problems on the network, so network equipment vendors typically include a switch port analyzer, or "span" port, that can take a copy of all the data and send it out over a single connection. We'd love to configure our IDSs to use the span ports to collect data, but our network monitoring systems are already using them.
To get around this, some vendors sell taps, which read the network data without altering the flow. In theory, we could tap the span port data as it heads to the network troubleshooting system and send a copy to our IDS. The problem is that every tap we can find isn't designed for a data center.
Most devices have one of those tiny 9-volt power converters that you used to see on calculators. I worry that whenever the wire wobbles, the power on the tap will go on and off and introduce errors on the tapped line. You can imagine how happy our network team would be if we introduced errors on the systems they use to try and find the real errors. This approach was a nonstarter.
Cisco Systems Inc. sells an IDS card that fits into a slot in its switches to monitor the switch traffic. This would solve the problem, but the cost of equipping all of our switches with these devices is prohibitive. Also, we don't like Cisco's management tools for its IDSs and prefer those from our current vendor.
There are vendors that sell specialized systems to copy flows to multiple ports and even tune which data gets sent so you don't overload the IDS with encrypted data it can't analyze. However, our network team has a simple rule: If it doesn't have a Cisco badge, it doesn't go on the network.
The latest Cisco products let you have more than one span port on a switch, but we've had a few performance problems, and the code is relatively untested in our environment. We don't want to put potentially unstable code into a new data center. Perhaps it's the perfect long-term solution, but we'd like to get the expanded monitoring in during the deployment rather than add it later.
The last idea my team and I had was to plug the span port into a managed hub and then use that to copy the data and send it to the troubleshooting box and our IDS. We would have an extra item taking up space in the cabinet, but it would be stable and fairly cheap, since hubs are old technology. It would even pass the Cisco badge test, we thought.
But there was one problem: Cisco doesn't sell managed hubs anymore. We've got a fair number of spares around that we could use, but these were taken out of service and are destined for the trash. And putting worn and scuffed equipment into the new data center doesn't seem like a good idea. So it's back to the drawing board. Meanwhile, if any readers have better ideas, I'd like to hear them.
What Do You Think?
This week?s journal is written by a real security manager, ?Vince Tuesday,? whose name and employer have been disguised for obvious reasons. Contact him at vince.tuesday@hushmail.com, or join the discussion in our forum: QuickLink a1590
To find a complete archive of our Security Manager?s Journals, go online to
computerworld.com/secjournal.