Voice of the DBA

Tag: security

  • Defending Against Ransomware

    I don’t manage production systems at Redgate, and I’ve not seen us have any disruption in the access to systems across the last few years. At a number of events, however, I’ve spoken to friends that have told me about the problems they’ve had with ransomware. I’ve been quite surprised how often this happens, as I see headlines, but none of the half dozen or so people I spoke with have worked at any company in the headlines. This is likely a bigger problem than I thought.

    I don’t know if you’ve been attacked, but you should be prepared. Denny Cherry has had to deal with this at at least one client, and he wrote a few things down in this article. He doesn’t necessarily recommend you pay, though that’s certainly an option. If you do, you should be prepared for future attacks or other issues. Anyone that wants to hold your data hostage once might be inclined to do it again.

    Apart from backups, air gaps, and other preventative measures you might take, including limited access between some workstations and servers, you ought to be sure you can rebuild systems that work in a similar manner to the current ones. Do you know what the specs and settings are for all your systems now? So many people assume they could just go get that information from the system itself, but what if you VMs and VM host are compromised? What if your monitoring system is encrypted? Do you really know all the settings that have been changed from defaults? If your DR plan somewhere outside the network and can you get to it?

    This is a good reason why DevOps and infrastructure as code (IaC) are important in a modern organizations. In these cases, a VCS can hold the data you need to rebuild systems. This is a good reason by using GitHub or some remote VCS might be better than self-hosting your code. If you routinely rebuild systems for dev/test, you’ll have some idea of how to deploy, and if you think about IaC as a part of your DR process, you should be able to redeploy on new hardware (or existing hardware that’s wiped clean).

    Ransomware is a part of the new world we live in, and we ought to be prepared to defend against it. Ensure you’re ready today, because there will likely be a ransomeware or other types of attack in the future. The more prepared you are with better practice now, the more likely you’ll be ready to adapt to some other security need in the future.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Remote Data Challenges

    With many of us working remotely now, security is going to be a concern for many organizations. While some might have company provided hardware, many of us will use our personal equipment to connect to data and systems. This brings even more challenges to ensuring security than we’ve had in the past. This might be especially true for organizations that have (or are) scrambling to get everyone connected and ensure access.

    There are a number of areas in which this might affect us as data professionals. First, we should ensure our devices are patched. Windows, OSX, Android, iOS, whatever platform you run, you ought to be properly patched. This might be especially disconcerting for some home users that run older versions of host platforms. This might be especially true for networking stacks, which have grown more secure over time. It is important for most of us, especially when using privileged accounts, to have fully patched devices.

    There’s also the issue of viruses, ransomware, and more transiting from home systems to work platforms. I know some companies are doing lots of work through remote access, but that’s not practical for many of us. I do think the idea of separating out traffic to production systems is a good one, and requiring some sort of remote terminal to a jump box might be preferred. Having some sort of PAW is a good idea as well, though not always easy to set up, especially right now.

    There are still the actual access rights and least privilege principles we want to maintain. Even as people struggle to get work done remotely, opening up all resources to users that want them can be a poor choice in many companies. We want to maintain adherence to good practices while working in an unfamiliar environment.

    There is also the idea of good data protection. This piece talks about DR and data protection, something that many of us data professionals think about regularly. I don’t know if organizations want to add home machines as remote backup targets, but we should certainly ensure that documents, code, and other information is protected. Workstations and laptops are going to fail, as we want to minimize data loss. Having version control for developers and default save locations that are remote are good practices for remote work. I know I keep most of my data in remote git repos, Dropbox or OneNote drives, or some other shared location that will persist if my hardware has issues.

    While many of us try to keep moving forward at work, and our management certainly wants us to do so, we should keep in mind the security and data protection are still important parts of our jobs.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Mongodb Encryption

    The last decade has seen a number of new database platforms get implemented in a variety of organizations. Most of the newer popular platforms have been NoSQL (Not Only SQL) products, and one of the first that became quite popular was MongoDB. I first ran into a few customers using this platform around 2012/2013. At the time some customers inquired whether we had any products to help with development. We did, somewhat, as we invested in 3T.

    MongoDB has enjoyed a lot of popularity and set some standards for how to store and retrieve data. CosmosDB (and other products) has API compatability with MongoDB, precisely because of its popularity. While I’m not sure MongoDB is the replacement for your RDBMS, I’m sure it has places and problem domains where it shines. I’ve also watched the product improve and grow to meet the requirements and desires of more customers. One recent addition was field level encryption.

    MongoDB has had storage level encryption, similar to TDE in SQL Server. It also has had transport encryption (think SSL network protection). This new feature is more like Always Encrypted (AE) in SQL Server. Clients can perform the encryption and decryption, assuming they have the keys. This isn’t quite like AE as it appears to need code changes, but it does protect the data from system administrators, which is a concern for some applications and industries.

    How well does this work? There certainly is a challenge with managing keys, distributing them to clients, revoking them, and more. All of these are the same challenges more encryption technologies have to deal with, including AE. This is a good addition to all data platforms, which ought to enable encryption, but having, or even using, the encryption, isn’t a panacea for the problem of protecting data. We need lots of other things to be designed, implemented, and operated securely.

    I’m not a big fan of MongoDB, but it’s a fine platform, and it likely works well for some organizations. I’m glad that it continues to enhance its security capabilities, and I hope that anyone implementing it enables all that they can. Too many installations in the past haven’t had good security, and that’s a problem. If you manage data, secure your system, and be sure you continue to monitor the platform for security issues and keep learning more about how to best protect your data.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Hiding Data Isn’t Always Easy

    There is an article about redacting data in a report done poorly. A consulting firm hired by Frontier Communications wrote a report and redacted lots of information. However, they apparently didn’t do a good job as all the information they blacked out could be read if the data were copy and pasted elsewhere. Something that’s much easier in digital reports than analog ones.

    This was a PDF document, and I checked it. On page 25, there is this sentence: ” Annual capital expenditures for Frontier’s West Virginia local exchange carrier companies have averaged over XXXXXXXX for the past nine years.” The XXX is blacked out, but pasting it into a document shows this is a $70mm amount. It pays to know your tools.

    This certainly isn’t a good technique for hiding information, but it’s not far off from what some people do when trying to mask or obfuscate sensitive production data in development environments. There are lots of cases where people use scripts that change data in one table, but not related data. Or that the changes are incomplete and don’t do a good job of ensuring there isn’t sensitive data leakage.

    To be fair, this is a hard problem, and there are no perfect solutions. Anyone masking data likely needs to take a few passes at the problem, making adjustments over time to try and ensure that the data is protected from unauthorized disclosure. There also isn’t a perfect solution, as many researchers have found ways to reconstruct the original data after it’s been anonymized.

    This is an area that I think is still somewhat immature, with relatively few best practices available for anyone to look at. While I have seen some guidance, I don’t see much on how one could verify they had done a good job. I hope we find ways to do better in the future, with more knowledge that helps data professionals ensure they are doing a good job. Otherwise, we won’t be able to protect data the way we want to protect it.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.