<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Matasano Chargen - Latest Comments in Why ConSentry Isn&amp;#8217;t Going To Solve Security</title><link>http://matasanochargen.disqus.com/</link><description></description><language>en</language><lastBuildDate>Wed, 04 Apr 2007 03:15:53 -0000</lastBuildDate><item><title>Re: Why ConSentry Isn&amp;#8217;t Going To Solve Security</title><link>http://www.matasano.com/log/768/why-consentry-isnt-going-to-solve-security/#comment-2322025</link><description>It would seem I promised the world in my blog!&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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...&lt;br&gt;&lt;br&gt;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.&lt;br&gt;--Michelle</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Michelle McLean</dc:creator><pubDate>Wed, 04 Apr 2007 03:15:53 -0000</pubDate></item><item><title>Re: Why ConSentry Isn&amp;#8217;t Going To Solve Security</title><link>http://www.matasano.com/log/768/why-consentry-isnt-going-to-solve-security/#comment-2322024</link><description>I just commented on something you left me on my blog prior to seeing this.  I should have included ConSentry to the list:&lt;br&gt;&lt;br&gt;&lt;a href="http://rationalsecurity.typepad.com/blog/2007/04/the_philosophy_.html" rel="nofollow"&gt;http://rationalsecurity.typepad.com/blog/2007/0...&lt;/a&gt;&lt;br&gt;&lt;br&gt;The port density "commitment" to high-speed security that Crossbeam has is, indeed, like comparing bacon to eggs ;)  &lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;As to your other points (and not trying to single out Consentry) you're absolutely correct.&lt;br&gt;&lt;br&gt;/Hoff</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Christofer Hoff</dc:creator><pubDate>Tue, 03 Apr 2007 15:59:51 -0000</pubDate></item></channel></rss>