Basic SQL Server Configuration Help for Involuntary DBAs

After my presentation at the Techno Security and Digital Forensics conference, I had a information security professional stop by to ask a few questions. He’s in the position where he supports other clients since he works in a third-party security operations center (SOC). The reason most of these clients pay for a SOC instead of developing one of their own is cost. Since they don’t have the money to splurge on a lot of IT positions, another one that’s usually missing is the DBA.

Often times, as a SOC provider, when they interact with clients they can tell fairly quickly that the SQL Servers aren’t configured well. However, they don’t have the knowledge to go in and help their clients in a quick and easy way. He asked for advice. I pointed him to something that we have in our community: sp_Blitz. It’s part of the First Responder Toolkit from Brent Ozar.

Why did I recommend that particular tool? There are several reasons:

  1. It’s designed to provide a quick health check of your SQL Server.
  2. It’s a free tool (yes, you have to register), meaning budget isn’t an issue.
  3. The community has worked on and contributed to it.
  4. It provides explanations and recommendations on how to fix what’s wrong.

For someone such as an involuntary DBA or a consultant trying to assist a client when that’s not your primary skill set, it lets you make solid recommendations immediately that will improve the SQL Server setup. And it’s not hard to setup and run:

If you haven’t looked at this tool before, grab it, put into a non-prod environment, and see if it can help you.

Sysinternals – A Swiss Army Knife for IT Pros

I’m at the Techno Security and Digital Forensics conference in Myrtle Beach again this year. I sat in on a presentation about performing malware analysis. The analyst began with using two popular Microsoft tools: Dependency Walker and Process Explorer. He used Dependency Walker to do a quick, static analysis of the malware file, just to see what .DLLs it used. As malware continues to become more and more sophisticated, this type of analysis is limited. We see a lot of noise. However, by watching the behavior in a sandboxed, isolated environment, we can see what a malware does. With the right set of tools, we can even fool malware into thinking its properly online.

Process Explorer is the more interesting tool here because it allows us to see processes in real time. We can see the handles a process has open. We can also examine any built-in strings that could reveal information about what the malware connects to, maybe who the author was, etc. But Process Explorer’s primary reason for existence wasn’t to help with malware analysis. It, like most of the rest of the Sysinternals suite, is designed to by a toolset to help administrators troubleshoot issues on their systems. I have Sysinternals tools available whenever I’m looking at a system.

The two tools I use the most are Process Explorer and Process Monitor. Process Monitor keeps a log of all file system and registry access. This is great for figuring out why a particular application is failing. Often something is missing. Or, the key to figuring out why something is broke is stored in a configuration file or in a registry value. By seeing what a process attempts to access, I can usually find where the issue is. Combined with Process Explorer, I can get a good view of what an application is trying to do.

The best part of these tools is that they are free. They aren’t hard to learn how to use, either. And they aren’t considered “hacking tools,” meaning you can run them on your system, even if you’re a DBA or developer. If you manage Windows systems, I would definitely recommend familiarizing yourself with these tools, if you haven’t already.