Firewall Wizards mailing list archives
RE: Vulnerability Response (was: BGP TCP RST Attacks)
From: "Marcus J. Ranum" <mjr () ranum com>
Date: Thu, 27 May 2004 13:07:34 -0400
Dave Piscitello wrote:
But don't you think you can manage risk better if you mitigate by central policy definition and patch management?
I don't think patch management is the solution for any significant aspect of the problem. I know that flies in the face of the "common wisdom" of security these days, but I think eventually time will tell and we'll give up on patch management as a security technique. The only place patches make a difference is on services that are internet-facing or mission critical. What you'll find is, if you can define those systems and services, you'll have good security if the list is small and the machines are well configured. If the list is large (the "have cake, eat it too, not get fat" philosophy of Internet security) you'll have cruddy security no matter what you do. Put differently, I see the "patch it everyplace" approach as an over-extension of an approach that *did* work OK: policy-centric host hardening. The idea was that we could harden certain crucial hosts and they'd be "safe enough" for Internet use. So people went and extended that philosophy to "harden everything" - i.e.: patch it everyplace. The problem is that hardening hosts only works when you are working with underlying software that CAN BE hardened and host operating systems that CAN BE secured. We were comfortable with building - and were able to build - very strong bastion hosts back in the early 90's. So people looked and said, "behold! if we just patch everything, then we won't NEED a proxy firewall! after all, we'll be as SECURE as a locked down proxy host!" Ummm.... Wrong. Given a few more years this reality will sink in. The "right way" is still the right way and has been all along. It's: - minimize your access footprint (reduce zone of risk) - default deny - identify the few Internet services you need to the few servers that need them, and lock those services down * keep those services patched if you can't lock them down with better means like chroot, setuid, and file permissions - audit and look at your logs The way this is gonna play itself out is that eventually the "old school" security folks are going to get really really tired of saying "we told you so" and switch to saying, "yeah, it hurts, doesn't it? stop whining. you got what you asked for."
I've used the CIS security tool (includes HFnetchk) and templates one-off with both MMC plug-in and local policy editing. This is hours per computer, and does not scale even in my home office. But if you use a template and push a configuration from a central policy server to all clients, it's more efficient, and uniform.
Centralized policy administration works but largely because it's USUALLY used to implement basic commonsense like default deny and minimized zone of risk. Don't confuse the symptom with the solution, though!! Organizations that do centralized policy administration are not more secure because that's what they do. It's that organizations that "get" security are more likely to be doing centralized policy administration. Because, done cluefully and with discipline, it helps. Clue and discipline is better off centralized because your typical organization does not have enough clue across the spectrum so you need to aggregate it in the central administration. Organizations with high clue in their IT department will centralize administration because they know users can't be trusted. As I write this I am realizing that there are a lot of dearly held myths of security that are misunderstood because we assign the effect to the symptom!! How could we have been so foolish, as a community?? :(
Perhaps initially, but this is a systemic problem, no? Anyone with kids knows the "clean the room" syndrome, and security operations are like parents with lots of messy children. Each child does little or nothing for a long long time, until the only way to clean his or her room is to literally empty it and restore order and cleanliness. But if the effort to establish the baseline is followed by more disciplined administration and housekeeping, the must fix disaster list is shorter, and more suitable to prioritization.
Put differently: after one beats one's head against the wall long enough, either one's brains turn to jelly, or one's clue level increases.
"None of our users would accept that kind of solution!" they cried.If this attitude is pervasive, then the client wasted your time and spent their money unwisely.
:) How pervasive do *YOU* think that attitude is, Dave? mjr. _______________________________________________ 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)