Robert Gleichauf is CTO for Cisco Systems' VPN and Security Business Group. During his tenure at Cisco, he has been responsible for the company's intrusion detection products and was among those responsible for migrating security into Cisco's Catalyst 6000 product line.
Christopher W. Klaus is founder and CTO of Internet Security Systems (ISS), a provider of information protection solutions. Technology Review, MIT's magazine of innovation, named him one of the top 100 young innovators for 1999. He has also been named Ernst & Young's Entrepreneur of the Year in the Internet products and services category.
Marcus J. Ranum is founder of NFR Security and an independent security consultant. He built the first commercial network firewall product, DEC SEAL, in 1990. While at Trusted Information Systems, he built and managed the president's mail server, whitehouse.gov. He was inducted into the Information Systems Security Association's (ISSA) Hall of Fame in June 2001.
Martin Roesch is founder, president and CEO of Sourcefire. He is the author and lead developer of the open-source Snort intrusion detection system, which is the foundation of Sourcefire's products.
Moderator Pete Lindstrom is director of security strategies at Hurwitz Group, an IT market research firm, and a member of Information Security's editorial board.
Information Security magazine (ISM): Intrusion detection is on the minds of many folks. How are threats evolving today?
KLAUS: In the past, you had two different underground groups -- virus writers and the hacker/intruder organizations. We're seeing a lot of convergence between those two. The virus writers are taking a lot of the techniques from the intruder community and embedding them into worms and backdoors. Traditional viruses are evolving into hybrid threats. So the most current type of threat is no longer the passive e-mail attachment Trojan, but a multifaceted vector of different types of attacks, different types of backdoors. In the latest methods, they're hooking into the peer-to-peer or instant messaging networks.
RANUM: Another thing I think is going to be really critical in the next couple of years is the new availability of mass rooters. The Teso guys just released something that can hack into 26 or 27 different versions of Wu-FTP. So, I think we're going to see an awful lot more indiscriminate hacking, and a lot of systems that are getting compromised within minutes or, in some cases, seconds of connecting to the Internet.
GLEICHAUF: Yes, and these attacks will escalate faster, and they'll be harder to eliminate once they take hold. People will run their remediation and think they've got things cleaned up, and it's still lurking months later.
ROESCH: The propagation of automated tools for auto-hacking combined with the fact that less and less sophisticated attackers are getting their hands on these tools is really going to cause big problems. The time delta between when a vulnerability is discovered and when an auto-attack tool is developed and put into wide distribution will get shorter and shorter, so there's going to be less and less response time from the vendor and admin community to get patches out.
ISM: How do IDSes evolve to protect against these types of threats?
GLEICHAUF: One of the things we'll see is an integration of the various components that have been sitting out there. You've got host-based, you've got network-based, and then you've got these second-order denial-of-service-type tools. In order to do a better job, customers are going to have to work with these tools in an integrated way.
Chris Klaus, Internet Security Systems
RANUM: One of the other side effects of these kinds of mass rooters and scanning tools is that they're going to overwhelm IDS admins with sheer quantity of alerts, unless the IDS gets smarter about dealing with alerts. In the next couple of years, IDSes will become smarter about weighing and sorting the relevance of the particular attacks that are being launched against the vulnerability of a particular network. So, we won't get alerts for systems that aren't vulnerable to the attacks being launched. We're going to have to pare down the sheer number of alerts and focus on tying those alerts to the business significance of the attacks.
ROESCH: We're also going to see a lot of development on the back end of intrusion detection-sensing technologies in correlating the data. It will get much more highly integrated into the overall intrusion detection infrastructure of an organization as opposed to what we have now, which are lots of point solutions talking to other point solutions that try to make sense of the data. It's going to bring together all of the data off the different types of sensing platforms, integrate that data in an intelligent manner and present a large-scale picture from multiple small-scale events.
KLAUS: Now that IDS has evolved to a certain point, clearly the next level is the whole management piece. More organizations are focusing on managing these events, correlating them. It's not a pure IDS. It's convergence not only from an IDS perspective, but also vulnerability assessment. The IDS needs to determine whether the system is vulnerable and whether to relate to it. Well, we've already got components out there that do assessment to determine some of these additional data points. The next level will be bringing in vulnerability information as well. A lot of people think of IDS as being purely network based. It's got to be at the network, but also at the server, the desktops, all the way down to the application layer.
ISM: How smart can we get?
RANUM: One of the big gating factors for now is the deplorable lack of standards. This is completely understandable, because this is an area that's evolving so quickly. We've got different products that produce alerts; everybody does things in a slightly different way, so the folks looking at aggregation are left trying to figure out how an NFR's data layout maps to an ISS data layout, maps to a Snort data layout, maps to a Cisco data layout. And that, by itself, is a tough problem. Of course, the question for the vendors is going to be, is there commercial drive? Are we seeing pressure from our customers to do that?
ISM: How important is integration of alerts and alarms to the end users?
GLEICHAUF: It's extremely important, and that's why you're seeing the emergence of these different monitoring alarm vendors who are pulling data together, normalizing it, and allowing users to cross-correlate -- NetForensics, Intellitactics, Network Intelligence, e-Security, etc. The real challenge is for people who can write good models for the data that comes out. The problem we have is that different enterprise networks create quite different traffic. Trying to model it and pull out interesting patterns with it, minimizing false positives and things like that is very difficult.
ISM: You talk about writing good data models. How good is the data itself?
GLEICHAUF: It varies, and it's not always the tools that are the problem. It's how the users have configured their equipment. You can take any of the products out there, and if you've tuned them well to your networks, you'll see things that stand out quickly. If you've turned everything on, and you're inundated with data, it will be more difficult.
RANUM: But it's deeper than that. One organization's notion of a false positive is going to be completely different from that of another organization, depending on their understanding of their site configuration. If I've got a network where I'm not running any IE users, and I start seeing traffic from browsers that announce that they're IE, I've learned a very different thing from somebody who's running an open-research network or university network.
KLAUS: The biggest criticism people have about IDS is probably the false positives. We've struggled with it, and we've been trying to educate our customer base about the difference between a false positive and a false alarm. At a technical level, when we talk about false positives, it's when we've written a signature or a detection algorithm that misidentifies legitimate traffic as the attack. More commonly, probably 80 percent of the things that people call false positives, we classify as "false alarms." That means our algorithm fired off in the manner that it was designed to do. This is where IDS has to be tweaked and configured. It's not something that ISS or any IDS vendors can correct, other than to provide facilities to help filter and make it easier to manage that type of information.
GLEICHAUF: To stop this problem in the long term, there will have to be a marriage of anomaly-based techniques with traditional signature-based techniques.
RANUM: One of the problems with anomaly detection is that even the current best research systems have something like a 75 percent success rate. So few customers have the ability to even understand what's going on in their networks. If you start giving them something that's giving unreliable data, they'll just throw it all out.
KLAUS: In terms of the number of different patterns and different ways we detect the attacks, we're marrying protocol analysis with pattern matching as well as using many other different techniques. There's anomaly detection and some statistical thresholds, etc., to determine when the attacks happen. In any different situation, it's going to be left up to the vendor to try and define as well as get some input from the customer on what patterns work most effectively against what type of attacks.
ISM: Marcus, is your main objection to this that there's going to be an increasing level of data swamping the IDS admin?
RANUM: It's not just an increasing level of data, it's an increasing rate of change in the data, and that doesn't argue well for the success of the classical anomaly-based detection approach. What we're going to see is sort of self-programming expert systems that essentially engineer out of their administrators what they want to see and what they don't want to see. The software needs to be smart enough to be able to say, "Here's something you haven't told me whether to bring to your attention or not, so I'm bringing it to your attention, so you can tell me what to do with it in the future."
Bob Gleichauf, Cisco Systems
ROESCH: I have a problem with pushing the intelligence, especially the level of intelligence that Marcus is espousing, out of the sensor level. I don't think it's necessarily good to have a sensor deciding what people want to see. I think the sensor's job is to collect the information about hostile or suspicious activity that it sees on the network. The data management system's job is to customize that data for the user.
RANUM: I was speaking conceptually. What you're going to have is a mixture where some of the endpoints know to just "mask this off because I see too much." It's going to be a push-pull between devices that's all going to be hidden from the user.
ISM: Chris, you started us down this path of false positives versus false alarms. Is this your classic case of unmet expectation on the user side?
KLAUS: Typical scenario: First-time user of IDS runs it, turns on every possible algorithm and configures it to say, "Tell me everything that's happening on my network." They're surprised by all the activity. Maybe they catch somebody doing some bad stuff, but then after a week, two weeks, they're like, "Hey, I'm getting flooded with this; there's no way I can respond to this." The phrase "false positive" comes up, but in fact, in many cases, these are just false alarms. That's the false expectation that you just throw IDS into any environment, and it tunes itself and automatically gives you only what you really need to see. We're still a long way away from doing that.
ISM: Is this a case of the Christmas puppy -- seems like a good idea, but then you get it in house, and it kind of overwhelms you?
GLEICHAUF: I think that's frequently what happens to customers, and then they go through the education process. Historically, many people dabbled in small numbers of intrusion detection products, and the industry did a disservice to itself by giving them free data tools as part of the product. As they started scaling their deployments, they realized those freebie tools weren't going to cut it. It's only now that people are having a pain threshold that's high enough to justify spending money to buy industrial-strength tools.
ISM: How do we convince users that there's value to be derived?
RANUM: Frankly, I think we're doing that already. What you find is all kinds of horrifying things going on in customers' networks that they didn't realize were occurring. When customers buy IDS, they're kind of shocked and dismayed at the state of their networks. It's a matter of education. At one deployment, a customer turned the IDS on and looked at me and said, "See? This is what I hate about intrusion detection -- all the false positives." But it wasn't a false positive at all. The alert meant that one of their systems was highly misconfigured and was actually potentially damaging other systems and the network's ability to function.
GLEICHAUF: One thing that may help is the integration of security services. So you'll see IDS going much more hand in hand with firewalls, just like VPN has started to migrate with firewalls. If these services are bundled together, they're doing something useful together, which implies that an IDS will detect something and automatically tell the firewall to enforce a policy. But to do that, we have to minimize false positives.
ISM: That's a great segue. Firewall: IDS friend or foe?
ROESCH: The firewall has been doing yeoman's duty, but it's got to evolve. Several vendors are moving this way. You've got the inline IDS from ISS. OneSecure and TippingPoint have inline modes, and, in the open-source world, you have products like Hogwash, which is a derivative of Snort. It's what we call a gateway IDS, where you essentially assume the point of a firewall on the network, but you give it the intelligence of the IDS to let it enforce policy.
KLAUS: For the next year or so, we're going to continue to see firewalls that are very much complementary to IDSes. They play a very specific function at a high level, setting the policy of what you allow in and out of your network. Any IDS can inspect what you allow into your network, and potentially stop those attacks. You're going to see more and more firewalls with some IDS capability.
GLEICHAUF: What could dramatically change things for everybody is the trend toward end-to-end services tunneling through port 80. There will be an even greater emphasis on what's inside the envelopes rather than the envelopes themselves.
KLAUS: The new hybrid threats are leveraging instant messaging networks, which by default are trying to get around firewalls. Not maliciously, but they want to grab the most market share, and the best way to do that is to masquerade the data just like it was a browser or any kind of Web connection. The only way to really dig into that data is to go one layer deeper than firewalls do today, and that's where IDS provides significant value.
RANUM: We haven't seen any of the mass rooters or remote control Trojans that are effectively employing SSL or any kind of transaction securities that would masquerade as e-commerce. But as soon as that happens, it's all over for firewalls.
GLEICHAUF: And that's why, as we go forward, there will have to be this integration of endpoint- and network-based intrusion detection monitoring and firewalling. Customers are going to have to make much more significant investments than they had formerly thought, and it will increase the cost of ownership and the emphasis on really good management tools, because managing many host/server endpoints versus a couple of NIDS peering point nodes is a big issue.
ISM: Let's discuss standards, which presuppose a problem of heterogeneous environments within the IDS space.
RANUM: The reality is that the vendors can't take the time to play with the standards guys. I ran into this when I was building firewalls back in 1992 [for Trusted Information Systems]. I wanted to deploy a firewall that had an integrated VPN, and I was one of the first vendors that did. If I had waited for the IETF to get off the stick about producing an IPSec standard, I would have had to wait until all my competitors were caught up. In fact, I would have had to wait three years. So it's not just the customer versus vendor dynamic, it's really a time-to-market versus an inability-to-innovate dynamic.
GLEICHAUF: Yes, when the vendors have participated in the IETF, we haven't been able to come to consensus for a number of different reasons. This has been a festering problem. I haven't seen what will break free for us to really do it well. Somebody big will have to weigh in.
Martin Roesch, Sourcefire
ISM: You've been granted one wish by the IDS genie to change the IDS world. What do you do?
ROESCH: IDS vendors really need to at least start getting along on some basic things, like sharing information -- not so much like the antivirus guys or anything like that -- but having our systems be able to interoperate with each other at least for sharing the output systems. There's been a real failure so far of anybody to come up with the one true output format that normalizes everything and brings everything together.
RANUM: It would be nice if there was at least a reasonable cut of a baseline benchmark for intrusion detection capabilities. It's a difficult problem. We've seen a number of cases where testing labs have been very badly skunked on how an IDS benchmark might work. So you get these things that produce results that are absolutely spectacular in a lab, but fall over dead on a customer network.
GLEICHAUF: The way I would like to effect change in the IDS space is for the managed service providers to have a stronger influence. They can help effect change in many of the areas we're talking about by virtue of all the different customers they touch.
KLAUS: If I could change the IDS space, I'd change it from intrusion detection, which is kind of a reactive state of looking at the problem, to more of a proactive paradigm, where we stop attacks or prevent attacks from happening at all.
IDS Crystal Ball
Over the next two years, what will be the most significant change in IDS technology?
KLAUS: What we'll see is that IDS in and of itself will be built into the components that make up the infrastructure. I think we'll see IDS ultimately being built into almost every firewall, every operating system and every desktop out there, so it's not a separately deployed product, but already built into the infrastructure when people deploy it.
GLEICHAUF: Two years from now, we'll see IDS migration into the infrastructure. Five years from now, we'll see the rise and fall of aggregation. And by that I mean that aggregation of data in the form we're talking about is simply a milestone toward getting to where it's transparent and used simply to identify the data models that get automated and embedded in systems.
RANUM: I think we'll see smarter sensors that work together, and a lot of aggregation. The next big fight in the IDS arena will be over aggregation, and, oddly enough, for all the vendors to be able to participate in that fight, we'll have to open up our data sources.
ROESCH: We'll see the proliferation of different sensor types, and we'll finally see the ability to effectively aggregate all this data and correlate it. We'll get an intelligent, high-level picture of what's actually happening on the network as opposed to this kind of collection of point solutions, and we'll try to make sense of it. We'll start seeing sensor technologies that work in concert with each other to identify real threats and give people the capability to analyze those threats effectively.
ISM: How do we get to intrusion prevention?
KLAUS: False positives are a key issue as we move in that direction. Obviously, if we're tagging legitimate traffic as attacks, customers will just not install our stuff in fear of stopping legitimate business. As an industry, we'll have to spend a tremendous amount of resources and time getting our algorithms fine-tuned, so that when people run our stuff, there aren't a lot of false positives.
ROESCH: There's always going to be a place for intrusion detection as a complement to intrusion prevention. One of the things with intrusion protection is that you're going to get systems that do the job, but you'll still need some sort of intrusion detection capability backing them up when they fail. Intrusion prevention is going to be yet another good layer of defense.
RANUM: Prevention is going to happen once we've got these detection systems that are better at getting their diagnosis quickly and more accurately, and they go into some kind of a centralized decision-support system. My guess is that we'll wind up with less of a prevention approach than a management approach -- intrusion management rather than prevention. We'll need to build a decision-support system that is constantly aware of the total state of a particular enterprise's vulnerability.
ISM: If you look at the state of IDS today compared to five years ago, what do you see?
RANUM: In 1997, I thought that it was actually useful to collect information for the customer and tell them virtually everything that was going on in their network. Our product was originally designed as kind of a super-smart program sniffer, and we got into the intrusion detection space because it can also do intrusion detection if you program it to do that. I thought that customers wanted lots of information about what's going on. They don't actually want information about what's going on, they want to be told the significance of what's going on. And that change in my thinking has driven our products into a completely different direction. People buy an IDS so they know what kind of attack they're under, and frankly they don't want the packets unless they're researchers. They want to know the significance of that attack to their particular network.
GLEICHAUF: Five years ago, we thought 10BaseT was the market and that we needed to invest in the data tools to help deal with the data, and that would create pull-through for products. And what customers did is they were spending their money and demanding faster and faster sensing, which put the whole area of data analysis tools on hold. So the IDS marketplace has grown more slowly than I thought it would.
KLAUS: One of the assumptions we had was managed security services were going to be really geared toward people who didn't know anything about security. So we thought, OK, the large companies already have a security team, so they have no need for MSS, but the small- and medium-sized businesses will be very interested. It's true that the SMBs were interested, but we were really wrong in that a lot of large companies are interested as well. That's changed with the economy. Back in the dot-com days, money was coming out of everywhere, and you didn't think about ROI. Obviously, that's changed a lot, and now large companies are saying, "How do we become more efficient at doing security management?
ROESCH: The biggest surprise for me, as an open-source guy, is the power of the open-source development model. When it's applied properly, and it actually works, it's a fantastic, powerful development model. From an IDS perspective, the things that have been surprising to me have been the fact that it's taken everybody as long as it's taken us to get to the point where we are today. I think we finally have a good understanding of the problem we're trying to solve now, and the next five years will be spent solving that problem.
Editor's note: In the September issue of Information Security, we'll turn the tables and ask four enterprise infosecurity managers to discuss the trials and tribulations of today's IDSes.