Webcast: How to Secure SQL Server – End to End Security

On April 16, 2024, I will be giving another webcast; this one will be on SQL Server security.

Sign up link

As always, the registration is free. Here’s the abstract:

Data is the lifeblood for almost every organization. As a result, platforms like Microsoft SQL Server are high-value targets for attackers. However, knowing what to do and not do can be daunting.

In this webinar, we’ll walk through a framework to secure your SQL Servers from end-to-end. Starting with the install and walking through surface area, permissions, backups, encryption, and concluding with decommissioning, we’ll cover every area you’ll need to consider for your SQL Server environment. Where they are applicable, we’ll also point out industry good practices and where to find the documentation on them.

By the end of the webinar, you should leave with a plan for where to start, what’s most important, and where to go for more information to ensure you can properly harden and secure the SQL Servers in your organization.

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

Trust No One Implicitly

At the Charlotte BI Group meeting last night, one of the questions I was asked after I gave my talk on Securing the ETL Pipeline was this:

“So you’re basically saying we should trust our DBAs?”

My response caught several people off guard:

“No, I’m saying to trust no one. Not even your DBAs.”

That received more than a few raised eyebrows. I went on to explain. I have two simple reasons to make this statement:

1) The difference between a trustworthy and untrustworthy employee is one life event.

Your DBA gets hammered in the divorce settlement and is now looking at barely scraping by. He or she has access to data that can be sold, and sold for a lot of money because (a) there is a lot of it and (b) it’s verified. You don’t think temptation is going to change a few folks’ behavior? Instead of divorce, substitute bankruptcy due to medical bills (especially if said person lost a loved one after all those bills) or a drug habit that becomes consuming.

A point I made along these lines is we often don’t know the personal lives of our co-workers, so it’s not a given that we’d catch such things. After all, a pilot who didn’t want to lose flying status was able to hide that he was shopping around doctors and we know how that ended up.

2) It might be your employee’s ID, just not your employee.

The Anthem hack tells us all we need to know on this topic. A telling quote from the article:

“An engineer discovered the incursion when he saw a database query being run using his credentials”

Trust No One Implicitly:

As #2 points out, even if you have trustworthy employees, you still have the case where an attacker can get in and steal data. Even though you trust your employees, you need to have controls in place that performs checks like you don’t trust them. That was my point last night. It’s no longer a matter of if an intruder is going to get in. It mostly definitely is now when and for how long.

Speaking at Charlotte BI Group Tomorrow

Tomorrow, Tuesday, April 7, 2015, I’ll be speaking at the Charlotte BI user group. The meeting starts at 5:30 PM.

Here’s the info:

RSVP Link

Topic: Securing the ETL Pipeline

We’re going to look at typical ETL (Extract, Transform, Load) pipelines and consider the weak points an attacker might go after. Our goal in this isn’t to cause FUD (Fear, Uncertainty, and Doubt), but to discuss risks at each point, options for protecting the vulnerability, and what we’ve seen typically done (if anything). While this talk primarily focuses on Microsoft SQL Server, especially the database engine and SSIS, many of the points covered will be applicable to any solution set.

Location: 8055 Microsoft Way, Charlotte NC 28273

SQL Saturday #354 – Charleston, SC is almost here!

If you are relatively near to Charleston, SC, there’s a SQL Saturday there this weekend, December 13th!

SQL Saturday #354 – Charleston, SC

Looking at the speaker list, if you’re able to attend you’ll get top notch training for FREE! For instance, the SQL Server Legend, Kevin Kline, will be present to give a presentation and participate in a career panel. Whatever your focus is with SQL Server, there looks to be topics covering it.

If you’re looking for security, come early, as my talk is at 9 AM. If you can’t make it, I’ve already uploaded my presentations and scripts to the site.

 

Speaking at Midlands PASS Chapter tonight

The Midlands PASS Chapter is an official PASS (Professional Association for SQL Server) chapter located in Columbia, SC. It’s free to attend our meetings, which are typically held the 2nd Thursday of each month.

Once a year we like to do an open forum on SQL Server security. It’s typically held in February, but was postponed due to the inclement weather. Therefore, we’re holding the open forum tonight, March 13, 2014, from 5:30 to 7:00 PM. The first part of every meeting is meet and greet to give folks time to network. Then we settle in for a presentation, or in this case, a forum discussion.

The SQL Server security open forum is as it sounds: folks are free to bring up whatever they want to with regards to SQL Server security and as a community we’ll try to take things apart and come up with the best answer. While I may focus on SQL Server security, I don’t have all the answers. None of us do. That’s why a few years ago we went to this more free form discussion.

If you’re in the area and would like to attend, please drop on by. We meet at Microstaff IT in Cayce, SC at 440 Knox Abbot Drive (tower with Bank of America logo on the top). If you look on Google Maps, the address is marked wrong. Google Maps is pointing at the shopping center right next to the tower, but the parking lots are connected.

A summary of the SQL Server security #datachat is live

Recently I posted about participating in a #datachat about SQL Server security. As it turned out, we didn’t talk about SQL Server security, but data security. It was a good discussion with quite a few knowledgeable folks joining in. A summary of the discussion including some highlighted tweets can be found here:

Four Critical Challenges in Implementing Data Security: A Conversation with SQL Server and Security Experts

The #datachats are community open forum discussions. You just have to know when to show up on Twitter! To see what topics are coming up and when they’re scheduled, check out the #datachat schedule.

Auditing VMware vCenter Actions (on SQL Server)

When you’ve got a SIEM appliance or application, you want actions and events going into it as a central repository. That allows you to see patterns and hopefully track incidents across systems. As a result, if you want to track actions in VMware’s vCenter and you’ve got the database hosted on SQL Server, you need to give access to the following two tables:

• VPX_EVENT
• VPX_EVENT_ARG

A standard tendency is to give the account that the SIEM product is using membership in the db_datareader role. Don’t do this. It’s a violation of the Principle of Least Privilege. It’s far better to create a user-defined role and granting it the appropriate permissions. Then make the account a member of the role. For instance:

USE VirtualCenterDB;
GO

CREATE ROLE [Auditor];
GO

GRANT SELECT ON OBJECT::dbo.VPX_EVENT TO [Auditor];
GRANT SELECT ON OBJECT::dbo.VPX_EVENT_ARG TO [Auditor];
GO


And then you make the user account being used by the SIEM product a member of the Auditor role.

The weakest link in database security

The weakest link in database security is the same as for most all IT security: people.

Because the weakest link is always people, we have adopted a principle called The Principle of Least Privilege to determine how we should assign security. If you’ve never heard of it, it’s a basic concept with some easy to follow rules:

1. Give enough rights to do the job.
2. Don’t give any more.
3. Don’t give any less.

#2 is particularly relevant. It’s easy to violate this, especially when SQL Server is concerned. If you’ve ever heard, “Just give the application db_datareader,” you’ve heard a violation of this principle. The same is true with db_datawriter. Why is this a violation? Let’s ask a few basic questions.

• Does the application (report / user / etc.) need access to all tables in the database?
• Does the application (report / user / etc.) need access to all view in the database?
• Are you sure the application (report / user /etc.) needs access to the catalog views (the system objects) for the database?

Often times, the risk is understated: “Well, so-and-so is completely safe. He would never do anything wrong with the data.” Yes, that particular person may be safe. Then again, life changes may alter that person’s morals and ethics. It’s amazing how much major events like a divorce, like medical bills, like gambling debts, like a new drug habit change those things. But let’s say the person is completely safe. Are you safe? No.

The problem isn’t the person. It’s the person’s user account. If someone were able to run under the context of the user account, he or she can do whatever the account can do. Give the account too many privileges and you’ve got a problem. If someone is willing to compromise an account, they are likely going to have few qualms about swiping important data.

See, it’s relatively hard to directly attack a database server and in a trusted environment. It’s much easier to slip a trojan in to an email or mail a link which leads to the malware being installed on the user’s computer. And then, BAM!, the attacker is in as that user and the attacker now has the user’s access to the database. If you’ve given too much access, that’s bad.

Therefore, given the weakest link in database security, the best practice is to follow The Principle of Least Privilege. Don’t leave it until the end and try to retrofit. You’ll likely be forced to rush and that’s when people cut corners with db_datareader and db_datawriter. Instead, get it attacked at the start of a project / development effort. Get it right from the beginning.

 

Security #Datachat on Twitter Tonight

Tonight, at 9 PM Eastern, I’ll be participating in a #datachat on SQL Server security. It’s sponsored by Confio (now part of Solarwinds).

You can find more details about the #datachat here.

How can you participate? Simply open up a search for #datachat and participate in the community Q and A. The more, the merrier!

I hope to see you online.