Voice of the DBA

Tag: security

  • Don’t Lose Data Without a Hacker

    The GDPR has been law since 2016 and been enforced since mid 2018. California has the CCPA in law, but not being enforced. In any case, it’s 2020 and we have lots of tools and knowledge about securing systems. We aren’t perfect, and certainly Microsoft isn’t, but we should be avoiding simple mistakes.

    For those of us in the US, or outside CA, we might be less worried, but if you’re in the EU, you should be concerned. Here is a mistake by Virgin Media, with data exposed for months. Someone configured a database, likely set it up for access remotely, and didn’t do a good job.

    It does start to feel that we ought to have some sort of security smoke test in every organization that checks for exposed databases in our networks. Perhaps we even ought to have this for all subscriptions with vendors that host services for us in the cloud. That might be good for IT people, but what about shadow IT, or the average person that just wants to share data with co-workers?

    No one ought to be able to configure a file share, an S3 bucket, Azure BLOB Storage, or anything similar by clicking in some sort of control panel. Honestly, I get that vendors want to make things easy, but we need security over data in all organizations. There ought to be a “configured” click to share button that runs a series of scripts to ensure we have secure controls over resources. File shares might be hard, but for databases, there’s no excuse.

    I do know that for some people, it’s a pain when they can’t create databases. I deal with customers regularly that have this restriction on developers, and it’s problematic. However, we need better security, and really, we need less real data being shared so widely. As an industry, we need better dev data sets, and we need better security protocols over any production data.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Secure Enclave Concerns

    We worry about security as data professionals. It’s a constant issue, though it seems that so many of the data breach issues come from simple mistakes. We have lots of automation, configuration as code, and more. These days we should have a protocol and automated process for setting up systems, file shares, and other ways of allowing others to access data.

    Awhile back we had attacks against hardware (Meltdown and Spectre), which required patches to systems to secure them. This was disruptive, but I haven’t seen any widespread security issues as a result of these flaws. Many systems were patched, though it’s entirely possible that there have been exploits.

    In a report this week, researchers have found a way to read data in the secure enclaves of some chipsets. That’s disconcerting because lots of secure software counts on the Intel Software Guard Extensions (SGX) protecting data. This is part of the Always Encrypted enhancements in SQL Server 2019, which I was happy to see added. These are supposed to help ensure you can protect data, even if you don’t have control of the physical machine, which is common in hosted and cloud scenarios.

    A new exploit could be a problem. Intel says it’s not, but they have an interest in saying that. The research looks complicated, and I could certainly see this is hard to do, but attacking a large environment, like a cloud subscription, might be something hackers try. Even if they aren’t successful, there may be performance issues with SGX calculations from a software patch.

    The point of this piece isn’t to alarm you. Likely this is more speculative than reality, but you should be aware there are potential issues. Encryption and security are complex topics, and I’m hoping Intel and Microsoft (and others) come up with better protections and mitigation for the issue. However, ultimately it’s up to us tech professionals to understand what possibilities there are and ensure we are taking every precaution we can.

    Steve Jones

  • Is 100% Security Possible?

    Microsoft has spent a lot of resources working to ensure their software can be automated, audited, and configured securely. After the SQL Slammer worm, there was an effort made by the organization to code more securely. Secure by design and by default was the goal, and they’ve continued in the years since to try and ensure we can better secure our systems. There’s even a Zero Trust methodology that they push these days.

    Microsoft is notoriously strict with security, disallowing networking to potential threats, and they encourage you to do this as well. They have SAWs and PAWs and auditing recommendations and advanced threat protection. They have an incredible security operations center, which I’d like to think they use for their internal resources.

    And yet, we have Microsoft support mis-configuring a database and exposing customer PII. How does this happen when security is a big part of the Microsoft business, and something that many of us rely on them doing well? This was human error, an issue with network security rules, and likely due to the complexity of these rules, because managing these and understanding the end result of a large set of rules is difficult for a human.

    Still, it’s disappointing and daunting. As I talk with people about DevOps and ensuring we automate our best practices, I find many people embracing the idea of using software to ensure our systems are set up consistently and securely, in the same way in all environments. I find plenty of people that prefer having the computer make the changes for them and removing the chance they make a mistake.

    However, if all of the staff doesn’t buy into the new process, it opens up potential places for problems. One human and cause problems by circumventing the system. In this case, Microsoft admits they have solutions to prevent and detect this, but they were not enabled. Again, this was likely a human mistake, but this isn’t clear from their post.

    Perhaps the most disappointing thing about this data breech is the lack of details. I’d like to know what rules failed, and maybe more importantly, what systems are in place to protect against this and how are they configured. This is a great opportunity for Microsoft to share some knowledge and educate their customers, but they didn’t take it. Specifics on the failure would help many of us ensure we don’t fall victim to the same issue.

    Security is hard. It’s a constant, ongoing battle to ensure we are following best practices, as well as learning and updating our knowledge all the time. If Microsoft can’t do it, can we hope to? Maybe more importantly, if Microsoft doesn’t help us understand how do secure systems well, with their experts and specialists, can we hope to do better?

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Quick Security Mistakes

    How many of you have gotten an urgent request from someone in your organization? Maybe it’s a new database, perhaps a quick, “simple” change to an application, possibly even a new server or share that someone can use to complete their work. It’s something new that you need to do. When that happens, how many of you ensure that you follow all the same steps and protocols to comply with the urgent request?

    A few of you do, but when we’re in a hurry, many of us don’t necessarily complete every step. We may shortcut something to get work done. We may have the best of intentions to go back and complete the work, but in a busy environment, it’s easy to forget to complete that last step, which might be configuring security or running all or unit tests or even decommissioning some resource that a user is done using. Some of you will realize these are big missteps, and some of you will still make them.

    Someone at the Department of Transportation in Coloroado (CDOT) made a mistake like this (thanks to DCAC and Joey D’Antoni for the story). They stood up a virtual machine, connecting it to their local network, but failing to properly secure it. In this case, the machine was exposed to the Internet and connected with a domain admin account. As you might guess, someone got into the machine and executed a ransomware attack on CDOT.

    As Joey points out, a few mistakes were made here, but these are the types of mistakes that anyone can make. Lots of us follow a process over, and over, and over again. Until we don’t. Until we’re distracted, busy, or in a hurry. They we take a shortcut. Most of the time nothing happens, but most of the time is becoming less acceptable. All of the time is the standard, which is why we try to use a DevOps, GitOps, or other process that ensures all the steps are completed. Not most of them.

    Do yourself a favor and build processes to handle your tasks with a script or the push of a button. Ensure the operations are logged and audited. Use these processes to be sure that setting up a new system, database, application, etc. is done in a consistent and secure manner. There’s still plenty of work to do for all of us. These processes will grow and change over time, and need to be maintained. Use your brain for the hard problem solving task of building a process and let the computer execute it, the same way, to completion, every time.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.