Episode 186: Analytics & Security: Find Pain Points, Make a Plan

Episode 186: Analytics & Security: Find Pain Points, Make a Plan

Episode 186: Analytics & Security: Find Pain Points, Make a Plan 560 420 Carlos L Chacon

2020 dawns a first for our podcast. This episode is dedicated entirely to a listener question. We’ve had questions before; however, this episode the team tackles two questions from longtime listener Trent Adams. The context of his questions surround the concepts of IT having the ability to provide new functionality to the business and the business appearing to be uninterested in moving forward. While we don’t know the entire situation, we discuss the best way to identify pain points and ways to introduce new technology without imposing new rules/processes on the business.

We would very much like to have more listener inspired episodes this year. If you have something you want to share with us, head over to sqldatapartners.com/podcast and submit your question and we’ll try to help you on the SQL Trail!

Financial Intelligence for IT Professionals

Episode Quotes

“When you understand what a debit memo and a credit memo is, when you understand what year-over-year growth is, when you have these words that mean something to the accounting portion of the business and the owners of the business, that makes it so much easier to implement analytics in a small business.”

“You start out with the things that are going to be most important to people, and it is critical that you find a champion on the business side, because IT-driven analytics projects tend to fail, if they’re trying to force a method onto the business people who don’t care about it.”

“A company will spend millions of dollars to clean up a problem, but they wouldn’t spend the $500 to prevent the problem. Treatment always gets more money than prevention.”

“Have those plans, have those relationships, start showing tangible benefits, and you’ll see more movement than if you just sit there and say, ‘I want to do this thing.’”

Listen to Learn

​00:38     Intro to the team and topic
01:35     Compañero Shout-Outs
01:53     Compañero comments on episodes
04:12     Trent Adams has been told there is no need for analytics at his job
09:31     Analytics might not be exactly what your boss thinks it is
13:09     You need to understand what the business needs and what the pain points are
15:45     Pushback can also be about the cost of the necessary products
18:32     It might be harder to get growth to happen in some work environments
22:56     If you start with small projects, people will notice and want to do more
25:38     Why contact data may not need to be secured
27:50     When contact data should be secured, and at least encrypt your backups
31:11     Sometimes encrypting is going to affect others…but sometimes it’s not
33:49     It’s sad that sometimes money can only be made available when there is a breach
36:31     Closing Thoughts

*Untranscribed Introduction*

Carlos:          Compañeros! Welcome to another edition of the SQL Data Partners Podcast. This is Episode 186. I am joined today by a motley crew, Eugene Meidinger.

Eugene:        Howdy.

Carlos:            And Kevin Feasel.

Kevin:            Ahoy.

Eugene:          That got me.

Carlos:            We have had comments in the past and when I originally set up the podcast, one of the things that I talked about doing was having listener Q&A and I don’t know that we’ve actually dedicated an entire episode to that before, so 185 episodes later, we are finally going to dedicate an episode to listener questions.

Kevin:            We finally got a listener email that was worth it, I think that’s what Carlos is saying.

Eugene:          Right?

Kevin:            You guys got to try harder.

Carlos:            That’s right, compañeros, you need to step up your game, here. And so he asked a couple of questions, and so the topic for today’s– well, we’re going to talk about lots of different things. So, I’m not really sure what our topic is today, but we’ll get into the question, and then we can kind of go from there. But we do have a couple of shout-outs we want to give. So, first to Paris Winters and then also to Harry Ragsdale, so thanks for reaching out. And then for this episode, the show notes are going to be at sqldatapartners.com. Of course, you can go to /podcast, or in this case, /186, for this episode. Okay, so I am going to change things around just slightly. This is perhaps a bit of a shout-out, but we did have a couple of comments on prior episodes that I want to get into before we get into Trent’s stuff, and this is long overdue, and so Sebastian Golbert, you’ll forgive me. So Episode 176, we were talking about storage options, and he says, “I want to mention an extra use case for direct query and that is an aggregation of a big fact table. It involves importing the fact table in the underlying model with direct query (only a preview is actually fetched) and then creating a copy of it with Power Query (by using a reference), aggregating it and then switching the aggregate table to import mode. This way it is possible to use the aggregate table for visualizations, which is much faster than direct querying an aggregate table, which involves a SQL aggregation command every time.” Interesting, so kind of another potential, I don’t know if a tweak, but another way to get around some of that getting the data in and out. So, thanks Sebastian, for that comment on Episode 176. I guess, did you want to chime in there at all, Eugene?

