The absence of network security
By Scott Bradner
Network World, 08/02/99
"There is no such thing as a secure computer network."
The New York Times said that a week ago and if The Times said something, it must be true. But do protocol and applications developers understand the implications of this?
Almost by definition, computer networks cannot be, in themselves, secure. The aim of computer networks is to facilitate access to computer-based resources. In order to do so, they transport information from one place to another, generally with a user or two somewhere along the line.
Users are a problem in the security world. They forget things like passwords. They get frustrated at the imposition of complex security procedures and circumvent these procedures to make their lives easier. They loan their accounts to friends. And many users think they are underpaid, overworked or underappreciated - as a result, these users are potentially corruptible.
It sure would be a lot easier, securitywise, without users.
Anything you do to make users' lives easier has security implications. For example, if you allow a remote user to access corporate servers, you have to open a door that other remote people may be able to exploit. If you run an e-mail system that can transfer programs or macro-filled documents, you are opening a barn door.
But it turns out that a major problem is the attitude of protocol and applications designers.
In the IETF, we now insist that all working groups keep security in mind as they design protocols. But even in the IETF, security is often reluctantly added at the end rather than designed in from the beginning. I say reluctantly because when I ask why a working group has not yet considered security, I keep getting the response "my customers are not asking for security." It has sometimes been quite a fight to get working groups to seriously worry about the issue.
If it's this hard to get secure protocols within an organization that has made security a specific goal, it seems to be almost impossible in commercial applications development organizations. Features are added to programs seemingly without any thought of the security implications.
This is not going to be easy to fix. Security is hard. Some of the people who would exploit security holes are very smart (if more than a bit immoral). They will find any small chink in the armor - and unless the developer is a real security expert, it is hard to see a chink when programming one in. The problem is made harder because of the easy-to-run exploitation scripts that get widely distributed.
Companies must get security expertise into their software development groups and users must use the resulting security tools. Otherwise, the Internet bubble may burst in a very ugly way.
Disclaimer: Harvard has seen many bubbles come and go, but the above worry about this bubble is mine.