Voice of the DBA

Tag: security

  • 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.

  • BYOD Fingerprint Concerns

    Many modern devices, whether mobile phones, tablets, or laptops, contain fingerprint readers. We’ve had readers for a long time, but they were very expensive and not widely deployed. That changed with mobile phones and now many devices include fingerprint readers as standard equipment. So much so that this seems to be a very common way of authenticating access on lots of devices.

    This isn’t necessarily a very secure way of protecting data. An ArsTechnica article notes that fake fingerprints were able to access these devices 80% of the time. That’s a success rate that might worry a lot of security personnel. Most organizations allow some sort of BYOD device, including many financial, medical, and other organizations that deal with sensitive data. Since control of a device often includes saved credentials and the ability to approve 2FA implementations, this could be an issue.

    Certainly nation states might try to take advantage of this to gain control of a device and access data from other governments, but I’m sure corporate espionage is in play here as well. I wouldn’t be surprised if this also becomes a technique for pranksters and jokers. Imagine you can bypass the fingerprint on a colleague’s phone. Maybe you want to change their wallpaper. Maybe you want to send an embarrassing email to friends. Maybe you want to add a backdoor to some code using their GitHub credentials. You could do anything from an innocuous joke to a malicious career threatening action. Imagine you choose to do this while your colleague is at lunch, with their phone forgotten on their desk.

    No security is perfect. Many of us that work with someone often might be able to guess a PIN or pattern on a device if we see it often enough. We certainly could easily put a keylogger on a wired keyboard at someone’s desk. There are plenty of vulnerabilities, and in this age of being highly connected through our devices, there are potential issues with all access. There’s no perfect solution, but we should be diligent with physical control of our devices and react swiftly if we think one might be stolen. Remote disable and a good backup might be top of my list.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Encryption Libraries

    One of the ways we work to implement better security is through the use of encryption. I remember the early days of PGP, VPNs adding end to end encryption, IPSec becoming available, and more. I was excited to see column level encryption come in SQL Server 2005, but it was a bit complex to implement and had issues. The evolution over time with TDE and Always Encrypted were welcome additions, but we can do better.

    Handling encryption in the database can provide some protection, but really, we’d like to see an end to end solution, that ensures data is protected on the wire as well as in the db. Microsoft does a lot of research, and released a Simple Encrypted Arithmetic Library (SEAL) as open source code. This is a C++ library that developers can use to protect their communications. Last year they also released a .NET wrapper to make it easier for a wide variety of developers to use.

    There is a lot more to deal with when handling encrypted at scale. Indexing and search operations are difficult and complex, and can require lots of resources. I think that the Always Encrypted in SQL Server 2019 with Secure Enclaves is a good evolution, but it’s complex to set up, tooling is poor, and maybe more disconcerting, there are potential vulnerabilities with secure enclaves on Intel chips.

    Certainly a combination of developers being able to use something like SEAL and a linkage with a secure enclave on the server for set-based operations might be something we can look forward to in the future. I hope so, as security continues to be a challenge for many of us.

    I’d also like to see more software that is built to ensure users can’t access huge amounts of data, and perhaps easier ways to control the export of large amounts of data. We do need this capability, but we also want very few people, or no people and only a process, with rights to do so.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.