For better security: always "block all" or "block in all" is enough?

[Peter Maxwell]

On 30 July 2010 00:08, Chris Buechler <cbuechler at gmail.com> wrote:

> On Thu, Jul 29, 2010 at 5:09 PM, Peter Maxwell <peter at allicient.co.uk>
> 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?