Voice of the DBA

Tag: security

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

  • The Security of Old Tech

    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.