Just last week, I had an interesting experience with a web host that I use (as always, names of the guilty withheld). It highlighted some of the things that I’ve talked about in this column about customer service, security, and employee empowerment. It wasn’t that big of an issue, but it was a reminder of how little problems can easily cascade, eventually resulting in lost customers (which I considered becoming before they fixed the problem).
Let me hit rewind and go through the play-by-play. I think there are some important lessons to be reminded of here.
The prosecutor’s case
I was attempting to setup a common CGI package on my account. I went on for a while and ran into problems that I knew meant that there was something wrong with either their servers or the installation process. The host’s online help docs didn’t get me anywhere, so I went searching around the net. With a little Google mojo, I found a good lead. There was a configuration file that needed to be adjusted.
The problem was that it wasn’t clear exactly how it was supposed to be adjusted. I tried just about everything obvious. Nothing worked. Finally at a standstill, I threw in the towel. I dropped an email to their tech support. They had an online submission form, but it went to the email that the host provides, which I’d never used or redirected.
The defendant’s case
I received a reply back pretty quickly. It stated that since my address wasn’t the primary email address for the account that, per their security procedures, they would have to contact the address that was, and see if this was a valid address to offer tech support to. From that point on it was mostly smooth sailing.
Well, gee, that doesn’t sound all that bad. So where’s the problem?
There were a few of them. First of all, even though it was true that I wasn’t writing from the contact address on file, I did include in my email to them the domain name that I was working on, and two forms of customer ID numbers that you can only get from within the account. Furthermore, I pasted in the entire error message that I was getting, again something that proves that I was already in. Given all of the information that I gave to them, it would have been trivial as well to check through their logs to see that I was, indeed, doing the work on this site that I said I was.
In short, it should have been clear that I already had full access to the site. One could counter that this doesn’t necessarily mean that I didn’t hack into it. There are problems with this response as well, though. For starters, I could just as easily hack into someone’s email as I could their web hosting account, so how would that have been de facto more secure? Additionally, if I really did hack in and wanted to contact them for help, why would I have “tipped them off?” There were certainly ways to write them that wouldn’t have. I could have actually used the in-house contact form. I could have just changed the contact email address once I was in there. On the other hand, it’s common for multiple people with different addresses to be working on the same account.
The verdict: guilty of misdemeanor
In the end, this only resulted in a short waste of time for us, but what if that time had been critical? It was, in truth, something I was trying to setup quickly, and the delay was quite irritatingly timed. The greater problem, though, was that it was unnecessary. The amount of assumptions that you would have to make to conclude that I was an intruder is too high to be easily plausible.
Of course, no web host wants to take unnecessary chances on security. So maybe was there another way? Yes: the host could have responded to my request with the necessary technical information, then dropped a separate note to the email address on file telling them of the conversation and verifying with them that I was indeed authorized to be working on the site.
The sentence: make your security more dynamic
This approach would accomplish multiple things. It would, of course, let me continue working on the site immediately. On the miniscule chance that I really was a bad guy, it would still let the account holder know about it.
It would also have another subtle advantage on this note. If I were truly a hacker, and I got an email saying “We’re going to check on you”, that would be my cue to cause whatever damage I was meaning to and get out of town. Instead, using the above approach, you can keep a quiet eye on them to see exactly what they are doing. This approach would have been more secure.
This goes back to the inherent deficiency of unbending rules. We mentioned in the past that it’s better to cut your employees some slack and given them the room to make judgment calls. This is a great example of why. A single tech worker given the room to think about this email could easily have come to the above correct conclusions.
On the other hand, if you make your security procedures rigid to the letter, you hand the people who really do want to cause damage a road map telling them exactly how to get in. If your procedure is dependent partially on well thought-out rules and partially on “common sense”, an intruder will have a harder time penetrating it. Meanwhile, the entire tech world is filled with people who have been locked out of their own accounts because of overly strict security doors that they lost the key to.
A co-worker I once had summed it up eloquently: “Laziness and security never go together.” A hard set of rules that you apply in all cases, even the most ridiculous, is lazy. Some workers may want to fall back on being that lazy, but that does no one any good. The sentence in this case is to teach your workers a bit more about how to spot the little things that signify that something is wrong, and then gives them the free hand to react to it intelligently, based on the specifics of each situation. It’s a little time invested for a lot of reward.