Rational Survivability

I dredged this post up from my prior blog because I think it’s interesting and relevant today given the current state of vulnerability management and patching.  I wrote this entry almost a year ago on 9/15/05, and I thought I’d bring it back to life here.

The post describes an alternative to the frenzied activities of Patch Tuesday and dovetails on what has become the raging debate of third party patches.  That being said, I don’t think there’s any excuse for crappy code, but today’s realities mean that despite tools like firewalls (even app. level,) NBAD, and IPS, we still have to patch — one way or another.

My motto is work smarter, not harder and I think Blue Lane’s product allows one to do just that.  It helps you manage risk by buying time — and in some cases by patching what is otherwise unpatchable.

I want to bring to light an issue that was raised by Mike Rothman: is the "patch proxy" concept fab or fad?  Market or function?  One could argue that ultimately IPS vendors will provide this functionality in their products.  However, today, IPS products do one of two things:  Allow or Drop. 

I’m not going to argue the "market or function" question, because that’s not the point of this post.

Blue Lane’s PatchPoint provides in-stream remediation at the network layer — the same remediation you’d get on the actual host but without having to touch it until you’ve regression tested the box.  So the product isn’t solely "Intrusion Detection" nor is it solely "Intrusion Prevention" — I like to call it "Intrusion Correction."

When I wrote this, I was one of Blue Lane’s first customers and their technology really proved itself quite well and worked very nicely as a L2 insertion with the rest of the layers of security we already had in place.  It allowed us to make rational decisions about how, when and why we patched so as not to incurr more risk in hasty patching than the exploit might do harm should it hit.

Unfortunately I can’t pull the comments section that went with it as I had a great exchange with Dominick White on why this wasn’t just like "…every other IPS product."  Honestly, in hindsight I would go back and clarify a few points, but perhaps the post in it’s original form will provoke just as many comments/questions as it did before.

Chris

September 15, 2005

About 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.

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.

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.

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?

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.

Guess what?  It works.  Very well.

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.

We "applied" the
patches to the machine instances behind the PatchPoint Gateway. Zip.
Nada. We couldn’t exploit a damned thing. It was impressive.

"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.

The approach is alarmingly, well, so 20 years ago!  Remember application proxy firewalls?

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."

Makes sense, no?

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…

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.

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.

I give it the "It Kicks Ass" Award of the week.

See Blue Lane Technologies for a far better explanation than this one.

The product provides (now) virtual patching for Microsoft, Oracle, Sun, Unix and Linux.  Sure would be nice not to have to apply 65 patches to your most critical Oracle databases every quarter…

I am certain that elements of this entry will require additional explanation and I hope we can discuss them here as this is really a very well-focused product offering that does a great job without boiling the ocean.

Chris