Episode 4 - Big, Hairy, Audacious Truthbombs

[00:00:06] Tom: Welcome to the DevSecOops podcast, where we explore the past, present and future of computing in the modern workplace. [00:00:12] Scotti: Your hosts are a trio of experts reportant, each representing different areas within it. A bit like a nerdy A team. So join Tom, James and Scotty for a regular, mostly serious podcast providing you with pragmatic advice and insights into modernizing your IT environment. [00:00:29] Tom: Welcome back to the show. My name is Tom and I'm joined once again by my good friend Scott, the cyber guru. How are you, Scott? [00:00:35] Scotti: Yeah, good, thanks, Tom. How are you going? [00:00:37] Tom: Not too bad, thank you. We are one short this week as our good friend James Vincent has. Well, we haven't received a ransom note, but by all accounts he's working out at a customer site today. So I guess one of us has to get in there and pay the bills and pay for the production values, the high production values that we subscribe to here at Cordon. So we thought we might mix it up a little this week and rather than have something that's a little vanilla, we'd go with something that's a little more edgy and possibly even controversial, and that is sharing some of the big, hard, hairy, ugly truths that we often have to share with our customers. And we have a bit of a reputation for having the hard discussions that others don't want to have with customers. And I know you and I have worked together in the past where we've sort of had circumstances where we've had to be pretty blunt with customers about the realities of their situation. So I'd like to just maybe unpack some of those and we can bounce back and forth and share our various experiences. [00:01:32] Scotti: Yeah, it sounds really good. And we have. We've worked in some very hairy situations several times since as well. So I think this would be an interesting one for a lot of people. We're going to talk about all of the things that nobody really talks about. So I'm really excited for this one. [00:01:46] Tom: If we don't get fired, I think we'll get a great big pat on the back for this one. [00:01:50] Scotti: Yeah, maybe we should have been kidnapped by the customer like James. That could have probably been a safer option today. [00:01:55] Tom: Yeah. [00:01:56] Scotti: So, yeah, let's kick off. So I'm obviously going to pick the cyber topics today because these are things we were kind of planning for the show. We're thinking, well, what really resonates with me. And hopefully these resonate with all the listeners as well. The first one, I think security is a mindset and it can really be as painful or as Painless as you want it to be. I come from an offensive security background, so I started life as a software developer. And if you've listened to the previous episodes, you'll know that I spent probably nearly 15 years being a penetration tester, day in and day out. So I tested systems. I test a system for a week, two weeks, up to a month. You'd see some of the most interesting, some of the most shocking things. So being a penetration tester or ethical hacker, I've seen organizations that do security really well and I've seen some organizations that probably don't know how to spell security but think that they're excellent in. Once again, just haven't really understood how to get the basics right. So I really wanted to dig into this a little bit with you and kind of get your view, Tom, on what you think around what a security mindset is. [00:03:02] Tom: Yeah, look, it's interesting for me, whilst I've sort of dipped my toe into security roles in the past, my background is very much infrastructure, cloud networking, that sort of grassroots systems engineering, if you like. I think we've worked in a particular organization in the past that had transformed itself from a very security immature environment to one where security culturally pervaded all walks of life and all areas within the organisation. I think to me, the real litmus test for whether you've created a security culture and a security mindset in an organisation is people that you wouldn't normally have come up to you bringing potential security issues. So, yeah, the friendly phishing sort of campaign is a good example of one where you've got people coming up to you. I think there's an awareness of that now, but this is where it's just general daily business coming up to you and saying, hey, there's something here that I think we should be doing better, we're not doing secure code review or hey, I've seen this, I think this might actually be a threat or hey, I've been looking at CVEs and picked this one up and this is coming from people not within the software engineering realm or even within my area, the sort of infrastructure engineering part of the business, but from people, people in HR or sales or other parts of the business as well. So I think when you've been successful in developing a security culture, that's where you really see everyone, not just those within technology, come out and start talking about security. And that to me means you've built a security mindset within the organization. [00:04:30] Scotti: Yeah, and that's actually really good. I think it's we talked about this the other day in the office, the hundred monkey effect. We know if anybody's familiar with the theory, you can look up on Wikipedia, it's been disproven. But the theory stands that when the hundredth person starts doing the thing, that you've actually achieved the goal that you set out to do. I think from an organizational point of view, there are lots of reasons why, like I'm a cyber person, someone that's not a cyber person is probably going to go, oh, cyber people always say security needs to be first at the detriment of everything else. I'm not actually talking about that. What I'm talking about is doing the things that actually will make your business more successful in the long term. So things like paying down your security technical debt. Too often have I seen when I go in and deliver a pen test report, you say, hey, we found all of these things. And they say, oh yeah, we knew about that. We never got around to fixing it. It's like, so you knew about the vulnerability that I used to exploit you right? Like, where is that in the next sprint at all? Often it's not. And that kind of brings into the idea that management don't really prioritize or don't really invest enough in cyber. And of course everyone's going to say, I'll spend more on cyber, but. And I actually looked this up today and we work with some really large organizations and this number kind of jumped out at me that you spend 1% of your revenue, or should ideally spend 1% of your revenue on cyber initiatives, cyber activities, tooling, vendors, staffing, all of the things that you need to run an effective cyber program. And if you're a $10 billion a year revenue company, that's $100 million a year that you're spending on cyber, right? That's just cyber. That's not a subset of it spent on cyber. No, that's just 100 million on cyber. And I'm not sure about you, but I can't think of any companies other than the banks perhaps that would spend $100 million on a cyber program per year. [00:06:19] Tom: Bang on. I think the other thing that I was going to mention too was when you have built up that security mindset as well, it's also a value multiplier around your security footprint. So you don't have to spend much more to get an increased set of eyes on your security posture. And I think there's an incredible amount of value in having those many eyes on security. It's the 100 monkeys, which as it turns out, does not have anything to do with writing Dostoyevsky. [00:06:46] Scotti: But you're right. So we talked in a previous episode about users being your biggest threat and your biggest asset. That's correct. So your employees, if they're all on board on the journey, this is great. And I know we're going to talk a little bit more about employees and how you can get them on the journey and what it actually means when you can't around change. But I think it's really important that everybody realizes that cyber is a team sport. You can't just outsource it to cyber. And I'm going to talk about outsourcing as well. But yeah, it requires everybody to kind of understand that it's necessary. I think we are slowly getting there. But I still see organizations today where cyber is an adjunct, an offshot. They're not really included or they don't make themselves available to be included either. But there's another one as well. I saw a ticket today quite amusingly that said, can you please roll back the password protection policy so I can provision this PC? And I thought that's not how you do it. Right. People are still trying and you end up with this wild friction inside an organization. But beyond that, if you're a B2C business security isn't just like, and I see cyber people do this all the time. They say, this is the only way we can do that. You must have multifactor authentication on all accounts. And we work with organizations where they say, well, we measure between when someone logs in and then like what the success rate to the next step is like. So we work with customers where they actually believe that if they force their customers to use MFA when they create an account or when they sign in, she going to turn them away and they'll just go to a competitor where it's easier to buy things. And a really good example of that. Right. So we had the iconic breach recently and that turned out that people had stole their credit cards and their accounts that didn't have MFA and they used weak passwords. Right. So I guess where it would be really good is not just a security mindset within your organization, but also a security first mindset with your customer base. And you can, I think you can take them on a journey. So instead of just saying cyber people, and this is, I'm looking directly at you instead of saying you must do mfa. And that's the only way, you know, what could you do to get your user base into that? Can you incentivize them. You need to take them on the journey. Right. I think a few years ago, if you'd said you need to do all of these things, you need think about if you're talking to your grandma and you said you've got to do these 15 or 20 things to make you more secure, they're going to go, I'm going to do none of it. So what is the number one thing they need to do today, I think is where I'm trying to get with this. [00:09:06] Tom: It's back to that pragmatic adoption of control, really into something that is consumable. [00:09:11] Scotti: Yeah, I think so. [00:09:12] Tom: Speaking of taking customers on the journey, one particular topic that's close to my heart in the interests of pragmatism and keeping things simple. You know, I see a lot of organizations and I've worked either within organizations or with organizations that try and run before they can walk. And by this I mean the place is falling down behind them. They don't have anything resembling any kind of reasonable sdlc. They don't have dev that looks anything like test, that looks anything like production. CI CD is a completely foreign concept to them, yet they're coming out of the woodwork and talking about things like microservices, like that's somehow going to be the silver bullet, or Pennnessy that solves all their software engineering woes. The hard truth here is you're not Netflix. Microservices is a great concept if you need to have this massive level of scale and you've got to eke out every last cent of value out of your platform because you've got things working on a global scale. But really, organizations need to focus on the fundamentals first. And microservices isn't the silver bullet that's going to fix up your shaky shack. [00:10:21] Scotti: You mean Kubernetes isn't going to solve all my work? [00:10:23] Tom: Kubernetes will not solve your problem. It's just adding another problem to your pile. [00:10:27] Scotti: I think you're right. You're talking about, well, hey, do we have the requisite skills to know what we need to do? It's a bit like catch 22. If you had the skills, you would understand that you needed to do something in a particular way and therefore you would have a tidier backyard. And then you would be looking at these newer technologies. It's always the organizations that are kind of lacking their skills and experience and that I've seen that kind of go, oh, we now need to go Kubernetes. I worked after we worked Together the first time I worked at another organization where they had a Java based application for all those wonderful Java developers. And Steve, if you listen to this, you'll be smiling that thought, hey, we need to modernize our legacy monolith application. And so we're going to take our Java application which has memory leaks and falls over all the time, and now we're going to put it inside Kubernetes, inside aws, because that was a great idea. And we've now got ended up with 48Amazon accounts because we didn't know how to do isolation. And we've got Kubernetes all over the shop. Do you know what the actual outcome of all of that was? [00:11:25] Tom: Tom was less reliable and less performant than before. [00:11:28] Scotti: All we would see on Slack every day is can someone unstuck the pods? That was the weird term that they used. But they said, yeah, the pods are stuck, they're not restarting. So all they did was take the bodgy application and throw it into kubernetes and thinking, oh well, containers will solve my problem because we can just restart them and we'll have lots of them. All it did was just add ridiculous amounts of complexity into an already broken ecosystem that actually probably should just been rewritten from the get go. But you do raise some really interesting points though. So if, for example, I said, look, I've got this bodgie application, what would you say would if I was the customer? And I said, tom, what should I do? What would you recommend in this situation? [00:12:07] Tom: Look, I'm not, I'm not a software architect or engineer, but what I'd actually look at doing is how can we do what we're doing now better? You know, these organizations were struggling to release things into production without causing outage. That's the first sort of thing you need to look at is why can't we do this in a safe, effective, efficient. And I think the problem was they were trying to jump to Z without. And I'm not saying there's anything wrong conceptually with microservices or kubernetes, containers or whatever, I think. But you need to get that foundation layer right first. If you're not able to release a patch into production right, there's something wrong with your qa. It could be something wrong. As I mentioned earlier around you don't have environments where you can adequately test in production like environments. So your dev and your test don't actually look anything like your production. So when you come to production, there are all these surprises. Jump out of the woodwork. That's one that get that SDLC formalized and working like a well oiled machine. Then make sure in your production and production like environments you actually have a capability to patch without downtime. So just basic stuff like throw things behind a load balancer and make sure you can cut over and direct traffic between back end sets. You don't have to jump to this infinitely scale out sort of concept. It's just the fundamentals of that old three layer application that's behind a load balancer. Do that stuff right. Once you can get that stuff right, then we can start talking about how can we re architect this application so we can get better value out of the platforms that we're delivering to and we can move into the cloud and start getting those benefits of cloud. But if your team isn't able to do the fundamentals right first, you're never going to succeed at those more complex things that you alluded to. [00:13:48] Scotti: Scott, I think what you're talking about, and I know Karl will absolutely love it when we say you need process and the process is actually your solution to this problem. You need to get the process and the fundamentals right. And no different than security being a mindset. Getting the process and how you build, deploy, manage, maintain and lifecycle all those applications and all those versions is actually quite important because if you throw more technology at it, all you're actually going to end up doing is introducing more problems, more issues. You can be increasing your security footprint potentially and it wouldn't be. I've got to say I've seen several times Kubernetes, clusters and control plane APIs being exposed to the Internet, which you and I probably know that, that you shouldn't do that. But if you don't know the process to follow, then putting your Kubernetes control plane API endpoints on the Internet probably seems like a good thing to do because it's easy. [00:14:42] Tom: Bang on, Scott. And I think one of the important things as well is having that, and we've talked about it in our previous episodes and that is the connection to the customer experience or the business context. So quite often those in technical teams sort of lose sight of the impact of what they do to the customer or to the business. And I know I've worked in environments where it's literally a case of well, it doesn't matter if we reboot that service, not actually load balanced or it's not something that's resilient to a node going down and there's a blip there. But yeah, when you start baking in that care about that sort of stuff and I have seen that happen to the point where you start succeeding in building some of these always on services, that becomes a thing of pride too. So when you start instilling again, it's back to your first part about instilling a culture within an organization. If you instill a culture of pride in the availability of your application as well, that should pervade teams as well to making sure that you establish the process that ensures that maximum availability and uptime as well. [00:15:38] Scotti: So talk to me about process because I know this one. We had a bit of a joke before the show about this one as well. So we've worked in a number of organizations where I think change management is probably a dirty word or maybe they have it but don't do it very well. I know that we worked with some famous change managers that used to like to decline all of our changes. It's like your systems are down. We need to make these changes so the systems come back up and they would decline it because we had some risk or there was going to be a problem. So. Which is quite amusing, right, considering your systems don't work now, we can't really make them any worse, but there's risk. So you're not going to let us make a change. Seems a bit counterintuitive to me and still does. I still look back on those times quite fondly. But look, talk to me a little bit about change management. What's the issue? [00:16:25] Tom: Yeah, change management's another one of my big, tough, hard truths and that is around the role of change management within an organization. I've come to really value it. Yeah, I was a bit hot headed in my younger years and I just saw it there as a blocker. But you know, where I worked early on in my career, the likes of Coles, where change management was done really well, I think opened my eyes to the value of change management within an organization. My problem comes where change office overextends either its own importance or misconstrues the concept of what change management is there for. And it's not to your point, Scotty, of eliminating any risk. The intent of change management is to capture and document changes going on within the organisation so that you have a considered approach to risk mitigation. And that's done through an appropriate review process. And then when, if and when, because invariably it does go wrong. Throughout change, when something does go wrong, you've got documented, well documented steps on who to communicate with. You know, the CIS that have been involved in the change. So when you do have an incident, you can relate it to that change and then you can enact the steps necessary to roll back. The problem, I find is when change really overextends that and they become blockers or you have to start convincing the change management team of why you need to implement a change in the first place. That's not the role of change management within the organization. And I think when change starts becoming a blocker, it's a bit like security in a sense where you've got a bad security culture. It's where people see security as a blocker so they start circumventing security. The same thing happens with change if change slows process down. Worked in organizations where a major change takes just as long as a minor change because there isn't any pragmatism baked into the whole process and it just becomes process for process sake. So like security, when you're doing it right, people work with you, when you're doing it wrong, people work around you. And that actually increases the risk because people start I can slip this one in without raising a change and the like. So I think it's incumbent that the hard truth is as a change management office, you need to be working with your implementing teams and helping to enable them rather than becoming a thorn in the side. You've probably worked with a whole gamut of different change maturities. What do you see works well and what are maybe some of the things that you'd avoid? [00:18:46] Scotti: Certainly with security related changes it's I see a lot recently where the organizations that aren't as mature, that don't have the visibility into their organization, they don't actually understand what their tech stack ecosystem looks like. And I know you think that's a no brainer, but quite often if you actually go and ask organization, do you actually know what's running your environment? They probably can't tell you or they can only tell you like half of it. So I see organizations that are a bit like that certainly when it comes to security changes or even it doesn't even have to be a security change, but quite often it's like, hey, we made a change to this and something doesn't work and so it must be security. Gotta be security. Turn off the EDR to turn off the waf. Turn off. It doesn't really matter what it is. It's like in fact, turn off the vulnerability scanning is what I've heard and it always makes me laugh. It's like, well what actually changed And a lot of times they can't say. I guess where I'm going with this is you really don't want to be thinking about rolling back security when security had nothing to do with it. And to your point, if non production doesn't look like production and you've perhaps don't have the same licenses and the same tooling across both, it's actually almost impossible to be able to conclusively point one way or another. And and standard troubleshooting points to you really need to only change one thing and then observe the outcome, not change 10 things. If anyone's used a 3D printer before, you know you change like lots of settings in your slicer program and then it doesn't work and then you change 10 more settings and it doesn't work and you actually get no closer to the outcome. What you really need to be looking at is how over a long it might take you longer initially but you can actually pinpoint the exact setting or the exact thing that you need to change. And similarly with change management in this example, what was the one thing that broke it. And more often than not it's not the security tooling, although it potentially could be the cause. So we there was one example where vulnerability scanning was actually causing network problems but it was actually the firewall and the firewall logs that were being emitted that was then triggering denial of service conditions because it was essentially flooding the network. So more often than not it ends up being security tooling that takes the blame when it's quite often not. But unless you actually like you really understand your environment and everybody's embracing change, it can be become one of these it's always security's fault and that's not an ideal culture and it's not a great place to be. But the reality is you're just wasting, you're burning time investigating something that actually wasn't the cause. [00:21:13] Tom: And I think there's a lot of those knee jerk reactions to things. And to your earlier point I think rollback should be one of the options. But I think I see organisations the prosper are ones that look to continue to roll forward that have teams that are capable of having those Plan Bs and working out culture of organisations that have this forward moving mentality. I think the other key thing there is not having a culture of punishment or fear of change going wrong as well because change does go wrong. The idea of a post change incident review is to identify could we have done anything better. And quite often if your change management is being done right There actually shouldn't be anything that necessarily could be done better. There might be some technical things that you can change in the implementation, but if you've gone through the process correctly, then it should be okay to close off a change incident review with everything was okay. What happens if you do have that culture of fear and a punitive culture? The people start hiding the truths. And the same goes with any kind of incident post incident review. If you're coming down on people like a ton of bricks, then people will start hiding truths to cover their tracks. And that's the worst possible outcome because you then miss the things that actually help your organisation grow and help your people grow as well. I guess in the same vein that we expect change to go wrong and if we have the right culture, we should not necessarily embrace that, but look to learn from that. And know a matter close to your heart is the acceptance that we can't build this impenetrable perimeter around an organisation. And we've got to accept the fact that there will be a time when bad actors do get into our environment. And the way we handle that is what differs mature organisations from immature organisations that become front page news. So what's your big hairy truth there? [00:23:00] Scotti: Yeah. The simple truth is at some point you're going to suffer an incident. The reality is how bad that incident is and how quickly you can recover is have you done all of the basic things right? And this is something that as organizations and as leaders, as security people, we often don't want to admit. You know, at some point all an attacker has to do is find one hole. And as a defender you've got to find all the holes and you have to fix them. And we know, we've talked in previous shows about actually how and why that is so difficult. But if organizations are going to succeed and we're not talking about succeeding in profits, I'm simply talking continuing to operate and continuing to exist, not having an extinction level event, then you really need to be thinking beyond just defense. I know it's a terrible analogy that, you know, what do they say? A good defense is a strong offense? I would almost say I'm not talking about going after the attackers. Right. What I see is organizations that are able to be more resilient and I'm talking about being able to detect, contain, eradicate and recover in reasonable timeframes are the ones that have got the basics right. So what I'm talking about is the idea of moving from solely looking at, in, in most cases, and we've talked about this in previous shows as well, about protecting the perimeter. So putting. If you think of a picture analogy, you've got your castle and you've got a moat and you've got some people in some watchtowers, you've got some archers with bow and arrows, right? All of those controls are looking outwards. And that's typically what we see in IT environments as well. They don't think about looking inwards. So what happens when someone gets in? So in a lot of organizations, they're looking at classification technologies, they're looking at things that can identify knowns, but as an attacker, like, ask any penetration tester. And I actually listen. I love the Risky Business podcast. Adam Boileau was talking about getting onto telco lawful interception systems and about how we went about that. And it took him, I think, two and a half months. Right, That's. It's quite interesting. Anybody that's. That likes pen testing or offensive security should definitely go have a listen to that most recent podcast. But the whole concept behind this is that it's just a matter of time, right? So it's a matter of time, effort, reward, and persistence. Or in some cases, I think. And it's happened to me as well, I've gone into a customer and said, we are so secure. We do all of this stuff, and they're there for you to test them and tell them how secure they are and how they aren't and how they can improve. But instead of kind of saying, hey, here's what we think the problems are, they spend the whole hour telling you how great they are, and all you know is that it's just bravado and they're actually really nervous. The ones that have said to me, we, Garrett, you won't be able to get in. Who are you? Especially, you'd imagine When I was 23, I was a lot more persistent and I had something to prove, right? So I used to turn up in a suit, and at the end of it, I'd used to deliver them a really, really long report that said, here's all the ways which I compromised you with a big smile on my face and go, well, we'll see you next year. So in saying that, though, there were some organizations that we and I specifically tested that were doing things right. So they would. They'd worked on the concept of, we know you're going to get in. How can we slow you down? Right? And by slowing you down, we're not talking about making it impossible for you to move around the network, we're talking about slowing you down, constraining your ability to operate inside an environment. So instead of saying, hey, once you're through the front door, free for all, there's no security cameras, right? How can we slow you down so that you have to be more noisy, that you have to bring in specialist tooling? So you have to make outbound connections to somewhere to bring in malware or bring in additional tooling. All of these things basically gives them more chance to detect you and once they do detect you, to be able to contain and then eradicate you. So I'm a huge proponent of things like Canary tokens. So thinks Canary make these great little devices that look and smell like whatever you want. So if you're an Oracle shop, you can make it look like an Oracle database. If you're a Microsoft shop, you can make it look like a file server or a domain controller. It's a very simple concept, is you make it look like a really irresistible target. You make it accessible inside your network or in the cloud or wherever you want to put it in your physical data center. They actually make physical devices as well. And to an attacker, it's indistinguishable from other true assets and real assets in your environment. So let's imagine if you're an attacker and you get into an environment and you're hitting a database or a file share, you're seeing customer data, you're seeing salary reviews, you're seeing sensitive information. The first thing you're going to do is try and download all of that. So all these little devices do is they chirp, they create an alert, they trigger a response, and it's a high fidelity response. So you have to imagine going from a. Let's just pick any EDR tool that's only specifically designed to detect specific things based on how you've configured it to almost 100% accuracy. Trigger event from a canary. That's like the best thing that you can do today inside your environment. [00:27:58] Tom: I know a topic that is highly controversial when talking to you, Scotty, but zero trust, is it smoke and mirrors, a facade? Is zero trust literally just a case of kicking the can down the road and moving the problem to the interior where you'd still have these things like canaries and the like being far more effective. Do you think the buzz around zero trust is just a marketing buzz? You know, we're talking about making this exterior impenetrable and we acknowledge that's impossible to do. So the solution to that is zero trust anywhere within your environment. Why is that? Impenetrability of the interior any different from the exterior. Zero trust is only as close as you eventually have to trust something and there you've got a hole again. So you still need all these things that catch the behaviors of rogue actors that get within and beyond your Zero Trust security zone. Are there elements to it that make sense? Where do you sit on Zero trust? [00:28:55] Scotti: At least Zero Trust, unlike some other security concepts and things that are quite popular in industry today, wasn't coined by Gartner. I think zero trust is an ideology. It's the way that you would design your environment. The whole concept here is that you need to be authenticated and authorized before you get access to things. What really irks me is a lot of Zero trust vendors are actually saying all zero trust is preventing inbound access. So the way that networks work, you have to have connectivity into an environment, right? So I remember seeing this and it really annoys me when I see it on LinkedIn with like, oh, you just need to move your front door so you don't have any inbound ports, but your inbound ports are in our cloud. So you create outbound connections from your environment to their environment, which obviously has to have open ports inbound to make this work. And then you connect to their cloud and somehow that makes you more secure. I think it's not a robust strategy. And if we're looking at thinking about attackers, right, If I know which Zero Trust provider is certainly the ones that use this kind of like cloud broker middleware model, I'm just going to go after these Zero Trust cloud providers. I don't see Zero Trust really solving the problem. What I do think does make a lot of sense is the idea that you should be authenticated and authorized and you shouldn't just implicitly trust someone when you're inside the network, which is to. The whole thing that we're talking about here is that you still need the controls inside your network so that when someone does invariably get in, or it could even be an insider threat, that you have the mechanisms to detect and detect them in a reasonable timeframes. Because you saying in a tabletop exercise, hey, yeah, we're able to detect them and then we're able to eradicate them. It's all fanciful. And all it really ends up is you feeling more prepared and you end up with this false sense of preparedness in your environment. And with everybody involved, they think, oh yeah, we're in a situation, we can actually, if someone was to get in, we'd be able to respond. The reality is your defenders even if they were able to detect them, don't have the requisite skills that perhaps don't have the authorization to even take down the system to stop the attackers spreading, because you need to continue to trade. So what do you do? [00:31:06] Tom: You. [00:31:06] Scotti: You let the attackers just move about your network. And I don't know if you've ever been involved in like purple team exercises where defenders are aware that offensive testing is going on and then they actually try to detect them and then you end up with this cat and mouse type game. I can't say that I've ever really seen those go too well for the defenders. [00:31:26] Tom: I thought purple team exercises were when Barney and Grimace turn up for a kid's birthday party. But no, I totally get it. And I think you nailed it when you said it's that false sense of security. Because that's what I see the danger of zero trust being these people that think I've established a zero trust or I've purchased a zero trust product now, so I'm completely dark and no one can get in. And the reality is you still need to be prepared. There is still some trust somewhere in the chain that can be exploited. And it's probably even more dangerous when you've got that illusion that you've got impenetrability where you find yourself exposed. But it's interesting, you just touched on something towards the end there, Scotty, and we mentioned it earlier too, and that is around the experience and expertise within an organisation. I know it's really hard to find good security people. And when security people tend to get trained up and get to a level of experience within an organisation which includes the IP of the organization as well, they tend to get poached or even go elsewhere. How do you deal with that challenge of security? And you know, what's the hard truth to organizations around security experience? Not just within security teams, I guess, but broader within the organisations. [00:32:36] Scotti: This is an interesting one because we always think that the problem is a lack of. You hear it so often. I'm so sick of hearing it. That there's a cyber skills shortage. Yes, there is and there probably always will be. Yeah, I'm really sick of hearing that it's just a cyber skills shortage. My take on this is perhaps quite controversial and that I don't think it's just a lack of cyber skills. We keep hearing about the cyber skill shortage. I actually think that there's a lack of literacy at the executive level. So I'm talking about board members, I'm talking about senior executives in organizations. They Actually, just they don't understand cyber, they should understand risk. They don't typically want to understand cyber. It's a bit like when you try and explain to your family members at a barbecue why they need to use multi factor authentication. Well, they all know why they need to do it after their data's been breached or they've had some fraudulent transactions on their credit card, or they've had money stolen out of their bank account. But until that happens, they're not really interested. And I think this is one of these things where if they don't really care about acquiring those skills, their net is going to flow all the way down the organization. You're not going to have requisite budgets, you're not going to have the support that you need for cyber initiatives. In my time dealing with executives and boards and I've done a lot of training for senior executives, the board members, I've had to present board packs. One of the things that really jumps out at me is that the devil's always in the detail, but the information is so diluted when it gets to executive board reports. And I worked with a guy really famously that said executive reports could just have pictures of ducks inside them and nobody would care. Right. It was the fact that there is a report, not the actual data that's within them. And what he says is really true because in many cases, if we're talking about risk, it's like, hey, let's use typical risk terminology. We've decreased the likelihood of this occurring by 50%. Well, does that really matter? We said before that attackers only have to find one way in. So you could decrease Your risk by 99.99999%. Never get to 100. Not that you ever could because we don't deal in absolutes and cybersecurity. It's one of these things, right? Like there's not enough understanding and they, if they aren't willing to really kind of dive into those cyber topics, I think the reports and the way that we're reporting metrics to boards and executives is a bit pointless. So I really think that the quality of the data and what we're reporting to the board needs to change. Because at the moment these metrics around percentage and likelihood, just whilst that's why they might understand it is and actually helping them make better informed decisions. [00:35:07] Tom: Yeah. And look, I know you're sick of hearing about the cyber skills shortage, but there is some reality to the fact. And you know, talking about quality of reporting then quality of cyber resources as well. There's a stark contrast, and I see it from, you know, from outside in the infrastructure space between really good cyber people who can communicate to that board level. And we've spoken about this in previous conversations as well, and I think that's key to combating this problem that you're alluding to here, Scotty. But there's a real difference between quality cyber resources and those that are cheap. I mean, it's the case everywhere where there's that false economy around cheap labour. But I think more so than anywhere, cyber is an area where the poles are massive. [00:35:53] Scotti: They are. And I see it getting worse, not better. At the moment when I started, like, I feel really old saying this, I'm only 37, turning 38 next year, as I have to keep telling my partner who keeps telling me, I'm old and nearly 40. When I was younger, there was no training. There would be perhaps some cyber papers at university. Nowadays you can walk out of school and go straight to university and do a Master's in cyber security. What I think that's led to is we have a whole bunch of people that are coming out that are really interested in cyber, that have some really good foundational skills. They're lacking the experience. We are also seeing a lot of people immigrating into this country with cyber backgrounds and cyber experience. What I can tell you from interviewing a whole number of these recently, I interviewed for an engineering role and a cybersecurity manager role for one of the customers that we work with. I think I might have reviewed 300 CVs for the manager role and an equal number for the engineering role. There are a lot of people that want to apply that. What is missing is the actual applicable experience. And it's a bit catch 22 because a lot of enterprises use expensive software that comes behind a paywall. In a lot of cases that people that are wanting to get into it just have no experience. But once again, it's a bit of a false economy because two parts it might seem great, like people might look great on paper and you don't really have a lot of time to evaluate their skills and experience. Let's take two examples here. You've got one CV that has everything that you want on it and another CV that's a bit more perhaps truthful, and you end up picking the one that's perhaps cheaper, that's overestimated, shall we say, or misrepresented their skills and experience on their resume. And then you find out, well, actually they don't know how to do the job and to your point, they don't have the experience and skills to communicate with others in the team or the others in the business or executives. And in fact, you end up with a worse outcome. And I think there's two parts to solve this problem. The first part is you really need to look at building and retaining your own talent. So that could be within your organization, that could be within your cyber team. You pointed out people get poached all the time. And it's true. Cyber is one of these industries that is so in demand that if you're not constantly thinking a bit like thinking that attackers will get into your environment, if you think that cyber, that the members in your cyber team are never going to leave and probably aren't getting five to 10 LinkedIn messages about new jobs every week, then you're kidding yourself. So you really need to be working on how can you retain them and retaining them. Honestly, it's not always about money. Sometimes it's about doing things better, more efficiently, sometimes it's playing with new tools. But everybody's different. Sometimes all you need to say is, that's a great job, well done, but you do need to address the burnout issue. And the last part of addressing that cyber skill shortage is internships. We keep talking about, hey, and I know this has probably been done to death. Anybody that follows people on LinkedIn will say, oh, everybody wants an internship and they need five years experience. Well, yeah, that's not going to happen. What I think is really important though is to identify those people that are interested, that have just graduated from university and they are looking to get some experience. Right. But bearing in mind when you choose to take those people on, either in an internship or in a full time position, that you still have to apply the same rules, that as soon as they get a little bit of experience, they're going to be looking to new opportunities. How do they further their skills and experience? How can they get paid more? So it's a difficult one, but I think to bring it back, it starts at the executives. And I'm talking to you, all those executives that are listening. You really need to up your cyber skills. And if you don't, there's lots of training courses out there. Harvard University has a great cyber skills course. [00:39:35] Tom: Maybe a bit of a leading question, can you outsource the problem? Scotty, if there is a shortage, can you bring others in to help out? Because I have a very hard home truth, and probably a surprising one around my position on outsourcing. [00:39:49] Scotti: I've got my thoughts on this But I'm keen to hear yours. [00:39:52] Tom: So actually, I think in the general IT sense, I actually don't have a problem with outsourcing. And for full disclosure, we as cordant, don't do any sort of managed services, but I think there's a lot to be gained by outsourcing when you do it right. I think the biggest problem is organizations don't prepare to outsource properly. So the old adage, if you fail to prepare, you must prepare to fail, outsourcing has sort of established itself as a bit of a reputation for degraded service levels, poor customer experience. And just for full context, I'm not talking about outsourcing, project delivery sort of stuff, I'm talking about the BAU operations, you know, standard ITIL stuff here. I think that the problem for most organisations is twofold. They're looking at the wrong things to outsource and when they do commit to outsourcing, they're not preparing the discrete packages that they have and want to get help with in the right way either. And I might dig into those a little bit, but maybe before I do, I'd be interested and I'm fine if it's completely different to my view, and it might be different in the cybersecurity realm. But what are your views from a cybersec perspective? [00:41:02] Scotti: I've got quite a bit of recent experience of seeing what happens when outsourcing goes wrong. Everything kind of goes in waves. It's no different than the way that offensive security and certainly organizations are being attacked. We originally started with networks and we moved to apps and we moved to users and we're kind of going almost a full circle in that area. And I see managed services being another one of those. What I see is a lot of organizations going, oh, we need it, we need an outcome, so we need to meet ISO, we need SOC2 compliance or something like that. And that then means, oh, well, we need a. We need an active SOC security operations center, which means you need a SIEM and potentially some automation or a SOAR platform or something like that. And so we go to market and we say we need a soc and then you get a whole bunch of SOC vendors and of which I've evaluated quite a few recently. And a bit like the CV thing, they'll say that they do all of this great stuff and they'll have all of this great marketing material, but you have to remember that it's in their best interest to get you on board and then paying monthly once you kind of onboard it. I personally see a Lot of disappointment, failed expectations. And to your point, a lot of it is around what did we think we were going to get versus what did we actually get? And then you end up in a really weird position of being able to try and recover a relationship that just atrophies over time. And I think largely you can't just outsource a problem. So, yes, you can outsource some of the problem, you certainly can't outsource the risk. But where I see this going well versus what you see time and time again is instead of having someone that has an understanding internally, they just outsource the entire end to end. So they go to a third party to say, hey, we need a SOC organization has no experience whatsoever about a soc at all. There's no people that. They've never run one. How do you validate that what the MSSP is telling you is actually correct or that they're actually delivering on what you think they're delivering? [00:43:01] Tom: Yeah, I think you nailed it with relationship, because I think I often see that, you know, managed services and outsourcing of bau, it's kind of like having a baby to save a relationship. It's where I've got this problem. And then the MSP comes in and sort of says, yeah, well, we've, you know, we've got all this experience and we can turn this around for you. We've got all these processes and we've got a framework that can address that. But the reality is you can't outsource a problem. It just actually becomes a bigger problem because you've got more parties, you've got more complexity, you've got less vested interest in the outcomes. And the chances are you haven't put together your contractuals properly to get the most out of that relationship. And what happens is you do get that outcome of degraded service in the end. [00:43:42] Scotti: It's funny you say contractuals. I remember reviewing a contract and I know I'm picking on a sock here. It's just the one that I have the most recent memories of. In the contract, it said. And there's subtle nuance here, right? Those of you that have worked in a SOC before, you'll understand what I'm talking about, but I'll explain as I go. So you set up your seeing solution. There's a whole bunch out there. Let's say it's Splunk. You send all your logs to Splunk to do some ingestion and some correlations. It's basically looking through logs to find events that could constitute a security incident and then that gets raised to an analyst to alert. In contracts I've seen things like, hey, instead of it being an SLA of we'll tell you about this particular thing within this particular time frame and it should be from when the event was ingested. It was actually when the event got raised. So the SLA was that they would tell you within a particular time frame from when the alert was detected, not from when the alert was ingested. So the subtle nuance here is that the actual correlation bit the search that was actually triggering the event that would end up end up in the ticketing system if that took three days. Well, it's kind of an old alert if it's critical event. So you end up in this situation where. Well, hang on a minute. Is that really how that should work? Probably not. Following on from that. So if you miss a few SLAs in this contract, it said if we miss a certain number of P1 or P2 events in the month, then that would trigger a credit on your account which you could then use later on. Interestingly though, there was also other clauses in there that said, hey, if we end up in this situation, there's an earn back period. So if we continue to not make like if we don't make any more mistakes in the next 90 days, we don't have to pay. So it's kind of like, hey, so if we do it wrong, there's really no penalty. And when there is a penalty, there's also a get out of jail free card. Like you really need to be looking inside your contract. Certainly when it's talking about outsourcing so that you don't end up in this situation. Because the reality is when you end up in that situation, it's like you now have to do the work because your MSSP isn't doing it. But also you now have to track your MSSP to pull them up on their SLAs to get the money back that you were owed that they should have been doing in the first place. Like you can see why this becomes. It's not just a 1x problem, it's a 2 to 3x problem. And then you still have to, as you said, manage the relationship. What do you do? Do you get out? It becomes really problematic for all parties involved. And the reality is it would've probably been better to just do it yourself in the first place. [00:46:07] Tom: And I think that's the. There are two things. One you need to incentivise like you do with your internal teams you need to incentivise improvement and you need to penalise that apathy and where you've got to, you know, where you've got to get out of jail thing. And sadly, MSPs are going to pull every single thread they can to try and get out of paying back money. So it's important that I guess at the get go you involve your operational teams in the process to review any contractuals and what you have to have in that case is an operational team that actually understands their own operations. So this comes back to making sure your own house is in order. That's the time to outsource. When you've got a good process, you've got things well documented, you've got clear internal SLAs around things. So when you have a clear understanding of what you do, then you can compartmentalise everything and take out those services, those tickets, those incidents, those monthly routine activities that you do and you can put a, you know, a dollar per click price on them and take them out and tie those to SLAs as well. But yeah, you don't want to get the wool pulled over your eyes with those sort of things. And probably that leads to the other key thing is knowing what it is you should and shouldn't outsource, you should maintain at least a portion of your internal teams. I think two, if nothing else, act as service delivery leads to keep everyone honest. But yeah, work with organisations in the past that were looking to outsource whole less bolus things like incident management. And that again, word of the day became a false economy because it's very easy when you've got, you know, first and second level incidents because they tend to be rather time bound, they tend to be rather discreet and they fall into a nice easy bucket. And you can say, yes, we've got X number of these tickets, Y number of those tickets, and then you can effectively take that out and get a quote on how much it would take and to estimate that if you take third level support as an example, tickets can be solved in 15 minutes. Tickets can take two to three weeks to solve and in the end you end up engaging your third level in a time and materials basis. And that can often become a false economy because you've got internals that have high level of IP and you're effectively outsourcing that to someone that doesn't know and doesn't understand your business. It's rare that there's value in outsourcing that kind of component. And likewise, another bizarre one for myself is where you completely outsource your architecture or project management side of the business. You know, you need to have that element that has a vested interest directly in the IP of the business. And that's not to say you can't augment those capabilities with externals. But there are some things that I strongly believe should stay within the business. And one like architecture is a great example and that may surprise people coming from the fact that we are by and large strategy and architects that deliver services to customers. [00:48:54] Scotti: You make an interesting point and I guess this is for the people that perhaps need a capability. Let's use a SOC example. If you don't have a cyber team, but you need a soc, do you trust the people that you're going to end up paying? Like I'm buying a car at the moment and they told me it'll be four weeks for it to be delivered. I'm selling my car today and so I'm going to be carless in four days, it will be one month. Right. So it's no different than when you go to a managed services provider. I know a terrible car analogy, but the same principle is true that if you need a service in some cases it makes sense to have someone to check the homework. You don't have the same, like you shouldn't be able to check your own homework. So if you are in that situation where you need to go out and you want to manage service for whatever reason because it makes sense for you, you don't want to build a capability internally. Sometimes it makes sense to engage a third party organization, for example, like not even saying us here, but somebody that doesn't do managed services that can act as that trusted advisor position to actually validate what they're saying to look at and kind of catch some of those things, those traps that you might fall into. And I think that's a great way to be able to kind of journey down the path. If you don't have the skills and experience to actually understand what it is and validate that, are you actually going to be getting value out of the service that you're procuring? [00:50:14] Tom: Yeah. Speaking of getting value out of the services you're procuring, another issue that is close to my heart is the move to cloud. I've got some serious home truths and I continue to share those almost on a daily basis with our customers. But my big truth here, if I can borrow another one in a row, Scotty, is the lift and shifting to cloud is just on prem in someone else's data center. [00:50:37] Scotti: I'm sure they made that a T shirt, didn't they? [00:50:39] Tom: A little cloudy's funny. And I know we have James as the cloud guy, but I'm almost every bit as much of a cloud guy as James. I'm a massive advocate for moving up the stack and doing cloud right. But yeah, I see cloud as cloud has become two different things in this industry. There's cloud, what I call cloud with a lowercase c which is a mentality, a paradigm, a methodology and that is leveraging the software defined nature of quote unquote the cloud to automate, to introduce repeatability to abstract and then to have a effectively consumer platform rather than do things at that very low level. But the weird thing is that cloud has also become synonymous with just the public cloud providers. So, you know, the aws, the Azure, the ocis. So much so that when moving to cloud someone ticks a box because they've lifted an on premises server and done the exact same things with the exact same tools, the exact same way they've been doing things for years into quote unquote the cloud. And I think this is beyond a false economy. This is not doing cloud right. Organizations that complain that cloud has been really expensive for them, it's probably a case of they haven't done cloud the right way or they haven't done it for the right reasons. You know a great example of that is if you have organizations looking to become more agile and to be able to reduce their time to delivery of the likes of compute. If we're taking things from a lift and shift bearish resource, there's no reason in all likelihood that they can't be doing that in a software defined manner on prem with what they have right now. There are so many organizations with VM where they can be calling APIs to deliver a VM quickly to a project delivery team. The problem is they've got their process wrong. It's up the putt. So why are you moving to cloud? Why do you want to move to cloud? Is it to gain benefit of scale and scale out and turn off resources when you're not using them? Burst out resources that makes a whole lot of sense. Or as I mentioned earlier, move up the stack where you're no longer having to look after the outsourcing model is a great example of outsource. Looking after your operating system and looking after the bare bones of the platform to an AWS or an Azure and just place your application on top because that's focusing on doing what you do best. So that makes Total sense. But when it irks me somewhat where when people say we're moving to the cloud and they literally just lift and shift their VMs, they keep using the same tooling that they were using in the past and then turn around and complain that it's so much more expensive than running things on premises. And unsurprisingly, they're not getting the agility that they thought. Or if they do get the agility, it's because they're doing things in a completely unmanaged fashion. The cloud hasn't enabled that. It's just the fact that someone's dropped their credit card and they're spinning up VMs like it's the wild west. [00:53:24] Scotti: And if we go back to the castle analogy, basically your castle is your on prem environment that you can go to the data center and you can physically see. When it's an intangible thing that you can never see, then what you end up is you don't have a moat. You have no one looking at anybody coming in. And then you wonder why attackers are now leveraging cloud is exactly this. They think a lot of organizations try and take their on prem tooling which isn't capable or then they have to. Security teams now have essentially doubled what they have to look at from a number of tools. We've gone from say 5 tools to 10 tools on prem to now we've got all of these cloud provider tools. And then if you've got a second or third cloud provider, you're actually multiplying that threefold. It becomes an unmanageable problem. So if you try and take these on prem tools to the cloud, you're going to realize that they don't work. So traditional vulnerability management, sure, yeah, you can deploy that as an agent on a machine. But cloud providers have their own tools as you start moving to PaaS based services in the cloud. So whether it be managed kubernetes, because we love kubernetes, or maybe it's relational databases, you now no longer have access to the underlying operating system or file system. One of the key ones actually that I was asked a lot at Oracle is how do I scan my S3 bucket? I need to install an antivirus on it. And it's like, well, actually you don't have access to the underlying operating system. This becomes a really foreign concept. So Tom, if I'm a customer and I'm going to the cloud, maybe I've got a couple of clouds and some on prem, what would you recommend as far as visibility goes? [00:54:53] Tom: One word Wiz. This may sound like a plug, but I've sort of worked with traditional on prem tools that extend into the cloud in the past. Are they born in the cloud sort of tools and they tend to be endemic to either a particular cloud provider or they only deliver a sort of subset of services. Yep, we do a fair bit relatively I guess in OCI as well. And OCI is a bit of a forgotten cousin in terms of the hyperscale cloud providers. If anything, that's the closest to something that does make sense when you are doing lift and shift and there are some organizations that look to get out of the data center and they have a goal to do that because they are shutting down or losing a lease on a data centre. That's an example where sort of lift and shift makes sense and I can appreciate that just move something to someone else's data centre. The challenge with OCI has been that there's a very limited set of tools that know and work with oci. And that's actually what brought us to Wiz in the first place was not only does it work with oci, it does so in an agentless fashion. And what I like about Wiz is that it actually shows you the communication not just within a particular cloud but between clouds as well. So chances are OCI is probably not someone's only cloud. They're probably talking over to AWS or to an Azure as well. And what I've liked about Wiz is that it actually shows you those the exposure and risk there and graphs that as well, which is another thing that I think is either lacking or if it isn't lacking, you lose that consistency as well. So it's nice to have that consistent view across your cloud sprawl, I guess. And I just think it's a really good tool and I think it's a bit of Australia's best kept secret at the moment. It's going gangbusters in the us. I'm just surprised more organizations haven't sort of at least tried it. It comes down to again it's a case of preparing, understanding what you're actually trying to do. So many things happen in a knee jerk manner and there's no planning and forethought that goes into this sort of stuff. Or what we have is organizations looking for a silver bullet to solve their problems. But it's not something that you click your fingers and you solve. You need to really embrace the cloud and you do that as part of a journey, a maturity journey. The organization has to grow as a Whole. And so many organizations, I think, just do things in a slap dash, knee jerk manner and are looking for that quick fix and quick solve. And I guess that's probably my last home truth is that there are no quick fix, easy solves to things. It's a journey and you've got to plan that journey out, right? [00:57:20] Scotti: It's funny you bring that up because my last one was that it isn't the hackers themselves. It's actually organizations that are their worst enemy. So, like, if you think about it, you've got complacency, there's a whole bunch of internal politics. You know, we've worked in organizations where executives don't want to admit there's a fault. They'll leave it to the last possible minute before a company threatens to sue them into oblivion, before they'll actually take action and then it costs them tens of millions of dollars. All of these things is essentially highlighting that organizations prefer to prioritize profit over security and the attackers are just merely exploiting those. I think the issue is that organizations really aren't willing to confront these internal problems. Perhaps it's because of the education point I raised earlier, or maybe there's another reason. But I think as a whole, if you as an organization really aren't willing to address a problem when it's raised, then you really don't have a lot of hope moving forward. Like I've seen so many times where near misses and security incidents and all the warning signs that are reported are ignored. [00:58:23] Tom: And we have had conversations where people will just say, yeah, I'll pay the fine. [00:58:27] Scotti: Yeah. And we see that changing in the US there's been a lot more like the SEC and things have started. You see some of the things that happened around Uber, right. Like trying to cover up incidents, it's not turning out so well for them. But I think certainly in Australia we're a little bit behind. You know, there's a whole bunch of other reasons as well that I, I think we're all still kind of got that shiny object syndrome. Nobody really wants to do the basics properly, like patching. I'm pretty sure that's on the ASD Essential 8 list. But you know, if you ask people, do you patch your things? They'll say maybe not really sure. How do we do that? We can't. You essentially get every excuse under the sun other than yes, we'll make it a priority because it is a foundational security element that we need to get right as part of the process before we can start doing the More important things for our customers all ties together as well. [00:59:19] Tom: It's back to that. You know, how many times have I heard the, well, we can't patch that because we can't afford the downtime. Why don't we have acceptable downtime windows for patching some of these things? Edit. Everything I think we've discussed today sort of ties back together to consistent themes. [00:59:32] Scotti: Yeah, I think certainly you raised that we can't afford the downtime. I'm of the opinion that it's better to be in control of how it goes, including potentially having a problem and rolling back and investing in something that makes sense for your business. Yeah, setting up something to be able to patch it seems like a pretty boring task, pretty thankless task. But it's better that you invest in that and that you can keep it and own it and you can build upon it rather than just, you know, if you don't, someone will eventually test and identify that you aren't patching things. I think if we look at the reverse of what we've talked about today, I think we've had a pretty big rant on the things that we don't like. I think where organizations succeed, where they get it right, they have the right culture, they have the right people, they retain the right people and that they're actively testing all the time, they're actually pushing the boundary of where are we today? So that continual improvement bit that you talked about earlier, security is one of these things that you don't do once. It's something that everybody chooses to do every day in the way that they work. When they are doing anything from writing an email to writing code to deploying something in the cloud, they're actively thinking about it. And that is a huge cultural shift for a lot of organizations. [01:00:40] Tom: Yeah, spot on. Look, I've really enjoyed the chat today, Scotty, you alluded to it. It's always fun to get a few rants off your chest, but I think these are important topics to discuss and they're topics that we often discuss with our customers. I had a acting on behalf of a customer, actually had a third party security assessment performed by another organization and they actually came back to me and said, look, what do you want the test to say? Do you want things to come out rosy or do you need to invest in a few security things? And I can write a bad report. And ultimately I was, I just want the truth, you know, are we in a good solid position? And it alarmed me. That was even a question. [01:01:17] Scotti: It actually happens more than, you know, There have been quite a few times where I have seen organizations that will actually go out there and it's in their interest so you can control it as a customer somewhat. And so if you're ever on the receiving end of one of these reports, certainly a third party pen testing attestation, you need to ask the scope, you need to ask the hard questions. Because just having no findings doesn't mean that there are none. And often when you go with cheaper providers, certainly they'll be part they can and have been passing off vulnerability scans, which is largely automated as penetration tests. And they are very vastly different things. But what you're talking about happens all the time. [01:01:57] Tom: Yeah, it's disappointing, but you nailed it. Again, it's the hard questions. It's the truth. We can't stick our head in the sand. You know, bad actors, if I have to summarise sort of the consistent themes in our conversation today, bad actors don't show mercy on complacency or on smoke and mirrors. There's no silver bullet to problems. It takes time. It takes analysis of process. Technology alone isn't going to fix that. And in fact, as we sort of discussed early on today, sometimes more technology adds complexity and it makes things harder to deal with and manage and inhibits growth. And ultimately a lot of these things are neglected in the pursuit of profit. But ultimately profit is there for the people. And if we can't keep the people safe, what's the point? Thanks for joining me again, Scotty. I had an absolute blast of a time. Hopefully we'll have James back in our next podcast, but until then, to all our listeners, stay safe. [01:02:54] Scotti: If you could use a little help or advice with modernizing your IT environment, visit Cordant Au to start a conversation with us. This has been a KBI Media production.