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.

Advertisements

Midlands PASS Meeting: 2016 SQL Server Security Refresher

The Midlands PASS Chapter will hold its next meeting on January 14, 2016 at Microstaff IT. We start the meet and greet at 5:30 PM and the main topic usually kicks off around 6 PM.

2016 SQL Server Security Refresher

Midlands PASS Chapter’s annual SQL Server security refresher! This is an open-ended discussing hosted by Data Platform MVP and resident SQL Server security expert, Brian Kelley. Bring your scenarios and questions and we’ll work through the best ways to build security solutions for and using Microsoft SQL Server.

You can RSVP here so we know how much food and refreshments to bring.

SQL Server Encryption Presentation on July 9, 2015

I will be giving a presentation on SQL Server Encryption through MSSQLTips. It’s at 3 PM EDT on July 9, 2015.

You can register through the MSSQLTips.com page for the webinar.

This sign-up page will allow you to sign up for multiple future webinars.

A rough outline of the presentation:

Data in the Database

  • The case for partial encryption (some data unencrypted)
  • The datatypes we use for encrypted data
  • The options available and who can see decrypted data
  • How we use SQL Server’s built-in functionality
  • Addressing Performance Issues

Encrypting the Whole Database (Transparent Data Encryption)

  • How it works
  • What you need to make it work
  • How do you handle recovery / disaster recovery

Encrypting Backups

  • Don’t wait until after it’s written to disk
  • TDE to the rescue
  • Encrypted backups in SQL Server 2014
  • Don’t reject 3rd party products

Encrypting Connections to SQL Server

  • The options
  • What about POODLE?
  • What about IPSEC?

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

Why You Shouldn’t Skip the Infrastructure/Security Architecture Review

It’s not usual for development projects to undergo an architecture review, but too many times these reviews consist only of developers. There are no server or network folks, much less any DBAs or security personnel. When I’ve brought this up to some of my developer friends, they wonder what the issue is. After all, developers have a good grasp of how things work, right?

If you’re an infrastructure type, you’re probably chuckling right now (or shaking your head sadly). If you’re a developer, let me ask you a very basic question, “Do you think the admins who support you understand everything about the code you write?” The obvious answer is, “No,” they don’t. They are very smart people but you’ve spent years learning to code, working through design patterns, finding and solving bugs, and a whole lot more about writing code that infrastructure folks don’t even think about. 

Infrastructure folks also spend years specializing in what they know. A lot of what we know don’t even enter into the realm of the developer. Most developers just don’t encounter the problems and issues we do because we solve them before they do. For instance, a recent install comes to mind where the installation was having an issue because of a hardened configuration with respect to the NICs. 

If you just thought, “What do you mean, hardened NIC configuration?” you just proved my point. If you do know what I mean but you don’t deal with that sort of thing regularly, you’ve also proved my point. If you do think about those things regularly but are quite aware that most developers don’t, you probably see my point. Infrastructure folks have specialized knowledge to bring to an architecture discussion that is not in the wheelhouse of most developers. This knowledge, if the infrastructure people are absent, is also absent. 

Infrastructure folks aren’t looking to throw roadblocks up on projects out of malevolence. Okay, MOST infrastructure folks aren’t looking to do that. What we are looking to do is doing our best to ensure that systems going in or being updated are as secure as possible and perform as well as we can make them. We want to minimize risk for the organization. We want to help the organization make the most out of every IT investment. Sometimes that means we challenge back. We see an issue or an area for improvement. Of course we are going to bring it up. 

The later in the project where we get a look at what’s going in, the harder and more costly it will be to the organization to try and make things better. If it’s a showstopper, there may not be time to avoid everything coming to a screeching halt. That’s why it’s important to get the infrastructure folks involved early and keep them involved throughout the whole project. It’s harder, yes, but it’s also what is best for the organization.

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

Previous Older Entries