The Lessons of the Worm

It's hard to have a computer program shut down 60 thousand computers across the country, including those at research and military installations, without having a few people figuring out that something has to be very wrong with the status quo. The 1988 Worm proved to be no exception.
The worm pointed out a number of glaring security holes in UNIX networks which would probably have gone unknown, or at least been ignored as not very significant, had not the worm been so graphic in its exploitation of such "little" bugs. There are even those who suggest thanking Morris for his actions as they provided a serious wake up call to system administrators around the country. Of course, other people have pointed out that there might have been other ways of delivering the same message.
Before late 1988, computer security was not a major concern of internet community, at least, not to the degree it was after November 2. There were a number of other bugs that the worm did not exploit, but which were discovered during a close reinspection of operating systems and (hopefully) patched up.
In addition to trying to find all the security holes in a system, several other discoveries were made, thanks to the worm:

• First, access to certain files should be only granted to those who need said access. One of the Worm's attacks too advantage of the fact that the file containing the encrypted passwords of all the users was publicly readable in most systems. This mean that the Worm could compare various encryptions of possible passwords against the encrypted passwords in this file without triggering security warnings, which would occur if a large number of incorrect login attempts were detected. In addition, the file was almost always in the same place on systems, making the Worm's job much easier. Fortunately, most computer networks have corrected this oversight.
• Many networks found that having a variety of different computers running on their network was an advantage. This is because it is highly unlikely that an infection on one machine will be able to run on a large number of different machines. Therefore, those networks with the greatest diversity have a lesser chance of being completely incapacitate by such an attack. (Of course, this limits software compatibility within a network, but we are concentrating on security right now and will ignore this.)
• Another lesson that was learned from the Worm that is a slightly less technical nature is that the sharing of research on something such as the worm (as MIT and Berkeley did in their attempts to decompile the program) is immensely helpful. Such a network of computer geeks and gurus ended up being the vanguard of the assault on the worm.
• In another issue, network security was shown to be incapable of defending from such attacks. Instead of concentrating on this area, many believe that the only real way to keep security tight is to have the defenses at the host, or computer, level.
• Beware of reflex reactions to computer problems. When system administrators discovered that the Worm was using sendmail to penetrate their systems, many of the responded by shutting down their mail server. This proved to be a cure that was worse than the disease. The worm had a number of other attack methods, and so was not really hampered by the loss of the mail utility. The only real result of the loss of the mail systems was the fact that mail describing how to defeat the worm and fix the bugs was delayed in reaching some sites.
• Logging information is vital in discovering the source of infections such as the Worm. Many sites were hampered by the fact that they couldn't tell where the worm was coming from and how it was entering the system. (Of course, 99% of the time, most log information is unused, and as a number of applications require logs of their own, this can cause quite a pile of usually useless information. Once again, it is a trade-off.)

In conclusion, the Worm made the internet community better prepared to handle and repel another such attack. However, the fact is that security is often a trade off with convenience, and for most day-to-day users, convenience ranks pretty highly. UNIX itself was never designed with security as its highest priority, but designed for ease of use. Thus, as long as security and ease of use are competing factions, the temptation will be to overlook security holes that would hamper legitimate users, thus leaving the door open for the next worm.