Category: Security

Fabiano Amorim hits three topics:

Over the course of this series, I’ve challenged the common assumption that a SQL Server environment is safe simply because it’s patched, firewalled, and configured according to familiar defaults.

I’ve proven that this is not quite true, because real security is not a checkbox. It requires a verification mindset, especially in areas where SQL Server intentionally provides powerful operational features for DBAs, developers, monitoring tools, and application frameworks. 

In this guide, I’ll focus on three features that are easy to underestimate because they look like normal SQL Server behavior. They are global temporary objects, Dynamic Management Views (DMVs), and audit coverage – each a useful feature in their own right.

The other thing they all have in common? They can each become part of an attack chain if granted too broadly, used inside privileged workflows, or trusted without validation. 

Click through for Fabiano’s guidance.

Emad Al-Mousa finds a way around:

Adversaries continuously exploit every available vector to exfiltrate sensitive data while evading detection. This risk is magnified because critical threats originate from both external cybercriminals and trusted insiders.

To counter this, robust database auditing acts as a foundational line of defense, enforcing tailored policies that align with corporate security and compliance mandates. By streaming these granular audit logs directly to a SIEM solution, Security Operations Center (SOC) analysts gain real-time visibility to spot anomalous queries and unauthorized modifications. Furthermore, these logs serve as an immutable evidentiary trail for post-incident forensics. Ensuring that the database security and logging engine functions reliably is therefore non-negotiable for enterprise risk mitigation, rapid incident response, and regulatory compliance.

The quick idea is that you can view database histogram data without tripping audit logs, and those histograms might contain some amount of the sensitive data that you don’t want people to see.

Fabiano Amorim offers some advice:

The SQL Server attack pattern is consistent: attackers do not always need a spectacular vulnerability. They often succeed by chaining normal features that were granted too broadly, trusted too much, or monitored too narrowly. 

In this article, I’ll focus on operational blind spots in SQL Server. These are the features DBAs use every day to keep SQL Server healthy: linked servers, traces, Dynamic Management Views, Extended Events, and session-management commands such as KILL.

These tools, while necessary, also create visibility, automation, and trust paths that attackers can abuse after compromising a low-privileged application account or a local database owner. 

Because of this, a SQL Server DBA should know the answer to the following questions at all times: where am I exposed, what should I monitor, and what should I change first? In this article, you’ll learn the answers to all three.

Click through for the advice.

Marlon Ribunal builds a checklist:

Here’s a follow up for our US Department of Defense STIG document. In my previous post, SQL Server Security Hardening Guide Using the DoD STIG Checklist, I walked through how I used the DoD STIG checklist as a starting point for reviewing and hardening a SQL Server environment.

After going through the checklist, I started thinking about what I would actually want to use the next time I perform a security review.

The DoD STIG for SQL Server is a great, solid starting point for establishing your security practices with SQL Server. In fact, it’s also a good template for your own STIG in your organization. So, you may want to create a custom checklist that makes sense from the perspective of your SQL Server environment.

The STIG is detailed, which is a good thing, but I found myself wanting something a little more practical for day-to-day DBA work. Something I could open, work through one item at a time, record what I found, and come back to later without having to navigate through the entire STIG document every time.

Click through to see what Marlon came up with.