I'm so glad that I knew you were about to do something stupid when I hit record because that meant you got the annoying noise out of the way sooner. Hello there everyone and welcome back to DB Alder Egg 8 podcast that is all about data and beer of course. I am your first and by my opinion primary co-host Chris. And my name is also Chris.
Hey Chris, guess what? What? No, don't do it again. Don't do it.
Baaaaa! Apologies to the addrons of every listener, young and old there. It's been a while since we did and my name is also Chris, don't you think? It's been a while but it's a classic.
Maybe we should change it up and both be Steve's one day. Kendra. I would love to name Kendra and which one of the main reasons is probably why I interact with Kendra so much but I would love to be a Kendra. You could be a Kendra.
Why not? I think the K just Kendra. Anyway, never mind. I'm getting fixated on names.
Also small or little known fact is that my name is actually Steve. It's not Chris. This is just being a true thing on you this whole time. You've just ruined our marketing gimmick.
Well, it would be about time for us to ruin any marketing gimmicks because of course today is a momentous recording as well because happy birthday to us. Why? Oh, you were doing a drummer. I'm not just banging the desk as you always do.
It's smashing my face against the desk. I can't of course sing Happy Birthday because I believe it's protected. And you can't sing. And because I can't sing but at the same time, yes, that of course means that DB Ail much like me this year has turned 30 today is the recording of DB Ail the big three zero.
I mean for the record that's 30 years, right? Oh, I'm turning 30 years this year but DBL turning 30 episodes. I'm why wait doggy is this no? I don't know.
We're turning 30 episodes. That's the important thing. So yeah, I wish I had a party popper but unfortunately I don't. Yay.
We spent a lot budget on the beer. We did. We did. It's actually probably a good idea to just tell everyone what we're going to be talking about today.
Before we get onto the beer and we don't have champagne to pop but I'm sure a beer can do. Next thing we've got some cold beer. So that's all right. But today you can expect Chris and myself to be talking about, well, I believe the theme is it ain't DevSecOps.
It's kind of all secure continuous security, i.e. in our opinion part of DevOps. It might be an unpopular opinion. Let's see where we end up.
Let's see if you agree out there. But we're going to be talking about what we mean by compliant database DevOps. We'll talk about compliance in general and some test data management. I know we've talked about data privacy in the past and we always do our data breach updates for which Chris has got some fantabulous updates for you today.
We'll be talking at three. Wow, okay. And we'll be talking about how certain practices within the database DevOps lifecycle actually help you remain compliant with say legislation and we'll be talking in a more general sense, as opposed to say calling out specific articles from say the GDPR or Poppier. So that's what you can expect from us today.
I think Chris that it is about time that we had our champagne moment. As you can see, I have a heart glass. It's your blurring. There you go.
I have a glass with hearts on it. And this glass of heart shallots. You do have it. Wow, that is a chalice.
What are you drinking today? I have a three assembly dry hot wheat beer. It looks nice. Tell me a bit about it.
I don't know, but it's not this really funky artwork that is definitely definitely not out of a young Charles nightmare. So it is a hazy wheat beer German style. Sounds good to me. Please don't drink while pregnant.
I mean, you're good, right? Oh, yeah, I'll risk it. Fair enough. I today am actually going to be drinking a significantly larger bit than you, which is also being blurred out, which makes it look a bit weird.
I saw the letters O and P. You did. In fact, I'm going to be drinking a salt and Pomona Island Shoop Napa. So I believe it's a collaboration between two brewers, salt, all in capitals and Pomona Island.
And it's this shoop, as it's known, and I just like saying that, shoop, shoop, shoop, is a New England IPA packed and stacked with tropical hopper omens. We dipped into a bag of tricks to bring you a juicy neighbor, smooth bodied and low in bitterness, not shy with the dry hop of Vic's secret enigma, Motuka, expect aromas of passion fruit, lime, pineapple and melon. And then literally the last line just says, shoop, buddup, buddup. Nice.
Line passion fruit and what's sorry? Passion fruit, lime, pineapple and melon. Wow. And it is 440 mils.
It's quite big, 440 milliliters. So that is, I don't know what that is in other measures. It's about a pint in there. I've got a pint over 500.
It's five, six, eight, five hundred 68 milliliters in a pint. So it's probably, yeah, just four fits of a pint. And it's also 6.4%. Oh, so Chris is going to get messed up.
Well, considering that I have now lost 17 kilos since the first of Jan, I'm hoping that it's going to get me pretty messed up. I mean, I'm hoping that we're going to talk about data. Nice. Oh, dear.
This is, this is going to be a controversial one. Here we go. All right. Let's go.
Three, two, one. Oh, that makes a nice noise. Oh, Chris. Oh, wow.
Steve, Steve, Steve, it take the smell is just passion fruit and pineapple. You know what? I'd really like in a beer. I've realized today is Kiwi.
Oh, oh, yeah. I don't know about a Kiwi flavor beer. If any of you out there happen to know of any Kiwi fruit flavored beer, I'll talk about New Zealanders. No, just take the hybrid DBA and mash them up into a pilsner.
I don't think it'd appreciate that. All right. Here's the pour. I was afraid there that I was going to keep pouring because I was so focused on getting the right sound.
Like this is more head than it is beer. That is a very European pour right there. Oh, I don't know the Europeans here. You say that, Chris.
That's not very fair. If you've ever been to Cologne and had cush in the little glasses, you'll know that it's not a massive head because the glasses are very, very small. So you've got to make sure that it's packed full of beer. That's the Dutch and the Belgian style where they have like the solid amounts of head that two thirds head.
That's why I'm going to sample this and see what I think. Oh, I wait there. So that's quite good. As promised, it's a hazy wheat beer and it tastes like a hazy wheat beer.
Yeah, nice. Wow. This is, that's pretty incredible. I think this is one of my favorite beers I've ever had.
Like, I don't just mean on DBL. I mean, I think this is now one of my absolute top five favorite beers. Maybe that's one thing we should do sometimes do a list of our own favorite beers. Don't completely off tangent.
A DBL special where we literally just talk about beers. Yeah, why not? There you go. Sort it.
All right. Well, that's they go wherever you are. Just write themselves. Cool.
So yeah, Sultan Pemona Island present chup and chup, Badoupe is Badonka Donk. Oh, that'd be good. Like a special on our favorite of all time beers. Yeah, we don't beer or we're including Lager in that as well.
And if we're going by DBL standards, am I including cider? I feel like you just have to stick to beer, but Lager is a beer, right? So, yeah, true. I think we were talking about ails, but I would happily include some Lager as well.
Anyway, anyway, let's get on to the main topic. So we've got about, well, about what? 30, 40 minutes. Let's get into the, I don't know, the tempo of the session, the satan of the session.
I'm finding an alternative for me to the session. We're about, you're trying not to say the meat of it. Yes, exactly. So let's get to the body of it.
Let's get past the head on the beer and straight for the beer itself. Chris, how do you feel about DevSecOps? Go. So DevSecOps is, I mean DevOps itself, as much as we all love DevOps at Reggae, it's definitely victim of a lot of buzzwords, buzzwordy.
Yeah. A lot of buzzwords that come in DevOps and come with DevOps and DevOps itself is the mother of all buzzwords. I mean, to be fair, the IT industry itself is the buzzword giant here. You've just got to show Kubernetes for everyone's ears to go, oh, did somebody say Kubernetes?
Yeah, I'm pretty sure you could create quite easily some kind of satirical piece talking about all of the buzzwords in DevOps. That's all I must have done already, but I'm proud and containers and I think DevOps buzzword being goes definitely a thing. That's got to be a thing. But yeah, so DevSecOps is someone taking the already loosely defined thing of DevOps and making the point that security should be a major consideration of DevSecOps, so the status of security.
So here's the interesting thing, right? Is what definition do we use when we talk about DevOps? I think we may have done it in the very, very first or second DBL. What is the definition that we, not just the two of us, but I think I guess Reggae is a whole align ourselves with when it comes to DevOps.
So we always use the definition that is the don of and brown one. Yeah, exactly. It comes from don of and brown, the alignment of people and process and Chris finished it up. Technology.
Yes. To constantly deliver value to our end users. Now, the interesting thing about that phrase is that if that's what DevOps is, we've got people and in DevSecOps, we're talking about DevOps with added security, right? Just for those who don't know, we're talking development, security, operations, DevSecOps.
And a lot of companies out there do seem to be aligning themselves to this DevSecOps principle and saying that, you know, and there's even job rolls out there like DevSecOps manager, like all these sorts of things that I've seen recently. And if you think about DevOps, if you think about what DevOps is, people and process and technology, technology by default should encompass good security, right? We should have firewalls. We should have, you know, penetration testing done against our applications and our network.
You just say gigabit penetration testing. All right, I'll go pen testing, make sure your bio works. And then you've got a process. Now, if you look to any of the world's major regulations on data security and data privacy, right?
GDPR, California, California, consumer privacy act, you've got the new privacy act in Dubai, New Zealand, Australia, Canada, South Korea, all of these major pieces of regulation, right? They also the same thing, which is you must implement sufficient technical and organizational measures to protect data, right? That's the leading point. So technical and organizational measures doesn't sound one off to me because it's an ongoing thing to keep protecting data.
You need to make sure that you keep doing these technological and organizational processes. Well, that's tooling and that's process. Given that all the major regulations, say, you know, this is one thing when it comes to protecting data, when it comes to security, it's process, it's tooling. Well, if it's people in this process and it's tooling, like in the regulation for good security, that's just DevOps.
I don't know, maybe I'm getting a bit tired of about it. One problem, I guess, I guess with that word, with that, that diatribe is that there was one crucial word that you used, and that's the word should. Yeah, good point. So I'm going to argue in the defence of DevSecOps, maybe as DevOps advocate, maybe just because I'd like picking fights with Chris.
So security is something that should be included in that, but sometimes isn't. And so I can see the need for people to call out security specifically, just because they want to make sure it's a body by it's very, very important, right? I have to be fair. I have seen a lot of diagrams.
I have seen a lot of diagrams that's like the DevOps kind of infinity eight on its side. I've seen a lot of people put security wrapped around that because you can't put security into any one stage. It's like the enamel on a tooth. Security just is that padlock around DevOps that keeps it nice and tight and nice and secure, which makes absolute sense.
But at the same time, if it's in every part of the DevOps process, by definition, if we have security during develop, during planning, during deploy, during maintain and monitor, it's already in DevOps. Whilst I completely agree with you, I think that it's important that it be called out as an important element. That is what it is, an element. And nobody does DevOps perfectly because DevOps involves people and people are by definition imperfect.
It means DevOps, well, okay, you're fine state, but DevOps can never be perfect because people can never be perfect. So if security is part of DevOps, if we're not doing the security aspect of DevOps perfectly, surely that just means that we aren't doing DevOps as well as we could be. And there are areas within DevOps as a concept that we can improve. That's my argument is that it's all just DevOps.
That makes sense. I think there's two other points I want to add here. Oh, yeah. Here's another couple of things to consider.
One is that a lot of people would argue that security is responsibility for everyone, right? Yes. Everyone, whether it be every single person, individual contributor, developer, front of staff, whatever it is, it's everyone's responsibility. And so DevOps, security should form part of that.
There should be some awareness to security. So putting a second there, pause that out. Another one. So another point to consider, or do you want to, or do you want to mull over that point?
Mm, mulling, mulling. Yes. Yes. No, go ahead.
So my other other point to raise here is, so we talk about DevOps as in a way of introducing agile to organizations generally. So operations teams and Dev teams, you could define security teams as being part of the operations team. That's fair. In a lot of organizations.
So why don't we try and bring DevOps practices to security teams and let them benefit from some of the things that DevOps brings us. So things like increase focus on automation and agile as a practice in general. So it's almost like if you consider the teams that traditionally would be in charge of the almost siloed job of security, like if we take info sec, info sec are a perfect example of this. If you think back to the Phoenix projects by Jean Kim et al.
Info sec other people who everyone's like, Oh, God, but you're thinking that DevSecOps is more of a way to include info sec in that general decision making and that, that process as it were. Yeah, I guess the two sides. One is taking that info sec team and looking at what you can apply to that team itself. And the other is then looking to include that team into DevOps process.
So interesting. Instead of having a security team, have security members in your development tribes or units or whatever that might be. I do worry that we're getting a bit navel gazier about this. It's very like DevOps versus DevSecOps ultimately, ultimately, the two parts, well, that's really what I think it's the same thing really.
Yeah, DevOps, exactly. Thank you for proving me right. So no, but the interesting thing with this is that, you know, there are a number of different ways to look at it. And, you know, I will die on my hill of DevOps is DevOps.
And I know there are people who agree with me and there are people who viscerally disagree with me, which is perfectly fine as well. We're all entitled to our opinions and you're all, you know, anyone who disagrees is entitled to be wrong. But regardless, the point we're trying to make, I suppose, is that, and I think we've both made it, is that good security does come through good process. And there are ways of adopting the process to include good security.
So I think that's a really good segue, I suppose, into literally the statement I made at the beginning, which is what is compliant database DevOps? Well, it's database DevOps, but it's DevSecOps. It's how do I include security and compliance as part of this process? So I guess the first piece of the puzzle, the place that we start with that general, how do we ensure security in our DevOps process, specifically relating to the database, I suppose the first step is test data management, right?
Because you can't develop and source control and build and deploy on top of infrastructure that hasn't been created and made available to the devs and the testers. So we've got to talk about the, you know, how does, for instance, provisioning back copies of production databases into non-production environments, how does that fit in? And how does, how do we secure that process specifically, as opposed to say a backup and restore? Yeah, I guess, but you know, there's large parts of it as well.
Like test data management is a big thing. Oh, yeah. We can't ignore the traditional, traditional points like making sure production is correctly sealed. Yeah, absolutely.
Making sure the configurations are all correct. That it's been patched, that, you know, because that's a big one, right? Making sure that it's patched, making sure it's up to date, making sure that you've locked down the users, perhaps not everyone and their mother and the kitchen sink should all have access to production. So that's absolutely a really important point to make enabling encryption as well, transparent data encryption or, you know, other encryption methods are always a good option to explore as well, depending on your production setup.
But from there then, if we're talking about the DevOps process, the actual development side of things for these databases, if we start with the pulling back of environments, kind of the D minus of doing that, I suppose, would be a backup and restore. Yeah, that's fair. I keep taking production, you restore it into Dev or test or wherever you need it. And anyone and their mother can basically access that, which is, yeah, a problem.
And, you know, we talk about paper reaches a lot. I've seen, I've even said this on the show, but the amount of data breaches, which are caused because someone has exposed a copy of production, yeah, an exposed Dev box somewhere. Yeah, I mean, that's a problem. You're basically giving people copies of production without them needing to access production.
Yeah, absolutely. For the hacker. I mean, we can't do anything for the people who found the hard disks in the printers in landfill. DevOps isn't going to help you there, but, you know, absolutely don't expose copies of production data to to everyone and the internet.
Obviously, that's where it's most at risk. So if the backup and restore is the D minus, then of course, we need to think about the actual process itself. So first things first, catalog, cataloging and understanding your data, because you can't protect what you don't know you have, you can't put the right protective measures in place if you don't have a good understanding of the thing that you're protecting. So my argument would be that the first step, the first stage to good compliant database DevOps or DevSec database ops, I don't know, is understand what you're looking after by cataloging it and having an ever evolving idea of, you know, an ever evolving idea of where that sense of information sits, developers add tables, they add columns, they split tables, blah, blah, blah, so yeah, awareness is a bit part of it knowing what you have and where, and then if you know what you have and where in your test data sets, what do you do with it?
Well, I mean, that's a good question. You can either discard it and just go with an empty set, or probably better is make sure you've got that realistic information in Dev test, but so that it doesn't pertain to living individuals. So we've covered this before on DBL a few times, actually the masking of non of production data for non production workloads, but really the emphasis on data masking is not just so that, you know, we can, a lot of people look at it as, ah ha, this is the headache that we can, that we can get rid of so we have realistic data when they should be thinking about it as an absolute necessity, because it's going to protect our data in non production environments whilst still enabling the development teams. So, given away as to what we have, anonymize the data that's tested when we now know where the accessibility is, we can give it to our development teams, how are we going to give it to the development teams?
Well, there's a number of different ways, obviously you can still, you know, even if you've obfuscated the data, if you've de identified it in any way, naturally the best thing to do next would be to in some way make it available. And dev, dev need copies, testers need copies, you need them for different branches, you need them for different, you need them for different work for different projects with different teams, you need multiple test environments so that you've got these multiple test cases parallel testing environments. So tests don't bump heads, there's a billion and one things that we need environments for. So we need to bear in mind, how do we protect things whilst also making them self service, whilst also automating the refresh of non production environments.
And for many people, the answer to this is virtualization, by virtualizing a copy of the database and making that available so developers can just pull down a copy, that's their ultimate way of doing it. But of course, the source copy that that's being virtualized from is being in some way sanitiser obfuscated. And I think that the important thing is that you're defining process that has intrinsically, well, got those stages in compliance, right? So like, we're not defining a process that has that as an afterthought, it's part of the process.
That's the thing, build security and from the bottom from the beginning of the process. Well, if it's all virtualized, then the actual set of data itself, the actual bulk of the physical data isn't located where we're delivering it anyway. And the second thing is if it's all sanitized at the very beginning, for the developers, it securities and afterthought, they don't have to worry about that. A further step along that would be including the cataloging almost as part of the software development lifecycle and saying, well, hey, not only is it an afterthought for developers, but if developers then add tables, columns, do anything to the data, that can be recorded in an ongoing basis as well.
So the cataloging should should actually fit in again as part of the process, such that if a developer's changes get promoted to say an integration environment, someone is included in info sec governance compliance DPO, whatever, someone is included making a conscious decision to say, this table we've added is probably going to collect sensitive information. So what we'll do is tag it as such, and that classification will also follow up through the DevOps pipeline, through the CI CD pipeline, the SDLC to the production environment. And that information will then feed into further obfuscation, further provisioning of environments further virtualization, which means that prod need never have anything on it that we don't know what it is or what it holds. So you end up with masking and virtualization, but you also end up with continuous classification with continuous compliance.
Actually, so a really cool implementation of this, but you, I mean, you reference like individuals from info sec who could do the cataloging balls are the developers, right? Oh, I totally mean that as well. Yeah, I'm a developer as a column. That goes through CI CD version control, we'll talk about that more in a second.
You deliver that gone to your testing environment, the test environment is part of the test deployment validates any new columns that have been added against the catalog. And if they haven't been in some way catalog and defined, then the deployment fails. I really like that. It's a really way of just forcing, I guess, someone to make a conscious decision of what that should be classified.
Absolutely. I think this is one of the things I like about SQL data catalog is that because there's an API, a REST API and also a PowerShell module, I could just call out to that as part of a deployment and say, hey, you know, is anything not classified, fail the deployment. And that's a beautiful thing because that's what deployment checks are there for is to make sure that, hey, it's all good. And then the one thing we skirted over there was version control, like version control is ultimately, it is, or has a key role to play here.
Version control in and out itself, we kind of forget about it these days, but a big reason that people wanted version control in the first place is to see who makes which changes. Oh, so much. Audit history. Absolutely.
And if you, if you're smart about this, it can mean that no one can interrupt in certain malicious code effectively after the fact because everything is validated, ordered, correct, and true version control. And any drift is detected in later stages so that any hot fixes or unauthorized changes in later environments is rectified almost instantaneously. Yeah, everything gets tracked and recorded. I don't think we need to really talk about that too much more.
But it's fairly obvious and fairly good practice these days. Yeah, I think you're right. But then I think there's also another layer to it. I think the other layer to it is if you think about, again, if we think about regulation, and I'm getting through this beer very quickly, that is all I've got left from the entire can, it's going down very, very easy as someone who hasn't had a beer since the last DBL.
And this is only my fourth beer of the year. It's really knocking me for six, but that's a good thing. Beer of the year. That's a good phrase anyway.
Yeah, well, I haven't got a beer of the year yet. I might have a beer of the year 2020. We should definitely do a review of the beers that we had in DBL in 2020 and include that in our top, top beers, special episodes. Anyway, we're mind mapping now.
We're coming up with good ideas. Welcome to DBL 30, where we talk about compliance and also future DBA. This is what we do, like, talk about what we're going to do next time. Exactly.
And then we talk about this time next time. And for some reason, listeners continue to listen. Oh, well, but the interesting thing about it is that if you think about what happens when you experience a data breach or a data event, that has to feed back into changes that were made. Okay, we had a data breach.
What was the exploit? The exploit was X. We managed to get to the bottom of that. But why was the exploit introduced?
What was the source of that exploit? How long has it been around? That's a massive one. Because, you know, when you declare to the governing body of the country that you're in, the nature of the data breach that you've experienced, you also have to include information about how long it's been potentially exploitable.
Yeah, absolutely. That makes a lot of sense. And source control gives us that visibility, because I can say, nuts, it happened on the contacts table. The contacts table was last changed by blah.
There I can see the change in the commit message. And I can go back to that developer, find out about that change a bit more, and also potentially re-educate them. And again, we're not talking blame here. We're talking accountability and granularity when it comes to object-level history.
So we have version control. We have ways of provisioning environments. We have a catalog to give us awareness. The other thing I think we should talk about is the actual automation processes.
Can we go on this for a long time? But I think the key crux here is, and you can kind of reference this here, but don't allow anyone to make changes to environments that is outside of the process. Hotfix is my number one best practice recommendation to move hotfixes completely. If you're using something like Azure DevOps deployed through Azure DevOps, the only user that has access to actually deploy against the target environment is the Azure DevOps deployed agent.
And then your security comes from the Azure DevOps platform itself, which you can wrap around with other things that make you feel more happy and secure. And so, approvers or deploy changes through that, they can't deploy changes outside of the version control deployment process anyway. And no one can introduce anything outside the process. So everything gets introduced through that.
Yeah, that's a process. Exactly what I was about to say. The interesting thing is, one of the questions I get asked, in fact, two of the questions I get asked a lot as part of our jobs, is number one, how do I roll this back? And number two is, but how do I handle this insert of the random process to do with the database around this?
And my answer is always number one, you know, there are methods of rolling back. But again, depending on which method you decide to go with, it should still be a defined process. And even if it's not a defined process, you know, maybe you decide to roll forwards instead, because actually, when it comes to things like database DevOps, because of things like persistent storage, rolling back doesn't really make any sense, except for programmable objects. So that's where it comes in really, really handy to have a good, fast, incremental, lean process that allows you to very quickly and easily spin up a bug fix branch, make a change, commit it, push it, raise a pull request, bash bash Bosch, straight through the pipeline up to prod and it's fixed.
That gives you the audit trail. That gives you the continuous integration, it gives you the proof that the fix works and doesn't just introduce a whole host of new bugs. And it proves that it can be deployed. It's in the process, it's fixed, it's secure, it's compliant.
And then, well, I guess we've already talked about what it's in production, how to have an awareness for production. So we've, I guess, alluding to monitoring platform, then lots of introduction, maybe some whole thing again, and you've got this nice DevOps process that has to really paint in private. So beautiful. Oh, DevOps with the focus on security.
I don't think we're ever going to agree on this, Chris, but I appreciate you trying. But yeah, 100%, I think that seems reasonable. Now, before we get into the news, hang on, let's, let's do a good old-fashioned DBL news introduction. Are you ready?
Welcome to, I thought you were going to sing it with me. Oh, okay, ready? And the news. Breakdown.
That was terrible. You can work on that for next time for DBL 31. I feel like you're on a very different way, thanks for being there. I was on a very different wavelength.
I don't know if I can. You were a classical FM. I like classical FM. Be a rock man and of, and I'm sorted.
I don't know why I went like that. Anyway, before we get into the actual data breach, well, data breach monthly, I suppose, which you've been fortunate, thank very thankfully on my part, doing all the research on, Chris, I appreciate it. So Steve, there is one thing I should mention as well is that we actually have a couple of webinars coming up about said compliant database DevOps process. And it actually includes all of the technology and the discussion on the different processes involved.
The webinars themselves, half an hour, you really don't need much time to go and see these things. But if you go to www.redgate.com forward slash events, you should be able to find a link to both a compliant database DevOps demonstration by our good friend and colleague, R.A. Escandari. Oh, yeah.
Another one. Something about provisioning environments. I hear he's handsome. Yes, that's right.
It's yours truly. I would of course be presenting on Redgate SQL provision and data cataloging as well. So for the preservation and protection of data in your DevOps pipeline. So yeah, if you go to www.redheifengate.com forward slash events, you'll be able to sign up and have a quick look at what has, what's new in the Red Gate camp.
And what's pretty exciting that we've got coming along. So I definitely say check that out. But Chris, over to you, we've still got a few minutes left. Take us to the bridge.
I have a few quick breaches that I thought were particularly interesting. I'm going to say the best for last. So first of all, a fairly straightforward one, a boring one by one accounts. So a IT operator called sitter, which does a lot of IT operations work for some of the start aligns airline companies.
So that's companies like Lufkansa, Singapore Airlines and United have lost hundreds of thousands of airline passengers data, specifically frequent flight data. So I thought you were going to say thousands of thousands of passengers luggage then wouldn't surprise me. But yeah, the Swiss space company is effectively a vault here. They have not lost things like passwords or credit card numbers or anything like that, but still some sense of information.
So name and membership number and apparently tier status, which I don't think people are really that precious. Well, I don't know, it's more like a mark, isn't it? I heard that I did also see a news article that there were some homes in Los Angeles or something, allowing you to, if you were an influencer or you were verified on a platform like TikTok or Twitter, that you could get a customizable blue tick for your house. I'm not sure how true that is.
I saw it very, very briefly on Reddit, but it's kind of like a hello, like I'm the more I travel the most, I'm the most wealthy, I'm et cetera, et cetera. So it could be, it could be treated as these are the top tier members. They probably have quite a lot of money because they probably travel like business class or first class everywhere. So it could be could be used for an exploit.
I've given me quite a lot of BA. I thought I'd mentioned that one. Next one. So this is a lot less of a traditional someone's access to the database.
There's a company in Silicon Valley called Vertada, which provides essentially a security suite for a lot of quite major organizations. So what some of the big clients include Tesla, there's quite a lot of jails, schools and hospitals that also use this company, Cloudfare is Cloudflare, sorry, is another big company itself that uses this product. And what they provide is things like security cameras and security camera feeds and analysis over the top of that. And an admin view of all of that.
And unfortunately hackers managed to get a super admin access, credential to a to the carter itself, which they then use to access a lot of live footage from those organizations. So again, healthcare, education, obviously very sensitive and the big copies themselves. So yeah, they just had live footage of these companies and that they can access. Some of this was then released well to Bloomberg and included specific incidents, which yeah, was pretty interesting.
The carter of fixes now and patches out now, but but 150,000 surveillance cameras will totally in total provide access to. And then the final one, this is my favorite one. You have a favorite day to reach a favorite day to reach. So there was a website called Weleak Info, which people might have heard about.
Oh, no, I can see where this is going. It was a details are a bit sparse on it, but the general agreement is that it was a essentially a marketplace for people to sell breached information under the guise of checkout, whether you've been included in a data breach. So they had a total of 12 billion records. So it's not 12 billion different bits of information.
That's 12 billion credentials overall, they were captured in their master database. And yeah, the guys that came under was pay a fee and see whether your information is captured. In reality, quite a little, yeah, it seems a bit more gray than that. The FBI actually sees their servers and the domain itself about a year ago.
So there's an international operation involved the NCA. So that's the National Crime Agency, the FBI, the Department of Justice, the German equipment as well that I'm not going to try and pronounce. But effectively all came together to seize that domain and arrest some individuals involved. There were about 20 people arrested.
So that company was seized that year ago. Then someone realized that the FBI hadn't actually been as judicious in their seizing of those servers as maybe they could have been. And some of their servers were still up is probably the wrong word, but they weren't under the seizure, specifically a payment server related to payments that were made via Stripe. So someone who operates for an intelligence firm specifically, so I guess a more of a white hat situation here, they frankly took control of that domain because it lapsed because the individuals have been arrested.
And they then effectively changed the credentials from Stripe that was pointing to that domain. So they just did a basic password reset. So they quite the domain password reset on the Stripe account. And then through that got all of the payment details of anyone who paid through Stripe on the Wheelie Info website.
So there's about 20,000 credentials leaked from the Wheelie Info website. Oh, sorry, 24,000 payments, turning to about 92,000 pounds. Yeah. Wow.
So it's like inception, isn't it? Exactly. Wheelie Info got leaked. And yeah, there's some questions about the individuals that were on the list of people who would pay for their information from Wheelie.
So yeah, that's the take you should use. Fantastic. Thank you so much for doing all of that. I really appreciate it.
And that's three pieces of very much so news for me, very much interesting listening. But sadly, we must draw to a close as our time has ebbed away. And on this the 30th episode of DBL. So I think I speak for both Chris and I, when I say once again, thank you everyone for listening.
We really, really appreciate your support. If you want to see anything in future DBLs, please do feel free to message us on Twitter or via the email address. Also, also on behalf of everyone listening. But as a special year for you, happy 13th birthday, Chris.
You can keep laughing, but I'm going to be sunning myself on the beach when my 30th arrives. And I know you're envious. So well, he says fingers crossed and touching wood, but we shall see, we shall see. I've at least had my first stab with the old medicine gun.
So we shall see where we go from there. Fingers crossed and did you. For now though, thank you so much for tuning in. Always a pleasure to be here with you.
And from us at DBL for the 30 that we've had and for the 30 more, it's cheers from me. Cheers from me.