Eugene:          No, that’s interesting, and it’s neat to see somebody getting into the weeds with some of this stuff. So, I’ll definitely keep that in mind with future projects. I like it.

Carlos:            On Episode 180, John Spanos says, “Thank you for your timely update on PolyBase for SQL Server 2019.” So, one of the things he’s excited about is support for external table that’s now in the on-premise. It was only available in Azure SQL Database, and so one of the worries or concerns that he had is that he’d have to have basically different versions, one for on-premise, and now one for Azure SQL Database. Now that it’s available, he can have the same code for the data warehouse for both on-premise and Azure SQL Database stuff.

Kevin:            Well, for Azure SQL Data Warehouse, yes. Azure SQL Database doesn’t have PolyBase. They have external tables for their elastic, “I’m going to connect one Azure SQL DB to another,” but they don’t have, at this point in time, the ability to say, “I want to connect to Blob Storage or to Oracle from Azure SQL DB.”

Carlos:            Gotcha. Yes, so perhaps he was talking about the Azure SQL Data Warehouse, then. Yeah. Okay, so, more features on the way, then, so that will be interesting to follow. So thanks, John, for that comment. Okay, so now this question comes from Trent Adams. So Kevin, do you want to review with us the question?

Kevin:            I do, I do. So, the question is, “What does one do when they’re told, ‘we have no need for analytics, no need to secure our data?’” Trent has taken the company to using AlwaysOn availability groups, implemented different methods of securing data and has some questions about follow-through. So, there are a couple of questions in here, as bonus points, I guess. The two questions: first, can a small business use analytics? Second, should data be secured even if it’s addresses and phone numbers and other contact info? So, those are the two topics of discussion. I’m going to say, let’s pick one, dive into it.

Carlos:            There we go. The first one is “we have no need for analytics.” Shall we tackle that one first?

Eugene:          Sure.

Kevin:            Sure, cause that is something that I have heard from companies, and it’s short-sighted, honestly.

Eugene:          Well, we’re missing a critical piece of this whole story. I mean, I don’t think that like, whatever deity you subscribe to was booming from the heavens and told him, “there’s no need for analytics, no need to secure the data.” So, the key question is, who is telling him this? Is it his boss? Is it users in the business? Because there’s a couple things. I worked at, I would say a medium-sized business at my last job. It was weird, cause it was two companies owned by the same people, so there was some overlap, but for the fire protection side, there was maybe like 130 employees. So not small, small, but not huge, either, and we definitely had a use for analytics, but I feel like this is one of those tail wagging the dog kind of scenarios. Like he goes to a conference and sees, “look at all this cool stuff we can do, I’m going to try and bring that back to the business.” And I think the important question is, what is does the business need on a daily basis? Do you understand their operational model? And you want to work from there. You want to work from, “what pain points do my colleagues deal with?” The way that I like to think about it is a lot of reporting is this pyramid, and it sounds like he’s trying to take care of the middle part of the pyramid. He needs to start at the foundation if he hasn’t already. So, this foundation is operational reporting, cause when you are in a small business, you need reporting for just the day in, day out stuff. Now hopefully, some of the existing ERP systems or what have you, produce this, but at my last job, we were producing invoices out of SSRS, we were producing work orders, we were producing time sheets, all this stuff, things that you might actually print out or hand to a colleague, or whatever. And these were not about analytics, per say, right? Somebody’s timesheet is not analytics, a work order is not analytics, but those needs of the business are generally the more urgent, important needs. So, the first thing is make sure that you have operational reporting in place, and then you can start to build off of that. But the next thing is, like I said, to understand, “well, what does your business do?” I know that whenever I started working at that job, like 8 years ago, I thought technology was king. I thought, “okay, the most important thing is the technology.” And I didn’t have enough appreciation for the intricacies of the business and what it did and what the business users cared about. It’s really important to be able to take that focus and understand, “okay, well, what is their pain point?” Because if you can understand where they’re running into an issue, like, I’ll give you an example. For the IT side, we had an issue with tracking utilization for our techs. How much of their time was spent working on billable work and how much was spent on other things? That was an area where analytics was a big deal. So, you understand those pain points, you can build out a small proof of concept, and work with the business user, collaborate with them to say, “hey, does this meet your needs?” And so, if you keep it small and agile, you can do this without making a bunch of waves, and so that’s why, going back, it’s really, really important to understand who’s saying this. Is it their boss? Because if you boss is saying it, well, you can decide to say, “you know what? I’m going to do some work on my own time, you know, a small proof of concept. I’m going to collaborate with one of the business users and see if I can get something. And if I can get something that they value, now I’ve got some buy-in and I can grow it out. One other thing, before I finish my rant, there’s a great book, I want to say it’s called Financial Intelligence for IT People. I’ll find the actual link and I’m sure we’ll put it in the show notes. But it explains a lot of these accounting terms, like what is a profit and loss sheet, all this kind of stuff, and that makes doing analytics with the business so much easier. Cause when you understand what a debit memo and a credit memo is, when you understand what year-over-year growth is, when you have these words that mean something to the accounting portion of the business and the owners of the business, that makes it so much easier to implement analytics in a small business.

Carlos:            There we go.

Kevin:            Yeah, I am going to say, what am I even doing here, because Eugene just stole most of my answer.

Eugene:          Nailed it. Yeah, you can take the other question. You can tell us why we shouldn’t secure our data.

Kevin:            No, let’s keep talking about this one, because I think there is more to hammer on. And I will take a, like 20% disagreement, with 80% vast agreement. Yeah, totally agree on Laslow’s Hierarchy of Database Needs, that you handle the most important things first. It’s not, “we’re going to start building a robotics project.”

Eugene:          IOT in blockchain, everybody.

Kevin:            Yeah, exactly, exactly. You don’t necessarily start up there, unless your company is IOT in blockchain. In which case, you’re getting a huge amount of money right now to produce nothing of value.

Eugene:          Yeah.

Kevin:            Sorry, did I say that out loud?

Eugene:          Yeah, you might have.

Carlos:            Yeah.

Kevin:            Hi, blockchain. So, you start out with the things that are going to be most important to people, and it is critical that you find a champion on the business side, because IT-driven analytics projects tend to fail if they’re trying to force a method onto the business people who don’t care about it. Where they can succeed, where IT-driven analytic projects can succeed is internal. So, “hey, let’s build out analytics on our development and figure out what parts of our stack are we having the most difficulties with? Where are the most trouble tickets coming in? How can we assign things and smooth out processes?” And this is something that, if you do that proof of concept Eugene is talking about, maybe you get buy-in from the CIO or from the CTO, or if it’s a really small company, from the President/CEO, whoever’s in charge of IT, ultimately. Because that person’s looking for efficiencies. Now, if you’re talking really small company, 15 people, there is still scope for analytics in this world, because you only have 15 people, you don’t have spare bodies to throw at problems. Like, this isn’t IBM in the 70’s where, “oh, we’ll just bring in another truckload of people to throw at this issue.” You have to be able to think through problems and anything that gives you a force multiplier is going to be advantageous, ultimately, to you. So, there are places where you can get those tendrils in, especially if you have some analytics background. If the context of this is, “I know nothing about analytics and what to spend the next two years learning about it,” that can be a really hard sell at a company. Especially a company that is small, because again, you know, if you’re the only data person saying, “well, our one data person is going to go off on walk-about for the next 6 months, and hopefully we’ll see him again after that.” That’s a hard sell to a company. But, if you’re able to tie it in with the regular work, then you start showing some of the benefits. Like, if you are a database administrator, let’s build some analytics on uptime. He mentions building out an availability group. Alright, you’ve built out availability groups, do you have the measures to show, “hey, here were times when things failed over. Here were times we were able to patch, we we’re able to increase our uptime to this number.” That is the technical operation. You’re building up some of these muscle memory steps that you can then apply to future analytics projects. And from the person who’s saying, “no, we don’t need analytics,” to that person it’s not analytics, because, building up a strawman, here, I think that person’s thinking of analytics like the way I said where “yeah, we’re just going to send a person out for 6 months on a peyote-fueled mission and they’re going to come back with a system that will do something that’ll make a robot’s eyes blink.”

Carlos:            Sure.

Eugene:          Well, or even just that in their mind, analytics is more higher up on Maslow’s Hierarchy with the Machine Learning and the Predictive analytics, and because Trent most likely hasn’t articulated the pain point of the business, it’s presumed that this is something that’s going to be prescriptive in telling the business what to do, as opposed to maybe a little bit more further down that pyramid and on the descriptive side of like, “here’s our current situation.” I think the moment you can ground it to an actual pain point, suddenly it’s not, “analytics” anymore, it’s like, “oh, this is a report,” in their mind.

Kevin:            Right. Yeah, and by the way, thank you for subtly correcting me on Maslow versus Laslow’s Hierarchy of Needs. Ron Swanson’s Hierarchy of Needs is better than both of them, but.

Eugene:          Right.

Kevin:            But yeah, picking up on that, you know, cutting out Carlos even further, you’re right, for somebody who is looking for a specific need to fill, that person may not think of it as analytics. But again, there may be a champion on the other side, on that business side, who actually is interested in analytics. It could be somebody in finance, like the finance person, “oh, I’ve got one or two people who help with AR and AP and they’re kind of overwhelmed. Can we help these people out?” And that’s where talking to other people on the business side and trying to understand where are they suffering? Where are those pain points? What can we, as developers, as administrators, do to help make those lives a bit easier? And some of that will be analytical in nature and it will be understanding the data, it will be understanding the needs behind this problem, and trying to come up with a solution. That solution may not be incredibly complicated. It may not require neural networks and dozens of boxes with GPUs in them and all kinds of really cool stuff. It may just be a relatively simple model that you build in a notebook and come up with some numbers that say, “oh, okay, well, I think these are your customers that are highest risk of leaving,” or, “these are the customers that are highest risk of non-payment.” “Maybe we’ve noticed that we’ve got return because of these reasons.” Or, on the invoicing side, that “if we don’t keep hitting these customers, they’re just not going to pay us.” So, there are places where analytics will get in, but it’s not analytics for the sake of analytics. It’s analytics to solve important business problems.

Carlos:            Yeah, I mean, no surprise, I think we’re all in agreement, here. Maybe one other consideration, the pushback can also be about the cost. Cause you can go from zero to lots of money pretty quickly, with some of these tools, and if there has been any investigation, I mean, Power BI’s come a long way, and of course, they’re kind of touting the $10 a month, but it wasn’t all that long ago, that, “okay, hey, let’s go with a Tableau or even a Click, or something like that, and it’s, “well, that’s $1500 a user,” and then all of a sudden, the math adds up really, really quick. I mean even the Power BI slider, we go from $10 a month to 5000. And so, I think we’re all saying the same thing, but they don’t necessarily want the tool. What they want is the problem solved, the pain point piece there.

Kevin:            Yeah, it’s about providing marginal value. If you’re able to provide that value at the margin, you may have to adjust expectations, because we have different expectations of where the margin is, and apparently the strawman person that I’ve built from this email, because we don’t know the people involved. But the strawman person I’ve built probably says the margin is a little bit closer than the emailer, Trent says, where Trent’s probably thinking, “hey, there are some really good cases here in the company where I can help solve problems.” And it’s all about finding the people who think that margin is a bit further out, or working to convince people that “yeah, look, we can take these steps,” and that updates your priors, basically.

