Thursday, March 10, 2005

Visiting Sourcefire

Today I visited the Columbia, MD headquarters of Sourcefire with DC Snort Users Group founder Keith McCammon, pictured with me at left. We drove up from our Falls Church, VA office to meet with Sourcefire founder and Snort creator Marty Roesch. Sourcefire is housed in an Ikea-type building constructed to house optical networking start-ups during the dot-com craze. In addition to Sourcefire, Optical Capital Group Ventures and another company called Debt Shield share the space.

We started our conversation with Marty by discussing the new VRT Certified Rules License Agreement. Marty said that Sourcefire isn't a "nameless, faceless company. Real people work here." He demonstrated Sourcefire's commitment to the security community by mentioning the change to the Audit clause, previously reported here. Marty reported that many companies, several of which he was previously unaware, have reported interest in Snort Integrator licenses. As of this afternoon almost 2,000 people had already registered for the new rules system. The revenue collected from those who choose to subscribe and those who purchase Integrator Licenses will be reinvested in rule development. Sourcefire employees seven people on its Vulnerability Research Team to create and test rules. They include Judy Novak, who I had not seen for several years.

Besides helping to pay rule developer salaries, revenue from the new rules system will also help pay for the equipment Sourcefire uses to develop and test Snort. At right is a picture of one of the racks of networking and testing infrastructure Sourcefire owns. The racks holds $500,000 worth of Spirent Avalanche and Spirent SmartBits network traffic and load generation gear. When Sourcefire develops a new rule, they don't just run Tcpreplay to pass traffic and test Snort's ability to trigger an alert. (I'm not faulting Tcpreplay -- it's a great tool and I use it often. In fact, Aaron just announced the release of Tcpreplay 3.0beta1, with many new capabilities.)

Sourcefire tests that Snort is able to trigger an alert while watching a loaded network. I would like to see someone replicate this setup in their basement! In other words, it's not going to happen at anywhere near the same level of quality assurance. This is the problem I have with ventures like those of Demarc and the mysterious Mr. Alternative Ruleset. Users should always be able to create their own rules, as that is one of the strengths of an open system like Snort. However, they must be exceedingly careful not to cripple their IDS by writing poor rules.

At left is a picture of some of the racks containing servers Sourcefire uses to develop Snort and associated components. Marty said the company has over 26 racks with more than 300 servers. They maintain gear for every version of their appliance they've shipped. They also have target ranges and plenty of development systems. When Sourcefire develops a new rule, for example, they perform 6.8 million regression tests to ensure the new rule does not adversely affect the rest of the rule base. Sometimes these tests take up to four hours per change, even with the load distributed across multiple servers. Sourcefire takes great care to ensure that their rules will not cause Snort to waste excessive time processing packets. Marty told how a rule developed by an external Snort user once made such poor use of PCRE that it took Snort 3 seconds to process each packet!

After looking at Sourcefire's server room, we toured the workspace. Marty employees over 60 people in his Columbia, MD location at over 100 worldwide. In addition to meeting with Judy Novak, who works on the VRT, we also spoke with Snort rule uber-creator Brian Caswell. I mentioned that the Snort 2.3.1 ruleset had new rules not in the 2.3.0 distribution. bmc told me that 2.3.1 packaged all of the new rules up to the date of the new licensing structure, which was 7 March. We discussed having a future DC Snort Users Group meeting closer to Columbia, MD to accommodate the schedules of Marty and Brian. I was surprised to see so many people working on Snort -- you can see in the picture the row upon row of cubicles. There were two engineering meetings happening when I took the photo, so many desks are empty.

After touring the floor we spoke to Marty about the future of Sourcefire. He is excited about the new IS5800 appliance. "This will take the performance issue off the table, and leave detection technology as the key metric," Marty said. Previously companies like Sourcefire were criticized for not being able to keep up with offerings by Tipping Point. Marty reminded us that the ability to process packets per second was more important than a device's "Gigabit" rating. I saw the IS5800 myself, so it is not just marketing hype. I think it will be an amazing piece of gear for those who want to run Snort at speeds over 1 Gigabit.

Near the end of our visit Marty made some interesting points about market pressure on the security scene. He said Sourcefire felt the heat from Gartner's declaration that IDS is dead. (Incidentally, I reported in 2003 that the Meta Group countered Gartner's worldview by saying "network and host intrusion detection systems (IDS) [are] high on the shopping list" of big businesses. Unfortunately, their point of view died when Gartner acquired Meta for $162 million in December 2004.) The integration of the Snort-inline code gives stock Snort the capability to do IPS, which is currently the "hot topic" for security purchasers. Apparently security commentators and reporters want nothing to do with intrusion detection; it's all about IPS now. Unfortunately, we all know that prevention eventually fails.

Keith and I thanked Marty for spending nearly two hours with us. We drove down the street and met Tenable Security founder and CTO Ron Gula for lunch. Ron made some good comments concerning the state of security certifications when he heard I passed my CCNA exam. He said that no one can agree on how to approach the security problem. He divided the world into people that "do" firewalls, IDS, vulnerability scanning, code audits, and a few other categories. Each buys the product and/or service that fits their world view. No one can agree on a standardized methodology to secure a network. Some people think the CISSP meets this need, but anyone who has taken the test knows the CISSP fails miserably in this respect. I posted in 2003 some thoughts on good certification features, and I wrote in The Tao that the best aspect of the CISSP is its code of ethics.

At some point in the future I would like to spend some time at Tenable to get a better look at their operations as well. Thanks to both Marty and Ron for spending some time with us today!

No comments: