Voice of the DBA

Tag: Database Weekly

  • Liability for AI Errors

    This week there was an article that speculated that doctors in the UK could be liable for errors made by AI tools unless rules are changed. The argument is that AI tools should be treated as products, which isn’t necessarily the case right now. Right now doctors may face all the liability instead of AI tool makers having some responsibility. From my reading, this doesn’t appear to say that doctors aren’t still accountable for mistakes, but they aren’t wholly accountable. The Medical Protection Society wants the technology vendors to bear some responsibility.

    I have to admit I’m torn here. If doctors are using tools, they should be sure the tools work well and they agree with the recommendations or results. However, I think AI changes things somewhat. If I read a medical device, say one that analyzes blood, I expect that the results are deterministic and accurate. If they aren’t, how could I, as a doctor, know that. The companies the built (or maintain) the device would be culpable for errors.

    Using AI assistance, however, is a little different. This is a non-deterministic interpretation of data. In the same situation, if an AI were to interpret blood results and summarize them, perhaps failing to point out a deviation of a value and this impacted patient care, is the AI responsible? The doctor for not realizing there is an issue? Joint responsibility?

    I think it’s unclear. I’m not 100% sure how I feel here, and I lean towards both being liable. If someone is training an AI model to help with medicine, then they ought to bear (and feel) accountable for results.

    This seems different than software engineering to me. In medicine we have humans overloaded and AI is supposed to help, but has to be responsible. I don’t think the stakes are as high in producing software. It’s an arbitrary decision to say we need to get xx work done with yy resources. AI can help, perhaps amplify the abilities of people to produce code, but the people still have to verify the AI results. Any time pressure is a decision we make, not one brought on by medical issues.

    Perhaps this seems hypocritical, and I will admin I’m not 100% sure how I feel, but I’m more concerned with AI technology bearing responsibility in healthcare than software. Do you feel the same way? Or perhaps in either case the AI is just a tool? Let me know what you think,

    Steve Jones

  • The New Wave of Security Threats

    We’ve had quite a few GDR patches for SQL Server released this year. If I glance at the Build Lists I maintain, I see Sept 2025, Nov 2025, Jan 2026, and Mar 2026 GDR patches. That seems rather frequent as the history of builds for recent versions has often seen them without any GDR, out-of-band patches. Just CU after CU every other month.

    That pattern of rare security updates might be changing for lots of software, not just SQL Server. There was an article recently that noted AI tools might start exposing lots of bugs, including security holes, in software that has been around for years. Someone recently used AI found bugs in both PostgreSQL and MariaDB that have been around for years. They are patched, so if you run those platforms, make sure you patch things. The information is out there and someone is looking to take advantage of it.

    Anthropic built a new model, Mythos, which has not been released publicly. It’s been given to a few customers who have used it in testing, and it seems that it might be more capable than expected at finding bugs. Hopefully, we will find out how good it is soon and lots of companies can use it to examine software. It’s certainly a danger as hackers and criminals might use it, but I believe that (responsible) information disclosure is better for everyone.

    This is also a good reminder that you need to patch your systems. I certainly get wary about updating on day 1, but I do try to patch without too much of a lag. There are no shortage of zero-day attacks, but I also weigh the risk of instability from patches of questionable quality. Many vendors do a great job of patches and upgrades most of the time, but “many” and “most” aren’t “all”, so I prefer to let others test early. Someone has to apply the patches on day 1, but I don’t want it to be me.

    Security is getting harder, it’s getting more burdensome, and it’s becoming more important. At the same time, lots of people are building better security with new tools, including AI. Just make sure you apply those patches to take advantage of their work.

    Steve Jones

  • 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