Validation of Hardware Write Blockers
I have always thought the standard was to validate hardware write blockers before first use on evidence and after changes to firmware. I was in a discussion about this topic and the person I was talking with said his lab validates their hardware prior to every acquisition…. Sounds logical but also seems overkill to me.
Any thoughts? Does anybody know where I can find the documented standard for this?
IF your HWWB fails validation one day, how many of the acquisitions since the last validation are good and bad? Could you take the stand in each of those cases and swear the acq was valid?
We also validate before every acquisition. I have had two WB fail in the past, I don;t want to have to tell a client his case may be mush necause the hardware could be called into question.
Thats also why we wipe every drive before acquiring, even though we may be using FTK imager to put a dd image into a folder. We wipe, the format, make a folder and acquire. It's not necessary, BUT it keeps the other side from calling procs into question and no matter how well you explain, the jury hears "reasonable doubt".
My masters work is on this very topic. There is no standard. Worse, there's much inconsistency between examiners. Best practice would seem to be to test equipment against an examplar drive often, verify images at the start and end of examinations. Finally, cross-verify tools against each other. As Bill indicated, always copy to a wiped destination. We could start a whole forum section on discussing best practices.
I have been thinking about this a little more… seems to me like a match of the acquisition and validation hashes when you are doing an acquisition would prove the write blocker was functioning correctly for that acquisition. Would it not? Wouldn't a policy of verifying these 2 hash values match for an acquisition serve as your validation on the write blocker?
And what happens when they don't match? Are you willing to take that risk when it matters most? Validating the hashes means you pulled the image and it's intact not that your write blocker is working properly.
I can acquire a disk in linux and not use a write blocker and generate matching hashes, it doesn't prove that a write blocker works though.
Assuming a dead acquisition, if the hashes don't match than you know there was an error during image. Re-image and re-validate.
To prove a write blocker blocks writes does require additional verification steps. That ought to be done to each newly acquired write-blocker and at some interval there after.
My only objection to the "interval" mathod, is if I find an error in the HWWB at some point, I have to call into question and throw out every image made since the last verification, since I have no way of knowing when it went bad.
Not worth the risk for me or my clients.
Wel, I don't think so. Let's talk about the workings of HWWBs for a couple of minutes.
If you had one that suddenly allowed writes, then you would have a concern. I don't think any of us will ever see that. It just isn't a failure mode we'll see with HWWBs. They simply don't start allowing writes. (Ignoring those with switches where the user can mis-set the switch). The most common failure mode will be no image, or mis-matched hashes as a result of a bad connection. Bad connections are a set-up issue and would be confined to the image being taken at the moment. Only that image would be impacted, and frankly, ought to be redone.
In the lab I work in we validate our WB devices on a schedule (once a month I think). Courts and attorneys seem to like the fact we do regular check-ups and normally don't question us further on it.
Once a month?
Do you only work on cases once a month?
No, the idea is that if the device is working month to month, it cannot break and fix itself. This provides a reliable indicator (when looking back) as to whether a device was working properly.