Re: log file protection. A WORM can be used like this. To use with normal filestructures you need to segregate the filestructure stuff (index files, directories and the like) and allow data to be written to the disk, or have a filestructure that just looks for the highest version of a directory or index block. I wrote a software WORM and published it (in src) in the mid 90s for VMS; the driver checked that any disk block it wrote above a "fence" block number was being written for the first time and would junk the write and claim success if not (so someone messing with it would not immediately realize that the attempt failed). The container was encrypted to defend the abstraction as I didn't want someone to mess with the container file directly. Someone could of course corrupt the contents, but it would be difficult to alter them tracelessly. Note too that the mapping of container file to logical disk blocks can be whatever I want. Not totally bulletproof, so a real WORM device is far better, but good enough to resist many attacks, in the sense of making tampering more likely to be detectable than in cases where a logfile is just written somewhere. The reason for doing this kind of thing was to improve the integrity of logfiles where it was infeasible for whatever reason to alter the software that wrote them. I should note that most sequential writes in fact buffer a device block before writing to a device, and that these techniques are useless against attacks that alter the memory buffers before they can be written. Clearly, more verbose logs minimize this issue. A number of companies have filesystems for WORM devices. The ones that write data to WORM periodically use this "normally use the highest version" scheme but can generally be told to use earlier indices to in effect undo changes. Glenn Everhart -----Original Message----- From: rferrellat_private [mailto:rferrellat_private] Sent: Tuesday, July 24, 2001 9:01 PM To: forensicsat_private Subject: Re: Signature on logs/eMail Hi folks, One of the solutions to the log authentication problem I've been pondering lately is the write once/read many network logging device. This could be essentially a CD-ROM drive (or the equivalent technology) designed to write a copy of the log in real time, using a process that makes subsequent overwrites physically impossible (or as near to impossible as one can get in this business), at least without obvious signs that an overwrite has been attempted. We know, for example, that each write pass over magnetic media leaves a permanent trace in the media substrate, so a detector specially designed to check for multiple writes could be employed as a verification check before and after the media was loaded into the drive. It could even burn a permanent record of the initial verification run, protected by a checksum (for example) in the header of the disk itself. This is all highly speculative, of course, although some aspects of this technology do already exist, and it doesn't address the issue of verifying currently existing logs. It would be expensive to develop and, at least initially, to deploy, but it might be a viable long term means of coming to terms with the electronic record verification problem. In thinking about the problem, I was reminded of my days in corporate security, when alarms and other electronically monitored security incidents were recorded in real time on a dot matrix continuous feed stack, attempted alterations to which were usually quite easy to spot. Courts seemed to have little trouble accepting those logs as genuine. Just a little postulating from a speculative fiction writer... ;-) Cheers, RGF Robert G. Ferrell, CISSP ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Wed Jul 25 2001 - 09:45:58 PDT