Assurance
--Trust me--

Bill Neugent
McLean, Virginia

Background

What assurance do you as a reader have that the information in this paper is reliable and that you can base your actions on it? Well, my advice to you is to behave the same way most system users behave. That is, see whether you like the features in this paper. If you like the features, who cares about assurance? If you don't like the features, who cares about assurance?

That's just the problem we face; users have not been convinced of the value of assurance. They care only about features and are unwilling to weigh the underlying risks. Life offers many examples. While system managers carefully select and procure applications, system users download freeware from the Internet. While parents advise children in appropriate dating partners, children date the same rebels that their parents dated when they were children.

Okay, I'll admit that not all people behave so irresponsibly. Some people are quite prudent and risk averse. You can spot them by their pocket protectors. Nevertheless, there is an unhealthy tendency in our society towards instant gratification and the pursuit of happiness. More calm sobriety and prudence are needed. People need to be protected from their baser instincts and from tradesmen who would shamelessly exploit their naive trust.

This paper provides guidance for those of us who really would like to do the right thing, and also for those of us who don't. After all, even rebels need to know the rules, so they'll know which behavior to avoid. So, how do we judge assurance? Is assurance a good idea that has been carried too far? Or is it a bad idea that has been carried too far?

Definition and Historical Context

But although the Europeans distinguish correctness and effectiveness, it is not clear whether they accept the possibility of being effective without being correct. That is, the ITSEC allows ratings of effectiveness (basic, medium, and high); but, regardless of how you score for effectiveness, it doesn't help you with your evaluation rating, which is based on correctness measures. This is noteworthy, because, within the U.S., the concept of being effective without being correct lies central to our culture. We tend to place higher regard on getting the job done than on getting all the forms and paperwork filled out properly. Furthermore, we even dress sloppier than Europeans and don't expect this to reflect negatively on our abilities. Clearly, there is much we can learn from the Europeans about proper assurance.

Criteria

At a high level, the ultimate objective of assurance is order. Humans are by nature uncivilized, barbaric, and overly fond of salted snacks; we thus need to be inculcated with culture and values lest we fall prey to the excesses of pleasure. In computer security, assurance imposes the culture and values that distinguish civilization from chaos. Assurance finally lays down the law that there is a right way and a wrong way.

The foundation of assurance is built upon the bedrock of criteria, sometimes called rules or mores. Life without criteria would be like a society without laws or a street gang without an enemy gang to oppose. Without criteria, there is no basis for judgment or even communication; there is no right and wrong. And, most importantly, without criteria, there are no jobs for criteria writers.

Professional criteria writers are not mere bureaucrats recruited from Federal regulatory agencies. They do not merely tinker with petty issues. They deal instead with universal truth. They engage the Universe itself in intellectual combat, wresting the secrets of time from the primordial mist and revealing the secrets to us members of the laity. Criteria writers do not develop commercial products, because that would undermine their objectivity.

Ratings

Criteria give us a yardstick that can be used to discipline product developers just as parents use yardsticks to discipline children. Yet criteria do not of themselves tell us what is good or bad, only what are the elements of goodness and badness. To put criteria to use, we need ratings. Some people balk at ratings, but we rate beef, tires, safes, and movies. Why not also computers?

Ratings for assurance are especially interesting because they help us to assess products by assessing the process by which the products were developed. In other words, to assess the product, you have to read a report written about the product by someone who didn't write the product. This provides an objectivity that the product itself cannot. Despite the inherently obvious merit of this approach, some product developers just don't understand it. They naively say, "What are you reading that for? Here's the product. Why don't you just try it out?" How pathetic.

Of course, the ideal product assurance process is one that completely eliminates any need to assess actual products. This can be done by requiring documents such as formal models that are so sophisticated that mere product developers are not even qualified to prepare them. Such documents require the services of security mathematicians, who were beamed into our Universe just for this task from another Universe that runs parallel to ours. It's clearly a very generous Universe, because they told us we could keep these mathematicians as long as we like.

Evaluators

Evaluation Considerations

Jean Girandoux once said, "The secret of success is sincerity. Once you can fake that you've got it made." Well, we assurance gladiators were not born yesterday. We are wise to such tricks. In seeing that assurance requirements are met, we insist that developers promise to play fair. For example, we clarify that it's not fair to try to make it look as though the assurance work has been done without actually doing it.

There are also legal considerations. For example, just as lawyers find legal loopholes in laws, so assurance lawyers will interpret assurance rules to their advantage. The only solution to this is to have our own assurance lawyers contest the interpretations. The resultant quasi-judicial process is in the best tradition of American justice and ensures that disagreements are not resolved prematurely. This might cause some slight increase in product cost, but our assurance lawyers have assured us that it best serves the public interest in the long run.

