From owner-freebsd-security@FreeBSD.ORG Sun Sep 10 03:29:04 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 399B916A403 for ; Sun, 10 Sep 2006 03:29:04 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B538D43D58 for ; Sun, 10 Sep 2006 03:29:02 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1431193pye for ; Sat, 09 Sep 2006 20:29:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dUevRXLxtqTsI7yNPWn4ifLi9drhQWwUECKE5q84S4EtbhssCX5psHPcpp1SYnV9YqIMLuxatWpyLQx33Z4br8I+zLdLPcHU7p97KbZiXhWBshs9AE1EFGrH6NGrws47O0DW0EGQFW2Hc2Pg6JyaPPJ8n1rsIqlTdize1FwfcPo= Received: by 10.35.106.15 with SMTP id i15mr6675978pym; Sat, 09 Sep 2006 20:29:02 -0700 (PDT) Received: by 10.35.34.3 with HTTP; Sat, 9 Sep 2006 20:29:02 -0700 (PDT) Message-ID: Date: Sat, 9 Sep 2006 22:29:02 -0500 From: "Travis H." To: "Bigby Findrake" In-Reply-To: <20060908101441.V90396@home.ephemeron.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060908101441.V90396@home.ephemeron.org> X-Mailman-Approved-At: Sun, 10 Sep 2006 11:23:31 +0000 Cc: freebsd-security@freebsd.org Subject: Re: comments on handbook chapter X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2006 03:29:04 -0000 On 9/8/06, Bigby Findrake 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