Carlos:            Right. The other benefit that I see, using your approach, Kevin, you talked about us kind of building internally and getting to know some of the tools and obviously we’re– well, this podcast, anyway, is very pro-Microsoft-oriented. But it won’t take very long for people to be defeated or to be like, “hey, that’s a great idea,” and then that idea, like if you can’t deliver on something pretty quickly, then the idea can get scuttled just as quickly. And so that idea of getting that hands-on internally, kind of taking some of your lumps and going through the process. I mean, we’ve talked about Power BI and how you approach the analytics slightly different, again, from a data perspective, from SQL Server, the mentality shift that you have to have. So, taking on that project for something that you can use internally, if you will, or for your own purposes, can also play dividends, because then when you’re ready to actually engage with others, hopefully, you’re a little more up to speed and then you can deliver faster, because that’s when you’ll also be able to provide a lot more value. Yeah.

Kevin:            Sure, so anything else before we move onto question number two?

Eugene:          I don’t think so.

Carlos:            Well, I will say, and I think Eugene mentioned it in terms of getting to know the business, and we talked about it before we hit record, but there is a consideration from just a personal growth perspective. I was actually at a chairman’s reception for RVA Technology last night, and we were talking with some of the older guys, and they were talking about digital transformation and how hard that is for the organization. So sometimes culture fit just may not work. Like, “this is the way we’ve always done things.” And that can be great for an analyst or, you know, a CFO, a manufacturing plant, potentially, although I’m sure we can make arguments that that’s not real. But if you’re looking at your long-term career, and I think of an experience going back to working for the state, so I worked for the state of Virginia, and I don’t begrudge any of you folks who work for the government; somebody’s got to do it. But I know that I was pretty young, I was still in my 20’s there, and I was looking around and I’m like, “I gotta get out of here.”

Kevin:            That’s exactly my feeling, too.

Carlos:            Because lots of folks were looking, I mean, they were like, “hey, I’ve got, whatever it was, X number of years until retirement,” and they were kind of waiting out the clock. And again, “this is the way we’ve always done things. I don’t need to innovate.” I knew that in my 20’s, I needed to innovate. I needed to do something different, because I didn’t want to be watching the paint dry, if you will, for 30 years. So, if you go through these processes, and it’s not successful, then there is that, I guess real possibility that it might be time to move on.

Kevin:            Yeah, exit is certainly an option, and even within working in state government, I had 5 years at the State of Ohio. My experience was colored by having a CIO who was really, really good and drove that, and this was also a very small agency, so was not nearly as sclerotic as a lot of other agencies were; that was a benefit. But even within those, maybe especially within those, there are definitely opportunities for advancement in terms of building out analytics projects. Now you’ll get quite a bit of, “this isn’t worth it” or short-timerism, “I’m only here for another nine years.” Yeah, it’s like, “wait, you realize what you just said, right?” That’s a lot of clock to run out. That’s like, “we got a three-point lead in the second quarter, time to start running ball.” So, despite that, it will probably be harder in those scenarios to find people on the business side, but there still are people are the business side. You know, there are still people who will say, “yeah, I actually do have problems I want to solve. I actually want to do something this year,” and you find those people and you work with those people. It is nice when you have cover from people higher up in your chain who are supportive, but part of that comes from success breeding success. That if you’re able to launch something small-scale that is successful, that does provide tangible value, then the story becomes a lot easier to sell. It’s harder to sell when it’s, “I’m going to build a giant system that’s going to solve a huge number of problems, but it’s going to take me three years to do it and I need full company support.”

Carlos:            Exactly.

Kevin:            That’s almost never going to go over. But, “here’s a two-week project that I worked with somebody over in HR and we were able to come up with a process to find, here are the employees who are most likely to quit in the next three months, and maybe managers should go talk to them.” Shorter-term, with tangible out-puts with  likelihood of success, then you can say, “hey, we drove that project, let’s try this slightly more complex project.” And it will also bring up more people from outside. They’ll say, “wait, this is the guy who put together the HR project. I want to work with this person on my particular problems.” And you start to see success that way, and it certainly softens the, “we don’t do analytics here” mindset, when you start seeing people succeed and chatter within the company about successful projects.

Eugene:          Yeah, reinforcing that, I think it’s worth stating that a lot of the things that you can do to build social capital, to build buy-in, to build investment from the business, to build a rapport, is very unsexy work. It’s most likely going to–

Kevin:            Talking to people.

