Yes. Snort has been an IDS/IPS engine since 2004 when we baked in the IPS functionality.
SnortSP we've been refactoring it. In early performance testing we realized that we didn't like what we were seeing from a performance perspective so we've been working on refactoring it to get to the performance envelope that we really want to see. The concept behind the SnortSP project was to build a common platform for building network traffic analysis apps and have them to be able to operate cooperatively on the same platform and same memory space so that they can share information about the real time environment that they were seeing and protecting. It was about being able to add things like DLP, reputation filtering or client-side inspection and really any network facing app that you would want to do that would involve deep-packet inspection. In theory it could be stuff as diverse as running a Web application firewall or even a vulnerability scanner. So the basic idea behind SnortSP was to be able to bring that to the table.
If an organization is going to invest in Sourcefire 3D and Snort, is there an understanding that they are going to also need to make an investment in another person or people to manage it?My thinking is driven by exposure to people in the community and other people who have developed intrusion detection/prevention engines in the industry and also the open source community.
founder, CTOSourcefire Inc.
Yes. I guess that shouldn't be a surprising thing at this point. We're 16 years down the road for network intrusion detection and prevention. It comes with a price tag of at least a person to babysit it once in a while. What we've been trying to do is reduce the amount of interaction required to get value out of the technology. The root problems associated with the tuning headache and the false positive headache boils down to asking people to keep their prevention systems up to date with a network environment that is evolving in real time. We build up a comprehensive network map of the environment and then we use that map to do things like tune our sensors, so the sensors that you can buy from Sourcefire can tune themselves. We also use it to do automatic data analysis. When we get an event in from Snort, we analyze that data so that we know about the target. We can rate and prioritize how important it is in your environment at that point in time. So the net effect of that is that we've taken away the tuning burden from people and then we do the impact assessment to reduce the stuff that remains down to the data that is actually important to the environment. You have talked about working on a new detection engine for Snort. What is being changed and why does Snort need a new detection engine?
It's a bit esoteric, but the detection engine model that snort uses today is one that is built around buffering the types of traffic and doing pattern matching to localize ourselves within the network protocol streams and using anchor points that we find in the data streams to try to detect attacks. The model that I would like to go to is more of a hierarchical protocol inspection model that reduces the amount of buffering involved and essentially does protocol decomposition instead of using our buffering and pair matching system that we've been using for the last 10 years. It's much less memory intensive. The net of it is that we believe we will be able to go faster and inspect deeper than we can today with this new engine model. How much of the changes that you make to Snort comes from the Snort community and how much of it is more of a business driver?
Actually, none of the above. In terms of driving the new detection engine design; that was mostly my own ideas that I kind of developed over the last 10 or 12 years of working on Snort and it's a "if you had it to do over again what would you do differently" kind of approach to the problem. What it's design reflects is the maturing of my thought on the topic than anything else. The community has never been real vocal about what kind of detection model you would use and they've never been real vocal about the structure of things like streaming assemblers and things like that. That's really down in the weeds kind of stuff and most people are operating at the level of making it talk to a database or getting a detection plug-in that works in the existing framework. The Snort 3 concept and SnortSP is really the refinement of a lot of my thinking and a lot of my thinking is driven by exposure to people in the community and other people who have developed intrusion detection/prevention engines in the industry and also the open source community. Sourcefire announced integration with QualysGuard a year ago and this year you've added a connector piece, making integration easier. How does combining Sourcefire IDS/IPS with vulnerability data improve its capabilities?
Our RNA technology discovers the network and builds that network map of what you've got out there. One of the things that it does as a byproduct of its operation is it builds up a vulnerability map of the network that it's observing. We use the vulnerability map for automated tuning of the snort engine and the impact assessment, looking at the real time event stream coming into our defense center and using that to provide real time prioritization for events. The integration with QualysGuard allows us to import vulnerability data discovered by Qualys directly into the map so that we have a positive identification of the vulnerabilities instead of just a vulnerability imprint. That allows us to have even more accurate tuning of the detection engine as well as better impact assessment capability.