Voice of the DBA

Tag: security

  • The Ransomware Hero

    One of the common attacks against many organizations today is ransomware. I’m constantly surprised when I see friends and they tell me they’ve been attacked, but the incident never made the news. I think many people would be upset with businesses if they knew the extent of attacks, but I also think that this would force more organizations to implement better security if shareholders and customers were aware of the incidents. This might even get employees and others to be more careful about the things they click and do, though that might be wishful thinking.

    In Illinois, in the US, there is a guy that is fighting ransomware and helping out both organizations and individuals. For free, which is much better than paying the fee, something plenty of organizations have done. Michael Gillespie runs ID Ransomware, a site that helps you determine what type of attack you’ve had. It can also possibly give you or generate a key that will allow you to decrypt your files.

    This man does this in his spare time, while working as a computer support person. It’s an amazing story, and one that is a little sad. Here is this man that doesn’t want to charge, and wants to help, but has struggled financially while doing so. Things have gotten better, and more people are supporting his efforts, including Emsisoft, who has hired him part time.

    If you get struck, it might be worth a visit to ID Ransomware and see if you can get some help. If you do, convince your boss to donate some payment to support Michael’s efforts. It’s a good cause, and certainly cheaper than paying a fee or losing lots of work while you try to sort out the problems.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Setting Certificate Backup Permissions for an Instance–#SQLNewBlogger

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    Recently I was testing some security change, and I made a backup of my certificate from one instance. I did this on a share that I’ll use to move the files to another instance. In this case, I had these files in the folder.

    2019-08-23 14_31_13-SQL

    The problem is that by default, SQL Server locks down permissions, as it should. That means that the other instance couldn’t access the files, as its service account didn’t have permissions.

    I fixed this by opening the security tab for the file. I had to do this for each, but I’ll show one here.

    2019-08-23 14_31_22-FinanceCert.cer Properties

    I clicked “Advanced” to get a more detailed view of permissions.

    2019-08-23 14_31_28-Advanced Security Settings for FinanceCert.cer

    Again, I really need to approve this view of the security settings. Once I acknowledge the UAC dialog, I can see this:

    2019-08-23 14_31_38-Advanced Security Settings for FinanceCert.cer

    What I needed to do here was add permissions for another service account. Clicking Add lets me select a principal.

    2019-08-23 14_31_46-Permission Entry for FinanceCert.cer

    For a local account, I need to give the “NT Service” prefix to my account, despite this not being shown as part of the service account settings.

    2019-08-23 14_31_57-Permission Entry for FinanceCert.cer

    When you click Check Names, this will shorten. If you enter this short version, it won’t work.

    2019-08-23 14_32_01-Permission Entry for FinanceCert.cer

    In my case, this account really just needs Read permissions.

    2019-08-23 14_32_05-Permission Entry for FinanceCert.cer

    Click OK, and I see it listed.

    2019-08-23 14_32_10-Advanced Security Settings for FinanceCert.cer

    That’s it. Now my SQL2017 instance can access the backup and create the certificate.

    SQLNewBlogger

    This is something I’d expect most people working with SQL Server on Windows would be easily able to do, but showing some knowledge here gives confidence in your abilities.

    This took longer to get screenshots than to write. You could easily do something similar.

  • Losing The Security Game

    It’s sad some weeks to see reports of security issues at large companies. It’s also discouraging some times when clients or friends will talk about security issues they’ve had in their organization. What’s mostly disappointing is how easy many of these issues would have been to prevent with a little effort.

    Joey D’Antoni made some fun of this with his Data Breach Game. It’s a bingo card you can print out and use the next time you hear about an issue. My guess is most of us could win this in about a week with the general state of security in most places. Some of you might win this in a day with inside knowledge.

    This is poking a little fun at the poor security practices of many places. There’s a wider article about 9 poor security practices you can read, with some notes about what you should be doing instead. When you read it, you’ll wonder why hasn’t someone just made these simple changes and dramatically improved security? I have asked myself that many times when I’ve seen some environments.

    Ultimately, no one wants bad security, but we (as a group) often make poor choices because we’re in a hurry. We can, and should to better. All of the items on this list can be avoided, and should be. Even the complexities of SQL Injection can be fixed with a little code refactoring. No time or that’s too hard? You should be building software in a Compliant Database DevOps manner.

    I like the list, though I wish ElasticSearch where on there in number 6 with MongoDB. Too many breaches this year from people dropping that server on their network without a password because they need full text searching of data. Don’t make that mistake. Always, always, always set a password on data resources. Developer or partner complaints aren’t worth the risk of losing data from an unsecured server.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • More Network Restrictions

    This past year has seen quite a rise in ransomware attacks. Certainly some big ones (Baltimore, Florida) are reported in the media, but there are lots of smaller ones that don’t make the news. As I’ve been attending some events in the last couple months, I’ve talked to various people that disclose they’ve had ransomware issues. Most of those didn’t make the news, but the events did cause IT staffs to scramble, work long hours, and forgo other tasks that might be improving the organization or helping customers.

    We know that there will be attacks on our organizations in the future, and some of them may be successful. Almost everyone is regularly attacked, though most are repelled with simple firewalls and better coding to prevent SQL injection. There are other things we can do, and certainly other groups in IT that need to worry about systems, but I suspect we’ll start to see one more change in how we work.

    Recently I was accepted to speak at SQL Saturday Memphis and really enjoyed the trip. However, when practicing one of my demos early in the am, I had trouble connecting to some remote resources. It wasn’t obvious what the issue was, and since I wasn’t in control of the endpoint for demos, I worried that the instratructure had an issue. Not what you want to see on a Saturday before a demo.

    Eventually I narrowed this down to port 1433 being blocked. Not a big deal as I had a VPN, but certainly something to be concerned about for a database professional. However, then I thought about the ransomeware and other security issues many organizations have had. Maybe some restrictions are a good thing.

    I wrote about networking segmentation, as did Joey D’Antoni, and I think this is where we will move in the future. After the SQL Slammer worm, plenty of organizations changed networking policy to hide port UDP 1434, which was good. I think some have gotten lazy, and the security issues we are seeing today might change things.

    That’s going to mean less access for people to connect to machines. That also means we need to think about DevOps style automation pipelines for code. We need to learn more about how to let machines run scripts for us and limit access. That way if our machine is attacked, we won’t necessarily be able to spread the issues to servers. We’ll still have plenty of other machines that might get hacked, but hopefully we can protect our servers.

    Security has become a bigger part of the job for all IT pros, and certainly critical for database pros. I hope that most of you embrace more stringent security and not try to circumvent it. Use automation, proxies, and more to keep your systems secure. And if they don’t quite work as you’d want them to, learn how to adjust them and work with the system, not against it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.