On this page Beizer recommends modeling "High-level control functions within an operating system. Transitions between user states, supervisor's states, and so on. Security handling of records, permission for read/write/modify privileges, priority interrupt and transitions between interrupt states and levels, recovery issues and the safety state of records and/or processes with respect to recording recovery data." So he's still talking about the operating system.
But that's not the only place he talks security. On page 17 in the chapter "The Taxonomy of Bugs", he notes that "Gratuitious enhancements [in functionality] can, if they increase the system's complexity, accumulate into a fertile compost heap that breeds future bugs, and they can burrow holes that can be converted into system security breaches."
Chapter 7, Data Validation and Syntax Testing, is devoted to the hazards of failure to sanitize inputs. He opens with:
I think one of the worst cop-outs ever invented by the computer industry is "garbage-in equals garbage-out". We know when to use that one! When a program of ours screws up in a nasty way. People are inconvenienced by the host of subsidiary problems that result. A big investigation is launched and it's discovered that an operator made a mistake, an improper tape was mounted, or the source data was inconsistent, or something like that. That's the time to put on the Guru's mantle, shake your head from side to side, disclaim all guilt, and mutter, "What do you expect? Garbage-in equals garbage-out."
Do we have the right to say that to the families of passengers on an airliner that crashes? Will you offer that explanation for the failure of the intensive care unit's monitor system? How about a nuclear reactor meltdown, a supertanker run aground, or a war? GIGO is no explanation for anything except our failure to install good data-validation checks, or worse, our failure to test the system's tolerance for bad data. The point is that garbage shouldn't get in at all -- not in the first place or in the last place. Every system must contend with a bewildering array of internal and external garbage, and if you don't think the world is hostile, how do you plan to cope with alpha particles?
Of course input validation is fundamental today. But Beizer is not finished predicting the future:
There are a few malicious users in every population -- infuriating people, professional Blue Meanies who delight in doing strange things to the systems they use. Years ago they'd pound the sides of vending machines for free sodas. Their sons and daughters invented the blue-box used to get free long-distance and international telephone calls. Now they're tired of probing the nuances of their home video games and they're out to attack computers. They're out to get you. Some of them are even programmers. The are persistent and systematic. A few hours of attack by one of them is worse than years of ordinary use and bugs found by chance. And there are so many of them; so many of them and so few of us.
Then there is crime. It's estimated that computer criminals (using mostly hokey inputs) are raking in hundreds of millions of dollars annually. Some criminals could be doing it from a telephone booth in Arkansas with an acoustic coupled programmable calculator. Every piece of bad data unknowingly accepted by a system, every crash-causing input sequence, is a chink in the system's armor that knowledgeable criminals can use to penetrate, corrupt and eventually suborn the system to their own purposes. And don't think the system's too complicated for them. They have your listings, and your documentation, and the data dictionary, and whatever else they need. There aren't many of them, but they are smart, highly motivated, and possibly organized.
Beizer was an interesting and challenging individual by many accounts. His writing style makes the material more entertaining than the title suggests.
No comments:
Post a Comment