Sunday, July 23, 2006

Logs in A Recent UBS Case

I am sure by now everybody heard about this UBS case, mostly due to a sneaky "he is a hacker" defense tactics ("@Stake had employed hackers [oh, horror - AC :-)] and Adams questioned several witnesses about whether hackers could be trusted with critical evidence...").

But there is another less well-covered aspect of this: logs. Here is an example: "Faulkner testified Wednesday that logs of any kind are poor forensics evidence. " I suspect he is talking about "logs=hearsay" argument, which might or might not fly.

Moreover, it gets deeper: "Faulkner said the logs can't be trusted as a form of evidence because too many of them can be edited by a root user. And he added that there are different means of access, for example, that aren't recorded in a specific log. Faulkner said user history logs can be edited by a root user, as can SU logs and command logs, which record what commands were made on the system. ''The logs are more for accounting,'' he told the jury. ''They're not designed for investigative purposes because they don't log everything.''

It makes little if any sense to me. From what I read (yeah, I know, IANAL, etc) just saying that something can be done does not invalidate the use of logs. Yes, UDP can be be spoofed, injected and intercepted, but that clearly doesn't lead to all syslogs being thrown out all the time. Yes, files can be modified, but it doesnt' mean they actually were.

So, what logs specifically were used: "VPN logs, WTMP logs [...] and SU (Switch User) logs." Are they guaranteed to always be bad evidence? Definitely not!

Here are some more interesting comments on the same case (and, not, I didn't write them :-))

2 comments:

Anonymous said...

What a lot of these vendors don't mention is the value of using logging appliances or separate log repositories to create a separation of powers. If you get the events off the originating device as soon as they're created and move them to someplace that the server admins can't access, you have a better argument (not a watertight one, but a better one :-) that they're more reliable. Separating auditing and monitoring from execution is always good practice.

Anton Chuvakin said...

Sure, I love to mention it, but sometimes its an uphill battle since some folks think they can "save money" by combining those responsibilities in one [soon to be poor :-) due to unemployment] sysadmin

Dr Anton Chuvakin