Utilizing a proven write blocker is generally important and a best practice during forensic investigations in order to ensure and prove that your actions as the investigator did not affect the original image (best evidence). Notice my use of the word “proven” in the previous section – depending on the situation, it can be very important that you utilize a tested form of write blocking technology (software or hardware) and can prove that it was functioning at the time of the image acquisition. This means that you need to develop a (or use an existing) test protocol that verifies the functionality of your write blocker of choice, and I’d personally recommend that you run and document these functional tests immediately prior to your acquisition process in order to help alleviate any concern that your process tampered with the original image. You can find some significant documentation on testing write blockers on the NIST Computer Forensics Tool Testing Program site.
Of course, now that I’ve gotten that off my chest, let’s get down to the real reason for this post – hardware versus software write blockers. There seems to not be a great deal of resources comparing these two options and also some discussion surrounding whether a software write blocker can be a proven and effective method for image acquisition. I think that the answer is: “yes, it can be effective, but consider your options.” In order to assist with the evaluation of the two options, I’ve put together a little pro’s and con’s list (please feel free to suggest additional items to be added to this list or correct any wrong assumptions I may be making):
Hardware Write Blocker
| Pros | Cons |
|
|
Software Write Blocker
| Pros | Cons |
|
|
A software write blocker can be implemented in a number of different ways (depending on the OS being used on the acquisition workstation, etc) and the current NIST CFTT test protocols for software write blockers only specifically deal with methods utilizing the 0x13 interrupt (however, they do state within their documentation that the tests can be adapted to other implementations). Given the number of possible differing implementations of software write blockers, it is very important that the person defending the process has a good deal of knowledge on how their software write blocking is implemented. Additionally, this person should be able to easily and clearly explain how the write blocker functions and prove that it was functioning at the time of the acquisition. Of course, the same requirements apply to hardware write blockers as well – although I find that, as mentioned above, they are easier to explain and appear to be more accepted.
As you’ve probably now guessed, when considering the information above and my personal workflow, I have decided that when needing to physically acquire an image that a hardware write blocker works better for me. However, that is a personal choice and from a technical standpoint a software write blocker (or similar proven functionality) can still be an effective and convenient method for preventing writes to an image. Is there anyone out there that utilizes software write blocking as their primary protection method during image acquisition? Has it easily held up to any challenge? Please feel free to comment…
I agree on the hardware write blocker. It is my personal choice. We use encase enterprise that allows acquisition remotely., as long as its on the network. What is your preferred hardware vendor for write blockers? Of course Guidance is recommending FastBloc but we may go with Tableau.