Friday, May 30, 2008

Prudent Password Security

We get email . . .

Awhile back I got an that said, in part:

    ". . . a book like yours is long overdue. I read with great interest the recent article in Reseller Advocate Magazine. I’ll be purchasing one of the editions when I get to the office Monday, but I had a few questions about your system.

    First, in this day of HIPAA and other security “best practices”, we continuously preach “DON’T WRITE DOWN YOUR PASSWORD” and “NEVER GIVE YOUR PASSWORD TO ANYONE”, but from what I read in the magazine article, we’ll be going from workstation to workstation to server documenting passwords and writing them down. What is your approach with your clients?

    Second, we’re going to take this collection of security data and place it next to the server (or worse, in the unsecured boss’s office) so that when someone does manage to break into the server room, we’ve just handed them the “keys to the city”.

Remember, everyone has to do what you think is best regarding security. Remember, also, that my Network Documentation Workbook is not intended to replace ISO9001 certification. In the real world, we have clients who fit this model:
  • They do not have passwords, use "password" as the password, or use their wife, husband, dog, cat, child, or company name.
  • They have no record of any passwords. Problem with the router? Neet to change ISPs? Throw away the router and get a new one, because you don't know the password.
  • No one has every written down the name of the ISP! or the account information for domain registry management. or the secret password you need to access your T1 account information.
  • They use the same password for everyone.
  • They do not change passwords when someone leaves the company. In fact, they don't disable or delete the user!
  • etc.

In the small business world, horrible security procedures abound.

99.999999999999999999999999999999999999999999999999999999999999999% of the time, the problem is NOT that there's a list of passwords in a binder on the shelf.

The problem is that all the access codes for the online banking account are posted on a bulletin board.

The problem is that the most important database in the company is available via the company web site with user "sa" and no password.

The problme is that the boss hasn't changed her password since her son was born in 1998.

The problem is that everyone knows every else's passwords.

The problem is that even United Airlines posts terminal logon information on their Sabre terminals at the airport.

So, here's the deal on documentation: Yes, we document everything. In most cases, we keep the network documentation binder next to the server. So if you need to know the active directory password for the server you upgraded from Server 2000, you'll have it at your fingertips. And if you need to know the account used to run that special line of business application? You got it.

Think about the number of times you've taken on a new client and there were no passwords or other information written down anywhere. You charged those clients to find, crack, or reset passwords. In some cases, you may have reinstalled an operating system in order to gain access. You've probably set routers, firewalls, and network print devices back to factory specs so you could get in and then reconfigure them.

You charged them to figure out whether DHCP is handed out by the router, firewall, server, or some other device that showed up one day. You charged them to figure out who the ISP is, what the line configuration is, who all the email users are, and whether email is stored in-house or hosted.

You've come across desktop PCs with local admin passwords -- or CMOS passwords -- that are not recorded anywhere.

Money Matters

How many hours did a client like that pay you to "figure out" all that stuff (and more)? Because you didn't do it all at once, it cost a lot. One day it's the firewall. Another day it's the network scanner configuration. An hour here, half an hour there.

You could easily spend 5-10 hours over the course of several months.

And did you write down all that stuff? If so, is it in a place where the client can find it? If you get hit by a bus, will the next technician have all that information at his fingertips, or will he start from scratch?

Poor documentation costs businesses a lot of money!

And if they pay this again and again every time there's a new technician? At some point, it's our industry that's to blame.

A Little Perspective

If you're concerned about the security of the network documentation binder, store it in a locked file cabinet in the boss's office.

Or in a locked cabinet in the server room. Or lock the server room.

There are many ways to secure the binder.

But, realisitically, how many times have you seen a situation that could have resulted in Binder Abuse? A stranger wanders into the office, finds his way to the server, and spends time flipping through the NDB.

Yes, it can happen.

But most of the time, for most businesses on earth, this is not the problem. The problem is that the company has to waste money paying (again) to figure out how a network is configured. In terms of real-world monetary loss, the consultant who doesn't record passwords is more expensive than the stranger who steals a binder.

- - - - -

You can certainly add any level of security you want to the NDB process. But there just isn't an argument to be made for not having a network documentation binder.

Documentation is not your enemy.


  1. Anonymous7:27 PM

    what article is that? I searched RAM's website for your name and it didn't find anything

  2. Anonymous11:22 PM

    This blog is published by Karl palachuk. In this blog he has talked about different techniques to prevent data from leakage within organization. Have a good day…………..


Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!