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:
- RE: Vulnerability Response (was: BGP TCP RST Attacks), (continued)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Ben Nagy (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Ben Nagy (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Paul D. Robertson (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) R. DuFresne (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Jim Seymour (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Ben Nagy (Jun 01)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) M. Dodge Mumford (Jun 01)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) Paul D. Robertson (Jun 01)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (Jun 01)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) Paul D. Robertson (Jun 01)
- Re:Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (Jun 01)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Paul D. Robertson (Jun 03)