Skip to content
Home » security » Predicting the future, circa 2003

Predicting the future, circa 2003

In the heat of the moment, I searched my blog this weekend for quotes that could potentially be taken out of context and found something rather prophetic that I wrote in the heat of the moment 11 1/2 years ago:

Keeping up on Microsoft security patches is becoming a full-time job. I don’t know if we can afford a full-time employee who does nothing but read Microsoft security bulletins and regression-test patches to make sure they can be safely deployed. I also don’t know who would want that job.

Who ended up with that job? Me, about a year after I left that gig. It actually turned out I was pretty good at it, once I landed in a shop that realized it needed someone to do that job, and utilized that position as part of an overall IT governance model.

 There are ways to solve all of those problems I faced in 2003. I know that now that I have 11 1/2 more years of experience under my belt, but I won’t be too hard on myself because the people with 11 1/2 more years of experience than me weren’t coming up with any solutions at the time either.

Part of it is that times have changed. Today, keeping ancient versions of SQL Server still running today is frequently a regulatory violation, or if regulations don’t apply, a contractual one.

If you absolutely have to do it, then yes, throwing more security at it is an option, like what someone asked me in 2003. It won’t be cheap, but it’s doable. The most straightforward method is to take all your ancient stuff that has to talk to each other, put it on an isolated network segment and put it on a VPN, RDP into the system to use it, get what you need, then export the output in a safe data format, and you can continue to use a legacy system that can’t be updated with reasonably low risk, though it’s not terribly convenient. Security frequently isn’t convenient.

The problem of protecting corporate data from insider-owned outside laptops is also solvable, but not cheap. We could have implemented 802.1x in 2003–the technology existed then–but I don’t know if we could have afforded it, and we would have had a lot of devices that weren’t capable of 802.1x at the time. The same network inhabitants who would have objected to crude MAC filtering would have objected to 802.1x as well, but it would have been easier to manage once the necessary infrastructure was in place.

Reading that old blog post, I was very frustrated with Microsoft at the time. Microsoft had some growing up to do, which they did. There was also some definite culture clash going on, but that’s explainable. This was an organization that fancied itself as very Internet savvy, and in some ways they were. They got in early enough that they accumulated a big pile of three- and four-letter domain names. And they certainly had ambitions to really take the Internet by storm. The thing was, they bet on Windows and most of the shops that went on to make it big on the Internet bet on Linux or BSD, or a combination of Linux, BSD and Windows.

Unix was a very hard sell in that shop because it had run on VMS for so long, but there were definitely times when it would have been more cost effective.

Lessons learned

This was a very tense situation, and we had a lot of tense situations in those days. Then again, when you go into a shop and find a server running Windows NT 4.0 and other Clinton-era software and patches ceased on some weird date, chances are it was a result of one of those other tense situations.

The most important thing I could have learned was networking–the human kind. Every shop has challenges and some of them take different approaches, so we can learn from each other. This particular shop had incredible turnover, at least when it came to newcomers, and that would have been a fantastic networking opportunity if I’d had the foresight to keep in touch. It didn’t occur to me at the time that the tendency of people to come in, last three months, and leave was part of a bigger issue, and that the phenomenon could have helped us to find the solution.

I was ahead of my time by virtue of blogging, at least.

We also have opportunities today that I didn’t have then. Listening to podcasts is a really easy and cost-effective way to get outside perspectives regardless of the other available opportunities.

And on a personal level, note that I was advocating for Unix in 2003 and yet I still live mostly on the Microsoft side of the house today. Part of our problem in 2003 was IT governance, or lack of it. Aside from broad directives that we were going to use Microsoft technologies, there was little other guidance or authority. By 2006 I was working in a shop that had a change control process,which provided the structure to plan, test, and implement changes on a regular, ongoing basis. It took a little time for me to adjust to that bureaucracy–and it really does add a layer of bureaucracy–but once you get used to that, it does actually make everything a lot easier because testing and recovery are all part of the process. IT truly becomes a discipline. We get in a routine, we build processes for everything we do on a recurring basis, and if we’re really doing things well, we use lessons learned to come back and revise and improve those processes on a recurring basis so we can get even better at what we do.

Unix would have solved some problems for us but wouldn’t have addressed the root cause. Implementing a change control process would have. I didn’t come up with that solution, but in my defense, neither did anyone else.

And that brings up one more thing I’ve learned about IT over the last 11-plus years. The problems we solve are important, but what we learn from those problems is even more important.

If you found this post informative or helpful, please share it!
%d bloggers like this: