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 everyone welcome to episode 16 of 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 back with us here at Input Output.
We're starting to get into audit season, audit and pin test and vulnerability test season. And this is the time of year when some people start remembering that they have to do these. It is going to be in another couple of months when we have almost no time left in the year that everybody will remember that they have to do their annual audit, that they have to do their annual pin test.
And like a surprise, it shows up every year. So very busy, very stressful time of the year as we start getting into towards the end of the year. Definitely not where I thought I would be owning my own business.
I figured it would be a nice relaxing holiday season. Just gets lots of time off, but not so much the case. But that's okay.
Not complaining about it. But one thing I wanted to talk about today is in the audits that we're doing, we always find a lot of different controls here and there that companies are having trouble with. But this is around data backups and some pretty serious things that if they're not done and if they're done like some of the companies that we've recently audited, it could actually end up putting you out of business or an even more hot water.
So it's very, very important. I really want to dive into some of the main points. And like a lot of the episodes, we're going to have a companion article.
So you'll be able to go on to inputoutput.com slash blog. It'll be right there. And that's going to go into a lot more detail, give you a lot more nuances.
And we'll continue to put some more articles out there and some useful tools that can really help you develop a good data backup plan. So a lot of important stuff there. So going forward, like every week, please click that subscribe button.
I click follow, leave us some comments. Love to hear from you. And before we actually get into the data backup talk itself, definitely trying a lot of new things on the marketing side.
And one of them is getting the social media platform going, obviously the podcast, which was a long time in the making. You know what? If you're on the fence about making a podcast, I would say just do it. It wasn't difficult to get things rolling and set up.
The commitment and making sure you have one every week or whatever your schedule is, that's where it comes in. But honestly, the biggest thing is it's the sitting on the sidelines or the analysis paralysis. Like a really good business partner, a coach of mine says you can't steer a parked car.
So I put that out there. If you're on the fence yourself about doing it, one, happy to talk with you about it. You, full disclosure, would have much better resources anywhere else, but definitely happy to share my experience.
Maybe we'll do that on a podcast, the ups and downs, what we've learned. But just get out there, do it. Rip the Band-Aid off and move forward.
But that's one of the things that we're doing a lot with the marketing, with everything else. And I think just like everybody else, chat GPT is a very big part of that. Obviously, we're not using it to create all of our content.
It definitely helps in areas. The way that we use it a lot is really it helps get over that analysis paralysis or it gives a good foundation to start polishing and to develop. And a lot of times it'll create something that I don't want to say it like that at all.
I want to say it like this. But that, again, still got the ball moving down the field. So if you're not using chat GPT, Claude, whichever, there's so many more.
If you're not using it at all, I would definitely say try it out. And don't go into it with the expectation of having it do everything for you. But it can be a great sounding board.
And one of the ways that I've used it is actually created a whole prompt, almost a whole persona in there of another risk analyst and business entrepreneur. And we just riff back and forth. I ask questions and it hits me with questions and it really helps kind of with a good thought process and even with some of the brainstorming on risk management.
So that's actually part of this because we have a lot of conversations back and forth. And one of them has decided to ask it, Hey, I think that my social media posts, the titles we're using, the things that we're trying to get people's attention with isn't the best. How could we do that better? How could we be better? Give in my tone, in the way that we've talked, give me some titles that you think that would be good for our companion data backup article.
And those are the ones I wanted to share with you. Now, there are a few in here where it started off that were kind of more click bait style. All of them are kind of click bait style, which is what we're going for a little bit more as a joke.
But some of the tame ones here, how a drunken squirrel almost ruined my business, but data backups saved the day. Why your business continuity plan is one pizza party away from disaster. Your business is doomed unless you read this, but I bet you won't.
Now, I think those are, they're not bad, you know, especially with it being able to come up with it in just a few seconds. But what's a little concerning, I don't know if concerning is the word. I don't know if I'm tainting it or if it's more of just a reflection of me and my conversations.
But I asked it to give some articles a little bit more on the side of the professional unprofessionalism that we have, even with cash in the cyber sheets. And those are a lot more interesting. So I think some of the gold ones here, well, that is really loud.
Why data backups are like condoms. You'll regret not using them. It's that it's very true.
I think that actually hits, I think that's a better sales pitch, a better elevator pitch for data backups than any of the others. But some more that it gave, and we're definitely looking for votes for which is the best. My data was screwed, but not in a good way.
How backups gave me the happy ending I needed. How data backups prevented my business from getting completely fucked. That one's not bad.
Why skipping data backups is like raw dogging your business, risky and stupid. And that's a good conversation that you can have with your teenagers too. So it kind of opens the door two ways.
Data backups, the only thing standing between your business and a 2 a.m. booty call from disaster. Data backups because trusting your IT guy is like playing Russian roulette with your business. Why not backing up your data is like going commando in a hurricane.
I think that would be more impressive for some people. Growers, not so much. And why not having a backup is like sending nudes to the wrong number.
You can't undo that shit. No, you can't. And a story for a completely different time is how we learned how Android phones used to manage their texting order and how you could accidentally send images to the wrong person.
Some of my friends got some very interesting things, but we're better friends for it now. So I don't know if that's my endorsement. I don't know if that solidified your reasons that you're not going to use chat GPT or any other platform, but what's going on behind the scenes? I liked it.
I got some giggles. I actually went down the rabbit hole with it for quite a while. But moving forward actually to the data backups, what you really care about.
I really want to talk to you today about these are some of the things that a lot of companies don't consider, either some or sometimes all of these, but they can snag you in different ways. And just doing these, I think it's 11, 11 different things is at least good to consider for all of your data backups. And we'll make sure that when things go sideways, you're actually protected.
But that you're also not creating more problems with the data backups themselves. Because that can cause you regulatory issues. It can cause you privacy issues.
All kinds of things that a lot of people completely overlook. So first and foremost, this seems like it would be, I think, a no-brainer. But it's not, is actually identifying all the critical systems and data in your company.
Map that shit out. Actually draw it. Get yourself a nice glass table like this and a magic marker, not a magic marker, a dry erase marker like a kid.
A dry erase marker and just start sketching it out. Use a big whiteboard, whatever. But draw it out.
What systems do you use? If we go back to our risk conversations from previous podcasts, previous talks, where we talk about the core business metrics, leads, conversions, average lifetime value, average lifetime, expenses. If we look at those, then we can look at what are the systems that support those, what's the data that supports those, and that's how we identify our critical systems. And then, that's also part of our business continuity.
We can make sure that we've got the continuity in place, the disaster recovery in place, and as part of that, we can have the data backups properly backing up the data. So, when you're creating that data model, that network diagram, that data flow, threat model, however you want to call it, make sure to put the information about the backups on there, how that's being done. This is also really good because it actually ties into one of the others, is the location of your backups.
You want to make sure that your backups are in locations that, one, they're accessible when you need them, but two, that it's not creating a situation to where if a system goes down or an area goes offline that you've lost your backups as well. So, very, very, very important. Identify all of your critical systems and data.
And listen, if you've been in the business a while, in your business, your organization a while, you really understand it and you know what all of these are, that's great. Go ahead and map it out, write it all down to make sure it's there. It's amazing what actually looking at it on paper or whatever medium will help jog your memory and talking through it.
So, I can't stress this one enough. So many times we find it that companies have overlooked some critical system or data and it causes such an issue. So, the next is, and this goes into identifying the critical systems, but understanding your business continuity requirements.
We understand our metrics, we understand what support those, now we need to look at how to keep those running. Systems are really useless without the data, so it all goes hand in hand. But, this goes back to understanding critical systems and data, and I'm saying that a lot because it's really, really, really important.
It's overwhelmingly overlooked. These are the biggest issues that companies overlook is not backing up or not structuring the backups for those critical systems and data appropriately. Tie that in with your business continuity and that way when you're working on these things, you're moving all kinds of things down the field at the same time.
Your risk management strategies, your backup controls, your implementation, your business continuity planning, all of it. So, it hits well. It's a really good investment of time.
The next two is really understanding your recovery point objective, your RPO, and your recovery time objective, RTO. Now, your RPO is basically, there's a lot of ways to say it, but easily put, how much data you could stand to lose. So, if our RPO is 24 hours, we have to be able to restore data no farther back than 24 hours.
I think I'm saying that backwards. We would want to have at most, we could lose a day's worth of data. That's a better way to say that.
So, if we lost 8 hours, that's fine. That's still within our RPO. But, if we didn't do a backup except for like 36 hours ago, well, that's exceeding our RPO by 12 hours.
That means we're losing more data than we could do without. And this will vary wildly between businesses and between systems. For a lot of what we're doing, it would suck to lose data.
Don't get me wrong. It always sucks to lose data to have to redo work. But, it wouldn't put us out of business.
It would just be duplication, a lot of duplication of effort. Because we don't even really store any critical data. We're very cognizant of that.
We structure everything to where we have very limited access to information. And even when we do, it's pretty much immediately scrubbed out. That's all part of our risk management strategy of being where the problems aren't, rather than trying to put all kinds of controls into place.
That's a whole other conversation. But, understanding the RPO is very, very important. For somebody like Amazon, where you've got tons of orders coming in every minute, every second, five minutes of downtime would be a lot of lost orders.
That almost could be unrecoverable for those orders. It would just pretty much, we're not going to have those. So, sometimes the same case in medical offices, high volume databases, the RPOs can be very low.
In other areas, it can be high. And what this is going to identify, your RPO is set by management. They're saying, this is what we need to operate the business.
This is one of our business objectives. Queue up ISO 27001 objectives. That's what that is.
Here's our RPO. Then you can design your data backup strategy to meet that. So, our RPO is 24 hours.
We're going to put in a system that integrates with our cloud. It backs up every 12 hours. That way we can be sure, even if one fails, we've got another one right around the corner, so we'll be within that 24 hours.
So, the next one is our recovery time objectives. And that's more, that's really just how long we can be without the data. When do we need to get it back online? So, I may only be able to lose six hours worth of data.
My RPO is only six hours. But, I could go two days without having access to that. Maybe I could even go a week.
So, my RPO is two days or a week. But, if we exceed that RTO, we've gone too long without that data, without access to that system. And that's where we're going to have a major impact to the business.
This is, again, set by senior management. They're saying, this is what we need to operate. We need to, we can't lose any more than this amount of data.
And we have to have access to it no longer than this amount of time. Your RPO and your RTOs will allow you to then choose the data backup systems. They'll let you identify what type of systems you need to look at for recovery, how quickly you can get things back up.
It doesn't do any good if you are backing things up every minute. If it takes you weeks to restore it, that may essentially be useless for your company. So, very important management.
And the RPO and RTO are very rarely identified in a company. These are a lot of times assumed by IT or roughly discussed with management. And when things hit the fan, when there's an impact, when we go to restore, that's when a lot of companies are finding out we don't have what we need.
What we actually need is not here. And that's a bad position to be in. So, make sure to identify RPO, RTO.
The next is all of the regulatory requirements. There are certain regulations. I should say practically every framework discusses data backups because they're super important.
But there's some regulations that it's a legal requirement. HIPAA requires that you have data backups. You have to maintain the majority of the data six years since last use.
And if you don't have it, you could be in serious legal trouble. That could lead to lots of fines, lots of problems. PCI, payment card industry, they're another one that has requirements.
And FTC safeguards rules. So, these are PCI is not a legal requirement. It's a contractual between you and the payment card industry.
But FTC safeguards rules, that's regulatory. HIPAA, regulatory. Those are U.S. government.
And there's plenty of others out there. So, you want to identify what your data backup requirements are and make sure that you're adhering to those. What we find a lot is a lot of companies are backing up data for a year.
But they don't have any longer than that. And if they're, say, under HIPAA, they won't have the data that they need for the six years since last use. And where this gets into trouble that a lot of people have a false sense of security is that they have the whole data sets there.
So, it's in that data that's backed up for a year. So, they'll have data in that backed up data set that's older. But if files are deleted, files are moved, as you approach that year, those could get scrubbed out and then you wouldn't have access to any of those older copies.
So, that's very important to consider how that works. And one of the best ways to help manage that is it can get very expensive having backup solutions go back multiple years, especially when you have tons and tons of data. But you can always look at, say, high availability for recent data.
Our RTO for data that's six months old is only three days. We need to be able to get access to any data within the past six months within three days. If it's over six months, we could wait two or three weeks.
And in that case, we can use a much less expensive backup solution to move into into more of an archive. So, that's a way that you can have your cake and eat it too. And even with a lot of regulatory requirements, it's very well understood that it could take a decent amount of time to get some of the older data.
That's perfectly okay. You just want to make sure that you can actually get to it. Another thing to consider with data backups, this one isn't as frequently overlooked, but it still is access control.
We spend a lot of time making sure nobody can gain access to our data on our systems, on our active drives, in our cloud environments. That same attention isn't always provided to our backup solutions. So, we have all of this data, all of this stuff we're trying to protect and we put it in this unsecure location.
And sometimes it's just a local drive that somebody could walk off with. It's amazing how many of those that people even forget to encrypt. So, you could just walk right into the server room and grab a drive with every bit of information from that company.
So, it's very important to look at who has access to the data backups. How can they access it? How can we lock it down? However, make sure that you maintain access. Don't just leave it to one or maybe two people, because if something happens to them, now you've lost access to your data.
This is very important when it comes to certain data backups are fully encrypted, like a zero knowledge, zero trust type of situation, like some of our backup solutions. And we don't maintain or even have access to the data keys, to the data encryption keys, the decks. Only the customer has that.
So, if they lose that encryption key, that data is useless. There is absolutely no way that we can help recover it. So, not only is access control about keeping the wrong people out, but it's also making sure that you maintain access.
That ties into availability and accessibility. We need to make sure that we can get to the data when we need it, and that it actually works as expected. I think that's it on that.
We've kind of talked about that, but that ties in with RPOs, RTOs, access, everything else that we talked about. We touched on this one, but the location of backups, we want to make sure that we're not putting all of our data in a place that if there's a disaster there, we've lost primary data and backup data. So, we don't want to make backups of our SharePoints say within our same tenant.
If we lose access to the tenant, we've lost all the data. We want to have out-of-band solutions for our backups. So, maybe with our Microsoft environment, we have a cloud integration, something like InfraScale, and it pulls the data.
So, now we have what's in Microsoft, we have InfraScale. And then maybe we even use another system, like Acronis, or we even do a local backup that's fully encrypted, so it's somewhere else. That way we have the data in multiple locations, so if one or two goes one or two of those locations go down, we've still got access to everything.
So, it's very, very important. What does happen a lot is backups are within the same tenants, and that causes a problem. Or, we've even seen this.
This actually goes more with the access control. It's managed with SSO, and if the tenant is lost, well, now the SSO is having issues and sometimes you can't get into the data backup location. So, again, these are all very important things.
It's also a good reason just to bring up, again, break glass accounts. Every system you have, you want to have at least one break glass, so things go completely sideways, you have a way to get in. Okay, next one.
This is something that is becoming more of an issue. I don't know if it's becoming more of an issue, or just more... Man, I just can't get this out. I'm not sure if it's a thing of it wasn't important before and now it is important.
I think it's more of a thing of it's always been important, but now people are starting to get blowback from it, so now there's more attention around it. There we go. But it's data jurisdiction.
So, it's considered a lot where you store your data. Is it here in the US? Is it in European servers? Is it somewhere else? And that's very important because where the data resides can affect what regulations, what laws you have to adhere to. This can have the same effect with your data backups.
So you want to be sure that you're storing them in correct jurisdictions, that you have the ability to specify where that data is actually going to reside. It's very, very important. It can quickly get you in hot water.
And you don't normally notice any type of issue until there's some sort of data incident or there's some sort of privacy issue and then it becomes a major issue. Now you're having to answer to laws and requirements that you've never considered. You didn't even know that you had to adhere to them.
So, don't get yourself into the situation of we didn't know that was the law. Ignorance is not a good defense there. So, data jurisdiction for where your live data production data is stored, which if you're not already doing that, make sure you find out.
That's very good for if we go back to step one, identifying critical systems and data, doing that map, seeing where it's at. But very important there. The next is, I think this kind of sums everything up, but actually implementing the backup process, but making sure you have the infrastructure there, making sure you have the resources, making sure that you can actually maintain it.
It's very important. And also that you're providing the training and the access to materials so that people can run it properly and access it properly. And the final one, and again is overlooked a whole lot, is testing the backups.
You need to make sure that what you're backing up, you can actually recover. Otherwise, you're just paying a lot of money to store gibberish somewhere that you're never going to be able to use. And it happens considerably more than it should.
Anecdotally, I would say at least 40 to 50% of the time, some backups are trying to be, sometimes the backups that you try to restore don't restore right. And we've seen it in companies with whole data sets and it's a major issue. That can cause problems because now you can't access, now you can't meet your RPO requirements.
You're having to go to a much farther back data backup. So what we want to do when testing is actually try and restore some of that data and to make sure that it's usable. And what I mean by that is I may be able to restore a document and see that yep, the data backup restored it.
I can actually see it on my desktop, there it is, we're good. You need to make sure that you can actually open the document, that it's actually legible, that it's understandable. Versions changed with your platforms that now the older copies won't open.
Or, this is more of a thing of with schematics, but you're using a new version of the schematic software. Is it properly maintaining the integrity? Are all the red lines that were on your schematics still red lines? Or have they changed to green? Which could be a pretty serious issue if you're doing like a design for military equipment or some sort of power plant. You need to make sure you have that right.
Those little integrity nuances, again a whole discussion on itself, but just goes to test the backup and make sure you're getting the data that you expect and that you need access to the way you need access to it. Very, very important. Make sure you can restore the servers, make sure that you can get into the data.
But that's actually just restoring it and trying that out. It's also not a bad idea in your test to schedule times to do a big data set. Restoring a file here or there is one thing.
Sometimes when you try to restore a whole lot of data at the same time, the systems freak out or you have trouble or maybe you find out you don't really have the bandwidth. That could be another thing that you want to make sure it's set up the way you expect it to and that you need it to be. Those are really kind of, I think that was 11, top issues that we see a lot and that are massively important when creating your data backup.
Obviously we didn't go into the different types of data backups, incremental, full, or the ways that you can set up the backup or different strategies. Some of that's in the article. Like I said, we'll continue to come out with different articles, have different talks about more backup strategies and ways to manage it, but not even looking at it from a cyber security threat or such, but just being able to get to what you need to get to.
It's very important to spend a good deal of time on making sure your backups are correct because if they're not, it can cost you, it could cost you your entire business. And I hate to say unfortunately we have seen it happen with companies that they couldn't recover because they didn't have proper data backups. And that's, you're putting a lot of work into your company.
Don't let it fall apart over something that you've got honestly full control over. So backups, backups, backups, very important. I'm done talking about it.
I think that's all the time we have for today. I do appreciate you being with us here on Cache in the Cyber Sheets. Please click that subscribe button or follow wherever you're listening to us at YouTube, Spotify, Apple podcast, anywhere that you're listening to us, please click that follow, send us some comments, let us know some things that you would like to see.
If there's things in your company that you're having trouble with, more than happy to riff on it here on the show for you. And also if you're a business owner, more than happy to have you on to hear your story, the things that you've gone through and how you've made it to the other side. Very, very interested in all of that.
So thank you for listening to Cache in the Cyber Sheets. We will see you next week at 10 a.m.
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.
