tag:blogger.com,1999:blog-168210992011-04-21T15:30:30.628-04:00Ramblings from the information security/information survivability/risk management wildside.Christofer Hoffhttp://www.blogger.com/profile/05054085294006720012noreply@blogger.comBlogger21100tag:blogger.com,1999:blog-16821099.post-1149908373347949952006-06-09T22:58:00.000-04:002006-06-09T22:59:33.346-04:00Hi.<br /><br />I've pruned the posts and moved my blog to <a href="http://rationalsecurity.typepad.com">http://rationalsecurity.typepad.com<br /></a><br />TypePad gave me more control and better options for blogging.<br /><br />Thanks,<br /><br />Chris<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/16821099-114990837334794995?l=rationalsecurity.blogspot.com' alt='' /></div>Christofer Hoffhttp://www.blogger.com/profile/05054085294006720012noreply@blogger.com0tag:blogger.com,1999:blog-16821099.post-1127104986822805982005-09-19T00:15:00.000-04:002005-09-19T00:43:06.890-04:00About two years ago as I was malcontently slumped over another batch of vulerabilities which required patches to remediate, it occured to me that even in light of good vulnerability management tools to prioritize vulnerabilities and patching efforts as well as tools to deploy them, the fact that I had to do either in a short period of time, well, stunk.<br /><br />Patch too early without proper regression testing and business impact analysis and you can blow an asset sky high. Downtime resulting from "Patches Gone Wild" can result in more risk than potentially not patching at all depending upon whether the exploit is in the wild and the criticality of the vulnerability.<br /><br />It was then that a VC contact turned me on to a company (who at the time was still in stealth mode at the time) - Blue Lane Technologies - who proposed a better way to patch.<br /><br />Namely, instead of patching the servers reactively without testing, why not patch the "network" instead and apply the same countermeasures to the streams as the patches do to the servers?<br /><br />Assuming all other things such as latency and resiliency are even, this would be an excellent foothold in the battle to actually patch less while still patching rationally! You would buy yourself the time to test and plan and THEN deploy the actual server patch on your own schedule.<br /><br />Guess what? It works. Very well.<br /><br />We started testing a couple of months ago and threw all sorts of nastiness at the solution. It sits in-line in front of servers (with NIC-card failover capabilities, thankyouverymuch) and works by applying ActiveFix patches to the network streams in real time. We took a test box behind the protected interface and had multiple VMWare instances of various Microsoft OS's and applications running. We hit it with all sorts of fun VA scanners, exploit tools and the like. Of course, the "boxes" were owned. We especially liked toying with MetaSploit since it allowed us to really play with payloads.<br /><br />We "applied" the patches to the machine instances behind the PatchPoint Gateway. Zip. Nada. We couldn't exploit a damned thing. It was impressive.<br /><br />"Ah," you say, "but any old NIPS/HIPS/AV/Firewall can do that!" Er, not so, Sparky. The notion here is that rather than simply dump an entire session, the actual active streams are "corrected" allowing good traffic to flow while preventing "bad" traffic from getting through -- on a per flow basis. It doesn't just send a RST and that $50M wire transfer to /dev/null, it actually allows legitimate business traffic to continue unimpeded.<br /><br />The approach is alarmingly, well, so 20 years ago! Remember application proxy firewalls?<br /><br />Well, if you think about how an FTP proxy works, one defines which "good" commands may be executed and anything else is merely ignored. A user could connect via FTP and type "delete" to his heart's content, but if "delete" was not allowed, the proxy would simply discard the requested command and never pass it on to the server. Your session was still up, you could continue to use FTP, you just could not "delete."<br /><br />Makes sense, no?<br /><br />If, for example, Microsoft's MS05-1,000,000 patch for, say, IIS was designed to remediate a buffer overflow vulnerability which truncated the POSTS to 1024 bytes, then that's exactly what Blue Lane's PatchPoint would do. If it *does* (on the odd chance) do something nasty to your application, you can simply "un-apply" the patch which takes about 10 seconds and you're in no worse shape than you were in the first place...<br /><br />It's an excellent solution that further adds to reducing our risks associated with patching for a price point that is easily justified given both the soft-cost cost avoidance issues associated with patch deployment and the very real costs of potential downtime associated with patch installation failures.<br /><br />Other manufacturers are rumored to be offering this virtual patching capability in their "deux ex machina" solutions, but I dare say that I have yet to see a more flexible, accurate and simple deployment than Blue Lane's. In fact, I've yet to see anyone promise to deliver the fixes in the timeframe that Blue Lane does.<br /><br />I give it the "It Kicks Ass" Award of the week.<br /><br />See <a href="http://www.bluelane.com">Blue Lane Technologies</a> for a far better explanation than this one.<br /><br />Chris<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/16821099-112710498682280598?l=rationalsecurity.blogspot.com' alt='' /></div>Christofer Hoffhttp://www.blogger.com/profile/05054085294006720012noreply@blogger.com11