The New Ideas

1. Prudent security ensnares only prudes. As we all know, the objective of a lawyer is not to achieve justice but to win. Please forgive me, then, if I ask you to think as a lawyer for a moment. Which of the following two clients would you choose to buy you your next Mercedes?

Client A. Mr. “Well Intentioned but Mediocre Person (WIMP).” This well-meaning soul, due to a sincere attempt to protect the assets with which he is entrusted, sets up a system with seven security safeguards. Being human, however, he fails to properly operate safeguard five. One day, snarf; the assets are gone and we have a clear case of inadequate protection. Mr. WIMP, wracked with remorse, is led away in chains. His wife is invited to appear on Phil Donohue.

Client B. Mr. “Teflon.” This charlatan, due to a total lack of concern, is using only three security safeguards to protect assets similar to those of Mr. WIMP. One day the same ploy eliminates his assets. “Hey,” he says. “What was I supposed to do? We had three safeguards on those assets and that’s all we’ve needed up until now. There’s no industry standard that says we needed safeguard five. Besides, I’ll bet I can find you places that use only two safeguards. We thought we were safe. Sure we know better now and we’ll use safeguard five in the future, but we honestly didn’t think we needed it. If we tried to defend against every single possible attack, security would grind our system to a halt. You can’t always be looking over everyone’s shoulder. Maybe our problem was just that we trusted our people a little too much. I guess we were wrong in that but, darn it, they’re good, decent people and I just wasn’t brought up to treat people like criminals. These people work hard for a living. Sure you get a bad apple sometimes, but darn it [insert listener’s first name], these people are like family to me.”

The only conclusion possible from this example is that security safeguards are legal vulnerabilities. When you establish a set of safeguards, you’ve acknowledged their necessity. The more extensive the safeguards, the more difficult it is for you to live up to your own standards. Life is simple. Why complicate it? Incidentally, Mr. Teflon has gone on to public office.

2. Multilevel security is not on the level. About 10 or 15 years ago the most remarkable and subtle denial of service attack in computer security history was quietly perpetrated. It occurred when The Commies, acting through a mole, suggested that multilevel security could be achieved through the use of security kernels and other arcane techniques. Since then, countless research dollars and numerous young intellectual warriors have been diverted down a technological cul de sac in search of the Holy Grail of computer security. Today, as the products of their labors accumulate in technological waste dumps and despoil the landscape, the chimera remains just out of reach.

“Not so,” the warriors would claim. “Don’t you know a Holy Grail when you see one? We have succeeded in developing multilevel secure (MLS) hosts.”

And there is truth in what they say. After many years of development and many failures, we do have simple MLS hosts. Unfortunately, nowadays people use intelligent workstations (which are not MLS) to talk to hosts. Therefore MLS hosts alone are no longer sufficient for MLS in many systems. Furthermore, since (l) objects such as files and messages remain single level and (2) there are restrictions on extracting lower-level data from single-level objects, use of MLS hosts can be awkward:

So our difficulty now is to find a problem that fits the solution.

Why is it that multilevel security is so difficult to achieve? The basic reason is organic--if you plant a kernel in fertile turf, it’s bound to grow. Most kernels have suffered no shortage of fertilizer. Another reason is that there are natural limits to simplicity, especially when one is doing something inherently complex². Even when it’s possible to build an MLS system, it usually in most customers’ eyes falls victim to the familiar “Let’s-take-’er-for-a-spin-and-see-what-this-baby’ll-do” syndrome. Security in a system, like reliability in humans, is typically not viewed as sufficient reason to excuse nerdy behavior.

My biggest problem with this situation is not the resultant delays and failures of military procurements. Without security technology as a pitfall, they would surely have found other equally effective stumbling blocks. Rather, I’m convinced that if so much young talent had not been so successfully diverted, we might have had Zork (the adventure game) five years earlier. On the other hand, is it possible that Zork itself is another successful denial of service attack?

