Re: [logs] Log archival

probertsat_private

On Thu, 12 Dec 2002 erinat_private wrote:

> Okay, I'm stepping up to the chopping block..........
> 
> First off, this is a great thread and rather than pull a 
> point-counterpoint, I'd suggest referencing an article I wrote that deals 
> with the subject: 
> http://www.vjolt.net/vol6/issue3/v6i3-a13-Kenneally.html  (III.B.2., most 
> notably).

I'm kind of counterpointish- so I'll wade right in with some issues, and 
if you don't mind counterpointing some of my assumptions, I'd appreciate 
it.  I'm going to start with one of your statements, because I believe 
heavily that it ties in with the checksumming issue:

"Computers may produce different results based on different assumptions of 
programmers, however, which can only be directly determined by looking at 
the source code."

While looking at source code certainly *can* provide a complete picture of 
what a program does, I think we've all (for the set of us who've dealt 
with large codebases) seen a lot of code where it doesn't necessarily 
help.  I'll also throw out another thing- it's perfectly valid to validate 
function by giving known input and comparing anticipated output as long as 
the scope of the expected behaviour is tested.  For instance, I can 
validate that an MD5 program does MD5 a set of given inputs to a set of 
given outputs and have _reasonable_ assurance that it will do it for any 
given input.  That doesn't mean that a particular function, or even 
implementation of a function hasn't been trojaned, but frankly source 
won't always tell you that either, and the supposition that we need to 
have a trusted computing base, a trusted debugger, and verify object code 
before we get to admissability is frankly way too far out.  Now, I'm 
slightly jaded- we have a division that "black box" tests and 
certifies cryptographic products[1]- but having seen the output of their 
process, and the number of problems they've found without delving into the 
source, as well as the results of actual usage of products that pass the 
test to believe that you don't need source to validate operation[2].

It's almost as dangerous to rely on looking at the source as it is to rely 
on function output- viral code isn't all that difficult to produce.  
That's one reason why checksumming programs is so important.  It does help 
if you can relate a particular source branch to an executable, but given 
the processor and compiler version fun we get these days, I'm not sure 
that's going to be true of most folks on this list who aren't just using 
binary tools (Hmmm- does that make open source weaker in some cases?  
Maybe I've just had too many GCC version issues lately *sigh*)

> As for Professor Kerr's article, I read it when it first came out and it is 
> indeed an extremely insightful article......
> 
> I'll try to address some of the issues/questions by reiterating some of 
> what I put forth in the aforementioned article as it pertains to judicial 
> approaches to reconciling the reliability of digital evidence (logs, in 
> this case) and the problem with hearsay and the business records exception 
> to digital evidence (logs, specifically):
> 
> I advocate, however, that it is dangerous to immunize certain computer 
> records from the hearsay rule by likening them to the product of a 
> mechanical process that cannot produce hearsay. It would be persuasive to 

The opposite view is also fairly dangerous though- I think it's reasonable 
to find them admissable absent the potential for, or indicators of 
significant malice.

> admissible data input, as with a radar gun or a calculator.  Computerized 
> printouts of phone traces, for example, were not hearsay in one case 
> because they did not rely on the assistance, observations, or reports of a 
> human declarant; the report of phone traces was contemporaneous with the 
> placement of the calls; and the printouts were "merely the tangible result 
> of the computer's internal operations."

Surely though, there's a threshold of normalcy that, absent other 
evidence, should stand as true.  For instance, I know that the creation 
and last accessed times on my disk drive are changable, but absent 
evidence that they have been, each instance of a file timestamp shouldn't 
be a mini-challenge waiting to happen.  Now, certainly part of this may be 
that the analysis and more importantly, standards of analysis might need 
to be professionally done or created.  

> As with authentication and F.R.E. 702 (reliability) standards, the depth of 
> inquiry and threshold of proof needed to establish computer-derived 
> evidence as a business record are not always clear. One of the earlier 
> cases to address this issue, for example, held computer records 
> inadmissible as business records because of an insufficient foundation. The 
> testimony of a record keeper for the telephone company was insufficient to 
> establish a proper foundation of "trouble recorder cards" at issue because 
> no complete and comprehensive explanation of either their method of 
> preparation or their meaning was provided. This was despite the facts that 

If there's a complete and comprehensive explaination- does that provide 
enough protection?  It seems to me that such an explaination doesn't 
affect the integrity of the process, which is the thing that *should* be 
the issue, so perhaps you can shed some light on the rationale from a 
lawyers perspective of why this is necessary- I certainly don't need to 
produce a complete and comprehensive explaination of an internal 
combustion engine in a hit and run accident (IOW, is this an artifiact of 
the court and the defense just needing to understand the technology, or is 
there a fundamental need of the prosecution to understand why a particular 
record was generated?)

> the witness testified to having direct supervision and control of all the 
> company's records, and that the cards were business records made in the 
> ordinary course of business at or about the times and dates indicated on 
> the cards.

It's my guess that a lot of precedent was set before we had farily 
widespread computer evidence technicians- can you perhaps enligten us on 
where that puts the courts in terms of admissability and veracity?  

> Unlike phone trace records and calculators, however, the software producing 
> logs (and log data) is programmed to capture and process data deemed to be 
> relevant to its programmed function from many computers over a network. 

That's only true of centralized log servers- which certainly have some 
issues- does that make a forensics friendly environment one which lots 
both locally and centrally?  

> Questions about how complete the data capture is and how the logging 
> software decides what should be captured and processed can only be done by 
> examining the underlying source. To admit such evidence without uncovering 
> the assumptions that underlie its function would invite the resolution of 
> claims based on less than a modicum of reliable evidence.

I'm not sure this is always true- having done a fair ammount of 
investigation in cases where the logs were most of what was there, but the 
suspect's admission of performing the act corroberated them, ommission and 
decision points aren't all that important compared to actual data points- 
the fact that 127.0.0.2 connected to the SSH port at 12:00 EST is a good 
indicator even if the IDENT record wasn't captured by a remote log 
server because of the SYN flood the attacker started in conjunction with 
the attack.

In other words, while sometimes it's possible that dropping the record 
that says "127.0.0.3" connected next, I think we shouldn't then 
automatically dismiss the logged evidence as hearsay and not admit it, but 
we should rely on expert analysis of the logs to help seperate the 
difference between possible, probable and factual.

> As for applying these legal standards and principles to the myriad of 
> digital scenarios, somehow I trust that there will be no shortage of issues 
> raised by this group ... looking forward to the dialogue.......

I'm sure I'll get clubbed down if we're veering too far from the 
technical, but I'd appreciate more of your insight, as these issues are 
near and dear to one of my roles :)

I think it'd be nice to see the FRE have a "computer record" section, 
rather than trying to lump them all into the buckets we all started out 
with.  There's a fine balance between falsified evidence and crimnals 
escaping justice that needs to be balanced.  If we can address even 
some of that in the logging technology, we'll all be better off.

Thanks,

Paul
[1] ICSA Labs, which has Crypto certification programs, the most notable 
of which is an IPSec program which has found things like IV, randomness 
and entropy problems in products without code review.
[2] I'm a big Open Source fan, but I've EnCased enough Windows boxes to be 
relatively happy that I can tell when the data hasn't been manipulated.
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
probertsat_private      which may have no basis whatsoever in fact."
probertsonat_private Director of Risk Assessment TruSecure Corporation

_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis