Date: Sat, 9 Sep 2006 22:29:02 -0500 From: "Travis H." <solinym@gmail.com> To: "Bigby Findrake" <bigby@ephemeron.org> Cc: freebsd-security@freebsd.org Subject: Re: comments on handbook chapter Message-ID: <d4f1333a0609092029n2d362c80me0bf58d8e70805e9@mail.gmail.com> In-Reply-To: <20060908101441.V90396@home.ephemeron.org> References: <d4f1333a0609061905y709843ecm454509067925a7ca@mail.gmail.com> <20060908101441.V90396@home.ephemeron.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/8/06, Bigby Findrake <bigby@ephemeron.org> wrote: > That's how I interpret that passage from the handbook - that you should > detect *and* prevent. I'm not clear on how anyone is interpreting that > passage to suggest that unequal weight should be given to one side or the > other (detection vs. prevention). The above passage all but says, "don't > do X because that will interfere with Y." I just don't see that advice as > advocating imbalance. Well, I think "one of the single most" is a somewhat strange turn of the phrase anyway. Which is it, one of many, or single? Anyway, he seems to be advocating /not/ hardening your system, so that the opponent can get in using an attack vector you know about, and which is easily detected. What if root runs a binary before the change gets detected? What if they alter the integrity database before the integrity check gets run? Ooops. There are plenty of ways to detect things without deliberately leaving known security holes hoping they'll be exploited by the first script-kiddie or worm that rooted your box. And if an access failure for a protection mechanism was auditable then every prevention would be a detection gratis. > In those cases, where you're hit by attacks that you didn't know existed, > the importance of detection probably rises. In fact, in the case of > attacks (and possibly vectors) that you weren't aware of, I would argue > that detection can be a prerequisite of prevention. Depends on what you mean by "didn't know existed". There are ways to prevent some 0-days, such as anomaly detection. There are some misuse-detection systems that can be given patterns general enough to catch derivatives of known attacks (I have a pretty good one that can catch most x86 stack overflows). And there are honeypots, that you can use to analyze your opponent's techniques. There are network forensic packages like sguil, that can provide valuable information either proactively (monitor all network traffic) or reactively (for analysis of how the attack got in). > But in the > cases where you cannot remove or mitigate the attack vector (eg. because > to do so would interfere with availability vs security), it seems to me > that prevention needs detection. Yes, I can agree with this, but my strategy is: Prevent if you can. An ounce of prevention is worth a pound of cure. Detect if you can't. Monitoring is boring and takes lots of time that could be used more productively. It's all sunk costs. -- "If you're not part of the solution, you're part of the precipitate." Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d4f1333a0609092029n2d362c80me0bf58d8e70805e9>