[logs] Re: Log integrity handling on central logsystem

Eric.Fitzgerald@private

Mea culpa: the link to my blog is actually
http://blogs.msdn.com/ericfitz and the category on legal/regulatory
requirements can be directly reached via this link:
http://blogs.msdn.com/ericfitz/archive/category/14726.aspx

Currently I have an excerpted section (with link to full text) on
Canadian national law on rules for electronic evidence and an excerpted
section (with link to full text) from the US Department of Justice
Cybercrime manual, which discusses logs in detail, citing statutory &
case law.

-----Original Message-----
From: Eric Fitzgerald 
Sent: Thursday, August 31, 2006 6:15 PM
To: 'Anton Chuvakin'
Cc: loganalysis@private
Subject: RE: [logs] Re: Log integrity handling on central logsystem

Regulations are probably coming and we are partly to blame.

I've started collecting legal & regulatory requirements for computer
logs, on my blog: http://msdn.microsoft.com/ericfitz

If you stumble across links, send them and I'll post them.  Maybe Dr.
Bird will put up a repository on loganalysis.org. (Hi Tina!)

A large number of my customers assume that log signing is a legal
requirement.  However I'm unaware of such a requirement.  I fear that
the industry itself is doing customers a disservice by pushing log
signing solutions.  In fact there is a warning from the courts on this
in the DoJ Cybercrime manual, section V, subsection B-1
http://www.usdoj.gov/criminal/cybercrime/s&smanual2002.htm#_VB1_ :

     United States v. Glasser, 773 F.2d 1553, 1559 (11th Cir. 1985)
     ("The existence of an air-tight security system [to prevent
     tampering] is not, however, a prerequisite to the admissibility
     of computer printouts. If such a prerequisite did exist, it
     would become virtually impossible to admit computer-generated
     records; the party opposing admission would have to show only
     that a better security system was feasible."). 

Also consider what you're giving up with log signing:  You can't reduce
signed logs by filtering out stuff you know you don't want prior to
storage.  You have to store everything.  You also can't translate
numeric tokens (often used in both Solaris and Windows logs) into
human-readable strings.

Regarding translation: "DOMAIN\USER" is a lot more understandable than
"S-1-5-21-32413514364-16452321255-1623531341-1964"

Regarding filtering prior to storage: I'm also seeing guidance here that
filtering is unacceptable.  I don't understand this.  The policy that
tells the system what activities for which to generate logs is itself a
kind of filter (it's a pre-filter instead of a post-filter).  By this
line of reasoning, if you are not allowed to filter, then you must turn
everything on full throttle, and store it all.  This will be untenable
for most organizations.  There are many systems, Windows included, that
are capable of generating so much log information that the system will
spend more resources logging than performing its "real" job.

In an enterprise the size of Microsoft, even with a reasonable audit
policy we generate tens of terabytes of security log data per month
(yes, we collect most of it and analyze what we collect).  The storage
cost for this is not cheap.  Online storage is nearly cost prohibitive.
Offline storage would be much less but dealing with that quantity of
data requires very diligent processes and sophisticated tools.
Extracting data out of this is actually quite a technical feat as well.

With ACS, which will ship late this year as part of Operations Manager
2007, we filter prior to event generation (audit policy); we don't
filter prior to transmission but we order, encrypt and sign (so we can
detect gaps and tampering), and we filter after verifying event stream
integrity but prior to routing to analysis tools or database.  This
seemed like a good compromise, although we get a lot of customer
requests for filtering at the agent what is sent on the network.

Finally, log signing requires key management.  To prevent log tampering
on the box where the log was generated you probably need a perfect
forward secrecy kind of key rotation solution.  For scalability you
probably will use HMAC and hash chains rather than true public-key
signing operations for most event records, instead choosing to sign only
every nth record or every t hours or whatever.  Each block will have its
own key although depending on implementation there might be a way to
derive K(n+1) from K(n).  Local key storage pretty much would obviate
the usefulness of the feature as in the absence of a TPM, obtaining the
local key has exactly the same difficulty as tampering with a
well-designed audit trail.  This implies a pretty sophisticated,
distributed key management solution.

Overall I am very concerned about the trend towards log signing- I think
it's the wrong move for the reasons above.

However I'm not blind to the way that the wind is blowing.  Sigh.

Eric

-----Original Message-----
From: anton.chuvakin@private [mailto:anton.chuvakin@private] On
Behalf Of Anton Chuvakin
Sent: Thursday, August 31, 2006 2:10 PM
To: Eric Fitzgerald
Cc: loganalysis@private
Subject: Re: [logs] Re: Log integrity handling on central logsystem

> Regarding log signing: is anyone aware of an actual regulatory or
legal
> requirement for log signing?

Isnt't that a bit too specific for most current regulations? I
personally haven't seen any direct regulatory mandate for log
signing...

-- 
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
     http://www.chuvakin.org
 http://chuvakin.blogspot.com
http://www.securitywarrior.com
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis