Welcome to Cash in the Cyber Sheets. I'm your host, James Bowers, and together we'll work with business leaders and industry experts to dive into the misunderstood business of cybersecurity and compliance to learn how to start making money from being secure and compliant. Welcome to Cash in the Cyber Sheets.
Hey everybody, welcome to Cash in the Cyber Sheets. I'm your host, James Bowers, Chief Security and Compliance Architect here at Input Output. Very happy to have you with us this week on episode 27, and I have to apologize to you. We actually are getting this one out late.
Um, with all the auditing, uh, over the past few weeks, just got out of the rhythm. Um, so normally we were a few episodes ahead that way things like this didn't happen, but had three weeks of audits. So got to a point to where we were doing the podcast basically the week of, and then, uh, this time actually got jury duty and got picked to be on a, uh, on a jury.
So it was in court for a few days and just with everything going on, if I'm completely honest, just, I forgot what day it was. Just, it completely fell out of my head. So at about, uh, 11 o'clock today, I freaked out because, oh my God, today's Thursday, not actually Tuesday.
And here we are. So mistakes happen even with us. It's, it's going to happen to everybody.
So I apologize to you. It's a, I was just thinking the other day, it's super cool that I've been getting these out at 10 o'clock that I've been doing these week after week, but say lovey here we are in any case, very happy to be back with you. And if you've never done jury duty, I think we can all agree.
It sucks. It's inconvenient. But honestly, on the other side, while I was sitting there for a very long time, got to thinking that if it was me in the chair, I would want good, dedicated people to be, to be in my jury and to really give me a fair shot.
So it is aggravating, but cup half full, really kind of a neat process that we have here and here in America, the great old U S of a, so this week we will continue talking about the dirty 13, the top audit findings that we see when, uh, auditing really everybody. We've been tying it to financial firms mostly, and mostly because that's helping with our SEO. But honestly, the dirty 13, these are things that we see across the board when we're doing audits.
And this week I want to talk about backup testing. So we're going to talk about what that means, why it's important. And I mean, obviously if we're talking about it, it's because like nobody's doing it.
So we'll get into that before we do, before we do click that like button, click that subscribe, get on the phone right now, tell your friends, tell your family, everybody about cash in the cyber sheets, get them here and send us some comments about things that you want to talk about. Obviously there's things out there because when we're talking to IT companies, when we're talking to businesses, they always have tons of questions. So get it, get the answers for free, more than happy to do that with you right here, um, and talk about what it is you want to talk about.
So with all that said, let's get into the dirty 13 backup testing, get comfortable in the chair here. There we go. So I don't think I'm almost certain.
I look back at my notes. I'm almost certain that we have not talked about poor backups in the dirty 13. That's a whole separate issue.
This week, I want to talk about the lack of backup testing because more companies than I don't want to say more companies than not, that's not right. More times when we audit, we're finding that companies have backups. Now that's still not a good way to say that.
It is more common for us to find companies not doing backup testing than to find companies not doing backups at all. There that, that came out, that came out, right. We still find a lot of companies that aren't doing backups properly, but it's much more prevalent that there's no backup testing than there is that there's no backups.
So that's why we're going with no backup testing first. And here in a week or so, we'll get into actual poor backups as part of the dirty 13. But the backup testing that I'm talking about is we do all this work to set up our backups.
We're maybe shuffling them out between different storage devices, or we're doing it in the cloud or wherever. And we're doing all this backup. We're spending in some cases, tons of money to do all of it because storage ain't cheap.
And the process isn't, isn't cheap and it's arduous and in a chore a lot of times, unless you set it up to be fully automated, which you should do. But in any case, even that setup, it takes investment, it's time, it's money, it's resources. And we're doing all of this work to back up all of our data and then practically never test to make sure that it's viable.
And we don't find out that the data is not viable until we really need it. So our backup test really need to make sure that the data that we're backing up is available and works as expected when we need to restore it. And I don't think this is going to be a terribly long episode because otherwise it's just going to be a lot of talking about the same thing, beating the dead horse.
But I think there's about really like three main tiers to this. So the first thing that we test backups for is accessibility. Is it, is it even going to be there? Can, can we even actually restore it? There are so many times where we work to, where we go to implement a backup, where we go to restore the data, we try to restore maybe the entire image and it fails, maybe one of the parts of the incremental backups didn't work, maybe the entire thing's corrupted for whatever reason, it's just not restoring.
And that point is terrifying when you got to restore this data and it's not coming up when perhaps you had ransomware, everything's encrypted and you tell, you tell them to go pound sand because we've got our backups. It doesn't matter. You go to restore your backup and none of it works.
That is horrendous, completely defeats the point of the backup could really end up shutting your company down. And a lot of things we talk about, this could shut your company down. This because they could, but the backups is a major thing.
Your data, your data, your information. It's, it's really one of the core things in the business. So number one, you have to make sure that it's accessible, that it's actually going to restore.
The next thing that we want to look for is, is it the expected data? Is this, is this what we were actually expecting to back up? And what we've seen, unfortunately, more times than we care to count, uh, is that the right repositories aren't being backed up or where the data was being stored, isn't in some of the areas that were being backed up or, and this goes to kind of the accessibility, is it going to restore correctly? We weren't backing up all of the data sets. So a good example of that is say the Adobe premiere projects, companies backing all those up, they've got it all. They've got it all backed up.
All of that premier data. They can load those projects they've, they've tested, but what they're not backing up. What they forgot to do is the raw data or any of the video data that goes in there.
So then when they go to start restoring everything, they've got the projects, but the projects don't have anything to reference. There's no data to pull in. So it's very important that we're backing up all of the data that we need.
Are we getting the expected data? Are we getting the correct information? The other one is integrity, and I'm going to come at this one two ways. One from a ransomware perspective, if you don't have your backup set up properly, say you're not doing enough backups and you get some sort of ransomware or you get some sort of corruption to your data and you get through say your week or month, whatever it is of backups, well, now what's in your backup repository might be that encrypted or corrupted data. So when you go to restore it, it doesn't work in this all kind of falls under that umbrella of accessibility.
But that integrity issue is we want to make sure that what we're backing up is what we're expecting. Are we, are we capturing the correct data? The other side of that, and this is more overlooked and deals typically more with archive situations. But when we go to restore the data, can we actually use it? And what will happen sometimes is we've got data from six, seven, eight, nine, 10 years ago, but the software platforms have changed and we have it backed up.
We don't have a system that can support that data or that can support it the correct way. Maybe it's a different version of AutoCAD and now rather than a straight red line, it represents it as a dotted green line, which could be horrendous if you're building something like a power plant. Part of our backup is we need to make sure that we've got the platforms that can actually use it and display it in the way that it was originally backed up.
And this one can be very difficult, but on the financial side, it's one of the reasons that, that we stress, and you have to make sure you retain a copy of each version of the software. Retain that copy, retain a system that can support it, make sure that your system can support it. And then obviously also have the data.
So here on our backup test, the things we need to do is one, make sure that we can access the backup repositories, make sure that we can actually restore the data. We need to make sure that when the data is restored, that we can access it and use it in the way that we expect. And part of what that's going to involve is making sure that we have a system that can run the applications that are needed to backup that, not the backup, that are needed to restore that data.
So our backup tests aren't just making sure that it's there, which is what we do see a lot when companies are saying they're testing their backups, they're going to make sure that they're there. It really needs to be that we're going from pulling the data out of our backup repositories and getting it to a point where we can confirm, yes, I can use this data just as it was intended. I've got the systems, I've got the access, everything I need to be able to use this backup properly, that's a backup test.
That's a restore test. And when you do that, make sure to document it. What data you checked, file that away because that's good audit procedure.
Then you have that little compliance piece checked off and you can be sure that your critical data for the organization is actually there when you need it. So, like I said, I'm not going to beat a dead horse there. Those are the big pillars of it.
Backup your data, test your backups, save your business. Thanks so much for listening this week. Can't wait to see you next week.
Thanks for joining us today. Don't forget, click that subscribe button, leave us a review, and share it with your network. Remember, security and compliance aren't just about avoiding risk. They're about unlocking your business's full potential. So stay secure, stay compliant, and we'll catch you next week on Cash in the Cyber Sheets. Goodbye for now.
