Firewall Wizards mailing list archives

Re: Vulnerability Response (was: BGP TCP RST Attacks)


From: "Paul D. Robertson" <paul () compuwar net>
Date: Tue, 1 Jun 2004 12:33:25 -0400 (EDT)

On Tue, 1 Jun 2004, M. Dodge Mumford wrote:

Paul D. Robertson said:
If it can't be attacked, then arguably, it doesn't need to be fixed.

That sentiment surprises me a bit. It appears to me to violate the concept
of defense in depth. Blocking the exploit path to a vulnerability may

I did say "arguably."  However, "can't be attacked" isn't automatically
equatable to "can't be attacked right now," which is what I think you're
getting at- for a large number of vulnerabilities- can't be attacked
right now equates to "this quarter/year" sorts of things- for another
large set of vulnerabilities, it equates to "better odds that your
platform vendor of choice will suddenly figure out how to convert all
their software to bug-free code!"

There's an argument to be made for always patching, only patching
occasionally, or never patching- it really all depends on your risk, and
which ways you choose to mitigate risk.  While patching is a valid
additional control, it's not the only additional control, and it may well
be that _for_some_things_ it's not the right suspenders to go with the
belt.

mitigate the risk greatly, but the vulnerability still remains. In your
instance, the exploit path would involve attacking your host operating
system that's performing the firewalling.


Obviously, which is why infrastructure is more important than ever!  It's
also a much easier sell to harden and spend real time on infrastructure
than it is on things which are infrastructure, but are so ubiquitous that
they're not seen as such, like desktop operating systems.  Now, guess
which OS gets more care and feeding- even though it's probably less at
risk (after all, the XP subsystem exists to deal with actively malicious
and unknown code of decidedly questionable use.)

I would think the point of mitigating the risk is to buy you time to fix the
vulnerability. That "time to fix" may be "until Longhorn is released." Which
assumes that Longhorn (or, broadly, version++) will fix the vulnerability.

Yes, that's a risk mitigation point, however it is possible to sometimes
ignore risk, or marginalize it where the rate of successful attack is near
zero, and it's possible to do the same where the cost of successful attack
is near zero.  The proof, of course, is in being able to successfully
predict those things, and move to change the posture when those
predictions aren't correct in a timeframe that still provides sufficient
protection.

It may be that it's more prudent to patch regularly once a quarter, and
block in the meantime, or it may actually be prudent to patch immediately-
there are significant costs with patching (not all of them
labo{u}r-related.)  Sometimes, the cure is worse than the disease- and
that has to be factored into any risk assessment.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


Current thread: