Voice of the DBA

Tag: security

  • Ransomware May Get Worse

    I’ve never had to deal with ransomware, but across the last couple years I’ve been surprised how many friends and customers have dealt with this. For those that are prepared, it’s a time sink and a hassle. For those that aren’t, there is the addition of finger pointing, anger, fear, and often lost data as well.

    I hope things don’t get worse, but I think this might be a sign they are. There is some speculation that criminal groups are working together, in a sort of computer hacker cartel. Apparently four criminal groups announced they would be working together. If that isn’t a sign of the craziness of the world, I don’t know what else would be. Criminal groups announcing they are collaborating? Apparently they must think they are businesses like the targets they attack.

    There has been some investigation, and there haven’t been signs this is a cartel, with no revenue sharing or coordination, but the fact that they are cross posting data and sharing techniques is bad enough. Helping each other out may help them find more targets and develop better techniques to get around security.

    The one concern I’d have with all of this is that these different groups may attack the same companies. Can you imagine getting through an attack, either paying a ransom or not, only to be attacked again? I do think that organizations ought to be worried about their security against ransomware, have good, air-gapped backups, and ensure if they are attacked, they plug any holes in their systems.

    Surviving one attack might be hard for an organization, but if there are two or more, I suspect someone’s career will be in trouble.

    Steve Jones

  • Removing SA from Azure SQL Database

    One of the recommendations from Microsoft SQL Server is to use Windows authentication. This has been in the docs for years, and I’ve heard many MS consultants and employees note this. Many customers and clients have tried to use Windows Authentication only, but often in a cross platform environment with Java or Linux clients, one usually has needed SQL authentication with a user and password. Client libraries have been enhanced so this isn’t necessary, but still some people prefer SQL authentication, especially with clients outside their organization. It’s simple, easy, and developers can make it work in seconds.

    With Azure SQL Databases, some companies defaulted to a username and password, as their Active Directory (AD) wasn’t extended to Azure. That has become easier to do, and many people are taking advantage of it. In fact, some customers are so integrated, they want to do away with usernames and passwords in Azure.

    Microsoft has listened, and is giving them the option. The feature is in preview, but if you enable this, SQL auth is turned off, which means whatever administrative account you set up for the server with a name and password will not work. That’s essentially the “sa” account, though with your own custom name.

    While this feature won’t be useful for everyone, it’s a good option to have. As more companies look to tighten security and limit the attack surface area, being able to make this choice is important. It’s also something that architects and administrators should be aware of and consider in their decisions on how to implement applications in Azure.

    Steve Jones

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

  • Shared Security

    When I worked in a large Operations team, we had various passwords for some systems that we stored in a password vault. This was on a network share that only the administrators had access to read. We used this for keeping a number of passwords for various services and systems that required sysadmins to access.

    However, we tried not to use shared accounts whenever possible. We wanted to ensure an audit trail, for both compliance and understanding of what happened in our environments. All sysadmins had two accounts, which allowed them to access most services. We only had a user/password stored for certain systems that needed some sort of separate account, and we did change those passwords regularly.

    Our customers didn’t always do this. In fact, I regularly found different groups using a single account, always logged in, for which everyone knew the user name and credentials. They never seemed to consider this a problem, despite regular security warnings from administrators.

    I was reminded of this story about a water treatment facility in Florida that was hacked. They had a shared account, used by many people, the same password for everyone, and a lack of a firewall. An intruder caused a release of chemicals, but no one was injured.

    Firewalls prevent a lot of issues, if they are configured to limit access. In addition, ensuring that each user has different passwords is important. This allows you to turn off access for certain people, which includes former employees. That’s basic security, and I’m surprised how often people forget about this, often because they worry about some system breaking.

    The tools we have to enforce stronger security have improved over the years, but we need to take advantage of them, and we need to ensure that good, if not best, security practices are followed. It’s easy to become lax over time, but remember that there are lots of threats out there, from hackers to malware, to former employees.

    Far too many people are attacked, more than are in the news, so don’t get complacent. We are all at risk.

    Steve Jones

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

  • A Bug or a Vandalism Opportunity

    I hadn’t heard about this problem at all until I saw a story recently. Apparently a one line command can be hidden inside a Windows shortcut file, a ZIP archive, batch files, or various other vectors. This command can trigger hard drive errors that corrupt the device.

    Yikes. A researcher apparently has been trying to draw attention to this since August, but it has not been fixed. What is scary is that this issues can be exploited by tricking standard accounts in Windows, not just privileged ones.

    However.

    It’s not really a big problem. I asked around and someone sent me a few links that this doesn’t actually corrupt the drive, but just gets Windows to report this. In that case, this might not actually do anything, but it certainly would cause my blood pressure to rise and my heart to skip a beat. This also might be a great phishing vector.

    If you get a message about corruption, check that it’s actual corruption and not just the report from a shortcut or link that uses this message. Certainly, be careful about what you click.

    And if you’re thinking of playing a joke on someone, this isn’t a good choice. This is more like vandalism than fun. I certainly wouldn’t be pleased if you did this to me.

    Steve Jones

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