The Six Dumbest Ideas in Computer Security

Marcus Ranum’s newest essay entitled The Six Dumbest Ideas in Computer Security makes for an interesting read. Obviously I don’t agree with some of it.

#1) Default Permit – agreed.

#2) Enumerating Badness – agreed.

#3) Penetrate and Patch
Penetrate and Patch is a good idea. It is just abused. It was never meant to replace good design in creating good software (or secure networks). The fact is the designer(s) of an application or a network (or any number of things) might not notice a flaw with it. In fact, in Richard Fenyman’s “Personal Observations on the Reliability of the Space Shuttle” the idea behind penetrate and patch is present (my emphasis):

The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern.
To summarize then, the computer software checking system and attitude is of the highest quality. There appears to be no process of gradually fooling oneself while degrading standards so characteristic of the Solid Rocket Booster or Space Shuttle Main Engine safety systems.

That is how every application should be developed. Unfortunately somewhere along the line we began to tolerate poorly designed, poorly programmed software until it became the norm and well designed, carefully programmed software became the anomaly (software like Qmail). Making reliable, secure software is more expensive and time consuming than making unreliable software destined to be hacked over and over again. Because reliability and security is not required by the customers, software development firms opt to create poorly designed software and adopt low quality software checking systems.
To summarize, the problem isn’t “Penetrate and Patch” it’s the fact that the good design and careful testing that should precede it have been abandoned.

#4) Hacking is Cool
Hacking is cool. This seem to be more about Ranum hating hackers than anything else. He starts by comparing hackers to cockroaches in a weird analogy. No it’s not cool to break into servers and copy credit card info and other stuff. It’s not cool to threaten online businesses with distributed denial of service attacks. But it is cool to brake software and it certainly requires brains. There’s nothing brilliant about typing
./exploit
but going from a segmentation fault because of a few extra characters copied into a buffer to executing any code you want is brilliant. Same for starting with the knowledge of what information goes into log files and what programs will process it to getting those programs to do something you want them to do. And you just got love packet kung fu like inverted syn cookies.
Yes we should learn how to design security systems that are hack-proof but how can we design such systems if we don’t know how they can be hacked? How hacking works? How those systems can fail? How can we say that something is safe if we don’t understand what can go wrong? We can’t. Without a full understanding of the causes of failure, the processes and circumstances that lead to it, we cannot realistically expect to make a system that will not fail. This is closely related to the previous so called “dumb idea” of penetrate and patch.

#5) Educating Users
Overall I tend to agree. You need to not only protect users from whatever may threaten them but also protect the system from the users. And do not underestimate your users resourcefulness and determination to bypass whatever restrictions you attempt to impose. For example, when executables files started being removed from emails based on their extension, users renamed files. When FEUP introduced software to prevent gaming in their computers, users quickly found a way around it simply by using upx.
That said, some user education is probably a good thing – just don’t rely on it.

#6) Action is Better Than Inaction – agreed.

The Minor Dumbs – agreed.

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 3.0 Unported License.

Related posts:

1. How To Keep Your Computer Spyware Free – Basic Windows Security
2. Computer Security Community Rant
3. Look at the pretty Anti-Spyware