Wednesday, July 23, 2008
Personal security when working overtime off-hours
One issue for information technology people working unusual hours, particularly when they “come in” while on call, is personal security and safety. This morning, the “10 Things” Column edited by Jody Gilbert on Tech Republic offers a column “Stay safe when you pull an all-nighter: 10 self-defense tips for techies”, link here.
Since the 1970s, I’ve dealt with going into the office at unusual hours and thought nothing of it. Doing so was a badge of honor. When I worked for Univac in 1974, we pulled night shifts at the Eagan Test Center (near St. Paul MN) testing benchmarks (while traveling) and I drove there on icy roads in a rental car and thought nothing of it. At NBC in Rockefeller Center in New York City in the mid 1970s, I sometimes had to go in during accounting closings on the 24-hour subway. I never thought anything of it, or ran into problems. In Dallas, the office was located in the trendy Oak Lawn section, but the parking lot was enclosed by a wire fence and locked gate (nevertheless, one employee had T-tops stolen). Back in Arlington VA in the 1990s, I sometimes came in at night and simply drove and parked at an office building near Ballston. In Minneapolis again, I could walk the Skyway. I never experienced any personal security problems going in to the office.
There was one problem in Ballston in 1990 when a “consultant” actually stole a server, which at the time would have been “worth” a lot more than it is now. That was right after I had started working there, and I had been there earlier that evening.
The other major alternative, of course, is dialing in from home with a corporate laptop, which presents its own security issues that have been covered before.
Another major security issue to think about is making sure, if you are a new employee or consultant, that you understand all of the employer’s or client’s security policies completely. When I worked for Chilton Credit Reporting, I learned (around 1982) that the company had a policy that every employee was responsible for the use of his own logon. What this meant, in that kind of environment, was simply being careful about passwords and particularly leaving oneself signed on at a mainframe terminal. Today, security policies would be a lot more complicated.