Voice of the DBA

Tag: security

  • 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.

  • We Should Demand Better

    I ran across an interesting open letter. Most of these are from individuals, often complaining or lamenting on the way something in the world works, or maybe doesn’t work.

    This latest letter was from the Chief InfoSec Officer at JPMorganChase, a large worldwide bank. This open letter was written to the software suppliers looking to do business with JPMorganChase, especially those in the SaaS area (Software as a Service). The letter opens by noting that SaaS is enabling cyber attackers and asks for three things: prioritize security over features, modernize security architecture, and work with security collaboratively to prevent abuse of connected systems.

    It’s a good letter. It talks about the problems at a high level, but is specific enough to recognize problems. Software is often delivered as a SaaS type application, even when there might be local components. For example, I lament Postman working this way, as it now seems to now require me to be connected in order to work. That’s something I learned while trying to get work done on an airplane, and I couldn’t get to any of my queries as I didn’t have wi-fi, despite the application running locally on my laptop.

    The threat of more attackers is amplified by the connectedness of new systems, new agents, and new protocols that allow a breach to escalate deeply inside systems. This is something we’ve faced in the past, but not at the scale that we face it today. Automation has become embedded in the computing world, not just inside organizations, but also inside hacking organizations. Malicious actors can and do use scripted attacks at a rate that we haven’t experienced in the past.

    I wish that most people purchasing software would prioritize security when making a decision, but often price and expediency outweigh anything else. While I do see many companies asking for security information, too often the requests are at high levels, and vendors can word their answers in a way to satisfy the screen without actually improving their own security coding and architecture.

    I do think the authorization and authentication of users is improving, so I have hope that more patterns and frameworks are published and widely used, and we’ll see more consistent security throughout software. Now, if we can just ensure the authors of those platforms do a good job of security, we might see the request from JPMorganChase come true.

    Steve Jones

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

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