News Stay informed about the latest enterprise technology news and product updates.

Preaching the merits of protocol analysis

Meet the networking industry's Pat Robertson. No, Laura Chappell doesn't save souls; she saves networks. As founder and senior protocol analyst with the San Jose, Calif.-based Protocol Analysis Institute, she travels from enterprise to enterprise, preaching about the merits of protocol analysis and helping wayward admins rediscover their faith -- in network analyzers, that is.

Chappell, who will be speaking at next week's Networking Decisions conference in Atlanta, offered a preview of her remarks, and discussed common network security mistakes, XML traffic monitoring and the merits of teaching the "black hat" arts.

At Networking Decisions, you'll be discussing the importance of network analyzers. First, what's the basic definition of a network analyzer?
A network analyzer is a system that taps in and listens to network traffic, decodes the traffic into near-readable form and displays the info in a graphical format. And those analyzers allow you to see the conversation happening on the wire, rather than just trying a blind hit-and-miss approach. Why is there a need for protocol analysis evangelism?
Most vendors have products that look at how their individual solutions are working, but everything comes down to the packet level, be it an attack or an application not running properly. So we are one of the very few groups who run that as our first method of troubleshooting. Why don't more companies use protocol analyzers?
I think there's a perception that this is a pretty difficult thing to do, [or] that dealing with packets and protocols is tedious and takes too much time. But the analyzer products have matured, and many of them have expert systems built in to identify unique traffic patterns. The graphical representations allow you to look at a graph and notice when something is not right. What was wrong with previous generations of network analyzers?
Many of the old systems didn't have proper decodes. They didn't decode a lot of the traffic you'd see. [Network administrators] had to figure out the numbers themselves based on what looked unusual. So they weren't nearly as smart as the systems that we have today. We couldn't build filters to really focus on one traffic path, or one traffic type as easily as we can now. Today, we can just point and click. Do you have any interesting stories regarding how a company realized it needed an analyzer?
When I go out [to a customer's site], most of the time the problem is that their network is slow. There's a standard set of procedures that I follow, and at the end I hand the customer an ROI worksheet. That tells them how much productivity that problem cost them, and how much money they could have saved. In some cases I've had clients who had problems for three to six months, but we were able to troubleshoot the problem in 25 minutes. If they had had an analyzer, they could have saved themselves $75,000. What's the mission of the Protocol Analysis Institute?
We are basically evangelists for the world of protocol analysis. We focus on getting people up to speed on packet-level communications for network troubleshooting and optimization. Recently, the University of Calgary decided to offer a virus-writing course. Do you think there's value in teaching the 'black art' angle on hacking?
The interesting thing is the 'black hats' know how to do this stuff, but it's the good guys that don't know. In order to battle it, you have to know something about the enemy. I think it's fantastic to teach the good folks about the bad tools, and how these programs are built. It's just like being a cop. A cop has to profile who the criminal is, and they have to know a lot about them, The more you know about them and their resources, the better equipped you are to battle them.

Now, I probably wouldn't have done a virus-writing class. Instead, I would have done a virus-dissection class. I would've shown code of existing viruses and picked it apart, simply because it would have been a faster process. What is the most common network security mistake that you see admins make?
I'd say probably not keeping systems patched, and up to date, or not being aware of the traffic flowing inside the company. Everyone is setting up rigid perimeters on the edge of the network, not realizing that all it takes is one person to bring something [harmful] inside that company's network. I call it having a network that's hard and crunchy on the outside, and soft and chewy on the inside. With one breach of that outer wall, we have a network that's totally vulnerable on the inside. I don't think people are paying enough attention to the inside of the network.

People also don't have a sold knowledge of the TCP/IP protocol stack, and how three specific areas -- domain name system (DNS), Internet Control Message Protocol (ICMP), and Address Resolution Protocol (ARP) -- can be exploited for attacks. They can be used for man-in-the-middle attacks (MiM attacks), as well as redirection attacks, and DNS spoofing. What's the biggest threat to network security that often goes unnoticed?
That threat is going to be the users, and sometimes it's the CEO of a company. He may bring in his laptop, and it might have a peer-to-peer file-sharing application on there, but he has no idea that it's acting as a relay. The users lack awareness of how simple some of these exploits are, and how easy it is to perform some of these attacks.

I also think DNS attacks are hot right now, either intentional or unintentional. If someone simply scans a network [aggressively], they can cause a network services disruption, though they weren't intending or trying to launch an attack. Plus there are many other clever ways to hide a DNS attack.


See how you can learn more from Laura Chappell at Networking Decisions 2003.

Watch Laura Chappell's webcast on calculating the cost of network downtime.

Read more stories by News Editor Eric B. Parizo.

Should companies be especially wary of the security concerns regarding XML, and are special tools needed to deal with it?
I think they should have an analyzer that does a solid job of decoding XML traffic, and the security personnel should be aware of what normal XML traffic is, so they can spot what's abnormal. Many analyzers can spot XML breaches and spoofed communications, but the analyst is the one who needs to understand what's normal.

Dig Deeper on Network management software and network analytics

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.