RE: SIM solution - Objectives ? (Firewall logging)

While I understand the importance and inevitability of audit, let's be
clear: Aggregation / Archival is _not_ monitoring. I put all my
Starbucks reciepts in a shoebox and ignore it until tax return time.
That is not monitoring.

When I monitor, I check to see if I accounted for my expenditures
throught the period. If I reconcile them periodically (and I would argue
a year is likely too long to be "periodically") then that is monitoring.


Also, monitoring is not response. You can monitor for exceptions, and
alert on exceptions but if nothing is done about it, have you achieved
anything? Monitoring is about defining exceptions (counts of events or
new unknown events) and assessing the risk presented by the stimulus
which caused those events.

If you look at ISO 17799 for log monitoring (where a lot of things like
COSO, CoBIT, and )they are not prescriptive on the period of
reconciliation.

ISO17799-s10.10.2 (this could be old) calls for the creation of
procedures to monitor system use, and review of the results of this
monitoring shall happen regularly, including:
*	Authorized access,
*	Privileged operations,
*	Unauthorized access attempts,
*	System alerts or failures, and
*	Changes to, or attempts to change, system security settings and
controls.

And yes, unless you wash the feet of the auditors after they step over
the palm branches laid before them, "good enough" should suffice. I
argue that the controls one needs to manage ones business are not
reasonable if they put one out of business. I don't believe that is the
spirit or the intent of these pieces of legislation or regulations. It
is to take a refocussed and reasonable (aka "good enough") effort
towards due dilligence. 

That is part of the challenge is what regulation are the objectives
aiming to satisfy...

PCI DSS, for example, is another matter entirely. PCIDSS-s10.6 (this
could be old) defines a review period for all system components, where
ISO17799 does not. Additionally it specifically mentions security device
logs such as intrusion detection system and authentication server logs
are in scope for these reviews.

W


-----Original Message-----
From: Paul Melson [mailto:[email protected]] 
Sent: Tuesday, May 29, 2007 3:08 PM
To: Fenwick, Wynn; [email protected]
Subject: RE: [logs] SIM solution - Objectives ? (Firewall logging)

-----Original Message-----
Subject: [logs] SIM solution - Objectives ? (Firewall logging)

> I love it when people take this logic and extend it such that a 
> switching
firewall is asked to log 100+ 
> bytes of data per session.  The firewalls tend to work really well
then. 
>
> If you never reconcile the bank account, why keep all those little
receipts from Starbucks?

In case of an audit..? :)




Seriously, though, that's the idea.  Keep all the records you can so
that you have access to whatever you need in an investigation while at
the same time hoping you need none of them.


> Would it not be better to say that we are going to take X effort and 
> spend
it looking at a set of N 
> rolled-up events and action owners to fix stuff. Yes, it's asymptotic,
imperfect, and more art than 
> science, but it has precedents in many other areas and will likely 
> meet
"good enough"
> standards. 

Better than what?  Better than nothing?  Definitely.  Better than
drowning people in log data by asking them to read through millions of
log events daily?  Probably.  But I think a "best-effort" approach is
going to have a hard time meeting compliance requirements if you try and
claim it as a control (which it is).

What you're really called to do is define those specific events that you
will monitor for and let the SIM, log analyzer, Perl script, or whatever
isolate them for your review and review them all.  Best effort log
analysis beyond that, searching for specific historic events in an
investigation or looking at trends and metadata over time, should be out
of scope or at least very vaguely defined for any compliance stuff
you're dealing with.

PaulM