Voice of the DBA

Tag: security

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

  • Better Protection from Hardware

    Microsoft is working on ways to protect your system at an even lower level than the bootloader. Many modern computers have UEFI protection, which allows for security in the boot process, and prevents untrusted code from running. This is intended to ensure that some other boot process cannot run and then invoke your Windows bootloader

    This doesn’t protect from firmware issues, but Microsoft may have a solution. Working with hardware companies (Intel, AMD), they have a System Guard Secure Launch that provides a way to secure your OS. There’s a light explanation at Ars Technica of what this means for you. Essentially, this allows the OS to reset the CPU and ensure untrusted firmware code isn’t running

    I won’t pretend to know how this works in depth, or what additional levels of security this provides, but I do recognize the problem being worked on here. I also think that criminals (and rogue nation state actors) are making deeper and more complex attacks on systems. We know that compromised code can be a major problem for our servers, and we need better mechanisms to ensure we can trust the platform on which we run our database servers

    Just recently there was an alert about a backdoor in SQL Server. This was noted as being in SQL Server 2012 and 2014. At first I was surprised this didn’t get more play, then I realized this was an issue with the Windows OS being compromised and then a patch installed on the SQL Server service to allow attackers to log into the database server. Disconcerting, but if someone gains control of the Windows OS, I’d expect they can get into SQL Server.

    Security is a problem with database servers, and the number and variety of attacks continues to grow. It pays to be diligent, and certainly, use whatever tools are available. Strong passwords, access controls and low privileged accounts, UEFI, SGSL, set up every security feature you can. After all, data is your organization’s most important asset.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Data for Defense

    It’s a dangerous world out there. Many of us hear about data breaches on a regular basis, and we often blame poor security at various organizations. Certainly there are a lot of silly mistakes made, whether in configuration or the mishandling of data in insecure environments. Security is a tough business, however, and most organizations don’t have the budget to combat all the threats they face, at least not as effectively as a larger organization could.

    I have more sympathy for organizations after reading about the work of some Microsoft security teams that go up against the world’s best hackers on a daily basis. To truly understand the vulnerabilities in software, someone must also understand how to attack it. Those of us that only have a defensive mindset are inherently limited in how we design protective measures.

    There is a group, the Microsoft Threat Intelligence Center (MSTIC), that looks for and tracks hackers around the world, trying to understand how they attack organizations. This is a group of multiple teams looking at nation state attacks, as well as complex software tricks, using the tremendous amount of data they gather from telemetry to analyze the different techniques and vectors used to exploit holes in our systems. They notify customers, letting them know when a customer need to be prepared to defend themselves.

    This is a fascinating read, and one that makes me think that most of our organizations are going to be at cyberwar for the foreseeable future. Already we know that any system on the Internet is likely to be probed and attacked if it has vulnerabilities. Most of us are careful about what we expose, but we also know the weakest link in our organization could cause us issues.

    We do the best we can, but often we do depend on other organizations, like Microsoft, to actively be identifying and helping us understand what to patch or change to protect ourselves. I assume Google and Apple have similar groups, notifying their customers of potential threats. These large vendors are likely the best positioned to help, given all the data they collect about their platforms. Certainly I worry about data privacy with these vendors, but I do think that their massive troves of data on how their software works can also benefit all of us.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.