3. Privacy advocates have something to hide. During Mr. Teflon’s election campaign, a problem arose over use of his campaign funds. He salvaged his campaign through brilliant use of candor. He did not deny the infraction. Instead he tapped a remarkable wellspring of public sentiment:

4. Formal specifications are overdressed. My opinion about formal specification and verification derives from personal experience. I had the lowly responsibility of formulating security test ideas for a system. I say lowly because the system in question was so rich and fortunate that it was being ministered to by an entire troupe of specialists in formal specification and verification. To me it was a tremendous honor simply to be associated with a system that had been touched by such remarkable illuminati. I didn’t understand anything they said, but that didn’t matter--I was face to face with the future and it was a heady experience.

A crew of people from still another independent organization was assigned to analyze the implementation against the FTLS. By the time the system was finally completed, this crew had spent at east ten man years doing their analysis. They had found quite a number of implementation errors and internal inconsistencies, although none that could actually be exploited by a user at a terminal. Nevertheless, because of the number of internal flaws, their conclusion was that they had “no confidence” in the system and that it should not be approved.

I shared their lack of confidence, but for a different reason. Once the developers finally got around to building the user interface, I was called in to make up security test ideas. In four months, with help from several colleagues, I had a stack of outrageous things to try. On trying them, I was astonished to discover a significant number of ways that users at terminals could romp all over that system. This came as quite a surprise to everyone, especially the program manager, who kept shaking his head and saying “But it’s been proven.”

Now don’t get me wrong. I’m not saying that this one example absolutely proves formal specification and verification to be ineffective. Obviously for that I’d need either (l) an FTLS and 20 man years of coverage or (2) at least three beers worth of analysis.

5. Confinement channels needn’t be covert up. A few years ago we’d never heard of them. Now every system manager has the recurring nightmare of having his system in for a regular checkup and hearing:

People used to think that the main threats to systems were from people. That’s true, of course, but it’s also mundane, especially since most of the culprits are just dumb old data entry people. Now, however, into the murky annals of villainy rides a new and finally a worthy foe--the confinement channel. Now the threat is no longer a witless clerk but an invisible ghost hidden in the software itself. No, no, not in the source code, you dummy. Only in the running object code, and even then hidden behind some branches. This uncanny ghost uses sophisticated signaling techniques to communicate with other ghosts and thereby to sneak secrets out of the system, a drop at a time. Incredible.

Let me illustrate. Let’s say you and a friend are locked in adjoining rooms and need to talk. You can’t shout, because the guards would hear. You lie in bed, staring at the pipe running up the shared wall. Suddenly you remember your Morse Code merit badge, and the bed squeaks as you leap to your feet in inspiration. You then realize that by jumping on the squeaky bed, you can effectively send dashes and dots to your colleague. That’s all there is to it. Simple (except maybe for sneaking the bed into the computer). But--and here’s the neat part--in a computer system these things are totally impossible to eliminate. That’s the mission, Mr. Quixote.

Now it is true that there has never been a single case of a confinement channel being used as a subtle signaling device to modulate a resource and thereby to leak secrets. But that doesn’t mean there won’t be such a case one day. That doesn’t mean we can afford to relax our guard. Some day perhaps there’ll be a criminal who tires of breaking into systems by the 10,000 traditional faster, easier, cheaper, and less risky ways; who desires something more classy. Sure, his boss would laugh him out of the organization, but let’s say he’s got his own little start-up criminal firm. He might just possibly be able to do it. That’s the point. It is possible. Right?

So, like any conscientious system manager, you’re willing to put out some bucks and even sacrifice some system performance to defend against these pesky rascals. Right? Right? Hello?

6. ALE (Annual Loss Estimate) blurs the perception. Some of my former colleagues used to do quantitative risk assessments for clients. Their technical approach was so complicated they had to call it a methodology rather than just a method. It works like this:

