Voice of the DBA

Tag: security

  • Ransomware and DevOps

    Ransomware.

    A scary topic and one attack that is apparently more common than I suspected. Before you go further, if you haven’t restored a database backup in the last month, stop and go verify your DR plan works. That’s one of the overconfident issues facing lots of government and businesses. While this might not help your entire organization, at least you’ll have some confidence in your process and that you can recover a database.

    This is a great article from Ars Technica and worth reading: A take of two cities: Why ransomware will just get worse. I’d recommend you read it and think about a few things. First, do you have insurance because things (or substitute your own word here) happen? Second, have you really tested a DR plan for some sort of software issue like this? You might think about a way to restore systems in an air-gapped manner that prevents them from re-triggering encryption from a remote source, or maybe even in a scenario where you reset dates/times to prevent timer triggered issues. If you don’t think you need to, read this article as well.

    Perhaps the bigger issue is are you actually patching and updating systems? Too many organizations can’t, don’t, or won’t. The former means you aren’t sourcing software properly. Either you’re using vendors with poor practices or have a poor development process. Organizations that don’t or won’t bother prioritizing patching, especially security issues, are likely those that will have issues as more criminals spread and use ransomware and other attacks for profit. Software and environments continue to be more complex, which means that the less you ensure the system is patched, the more likelihood there is of a vulnerability in your environment.

    DevOps and the cloud PaaS/SaaS platforms are attractive for a few reasons. One is that the platforms are constantly kept up to date, forcing you to move along with them. SaaS cloud vendors know this and are constantly patching and updating their software in order to keep it running. DevOps asks that we always have the ability to release, that we have the ability to patch on demand, not only at certain intervals. This is something I try to emphasize when talking about DevOps. It isn’t necessarily about velocity, but it is about being able to release when you need to, whether that’s today or next month. This is especially important for security issues.

    I have had hope for a long time that insurance would drive software to higher quality, and I still do. With the attacks and issues of ransomware, and who knows what other techniques that will be developed, I still believe more companies will buy insurance. I then hope, because of selfish motives, the insurance companies will require frequent patching, regular vendor certification of new platform versions, and better development processes. If insurance drives DevOps, I’m all for it, but I’d prefer you decide to adopt it yourself and start making changes today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The Road to Better Data Handling

    Recently I was on an internal communication thread with multiple people at Redgate Software. We have various ways to keep our (semi-) distributed teams in touch with one another and handle issues. While email works, I think many people like Slack better for quick discussions. I appreciate that as a remote worker since I’m not around to hear a conversation around a desk. To be fair, with a busy staff, others often aren’t as well, so a thread in Slack often saves details others can see later.

    In any case, we had some issue. I don’t know if this was a product issue with a customer or a communication item for our marketing group. No matter what it was, we had someone mention they could help if the first poster would provide details. The next message that I saw was great. It said something along the lines of

    “Please do not post email details in Slack.”

    A gentle reminder, but one that was needed. It’s great that we want to help others and work through problems, but in many companies we’ve played far too fast and loose with data. Not necessarily technical people, but often our customers have. Many of them will put sensitive information in “notes” fields in our databases. It’s a hassle when we want to work with data that hasn’t been put in a normalized space and must extract it somehow.

    It’s also a source of data leakage. While we might appreciate saving a quick note, these aren’t secured communications, and more importantly, they provide yet another attack vector for problems if we lost control of the backups, archives, etc. Even worse, we could have gotten a request to remove emails and we now have another security risk with the email email searchable in old Slack messages.

    This is likely a bit of an extreme example, but still a place where data handling should be better. We have secure systems for tickets or issues where we can store data. Or we can reference their information in another way. I’ve started doing this in GitHub, where we often log issues for SQLServerCentral users. Rather than putting in an email, I’ll put a user ID or other identifier. If the user wants to delete their account, I don’t want their email floating around anywhere it isn’t required.

    While it might be a bit more hassle to be careful with personal information, I think it’s much better than treating it as unimportant and potentially having it disclosed in some security incident. Whether it’s my email, tax ID number, or credit card, I’d want my own data handled carefully and am trying to do the same for others.

    Steve Jones

    Listen to the podcast at Libsyn

  • Spread the Word about Basic Security

    I went with my daughter the other day to set up her bank account. She’s now an adult and this is one of those items we need to get done, especially in today’s world of electronic banking and money transfers. It’s time she takes another step towards being responsible and accountable for her finances.

    As we went through the process, one of the steps was her setting up an account with the online presence of this bank. I told her to be sure to use a new password, one not in use anywhere. She agreed, but then said she has 3 or 4 passwords that she uses in different places. I told her that’s not enough, and explained why. There is an interesting article about a MySpace security flaw in 2017.

    Most of you don’t use MySpace, but you might have. Even if you haven’t, your kids or parents might use some popular tool, such as Facebook, Snapchat, Instagram, etc. Tomorrow we might discover a similar security issue, or worse, a disclosure of your passwords. If you think it can’t happen, go try a few emails over at https://haveibeenpwned.com. You might be surprised at the results. My kids were.

    It’s not that your bank is necessarily vulnerable to hacking a password. However, if you’ve used the same (or very similar password like PasswordCNNdotcom) for your news reading at CNN, then if that company is hacked, it’s not too difficult to take all emails  and then try PasswordChasedotcom at Chase National Bank’s site.

    Reusing passwords is a bad idea. I do it for demo accounts across virtual machines, and even that bothers me. Everywhere else, I use a password manager and I have hundreds of passwords, separate ones for each site. My wife is annoyed if she needs a password for any of our accounts and I give her something like “4Gbv8A^f8” on my phone, but I’m not going to make simpler ones or reuse them.

    Separate accounts and separate passwords are a mantra I’ve used for years at work and at home. Please spread the word and get those in your life to use separate, strong passwords for their online activities.

    Steve Jones

    Listen to the podcast at Libsyn.

  • High Prices for High Security

    I was excited to see the new Secure Enclave technology come to Always Encrypted (AE) in SQL Server 2019. I’ve thought that the way Microsoft implemented the AE technology in SQL Server 2016 was a start and a good step forward, but it had too many restrictions. Kind of like Availability Groups in 2012 and In-Memory technology in 2014. A good idea, but not really ready for most of us to use.

    One of the biggest restrictions in SQL Server 2016, in my opinion, was the inability to run range queries on encrypted data. These are the greater than, less than, and LIKE items that many of us need to use in applications. This made sense, since the server doesn’t know how to decrypt the data, but many applications need these queries.

    That goes away in SQL Server 2019 with Secure Enclaves. I’m looking forward to testing and working with this, but there’s one interesting limitation for me. The SQL Server computer that runs the secure enclave must meet one of these requirements. It has to run on Windows 10 or Windows 2019 Server – Datacenter Edition. There also has to be an HGS server for attestation, but this can be a WS2019 Standard Edition.

    Is it a big deal? I don’t know. Windows Server 2019 lists  with Datacenter at $6155 and Standard at $972. That means it will cost me $5,183 for Always Encrypted on my SQL Server. Not a bad price for the encryption and additional security. An HSM appliance goes for quite a bit. One in Azure is $5k + $4.85/hour and most of the enterprise appliances I’ve priced at $10k+. And you need two.

    In some sense, maybe this doesn’t matter. The cost of $5k isn’t much, especially when you consider the downside of not using encryption and having a data breech. You don’t need this on all SQL Servers, just those that need AE, and even then you can run SQL Server Standard Edition. The cost of core licensing is likely going to already be quite a bit and this is just like having to pay for a few more cores. Is this an impediment for your organization?

    At first this seemed like a burden, but the more I look at it, $5k isn’t a lot for encryption on your server. I hope this doesn’t deter organizations from adopting AE, and more importantly, I hope Microsoft continues to invest in this technology. I’d like to see multi-certificate support and the ability to easily revoke access for a compromised system while I deal with any security issues. There are other things, and we’ll see how this evolves in the future.

    Steve Jones

    Listen to the podcast at Libsyn.