Guidance on Moving Off of SQL Server 2008 and 2008 R2

July 9, 2019 will be here soon. With it comes the end of support, including security updates for SQL Server 2008 and SQL Server 2008 R2 unless you either migrate to Azure or enter into an agreement program with Microsoft. I know quite a few folks are facing this situation, so I wrote a guide covering why to migrate (other than regulatory) as well as what to do if you can’t, over at Simple Talk: The End of SQL Server 2008 and 2008 R2 Extended Support.

MSSQLTips Webcast on Security

On February 11, 2016, at 3 PM EST, I’ll be giving a security webinar for MSSQLTips. It’s titled Performing a SQL Server Security Risk Assessment. Here’s the abstract:

You have one or more SQL Servers and you want to assess the security of each. What’s a priority? What puts your organization at the greatest risk? What should you attack first?

In this presentation, we’ll look at how to do a security risk assessment of SQL Server. We’ll cover all the common big ticket items, the ones that could lead to a server breach, data loss, or a system becoming unavailable due to mismanagement. Also, we’ll discuss how to assess other items which you may find and how to rank and prioritize them. Armed with this information, you’ll be better equipped to provide a to do list to your management with justifications and relative impact for each proposed change.

If you’re interested in attending the webinar, it’s free but you’ll need to register.

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.

My Upcoming Speaking Engagements

March 4 – Charleston PASS, Charleston, SC

What Admins Absolutely Must Know About SQL Server Security

There are so many security tips out there for SQL Server. Almost all of them are rated as a best practice. What do you listen to? What do you focus on? In this session we’ll break down what you absolutely must know about securing SQL Server. We’ll look at the things to look for within SQL Server, including some of the nooks and crannies an attacker might use but what are rarely audited. You’ll leave with a checklist of what to investigate and a set of scripts to run on your own systems.

Register Here

March 12 – Webinar with MSSQLTips.com

SQL Server backup automation and best practices

Join us for this webcast to learn about best practices for backing up your SQL Server databases along with things you can automate to reduce your workload.

Having proper backups for your SQL Server databases is your last line of defense when things go wrong. Database backups are rarely used to restore a production database, but when they are needed, having a solid plan is paramount.

In this webcast we will cover:

  • The types of backups to setup for your databases
  • Proper database settings for backups
  • Protecting database backups
  • Backing up system databases
  • Automating backups with SQL Agent and other scheduling tools
  • Automating checks to ensure backups are successful
  • Setting up alerts and notifications for backup failures
  • and more

Register Here

March 12 – Midlands PASS, Columbia, SC

What Developers Absolutely Must Know About SQL Server Security

There are so many security tips out there for SQL Server. Almost all of them are rated as a best practice.What do you listen to? What do you focus on? In this session we’ll break down what you absolutely must know about building secure database using SQL Server. We’ll look at the SQL Server securables model, how you can simplify your security model using patterns and models you are already familiar with, how roles can be used to aggregate security cleanly, and how to put in triggers and other mechanisms to try and protect your databases from attack.

Register Here

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 SQL Saturday #354 – Charleston, SC

If you’re looking to warm up for the winter, come on down to Charleston, SC, on December 13, 2014. Charleston will be hosting its second SQL Saturday. Why Charleston?

And, oh yeah, SQL Saturday! But outside of SQL Saturday, here’s a great link to see all the places to hit and see in Charleston.

As for me, I’ll be giving a security talk:

What You Absolutely Must Know about SQL Server Security

There are so many security tips out there for SQL Server. Almost all of them are rated as a best practice.What do you listen to? What do you focus on? In this session we’ll break down what you absolutely must know about securing SQL Server. We’ll look at the things to look for within SQL Server, including some of the nooks and crannies an attacker might use but what are rarely audited. You’ll leave with a checklist of what to investigate and a set of scripts to run on your own systems.

Carolina Technology Conference: Presentation Materials

For those able to attend my session at this year’s Carolina Technology Conference, thank you! As promised, here are the slides, sample code, and audit scripts from my presentation on What You Absolutely Must Know about SQL Server Security:

ZIP file: What You Absolutely Must Know about SQL Server security

4 Attitudes I Wish I Had Earlier as a DBA

I was tagged by Mike Walsh (blog | twitter) in his post 4 Attitudes I Wish I Had Earlier As a DBA.

I Don’t Have to Do It Alone

