Tag: security

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.

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.

I remember working at a large organization with a team of other IT Operations staffers. We rotated this one job every month amongst a few people, each taking turns, where we’d lose a day to update all the privileged passwords for our servers. This was before Managed Service Accounts and the cloud, when we were required to change these every 30 days and then store the new ones in an encrypted store.

What struck me when I got stuck with this wasn’t the requirement to change every 30 days; that seemed normal. The thing that bothered me was how manual this was. As a former developer, I wrote some scripts to automated this, pre-PowerShell, and make the task easier on my fellow sys admins. I had scripts to generate a password, change it in AD, then print the pwd to be copied into our secure storage (no API there). This ran in a loop so I didn’t lose a whole day to changing password.

These days, we have lots of alternatives to managing passwords, and in fact, much of modern guidance isn’t to require password changes so often. For systems, use an automated process such as an MSA or GMSA. For users, we’ve mostly given up on changes and are trying to get people to use decently long passwords and disparate ones across services.

Modern guidance from Microsoft says to avoid using common passwords (asdfasdf, password1, ec.) and don’t use the same password in multiple places. MFA is also recommended, but the anti-patterns for success are requiring long, complex passwords or frequent changes. Studies show these lead to less security because users do stupid things.

These days, I would guess many of you managing database systems use some sort of integrated security with AD, Entra, OAuth, etc. However, I know there are still places where passwords are in use. Do you require changes often? Do you change any of your passwords regularly?

Security is always hard, and it’s even harder when the recommendations and rules aren’t consistent or even enforced. I don’t know what to do, but I try to use disparate, long passwords and MFA wherever I can. So far that’s worked well.

Steve Jones

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

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

I read a piece recently that got me thinking that data breaches might be inevitable. Disclosure: This was written by Redgate, for whom I work, titled “Data breaches May Be Inevitable—Compliance Failures Don’t Have to Be“. It’s based on our research with the State of Database Landscape survey as well as feedback and conversations with customers.

The thing that caught my eye was the first part: data breaches may be inevitable. Do you think that’s true? Are we doomed to lose data in our organizations, not as a possibility, but something that will happen at some unknown time in the future? Those of you who have suffered breaches might agree with this, but for those of you who haven’t had to deal with that situation, are you resigned to it happening at some point?

I’ve gone through phases in my career. In a few jobs I worried about this. When we started SQL Server Central, we were very careful and cautious, trying to be sure we wouldn’t be caught losing email addresses of the community members. We never had an issue, and I’m proud of that. These days at Redgate, I worry a bit more, mostly because we’re growing and it only takes one person to click on a phishing email to cause problems. Fortunately our IT group is on the ball and even conducts plenty of “mystery shopper” email campaigns to test our awareness with follow-ups to help ensure people are aware and careful with how we handle data.

The criminals always have an advantage in that they are focused and only have to take advantage of one mistake to win. We have to constantly be vigilant, across all our staffers and systems. Simple mistakes, or worse, typos in complex configuration files could result in a data breach. One of the places this can happen is in test/dev environments where more people the make changes. If we have sensitive data in those places, we’re increasing our risk.

I don’t think breaches are inevitable, mostly because companies are getting better at simple security measures and reducing the ways in which unauthorized access takes place. There’s also the fact that the world is huge and there are more and more systems all the time, which might reduce our chances of the criminals targeting us. Don’t get complacent, as automation gives criminals a tool to attack us at scale, in the same way it lets us get more done with less.

One criminal can do a lot of damage, so remember that the next time you’re annoyed by your MFA or other security measures.

Steve Jones

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

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