[logs] Re: Log integrity handling on central logsystem

wynn.fenwick@private

Nice!!

I have been reviewing this lately. There are some specific
recommendations within ISO17799 (specificially section 10.10) which is a
decent high-level guideline for management of logs. I've never been a
big fan of fuzzy standards. There is often room for a lot of
interpretation, which can be orders of magnitude difference in risk and
cost. 

Ie: 17799 doesn't state which algorithm one should use to verify the
authenticity of the logs once stored, or the aperture for modification.
It simply says some measure should be taken. S10.10.3 sets some
guidance:

	"Implementation guidance
	Controls should aim to protect against unauthorized changes and
operational problems with the
	logging facility including:
	a) alterations to the message types that are recorded;
	b) log files being edited or deleted;
	c) storage capacity of the log file media being exceeded,
resulting in either the failure to
	record events or over-writing of past recorded events.
	Some audit logs may be required to be archived as part of the
record retention policy or because of
	requirements to collect and retain evidence (see also 13.2.3)."

For example, 
A) Digitally sign the logs in real-time from a private key signed by a
CA which has an assurance level at least the level of assurance that
these logs would provide evidence to protect = $N; 
B) Individual access to logs by a closed user group with privilege
escalation = 1/100th $N???

I have suggested to many that B) with an MIC hash (ie: at least MD5sum
or SHA1sum) of the logs at compression time, sent to another user or
location that has a different set of administrators (ie: maybe a
manager's or team email box) might be one place to start. 

Let the auditors then generate the findings that force the justification
for a higher assurance level of authenticity.

Many auditors will say (and many tool vendors will never say) - the goal
here is not to burn every cent of revenue on security safeguards but to
provide gauges and levers for the the management of omnipresent and
dynamic risk. 

IANAL, but the admissability issue is very interesting in that there are
two ways to admit the info. When we get to this point, though, usually
all hell has broken loose. 

Wynn

"A good plan executed today is better than a perfect plan executed at
some indefinite point in the future." - Gen. Geo. Patton

-----Original Message-----
From: loganalysis-bounces+wynn.fenwick=cgi.com@private
[mailto:loganalysis-bounces+wynn.fenwick=cgi.com@private] On
Behalf Of Eric Fitzgerald
Sent: Friday, September 01, 2006 1:16 PM
To: loganalysis@private
Subject: [logs] Re: Log integrity handling on central logsystem

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
_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis