[unisog] Do Windows file access, file mod, file create timestamps lie?

[Brian Smith-Sweeney]

> And this isn't just a Windows issue.  Most OS will cache atime updates for
> as long as is felt safe.  The effect isn't as dramatic as NTFS, but it's
> still there.  And if you want a real shocker, mount an OSX volume
> read-only, root around in it, and check the timestamps.  Then umount/mount
> it again and breathe easy.
> 
Yeah this gave us a bit of a jump the other day.  I ended up posting
about it to the Sleuthkit list and only got a response from one guy
there.  After looking around for some relevant documentation (and
finding none) we submitted a bug report to Apple who says they've got an
engineer working on it.

This has some pretty horrific implications for forensics.  Imagine you
do your analysis, look at some files, and at some point fire off your
script or Autopsy to generate a file activity timeline for you.  Then
later you notice modified atimes on files that *should've* been on a
read-only volume.  Might call into question how well you followed your
incident response procedure.  I've thankfully never had to testify
regarding my forensic work, but this seems like the kind of thing that
would mess with your credibility.

Read-only volumes should be read-only.  Representing them otherwise,
even if you're not actually modifying them, is a Bad Thing.

Cheers,
Brian