Or, as my more cliché-oriented friends might put it, "Duh!"

Leaving aside the issue of whether Sutton ever actually said any such thing, there's a good reason why that quote has become so popular in so many different contexts. It has a lot in common with William of Ockham's so-called Razor, "Pluralitas non est ponenda sine neccesitate," (Plurality should not be assumed without necessity), or, more prescriptively, "Keep it simple, stupid!"

Security practices and tools can get pretty darned complex and can and do call for a fair degree of specialized knowledge and sophistication. However, security principles are as basic and straightforward as any computer-related subject gets.

Is It Safe?

One of my favorite movie scenes of all time occurs in John Schlesinger's 1976 thriller, Marathon Man, when a Nazi dentist played by Sir Laurence Olivier asks a hapless innocent played by Dustin Hoffman the same question, over and over again.

"Is it safe?"

Each repetition is punctuated by the evil dentist drilling into yet another of his unwilling patient's nerves-without benefit of anesthesia--while Hoffman's bewildered character screams his ignorance.

Minus the drill and the Nazi dentist, that's the same question you should be asking yourself about your network. Start with the basics: How physically secure are your servers and telephone lines? What about your printouts? Do you shred documents when you're done with them..and do you lock them up when you leave at night? How many people have root access on your servers? How many of them need it? And so on.

Always start with the physical plant, because CERT (Computer Emergency Response Team), FIRST (First Incident Response Team) and the FBI all agree that most incidents of unauthorized access are inside jobs. It's the disgruntled employee, the dishonest contractor, the unescorted visitor, and the dumpster-diving "hacker" that present the biggest threats. Understanding your environment is key to assessing the threats to its security. Only after you're confident you've accounted for the physical holes in your defense should you go on to list the logical ones.

Start off by visiting CERT's web site, make sure you've read all its summaries and understand which ones apply to your servers' operating systems. Subscribe to its mailing listor Usenet newsgroup and read the new bulletins that apply to you.

Be sure to test your systems' obvious vulnerabilities. Login as an unprivileged user and try to get copies of your passwd and other sensitive files, such as sendmail.cf. Poke through your system directories and your user tree. Look at your web pages' source code and see if it reveals information about your document tree that might provide a way into your system.

Then get and run Dan Farmer and Wietse Venema's System Administrator Tool for Analyzing Networks, version 1.1.1, better known by its acronym, SATAN. SATAN only runs on Unix machines and version 1.1.1 requires a non-alpha Perl 5 interpreter, a web browser, a reasonably powerful CPU, and 64 megabytes of memory to run satisfactorily (yes, I know the README says 32 megabytes, but that really isn't enough).

SATAN will identify all of the most commonly-exploited holes in your system's security envelope. If it finds one (and it generally does), it also provides a basic tutorial on how you go about plugging it.

That's a good thing.

Naturally, you'll also want to install SATAN's counterpart, Courtney. If you run Sun hosts, you may want to employ Gabriel, instead. Both programs monitor potential SATAN attacks against your network (and system crackers also employ SATAN to discover exploitable security holes).

What's Your Plan?

Once you've identified the most obvious holes in your security environment (you'll probably never find them all), you'll be ready to begin planning your security strategy. This is harder than it sounds, since you've got to balance your very real need to secure your network against the equally real problem of unnecessarily infringing--or appearing to infringe--on your users' sense of freedom.

Nobody likes Big Brother, and people who focus on security are often seen as capricious, high-handed and even fascistic. Your task is to craft a strategy that is just as restrictive as it has to be--and no more so.

One way to accomplish this delicate balancing act is to bring the user community into the process of crafting your policies and procedures. (Mind you, this is a lot easier to do in a corporate setting than in a typical ISP!)

Your goal should be to create policies that people will actually follow and procedures that enable those policies to succeed. If, as is the case with the typical ISP, you don't have the luxury of bringing your users into the process of formulating you policies, you'll have to focus on making the user end of your procedures as transparent and painless as possible.

You'll probably want to generate policies on things like multiple logins, access to executables, maximum idle time, and password length and character. Your procedures will have to support those things. For instance, you may decide not to allow your users to run their own CGI scripts. Instead, you might want to make some standard, well-tested CGIs available for them to incorporate into their own web pages. Likewise, you might want to create a CGI that permits them to change their password via their web browser, and so on.

You Talkin' to Me?

From the perspective of the user community, security is mostly a state of mind. You have to make your users aware of the issues early and remind them often. Depending on just how sensitive you are about such things, you might want to consider requiring them to sign and return a user agreement that includes a section on security policies. If you do so, it might also be a good idea to require a second signature on that specific page.

After all, they might even read the thing.

