The difficulty of keeping individual machines secured at this pace leads many organizations to invest heavily in firewalls, in hopes that at least external attacks can be mitigated. The global Internet ensures that attacks are as likely to come from China or Brazil as from the next cubicle over. External attackers, unfortunately, are almost entirely unaccountable for their actions, and most organizations are deeply averse to lack of accountability. There are other legitimate reasons for firewalls and demilitarized zones: usage monitoring, for instance. Even so, wouldn't the need for perimeter network defenses be diminished if each computer were its own firewall? And how difficult is that?

In many cases, it all comes down to ports. Let's take a look at the flaws in default OS configuration

A Network Security Primer
Network attacks occur, appropriately enough, through a system's network interface, distinguishing them from attacks by authorized local users or breaches in physical security. TCP over IP is the most commonly abused network protocol pair, so some understanding of how TCP/IP works is essential to our security plan.

TCP/IP traffic uses ports. By design, there are 65,536 possible TCP/IP ports. Communication can occur on any "open" ports. By implication, so can attacks. "Open" ports are associated with applications or processes. Such processes are said to be "listening," and will interpret and respond to traffic addressed to particular ports. Ports with no associated processes are closed. The Internet Engineering Task Force (IETF) allocates certain ports for certain uses. For instance, HTTP uses port 80, meaning that a Web server in conformance with IETF expectations will respond to network traffic addressed to port 80, and ignore traffic for other ports.

Most vulnerabilities arise when a listening process is faulty in some way, thereby opening an avenue of attack. Faulty programming can allow a remote user to slow or kill the process or system itself (called a denial-of-service attack), execute arbitrary commands like "rm" or "delete," or upload files to ostensibly protected locations.

As a general rule, then, one of the first steps in securing any networked computer is reducing the number of listening ports. According to the SANS Institute's www.incidents.org Web site, these were the most frequently attacked ports, in decreasing order of frequency, for the week of May 6:

Let's compare the above to a list of open ports on a freshly installed Solaris machine. These are the defaults (obtained from the output of the command "netstat a"). Some of the port numbers have been converted to their respective process names. In the interest of brevity, this is not a complete list:

Some of the listed ports (FTP, telnet) correspond to the CERT list, but many more additional ports are open. Even if there aren't known vulnerabilities associated with all of these applications, this list should make the administrator in you nervous. As a general rule of thumb, services not offered cannot be hacked, yet by default, Solaris offers everything. Securing this machine will require knowledge and time, both often in short supply.

Systems Perilous
Unfortunately, Solaris 8 is not unique. Many vendors distribute operating systems with lax default security. Bruce Schneier, author of the seminal "Applied Cryptography" and the more business-oriented "Secrets and Lies: Digital Security in a Networked World," calls this "default to insecure" engineering, and argues that this "cavalier approach to security is pervasive" (Secrets and Lies, p. 370-71). Computer security experts recommend the exact opposite: Systems should default to a secure state, and ports should be opened manually, as necessary to provide services.

Compounding the problem, there are serious doubts as to whether today's networks can be secured at all, without wholesale migration to newer protocols like IPv6 that were designed with security in mind. In a famous 1989 paper, Steven Bellovin of AT&T Laboratories outlined several security problems in the TCP/IP protocol suite itselfnot with a particular operating system or application, but with the state of being on a TCP/IP network. Twelve years later, many operating systems still ship with these security holes enabled by default. The hacked systems that inevitably result are generally attributed to "user misconfiguration."

Let's derive some general propositions:

1. No computer is entirely secure.
2. Some computers are more secure than others.
3. Computers left in their default configurations are among the least secure.

If we accept these propositions, do we accept that "user misconfiguration" is to blame, or do we reproach vendors for lackadaisical security?

Pliable Liability
If the American motor vehicle industry has taught us anything, it's that unless a product spontaneously combusts, vendors are rarely held liable, especially when the damage is to consumers rather than businesses. Bad software, however, seems to impact businesses and consumers alike. Estimates of damages from faulty software -- e-mail viruses transmitted via Microsoft's Outlook mail client, for instance -- range in the billions of dollars. Putting aside the question of the "reality" of such damages, it seems unusual that there is little concerted response from the business world to an apparently serious loss in productivity.

In truth, there can't be a concerted response, because nobody does it better (and not in the sense Carly Simon meant). All software publishers publish bugs. It's in the best interest of the industry as a whole to promote liability-limiting legislation like the Uniform Computer Information Transactions Act (UCITA), which essentially negates liability for bad software, provided click-through licenses are used or defects stated in small print. In reality, of course, such licenses are rarely read, especially if they're still inside the shrinkwrap. Penalizing software publishers in proportion to damages would only help to nullify the UCITA and similar measures.

Public activism, in the form of full-disclosure mailing lists and Web sites like BugTraq, has made great strides in the quest to make vendors carry the weight of their more egregious sins. Despite my sympathy for digital vigilantism, even I'll admit that software is not a perfect art. Legitimate bugs escape notice even in heavily audited code. Even the many-eyes approach of the Open Source model is no guarantee of bug-free software. A measure of risk is always implicit in the contract between consumer and producer, and some measure of protection from bug-induced liability is necessary to ensure that the industry continues to produce software at all.

Default to Insecure
But to my mind, bugs aren't the issue here. "Until companies have some legal incentives to produce secure products, they won't bother" (Secrets and Lies, p. 366). Schneier focuses on the expensive and distasteful process of diagnosis, coding and regression testing that fixing bugs requires. Yet we should be careful to differentiate between true bugs and simple failure to abide by the most mundane security prescriptions, such as pruning unnecessary listening ports. The "default to insecure" ethos that would qualify as criminal negligence in other industries is accepted wisdom in the computer industry. If cars featured locks that could be opened remotely by random users, and then told to go about opening neighboring cars as well, one suspects that the car manufacturer would be held a little bit liable (given OnStar's popularity, I realize that this analogy may fall flat).

So long as vendors ignore the basic security recommendations, ship woefully vulnerable default configurations, and build profit centers around flawed security models (Microsoft's incredibly successful Visual Basic being the best example), the number of insecure systems will grow. Pervasive, blatant disregard for security transcends the more defensible category of true "bugs," but legislation like UCITA does little to differentiate the two. Only in the computer industry does the pretense of "user misconfiguration" hold legal weight. Neither the implementation of good security nor the penalties for bad security are the vendor's problem. It's not just accepted wisdom any more; it's the law.