Voice of the DBA

Tag: security

  • A Cloud Dependency Failure from Amazon

    I went to sleep while reading a Kindle book on my phone. I know because my hand dropped and the phone knocked me in the forehead. I set it on the nightstand and went to sleep again.

    I woke up and was planning on reading for a few minutes before starting my Monday. When I opened the Kindle app, it asked me to log in. When I did, Amazon said my account was locked and I needed to check an email. I did, and found one from Amazon.co.uk questioning a purchase I made and asking for me to very an order number and the last 2 digits of a card to charge.

    I wasn’t sure what to do, but since my wife was complaining about her Audible account, I knew I needed to do something.

    I didn’t like the email for multiple security reasons, including not giving me a way to verify the email online. Checking Amazon’s help page said I should have a link in the email to a form. Even when I called the Amazon help line, they said I should have a link when I logged in to do so. I didn’t on either the .com or .co.uk sites, but Amazon Customer Service eventually unlocked my account.

    I wrote about Dependencies in today’s editorial, inspired by this story and the Reddit story linked in there about losing access to Claude. That’s scrary, especially in this new automated world where AI agents might be examining activity and undertake this type of action to prevent other issues. It’s an overreaching type of judgment that starts to expose the dangers of a highly interconnected world.

    I get Amazon might want to ensure my purchase was legitimate and perhaps prevent future orders, but also locking my content away (books, movies, audio, etc.) because of a shopping issue seems extreme.

    It’s certainly my issue, and I’m not sure how I untangle things for the future, but it does make me think about limiting dependencies a bit more in the future. Or at least understanding the dangers of too much on one service.

    Whether that’s the books I read or the services my company gets from any one vendor.

  • Local Agents

    Recently I saw an interesting article, saying that someone could build a general purpose coding agent in 131 lines of Python code. That’s a neat idea, though I’m not sure that this is better than just using Claude Code, especially as the agent still uses the online version of  the Claude model from Anthropic to generate code or perform other tasks. There’s a video in the article showing how this code can be used to perform some quick tasks on a computer.

    However, the code isn’t specific to Anthropic. It can be used with any LLM, and I started doing just that, with a copy of the code from the article, but modified to use a local AI LLM running under Ollama. You can see my repo and feel free to download and play with it. It’s expecting a local LLM on 11434.

    I’m a big fan of local agents for a variety of reasons, but mostly because I know humans tend to do dumb things. Especially with new technology, and maybe even more especially in development areas.

    That includes me.

    I’ll take shortcuts. I’ll give an agent sysadmin on a dev database to try things. I want to be able to experiment, learn, and see what works. I want to learn how to use tools and fail using them. That’s how I get better. That’s how I get better in sports, in music, and in technology.

    And that’s not a project I can take time to work on. I don’t get to dedicate time to just learn and then go back to work. Work never ends. It’s a grinding, constant, continuous treadmill of things I need to deliver to others. I have to learn to experiment around those deliverables when I can find spare moments.

    With AI, that means we’ll do things that get InfoSec teams to cringe. I get the concerns over data transiting networks and going to who-knows-where to be used who-knows-how-by-others. I appreciate business subscriptions that guarantee that data won’t be used, but I also want extra safeguards at times. That means local models. Not necessarily on my laptop, but in my data center.

    Plus, that way I (or my org) can control the costs and manage expectations.

    I hope local models and local agents catch on, I hope more vendors support them and more organizations are willing to run them. Even in something like AWS Bedrock or Azure Open AI or Vertex AI. Then I can rent the latest and greatest hardware, but have more control over how my organization uses it.

    Steve Jones

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

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

  • 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