Eugene:          Well, sure. But what I mean is like, the stuff that they probably need right now is data extraction from your accounting system, or your ARP system or your whatever operational systems. If you talk to someone, they’re probably going to be like, “hey, I just need to get this data into an Excel file.” And you’re like, “but I want to build a data warehouse with ColumnStore,” and they’re like, “Excel file.” And that’s kind of the thing is, the analytics stuff, the pie in the sky stuff is exciting and sexy and you feel like you’re going to learn all of these things, but if you want to kind of build that snowball and start to get some real traction, you need to start with this small, little thing of, “okay, I’m going to set up a connection to this table,” or ideally, you’ve some copy of the data, especially if you have a readable secondary, “okay, I’m going to set up this Excel file to read data straight from the readable secondary, here you go.” And they’re going to appreciate it, and then you start to build that social capital to work your way up to bigger things.

Carlos:            Yeah. So, we actually have one other example, that admittedly we’re still working on, so SQL Data Partners has a relationship with a company called EPMS, which is a printing– they build printing software. And anyway, they had a conference and some of their users came back, like, “hey, we want visualization reports,” and so that’s how ultimately, we got involved. And one of the things that was interesting is that the organization was kind of pushing us to build reports, but in talking to some of the users, what they really wanted– they wanted visualizations, but what they really wanted was the ability to get into that data a little bit easier. So many of the reports, they would kind of break open the stored procedures that the company had written and then try to tweak or add columns or what have you, for their own purposes, but they would very quickly exceed their technical capabilities, and so they were very frustrated with that. And so, what became clear is that, yes, while they may want some reports, what they really needed was a good data model that they could then use and be able to pull these things and using a tool like Power BI to be able to interface with that. And so it was an important shift in thought, because it did change the way that we were approaching that relationship a bit.

Kevin:            That makes sense. Alright, so the second question. Should data be secured, even if it is addresses and phone numbers and other contact info? I promise that I will take the devil’s advocate on this one, so let’s see what Carlos and Eugene say and then I will take the opposite attack.

Eugene:          Oh, fun.

Kevin:            Just to make this fun.

Carlos:            Well, I’m not sure the opposite, I guess my suggestion was go back and listen to Episode 171 with Tom Norman where we talked about SQL Server Encryption and he kind of went through some of those like, “hey, here are these columns, would you or would you not encrypt?” Yeah, so it’s a tough one. So, I guess Eugene, what are your thoughts, here?

Eugene:          Yeah, no, I’m going to take the– I don’t know, pessimistic isn’t quite the right word, but I’m going to say, in a lot of cases, no. I mean the way that I would approach this is, “okay, let’s imagine a breach. What is going to be the cost and the risk to the business,” because this is a small business, so there’s a number of priorities. There may be a situation where, okay, if we just get a million dollar cyber insurance policy, or data breach policy, that that’s actually going to cover this issue. And so, he mentions addresses and contact information, and we were having the discussion before about, “okay, well how much of that is actually PII?” So, again, this kind of circles back to the prior question, but if I were in this situation, I would try to imagine myself as the CEO caring about the whole entire business and the biggest thing is the business surviving. Especially if this is a small business that’s probably family-owned or something like that, and so, the question is, what existential threat does this provide? Now, that being said, if there’s a super easy way to do it, awesome. Like, if you can just flip a switch and turn on transparent data encryption and that meets what you’re trying to do, great. But, you know, for some of these things, it might require changes to the application if you’re encrypting columns or something like that. And so, yeah, I mean for me, I would say very much, “okay, what’s the actual risk to the business if there’s a breach, if there’s an issue?”

Kevin:            Okay, since I promised to take the devil’s advocate, I’m going to argue, yes. In reality, I think I ca– I lean closer to Eugene. I was actually expecting to take the ‘no’ on this one.

Eugene:          No, I get it. I threw you a curveball. You’re just going to have to deal with it.

