I was a young Air Force lieutenant when Ken Thompson released his 1984 piece, Reflections on Trusting Trust. Assigned to a data center in the Pentagon, I was working on the B2 evaluation of Honeywell Multics with the fine folks at the National Computer Security Center and contributing some words to the growing Rainbow Series books. We were in ongoing debates over the meaning of phrases such as “top-level specification” and “on behalf of” in the Orange Book (a mail thread that went on for several years) and trying to perpetuate the wave of talking about “trusted computers” instead of “secure computers.”

We talked a lot about “how much trust do I get for how much analysis and testing” and “how much trust do I need for certain scenarios, like allowing a computer to automatically downgrade data from Top Secret to Secret.” These kinds of concepts ended up in capability maturity models, testing models, and risk models.

I took Ken’s words to heart and quickly made up my mind that we could really only move the trust bar up slightly (like from 10% to 20%), even with enormous expense. It was immediately obvious that getting up to, say, 75% would require so much calendar time that no one would wait for the result (and I think later experience with Orange Book evaluations, Common Criteria evaluations, and related programs have borne this out). Between hardware, software, firmware—and the completely unpredictable human factors—we really had no idea how even the most reviewed code would operate in relatively controlled environments (e.g., in a government facility where everyone was cleared), much less how it would operate in a hostile environment (hostile mobile code was not really a problem yet) where people might actively be up to nefarious deeds.

Why should you care about my reminiscing? Well, because I think a flavor of trust is still a major problem today and it’s costing everyone a bunch of money that could be put into real long-term solutions.

As I talk with my operations friends these days, I’m seeing a subtle shift in their thinking. They’re thinking more and more about appliances (web application firewalls, IDS and stuff like that), but not for direct security value. They seem to be thinking that since the software they install, whether purchased or built internally, will certainly have security problems, they have to install more bells and whistles so that operations can protect itself. This is beyond healthy paranoia; it’s an unhealthy distrust of people who should be active partners, even if it’s been earned by years of spectacular failures.

Then I started wondering why so many development organizations throw out requirements documents from product managers and just start over. Is it only because the requirements are so bad, or is it also because the developers just don’t trust the managers to know what they’re talking about?

And why do so many managers try to tell development organization how to create applications, instead of simply what the creation must accomplish? Do they simply not trust the developers to be aware of business objectives, or do they just not understand the creative processes involved?

And so on.

What an enormous amount of wasted cycles that could be used to greater organizational good.

We may never get to the point where we can implicitly trust software. But, can’t we at get to the point where we can trust each other?

Technorati Tags: software security, software quality

This entry was posted by Sammy Migues on Monday, March 5th, 2007 and is filed under Software Quality, Assurance, General Interest. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.