Mike Murr over on the Forensic Computing blog posed an interesting question yesterday, surrounding the definition of "forensically sound". Mike made some interesting points...I suggest you read through them and ponder the idea for a bit.
This was also picked up by Richard Bejtlich at TaoSecurity.
My thoughts on this is that it's an important and timely question really...what is "forensically sound" evidence? Given that potential sources of evidence no longer consist of simply hard drives, but now also include volatile memory, the network, and non-hard drive sources such as cell phones, PDAs, thumb drives, digital cameras, etc., maybe it's about time for another definition.
I'm not usually a big fan of massive cross-posting, but this is an important issue...the current definition doesn't bode well for live response and acquisitions. So, if you're so inclined, read up and add a comment.
Addendum, 4 Aug: It looks like we may be closer to a definition. I'm copying and pasting this definition from a comment I made on the TaoSecurity blog:
"A forensically sound duplicate is obtained in a manner that does not materially alter the source evidence, except to the minimum extent necessary to obtain the evidence. The manner used to obtain the evidence must be documented, and should be justified to the extent applicable."
The second sentence in bold is something I added. Having been in the military, I'll just say that the placement of "must" and "should" were purposeful and intended.
Thoughts?
I think we should probably separate dead forensics and live forensics in a definition of forensically sound evidence.
ReplyDeleteIn cases where the only option is traditional or "dead" forensics, we can clearly define a "forensically sound" image as an one that is an exact digital copy of the suspect's digital data - be that from a hard drive, thumb drive, memory card, etc...
But with more focus being put lately on live forensics, perhaps more specific criteria should be looked at for the definition. It would be helpful in most courtrooms if specific methods of live RAM acquisition could be referred to, while phrasing the definition as lawyer-friendly as possible :)
Do you think it would be possible to refer to known methods?
Something along the lines of:
If the volatile system memory was imaged, then it must use as little memory space to be run as possible, and have a clearly identifiable executable. In addition, the target where the system memory is written should be as unobtrusive to the suspect operating system as possible. If an external USB type device is used, it should not inject any code into the target OS (i.e. the newer U3 type devices). If something along the lines of NETCAT is used, then its process payload on the suspect's system memory should be as small as possible, and preferably not alter the networking stack.
I'm not comfortable with how you have to give the suspect's NIC a static IP to get NETCAT to work. I've done forensic exams in the past where having the last IP address the suspect's OS was using is pretty important. When the practitioner has to modify that IP to image memory, I think that would leave a pretty big hole for a tech-savvy defense attorney to start attacking.
With that being said, what are your thoughts on this? Do you think specific methodologies (not specific tools) should be adopted as a defacto standard for doing a "forensically sound" image of RAM? Or do you think that this would just be re-stating the obvious?
Do recall that what you are attempting to do is create a definition for technicians. The Federal Rules of Evidence already have a definition that acts as a rule for admissibility. Anything beyond that, for the purposes of litigation will be too specific and introduce unnecessary conflict.
ReplyDeleteAnonymous...
ReplyDelete"Do recall that what you are attempting to do is create a definition for technicians."
Not necessarily. If you follow back to Craig's original comments, then to Michael's on his blog, and then to both Craig and Michael's on the TaoSecurity blog, at no point does anyone say that this is for technicians only. In fact, it's pretty clear that what we're attempting to do is redefine "forensically sound" overall, so that things such as the contents of RAM and other devices can be included as evidence.
Geoff,
ReplyDeleteI've recently re-read your comment and had some thoughts I wanted to share:
If the volatile system memory was imaged, then it must use as little memory space to be run as possible, and have a clearly identifiable executable.
Okay, that sounds good. It also seems that this issue has already been addressed. Using just George Garner's version of dd.exe, for example, uses as little memory as possible right now, and the executable is clearly identifiable.
In addition, the target where the system memory is written should be as unobtrusive to the suspect operating system as possible. If an external USB type device is used, it should not inject any code into the target OS (i.e. the newer U3 type devices).
I'm not sure how one would go about defining "as unobtrusive as possible", other than to simply say that the investigator should endeavor to (a) minimize the impact on the system, and (b) document her steps so that the impact is defined.
Also, to be clear, the U3-enabled devices do not "inject code into the target OS". They rely on the 0S's inherent ability to provide an autorun capability for CDFS drives.
Yes, this *can* be used to "inject code" by someone, but one would hope that the basic tenets of forensics would prevent a responder from picking up a thumb drive that he finds on the ground on his way to a scene, and using that device.
If something along the lines of NETCAT is used, then its process payload on the suspect's system memory should be as small as possible, and preferably not alter the networking stack.
Again, I'm not sure how one would go about defining "as small as possible". Instead, I'd recommend defining a methodology, and using that. The issues I can see running into is that if you strip out all of the other functionality of netcat and include only the basic components needed to send traffic out over the network, and then code that in assembly, do you then have a tool that is "as small as possible"? If so, it can be argued that you cannot then add encryption, b/c it's not "as small as possible".
Altering the network stack would perhaps entail changes to the system that should be caught during the validation and documentation process for the methodology.
I'm not comfortable with how you have to give the suspect's NIC a static IP to get NETCAT to work.
Interesting. I use DHCP on my network, and that includes my VMWare guest OS's and I have yet to experience this issue with netcat.
Good points Harlan.
ReplyDeleteUsing just George Garner's version of dd.exe, for example, uses as little memory as possible right now, and the executable is clearly identifiable.
Exactly what I had in mind when I mentioned using minimal memory. If we're seeking a definition of "Forensically Sound", then any tools that are created in the future should adhere to the same standards, or risk not being used by forensic examiners.
I'm not sure how one would go about defining "as unobtrusive as possible"
Neither am I :)
On the U3 devices - I guess using the phrase "inject code" was not quite what I meant. More like "not give the target OS a chance to further modify it's registry or log files"... know what I mean?
As far as NETCAT - I realize you don't "have" to alter the IP addy. What I was referring to was that in the definition of "forensically sound" Something should mention that if the network information is altered, then some information in volatile RAM about the user's network address could be lost... In other words, don't make any modifications to the target system that would change that.
Hope that made sense... It was a long day at work, and the sleep monkey is on my back.
...any tools that are created in the future should adhere to the same standards, or risk not being used by forensic examiners.
ReplyDeleteMost tools used today in live response weren't designed for that purpose. What we have to do is test the tools, validate them, and decide if they want to use them.
On the U3 devices - [snip]... know what I mean?
Oh, very much so!
As far a modifying the target/victim system, of course we don't want to do that...but if it must be done then we want to do as little as possible, and document what we do.
Part of what we need to keep in mind is that the tools we use are not written by folks who have a forensics purpose in mind. Those that are are most often of limited distribution. So test the tools, be sure of what you're doing...and document everything!