Firewall Wizards mailing list archives
RE: Vulnerability Response (was: BGP TCP RST Attacks)
From: "Ben Nagy" <ben () iagu net>
Date: Tue, 25 May 2004 14:29:10 +0200
Heya, Well, I see your point, BUT... If we're talking real world, my experience is that virtually every company that is large enough to be complex is wide open to multiple worm infection vectors. A well designed worm (for a change) would go through the first world like curry through a drunk. Firewalls don't really help very much - every major organisation that gets w0rmed already had one (and YES, I'm sure they had 139 445 and 1025 closed). This is not news, and that's part of the reason I work in "vulnerability management" now. Did you see this: http://www.dtc.umn.edu/weis2004/weaver.pdf I like Weaver / Paxons' stuff, but in this case I think they are being conservative. My stance: Stack-based remote system windows exploits need to be identified and patched yesterday, end of story. Anything else is downright negligent. "Mitigation" (eg pseudo airgaps, firewalls, pixies and unicorns) has failed in 911 systems, utilities, airline reservation systems, coastguard, banks.... - all of which included "isolated networks". The trouble is that people are so punch-drunk now with MS patches that nobody knows "critical" from "critical and urgent". I think that OS vendors _and_ the research community could do more to address that issue. It will only get worse - a 0day worm would knock our socks off. To me, amongst the plethora of product, service and snake oil there are two evolving solution spaces that solve real problems. Host based vulnerability mitigation, and anything that allows an organisation to condense and prioritise information about where they are exposed to known vulnerabilities in realtime. Firewalls remain a critical part of any infrastructure, of course, but, to be frank, they just don't work as well anymore. Actually, I feel so strongly about this I'm going to go ahead and cc the list on a unicast response. Sorry - and, Ken, please don't interpret this as a flame or rant against you. I think you must have just touched a nerve. ;) Cheers, ben
-----Original Message----- From: Claussen, Ken [mailto:Ken () kccweb com] Sent: Tuesday, May 25, 2004 1:36 PM To: Ben Nagy Subject: RE: [fw-wiz] Vulnerability Response (was: BGP TCP RST Attacks) Good morning Ben. I would say "Mitigating Factors" provides the ease of use that you refer to. By implementing or compensating for the Mitigating Factors it is possible to decrease the real world severity in a given environment. Note: Lessen does not mean eliminate. IE. A firewall blocks LSASS until an infected laptop comes home and connects to the LAN. Unless there is a screening process before the Laptop is allowed on the LAN (uncommon) it will likely pass the infection on to other systems. In this case the mitigating factor extended the time a company could spend evaluating the patch before deployment, but does not entirely eliminate risk of infection/compromise. Ken Claussen MCSE (NT42K) CCNA CCA "In Theory it should work as you describe, but the difference between theory and reality is the truth! For this we all strive"
_______________________________________________ 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) Ben Nagy (May 21)
- <Possible follow-ups>
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Ben Nagy (May 25)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (May 27)
- RE: Vulnerability Response Ben Nagy (May 27)
- RE: Vulnerability Response Marcus J. Ranum (May 27)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Dave Piscitello (May 27)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (May 27)
- RE: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (May 27)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) Devdas Bhagat (May 27)
- Re: Vulnerability Response (was: BGP TCP RST Attacks) Marcus J. Ranum (May 27)