[00:00:00] Speaker A: Data is becoming such an important piece of pause and attack points from an attacker's point of view. It's also, in my opinion, of primary importance to actually protect the code itself. Protect the data, too. So implement the security practices, but also protect the data.
[00:00:20] Speaker B: This is KBCS.
[00:00:23] Speaker C: This is a primary target for ransomware.
[00:00:25] Speaker A: Campaigns, security and testing and performance and.
[00:00:28] Speaker C: Scalability, risk and compliance. We can actually automatically take that data and use it.
Joining me today is Courtney Farquharson, CTO from back ride up. And today we're discussing the final cog in DevOps, data protection. So, Courtney, thanks for joining and welcome.
[00:00:44] Speaker A: Yeah, thanks so much for having me here.
[00:00:46] Speaker C: Okay, so I caught up with you and I think your colleague a fair few months ago, and we were talking about, like, what were we going to discuss on today's show? So I wanted to start right there with the whole term shift left insecurity that we often hear people banging around. It's written in a lot of content that we see online, and people talk about it on social media. But I sort of feel maybe perhaps, you know, people's eyes glaze over once I start to hear that term. So what are your sort of thoughts on the whole shift left approach?
[00:01:17] Speaker A: Yeah, it's a great question. I think there's probably a lot of terms in the sort of cybersecurity world that results in people glazing over a lot of acronyms and phrases that people, especially companies as well, make up, but overwhelming. And even as a tech founder myself, I struggle understanding what the various options do, like ASPM and app risk and IAC and soar. And there's a lot of stuff being thrown at cisos and ctos, and every security company is shouting on LinkedIn about them. So it's trying to cut through the noise. The way I think about shift left security is when you're a CISO or a CTI, you really want to understand what the threats are and how well you're covered as a company. I'll borrow from SNCC, which is a very well known cybersecurity platform, and their front page tagline on their website is develop fast, stay secure. And I think that's really what you worried about as a CTO of ciso. So business wants to go faster, get to market, and the CISO wants to stay secure to avoid anything out, I guess, on the COVID of the local newspaper. Wanting to stay secure can add overhead and costs if the security is not built in automatically into the pipeline of getting code from the development machine to production. And that in essence is the shift left security is how do we get it from the developer machine into production securely and safely. That's a fine balance. You have to land somewhere in between developing fast and staying secure. I think also the concept of shift layer from the concept of security is obviously automating and building in those security practices at the beginning of the pipeline. So if we check in code, instead of having to manually check in whether the code is secure, as a developer, we now have tools that can do that. Rich, it's great we start that security process right at the beginning of the chain. And in the concept of potentially shift left testing, which has also been thrown around a lot, would be implementing automated testing in the beginning of the pipeline. So you're releasing your qas and your testers from manually testing every change a developer makes, and rather than to have a series of automated tests that run against that code to check that everything still works. In essence, then, if you've implemented shift left security correctly, developing fast and staying secure means you can reduce manual costs. So I guess the shift left security, it's a bit of a buzz phrase, but it takes in so many different, I guess, thoughts and optimizations. And I think it's always a process that you never arrive at the end of shift left security. So there's always been more vulnerabilities found every day. There's always more automated testing security could introduce, but then you end up developing soil. So pipeline security is too slow or egresse or over engineered. So, yeah, I think the CIO, CIO services and CTO's core job is to make sure that over engineering, the shift left mechanisms doesn't occur either. And every minute the developers waiting on a pipeline cost business, it's a fine balance push for business, which is, which is constant.
[00:04:33] Speaker C: So Courtney, you mentioned that with the whole shift left approach, you never sort of arrive there. Like, obviously things are always going to evolve and things are always going to be there in terms of vulnerabilities, et cetera. So do you think people ever think, hey, I've arrived and I don't have to do anything more?
[00:04:49] Speaker A: Yes, I think that. I think that people often bring in, well, maybe companies bring in external consultants. I mean, we even work with a couple of DevOps consulting practices that come in and re engineer and help with the shift list approach. And I think that they potentially come in, in there and implement the best practices and then leave and potentially to the upper management might think, okay, we've been there, we've done that, but at the same time, you know, like I said, it's, there's always new vulnerabilities, there's always new ways of doing things. Assuming your code base is growing and growing, you know, those practices have to be implemented for the new code content. Maybe that's being produced. So I think it's an ever evolving process, especially with how quickly cybersecurity and specifically devsecops is changing.
[00:05:42] Speaker C: Yeah, no, that's interesting as well. And I think that's why getting people like yourself on the show to be able to have this conversation and to explain that, would you sort of say as well that perhaps to your earlier point, like, you know, so many acronyms and all of that, do you think that people just maybe think about this whole shift left approach as, oh, it's just another thing I've got to add to my never ending to do list, and then sometimes people just don't quite get around to it?
[00:06:06] Speaker A: Yes, I think so. I mean, it's because it is quite vague. You know, you've had other guests that I've heard on your podcast talk about shift left, and I'm sure they talk about it very differently to what I would maybe. So. I think the concept of it is different to every person. And so, yeah, I mean, that's always the conversation that should be ever evolving, but potentially isn't. You know, it's not black and white. It's not like implementing office 365 or implementing your ERP and then being done.
[00:06:36] Speaker C: So, Courtney, I want to switch gears now, and I flip over into backups. Now, perhaps, you know, backups is one of those things that maybe, you know, people think. It's not the most interesting topic, for example, but also I think it's one that people seem to perhaps forget about or it seems to get relegated a lot. So, Mamie, talk to me about your thoughts here.
[00:06:57] Speaker A: Yeah, it's a good one. I mean, it's running a backup company. It's. I try to make it exciting, but let's be honest, it's a bit of an insurance policy, I suppose around since the dawn of time in that people have been producing any applications and sort of on premise kind of stuff and backing those up to today where companies are backing up code also content. So an office 365. So with that shift of workload, say, in a company that may have had, like, an email server sitting on premise somewhere, they've now accepted that a lot of that needs to move to the cloud in order to offset maybe the maintenance that you had with on premise services. The next question then comes is, okay, if it's in the cloud then is it backed up? And so countless companies that would assist in backing up, say, your office 365, your salesforce, your Gmail, your G suite or whatever it is, there's a lot of companies that will help you out and implement these backups for you, that space. And so, you know, I mean, and it's relevant, right? So we've seen say, the unisuper debacle with Google, and I'll quote this one, that the disruption arose from unprecedented sequence of events. If those unprecedented sequences of events happened more often. There's stories also in Australia, wherever countless ransomware attacks have a cool office 365 data, like email, word documents, things like that, where attackers use, say, email phishing to get access to employee accounts and then to office 365 data, they can encrypt it and demand a ransom to the data. So if you have an unencrypted backup, well then I guess at least you have options, right? So do you actually need to pay that ransom? If I've got another backup of that data, sure, your ransom attacker might use the data, but at least you can get it back. So yeah, I think backups are definitely relevant. The next question I mostly ask people when it comes to code is because predominantly we find that companies come to us, they back up their office 65, but they don't necessarily back up the GitHub or Azure DevOps. Then the question I ask is, well, if you think you were documented email content stored in the cloud isn't, why would your code content stored in the cloud not be as important? Right. So code repositories or metadata around that code, GitHub or Azure DevOps, why is that not equally important? I mean, I'd even argue that you likely paid more for your code content than you did producing word documents, right? So content and cloud should generally be backed up and whatever system also matter, you know, whatever system it is in. And so the code and associated pipelines and work items and tasks and all that kind of stuff is, I guess, just as vulnerable as your word documents.
[00:09:48] Speaker C: Okay, so you said when you're asking people around, why wouldn't they back up their repositories, like GitHub for example? What do people say to that?
[00:09:55] Speaker A: Yeah, that's a great question. Right. And it's a very valid one too. I think probably the most common reason we hear is because engineers and potentially even management that may have an engineering background will say that the git system is decentralized. So really what that means is when the team works on code, let's say you and I work on a code repository. I pull it down from the cloud onto my local machine and then so do you, right? And so we both work on it. We both have a full copy of the code and all the history that's occurred. So really if I got hacked today and everything was deleted, you could come to you or I and say, okay, let's restore that from the local copy that we have on our sheets. And so people and companies feel confident in that, right? So they'll just say lost everything, they'll just go to their local, they'll just go to the developers, right, but you can kind of see the holes in that, right, because how does that scale? Let's say I have 2000 repositories of code. Let's say you have a code repository for a yemenite mobile application that no developers touched in two years and somebody comes and deletes it and every developer since left the company or got a new laptop, now you're a little bit stuck, right, without the backups. And then what about all the issues if you lost those because of all of these code platforms, they track the issues around sort of like a jira where you're tracking the tasks around developing code and then all the pipelines.
Effectively you would have spent maybe hundreds of thousands of millions implementing these secure coding practices. And so definitely valuable to back those up. And I think sometimes people overlook the edge cases in terms of backup.
[00:11:47] Speaker C: Okay, so there's a couple of interesting things you said before that I want to revisit, mentioning more specifically the uni super case. So maybe what you can do is provide a little bit of an overview for people who aren't familiar or for people who live overseas and aren't as exposed to that situation. And then you mentioned before, I'm, you know, I am present in like sequence of events, but what we are often seeing in the market, as you would know, like these things are becoming pretty common now. So it's not like it's, oh it's unprecedented. Like it's just, it's happening. Would love to get your thoughts then on the exploration of the uni super. And then, you know, people sort of trying to perhaps sweep these sort of things under the carpet because these things are becoming really common now with large companies as well. So it's not like, oh, it happens once in a hundred years, like it's happening quite frequently, potentially.
[00:12:30] Speaker A: Like even from a political standpoint, we wont go too far into that. But the sort of security and cyber side of things is a very interesting attack point for any company these days. 20 years ago, hackers may not have thought about or malicious people would not necessarily thought about attacking a company from a code point of view or content point of view. So they might have had to try to manipulate companies in the, say, invoice scams or things like that. But now with people's content all in the cloud, it's becoming more and more prevalent. Right. So if you look at the unisuper case, you've got people's super accounts, let's say my balance, which is just a number and it's a number in a database. So if that disappears, it almost feels like it's your word against mine as to how much is in there. It's becoming more and more prevalent to be able to have backups for this kind of content. And that critical infrastructure that affects everyday consumers is all there in the cloud. So I think from a backup standpoint, it's very important to back up that content and then also the applications that actually support that content and of course the code that supports those applications.
[00:13:52] Speaker C: And then you mentioned before as well, Courtney, that uni Sieber were lucky to have backups of their backup, but I'm assuming that companies don't have that at all. So in this particular case, just say they didn't have that. What would have happened?
[00:14:03] Speaker A: So if they didn't have the backup of the backup? I don't know the intricate details of that particular case, but I do know that the unisuper CTO relied on a third party backup, which may or may not have been Google themselves. But what we see in the market is, and what background up provides is three, two, one, backups. Really what that means is that people or companies backup their code, say, to, let's say I'm running Azure DevOps, which is a Microsoft product, I might backup my code to Azure. But what happens if all of Microsoft goes down? You know, wouldn't I want my code elsewhere? Wouldn't I want it in TCP like Google Cloud platform? Or wouldn't I want it in AwS? So what we're seeing more and more companies wanting to do is to have a copy in Azure and then have a copy in an alternate, I guess, data provider. Right? So that really offsets that risk.
[00:15:05] Speaker C: Yeah. Okay. I think that makes sense because this is more so just, I'm just thinking about the average sort of company, right, and their maturation around these things and sometimes not having like having a backup of a backup like that. You know, a lot of people probably aren't even in that position. Think I've got a backup. Maybe it's, you know, backed up a couple of months ago, maybe it's that. But, you know, you've probably seen cases in your experience where people aren't doing that at all. They're not doing it as frequently. Like, what do you think perhaps where people go wrong when it comes to backup? What do you think it is? Is it one of those things where again, it's something that just go, you know, is the long list of things people need to do? And, you know, sometimes backups just aren't high on the priority list at times. So what, what are some of these misconceptions that you often see when it comes to backups?
[00:15:50] Speaker A: The one thing that people sort of see from the top, they might get, say the board, the board of the company might say, hey, how protected are we if it all goes wrong? What happens? They come out to the market and they say, ok, let's see. If Office 365 goes down, can we still recover our documents? So they go, okay, let's back those documents up to another provider. So they back it up to Aws. But then the first thing that they might not do is ever check that they can recover from it. So in some instances they try to run the restore and not so much these days, but certainly there are cases of it previously where they can't actually run the restoration process. And so we have companies, too, wherever they come to us, and they rely on us to not only backup the content but also run what we call BCP testing. So business continuity, I think it is testing. So they're able to make sure that in the event that things do go wrong, they have a process to actually run those restorations and that when they do it, it will succeed because they have been testing it, you know, months before.
[00:17:08] Speaker C: Do you think people are doing that, though? Like, because that's sort of like a nice to have world, especially when it comes to, like, BCP side of things.
I know a lot of friends in the industry that, you know, run a lot of these workshops, et cetera. But from what I'm hearing is it's like companies just aren't doing that or they're saying they're doing it, but then when something goes wrong, everyone sort of just freaks out. It's like, well, we don't know what would, we don't know what we're supposed to do.
[00:17:29] Speaker A: Yeah, I mean, and it's, it's really complicated sometimes because to comply with, I guess, certifications like say SOP two or ISO 27,001 or even apras for financial companies, they need to comply with these regulations where they're meant to be testing all of these things, but they're not. And we obviously monitor our usage on background up. And I would say that there aren't that many companies that are actually running these restore procedures. We're confident and 100% confident that we can restore, but we don't have a lot of companies that are actually running these tests every month. So I think your view of the market is definitely correct. I think that people are regulated or doing these things, but are not actually doing that in reality.
[00:18:23] Speaker C: So in terms of sort of backups in general, maybe can you give us an example of, and you can pick a type of company, an industry, give us an example of what a good backup strategy would look like from your experience.
[00:18:35] Speaker A: Right.
[00:18:35] Speaker C: So I know it's like all, it depends, but maybe just give us an example so people can understand a little bit more around what your thoughts are when it comes to this. What are the things people need to take into consideration that are reasonable?
[00:18:48] Speaker A: Yeah, sure. I think I'll look at it from a code point of view in terms of backing up your code, because that's probably what I know most about. There's a lot of standards in the backup industry which again, are not necessarily regulated, but, or sort of best practices, one would say. So the first one that comes up quite often is immutability of backups. Really what that means is you basically create a backup and then make sure that it is only read only. So you can never overwrite that backup.
So in that instance, let's say an attacker got hold of that backup, they wouldn't be able to overwrite it in any case. Or if a backup provider was to inadvertently, you know, ship some kind of bug that, you know, the backups didn't get overwritten. So the immutability, meaning the practice that those backups are never overwritten, is definitely a best practice that occurs and is pretty much standard now and then the three to one backups also is another common best practice. So the idea, as I said, you know, you have three copies of the data, one in production, which is your actual data, and then another copy, which is potentially in one of the cloud providers. So if I run that backup or run a backup of, say, a code repository, I can back it up in a, in a format that's easily recoverable, say, to azure or Google Cloud, and then I have one more copy, which is potentially on premise too. Right? So we support something called SFTP, which is a way for you to connect our software to, say, an on premise server somewhere. So even if the cloud version or that backup disappeared, then there would be another copy. And again, we get to that backup of a backup. Right. So the uni super case where, you know, they, they really relied on that third copy. And so that's another best practice. And then lastly, what we're seeing is people encrypting those backups. So if a hacker was able to get to the backups, then wouldn't it just be easy for them to download them and effectively back to square one? So the next practice that people and companies are implementing is the encryption around those backups. And that can be endless too, in the way that you encrypt that data and the best way for it to keep those encryption keys safe as well.
[00:21:19] Speaker C: Okay, so that's interesting. Okay, I want to follow this a little bit more. So going back to the three, two, one example on the backups, would you say generally if you had to wait it, do you think people actually have the backup of the backup? Is this a common that, like maybe perhaps, you know, mature organizations have this sort of approach and this capability, but just generally speaking, with your experience, like, do you think people are doing that at all? Like. Cause I, like I said, I'm even some people saying that they don't even have a backup, let alone a backup of the backup. So, I mean, what percentage of companies don't have the backup of the backup, for example, if you had to weight it?
[00:21:56] Speaker A: Yeah, good question. I mean, I would say only 10% of our customers might be using a secondary storage. So that there's the copy in production and then there's one backup, and then there's a third backup. Right. So we call that the secondary storage that, you know, is probably 10% in our case. Now, you would expect in some of our larger customers that you would know, say, telcos and things like that. They're almost always using those. But then if you look at a small software house, you know, potentially under, say, 50 employees, maybe just a local agency, I would guess that they may not even have backups at all. I guess it all depends on that risk profile. And that usually, in my experience, stems from trying to blow it.
[00:22:45] Speaker C: Yeah. Okay, so then I've got another question as well, which I've asked people on the show recently. So going back to that it outage that we experienced now, it was actually, my husband was talking to me about. He saw someone on the news saying, you know, in an ideal world. We have, you know, this whole Abcdefg sort of, you know, BCP process. But then he was like, this is not feasible for companies to actually, you know, employ something like that. So, like, where do you draw the line when it's like, I don't know, you say you turned around and was like, okay, Carissa, well, we're going to have, I'm making this up, by the way, three backups of the backup, because that makes sense. And just in case something happens. But where do we draw the line when it becomes, obviously businesses are in business to make money, right? And this is an executive podcast. So it's like from, if I put my security hat on, I get it. And then the other side of it, when it's, you've got executives that trying to understand security and all these types of things and writing all this money, where do we find the balance between making money to make sure our business continues but they're not going down the path where we're just overdoing it. Because like I said, in the perfect world of this, it outage, for example, we just can't have plan a to plan e in place or else businesses would just go bankrupt. So how do you, would you sort of find the balance between that?
[00:24:02] Speaker A: Yeah, it's a great question. I sort of put myself definitely on the more lean approach, and that's maybe because I've run startups myself and I've worked for Microsoft myself. So I've seen over engineering. I've seen, and I've worked in government institutions as well. And you see a lot more over engineering there. And what I mean by over engineering is, I guess, employees. And there's this over sensitivity around, like you said, having backups or backups of backups, and we just keep going, right. And so it's endless. And potentially in a government situation, necessarily, and I might be speaking out of turn here, but they don't necessarily have to be too concerned about the profit at the end of the day. They really have to be concerned about delivering a service, right? So potentially having five backups to deliver service, New South Wales, for instance, is a good thing, right. Because at the end of the day, we want to make sure that our license data and everything else is safe no matter what. Right. So we need fire back. I think the, you know, and then you got on the other side of the coin like you were alluding to, you know, it's just not feasible and it's just not in the company's best interest from a business point of view to make money and then spend a all of it trying to secure what you have. Right. Because that's just at the end of the day, it's the way that your company will go downhill. So I think the automation piece again, is what we come back to.
If you could put your, I guess your backup hat on for a moment. Implement the best practices which a lot of backup providers provide, say companies like Veeam or Rubrik, where just by default they're able to plug into your office 365 and create you two backups. And that's pretty much all automated as long as you provision your own storage. Companies like background app or even Veeam and others are able to just provision that storage. Sorry, provision the backups within the storage that you create. That's usually good enough for most companies then from a process point of view and not spending endless resources on actually creating those backups. And I think that that is probably the starting point. And then after that you start to think about, okay, do these backups actually work? But that again, you're not going to start spending money on somebody actually manually restoring things and checking that they work. So again, that's going to eat into your profitability. So there's a whole line of, I guess, measures and you pick where you want to lie on that versus the kinds of risk that you want are happy to have as a business.
[00:26:46] Speaker C: Yeah, I think that makes sense because again, like, at the end of the day, like, of course, like from a security point of view, we want to do all these things, but it just, it just doesn't make sense sometimes. Like you said, some people over engineer it, right? So it's more about having conversations like yourself. Like people yourself on the show to, yes, talk about the security element of it, but then also want to focus on, you know, executives and what they, what they're responsible for. So it's like, yeah, that's cool, but like, I can't literally come at the end of the day and I have $0 left because I've gone and spent all on backups because I've got seven of them. Do I need seven of them? Probably not. So I think it's around, well, where's the line? And I think sometimes perhaps in my experience, people perhaps get lost in the vision of what they really there to do. And it's not to literally blow profits on all the technology capability. Like, I get it. But at the same time, I think perhaps you will lose sight of what they're there to do, which is to make sure the business keeps operating.
[00:27:42] Speaker A: Yeah, sadly, there is a lot of what I think is the mongering in the security world. A lot of the time people will or companies, especially platforms, will say to you, you need all these things, you need X, Y and Z, and if you don't have it, you're going to get hacked and you're going to get phished and you're going to be on the front page of the syndrome Heraldez. There's a bit of fear tactics in there, but at the end of the day we actually do live in by the numbers. We actually live in quite a secure environment in terms of producing applications. Sure, accidents happen and they come to the top of the media, but they are very few and far between. And I say this as a company in the security environment, I think that these practices are really, especially from a backup point of view, an insurance policy against things going really, really wrong. But day to day, typically we're in quite a safe environment.
[00:28:44] Speaker C: So I want to focus on resources that you mentioned before, but perhaps maybe talk us through human error in managing DevOps data. What does this sort of look like?
[00:28:55] Speaker A: Yeah, so I mean, maybe some examples are best. We have had companies come to us. I would say they would come to an office 365 or Salesforce data protection tool where they'll, you know, they may have. Let me think of an example. The first one might be a migration. So we have had a customer who is doing paying migration from Azure DevOps to GitHub. They corrupted some of their data in moving it and they had already removed it from Azure DevOps. And so we're in a situation where they couldn't restore it into GitHub. And so from the human, I guess you could put that down to human error. We also have had a customer come to us that thought that. So they were a software house, they were working with the developer. The developer said that they had given the source code to the client, client said that they didn't have it and so the code had basically disappeared. It had been removed costs point of view from the software house. So obviously hosting code, you have costs, software house removed that and the client didn't have it either. So from a human error point of view, I think there's probably two of the examples I could think of offhand where that does come into effect.
[00:30:09] Speaker C: And would you say as well with automation, et cetera, it's going to reduce a lot of that error now and it's also going to save costs because again, people that are perhaps spending a lot of money on resources of doing this stuff manually can be reduced by automation, et cetera.
[00:30:26] Speaker A: We run a platform which automatically searches your DevOps on a daily or even more periodic basis and finds any new content you might have produced. So first one being code, but then also tasks and work items and attachments and everything else that's stored in your DevOps. And we automatically find it and back it up for you and push it to your storage without you, even, even mine. So, you know, the automation piece of that is very important.
[00:30:53] Speaker C: So I want to sort of switch gears now and I want to focus on, we've sort of touched on a little bit. Maybe you can go a little bit deeper into, you know, a ransomware attack, for example. So maybe talk us through this. What does this look like? And then perhaps some of the fallout you've seen businesses go through because maybe they don't have a backup and they definitely don't have a backup of a backup. What does that sort of look like?
[00:31:15] Speaker A: Yeah, that's right. So ironically in 2022, Microsoft themselves, who run Azure DevOps. So you think about obviously Microsoft produced code. So they run Azure DevOps internally, which is their own platform. I mean they also now own GitHub. So they own the two biggest code sources in the world. They at the time are running Azure DevOps internally and they had their Azure DevOps ransom by some hackers that were able to get access to the Bing maps source code. So as much as I talk about fear mongering, I mean, I can tell this story to customers too, in terms of the source of your code has also been hacked. So that again is not a common outcome, but is clearly possible.
And we've had another example of where a customer has come to us having experienced a ransom attack. Sadly, backup doesn't help after the fact. So hacker gets in, they download all the code and then they effectively delete it overnight. So that's what happened to this customer came to us, they deleted it overnight. And then when in the next morning the developers arrived to basically no code. Of course they have their local copies, but as I said before, it could be older repositories that no local copies. And then once they've deleted all, they put a price on it and say it's a million bucks, you purchase a million bucks and they'll give it back to you. Right. But at least with the backups, you're not at the mercy of that attacker. Right. So you had no backup, you have to pay the ransom and then they take your money and you don't necessarily get that code back. Right. You can just take money and walk away, but at least you'll get backup, you stand a chance. Right. At least you have that option to be able to restore from backup and, and take that ransom attack of play somewhat.
[00:33:03] Speaker C: That's a good point that you raise around being at the mercy of people. Right. And would you say at times people are in that position like, well, I don't have anything else going on, so I feel like my back's against the wall?
[00:33:15] Speaker A: Yes, definitely. I mean, in the example we had a customer, I'm not sure of the full story, but I do know that that customer paid that ransom attack. Luckily the hacker was able to give their code back, so that ended well. But I guess you don't really know who you're dealing with.
[00:33:33] Speaker C: And what do you sort of see moving forward now with, we've touched on the importance of backups, but then also perhaps this whole unprecedented sequence of events, but these things are becoming common now with what we've seen with very, very large technology players out there. So it really can happen anytime, anywhere. And look how quickly our whole world sort of came to a bit of a standstill depending on which industry you're at. We're in. Do you think now people have to start really focusing on this because it is going to become probably a common occurrence, and I hate to say it, but it probably will. Cybercriminals are getting better. It's easier to do things now more than ever. We've got AI, we've got automation, so things are becoming faster.
Is this something that people do need to start to pay attention to? Because as we've seen, our whole society can stop very quickly when something goes wrong because it is a bit of a domino effect. So what are your thoughts then, Courtney? Sort of looking ahead and how businesses are reacting to these, for example, large it outages that are occurring right around the world.
[00:34:32] Speaker A: Data is obviously a great attack point. Right. So you're probably alluding to the crowdstrike outage where, you know, all these machines were effectively offline. And I know of customers that had a whole bunch of developers that couldn't work right while they stared at the groove screens. And so something small like that could easily be engineered, right, in the same way that, you know, attacking somebody's code and attacking their data that they have is probably the best way of bringing down a customer. You're bringing down a company, you're just really hamstrung by that situation. Right? You can do nothing without your word documents, you can do nothing without your salesforce data. You can do nothing without your code. You can't produce anything. So more and more, it's basically attacking somebody's data is the best way to bring them down. So what does that mean? It becomes one of the most important points to actually protect.
[00:35:30] Speaker C: So, Courtney, do you have any sort of closing comments or any final thoughts you'd like to leave our audience with today?
[00:35:36] Speaker A: Basically, there is a lot of, there's a lot of acronyms, there's a lot of content coming at you. There's especially in the cybersecurity world, and there's a lot of fear mongering, I think, you know, if you get back to basics, rarely at the end of the day is implementing best practices from, you know, some of the great providers in terms of shift left, you know, looking at companies like sneak, where, you know, you can protect that, you know, that code base, you know, definitely from vulnerabilities, from, like, testing and be able to optimize the way that you produce code. But I think also because data is becoming such a, you know, an important piece of, or important tack points from an attacker's point of view, it's also, in my opinion, of primary importance to actually protect the code itself. Right. Protect the data, too. So implement the security practices, but also protect the data.
[00:36:38] Speaker B: This is KVcast, the voice of Cyberez.
[00:36:43] Speaker C: Thanks for tuning in. For more industry leading news and thought provoking articles, visit KBI Media to get access today.
[00:36:51] Speaker B: This episode is brought to you by Mercsec, your smarter route to security talent. Mercsec's executive search has helped enterprise organizations find the right people from around the world since 2012. Their on demand talent acquisition team helps startups and middle sized businesses scale faster and more efficiently. Find out
[email protected] today.
