Why ConSentry Isn’t Going To Solve Security
Thomas Ptacek | April 3rd, 2007 | Filed Under: Industry Punditry, Uncategorized
Michelle at ConSentry writes,
Two - the innovation cycle for security vs. switching. This topic is even more interesting, because every shop has this problem. Basically, people want their infrastructure to last five to seven years but they know security changes at a much faster rate. So how can you have a switch that can “keep up” with those security changes?
I like how she’s condensed the problem here.
On the other hand, ConSentry’s answer to the problem is crazy.
ConSentry looks at this problem and says, “Security changes faster than network infrastructure. The answer is to build to the hardest common denominator: a switch with 10-20 Gig ports and a custom MIPS processor complex that can run software at those sustained speeds”.
My answer is, “Go read George Varghese’s book, come back, and tell me that a high-speed middlebox is the right place to solve interesting security problems at all”.
Switching is “commoditized”, if by “commoditized” you mean “completely owned up and down Monday through Sunday by a general manager at Cisco”. For switching to enable security, all it has to do is come up with a scaleable offload mechanism:
Fully commoditized SPAN ports
A high-speed high-density tap blade
Stats and trace export features like NetFlow-NG
Whatever backplane-enabled security foo Cisco decides to field when the PIX and IDS teams sort out their turf wars.
The problem with what Michelle is arguing is, security also changes faster than the speed of SRAM. Meaning, no matter how fancy and whizz-bang ConSentry makes their memory bus or north bridge complex or whatever it is they patented with that MIPS chip they designed, it’s still not going to be fast enough to:
Accomodate all the security features operators are going to demand
Make designing, implementing, provisioning, and fielding any one of those features simple and fast enough to keep up.
Handle the most complicated of those problems, which require line speed full decode and emulation of complicated server software, at all.
Chris Hoff at Crossbeam, which, for what it’s worth, has nothing resembling the commitment to high-speed security that ConSentry has (bacon and egg: Chris is the chicken, Michelle is, well, etc), called me out for arguing on the one hand that security belongs baked into the network and on the other that it should be kept the hell out of our core protocols. To clarify:
To the extent that we’re going to deploy security features in middleboxes deployed at arbitrary places on the network, Cisco is going to own that. The rest of security —- meaning, most of it —- will be solved elsewhere.
Christofer Hoff
April 3rd, 2007 3:59 pmI just commented on something you left me on my blog prior to seeing this. I should have included ConSentry to the list:
http://rationalsecurity.typepad.com/blog/2007/04/the_philosophy_.html
The port density “commitment” to high-speed security that Crossbeam has is, indeed, like comparing bacon to eggs
We’re not trying to replace the access layer. We sit in different areas of the network protecting different things. Perimeter or off the core switching fabric in the datacenter is where we sit. No need for high port densities; shunts off the switches with MLT gig ports or 10Gb/s connections into the load-balanced network processing modules that load balance across security applications running on blades in the same chassis.
Don’t need 500 core MIPS processors or a bunch of ASICs. FPGA’s and Intel processors do just find when you can scale sideways, thankyouverymuch.
As to your other points (and not trying to single out Consentry) you’re absolutely correct.
/Hoff
Michelle McLean
April 4th, 2007 3:15 amIt would seem I promised the world in my blog!
Is every security feature you’re ever going to use within the LAN going to get embedded in a switch? And come from ConSentry? No. But are there a lot of LAN security functions you can and should provide within the network itself? And is ConSentry doing that? Yes.
You’re right - building the horsepower to inspect and control every user flow is indeed hard. But we’ve built it. So calling it a crazy idea because it’s hard seems a bit late.
And if you merely dump all the flows from the switch into another box, doesn’t it have to have all the horsepower to process the flows anyway? Why is that easier? Besides, you want immediate enforcement - better that it’s in the forwarding plane directly.
And again, we’re not trying to do EVERYTHING. So the questions around full app decode and all that - we’re not trying to do that. Parse enough to know the app - for real, not by L4 info - and enforce policy on that info, but not take over all the granularity you’d apply within the app itself.
Appreciate your take on our level of “commitment” to security. The analogy leaves a bit to be desired, but that’s just because we’re the bacon in this case…
Actually, it’d be great to talk live sometime. We could probably have a richer discussion that way, with more clarity around what ConSentry is and isn’t trying to do. I’d really enjoy that chance. In the meantime, thanks for the dialogue.
–Michelle
Leave a reply