I love Spring

May is upon us. My son Michael turns 19 this month, I'm in the midst of trying to get a new company going to replace our employment with Lineo, and summer is fast approaching. All in all, things are pretty normal.

As noted in the April page (which I just put up on May 1) I spent most of my spare hours in April thinking about and writing my formal objection to the proposed blank audio recording media levy here in Canada. I just sent it off to the Copyright board and now begin what could be an "interesting" time leading up to a potential appearance before the board some time after the summer this year.

Ahh well, this should be a good reason for taking some sort of holiday and traveling back to Ontario. While I have been there before many times, I've only spent a couple of weeks actually being a tourist, back in the early 90's when I was working more closely with CEN-TA. At that time I was looking after their computer systems and remote offices all across Canada and took the opportunity to extend a business trip and enjoy some time with Shirley away from the kids.

Much as we here in the West disparage the East in general (and Ontario in particular), there really is a lot of very pretty and interesting scenery there, as well as a lot of our Canadian history. If you choose your times right, it even has a pleasant climate - usually for a week or so during Spring and Fall :) We hit the week in spring around the end of May, driving around the lake country between Ottawa and Toronto; pleasant memories.

Parallels in Life

I took a day "off" last Sunday (April 28) and hopped on my motorcycle at 5:30 in the morning to catch the first ferry to Vancouver Island to visit my mother and brother for the day. I like to take the Honda because, while the first ferry is rarely busy, when I come home later in the day I get on ahead of everyone else and never have to wait; one of the nice things about the way our ferry system treats motorcyclists.

The trip over was uneventful. I'd already had a bowl of cereal, and I was invited to brunch with my mother at 11AM, so got to skip the ferry food. Getting in to Nanaimo at 8AM meant I was quite a bit early to see anyone, so I took the time to visit some of my favourite back roads between Nanaimo and French Creek where one of my two brothers lives with his family. Kerry and his wife and daughter are off in Europe for the next while, and I thought I'd drop in on their property to check it out. The day was clear and calm, and despite the fact that it was still only late April, the day proved to be quite warm.

I stopped for gas in Parksville and got to talking to one of the other customers. The Honda tends to attract attention as much due to its size as to its great looks, even though it is straight off the assembly line with no modifications. Along with the typical remarks on the bike itself, this gentleman took a look at my heavy leathers and asked if the fact that they were black made them hot to wear. The answer of course is that keeping warm is actually the hardest part of riding in all but the hottest climates when one is going 110K (60mph) since the wind chills you. The other side of the coin is that when it is hot, you want your leathers to be able to help cool you so you don't take them off!

Now I do a lot of thinking while I drive. I love driving (especially on the Honda), have several million miles under my belt, and it relaxes me. This day trip was no exception, and after brunch and a wonderful 4 hour chat with mom I took back to the road again with the intention of seeing my other brother, Doug, about 100 miles South of Nanaimo in Victoria, the capital of BC.

During this next 4 hours of driving (I like the back roads and took my time) I thought back to what the gentleman and I had talked about, and how the design of good motorcycle leathers in fact parallels the design of good computer systems in general, and security systems in particular - a strange parallel, but a good one none the less.

The worst thing you can do with motorcycle leathers is not wear them when you are riding. The reasons you might do this all have to do with convenience and comfort. If it takes too long to put them on, you might decide not to for a short ride; bad move.

If you are uncomfortable in your leathers, you might decide not to put them on, or might decide to take some or all of them off. When it's hot this is a real problem with some designs. I spent extra on mine just so I don't get tempted. They have the facility to open up zippers front and back and set up a scoop on each side of my chest to push air through them. This coupled with scoops on the arms at the wrist make them almost as cool as not wearing them at all - and the design keeps me wearing them.

The parallel with security systems might sound like a bit of a stretch, but bear with me.

Leathers keep you safe when the unexpected happens. Somebody pulls out of a side road in front of you, a tire blows, or a patch of diesel on a curve, or any one of life's challenges on two wheels.

Your security system should keep you safe in similarly unexpected encounters and just as with leathers, it should not be uncomfortable enough in its use that your users never forsake it or go around it (not use it) at any time!

The most obvious item with a comfort zone is passwords. Unless users can remember passwords without having to write them down, they leave your systems open to a number of potential "accidents" with injuries:

While passwords are the most obvious security item with a comfort zone, you can probably think of others in your daily grind. Ones I watch for include restrictive rules on access to something, policies and procedures which intrude on employees' ability to do their job or even worse, get in the way completely.

