Validating write blockers

In the Recommended forensic hardware thread in the Hardware forum I recently wrote the following about a hardware write blocker I'd just come across which I hadn't seen before:

I think this brings up the interesting question of how we (as practitioners) test the write blocking capability of new devices both to satisfy ourselves that they work as advertised and to be able to show that in court.

For the sake of argument, let's imagine that we *need* to use one of these IOI products (if we want to be specific we'll say it's the FW2ATA525-MR1-WP already mentioned) but it's not a device you've used or tested before, it hasn't been used in a court case in your area and you have only the manufacturer's word that it works properly. What methodology are you going to employ to test it in some formal sense?

In practice, I suspect most of us use write blockers which are seen as industry standards and have already gone through some form of validation procedure. Typical choices would be Guidance Software's FastBloc devices or something from the Tableau product line, both examples of items from well respected specialist companies. Not only have these devices presumably undergone extensive testing by manufacturers concerned to protect their reputation as industry leaders but we also have the results of independent testing to refer to, perhaps the best well known being the NIST hardware write block testing program.

What of new devices from relatively unknown manufacturers though? How do we reassure ourselves and the courts that they work as advertised? The obvious answer is that we test them ourselves but how exactly do we do that, what methodology do we use?

In theory, write blocking is easy to understand: we want to prevent any alterations to the attached evidence device while allowing all data to be retrieved. In practice the situation is more complex, there are many different commands which can be sent to a storage device from a variety of different components in a host computer (BIOS, OS, application software, etc.) and we need to satisfy ourselves that a write blocking device operates as expected (preventing alteration/allowing retrieval) under all circumstances. Similarly, testing methodologies can be either straightforward or complex. For example, compare the validation methodology suggested in the Helix manual:

This process is based on the National Center for Forensic Science (NCFS) 5 step validation process for testing write protection devices (Erickson, 2004). It was originally designed to test the Windows XP SP2 USB software write blocker, but has been adapted to test any hardware and/or software write blockers.

Step #1 – Prepare the media

a) Attach the storage media you will be testing with to your forensic workstation
in write-enabled mode.
b) Wipe the media - validate that this has been successful.
c) Format the media with a file format of your choosing.
d) Copy an amount of data to the media.
e) Delete a selection of this data from the media.
f) On the desktop of your forensic workstation create 3 folders. Call these Step-1, Step-2 and Step-5.
g) Image the media into the Step-1 folder and note the MD5 hash.

Step #2 – Testing the media

a) Remove and then replace the testing media into your forensic workstation.
b) Copy some data to the media.
c) Deleted a selection of this data from the media.
d) Image the media into the Step-2 folder and note the MD5 hash.
e) Validate that this hash value is ''different'' to that produced in Step #1.

Step #3 – Activate the write blocking device

a) Remove the media from your forensic workstation.
b) Attach and/or activate the write protection device.
c) Follow any specific activation procedures for the specific blocker.

Step #4 – Test the write blocking device

a) Insert the media into your forensic workstation.
b) Attempt to copy files onto the media.
c) Attempt to delete files from the media.
d) Attempt to format the media.

Step #5 – Check for any changes to the media

a) Image the media into the Step-3 folder and note the MD5 hash.
b) Validate that this MD5 hash is the ''same'' as the MD5 hash from Step #2.

with the methodology outlined by NIST in their test plan available at http://www.cftt.nist.gov/hardware_write_block.htm.

If you're thinking the easy way round this is just to avoid the issue and buy one of the well known write blockers instead, the bad news is that testing your device (regardless of manufacturer) is almost certainly something you should be doing anyway. There's a good thread here in the forums discussing when and why write blockers should be tested.

Of course, we need to see validation within the wider context of the entire forensic process which involves, potentially at least, presenting evidence in court. As a result, there may be certain testing methodologies which are already specified or recommended wherever we find ourselves working.

I think I'm going to dig a little further into this and see what various agencies have to say. I'll report back when I have some news but in the meantime any thoughts or comments would be very welcome. How would you validate a new write blocker? Do you regularly test your existing device? How reliable are hardware write blockers (have you had one fail on you)? Let me know.