One of the most basic security precautions you can take is to make and enforce rules that require all passwords to contain mixed-case alphabetical characters, (assuming you're in an environment that makes the distinction, of course), numbers and non-alphanumeric characters. And they ought to be no less than seven characters long, too.

The sad truth is that your users and staff--even those who ought to know better--will, if left to themselves, choose their spouse's, children's or pet's names, their Social Security or telephone or license plate numbers, or equally obvious passwords. They'll write them down and paste them to their monitors or (if they're really clever) to the underside of their desk drawers. They'll tell their deskmates or secretaries what they are and, even worse, they'll tell anyone who calls them up and sounds even remotely trustworthy.

To get them to cooperate with even basic security measures, you've got to ensure that they feel personally responsible for abiding by the rules. The only way to make that happen is to give them a sense of ownership over the problem. Now, granted, this is a little harder to do with your customers than with your staff, but there are ways to accomplish it with even the least sophisticated user--at least where passwords are concerned.

A very good strategy is to run Alex Muffett's crack program on your own passwd file from time to time. An even better one is to install anlpasswd as a replacement for your passwd executable. Anlpasswd is essentially a Perl script and a big dictionary file that it checks all password changes against.

Keep Watching the Skies!

Thoughtful, thorough threat analysis is the sine qua non of understanding your system's security requirements. Developing appropriate policies and procedures is key to creating a secure network environment. User education and compliance are fundamental to establishing a secure setting. And constant monitoring is the only way to maintain your security.

There's no "set and forget" mode with security systems. As in the race between guns and armor, the folks who compromise computer networks for fun and profit are constantly developing new tactics and tools to accomplish their aims. Today's reliable security system is tomorrow's Swiss cheese--and there are a lot of rats loose in the world.

You'll want to maintain and monitor logs of as many different kinds as possible. Analyzing those logs will help you to spot possible intruders in time to deal with them.

Of course, that's easier said than done. Analyzing system logs is a non-trivially difficult and time-consuming pursuit. The logs themselves are often huge and 99 percent of their entries are completely innocuous. It's that other 1 percent (or, more typically, 0.001 percent) that should concern you. You want to capture the information that will help you spot them, but you need to be able to pick the telltale entries out of the crowd.

A number of tools that will help you accomplish that task are listed in the comprehensive set of links maintained at the National Institute of Standards and Technology's Computer Security Resource Clearinghouse "Unix Host and Network Security Tools". If you use these tools in combination with Wietse Venema's logdaemon version 5.6--which replaces rshd, rlogind, ftpd, rexecd, login, and tel netd with utilities that log far more information than the programs they replace--utilities such as chklastlog, chkwtmp and trimlog (which lets you set rules to keep your logfiles trimmed to a manageable size) can help you find the entries that are most likely to uncover intruders on your system.

Intrusion isn't your only concern, of course. Denial of service attacks have become all too commonplace in the Internet universe. Sometimes they're conducted as part of a break-in attempt-the infamous SYN-flood cracker strategy that Avi Freedman covered so well in these pages last year being the best known example. On other occasions, they're meant to be punitive or merely mischievous. Whatever the motivation for the attack, you'll want to know when your hosts are being targeted. If your system is based on Sun hosts, or if you have the programming expertise necessary to modify it to run on other platforms, InternetMCI offers a freeware Perl 5 script called DoSTracker.

Do You Read Me, HAL?

Of course, you can download all kinds of information about security from the Net, you can follow your peers' anecdotal suggestions and you can even take my advice. But some subjects actually benefit from in-depth treatment and Internet security is one of them. Four of my favorite dead-trees resources are:

Practical Unix & Internet Security, 2nd Edition by Simson Garfinkel and Gene Spafford (copyright 1996, 1991 by O'Reilly & Associates, $39.95 ISBN 1-56592-148-8). A massive, (815 pages, plus appendices and index,) comprehensive and authoritative guide to security principles and practices in the Unix environment. It starts where all good security begins--with how to formulate, promulgate and enforce appropriate security policies--and ends with a discussion of the entire issue of trust. In between, it covers everything from user responsibility to handling security incidents, with stops at system and network security and discussions of firewalls, wrappers, proxies and building security into your own programs. It includes lots of nuts-and-bolts examples and explanations to supplement its more theoretical discourse. And it should make a great companion to

Firewalls and Internet Security: Repelling the Wily Hacker, Second Edition by William Cheswick and Steven Bellovin from Addison-Wesley Publishing Company. The bad news is that this book is not yet available and the original edition (copyright 1994 by AT&T Bell Laboratories, Inc., $26.95, ISBN 0-201-63357-4)--which was the best-selling professional computer reference book of 1994--is now more than a little out of date. The good news is that it should show up in better computer book stores everywhere real soon now. That's good news because Cheswick and Bellovin, both senior researchers at AT&T Bell Labs (now Lucent Technologies) who were responsible for designing and installing AT&T's firewall server at a time when there simply weren't any off-the-shelf firewall products. There's still lots of good stuff in the First Edition and the Second ought to really be something.

The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage by Clifford Stoll (copyright 1989, 1995 by Simon & Schuster, $6.99, ISBN 0671726889) is the story of how Stoll uncovered the Hanover Hacker, Markus Hess, after noticing a $0.75 accounting error in a user account log. Hess, who was using hosts at Lawrence Berkeley Laboratory as a launching point to break into Defense Department computers and steal nuclear secrets was caught and convicted due mostly to Stoll's efforts. The book is extremely entertaining and creates real insights into the kind of monitoring it takes to catch a skilled cracker--and the way "the authorities" too often ignore the unwelcome implications of seemingly trivial clues.

Takedown: The Pursuit and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw - By the Man Who Did It by Tsutomu Shimomura and John Markoff (copyright 1996 by Hyperion Press, $5.99, ISBN 0786889136) is another Cuckoo's Egg-like tale. Unless Shimomura's personal life fascinates you, it's not nearly as engaging as Stoll's book, but, since it recounts how Shimomura tracked Mitnick down by monitoring his exploitation of holes in three major ISPs' security, it makes a useful cautionary tale for other ISPs. It also contains some very practical pointers about what to look for when you suspect an intruder, such as changes in log file sizes (especially when they shrink).