Voice of the DBA

There has been a lot of news about air traffic problems in the US in 2025. I haven’t had any delays due to this, though I’ve gotten a few messages in my travels that I might want to reschedule. There was an article that some of the technology still used in various facilities is old and needs upgrading. Old as in Windows 95 and floppy disks.

That’s old, but obviously it still works. Even with the various accounts of problems, almost every day thousands of flights are managed successfully by the people who run these systems. They’re not alone, as the article also points out that some other transit systems make do with technology that most of us would never think of using for any system.

In early 2024, Microsoft was attacked by Midnight Blizzard, a nation-state threat actor that successfully infiltrated a test system and gained access to many other systems inside the Microsoft network. The initial attack was via a password spray attack (guessing multiple passwords), targeting an admin account on a test system that lacked MFA and robust monitoring.

The trouble with air traffic controllers and the Microsoft attack are two disparate events, but they both highlight that there is a lot of older technology in use, even in places like Microsoft, a supposedly cutting-edge company. I’m sure many of you have some older systems inside your organization, hopefully not running Windows 95 or SQL Server 2000, but I routinely run into SQL Server 2008 inside customers.

There have been a lot of changes since the year 2000 with regards to security inside of computer systems. Many software packages have upgraded their security features and configuration in the last 20-plus years to become more robust. These days it seems that most of the software I use requires some sort of authentication besides a password, with lockouts and limits to prevent hackers from easily accessing systems.

This isn’t to say that newer technology is fool-proof, but it is more difficult for most hackers, especially the script-kiddies who copy exploit code from others, to break in. A lot of attacks can be prevented by simple changes that limit the ability of malicious users from experimenting over and over with your systems, looking for vulnerabilities.

However, quite a few of those security changes require newer versions. Older technology often works and works well. We feel comfortable with it, and if it’s not broken, why fix (or change) it?

I expect a database server to run for 10 years, as it can be hard to find time to constantly upgrade instances. That being said, a ten year old system would be one running SQL Server 2016. Anything older should already be upgraded, with plans to move your 2016 servers to something newer in the next year.

Take advantage of newer technology where you can, and ensure you are patched against known vulnerabilities. If you can’t upgrade, then you should secure those systems as tightly as you can, ensure no accounts on them are privileged on other systems, and monitor them constantly for potential issues. Otherwise, I’m not sure you’re doing a professional job of managing those servers.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

I remember working at a large organization with a team of other IT Operations staffers. We rotated this one job every month amongst a few people, each taking turns, where we’d lose a day to update all the privileged passwords for our servers. This was before Managed Service Accounts and the cloud, when we were required to change these every 30 days and then store the new ones in an encrypted store.

What struck me when I got stuck with this wasn’t the requirement to change every 30 days; that seemed normal. The thing that bothered me was how manual this was. As a former developer, I wrote some scripts to automated this, pre-PowerShell, and make the task easier on my fellow sys admins. I had scripts to generate a password, change it in AD, then print the pwd to be copied into our secure storage (no API there). This ran in a loop so I didn’t lose a whole day to changing password.

These days, we have lots of alternatives to managing passwords, and in fact, much of modern guidance isn’t to require password changes so often. For systems, use an automated process such as an MSA or GMSA. For users, we’ve mostly given up on changes and are trying to get people to use decently long passwords and disparate ones across services.

Modern guidance from Microsoft says to avoid using common passwords (asdfasdf, password1, ec.) and don’t use the same password in multiple places. MFA is also recommended, but the anti-patterns for success are requiring long, complex passwords or frequent changes. Studies show these lead to less security because users do stupid things.

These days, I would guess many of you managing database systems use some sort of integrated security with AD, Entra, OAuth, etc. However, I know there are still places where passwords are in use. Do you require changes often? Do you change any of your passwords regularly?

Security is always hard, and it’s even harder when the recommendations and rules aren’t consistent or even enforced. I don’t know what to do, but I try to use disparate, long passwords and MFA wherever I can. So far that’s worked well.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.