You’ve got first name, last name, full name, birth date, address, email, phone, tax ID or Social Security Number, driver’s license number, medical evaluation notes, MAC address, and IP address columns in a table. So, what would you encrypt in this table? In this episode, our guest, Tom Norman discusses various encryption options and how he goes about choosing what to encrypt. As there are more and more security breaches, the ability to encrypt data is as important as ever.
“Our data is out there and as data professionals, it’s our job to protect that data.”
“One thing to note when you use transparent data encryption is you can go turn it on tomorrow or today in your environment. Transparent data encryption does not affect your code at all.”
“When you start encrypting, Microsoft’s going to make you open up your pocketbook. If you’re going to be serious about your encryption and auditing and stuff, you’re going to have to run Enterprise if you’re on-prem. If you’re in the cloud, it’s all there, you’re paying the same costs.”
Listen to Learn
00:38 Intro to the guest and team
01:21 Compañero Shout-Outs
02:24 How to win a SQL Data Partners Podcast t-shirt
03:28 SQL Server in the News
06:32 Intro to the topic
08:08 There are three different types of data encryption in SQL Server
10:23 You might want to think about turning on transparent encryption as a first step
13:27 Differences between column- or cell-level encryption and Always Encrypted
15:36 There are two flavors of Always Encrypted
18:04 When and where you might want to use encryption
22:46 Encryption is not the only layer you can and should use to secure your data
23:58 Thoughts on certificate management
26:17 Encryption when changing certificates and cell-level encryption
28:37 Other considerations to consider if you’re going to implement encryption
30:00 SQL Family Questions
32:00 Closing Thoughts
About Tom Norman
In 1998, Tom changed his career focus to begin working with SQL Server. He has worked in all aspects of SQL Server including Administration, Database Development, BI and Reporting Services. He has worked in the Finance and Compliance industry. His experience has included International deployments. Tom is the Leader of the PASS Virtualization chapter and the past President of the Denver SQL Server User Group.
Music for SQL Server in the News by Mansardian
Carlos: Compañeros, welcome to another edition of the SQL Data Partners Podcast! My name is Carlos L Chacon, your host. This is Episode 171, and welcome! We have as our guest today, our good friend Tom Norman. Welcome to the program, Tom.
Tom: Thanks, Carlos, it’s great to be back with you again.
Carlos: Yes, so our topic today is Encryption. Before we get into that, we need to recognize Eugene. Eugene is bravely trying to join us from the side of the road.
Eugene: Yes, I’m risking my life for this podcast.
Carlos: Yeah, full dedication here, compañeros. We do need to excuse Kevin Feasel. Kevin Feasel wasn’t able to make it today, as well as Angela. So we’re sorry that we missed them. So before we get into it, we do have a couple of shout-outs that we want to give. I want to give a shout-out to Karabo Calvin Thari, and again, hopefully I said that kind of right, for connecting with us. And as well, compañeros, it is now time to announce that Angela has found greener pastures and is taking her pursuits elsewhere and so unfortunately, won’t be with us on the podcast any longer, so we wish Angela the best of luck in her future endeavors. So Tom, you had a shout-out you wanted to give.
Tom: Yeah, Carlos, I met Lisa Outlaw, an auditor here in the North Carolina area at SQLSaturday Raleigh, just recently and we began to work together and she’s going to help me to refine the encryption and auditing that is becoming so very important to each one of us.
Carlos: Sure, yeah. That is nice when you can find a good auditor to help you out.
Tom: Oh yeah, instead of sitting in front of them when they’re grilling you, so this is on the friendly side instead of the adversarial side.
Carlos: Okay, so compañeros, we mentioned it last week, but however, because of the way of the recordings and the timing ended up working, you actually haven’t had the chance to enter just yet, however, we do have t-shirts from the show that are now available. You can use the #sqltrail and comment about what’s going on in your life. You can mention something about the podcast, you can talk about what you’re doing for the summer, or the winter, depending on where in the world you might be. However, currently, we’d love to get all that social media, those pieces, and we will share those with you when they come. Unfortunately, however, as we begin to roll this out, slow and steady as she goes, I am only able to ship in the United States, as of right now. Now, I’m hoping that will change, but as of right now, we can only ship to the United States, so #sqltrail, we are going to choose one of the folks that mention us on social media, or that use that hashtag, rather, on social media. We’ll enter you to win a SQL Data Partners Podcast t-shirt. So, hopefully you will take us up on that challenge. So now, for a little SQL Server in the News. We actually have two items for you today. The first we wanted to talk about was the SQL Vulnerability Assessment. So this is ultimately introduced for Azure SQL Database, but it’s a tool that will go and take a peek so you don’t have to be the security guru to understand what vulnerabilities may be available for your database. That has actually been around for probably at least a year now, if my timing is correct. However, they have introduced access or availability for Managed Instance and Data Warehouse. So those are some new features that are available there to you. Now, before we started recording, Tom, you actually mentioned that you were starting to use some of this.
Tom: Yes, I’m starting to use it and Carlos, just to go further, the vulnerability report is also available in SSMS 17. If I remember it started in 17.5. But it is actually in there and I’m on-prem doing my classification and vulnerability reports in the new SSMS version, so you do need to get to the latest.
Carlos: There you go. So it sounds like, so if it’s in the 17.9, so maybe not quite, quite the latest, because we just talked about 18 being available, but that is interesting that they’ve made that available in SQL Server Management Studio, so yeah, that’s neat that you can do that. And in addition to just getting the report, you’re actually talking about classifying your data, so it sounds like there are some functionality above and beyond just getting a report.
Tom: Yes, it actually allows you to go in and pull up your report and everything. I would say right now, stay on 17.9.1 version, don’t go to 18.0. I actually recorded a bug to them because the classification was different between 17.9 and 18.0 and 17.9 had more of the proper fields like names and stuff like that it in, where 18 didn’t have it, so I gave them a screenshot, so hopefully they’ll get 18 fixed here, soon.
Carlos: I know they’re trying to integrate lots of different things, so we’re definitely understanding of what they’re trying to do. Okay, so another piece, Tom, you wanted to talk about a driver for .NET Core.
Tom: Yes, Always Encrypted, people have really railed on Microsoft really bad, because a lot of these guys out here using .NET Core couldn’t do it until like yesterday. Yesterday, Microsoft announced that there’s a new out-of-band version of the SQL client, Microsoft.Data.SqlClient, that supports Always Encrypted. They actually sent that information, and Carlos, I’ll forward that over to you so that we can put it along with these notes, because these .NET Core hard fans, didn’t want to do it in the Legacy version, which works very well.
Carlos: Well, there you go. So speaking of our show notes, sqldatapartners.com/encryption or sqldatapartners.com/171 for our show notes to today’s episode. Okay, so as we mentioned, compañeros, as we jump in here, we wanted to talk about SQL Server Data Encryption, ultimately. Now, there are a number of different options and while Microsoft is trying to help us, sometimes they can get very confusing as to what features are available for what offering, how to use them, how they’re different and things like that. So what we wanted to do today was to go over re-give some of that high level overview and then talk about strategies or thoughts around the how’s and then maybe the what’s that you need to be encrypting, because it can be very easy to be like, “oh, I want to encrypt the whole database and I want everything to be encrypted” and it sounds good in theory, but then in practice, makes things a little more challenging. Wouldn’t you agree, Tom?
Tom: I would definitely agree, Carlos. There are some things that we’ll definitely get into here in a moment, but I want to step you back for just a moment and talk about why, why we should encrypt. Because I don’t know whether you know, but just go out there and Google ‘data breaches in 2019’, the biggest data breaches, and Carlos, guess what? One of them is one that you and I use all the time, Twitter. Twitter had a data breach. So our data’s out there and as data professionals, it’s our job to protect that data. So, are you ready to get into the types, Carlos?
Carlos: There you go, let’s do it.
Tom: Alright. So there’s three different types of data encryption, currently within the SQL Server platform, and we’re going to strictly narrow our focus on there. And when you’re talking about going to the cloud, some of them are as easy as doing a checkbox, but our concentration is going to be a little bit more to the on-prem, but they’re available in both, so don’t hesitate away from that, because it’s a little bit easier, actually, if you’re in the cloud. So first of all, we’re going to talk about transparent data encryption, and then the other types, we’ll briefly mention them, come back and discuss them a little bit in further depth, and that is cell-level encryption and Always Encrypted. So, both transparent data encryption and cell-level encryption, Carlos, came in, in 2005. They’ve been around that long, and I’ve actually been using transparent data encryption since 2005. Did you know that?
Carlos: It has been a long time.
Tom: It’s been a real long time. And there’s some great, great blogs out there, guys, to show you, actually, how to do it because it’s been out there so very long. Transparent data encryption is really important, more from the standpoint of protecting data at rest.
Carlos: Think like your backup files or your things like that.
Tom: Exactly, your backup files, things like that and if someone did actually even get hold of your MDF or your LDF files, then they would be encrypted, and they wouldn’t be able to restore them. One thing to denote when you use transparent data encryption is you can go turn it on tomorrow or today in your environment. Transparent data encryption does not affect your code at all. It’s strictly behind the scenes. I’ve actually even rotated my transparent data encryption certificate during the middle of the day, and you’re like going, “what?” Yes, it will allow you to do that and you can watch its percentage as it’s happening.
Carlos: Wow. Now from a TDE perspective, would you go ahead and suggest that folks, I don’t want to say ‘turn it on by default’, but if they’re thinking about encryption, that this is the first step?
Tom: It is definitely one of the first things that I would turn on, because as we get in a little bit further into it, in talking about data and we talk about how to encrypt data and what to actually encrypt at the cell level, there are some portions of data you’re not going to encrypt necessarily at the cell level. Why would you think that would be, Carlos?
Carlos: Well, I have a little advantage here, in that we’ve talked about this before, and so one of the challenges with encryption is that then doing things like JOINs or comparisons then becomes very difficult, because all the information’s encrypted.
Tom: Yes, that can definitely cause you problems and stuff and some of the other things is just right up front to let people know what about performance? Performance, I’ll tell you that my top 3 most resource-intensive stored procedures enquiries happens to deal with encryption, of encrypting and decrypting this data. Now the application probably does that more frequently than it really should, but that is my top 3 most resource-intensive queries.
Carlos: Interesting, and we generally attribute the uptick to CPU.
Tom: Yes, yes, exactly. That’s where you’re going to see the huge uptick is, and I won’t say huge, it’s probably less than 5%, but the thing of it is, is that is the uptick is where you’re going to see your performance, because all your encryption and decryption actually are happening on the CPU, not in memory.
Carlos: Right, right. And so this can be in a sense good news, because for the, dare I say it? So without knowing your individual circumstances, compañeros, but in the vast majority of environments that I’ve seen, CPU is generally not the problem. There’s, again, the 80/20 rule here. Generally, that 5%, the databases have that to give. So I haven’t seen that, generally, as being a huge or insurmountable hurdle to pass when we talk about implementing security for a lot of these folks.
Tom: And that’s very true and let me also go a little bit further into that area and say that the most resource-intensive queries on my system right now are still using the old cell-level encryption, which is a 2005 methodology, and that one, basically, because it is decrypting and encrypting on the SQL Server itself, then that’s what’s using all of my CPU for the memory. But guess what? Always Encrypted moves it to the web or app tier.
Carlos: Ta da, and hence, one of the differences. I guess it’s important that we call that out, because we’ve talked about Always Encrypted on this program before, and ultimately, it’s a column- or cell-level encryption, but there are two different flavors of this. So there is the older version, which doesn’t even have a name. I guess the marketing people were not around that day when they came out with this feature and so commonly just called, which again, kind of makes it confusing, column- or cell-level encryption.
Carlos: And then there is Always Encrypted. Same ultimately idea, but different implementations, strategies.
Tom: And let’s talk about what those differences are. So let’s step back for a moment and do realize that Microsoft, when you start encrypting, Microsoft’s going to make you open up your pocketbook. So if you’re going to be using transparent data encryption, or TDE for short, you are going to need the Enterprise edition. Now, if you’re going to be serious about your encryption and auditing and stuff, you’re going to have to run Enterprise. I’m sorry, but you’re going to have to run Enterprise if you’re on-prem. If you’re in the cloud, guess what? There’s only one flavor, so it’s all there, you’re paying the same costs, so that makes it a little bit different, maybe, if we’re going up there to the cloud. So cell-level, again, you can put it all the way back to 2005 and it was Enterprise edition, too, but cell-level’s harder to implement because you’ve got to go make code changes to implement cell-level encryption. It is not something that just, you turn it on and it happens. But guess what? Always Encrypted, when it first came out in 2016, was Enterprise edition, but Always Encrypted is now Standard in SP1. And the nice thing about Always Encrypted, Carlos, is you can turn around and actually implement that with very little changes and possibly none to your database to put Always Encrypted in place and we’ll talk about that a little bit more in depth. So let’s talk about the different flavors of Always Encrypted.
Carlos: Okay, here we go.
Tom: There’s actually two flavors, Carlos. When you’re turning it on, you can either turn it on for randomized or you can turn it on for deterministic. So, when you turn it on for randomized, number one, make absolutely sure, and I don’t use it for this reason, you’ve got to make absolutely sure that no one will ever want to do any searches or groupings or equality or joining or anything on that column, if it’s randomized. It is the absolute most secure thing you can do.
Carlos: That’s right, and yet with the idea of being here, so that if we were going to use as the example, there’s probably a few more Tom’s than there are Eugene’s and Carlos’s in there, but you never you never know, depending on what your data source looks like. When it encrypts that, all of the Tom’s are going to get a different computation, if you will. So if you were to look at it, they’d all be different in the randomized option.
Tom: Exactly, exactly. So randomized might be good for passwords, but that’s the only area that I might even come close. All of mine, Carlos, that we have, and by the way, we have all of this encryption running all three flavors running in our production environment. We actually use deterministic today, and deterministic gives you the ability to join, it gives you the ability to filter but the thing to denote in the 2016 version of it, it’s got to be an equality. You can’t do a range. You can’t do a like on the data in 2016 version of it.
Carlos: Gotcha, so just equals.
Tom: Just equals. So, guess what’s coming in 2019?
Eugene: I know.
Tom: 2019’s going to give us that ability to be able to do likes and ranges and stuff like that with it. It is very interesting and something that I’m beginning to dig into, but it’s one of those that it takes a lot to get it set up on an on-prem situation.
Carlos: Yeah, no question.
Tom: Yeah, there’s a lot of things.
Carlos: Now you had given us again, so you mentioned obviously you’re using encryption here. You had given us a couple of ideas or places where folks might want to start thinking about putting encryption in.
Tom: Yeah, when you’re looking at your data and you’re reviewing your data, you’re looking at several different fields, and let’s just go ahead and talk about those fields and some things that basically I do when I look at what columns do I encrypt? Now remember, earlier, that I said my three worst performing queries have to deal with encrypting and decrypting. So as I look at the data, there’s laws that you have to pay attention to. So, some of those laws are PII, personal identifiable information. You’ve got the GDPR that came out in Europe, and you’re like going, “but Tom, that’s Europe, we don’t care about Europe, we’re just US.” Well, California almost mirrored that law and it’s going into effect January 1, 2020. Did you know that?
Carlos: Fun times.
Tom: Fun times, so if you’re not dealing with this, you’re going to have to deal with it, unless you just cut off California and say you’re not doing business in California. Eventually, you’re going to end up not being able to do business anywhere because all the governments are doing it.
Carlos: And here, I thought you were going to say eventually California’s going to fall into the ocean.
Tom: Well, they could.
Carlos: Different topic, I suppose.
Tom: Different topic, there. Let’s just talk about some different fields and talk about encrypting. So, if you’ve got your pen and paper, guys, go write these down and kind of look at them. You’ve got your first name, you’ve got your last name, then you have a name field that might have your first name and last name in that field. You have your birth date and address, email, phone, tax ID or Social Security Number, driver’s license number, medical evaluation notes, a MAC address, an IP address, and much, much more. So, what would you encrypt there, Carlos?
Carlos: So, the ones that stand out to me are going to be tax ID number and driver’s license number. While it’s not impossible that you would want to run a report on those specific pieces, I tend to see that as information that you need for reporting purposes but not necessarily for sorting or row identification. So they are sensitive and they’re also unlikely to be used.
Eugene: Yeah, this sounds like a trick question to me, because, well, I mean all of that sounds like personally identifiable information.
Carlos: That’s also true.
Tom: It is, isn’t it? It could be all personally identifiable information. It is a trick question to make you think about it from a performance standpoint. Because what you turn around and do is you– the way that I personally look at it, and Lisa’s helping vet this for me, is basically if the field, the one field can identify you, the one field, then it’s encrypted. So for example, if you have the full name in a name field, you’re going to encrypt that, would you not? Yes, I would encrypt it. If it’s got the full name in it. Most of us, hopefully, have our first name, last name broken out in two fields to be able to search by it. So that would be one that I would encrypt because that one field can personally identify me. But if you have multiple fields that identify you and you’re correct also, in the fact that those multiple fields, then you take other avenues of basically protecting that data, i.e. DTE. I.e. doing a SQL audit on it to know that basically, okay, this person’s selecting the data and what are they doing with that data? Even in my Reporting Services instances, I’ve got a folder that basically says, here is my non-secure reports and here’s my secure reports. If it’s pulling out PII or HIPAA data or PCI credit card data or whatever, it’s in the secure report and I basically have my secure report ability not to email those reports. You cannot select from Reporting Services and email those reports. It will not let you and create a subscription.
Carlos: There you go. Now that’s interesting, so we talk about encryption, and we might think of it as that being the silver bullet, but in that example, we still need layers. There’s still layers of pieces that we can add to really secure our information.
Tom: Correct, because when you’re sitting in front of an auditor, which I did for 17 years, I worked at a credit card company, and the thing of it is, is they’re looking at what you’re doing to actually protect the overall data set that you’re dealing with. It’s not just encryption. Encryption is a huge part of it, because if someone steals your database and does get hold of it and you don’t have TDE on and they can restore the database, then that’s a problem. And you know, data breaches, I’m like going, if you’re on SQL Server and you’re having a data breach, they’re basically going to have to run a report to get all of that data. They shouldn’t be able to restore your database, because you should have TDE on and then they can’t restore. You can’t even take that database to a QA environment without basically taking your certificate and putting it on the other environment, and then you can restore the database.
Carlos: Yeah. Speaking of, I don’t know if it’s complications or steps that you need to take we talked about some of the tactical pieces to implement this. Another consideration in all of this is that in order to implement encryption, I’m going to have to use a certificate. Which then kind of brings its own set of administration requirements to itself, because any time I encrypt, I have to have that certificate. So could we talk quickly about certificate management and maybe thoughts around how you keep those pieces safe and ensure that you always have them? Particularly like restores or moving that data around from place to place?
Tom: Sure. So, first of all, TDE’s certificate is actually on the Windows system, you can actually see it in the master database. We actually rotate ours on a yearly basis and then we back it up, we make sure that it’s on a disc with the backup drives. Because we do rotate annually, we do have several of those certificates sitting around in case we need to restore an older database than what the certificate’s currently protecting. Now when you go to Always Encrypted, Always Encrypted basically has an encryption key, but it can actually be stored in either the Windows Certificate Store on the server. Yes, database people, you need to learn how to work with the Windows Certificate Store. Or you can actually put it up into Azure Key Vault or a key storage provider. Ours is currently in the Windows Certificate Store on the local machine, but we are, this year, going to move to Azure Key Vault and put it up there, and what we’re hoping with that is it’s going to make it easier, basically, to rotate that key on an annual basis. Right now the column master key, Carlos, when you’re setting it up, the column master key has to be on the SQL Server, but as soon as you get it all set up, that column master key gets moved off to your web or app server, because all the encryption then with Always Encrypted is happening through the .NET layer.
Carlos: Right, up there, yeah.
Tom: Yeah, and it’s got to be with the 4.6.1 or higher version of .NET.
Carlos: So you mentioned changing those certificates yearly. I imagine that when you change a certificate, does it have to go through and do a re-encryption or does it just automatically accept that new certificate, or is there some magic, there?
Tom: Well, when you’re doing it with the TDE level, it does go in and re-encrypt the data and like you heard me earlier, I’ve actually done that live during production, during the day. It does it in the background.
Carlos: Gotcha, that’s right.
Tom: But as far as Always Encrypted, it actually goes around and when you change the certificate, it basically changes the column master key, which is protecting the column encryption key, which actually encrypts the data, so you’re not really having to re-encrypt the data.
Carlos: Gotcha, okay.
Tom: So that’s what it’s protecting. Now we did not talk about cell-level there. The reason we didn’t talk about cell-level is if you’re going to do cell-level encryption, number one you shouldn’t be on 2008 or 2008 R2 anymore, because guess what, it’s going out of support. But for 2012, you could use it. But why? Get up to 2016, because Always Encrypted basically goes in pretty much very easy to get it in. we did it with only a few minor hiccups that we had to change and one of those hiccups, Carlos, we ran into is that the data type, the length of my varchar field was not the same on the table as it was in the stored procedure parameter.
Carlos: Oh, interesting.
Tom: So, how lazy are we, right? You’re going to find out if you turned it on and you read it and you’ve been real lazy and you hadn’t looked up what that field type is. So that is one of the things that bit us, but that was it. We turned it on and besides the guys having to leave .NET Core, which they grumbled all the way back to the previous .NET version, it just worked.
Carlos: Ta da! Okay, so it’s going to be your developers who are going to be happy about that driver announcement, then.
Tom: Yes, my developers are going to be exited about that new layer.
Carlos: Well, there you go. Okay, so other thoughts or first impressions that people should consider if they’re going to try to implement encryption?
Tom: One is, of course, always do it in a QA environment and make sure everything’s working and stuff. Besides, TDE– I even have TDE turned on in my development area. We started a new project earlier this year, and when we started the new project, we looked at all the fields and we started encrypting immediately, and they were mad. All my developers were mad. “I got to deal with encryption?” “Yes, day one, you’re going to start dealing with encryption.” So start immediately, as soon as you can. If it’s an ongoing project, go ahead and put it out there and realize if they’re on .NET Core, until you’ve got this new driver, that you’re going to have to– might have to do some work. And realize, too, 2019’s going to bring all new availability to you to do the likes and ranges.
Carlos: Right, the functionality. Yeah, that’ll be very nice.
Tom: So make sure if you’re doing Always Encrypted, though, today, before you get to 2019, if you’re on 2016 or higher, just remember that you can only do full equalities there, so that’s very important. If you’re going to need to do likes or ranges, don’t encrypt that field.
Carlos: There you go. Okay, so shall we go ahead and do SQL Family?
Carlos: All-time favorite movie?
Tom: Mama Mia.
Carlos: Mama Mia, that’s right. So I think we have asked you. We actually did have these questions last time you were on, because I feel like I remember that.
Tom: Yes, sir.
Carlos: Okay, here we go. So city or place you most want to visit?
Tom: I think we’ve traveled around the world pretty much.
Carlos: Well, it could be re-visit. I don’t say that it has to be your first time.
Tom: Probably two of my favorite cities would be Prague and Salzburg, Austria. Salzburg is just gorgeous. And if I go my second favorite movie was Sound of Music. It was filmed in Salzburg.
Carlos: Salzburg, there you go.
Tom: But they know nothing of it, so when you go there, don’t ask them about it.
Carlos: Don’t ask them about it.
Tom: They do have a tour, but they’ll tell you that the locals know nothing of it.
Carlos: Gotcha, that’s funny. Yeah, just go start singing in the hills.
Tom: That’s right.
Carlos: I’m sure people will catch on. Food that reminds you of your childhood?
Tom: You probably remember this one, shrimp.
Carlos: Prepared a certain way?
Tom: Any way, because remember my dad had a boat and we went shrimping in the Gulf of Mexico and just brought back loads of shrimp.
Carlos: Ta da!
Tom: All we had to do is pay for the gas of the boat.
Carlos: Very nice. yeah, so it all of a sudden reminds me of that scene in Forest Gump. All the different kinds of shrimp.
Tom: Yeah, yeah.
Carlos: Okay, our last question for you today, Tom. If you could have one superhero power, what would it be and why do you want it?
Tom: Flying. I would like to fly. I do like to travel, so I would love to just fly to wherever I want to go.
Carlos: Fly, fly like an eagle.
Carlos: Very good. Awesome. Well, thanks again, Tom, for being on the program today. We do appreciate it.
Tom: Alright, thanks, Carlos, for having me again and it was great talking to you guys.
Carlos: So that’s going to do it for today’s episode, compañeros. Hopefully you have gotten a little more information about encryption and we’d like to hear about your stories about how you’re encrypting. Hopefully not horror stories, but you can share those too, as well. Don’t forget to use #sqltrail to enter to win those shirts. And you’re welcome to connect with us on social media. Tom, how can people connect with you?
Tom: They can also connect me on social media as armordba on Twitter or armordba is also my blog, which I don’t do a good job on it at all.
Carlos: It’s tough.
Tom: Catch me at SQLSaturdays. I will be in Atlanta and Virginia Beach and Dallas and I forget where else I’m going. I’m going several places in the next couple months.
Carlos: There you go, check the schedule. And Eugene, who did rejoin us again, here, at the end.
Eugene: Yes, I am here. I’m a real boy, I swear.
Carlos: How can folks connect with you, sir?
Eugene: Yeah, you can follow me on Twitter at sqlgene or I just came out with a Pluralsight course on Power Query, so go watch that and help pay my mortgage.
Carlos: There you go. And compañeros, you can connect with me on LinkedIn. I am @Carlos L Chacon and I’ll see you on the SQL Trail.