7. The Jones family (next door) just bought a Ferrari with THEIR computer crime profits. In Russian roulette, there is a 5/6 chance that you will get nothing and a 1/6 chance that you will die. People play the game. In computer crime, there is a 9,999/10,000 chance that you will steal $500,000 and a 1/10,000 chance that you will go to jail for three months and then (unless prevented by ethical qualms) become a security consultant. System managers claim that their people would not play this game. Sure, you might quibble about the precise numbers, but everyone knows the average computer heist nets 500 G’s, and I won’t demean such a revered figure with anything so banal as a reference.

Perhaps you think that most people--even yourself--are above crime. I once conducted an ethics survey and the findings showed that all people willfully violate their own ethical standards in some areas. (Well, everyone but one holier-than-thou sourpuss who was probably lying anyway.) These findings convinced me that people are basically dishonest, but that they are honest about their dishonesty. Unfortunately, I found it difficult to proceed from this finding, except to note one practical application: as long as one is vague about the charge, one can safely accuse anyone.

If this revelation about ethics causes you to wonder whether your assets are covered, have faith. Whatever else might happen, still your corporate assets (if they are worth anything) are protected by that trusted pillar of our society, the $8,000/year night watchman.

“So,” you say, “OK, computer crime is great, but how do I get my fair share? I don’t know anything about breaking into computers.”

For our pioneering forefathers of crime, this was a problem. Now, fortunately, numerous benefactors have stepped in to fill this information void.(4,5) Those who tire of computer crime and prefer to move on to the glory of operation on a national or international plane have not been forgotten. (6)

One final word. To date, computer crime has been mainly a gentleman’s sport, along with fox hunting and sexual intimidation. This has some benefits, in that it’s satisfying to meet with other gentlemen in the Explorers’ Club to discuss your exploits over a Brandy. On the other hand, some people are beginning to miss women in the profession. For one thing, today’s perps (i.e., perpetrators) are becoming sloppy. There are reports of accidental destruction of files. Many feel a woman’s touch is needed to clean up after this sloppiness (and, for that matter, to teach the perps a thing or two about personal hygiene). For another thing, if you’re mukkus enough to be the 1/10,000, it would be nice to have some decent sympathy.

CONCLUSION

Perhaps it will surprise you, but many people in our profession will not agree with these opinions. Some might resent the threat posed by the ideas’ irrefutable clarity (i.e., clear to the point of transparency). Some might resent the humor, but then they’d probably resent humor even in an undertaker.

Regardless, I think it’s clear that, taken together, these opinions shake the foundations of today’s computer security infrastructure. (If you’re not wearing a hard hat, perhaps you’ve acquired a bump or two yourself.) Furthermore, I throw down the gauntlet to my computer security colleagues and double-dare everyone to try to refute these opinions. That will not be an easy task, because you can only refute something that is based on logic. The strength of my arguments is that they have no logical foundation whatsoever. Rather, they are based only on feelings, hearsay, and personal experience, and sometimes not even on those things. Naturally, I prefer to think of it as common sense. Perhaps you have your own name for it.

FOOTNOTES

1 Should someone employ this approach with you, you might be tempted to reason with the person. Why bother? It’s more satisfying instead to take advantage of the substantial guidance that exists on how to Get Even.(1,2.3)

2 You should only worry if your company hires for this position an intelligent,. thorough person who has a knowing twinkle in his eye.

REFERENCES

1. Hayduke, George, Get Even: The Complete Book of Dirty Tricks, Paladin Press, 1980.

2. Wilson, Nolan, Electronic Harassment, Desert Publications, 1981.

3. Chunder, H. Nelson, I Hate You! An Angry Man’s Guide to Revenge, Paladin Press, 1983.

4. Cornwall, Hugo, The Hackers Handbook, Century Communications, 1985.

5. Harry, M., The Computer Underground, Loompanics Unlimited, 1985.

6. Santoro, Victor, The Rip-Off Book, Loompanics Unlimited, 1984.

ACM COPYRIGHT NOTICE. Copyright © 1986 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or permissions@acm.org. This copy is posted by permission of ACM and may not be redistributed.

Updated: 20-Oct-2005