On Validation

I’ve struggled with the concept of “validation” for some time; not the concept in general, but as it applies specifically to SOC and DFIR analysis. I’ve got a background that includes technical troubleshooting, so “validation” of findings, or the idea of “do you know what you know, or are you just guessing”, has been part of my thought processes going back for about…wow…40 years.

Here’s an example…when setting up communications during Team Spirit ’91 (military exercises in South Korea), my unit had a TA-938 “hot line” with another unit. This is exactly what it sounds like…it was a directly line to that other unit, and if one end was picked up, the other end would automatically ring. Yes, a “Bat phone”. Just like that. Late one evening, I was in the “SOC” (our tent with all of the communications equipment) and we got a call that the hot line wasn’t working. We checked connections, checked and replaced the batteries in the phone (the TA-938 phones took 2 D cell batteries, both facing the same direction), etc. There were assumptions and accusations thrown about as to why the phone wasn’t working, as my team and I worked through the troubleshooting process. We didn’t work on assumption; instead, we checked, rechecked, and validated everything. In the end, we found nothing wrong with the equipment on our end; however, the following day, we did find out what the issue was – at the other end, there was only one Marine in the tent, and that person had left the tent for a smoke break during the time of the attempted calls.

We could have just said, “oh, it’s the batteries…”, and replaced them…and we’d have the same issue all over again. Or, we could have just stated, “…the equipment on the other end

[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.