Voice of the DBA

Tag: security

  • Microsoft Security Changes and SQL Server

    For almost as long as I’ve been working as a data professional, NTLM has been the security protocol used in Windows. Microsoft added Kerberos over 20 years ago, but NTLM is still a fallback. Like so many things Microsoft has worked on, they loathe breaking backwards compatibility, so NTLM has been available. However, it has issues, like the double hop problem, and there are numerous security issues with the protocol. I tested a security product over 20 years ago that could break NTLM passwords in under an hour. On old Pentium-based computers.

    This week Rebecca Lewis posted an article about the upcoming changes in Windows where NTLM is being phased out. She audits various clients and finds many are still using NTLM for SQL Server connections. Her observation is many people aren’t aware of this, and I’d concur. There is an informational message that is written to the SQL Server error log, but how many of you are checking the log and acting on this or even understand what it means? How many of you might have developers (or yourself) using named pipes and be unaware? That’s an NTLM only connection.

    Heck, I’ve got a friend fighting through SSL connections with SQL Server, which is something I rarely seen. This person will eventually no longer need to “trust server certificate” in every connection string, but I bet many of you are years away from implementing that. That’s another change Microsoft wanted implemented, and why modern drivers no only set this to true by default.

    Later this year, NTLM v1 will phase out, but that’s not likely what most of you use with SQL Server. However, the next major Windows server release will disable NTLM v2, and you won’t remember this editorial or the announcement then. What will happen is Windows admins will upgrade systems and you won’t be able to connect.

    Rebecca gives you some things to check, but since many of you might work in large estates, you’ll need time to ensure clients and servers get updated and NTLM isn’t the protocol you depend on. Trust me, if Windows or even a client driver upgrade remove this, you are in for a bad day (or week, or weeks) trying to get things working.

    I’d also suggest you learn how SQL Server SSL connections work. I don’t know that many orgs will require this, but some might as security becomes more automate-able and more CSOs start to ask that we ensure no man-in-the-middle attacks reach our servers.

    Steve Jones

  • No Defaults Passwords Ever

    I appreciate default passwords on systems. Often, for routers or other devices, I might need a way to connect initially. Or, if I perform a hardware reset, I want some password that I can use to reconfigure things. However, I am pretty good (not perfect, but really good) at changing those passwords to something else. It drives my wife slightly crazy at times, but I save the passwords and stick them in a manager I share with her periodically.

    SQL Server doesn’t store a default password when you install it. If you enable the sa account, you need to create your own password. I primarily deal with containers, and I always set one, usually my own default. However, lots of software either allows a blank password or has a default password set on installation. Oracle even lists theirs in docs. That’s not the worst idea if sysadmins change them, but if they don’t, it’s a threat vector for attackers. I was working with a customer last year who had an Oracle database. I asked them to try a default user/pwd as a test and it worked. I think my head was slowly shaking for the rest of the call.

    Recently, Silicon Valley saw the result of a default password not being changed when someone hacked the crosswalk signals and uploaded fake audio files that played when the signals changed. The vendor (not surprisingly) advised the city to change the passwords to something strong. A somewhat harmless prank, but it’s possible that someone might have made a more nefarious change.

    It’s 2026. We know there are people out there with malicious intentions, as well as those whose prank goes sidesways and have unexpected side effects. There isn’t a good reason to keep default passwords anywhere, including in your own personal devices. These days, connectivity among many systems is a reality with network, Bluetooth, NFC, and who knows what other connections are possible. Your personal devices ought to have defaults changed for your own protection.

    Inside organizations, it can be worse as the weakest link can be exploited to gain access to other systems. Quite a few hacks started in test systems and progressed to accessing production data. Even places we might not expect to be problematic, such as version control systems, have been used by hackers to gain access.

    To me, finding a default password is worthy of a reprimand and a note in whoever’s file forgot to change it. A second offense ought to lead to a suspension at a minimum and possibly termination. This is such a low bar of required security that I can’t think of a good excuse to allow it anywhere.

    Steve Jones

  • Minimally Viable Security

    Security has been a constant concern for many IT professionals over the years. Many of us are trying to implement better security controls, and yet at the same time, we try to avoid anything that slows us down. Security clearly hasn’t been a big enough concern, as we’ve had more than our share of SQL Injection issues. These often come about from poor practices, lack of education, and too many people not learning to adopt better habits across time.

    We’ve also had no shortage of lost backups, open cloud buckets, and more over the years. While security (or cybersecurity) is listed as a concern for tech management, they are quick to avoid slowing down any development or deployment of software. While it is easier to get time for patching these days, it’s still not easy. There are plenty of organizations that prioritize resources spent on tasks other than patching, upgrading systems, or training developers.

    One of the ideas in modern software development is to often build an MVP, a minimally viable product, where we can test ideas and determine if our solution is worth pursuing. This could be a greenfield application, or even a feature enhancement to an existing system. In the age of GenAI, vibe-coding, and more, this might be MCP or agent-based AI additions to software that are being developed and enhanced rapidly, incorporating feedback from customers.

    If we allow minimal amounts of features to test things, shouldn’t we have minimal levels of security as well? That’s the thrust of a blog post from Forrester that discusses how we might look forward in 2026 to protecting our digital systems. There ought to be a minimum set of controls, testing, and more that ensures we can build software that doesn’t cost more from security issues than it generates in revenue. This might be especially important in the age of GenAI-coding where we can have less experienced engineers or even helpful agents committing lots of code they expect to deploy to production.

    Education is important here to ensure everyone is aware of your MVS (minimal viable security) before they get too far along. It might be especially important in helping others guide their GenAI tools to ensure security is being considered early on. Adding in security requirements as a standard for your tools, such as in a Claude.MD file is a best practice that should be required for all future software development. You never know who might start to add AI coding tools or agents to your codebase, so be prepared now.

    Education isn’t enough. It’s too easy for someone to forget what they learned. It’s also easy to assume many people have learned something when they haven’t. To me, part of an MVS is ensuring you have a framework or platform that can test all code and ensure that your systems are being securely built and deployed. This includes third-party software, especially SaaS products, where vendors might be tempted to sell you their own MVP without any MVS.

    Steve Jones

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

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

  • Your Security Checkup

    Recently I saw an article on Simple Talk, 15 Practical Tips for Securing SQL Server, and I thought that many of these are fairly simple things. Turn off unused features, disable sa, etc. These are things that a lot of people probably ensure are in their SQL Servers builds.

    Though, I’m sure a lot of people don’t bother.

    Often, I’ve found that different people might be responsible for setting up servers, or they might have rights to change things on existing servers. Over time, what we thought of as a standard often isn’t standard on all instances. Exceptions creep in, perhaps because developers change things when they don’t know better or aren’t thinking of security. Vendor software might have some  unexpected requirements for similar reasons that deviate from our standard. We also might change our own standards over time and forget to revisit existing servers.

    I wonder how many of you have a security audit procedure in place to re-examine your existing servers. It’s something that ought to be done periodically, like storage management. It isn’t needed every day or week, but a few times a year you might want to ensure things are set appropriately and ready for the next few months.

    I’ve been surprised at the number of people that really like the Redgate Monitor Configuration page to keep track of their servers and the deviations their own standard config. It’s also been interesting how many people upgrade to the Enterprise Edition to get the Security features. Tracking these over time can be a pain DBAs want an easy way to do this. In fact, there are so many feature requests for enhancements to security tracking that the devs on RGMEE are very busy.

    It’s getting to be the end of the year, and that’s a slower time for many of us. Unless your business is related to the holidays, a lot of people take vacation, we have code freezes, and there’s a little more time for housekeeping. This might be a good time to conduct a little security audit and ensure that your servers aren’t open for attack or making it easy for malicious actors, or naïve but well-intentioned coworkers, to get into systems.

    DBATools is a great way to do some changing or enforcing of standards across lots of servers. Even if you can’t change all the settings, you might ensure you have documentation on why that one instance has an sa account enabled. You might also ensure that your security people have signed off on any exceptions.

    If nothing else, a good security checkup should include checking your versions and getting up to date on patches.

    Steve Jones

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

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