There are, as you can see, a few tools for your use. If you want a second reason for looking at these tools, keep in mind that people trying to break into your system know how to, and do, use these tools. This is where the knowledge comes in.

Knowledge Gathering

Someone once said a little knowledge goes a long way. As stated in the chapter opening, all the bells and whistles can be there, but if they are not active, they do no good. It is, therefore, important that the system staff, the users, and the keepers of the sacred root password all follow the security procedures put in place—that they gather all the knowledge necessary to adhere to those procedures.

I was at the bank the other day, filling out an application for a car loan. The person assisting me at the bank was at a copy machine in another room (I could see her through the window). Another banking person, obviously new, could be heard from his office. He was having problems logging in to the bank's computer. He came out and looked around for the bank employee helping me. He did not see her. I got his attention and pointed him toward the copy area. He thanked me and went to her and asked for the system's password because he could not remember it. She could not remember the password. He went back to his desk, checked a list of telephone numbers hanging on the wall by his phone, entered something into the computer, and was in. About that time, my bank person came out of the copy area, stuck her head in his office, and said that she recalled the password. He said he had it. She asked if he had done with the password what they normally do. He looked at his phone list and said yes. She left and returned to me at her desk.

This scenario is true. The unfortunate thing about it, besides the fact that at least two customers, the person with the employee trying to log in to the system, and I, saw the whole thing, is that they didn't know, nor did they care that others might be listening. To them it was business as usual. What can be learned from this? DON'T WRITE DOWN PASSWORDS!!!!!

Not only should passwords not be written down, but they should also not be easily associated with the user. I'll give you two examples that illustrate this point. The first involves a wonderful man from the Middle East with whom I worked on a client site. He has three boys. As a proud father, he talks about them often. When referring to them individually, he uses their first names. When referring to them cumulatively, he calls them "three boys." His password (actually, he uses the same password for all his accounts) is threeboys.

The second example comes from one of the sweetest people I have met in the industry. She is an unmarried person with no children. On her desk is a little stuffed cow, named Chelsea. I do

not remember the significance of the name, but I remember that she really likes dairy cows. Her password is, you guessed it, chelsea. These peoples' passwords are probably still threeboys and chelsea.

File security is another big issue. The use of umask (file creation masks) should be mandated. It should also be set to the maximum amount possible. It is easy to change a particular file to give someone else access to it. It is difficult, if not impossible, to know who is looking at your files. The sensitivity of the data, of course, would certainly determine the exact level of security placed on the file. In extremely sensitive cases, such as employees' personnel records, it might be necessary to also encrypt the files.

After an audit has been done, you should have an excellent idea of what security issues you need to be aware of and which issues you need to track. The next section shows you how to track intruders.

Danger, Will Robins, Danger!

I used to love watching Lost in Space. On that show there was a life-sized robot that would declare, "Danger, Will Robins, danger!" when there was some danger. Unfortunately, there is no such robot to declare when there is danger on our systems. (There are some tools, but they are nowhere near as consistent as the robot was!)

If you have a lot of extra disk space, you can turn on auditing. Auditing records all user connects and disconnects from your system. If you don't rely on auditing, you should scan the logs often. As an alternative, it might be worthwhile to write a quick summary script that gives an account of the amount of time each user is on the system.

Unfortunately, there are too many holes to block them all. Measures can be placed to plug the biggest of them, but locking a computer in a vault, allowing no one access to it and no connectivity outside of the vault, is the only way to keep a system secure. The bottom line is, if users want into your system, and they are good enough, they can get in. What you have to do is prepare for the worst.

Preparing for the Worst

There are basically three things that can be done to a system, short of physically removing it. These are stealing data, destroying data, and providing easier access for next time. Physically, an intruder can destroy or remove equipment, or, if very creative, could even add hardware. Short of chaining the system to the desk, there is not much that can be done about theft. The physical security is beyond the scope of this book, anyway. What is within the scope of this book is dealing with the data, and dealing with additional access measures.

Data should be backed up on a regular basis. The backed-up information, depending on how secure it needs to be, can be kept on a shelf next to the system or kept in a locked vault at an alternative location. This is the best way of getting back data that has been destroyed.