From owner-freebsd-pf@FreeBSD.ORG Fri Jul 30 00:07:02 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DE751065672 for ; Fri, 30 Jul 2010 00:07:02 +0000 (UTC) (envelope-from allicient3141@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id F146A8FC12 for ; Fri, 30 Jul 2010 00:07:01 +0000 (UTC) Received: by bwz12 with SMTP id 12so588790bwz.13 for ; Thu, 29 Jul 2010 17:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=VXI8vYLaOcebrGNQIjrGEffpTBJTkAAQQFg6OLd/hHU=; b=ohih73geny+Rum0zjdz/aaoDasrt6ROrRdZpeVJesT5dd/X8BlMJJsG3ykc37+umTE jmL83KLVau8xx42g5NbhRksj+1eW7GJRX1IoTUPTkm2E4uLgvlfEMX8uslRGie+RBqbU 0XyDCYMmCya7A6N5mMsnCG1Zv94uOlwkoJq+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Cp9KbPP2pbYhrtz3qxDo1qDPqMOF/PTwmxdzNOyBQDPNFgx6IqS0SBWAH+nvkZ4NYO dk5W0KpFIMMF6vIchL3tsg3uPtqEtmMP4tFP05l7k/7K6ju0fCRvDIoKMlBxsTweXyqv +8OBXeDBY0+C68kfI37MtpXwLzRE4YPrzx2XQ= MIME-Version: 1.0 Received: by 10.204.45.136 with SMTP id e8mr608903bkf.94.1280448420673; Thu, 29 Jul 2010 17:07:00 -0700 (PDT) Sender: allicient3141@gmail.com Received: by 10.204.112.208 with HTTP; Thu, 29 Jul 2010 17:07:00 -0700 (PDT) In-Reply-To: References: <20290C577F743240B5256C89EFA753810C46894B92@HIKAWSEX01.ad.harman.com> <9E8D76EC267C9444AC737F649CBBAD902769BF6F5B@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902767E3BF75@PEMEXMBXVS02.jellyfishnet.co.uk.local> <9E8D76EC267C9444AC737F649CBBAD902769C51EE9@PEMEXMBXVS02.jellyfishnet.co.uk.local> Date: Fri, 30 Jul 2010 01:07:00 +0100 X-Google-Sender-Auth: 6s5HCn3MDyfeCBoemXUq8TI76VM Message-ID: From: Peter Maxwell To: Chris Buechler Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-pf@freebsd.org" Subject: Re: For better security: always "block all" or "block in all" is enough? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 00:07:02 -0000 On 30 July 2010 00:08, Chris Buechler wrote: > On Thu, Jul 29, 2010 at 5:09 PM, Peter Maxwell > wrote: > > > > An ISMS, is a company defined document so will likely have different > entries > > or even none at all for that matter depending on the company. In a > previous > > company I worked for, you would have just supported my point. > > > > And nice try, what documents & sections in PCI DSS, Basel II, and SOX are > > you referring to? > > > > I'm not going to bother looking up any specifics, but by your comments > as a whole it's blatantly obvious you haven't spent any time in a > highly regulated environment with internal and external auditors plus > federal regulators auditing more on top of that. Or maybe things > across the pond are vastly different than they are in the US, but I > doubt that. > If you're going to make broad statements about my background or capabilities, it would be massively ignorant not to use specifics. So go on, don't be lazy - if it is blatantly obvious to you, give us the benefit of your wisdom. While you are at it, why don't you furnish us with an example from either statutory legislation, regulatory guidelines or similar which actually states a requirement to log all dropped packets on a firewall. Then show that it is mandatory for a company to include that in the scope of their ISMS and information security policy. There probably is not a direct analogy with a Federal regulator here, the nearest I can think of are CESG certified staff/consultants. > > > >> Or it's part of a much larger picture which is fed into an SIEM system > for > >> event correlation and consequent alerting. > >> > > > > So, you're also exposing a node in you SEM to a shed load of unnecessary > > noise. > > > > Not true in the least. Block logs are probably overvalued as a whole > since what you're dropping by definition can't hurt you and the less > clueful tend to be more concerned about what they're blocking than > what they're passing, but there is value in analysis there. If your > hourly/daily average is X log entries and all of a sudden it's > drastically higher or lower than normal, there's something going on > that should be investigated. If we're taking pf as an example, there are per-rule statistics that will tell you that without the overhead of logging every packet. Then you have a considered choice on whether to enable logging of every dropped packet, or only a subset, say dropped udp packets. > What Greg describes is very common > (nearly universal aside from small institutions) in highly regulated > environments and provides value. The bulk of such organizations I've > done work for do the equivalent of adding a 'log' to every single line > in your pf.conf (or very close to it), and dump huge amounts of log > data to their SIEM. Or use something like NetFlow for passed traffic, > and just let the firewall log all blocks only. > In an organisational context, that may work. There is still the issue of whether it's extra load on the firewall, but put that aside for the moment. A typical organisation will not have that many firewall devices, and typically there won't be massive amounts of data traversing them, so you can probably afford to drop that amount of data into a SEM; of dubious use, but you can do it. When you start looking at a carrier environment managing many, many, more firewall modules, it starts to get a tad silly to dump all blocked packets into a SEM - what do you really expect it to tell you for the much more expensive price tag?