Spying on Not-Invented-Here

The Help Net Security website has a fascinating article about a common hole in security, in the business world: One in 10 IT pros have access to accounts from previous jobs.

You would think that when a person leaves a company, all of his or her access to that company’s computers would be removed. You might even think that all of a person’s access was controlled at one secure control point, so that a single action was all that was required to remove all of a person’s ability to connect to a previous company. Alas, it’s not that simple. An observation of Bruce Schneier seems to hold, instead: companies set up their projects with productivity in mind, not security. Security can slow things down a bit, and is often an afterthought.

I benefited from one of these loopholes in an amusing way. I was working at a company, developing software for a client. This development work was “on spec” because the client had no money to pay us until they floated a public offering. I worked closely with the client to identify needed software, and I was proud of my results.

After the client got their next round of funding, they brought in a new set of developers, a group whose experience was better suited than mine to their future needs. For a very short time, we all worked together while they set up their development environment. I proposed to give them a walkthrough of the features of my software so that they could decide what they might want to integrate into their future work. Politely but firmly, they made it clear that they were only interested in what they would write themselves. It would be a waste of their time to spend even one day on my work. I didn’t feel too awful about this, because I had been paid for my work, and I know that the “NIH” sentiment is very strong among programmers. The client severed all connections with me and I no longer had access to their developers or to their work.

Except for one thing.

When the client was setting up its development environment, it used an excellent tool for tracking bug reports. I was working with their people at this time, so my email account was added to the list of bug report recipients. I got to read all their bug reports.

I would say that 98% of these were either boring to me or incomprehensible, but the remaining 2% made my day. These were reports about unexpected problems they had to solve, that I had already solved in my software that it was not worth their time to know about. I’ll give you a taste:

In the client’s product, a modern UNIX system had to communicate with customer terminals that ran a very customized version of an older UNIX. UNIX systems store the date as the number of units since a reference date, say, midnight, January 1, 1964. In the client’s case, the two different UNIX systems used a different reference date, so that the same date “number” meant different a day and year in the two systems. My software had routinely adjusted date fields between the two systems, to allow for this. I was delighted to see the bug report about “Holy Cow, did you realize that the date fields are different on the two systems, and that it’s screwing us?”

It was a long time before I stopped enjoying those bug reports.