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

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

  • Next message: Marcus J. Ranum: "Re:[fw-wiz] Vulnerability Response (was: BGP TCP RST Attacks)"
    To: "Marcus J. Ranum" <mjr@ranum.com>
    Date: Tue, 1 Jun 2004 13:55:56 -0400 (EDT)
    
    

    On Tue, 1 Jun 2004, Marcus J. Ranum wrote:

    > So, if making your network separated so that "it can't be attacked"
    > is going to address 95% of the risks (ninjas, nanobots, etc, are still
    > a problem) and hardening the system is going to address another 95%
    > you're best off if you do the easiest/cheapest one first. In the case
    > of using my "perfect firewall" it's usually easier since it's almost
    > always easier and cheaper to NOT DO SOMETHING than to DO
    > something. The equipment cost for an air gap is low. ;)

    Right, this is why default deny inbound is still the #1 thing you can do
    to a network. It negates probably 85% of the attack traffic coming at
    you, and it's usually less than 10 minutes to implement on the border
    router. When I ran mail servers, I'd refuse to implement AV on my
    gateway, proclaiming it a "desktop problem!" That was probably the
    silliest stance I've ever taken (but it did keep my gateway maintanence
    low) - that's probably good for >80% of e-mail spreading malware. Add a DMZ
    for inbound HTTP, and you're sitting pretty good overall for the easy to
    do and high protection stuff. From there on, things get complicated,
    which is why everything else is not so uniformly implemented. I'd say
    that >70% of the outbound trojans use IRC as a control vector- so blocking
    6667 outbound (and this is a temporal block, it won't always be true for
    the bulk of trojans, but is for now) will reduce the risk of already
    compromised machines more than anything other than blocking outbound SMTP
    (well, outbound SMTP reduces your risk of hitting anyone else, not your
    risk of bad stuff happening _yet_.)

    > What's interesting is that if you have 2 security controls that each
    > help block (on average, assuming random distribution of attack
    > vectors - which is an interesting assumption) 50% of the attacks,
    > then you've got 75% of the attacks blocked. Again, the assumption
    > of random distribution is an interesting and important problem
    > in the theory. If the attacks distribute disproportionately - if you
    > can whack 50% of the network attacks and 90% of the attacks
    > are networked - then your air gap is going to show a much higher
    > value (95% of 90%) One of the things that makes firewalls
    > remain attractive is that a disproportion of attacks are networked
    > AND the effort factor to install them at a perimeter is low.

    Right, and in this case, defense in depth comes from two things- the first
    is doing that blocking in two places, the router *and* the firewall- it's
    your most effective control, so it should be duplicated, and the second is
    to deal with things that have to be allowed to use that vector (including
    desktop browsers, SMTP servers and Web servers.)

    > The concept of defense in depth is to do some pretty basic
    > stuff in lots of places. And it works. So if you're willing to
    > assume in Paul's example that "the system cannot be attacked
    > is ONLY 95% effective - then a 50% effective antivirus system
    > on the desktop behind the airgap bumps your likelihood of an
    > attack getting through down to a whopping 2.5%. But if you

    Actually, I'd argue that perimeter AV probably gets you that far, and
    desktop AV is good for about .5% protection from the same vector. Desktop
    AV is really the primary control for machine<->machine worms, but it's
    _likely_ that a "personal firewall" is more effective and requires less
    change over time.

    > think about it, your first line of defense makes a lot of the
    > difference and after that it's all diminishing returns.
    >
    > Hmm... Did I just say that "just doing ANYTHING" is a good
    > start? I think I did. ;) Perhaps that's why we find ourselves
    > on the fence about the host/network - where do I secure it ?
    > issue - doing *anything* that's not manifestly stupid helps
    > a great deal. Doing any 2 things that aren't manifestly
    > stupid gets you most of the rest of the way 100% for all
    > intents and purposes. If you accept some of the logic I've
    > thrown at you above, then it stands to reason that doing
    > things that help less than 40-50% of the time is probably
    > a waste of time unless you're doing 3 or more of them.
    >

    Right, the non-obvious point here is that doing 1 thing that's 95%
    effective is not always better than doing three things that are 80%
    effective. The obvious synergies have to be in the attack vector
    protection, but if the 95% thing is really hard and the three 80%'s are
    easier, you're much more likely to achieve success with the easy ones.
    The other side of the coin is failure modes- if you do 3 80% things and
    two of them fail, you're still likely to be better protected than doing
    one 95% thing, especially if that were to fail.

    So, if we take perimeter AV and desktop AV, both probably ~85% effective,
    and map that against hardening a system to not run signed code at all,
    which is probably 99.5% effective, but requires massive support and
    maintenance costs- AV wins. Yes, hardening is better- 99 times out of 100
    it'll work, where AV will work 85 times out of 100. Also, you'll get
    slightly better protection if the AV product isn't identical, because then
    the vendor's update cycles become synergistic.

    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: Marcus J. Ranum: "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: No Black Ice trial-ware or free version?
      ... understand that an attack can come from many program types such as an OCX, ... And BID does this very well. ... Too me a software firewall for the Windows desk top means: ... Know to enable the protection features that IE and OE have available on ...
      (comp.security.firewalls)
    • 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)