Validation of Hardw...
 
Notifications
Clear all

Validation of Hardware Write Blockers

12 Posts
6 Users
0 Likes
1,586 Views
(@bradspenrath)
Posts: 8
Active Member
Topic starter
 

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?

Thanks

 
Posted : 03/05/2007 8:24 pm
deckard
(@deckard)
Posts: 77
Trusted Member
 

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".

Bill

 
Posted : 03/05/2007 8:36 pm
(@bradspenrath)
Posts: 8
Active Member
Topic starter
 

Valid points…

 
Posted : 03/05/2007 8:44 pm
 ddow
(@ddow)
Posts: 278
Reputable Member
 

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.

 
Posted : 04/05/2007 1:36 am
(@bradspenrath)
Posts: 8
Active Member
Topic starter
 

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?

 
Posted : 04/05/2007 9:03 pm
hogfly
(@hogfly)
Posts: 287
Reputable Member
 

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.

 
Posted : 04/05/2007 10:02 pm
 ddow
(@ddow)
Posts: 278
Reputable Member
 

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.

 
Posted : 05/05/2007 5:30 am
deckard
(@deckard)
Posts: 77
Trusted Member
 

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.

Bill

 
Posted : 07/05/2007 3:55 pm
 ddow
(@ddow)
Posts: 278
Reputable Member
 

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.

 
Posted : 08/05/2007 7:10 pm
Dawson
(@dawson)
Posts: 16
Active Member
 

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.

-Dawson
www.computer-forensic-resources.com

 
Posted : 18/06/2007 4:10 pm
Page 1 / 2
Share: