Hello there everyone and welcome to Redgate's first ever podcast. Well first ever podcast that I'm aware of Chris is that Same with your expectations. Yeah, lots of YouTube videos but as far as online podcast brilliant Well, we're happy to be here with you today and let's get some introductions out of the way So my name is Chris and my name is also Chris fantastic. So you're not ever going to forget who's talking Should we go over surnames as well?
Just use first names. That's probably a good idea So my name is Chris Unwin and I am one of the pre-sales engineers here at Redgate specializing in data privacy and protection My name is Chris Unwin and I'm one of the oh wait no other one. That's you my name is Chris Kurzwell and I am also a pre-sales engineer not just copying you that time and I focus on Everything really I don't really have a focus although I have been seeing some excellent work from Chris most recently to do with Redgate's DevOps solution, but obviously a bit more on that maybe later on or maybe on another podcast So yeah, we have this idea that maybe we make a podcast together. Mm-hmm.
Don't really know why because we enjoy each other's company I'm sorry to regret this already This is just us we're just gonna talk and see what we come up with really absolutely and hopefully to those of you who are listening I hope it will be able to share a few kernels of wisdom. Maybe some knowledge. Maybe something a bit red-gating Maybe something a bit more general, but hopefully what we're going to be tackling is a few pertinent topics within the IT community So obviously largely it'll be around things like database development DevOps You know data protection I think whatever kind of takes our fancy and the main things brought us together really is beer We are both big beer fans. I'm a little bit.
Okay. Well fortunately I've had too much beer which makes me a big beer fan So actually we've got here today a couple of beers for us that we're gonna be enjoying whilst we discuss one of our next topics now This particular beer Chris. I don't know if you've ever seen this No, so you brought this one in so I let you do the introductions sure so today We are going to be having it's called pride and joy from the vocation brewery. Is it your pride and joy?
It is absolutely I thought it was a good way to start off with our first ever podcast to have as our pride and pride enjoy as it were Not even started and we're already plenty cheesy. Yeah, so pride and joy from vocation brewery vocation brewery being a brewery based here in the UK Indeed in Yorkshire and I would admit I've never had this beer before but I did see it I thought that looks cold and refreshing and it has been quite warm recently as well So it's an American payload about 5.3% and we've got a couple of lovely cans here to enjoy as we discuss it So we're going in cold together. We are going in cold together. So should we do our separate and get these open?
Perfect. Okay, so what can you notice on the nose? Okay, good stuff. Can we get smell through the podcast?
Can we fill for that out? Welcome ladies and gentlemen to Redgate's Melavision. So theoretically this beer is supposed to have flavors and aromas of mango citrus earthy pine tropical flute fruit and blueberries. It smells kind of fruity.
It definitely smells fruity. It smells as far as my palate goes. It smells fruity smells like beer. It's a fruity mango-y beer.
It does actually taste somewhat mango-y. I'm getting mango-y after taste. Might have to do with the whole mango that I ate this afternoon. So Chris is already halfway through the can.
It's definitely not halfway through. It's a little can. Okay. Yeah, he's the one with the problem for the record.
Oh yeah, that's quite nice. I don't tend to go for American craft beers. No? No?
Not saying that you should exclude them from future use. You should always try new things. But yeah, that's quite nice. Brilliant.
Well, without further ado then, Chris, we've got our beers. We're stuck in a small cost-rophobic room together. Shall we have a chance about, I don't know which topic you've picked out for this week? So I wanted to speak to you about the topic of test data.
Okay, that's an interesting one. So test data. I'm writing application, right? And I have a particular function that I want to test, right?
I have to put it simply. And to do that, I'm probably going to need some data. This is true. So the question is, where do I get that data from?
Well, I'm glad to ask Chris because being somewhat of an expert on that particular data myself, I would say you should just use production data. It's interesting that the guy who's the data privacy specialist comes out with that. But yeah, obviously these days you can't really just use production data. Whereas in the past, if I was writing my own application, I wanted to test it.
I'd use data taken from production back up and restore. I wouldn't really be so aware, I guess, that would be an issue. That I'm potentially taking people's personal information and using it just to test code. Well, that's the best way you can figure out that it validates, right?
I mean, if you're using real data from production and you're testing something that eventually is going to be deployed to production, then you would expect to use production data. So you can really check that everything's hunky-dory with obviously what you've developed. And of course, knowing your start of development, everything's probably perfectly fine, but it's always nice to know and have that assurance. But yeah, you now have large bits of legislation that are effectively saying you can't take people's data and use it.
It means that they didn't agree to. So that'll be the GDPR, that'll be whatever that is around the world. And I wanted to ask you, do you think the reason for that would be? Why is that a bit of legislation?
What are they getting at that? Why don't they want us using that production data and test the world? Oh gosh, well there's about 50 different questions in there. I mean, for start, obviously what we need, all right, we've taken the GDPR as our prime candidate, as is everyone at the moment.
But in terms of the GDPR, then we need to have a legal basis for processing data. Now, in terms of our legal basis, for justifying our processing of this data, that probably doesn't include test data management. Now, we obviously discussed why we want to have data in test. But ideally, we don't really want to be using that because it's never going to have the same level of protection as it were.
I mean, you might encrypt the heck out of your production system. You might have TDE enabled. You might have Pro11 encryption. You might have dynamic data masking.
You could have all of these different things. And of course, all of the various bits of hardware and network security in place. But realistically, are you ever going to have that for development and test service as well? Yeah, so I think that's really what the legislature is getting at there.
They're saying that those other tests environments aren't going to be as secure. So you definitely shouldn't just be taking copies of that data and spinning it up. And yeah, because it's less secure, that means it's more vulnerable to a breach, to a heck or whatever that might be. And also more vulnerable to malicious employees.
Well, this is true. I think we did a webinar possibly two weeks ago now, which was long. It hasn't been that long. Every day you can't go like you start.
But we did a webinar and we took a look at a couple of the causes for these major data breaches, these millions of records being exposed. And funnily enough, it was only about 45%, 40% due to actual nefarious hacking means where people have tried cracking into the system. And of course, the rest of that lovely pie chart that we saw was accidental exposure, employees leaking information onto the interwebs. So didn't you accidentally expose yourself over the interwebs recently?
Was that something else? That's something entirely different. Weird thing to write to a price about that. But there's so many different ways that data can get out there.
And the last thing we want is to duplicate our headache. We don't want to take data and split that out all over the place. It's also interesting when we say 50% of data was hacked and hack is a word that comes up time and time again. There's a film Hackers from like 1995.
You keep bringing this out. You love this film. That's not actually. But really cheesy film.
And if anyone's seen it and works in IT, it's the most stereotypical cringe at the representation of IT and what hacking is. You close it all the time. Whenever IT is represented in the media, the idea of hacking is some kind of guy sat in a room while this amazing UI cracks off. And maybe some matrix-style codes and scrolls down the screen.
Whereas a lot of the time, it's simple exploits, right? If you've ever wanted to hack like that, then go to hackatypa.com. One of my particular favorite websites, put your headphones on and just go crazy on that keyboard. Pretend like you are one of those.
Some radio games machine going. I do love radio games machine. Almost as much as I'm enjoying this bit. Nice good bit.
But yeah, back on topic. So test data, you don't want to be taking that out and putting it into pre-production. In pre-production of violence. Or sorry, you don't want to be taking production data and pushing it out into those environments.
Because they're probably going to be less secure and easier for malicious individuals to gain access to. But also, sorry, what I was trying to get out here is that I guess the legislation is kind of enforcing best practice. This is true. So the best practice really was not to do that before.
And the legislation is kind of saying that you shouldn't be doing that. So that brings us into a question though. If you can't take production data and use that to do your testing, what do you use for your testing? How do you test anything?
Well, I use for test data. I use an empty schema. So Chris writes bad code. Well, I got quite a scene by the dress.
And then blank and it came out blank. It's all working. Test is validating. So I mean, there are a couple of options.
The first is we set everything to be the same. So we create maybe. So everything is Chris. So it's almost like we're in this room and everyone is Chris.
And they are working red gate as a sales engineer and drinking the same beer. Well, not that we fit that demographic. But fortunately, you could easily write some very bog standard scripts to just pop in random sequences of letters and numbers and characters such that you end up with some data. I could write a script.
I guess that would populate my test environment with data. But you kind of touched on one thing there, which is it might just be very basic. And everyone's called Chris. Everyone works at red gate.
So long. But if I want it to be a little bit less basic, a little bit more sophisticated, then I guess I have to write that. Well, you might have to write it. And there are certainly some people out there who have written the most extraordinary data generation scripts.
Certainly, I've seen one at work. And my goodness, there was many moons that have went into that particular script. So I could take someone's particular script off Stack Overflow or whatever it might be. And it'll all work and I'll be tickety-boo.
I guess it's not very supportable though, is it? Well, that would be the ideal. But then you've got to worry about foreign key relationships. You've got to worry about if you've got any particular data.
Obviously, no one's database is going to be the same across company. So it's one of these awful situations we find ourselves in, which is, do we bake it in house and end up with a cake that's somewhat subpar? Or do we actually go all out and build ourselves a quack-on-boosh of different profiterals? Well, what is a quack-on-boosh?
A quack-on-boosh is a stack of profiterals covered in caramel and it's French, meaning like crack in the mouth quack on bush. Oh, wow, OK. Yeah, exactly. So it's a delicious thing.
I've only ever seen one in my life excluding the many, many times I've watched the Great British Bake Off. Did you face that? I did. It was incredible.
I tasted like a profiteral company. But the thing is, is that there are so many third parties out there now, including Redgate. Obviously, it would be remiss of us to mention our own data generation capabilities. It was funny though.
I thought I'd come up. But fortunately, Redgate has this tool called SQL Data Generator. I mean, call it as you see it. And essentially, we can look at these tables and we can generate lots of different bits of data into all the different columns, obviously foreign key aware and all that.
So scripting can be time consuming. It's really supportable. So using that application like Data Generator sounds like a good way of doing it. It's something we both use time and time again.
That's true. And it works pretty well, right? So we can use effectively different generators, so whether it be regex or Python or use libraries. So like, dictionary, so for example, list names like Chris or Chris or maybe Chris.
That's a good option. That's one of my favourite. Yeah, and that is a pretty good way of generating data. But I feel a buck coming.
I feel a buck coming. Well, I had data that one up. Absolutely. Yes, there is a buck coming.
And the buck is we can't synthesise all of our data. And the reason for this, I mean, we might be able to synthesise a good portion of our data, absolutely. But there are still a number of challenges where all of these third parties are still going to fall down and go boom. And that is that if we want to make sense of any of our data, then we want to preserve the demographic of the data.
We want to preserve roughly how the data looks and feels in production. We might have some very specific things in it, such as financial information or particular location information that we perhaps want to preserve, whether it's for reporting purposes or because we need to check that it still validates. Stuff that inherently isn't, and we haven't even used these words yet, but it's not personally identifiable information. And we want to preserve that.
We don't just want to generate over the top of it. So what you're saying is we want to take the data and make sure that it's still got some logical links in, right? Yeah, absolutely. We want to make sure it still looks like our production data.
Yeah. And why is that important? Why would I want those logical links in that? So again, you need to, if you spin up a test instance of your application or you need to do some testing against that particular set of data to make sure that it validates, maybe you've written a new stored procedure or you're firing it into some backend application, you still want the data to look realistic.
You want to know that Mr. Chris Unwin, for example, returns data, maybe you're a pharmaceutical company and you're trying to check that indeed Chris Unwin did buy some antihistamines when he was suffering the hay fever, which of course is all the time. And then you might also want to check that Mr. Chris Kurzwell ended up getting also antihistamines.
He promised that we're not the same person just doing different voices. I don't know what you mean. Yeah, introducing my friend Chris Harrelson. But the point is that we still need to make sure that it validates and it's still realistic.
And that's a really tough thing to do. So we're sort of doing this juggling act where we're saying, well, how do we protect the people whose information we gather? And also, how do we make sure that the data is realistic? So we need some good strategies for handling that.
So we can still do our tests and we want to do our tests. We need some kind of logical link in there to make sure that our functionality is working well. So we need data that is generated but still has links in. Yes.
How are we going to do that? Well, obviously one of the main things that the GDPR calls out in particular, and indeed, we'll probably just see that being a benchmark really, is you've got all number of different people around the world working on different pieces of legislation. But all of them seem pretty dead set on the word, pseudonomization. I'll say that again for you slowly.
Pseudonomization. That gives me shivers every time. Or am I just cringing? Possibly cringing.
But essentially what we do with pseudonomization or masking the data, we can preserve the stuff that's useful. But ultimately, we can mask the stuff that we don't want to be used for nefarious purposes or even for testing purposes. So ultimately, we're taking our production data and we're masking it. We don't know in such a way that's reversible?
Well, it depends. So for example, obviously, Redgate is very much a SQL Server focused shop, but there are lots of different ways you can be gathering storing data. But we'll take SQL Server as a good example. So in SQL Server 2016 and up, there is dynamic data masking.
And what we mean by dynamic is that the data stays the same as source. And then as it's transmitted to the person running the query, obviously we're checking against their permissions and generating a mask based on what they can see or what they're allowed to see, which is great. But there's another bug coming. Obviously, if you have SA credentials on your local machine and you've got a copy there or you want useful data, certainly dynamic data masking has a habit of generating lots of, I think, I think the Americans would call it garbage.
And it has a habit of doing that. So what we would ideally like is something that's more contextually aware. And indeed, where we're pushing out copies of this database for development purposes, spinning fresh copies up for more agile business buzzword bingo, agile testing. When we're spinning these environments up, we just prefer that they were masked inherently.
Yeah, I guess we don't really need to be reversible for a lot of that data. And also, there is a question of whether that is actually compliant in and of itself, right? If you can actually run a process and get back to that original source, then have we really made the compliance goals? Done our due diligence.
Because I'd argue that if there is a method to go back, then that process is not compliant. Absolutely. And the problem is with things like GDPR and for all of you listeners in South Africa, Poppy, anyone in South Korea, Pippa in... Why is it always gold, names?
Why is there no Poppy in Pippa? Well, that's okay. The US has the privacy shield. I quite like that one.
Because I think shield in itself is the acronym here. So basically... So basically shield. P shield.
And essentially, what we want to do is just make sure there is no reverse engineering key. And they all do call out how... They call out that you should be protecting the data. You should be taking steps to protect the data.
But they don't tell you how. It's not a framework. We're not working against ISO 27001 here. There's no checkbox that says, hey, are you doing this thing?
Great. Keep doing it. We find that quite a lot with modern compliance legislation. That's especially in the world of IT, where you'd expect there to be something that definitively says we are compliant, we are not compliant.
Instead, it's very general. And they give it to you in very general terms. So that you can't really treat it as a checkbox exercise and you think quite carefully about it. I think that's usually the plan.
So if you look at some Miffit, which is a financial regulation, it's written in a very similar way. The regulator has said that you must provide them data within a timeframe, but not giving you a timeframe. And all types of examples are like that. So it kind of puts the audience on organisations to just be as compliant as possible.
Yeah. So by design and by default, pretty much. Yeah. Again, cringing.
Cringing and referencing back to that webinar that we did as well. We're trying to forget it. Yeah, we'll try and forget that. But yes, the key is let's try and mask in place.
Let's try and mask statically. And of course, try and retain the look, the touch, the feel of production, but mask the necessary field so that we can't get back to the individual. And ultimately, this means that we kind of, if we don't have any personally identifiable information in these pre-production environments, then we effectively remove them entirely from the scope of any of these particular pieces of legislation. So give us your best sales position, Chris.
We've got a situation where we've got data that we want to push into tests from production and we want to mask it. How do we do that? Oh, gosh, Chris, that's a good. No, we're not going to make this a sales pitch.
Everybody knows that Redgate has obviously a tool for this in SQL provision and we can create these pre-production environments. We can ensure that they're pseudonomized effectively and we can do all of that. That's absolutely fine. If anyone who actually wants to know more about it, they can either get in touch with us with Chris.
One of our last names, Unwin or Kurzwell at red-gate.com. Go on the Redgate website, anything like that. But equally, all we want to do is just make sure that we're protecting these environments. That is the key.
Ultimately, we need a process whereby anytime we restore our database from a backup, anytime we move data around, anytime we create any environments regardless of process, we need to make sure that we take any information that's personally identifiable, whether directly, like names, email addresses, telephone numbers, or even by correlation as well. So for example, if you've got an age, that's not personally identifiable. If you've got a postcode, well, that's a lot of people. So it's not directly personally identifiable.
But if you've got an age of say, a 92-year-old. And then you've got a postcode. And then you've got a postcode. And then you've got a postcode.
And then you can narrow it down on the individual. Exactly. Much like if you knew Chris at redgate, you can narrow it down to any one of about 50 guys. This is a good point.
Chris, do you give me your express consent to pass out your email address to these people? Oh, definitely not. Oh, well, it was retracted. So obviously, this isn't just the only reason that we're talking about this.
It's very, very important to be discussing data privacy and data sensitivity at the moment, particularly with some very high-profile cases going on in the world as we speak. Yeah, so let's have a quick look at the news. Let me just take a look at the newspaper here. This is going to be a segment in the future.
We're going to do a news segment. It started here first, ladies and gentlemen. Hey, Chris, what's the weather going to be like today? Sunny, I don't know, it's August.
So it's not August, it's June. You can tell it's going to the end of the podcast and I drank most of my beer. Yeah, it's pretty sunny at the moment. So let's actually do a news segment.
So Chris has been in the news recently. We have looked at a particular interesting case study, I guess. That's because very recently, Dixon's carphone, I'm still not 100% sure I've got the entire name of the company there, have announced that they have a data breach. And this is, I think this is the first major, at least the first major data breach in Britain since GDPR came into effect.
This is true at O-but. Yeah, there's a bug coming. That again could be a bit of a bit, couldn't it? There's a bug coming.
Listen to our podcast folks, it's full of butts. But yes, it essentially does represent the first breach since the GDPR came into force, but they reckon that the breach actually happened before the GDPR came into force. It kind of feels a bit fuzzy to me. I don't know.
I'm sure they've managed the time, the announcement of this very specifically to give them the most amount of time, but it seems a bit strange. Well, we're still very far off of the decision. So typically looking at the ICO's track record, I think we're probably talking about this in six months time when potentially a fine is levied. Back on track then, Dixon's carphone announced that they had a data breach.
Correct. The data breach itself, from my understanding, they had a previous data breach, right? They had about 2015. They were fined by the ICO 400,000 pounds.
400,000 pounds, yeah. Okay. So they're $550,000. From what I read into that, well, at time of recording, it's about that much.
In doing a lot of investigations into that breach, I believe they uncovered this breach. Really? They uncovered this additional breach. They've known about it for a little while, but I think they've only recently announced it because of the, you know, that's the latest they could get away with announcing it.
So potentially, I mean, under the GDPR, obviously you've got to announce within 72 hours of discovering the data breach. Yeah. It was definitely, it was definitely outside of 72 hours since that happens. Slightly.
Slightly. Yeah. It was 1.2, I mean, it was a two-fold data breach. You've got 1.2 million customers' information actually being leaked as part of this.
And indeed, 5.9 million customer cards. Now, 5.9 million, but 5.8 million of those were EU nationals? They came out on announced that they believe none of the cards were used for fraud. So 5.8 million cards were, as you said, they were EU nationals that are protected by Chippapin, which is great, gravity of Chippapin, but for those 100,000 people, we don't have Chippapin, 105,000 people.
No, that's being said. I've got my face now. They obviously aren't protected by that. So could potentially be used for fraud.
Of course, yeah. In notifying the authorities, you'd hope that some checks will be put in place by the credit card holders. However, that's probably not of a huge amount of comfort, especially to the 1.2 million people who have their data out there. Yeah.
And what potentially is going to happen to that data? Well, that's a good question. Nobody really knows it. It depends on who obviously has that data.
So one of my favorite comments on this actually came from the consumer group, which actually a guy called Alex, Alex Neal, I think. Oh, no, no, no, no, go on. Don't lie. Oh.
Anyway, he said it's critical. The company moves quickly. Now, that's not the whole quote. The whole quote is, hang on, I've got it right here.
I've prepared something. It is critical. The company moves quickly to ensure those affected, get clear information about what has happened and what steps they should take to protect themselves. Now, it's a really interesting quote because he starts off by saying the company has to move quickly.
Now, yes, they need to move quickly. Yes, they need to alert customers. But the difference is that they need to move quickly sort of twofold. They need to move quickly to alert customers.
But they also need to move quickly in general. And that's why a lot of people that we speak to spend their time putting in place good DevOps practices and putting in place good compliance practices or compliant DevOps or DevSecOps or however you want to call it. Have they really moved that quickly, though? If they've delayed this announcement?
By year. It doesn't sound like they move particularly quickly. Well, again, that's a comment from which, more than anything. But absolutely the need is to move quickly.
And whether it's discovering the data breach quickly, reporting it quickly or putting in place the necessary processes. Do we monitor where all of our data is? Do we know where all of our data is to begin with? How are we protecting it?
Being able to respond to threats like this is crucial. So on the breach itself, we know it's important, especially now, the legislation's and force around that. The actual breach itself. From what is announcing a lot of the news out there is that the breach was effectively a processing layer, I think?
Yeah. Was it the point of sale devices? Yeah. So the point of sale devices appeared to be out of what's the terminology?
They were not up to date patch level. And so because of that, the breach was caused. And so that kind of comes back to what we were talking about earlier with the kind of pauses of the breach. So like hacking and, you know, hacking not necessarily just being a kid in his bedroom, smashing away, listening to death metal, but also just being someone who's noticed an exploit and abusing it.
Well, it's interesting because the UK's ICO actually did issue a statement about patching hardware and software. I think it was they were talking about the existing vulnerabilities could lead to fresh punishment, certainly as the GDPR is enforced. So the ICO stated that fines would be a last resort, as it were. But Nigel Holden, who's the head of the technology policy at the ICO, he said there may be some circumstances where organizations, there's just too much of this quote clearly.
But he said, there may be some circumstances where organizations could be held liable for a breach of security that relates to measures such as patches that should have been taken previously. So ultimately, failure to patch known vulnerabilities is a factor that the ICO actually takes into account when determining whether a breach of the seventh principle of the Data Protection Act is serious enough to warrant a civil monetary penalty. And it will be the same with the GDPR. In summary, patch your stuff.
So it's one of those things that it's easy to say, point of sale devices, people are going to be quite hesitant when it comes to patching those, obviously, because if they go down, that's a big problem. That's slightly hard to fix, causes you significant business issues. So you can kind of understand the hesitation, but ultimately it's the law. I have to admit, though, I think I'd rather get busy patching my POS devices than having my share price drop 6% in the first day after declaring a potential data breach.
Yep, and that's another really good point, right? The impact of that. So they've announced the data breach. There was a stock price drop as the result, which, what do you do?
Do you announce the breach? Do you take the stock price hit? Do you take the fine? I think most of the time you're probably better off taking the stock price drop.
I would probably happily pay out for those point of sale devices to be upgraded sooner than I'd take the stock price drop. Sure, yeah, after the fact. But yeah, so you've got the stock price drop. There's also the potential fine.
So we would find 400,000 pounds before GDPR was put into effect. Again, this probably won't be covered by GDPR. But if they were, then that is what? 4%.
I think it's two or 4% of global turnover or up to 20 million euros. I'm not saying that they will actually be fined a full 4%. That's probably going to be reserved for the highest cases. But still, if you're looking at a company that brings in 10 billion in terms of revenue, 4% of that is 400 million.
It's a lot. Yeah, it's quite a bit of money. Anyway, so I think that's pretty much all we have time for today. Obviously, we've gone over quite a bit of information.
Wouldn't you say, Chris? Yeah, I guess. I think we've got time for more. So we'll have another podcast at some point in the future.
Most likely. Anyway, less Chris gets fired. Unless I get fired, which based on some of the surface information in this podcast may yet come to fruition. But regardless, thank you, Chris.
Yeah, thank you for also being here with me. And thank you all for joining us. We'll look forward to seeing you hopefully at our next podcast and to round things off. Final notes about the beer, Chris.
Yeah, I quite like that. It's pretty good. It's very drinkable. I would also say it's quite drinkable.
And so just round things off of the cheers. Cheers. Cheers. Cheers.