Main menu

Post navigation

Guidance Software, Evidence and Software Provenance

So Chris beat me to the mocking of Guidance Software. I was going to do that, and then ask about the software that they produce, and its heavy use in legal proceedings. If your corporate network is full of hackers, what does that say about the admissibility of the output of your software?

There’s also a concept floating around out there in executive suites of “software provenance.” The idea is that you should be able to track and understand who’s checked software in. I don’t know of any software that would really do that effectively.

Let’s assume that there’s some awesome, hard to hack, SDL’d version control software out there with integrated three-factor authentication that logs every check-in to paper and cryptographizes it out the wazoo. It hash-trees, it signs, it timestamps and publishes the good news in the newspaper. Let’s even say that it was installed at Guidance. I should mention that I have no knowledge of what’s happened at Guidance and this is all hypothetical.

Alice the hacker wants to install a backdoor in EnCase that will cause it to not see any file starting with the string “$sys$” and Alice can write code to do that. Let’s next say that Alice pwns Bob the developer’s workstation. She waits until he’s checking in a large set of files, and adds her back door. Bob does the chicken dance with his smartcard, swiptes his fingerprint, and types his 19 character password. And checks in Alice’s code.

I don’t know what it will cost Guidance to ensure its software makes it through the next court case.

4 thoughts on “Guidance Software, Evidence and Software Provenance”

I had the timezone advantage, Adam. :^)
Your point was not lost on Guidance. From their press release, which I linked to:
“Importantly, the settlement also acknowledges that none of the customer data contained on Guidance’s secure,air-gapped,
Professional Services network, was ever compromised or impacted.”
I do not know if that statement is true, because I don’t know what document it refers to. The consent agreement says nothing about any separate network, and the complaint says:
“Respondent also operates a separate computer network that does not connect to the corporate network or the internet and is used only by its Professional Services Division.”
If this statement is what Guidance is referring to, then I humbly disagree — there is no acknowledgment of anything regarding this network other than its existence, the fact that it is not connected to the compromised network or the internet, and that it is used by the PSD. The elements Guidance says are acknowledged — that no customer data was ever impacted or compromised — are not mentioned at all. If there is another document which contains an affirmative statement that this other network was not compromised, I’d like to read it.

And I was mostly thinking about the fact that, when someone somewhere decided to store passwords in the clear (a cost-/effort-saving proposition for the dev team) or any of the other design decisions which aggravated the vulnerabilities in their application, they probably never thought to themselves, “I wonder what sort of regulatory risk this might expose us to?”