Some developers think of formal specifications as no different from a bureaucratic requirement to fill out extra forms. They don't understand that every one of those forms serves a valuable purpose. Furthermore, they don't understand the value of logic. That's understandable, of course, since they are only developers. Even Lord Dunsany didn't understand. In 1938, he wrote that "logic, like whiskey, loses its beneficial effect when taken in too large quantities." Since then, Lord Dunsany has died, but logic still exists and continues to outlast its naysayers.

Most users make the mistake of narrowly basing their judgments on personal experiences. For example, if they know and trust product developers, the process the developers follow is less important. If they know and don't trust the developers, no process will convince them that the developers' product is of high quality. So, logically, it follows that they might trust developers they don't know, as long as the developers have name recognition. This is how one knows, for example, that a sprite done by Chagall for a cathedral window is better than an identical sprite done by a grammar-school class for a school window.

There is obvious merit to these judgments, but they also carry subtle dangers. The main danger is that companies with name recognition, who have a track record of developing products that are well liked by users, will become so arrogant in this success that they question the authority of the criteria. They might even come to consider criteria compliance less important than product sales. Such heresy cannot be tolerated. Strong government control is crucial in enforcing use of only those products that play by the rules.

Constant Vigilance

When you go shopping for assurance, do not be fooled by cheap substitutes. As you reach out to take a bottle of assurance from the shelf, your eye might be caught by several imitation assurance products sitting nearby. All of these imitation products are less expensive than assurance and some are very attractively packaged. They are targeted towards different personality types.

Caring people often find themselves settling for reassurance: "There, there; it could have been worse." Macho types inevitably prefer cock-sure-ance: "It won't happen here." The classic example of cock-sure-ance is that of the civil war general: "They couldn't hit an elephant at this dist ..." Even risk averse, prudent people sometimes buy related products. The most popular is insurance. Users must not be fooled by these imitation products but must seek out genuine assurance.

Let us conclude with an example of an assurance substitute that illustrates the need for constant vigilance in defending our assurance Highest-Order Notions Of Rectitude (HONOR). The example shows a particularly pernicious form of imitation assurance. Assurance is usually thought of in terms of a single, benevolent, high-assurance system, smiling protectively down at us. But we assurance advocates are reasonable and acknowledge that nothing is perfect. We heed the wisdom of centuries, which concludes that, "Two heads are better than one," and warns, "Don't put all your eggs into one basket."

Obviously, if you really want to be sure of doing something right, you have to do it twice. Shakespeare subscribed to this belief: "I'll make assurance double sure" (Macbeth, IV c, 1605). It also has been used to explain the practice of polygamy (though true assurance advocates find more security in celibacy). In some cases (e.g., dual exhaust pipes), it is considered a matter of style to have dual systems (though true assurance advocates are mistrustful of style).

With respect to computer security, dual control has long been axiomatic and manifests itself in the principles of separation of duties and two-man control. But this computer security double check has been misinterpreted in some quarters. It is obvious to any reasoning person that the idea behind this double check is to add two high-assurance checks and thereby gain better assurance than from either check alone. However, heretics have twisted the concept to say that two low-assurance checks can substitute for a high-assurance check! They say that 1+1=1.5. We say that 0+0=0. In a sense, they would sell us assurance via features. Oh, foul and heinous treachery! See what temptations await to seduce the unwary.

But let us reaffirm the need for double checks. After all, redundancy and the distribution of control are fundamental to the very construction of our government; it is called the balance of power. Of course, the government interpretation of balance of power is for each side to impede the efforts of the other side, with the effect that government is not as effective and efficient as it might be. But then this does protect us from government excess. Basically, the government structure itself restrains our more extreme impulses. Perhaps that is why some vehicles have governors to keep them from going too fast. In a larger sense, what we are doing here is sacrificing performance for security.

And is this not as it should be? Even if you cannot reason it through, surely you must feel that such sacrifices are needed to purge from our natures the imprudent desires for unharnessed performance and capability? Surely you must sense that the hedonistic pursuit of features feeds primitive hungers that are best kept in check. The Puritans knew the pitfalls of such indulgences and knew also the rewards of abstinence. So must we learn that less is more, that self denial gives birth to self control, and that pain becomes pleasure.

References

Commission of the European Communities, June 1991, Information Technology Security Evaluation Criteria (ITSEC), Provisional Harmonized Criteria, Brussels, Belgium.

NCSC, 21 October 1988, Glossary of Computer Security Terms, Fort Meade, Maryland.

Updated: 20-Oct-2005