Welcome back to the Windows Forensic Path. In Course 11, we're talking about creating a forensic disk image. In this module, Module 2, we're going to talk about validating our forensic tools. Validation is important because we want to ensure the accuracy of our findings and conclusions. If we haven't validated the tools we're using, how can we say with certainty that they're working properly? We want to be aware of any software issues, so we need to test and validate to make sure that your tools are working and you do not have any software issues. We want to avoid our findings being called into question. If we haven't tested and validated, it leaves a big hole for somebody to attack us on the validity of our findings. What should be validated? Well, definitely you want to validate your hardware write blockers, and you want to make sure they're working. You want to validate your software write blockers, I would do this at each use. You want to make sure you validate your imaging software, the software we're going to use to make the image just to ensure that it is working correctly, and you want to also validate your examination software, the software you're going to use to conduct your examination. When we're validating our hardware write blockers, you want to use a designated drive. You want to have a designated test drive in your lab that you use to validate your hardware write blockers. You never validate on the original evidence. You want to know the hash value of the drive that you are using, the designated drive you're using. It is good to use a small drive because it makes it faster to do the validation. Validate at least monthly or whatever your operation requires. Keep the firmware updated. Hardware write blockers have internal firmware, and you want to make sure that your firmware is up-to-date. You never want to be embarrassed finding out that you're write blocker failed because you as the investigator failed to update your firmware. The validation process for a hardware write blocker is you'll connect your designated test drive to the write blocker, you will conduct a hash value of the test drive. Once you've conducted the hash value, you'll attempt to write to the drive. Then you will rehash the test drive and the hash value should match. Now, while you're going through this process, you want to be documenting. You want to be writing your steps down, you want to take screenshots of your write attempts to show that you have attempted to write to the drive and that you were not able to, and you want to record your beginning hash value, the one you do before you attempt to write to the drive, and the hash value you do after you've attempted to write to the drive. You want to record all this, you want to keep it in a file somewhere in your lab, and like I said, you want to do it at least monthly or whatever your agency requires. Validating your software write blockers. Now, software write blockers are used mainly on removable media at this point in time. Or you're going to use them on a hard drive that cannot be removed, like when we talked about booting into a Linux distro or a Windows FE distro. You're going to use these when the hardware option is not available. If you have a hardware options available, always use it over the software option, and make sure that you keep your software write blockers updated. Software write blockers also use a designated drive. Again, have a designated USB device because you're mainly going to use these things on removable media at this point in time, know the hash value of that drive, use a small drive, and validate it before each use. The process would be the same as it was with your hardware write blocker. You would initiate the software write blocker and make sure it's turned on, plug in the USB device, hash the USB device, attempt to write to it, and then rehash the device and make sure those hash values match. It doesn't take very long to do, and I highly recommend doing it before each use. When you do it, you're going to do it on your test drive, never ever validate on original evidence. We're going to activate the software write blocker, we're going to connect the test drive to our examination computer. We're going to hash the test drive, we're going to attempt to write to the test drive, and rehash the test drive. That is the validation process. Our hash values should be the same, and again, make sure you document the results and the actions that you took when you attempted to write throughout this process. You should also keep these validations somewhere in your lab so that you can show documentation if it's ever called into question. Now, your imaging software. One thing you want to make sure about your imaging software is you want to make sure it is imaging the entire physical disk if you're imaging a physical drive. Make sure you're getting the entire drive. When you validate again, use a test drive with a known size and known hash values. The hashes should match; the hash of the test drive, should match the hash of the image, and when you rehash the test drive, that hash value should also match. Use a small drive because it makes the process much quicker. Keep your software updated, your imaging software. You should not be using outdated versions. Validate as required by your agency policy. If you do not have a policy, again, I would recommend doing it in disk once a month. Again, you need to document the results of a validation. Our examination software. Read through these notes on your evaluation software so you know if there are any known bugs. Be aware of these known issues. Always update your examination software to the latest stable version. The process is similar. We're going to use a designated validation drive. Your lab should have a drive that they use to validate the software you're examining your evidence with. The drive should have known results. It should have known hash values, and it also should have known files on it. You want to cover all the major functions of your software. Whatever examination software you're using, when you do your validation, that should include all the major functions of that particular piece of software. If you're looking for a lot of image files, for example, part of your validation should be recovering image files. Cover the common areas of your examinations. Follow your agency policy, and document the results of your validation. If you're somewhere that does not have a policy, I would do a validation with each full-number upgrade of the software. If you go from version 4.1 to version 5.1, when that 4 becomes a 5 is when you need to validate. What validation does for us is it allows us to be confident in the accuracy of our findings and conclusions. Because if we didn't test our examination software, how can we be confident with the findings that we're seeing when our dates and times with the files recovery, the locations that software is telling us these files came from? You definitely need to validate your examination software. We also want to adhere to scientific principle We talked about scientific principles at the beginning of this path. This also helps us head off our findings being called into question. In our next module, we're going to take a close look at our write blockers and talk about how they function.
