oreilly.comSafari Books Online.Conferences.


Professional Paranoia: Secrets of Security Experts
Pages: 1, 2

If you're a programmer, your tools are libraries, IDEs, languages, and so on. If you're a network administrator, your tools are physical devices, operating systems, and server software. Take a moment to think about what your tools are.

When a good auto mechanic is finished with his tools, he cleans them and puts them away. When was the last time you spent any time checking over your tools? What patches haven't you applied? Are you still sending mail with sloppy "CDONTS"? What about that default password on the Cisco? Or those unsanitized Perl regexes? Many people have things that they know they should have done, but haven't gotten around to yet. Might as well leave your wrenches out in the rain.

Also, you need to know what tools you have and what they do. I've seen a network administrator who was blissfully unaware that when he dialed into the Net to avoid a firewall, his laptop started broadcasting RIP and dragged the corporate network traffic out through his 56k dial-up. He was too busy with his unfettered Net access to answer user complaints. (I only noticed because CVS worked one hour a day, between 12:00 and 1:00.) I've seen a developer implement a private back-up scheme because he didn't know there was a file server for his use. Because this back-up scheme involved a CD burner and the trunk of his car in a Michigan summer, it was a security problem. Learn what you have. Use it. If it's insecure, don't do it.

If you're a programmer, examine the source code of your product for weaknesses. Check the source code of your programming libraries as well. Every language has its own weaknesses, from the classic C buffer overruns to Perl scripts that allow someone to slip cat /etc/passwd into an exec file. Security folks gripe about Microsoft a lot, but it's just as possible to write insecure PHP or Perl as it is to write insecure ASP. PHP, ASP, Ada, Modula-3 -- they all have their share of weaknesses where data must be handled carefully. Coding practices that are perfectly safe in Java might create hideous gaping security holes in C++, even though the languages look similar.

If you're a network administrator, learn what's going on in your network. Odd behavior means that you don't understand something. If you don't understand what's happening in normal circumstances, how can you expect to understand what's happening when a script kiddie defaces your web site -- or worse, when a skilled attacker slips into your fileserver and the only symptom you have is one unexplained 3:00 a.m. reboot?

Network administrators in particular have to watch out for users. If you don't provide the resources the company staff needs, the employees of the company will find a way to get them. This frequently involves phone lines becoming modem lines or some clever boy tunneling SSh over port 80; in other words, security holes you know nothing about.

Secondly, let's consider you.

Computing changes constantly. So do law, medicine, social work, and dozens of other fields. If you don't keep up on changes in your field, you're creating security problems.

For a network administrator, this means BugTraq and vendor security bulletins. You need to know not only the security holes in what you have, you need to understand the security problems in what you might have. One day, some manager is going to come up to you and say, "I just saw a nice ad for the BooSoft MultiThwack. We could use it, please order one." You need to be able to respond with a calm and well-reasoned "The MultiThwack has some nice features, but it has a history of security problems. Would you like me to investigate some secure and reliable alternatives to provide that same functionality?"

As a programmer, you need to know what security holes are being discovered in your tools. Read a security mailing list for your language. If you look, you'll find one.

If a lawyer doesn't keep up on new legal precedents in his field, he's dead meat. So are you.

Get a couple of security books, and read them. I have three I'm going to recommend.

  • Practical Unix & Internet Security, by Simson Garfinkel and Gene Spafford is a good overview of how to secure a network.

  • Secrets & Lies by Bruce Schneier is a good overview of how real-world security works. It's readable by both technical and non-technical people alike.

  • Finally, Maximum Security by that best-selling author "Anonymous," is a good guide to breaking into your own network. There are others, such as Hacking Exposed, but Maximum Security is one of my favorites.

You cannot secure everything. If you're a network administrator, you can make sure that the firewall is tightly secured and that only certain types of traffic can pass in and out. You have to trust that your developers are writing their code without buffer overruns or passwords hard-coded in JavaScript. Similarly, if you're a developer, you need to make sure your code is tightly secured. If the network administrator is a doofus who leaves NFS shares open to the Net, you're doomed anyway.

The short answer is: communicate. And learn. Learn everything you can. A little bit of professional paranoia on your part can solve a lot of problems for a lot of people.

Let me be as blunt as possible:

Computing professionals who don't understand the security issues inherent in their chosen fields are creating security problems.

But hey, you don't have to listen to me. I can always make a good living saying "I told you so."

Michael W. Lucas

Return to

Sponsored by: