Giving a Security Webinar this Wednesday

If you haven’t already signed up, on November 29, 2023, at 11 AM Eastern Standard Time, I’m presenting a webinar on how to harden SQL Server.

Link to Register (free): GoTo Webinar – How to harden SQL Server – registration

Here’s the abstract:

Microsoft SQL Server has been a target of threat actors for over 20 years. The first world-wide exploit of SQL Server was known as SQL Slammer and it caused significant changes to Microsoft’s software development lifecycle and the instituting the Trustworthy Computing initiative. Now, a fresh attack against SQL Server has made the news: DB#Jammer. DB#Jammer and attacks like it exploit poor security configurations in both SQL Server and the surrounding technology.

Beyond the abstract, here’s what I’m going to go into detail about:

• Understanding surface area, zero trust, and network security.
• Assuming an already breached mentality.
• The importance of basics such as password strength and account lockout.
• The need for a layered approach when it comes to security – network, OS, and SQL Server.
• Proper auditing and reporting to detect breaches

Is that the right question to ask?

This is not a “clickbait” title, but an important consideration when it comes to developing technical solutions. Let me give you an example between two questions for SQL Server on-premises running on Windows.

Question 1: Does SQL Server allow you to set things like password complexity, password length, and the number of failed login attempts before the account is locked?

Question 2: Does SQL Server support things like password complexity, password length, and locking the account after a number of failed login attempts?

At first glance, the questions are similar. The difference in the questions is centered around whether or not SQL Server lets you set those values. SQL Server does not. SQL Server will use the Windows policies with regards to passwords (see the section on CHECK_POLICY). So while SQL Server support those elements, it doesn’t allow you to directly set them. Therefore, the answer to Question 1 is no while the answer to Question 2 is yes. If the goal is to ensure that proper password policies are enforceable, then SQL Server does that. Answering Question 1 without any further discussion will miss the goal.

So what happens if we get a question like question 1? It’s time for us to ask clarifying questions. We need to understand what the asker is trying to discover or verify. I’ve had engagements with IS auditors where Question 1 was asked. That causes me to stop and ask back something like, “Are you looking to see that logins created in SQL Server can have enforcement of strong password policies?” This gets to the root of what they are trying to understand. By asking this clarifying question, I get a chance to give them the complete answer, which is beyond what the auditor initially asked.

I’ve seen similar types of questions coming from developers. For instance, a typical question might be, “Have I got this query correct to use a CTE?” I can answer that question directly, it’s a simple yes or no, but I should ask, “What is this query supposed to do?” It may be they don’t need a CTE at all. But neither I nor the developer won’t know that unless I ask my question to understand what the developer is trying to do.

It’s often up to the person with the expertise to ensure the appropriate question is asked. There’s an old saying, “they don’t know what they don’t know.” And there’s another saying, “Anyone can have a brain fart.” So even if someone should also be an expert, it’s never a bad idea to ask the intent behind the initial question so we can ensure the right question is asked and properly answered. Don’t be afraid to spend the effort to ensure the right question is being asked.

Webinar: How to Harden SQL Server

On November 29, 2023, at 11 AM Eastern Standard Time, I’m presenting a webinar on how to harden SQL Server.

Link to Register (free): GoTo Webinar – How to harden SQL Server – registration

Here’s the abstract:

Microsoft SQL Server has been a target of threat actors for over 20 years. The first world-wide exploit of SQL Server was known as SQL Slammer and it caused significant changes to Microsoft’s software development lifecycle and the instituting the Trustworthy Computing initiative. Now, a fresh attack against SQL Server has made the news: DB#Jammer. DB#Jammer and attacks like it exploit poor security configurations in both SQL Server and the surrounding technology.

Beyond the abstract, here’s what I’m going to go into detail about:

• Understanding surface area, zero trust, and network security.
• Assuming an already breached mentality.
• The importance of basics such as password strength and account lockout.
• The need for a layered approach when it comes to security – network, OS, and SQL Server.
• Proper auditing and reporting to detect breaches