There are lots of reasons why an IT manager might put a restrictive policy or complex procedure in place. There are even more cases where evolution has put policy and procedure roadblocks to productivity in front of employees to the point where they actively work at going around them.

Take the case of one international company I know. The original proposal was to connect all the various world-wide offices back to the head office via various speeds of Frame Relay link, and only allow connection to the Internet via the one link at head office. Now in a traditional business such as an insurance or wholesale or retail empire, this might have been reasonable. But this was a software company with a focus on Internet software and other things GPL. The people hired into the various offices were used to going directly to the 'Net to get source at any and all times, and were used to multi-megabits/second incoming links in most cases with ADSL and cable connections. Putting a backhaul to head office (adding about 100ms latency at the best case) and then choking all such access through what was to be a pair of T1 links (for redundancy) which were also to host the company's web site and public download meant that programmers would wait huge lengths of time for things they needed in order to work at all. And all this was proposed in the name of security.

Now don't get me wrong. The security aspect was critical. Work on proprietary customer code and things like design specs and internal correspondence all had to be done with utmost security. On the other hand, software techs forced to sip from a straw when they are used to drinking from a bucket will figure out a way to use the bucket - and that may not be as secure as you want/wish it would be unless you (as IT manager) know about it and get a say in its implementation. Fortunately, saner heads prevailed and the idea was dropped in favour of encrypted VPN technology via local Internet links.

In another case, a change in technology from a mainframe oriented inventory system to a networked client/server one caused no end of grief. The manufacturing company maintained a parts inventory that included some very expensive custom parts, but spread their locations around between several plant locations, each of which might need the same part, on the theory that shipping from one to another was faster than having one created on demand, but keeping one at each location was more than was needed for the likelihood of a breakdown happening. The problem was that the client/server inventory system didn't really deal with this properly since each plant had its own inventory instead of the centralized one they used to share. The "fix" was to create a separate "bin" location in each which detailed the shared inventory - and put into the description the real location of the part. This was fine except that there was no provision for automatically updating the remote systems when a local system used a part that was stored locally. The plan had been to phone the other sites (the frequency of this was low enough and the parts cost enough that this manual interaction was deemed of minimal cost) if/when a part was needed. So a big drive-shaft was taken out of stock one day and this fact not recorded in the remote data. A few weeks later, the same part was needed at another location. It had not yet been replaced (turn-around on this part was something like 6 weeks unless a rush order was placed) but the requesting location didn't know this - they thought it was in stock. 

The parts manager at the location where the part should have been was off on vacation, and the order for the part was inadvertently put into a back-order queue to await the arrival of the already ordered part. At an average of $1million per day of downtime for lack of this part, the fact that the order was not pushed to rush status immediately was very costly.

Some bright spark at one of the plants decided that he could fix this problem by using a modem at each site to send automatic updates. He didn't inform IT of this since he figured they didn't know enough about the problem to give it the priority it was due - and so he went ahead and "fixed" the problem himself. In fact, he almost got it right - the updates did go, and the inventory didn't have a problem anymore. The problem was that there was trivial protection on the modems and somebody hacked into the server at one location one day and put in a Trojan. It took IT a while to track down what happened and fix the major security leak this caused. Fortunately the culprit (the cracker, not the employee) didn't destroy any data.

These two examples are a couple of the more complex ones I've seen. The more typical one is the employee who brings a modem to work and hooks it up to the phone line and their workstation so they can get their personal mail at lunch time - and in so doing brings in a virus or worm or worse.

Employees have to understand why security features are in use, and what they protect against and how. They need to know why the company "wears leathers" on their IT systems and understand that the policy is there to protect, not to annoy. On the other side, IT people need to understand what drives employees to subvert security systems and when to back off or at least educate.

The human in the security loop needs to know what is going on and be involved in the process from the start. They need to be reminded frequently (but not nagged unmercifully or they'll tune you out) of what is being protected, why, and how.

Council users on picking good quality passwords, but allow them to keep them long enough that the effort of memorizing them is not wasted or annoying. In this you need to council and teach good password entry skills such as guarding against shoulder surfing, etc. By all means, run password cracking programs and hound those whose passwords you crack to fix their habits.

Remind users of policies on unauthorized Internet links and activities - and why they should care. On the other hand, listen to them when they tell you that a particular policy is "getting in the way". It may be that there is nothing that can be done about it, but you may need to run interference between the employee and a manager with unreasonable expectations. 

Remember, the comfort level of the security is every bit as critical as the actual level of security it provides. Don't let your users be uncomfortable.

richard