Kevin:            Yeah. Yeah, so here’s the yes. GDPR includes home address. So, if you’re dealing with European customers, in order to be GDPR compliant, you better have a way of dealing with home addresses and ‘dealing with’ includes securing it, includes the possibility of eliminating it under Right to be Forgotten. So, yeah, home address, phone numbers, anything that can be used to nail down a person is technically considered, you know, PII, it’s considered that Personally Identifiable Information. So, if you’re storing names, addresses, phone numbers, yeah, you want to secure that. If you have backups– hopefully you’re taking backups. If you’re not, that’s a bigger problem. But, encrypt the backups, that’s trivial. That is built into SQL Server, newer versions of SQL Server it’s extremely easy and really new versions of SQL Server, you can actually compress that without having it blow out your database backup size. So, encrypt those backups. You can use transparent data encryption, it’s a great way of checking a block. Whether it actually does anything for security is a different question, who’s answer is ‘no’.

Carlos:            Well, I think the old, the tape falls off the back of the truck, somebody picks it up.

Kevin:            Yep, so that, that’s for encrypting backups. Absolutely encrypt backups, because going back to the State of Ohio, there was a famous case where one particular agency I won’t mention which agency it is, but their backup policy was to give the intern all the backup tapes. Intern’s car got broken into and someone stole the tapes. All those database backups were unencrypted. The intern got fired, the person who made the policy to give the intern the tapes didn’t get fired, because it’s easier to fire an intern, I guess.

Carlos:            Awesome.

Kevin:            So, it’s a legit scenario that somebody gets access to those backups. Encrypt those, for sure. Disc-level encryption? There are debates. In general, the answer, I think, is yeah, you usually want to, especially if it is data that is in any way sensitive, go ahead and encrypt that. If you absolutely need blazing fast performance, absolute fastest performance, I can see the argument of not encrypting, but then you don’t put personally identifiable information on that server. Leave it over on a different server where it is encrypted. Using something like Always Encrypted, yeah, talk to Tom if you can. He’s down here in the area, he likes talking to people. Or listen to the episode. Learning about something like Always Encrypted, or even before that, just column-level encryption in SQL Server or simply using encryption built into your application layer, like .net has NuGet packages that will help you encrypt data. Doing these little things, it does require some dev effort, and depending on, regulatory compliance, depending on level of risk, it will often be worth doing this type of work.

Carlos:            Sure. You know, one of the challenges is, unlike the analytics example we had, once you start implementing security, you can’t do it just for yourself. Well, I guess assuming you have a dev server, I guess that would be potentially an instance of, I guess, going through the motions for your own self. But generally, you very quickly get into other people’s, I don’t know if cross-hairs is the right word, but you’re going to impact them.

Kevin:            Oh, yeah, absolutely.

Carlos:            Yeah, Eugene mentioned application changes, and so the barrier to get started can be a little bit higher.

Kevin:            Yeah, if you think about reporting, well, if my report included the address, in Reporting Services, if I was just querying a table, now I’m going to get back some varbinary blob, how do I decrypt that? So, it may involve quite a bit of effort, there. Also, there are limits to what you can do. Every environment has Excel spreadsheets everywhere. How much are you going to do to secure those Excel spreadsheets? And the answer may be, “well, best effort is essentially none. We secure the database and hope that the Excel spreadsheets don’t exist, just magically wish them away.” But I guess it depends on how far you want to go down the rabbit hole, and how far you want to go is going to depend on, “what are the other business requirements?” Like if you’re already doing 50 hours of work a week just to keep things running, it’s hard to then come back and say, “we also need to do a lot of extra work to encrypt these addresses and phone numbers.” Unless you can bring a tangible benefit that, “we do business with a lot of European customers, and with GDPR,” or “we do business with California customers and with their privacy regime that’s coming up soon.” There’s one in California, there are about 6 or 7 states that are working on their own versions, many of which are patterned after GDPR. Well, as those come into play, the answer of, “it’s Europe, we don’t have any European customers” becomes even less valuable, it becomes even less viable. And also, incidentally, if you have an Irish person who happens to live in your city and uses your product, that Irish person is still covered under GDPR. So, even if the likelihood of the European courts coming after you is really low, the likelihood of California courts coming after you is a good bit higher, which means, you’re going to have to do this at some point. So, that’s probably the best sales pitch for doing it.

Carlos:            Yeah, another interesting conversation we had last night at this chairman’s event was how quickly money can be made available when there is a breach or there is an issue.