I’ve always worked hard in my IT career to be knowledgeable in my field. I don’t like not knowing how to do something, and I’ll spend the time and research to figure out how to make something work or how to fix a problem. Early on in my career, whenever my team would encounter an issue, I took it as a personal challenge to solve every issue. At first this sounds great. Brian is being a real go-getter. But there’s a catch.

It hurts the team. When one person is solving all the problems, especially when that one person isn’t giving anyone else a chance, the rest of the team starts to become apathetic about new problems coming in. After all, Brian will solve it. This means one person, me, gets stuck with all the new problems. It destroys my work life balance. It means I don’t have a life. I get stressed out. I miss work. Suddenly there are problems that need solving and Brian is out. Or, two big problems hit at the same time. Brian can only work on one.

Now there’s a big problem. Since others stopped solving problems, the team isn’t prepared to solve the one Brian isn’t working on. As a result, Brian, the team, and the organization suffers. It’s one thing to be a high performer. It’s quite another to try and do it all alone. What I have learned is to be a high performer and to try and bring people along with me to also be high performers. Let’s solve the problems together, so others grow.

The Technical Solution Isn’t Always the Right Solution

This one took a long time for me to get. I like processes. I like solving technical problems. Often times I could see a technical solution to a problem, albeit a complex one. It took my last manager to get through my head this simple concept: sometimes the best solution is a people solution and not a technical one.

There isn’t a standard rule when this is true. However, when you start weighing a technical solution versus a people solution and the people solution looks less complex, it’s time to start seriously considering the people solution. This is especially true when you don’t need 100% adherence or when you have time to offer a few reminders.

People Skills Are Important

One of the reasons I received promotions early in my IT career is that I was able to talk with key business folks. I interacted well with HR when we were putting in a new software package. I could understand the PMs (probably because I was one in the USAF) and could give them estimates in their terms as well as explain variances due to issues being faced. However, I sometimes struggled with developers. Don’t all DBAs? Maybe, but most of the struggles were my own creation. Rather than asking the question, “What are you trying to solve?” and then working with the developer to find the answer, I was quick on the “No, you’re wrong,” stamp. That doesn’t do anyone any good. I have found that when I can remember to engage my people skills and not my rubber stamp, I am more effective at my job.

Remember Who Is the Boss

At the end of the day, I may feel a solution is not the best. I may not like it at all. However, unless I feel that a solution or an instruction causes me to compromise my morality or my integrity, if my management decides to go a certain direction, I’m supposed to execute. I can offer my objection to my management, but if they say, “This is the way it is,” then it’s time to stop fighting and go to it.

I knew this before becoming a DBA. After all, this is the way things work in the military. You can object, if there’s time, to your immediate chain-of-command and if that person says, “This is the way it is,” you are supposed to make the command your own. However, when I got into the civilian workplace, I somehow forgot this way of thinking. I know a few situations earlier in my career would have gone a lot better if, having voiced my objections, I hunkered down and got the work done.

 

Nothing earth-shattering, but hopefully it’ll help someone else.

Guest Post on SQL Authority – Default Trace & Deleted Databases

I had the opportunity to write another guest post at SQL Authority:

Finding Out What Changed in a Deleted Database

This one covers how to determine who made changes in a database that has been deleted. This isn’t a situation where you can use the schema changes history report because there’s no database to select from in SQL Server Management Studio.

I realize that there’s a limited use for the technique. However, if someone is trying to cover a some sort of mishap (dropped the wrong table, etc.) at simply by deleting a database, this is the quickest way to find out what they did. While we can agree dropping a database is typically a worse mishap to recover from, it’s a foreseeable accident and so one could have just such an “accident” to cover up changes they were attempting to make somewhere they shouldn’t have been (like changing code in production without authorization).

Presenting on Top SQL Server Vulnerabilities

On February 19th, 2014, I’ll be giving a webinar from 3-4 PM Eastern on the Top SQL Server Vulnerabilities. You can register here for it.

It is being provided by MSSQLTips.com and GreenSQL. Here’s what I’m covering:

Your goal is to have a secure SQL Server installation. However, you don’t have forever to get the job done. Nor do you have an infinite amount of time and resources to monitor the installation after it’s in production.

  • What are the biggest things to focus on?
  • What will be your most painful headaches going forward?
  • What should you be watching for to detect a potential compromise?

In this webinar, I’ll answer these questions so you can quickly and effectively configure and test your SQL Server for optimal security. We will also give you a glimpse into GreenSQL’s offerings to secure your SQL Servers. For those on a tight budget, scripts will be provided and free tools referenced.

Previous Older Entries