Re: [fw-wiz] Vulnerability Response (was: BGP TCP RST Attacks)

From: Paul D. Robertson (paul_at_compuwar.net)
Date: 06/01/04

  • Next message: Paul D. Robertson: "RE: [fw-wiz] Vulnerability Response (was: BGP TCP RST Attacks)" 
    To: "M. Dodge Mumford" <dodge@dmumford.com>
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

  • Next message: Paul D. Robertson: "RE: [fw-wiz] Vulnerability Response (was: BGP TCP RST Attacks)"

    Relevant Pages

    • Re: Password Cracking
      ... >> The problem is that cracking passwords does not reduce risk. ... > dictionary attack, I am justified in claiming that cracking passwords ... >>> order in which they uncover them. ... Password crackers do not prove anyhting at all ...
      (comp.security.misc)
    • Re: Password Cracking
      ... >> The problem is that cracking passwords does not reduce risk. ... > dictionary attack, I am justified in claiming that cracking passwords ... >>> order in which they uncover them. ... Password crackers do not prove anyhting at all ...
      (comp.os.ms-windows.nt.admin.security)
    • Re: Illegal to do research on cryptography?
      ... Um that's risk management not security. ... system is high because the cost of attack is low. ... Hackers go after everything. ...
      (sci.crypt)
    • Re: But the Borders are Secure now..........
      ... attack by Al Qaida? ... that's why I asked for his evaluation of the risk and noted that I ...
      (rec.bicycles.racing)
    • Re: But the Borders are Secure now..........
      ... that's why I asked for his evaluation of the risk and noted that I was running the risk of making an invalid inference. ... how does one evaluate the risk of a terrorist attack? ... The easiest way to evaluate the risk of terror attacks is to look at the historical record, which is pretty much how actuaries like to study risk when they're insuring you. ... the risk posed by Al Qaida to be higher than I have, it would be interesting to know if Tom is now feeling more secure than he used to as a gauge of popular opinion. ...
      (rec.bicycles.racing)