Kevin:            Oh yeah, yeah, a company will spend millions of dollars to clean up a problem, but they wouldn’t spend the $500 to prevent the problem.

Carlos:            Yeah, yeah.

Kevin:            Treatment always gets more money than prevention.

Carlos:            Right. And so, it’s a bit unfortunate there, but that is, yeah, sometimes the world that we live in. Again, being able to be available to implement those things, also good.

Kevin:            Right, and part of this may just be, have a plan. Walk through the architecture, go through– don’t actually do it, but walk through. What exactly are the steps that you would need? If it’s simply, “I use Enterprise Edition, we can turn on transparent data encryption, nobody would notice,” that’s something that’s real easy to sell. If it’s, “encrypt our backups,” that’s real easy to sell. Nobody on the business side’s going to care about that, just go ahead and do it. If it’s radical application changes, walk through what those application changes are, go as far as you can, have that document there, because at some point, there may come a day when somebody else higher up in the chain says, “oh yeah, this California Data Protection Act is now official. We should probably get on that. What do we do?” And instead of sitting there twiddling your thumbs like, “well, I’m– I don’t know what to do,” you can say, “hey, I have a plan for that. Here’s what it’s going to take, here’s the rough number of hours, here are the steps, here’s what the impact would be to the business.” And now, those higher ups, they’re going to understand what the nature of the problem is and be able to weigh that against the other projects that are happening, versus something that’s a lot murkier of, “I’m going to go off into the ether and I’ll come back in a few days and stuff will be there, maybe.”

Carlos:            Yeah. Although, if you’re headed into the ether, that might be kind of fun.

Kevin:            Yeah, yeah.

Carlos:            Sorry, am I–

Kevin:            So far, I’ve sent people on walkabouts, peyote-fueled trips into the desert and now it’s the ether. Where do these IT people go?

Eugene:          And you’re still a manager at Channel Advisor, right?

Kevin:            I still manage people, yes.

Carlos:            But it’s like you haven’t been on a trip for a while. It’s like been what, like three weeks, you get a little–

Kevin:            Almost. Almost three weeks.

Carlos:            A little anxious, there? Yeah, so there you go. So Trent, a couple of our thoughts. Take ‘em or leave ‘em. Compañeros, I guess we’re always interested in what you have to say, and if you have a thought or a scenario that you want to throw by us, we’d be happy to chat about it.

Kevin:            We will happily build up strawmen.

Carlos:            Right, that’s right. So, I guess last thoughts, gentlemen?

Eugene:          Yeah, no, this was an interesting question, and I think it’s a common challenge when you’re working at a small business. Right, it’s so much harder to justify some of these things than whenever, you know, you’ve got a team of 20 IT people.

Kevin:            Yeah, it certainly becomes harder to prioritize these sorts of things, but what we came back to over and over is, “have a plan, have people on the business side who are interested.” You may influence those people on the business side if you build relationships and talk to people. I hate doing that, but it’s necessary to do that. But have those plans, have those relationships, start showing tangible benefits, and you’ll see more movement than if you just sit there and say, “I want to do this thing.”

Carlos:            Right. Okay, well, awesome, so compañeros, that’s going to do it for today’s episode. as always, you can reach out to us, say hello, we’re friendly people.

Kevin:            Most of us.

Carlos:            And you can reach out to us on social media. Eugene?

Eugene:          Yeah, you can find me on Twitter @sqlgene and at sqlgene.com.

Carlos:            Kevin?

Kevin:            You can find me on walkabout or in the desert, apparently.

Carlos:            Or in the ether, if the–

Kevin:            You’re not going to find me in the ether, I’ll just tell you that.

Carlos:            And compañeros, I am on LinkedIn at Carlos L Chacon. Thank you again for tuning in today. We hope you enjoyed today’s episode and I’ll see you on the SQL Trail.

1 Comment
  • Dew Drop – January 2, 2020 (#3103) | Morning Dew January 2, 2020 at 7:07 am

    […] SQL Data Partners Podcast Episode 186: Analytics & Security: Find Pain Points, Make a Plan (Carlos L. Chacon) […]

Leave a Reply

Back to top