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 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
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) 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) 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) 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)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) George Capehart (Jun 03)