Professional Paranoia: Secrets of Security Experts

The last security article I wrote generated a flood of email. Most messages said exactly the same thing: "How do I become a security professional?"

First of all, you probably don't want to become a security professional. Sure, it sounds glamorous: You strut in, violate a network a dozen different ways, and show that you know a lot about security. That really isn't a big deal; you can do the same sort of thing just by demonstrating that you're good in any field. All you have to add is the strut.

Most security professionals are contract consultants. They visit different companies and perform intrusion testing. That's where where they break into the network and demonstrate just how badly flawed the system security is. It's a pretty safe bet that you can go to any company in North America today and break in. I did this for a couple years as an independent contractor. I found that I hate to say "I told you so."

No, I take that back. I love to say "I told you so." But I get so very tired of it. Much as a front-line help desk person learns to despise callers for merely breathing, a security pro grows to despair clients of ever getting a clue. If I hear one more high-level manager say, "But we paid a $100,000 for this security system just last year," I'm going to slap them upside the head with a week-dead salmon.

If you're good, you can get a job at a company where security is paramount. Here in Detroit, several automotive firms and their suppliers demand absolute security. It's all schedules and permissions policies and making sure that someone doesn't install one of those free Unix variations without authorization. After all, users who can comfortably use desktop Unix are the most difficult to handle. They either have more of a clue about computing than the average user, or they're a menace to network safety -- possibly both. And they probably want SSh and CVS access to the Net instead of plain vanilla HTTP.

The 60-page security policy you dragged through five different committees and nine revisions says that they only get HTTP. And that same policy probably says that they only get the corporate-approved OS, even if the senior LAN troubleshooter might as well be hog-tied without his BSD laptop. You're no longer a geek. You're a paper-pusher, a "proxy Nazi," and a general pain. And every committee meeting has scraped a little bit of sunshine off your soul. You can't be a good guy even if you still want to be.

At the end, it doesn't matter. You can be as skilled as you want to be and someone, somewhere, can still kick your hiney. Arrogance isn't useful in the security business. Humility is. I'm no longer a security professional because I want to be arrogant on occasion.

What you can do quite effectively is bring a security awareness to your current job. If you're a programmer, network administrator, or even a help desk person, an understanding of the security implications of your work can do nothing but help your career.

There's two methods that have been used by professionals for hundreds of years. They apply just as well to computing professionals today.

Take care of your tools

Take care of yourself

You wouldn't see a long-term professional mover trying to shift a refrigerator without a back brace, or a doctor putting his ear to your chest without a stethoscope. Similarly, if you don't understand the ins and outs of your tools, they'll corrode and you'll slip a disk.

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.

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.