Columns

A perpetual game of Internet chess

• By Tony Baer
• December 1, 2001

Ever since the Internet became part of pop culture, our wisest people have been ruminating about the question of when, not whether, the Internet would ever melt down. It has so far survived. In fact, during the September 11 attacks, the Internet provided the only reliable means for New Yorkers to get messages out to friends and relatives.

Credit that to the brilliance and simplicity of IP protocols, which empower every packet to find its own way around network roadblocks wherever they are.

Yet barely days after the attacks, the Internet was tied up—but not shut down—by the Nimda and Code Red viruses. The Internet survived again. But here are a few scary thoughts. What if the viruses had been timed for release with the World Trade Center attacks? And what if those viruses had been accompanied by vast invasions of corporate data banks?

Given the way most organizations protect themselves against cyberattacks, cleverly designed rogue agents could have run rings around the antivirus measures, firewalls, passwords and access control policies that, for most companies, pass for IT security policy today.

According to Gartner Inc. analyst Richard Hunter, firewalls won't guard against the most likely source of sabotage: a disgruntled employee. His colleague John Pescatore adds that maybe it is time to encrypt not just external communications, but the contents of company databases.

There's no escaping it: effective security is anything but cut-and-dried. David Cotter, a security specialist for consulting firm Alliant Technologies in Morristown, N.J., described a recent engagement with a Fortune 1,000 corporation that overhauled its IT security. The goal was a highly layered process, because no single feature or process could catch everything. It included the following:

• Policies. Coming from a backdrop of skeletal policies for items ranging from e-mail usage to Internet access, data classification and change management processes, the company conducted a huge overhaul, formally designating what constitutes proper alerts, who's in charge of making which decisions and when to quarantine compromised systems. At the application development-level, the organization had already largely standardized on Java and Visual Basic for new Web applications, but had to develop guidelines for preventing new systems from opening up the wrong ports.
• Beefing up antivirus protection. The organization had plenty of tools, but most of the processes were localized and ad hoc. Besides designating quarantine and decision-making responsibilities, the company implemented a specialized virus management console because the SNMP data that was fed to existing network management frameworks, such as HP OpenView, proved inadequate.
• Content filtering. At the risk of playing censor, Cotter's advice was to start with a highly restrictive policy, screening e-mail and Web sites for the seven dirty words and more. With experience, he said, you can gradually ease up.
• Intrusion detection. Firewalls are just one piece of the strategy. The project supplemented them with external mechanisms, checking routers and other network devices that communicate with specialized consoles on a 24x7 basis using highly encrypted proprietary protocols.
• Culture changes. Sounding like ERP and other enterprise application projects before them, security dictated changes in mindsets, internalizing thought patterns such as having employees shut off network connections whenever taking restroom or coffee breaks.

Like the ongoing debate over national security vs. civil liberties, solutions to IT security problems often raise more questions than they answer. For instance, when does enterprise content filtering equate to petty censorship? When does intrusion detection generate so many alerts that humans grow jaded to the warning messages? When will users grow tired of all the extra vigilance? And how frequently must you update change management processes to reflect what's really happening inside the organization?

Then there's the question of where developers fit into all this. Sure, choosing a "secure" language like Java protects against obvious faults, like memory leaks or the commandeering of system resources, but the applications themselves could still contain faulty logic that allows the wrong people to get access to the right stuff.

For developers, network managers and CIOs, the new lessons of security are that nothing is 100% fault-tolerant, and that protection involves playing a continual game of chess where the pawns and underlying assumptions are in constant motion.