Episode Transcript
[00:00:06] Tom: Welcome to the DevSecOps 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 from Cordant, 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:30] Tom: Welcome back to this week's episode of DevSecOps, the podcast where we delve candidly into the world of ICT and security strategy, design and operations. My name's Tom Walker and I'm once again joined by Cordance resident security ninja, Scott Fletcher. How's it going, Scotty?
[00:00:44] Scotti: Yeah, I'm pretty good for a Wednesday.
[00:00:46] Tom: That's good. I like. Not that anyone can see, but I'm really digging that hoodie you're wearing. Looks cool.
[00:00:51] Scotti: Oh, I do love the hoodie. Big fan of orange.
[00:00:54] Tom: Yep. So are we. Now. I'm really looking forward to this week's topic as it provides a little bit of the behind the scenes view of how we go about things at Cordant. So just to paint the picture, whether we're working with the customer on a part solution or a complete IT strategy rewrite, yeah, we go through a discovery process and we take those findings back to a bit of a think tank internally. And this is where we sort of get get our best minds, which we like to say are all of our minds. And we go through the requirements of the customer's particular situation, how and then we proceed to oftentimes very passionately share our collective experiences and preferences as we build out the solution for the customer.
[00:01:33] Scotti: And it's fair to say we're very passionate and don't always see eye to eye. But the culmination of the robust discussion is a who, what, why and how we go about solving the customer's problems. Now these discussions can go on for days or weeks, so we aren't going to cover everything here today. But what we did want to do is go through a rapid fire run through of our own individual preferences and go tos when it comes to the what part of the conversation.
And that is, yeah, pretty much the technology stack itself. Acknowledging that these are both point in time and without the customer context, though we'll do our best to add a bit of context to our responses.
[00:02:08] Tom: That's right. Let's think of this, I guess as a, you know, you presented and Scotty, you and I have been through this, this very situation ourselves. We've pretty much presented a greenfields opportunity and There were different technologies and different how. What. Who's back then, and that's evolved to this point in time. But let's think of it in that context that you've got a blank slate, basically, and can do everything over again. What would you choose to implement for this particular service in this particular scenario? So, as always, I'll be representing the infrastructure side of the discussion with Scott, the security side, and I think we'll wrap things up by reflecting on our responses and covering off what some of the key common themes we've uncovered and what those weighting factors are when deciding on the technology. So, Scotty, how about we get started? Did you maybe want to read through some of the infrastructure capabilities and I'll respond with my thoughts on each one and we can again enter into a little mini robust discussion if we've got any disagreements on some of these things, as I suspect we may have on one or two of these things.
[00:03:01] Scotti: Actually, it's probably a really good. Interesting place to start, is that you and I first met each other in one of these environments. We were presented with a. A really unique opportunity and one that I fondly look back on, which is probably why we still work together. Several companies later, I think it was a great chance for us to.
Certainly for me, I was 25, I think, at the time, if my memory serves me correctly. So as you say, the time when we had the opportunity to do this, it was different times, different technologies. Pretty sure we were evaluating Cylance at one of these points in time. And now I'm pretty sure that's owned by BlackBerry and doesn't really exist anymore.
[00:03:40] Tom: Who would have thought that BlackBerry exists, but not Silence?
[00:03:43] Scotti: That's. It's very true. Well, we've got, we've now got CrowdStrike as, as the market leader, but Silence was touted, I think, the first product to have AI, or what they colloquially called AI back then. Let's just start right at the scratch. So I know that we internally deal with a lot of customers that come to us and say, what are we going to do now that VMware is owned by Broadcom? So maybe let's start with the hypervisor. I'm really keen to get your thoughts on, like, is there anyone else? Where should. Where should we go?
[00:04:12] Tom: Yeah, it's a really interesting topic because pretty much every customer's asked this. I guess one speaks to the ubiquity of VMware. I'm not sure if it's like this. I suspect it is elsewhere in the world, but particularly in Australia. VMware basically owns on prem virtualization and the hypervisor. As we've gone through this, we've gone through the process now with organizations that are saying, hey, we need to pivot quickly because we're just about to renew. And you look at what they're doing, their operations, the technologies that they're using within VMware, whether it's NSX or Spanned storage and VSAN across their data centers, unfortunately there's nothing. There's no quick and easy answer to this because there aren't really many competitors that do the breadth of what VMware does. As much as it pains me to say this, and I'll go on record as saying I hate what Broadcom have done to customers and what they've done to the great legacy of VMware because it's been a brilliant technology for so long, I can't see any reasonable alternative to that. And if I was going from scratch again, as much as, you know, it's lining Broadcom's pockets, I'd be going with a VCF solution at the moment for on prem hypervisor. As much as I'd say if you are trying to do VMs, really start looking at maybe doing cloud native VMs if you absolutely have to. Again, aim up the stack as much as possible. But if you're on prem and doing virtualization, I think VMware is still king.
[00:05:34] Scotti: So what about the licensing bit? You touched on that. It's quite an interesting one because I actually, I'm quite glad that I don't have to deal with licensing certainly around infrastructure. What would be if you had to give someone some advice? The licensing, certainly. I know that's one of the things that most customers have issues with Broadcom, I'm assuming they put the price up. Actually, I'm pretty sure they put the price up. Like how would you. Is there anything that customers could look at doing in the short term to make that a bit more bearable?
[00:05:58] Tom: Maybe look at consolidation. So bringing your core count down and do you need all the hardware that you currently have? You know, a lot of organizations are many generations old now and there's opportunity there to consolidate some of their workloads. Look at moving those workloads to cloud native and accelerating that. But really they've actually Broadcom have greatly simplified the licensing model and that's where it's gone up for a lot of customers as well. It's not in that they've increased the price two or threefold on a particular sku. It's that they're now pushing people who may have once upon a time had very specific licenses or enterprise license agreements to their, to their all encompassing VCF platform. And because we are talking about a greenfield sort of scenario here, not taking into account anything else, if you accept that and adopt that, you're actually buying into many different technologies and capabilities there, it's not that bad a value when you look at that vcf, if you're going from a per core license for just core virtualization effectively to vcf, yes, it's very expensive.
But if again we contextualize our situations to greenfields, it's still a very compelling package, if you like.
[00:07:04] Scotti: And I guess there's another interesting point to that too. So you and I both worked for a hyperscaler or a self proclaimed hyperscaler that we won't name at the moment. And a lot of those like the aws, gcp, Azure, Oracle will all go to you and say if you're a VMware customer, oh, you can run that, you can run your VMware stack in the cloud. What would you say to those customers?
[00:07:23] Tom: Start looking at peeling off that asap. So maybe only look at that as a tactical solution, but as soon as you can start looking at moving those again, if you're looking at running VMs and you're doing that, leverage the cloud's VM layer and hypervisor layer to run those natively on the cloud platform as well. So as much as I was paid to encourage people to move towards that, even then I would be honest with customers and say look at this as a tactical solution.
[00:07:50] Scotti: That's a fair answer.
[00:07:51] Tom: Another one that's not so much contentious is a fairly large cost item on a lot of organizations technology purchase sheet and that is their logging and their log repo. Splunk has sort of evolved as a bit of an industry leader in that space, but I know a lot of customers are talking to us and specifically talking to you and saying what can we do here to reduce our splunk cost? Are there alternatives?
[00:08:15] Scotti: Yeah, fascinating question. Tomorrow I think when it comes to SIEM solutions or logging solutions, there's a lot of conflation between logging solutions, SIEM solutions, SOAR solutions. So for those that aren't familiar with the concept of soar, it stands for security, orchestration and automated response. I think there are the traditional player. You're exactly right. Splunk still for me holds kind of number one spot if I was looking to go to market.
There are a whole range of considerations before kind of Making a decision though I know for example one of the tools that we potentially going to talk about as well as CrowdStrike and so CrowdStrike have a SIEM solution as well. So there's, there's a whole range of different vendors that kind of solve different pieces of the puzzle. Wiz is another one that does it for cloud but not for on prem currently. I think for organizations a SIEM or log solution really needs to look at the what type of organization are you? All of these tools require significant expertise and not just one person unless you expect them to work 24 hours, seven days a week, 365 days a year. So in many cases you want to actually be looking at a hybrid operating model where you've got some of the responsibility outsourced to a third party. Potentially that's level one, maybe level two, unlikely you're going to outsource level three, triage and response to a third party. Although in some cases that might be suitable depending on the type of organization that you are. So you really need to start with that piece. For me, if you are the type of customer and we've worked with a customer recently where they had a hybrid operating model with Splunk Cloud and Splunk Enterprise and they've essentially moved that all in house so they now manage it. So they have teams that operate manage Splunk Cloud, all of the integrations, all of the log sources, all of the detection engineering, all of the operations, all of the response, all of the automation. That's not a small feat. I can't, I really want everyone listening to really think about that before they go down that path because otherwise all you're essentially doing is buying a very expensive logging solution that isn't really delivering you value. But if you were to say to me, hey look, which one would I go with? I think there's the, the bit of me that says hey, don't go with Sentinel. But if you are an all a complete Microsoft shop and you've done the analysis that says we don't need support for anything, that's kind of exotic. So outside of the Microsoft ecosystem, Sentinel is a great decision for you. I'm kind of excluding cost from all these things because costs change depending on what time of the year it is that you're buying it in many cases or the types of services you're buying. If you're all in with CrowdStrike for example CrowdStrike SIEM probably makes a really good, makes a really good choice and certainly when it comes to incident response as well, because everybody focuses on getting the logs into a seam. But then when you have an event or you have an incident and you need to do something with it, it makes sense that all the pieces are kind of converged together. So if you for example, have CrowdStrike's incident response service, then having CrowdStrike EDR and CrowdStrike SIEM is a great idea. But I think bringing it right back, like if you need something that isn't specifically aligned with a vendor, if you're not specifically in the cloud, so you've hybrid on prem and you're also in the cloud, then Splunk for me would still be. Still be the number one. But noting you need very specialized skills to manage and operate that or you need to factor that into the cost of acquisition.
[00:11:40] Tom: Yeah, awesome. I was going to say something but you sort of wrapped it all up in your response. So I don't really have.
[00:11:45] Scotti: It's one of the things that we get asked a lot, right? I know there's another customer that's come to us and said hey, what is it we need to go to market for? In so many cases, logging is one of those things that I guess it's true for all of the technologies people and myself included. I've done my best to not specifically focus on the certain reasons being in Cordon that it's not just about the technology, it's actually how you plan on using it and also where you are in your maturity journey. Because do you really need that gold plated all in everything that's costing you $1 million a year when you're actually getting zero value out of it because you've got nobody that knows how to use it?
[00:12:20] Tom: I think that's a very important bit of context to add as well there because I was going to, I was actually going to ask, you know, is there, is there something for some of the. Just the requirement is we just need to capture our log somewhere and have somewhere that we can go to. Is there a cheap, dirty, nasty logging solution that someone could leverage?
[00:12:36] Scotti: I wouldn't say dirty or nasty. I think, look, there are lot. There are lots of really good logging solutions. I think a lot of people might look at an open source solution that they self host and maybe that's good enough. Maybe that's exactly what you need for this point in time. I think there are some really good logging solutions out there. There's also some really good options if you do want to go with a splunk. Things like complimentary services like cripple are also really useful. I know Splunk has Edge processor as well. So if you have a large volume of log sources, if you're dealing with the hundreds of gigabytes a day, which probably is most customers that we would deal with, having something that actually can filter out all of the noise or optimize those logs for storage, I think is, is something that you would probably want to look to as well. And there are other really good things that you could do with likes of Kribble, which is actually store those logs in low cost storage, for example, like Amazon Glacier. And then you want to replay those logs. If you need to replay an incident that occurred and you actually want all the logs to go through to actually trigger detections like. So there's some really neat ways that you think about doing so. You can actually be really crafty. You don't have to go to one vendor and say, hey, we need to cover all of our license.
Look, if it was me, I would probably go with the Elk Stack, Elastic Logstash and Kibana. If I wanted something that was perhaps as gold standard as Splunk. Knowing once again that you need specific skills and resources to set up, manage and maintain that. Otherwise you're going to find that all. Once again, all you're doing is having very expensive log storage for no, no real benefit or value.
[00:14:10] Tom: All right, what's next up for me?
[00:14:12] Scotti: What's next up for you? Well, I really want to talk about, I'm interested that you put on this one. In yours, you put down code repos. So where do developers store their code? I'm going to particularly pick on this one because this is one that I know quite well. But I'm keen to get your thoughts on this.
[00:14:28] Tom: Yeah, you're right. It's usually a developer led decision.
When we're sort of putting together holistic views on what we're providing, it's quite often the responsibility of the infrastructure team to manage that repo on prem. So it's often a conversation that customers have with us. Now why it's relevant here is that we have customers particularly working in the utility space where they have data sovereignty requirements. So it's not as simple as just using a cloud based repo. And obviously bumped into the situation where GitHub was purchased by Microsoft. They obviously have their repo stored in different geographic regions. There is a bit of a challenge with GitHub and that is that the agent that actually schedules jobs to run as part of a CICD pipeline, for instance, there's no sort of on prem solution for that. So where we do have OT environments and one of the things we like to promote is consistency of solutioning and tooling across say OT and IT environments. So I haven't mentioned it thus far, but part of the contextualized thought process for us and for me when I go through this is do we need to have an on Prem and cloud based solution and something that we can unify in terms of operations there. So with GitHub itself that would be the first thing that probably springs to mind, but that's not going to work in the OT example because it actually needs cloud connectivity, so it actually reaches out to a cloud based solution to schedule those jobs. Whereas something like gitlabs can be entirely run on prem, it's something that covers off everything. If the development team were open to it, probably my gut feel would be something like a gitlabs there and that's going to cover off all your automation, your code repo, et cetera, whilst giving you the flexibility to either run that as a SaaS product on Prem with cloud assistance, or fully air gapped and run on Prem in isolation.
[00:16:14] Scotti: You missed out the homegrown Australian solution.
[00:16:17] Tom: Atlassian.
[00:16:18] Scotti: You missed out Atlassian. BitBucket. Where's BitBucket in all of this?
[00:16:22] Tom: I've kind of gone anti Atlassian after being scarred by my JIRA experience in the past.
[00:16:28] Scotti: You and everybody else. You and everybody else. But once again an on Prem and also a cloud SaaS solution.
Personally, I've got some interesting thoughts on this. I think my take on this is Microsoft buying GitHub. I think it's a wonderful thing. I think noting that Git was originally created by Linus 12volt. So I think it's wonderful that Microsoft brought something that was created by someone who founded Linux. But it's also a really good indicator. You go to GitHub today, it doesn't really feel like Microsoft, they haven't butchered GitHub like they have so many other things. So for me, I'm all for GitHub. It introduces a whole range of issues when you've got things stored in the cloud. But and I had to Google this because I was going to say Schneider's law and it's not, it's Kirchhoff's principle. The principle that the security should be reliant should be dependent on the key, not the secrecy of the algorithm. So in that case my view is your source code. Well, it might be proprietary, there might be some intellectual property there, but from a security standpoint, as long as it's securely stored in GitHub and you've got the right controls around it, it shouldn't really matter too much. Obviously the intellectual property and I'm sure most lawyers or business people probably disagree with me on that fact. I run GitLab at home and I think it's great. I use it for a whole range of projects. I've got pipelines, it works very similar to GitHub. I do see there being other alternatives to this as well though. So you're not specifically limited to GitHub or GitLab or BitBucket. If you're all in with Atlassian, you've got all your cloud service provider options as well. So you've got Azure, DevOps and you've got all the equivalent in AWS, GCP and OCI. I think Oracle call it Visual Builder Studio which is vbs. Very confusing with Visual Basic scripting from Windows. Not sure what Oracle was thinking there, but look, I think at the end of the day, regardless of which product you choose, from my point of view, from a security standpoint, it's ensuring that you don't have in your code repos that shouldn't be there. So secrets keys. After that it's really down to developer preference and a bit like the SIEM solution. What does your team prefer to use and what skills do you have in your organization?
[00:18:38] Tom: Yeah, I think it's interesting the question around the Microsoft ownership has actually been more around organizations concerned that once Microsoft have that code and that repo, they actually train AI models on your your code. Now whether or not that's reality or not, there's concern that that may pivot at any time. So it's interesting that that that's come back as feedback from multiple customers. Now I don't know if it's part of GitLabs marketing to use that and a bit of fear mongering there. But the other thing I actually like about GitLabs is I find it a bit easier to use from a perspective it feels friendlier and happier for me as a non developer, which means I find that it's easier to move that into the world of infrastructure. People who are dealing with IAC and storing that in their gitlabs repo. But at the end of the day both work, both functional as you point out. There are many things out there that do a really good job of that.
[00:19:31] Scotti: All right, your turn, your turn to choose one.
[00:19:33] Tom: All right, interesting. Okay, this is one that I probably haven't had a magnifying glass on For a little while. But discovery tooling, by this I effectively mean that the things that are out there sniffing the network for the unknowns and finding things that you're not aware of. I know in our situation in the past we use various tools to do this. There are things by Ivanti and Solarwinds and the like. What's the current go with this sort of stuff? Is it a relic of the past? Are we still doing this?
[00:20:00] Scotti: I'm laughing as you're talking because in my mind you rattled off Ivanti, SolarWinds, these are all agent based things that run on Windows, aren't they?
[00:20:09] Tom: They can do, but they also do network sniffing.
[00:20:13] Scotti: I'm speaking in jest, I was just, I'm just poking fun. Look, there are a whole range of different tools and there are ones that I guess are probably more security focused that I'd be more familiar with and then there are ones that are more useful operationally. So around the cmdb, enumeration, asset management, lifecycle management, operations part of the business.
I think from a security point of view usually there's kind of two approaches. There's the outside in and the inside out approach. I know for everyone listening, I'm oversimplifying it massively here. From an external in point of view once again for me really comes down to what is your end goal? How mature are it? How mature is your organization to respond to things that you find. Also what's your budget? Because you can go once again from everything that's super cheap, right? If I look at outside in like if you, if all you're interested in is attack surface management from an external kind of point of view, from a network layer you've got things like Shodan which are from kind of like almost free to you know, a couple of hundred dollars a month. You can kind of go up from there. And I think where there's been a lot of, there's been a big shift. A lot of the attack surface management tools that focus on your external primitive largely focused on network infrastructure. So like DNS servers, service endpoints. So what's running on a particular port, what software is running on that, on that particular as that service?
I think where a lot of those attack surface management tools need to evolve and if you're out there going to look for one, you really want to be looking at, I guess identities and what I mean by that is people are no longer really attacking your infrastructure. It's weird, we go through these waves in cybersecurity. People used to attack the network, then the Network got better, we got stateful inspection and firewalls and things like that. And now we're going to talk about firewalls shortly. But we've kind of moved where the attackers have kind of evolved and they have learned that networks are now really hard. We've got really good detection around malicious traffic, etc. Where they've pivoted to recently is they understand that organizations don't really have a good grasp on identity and access management. So they've got users that have weak passwords that don't have MFA for one reason. Prime example, like a couple of weeks ago all of the Australian superannuation funds were having credential stuffing attacks simply because. And they were succeeding because they did hadn't implemented MFA, which in 2025 is just mind blowing. So what's actually happened is they're now focusing on identities, they're focusing on user accounts, they're focusing on service accounts. So they've kind of gone to the complete end of the spectrum. And that also means that you're now, now affects things like SaaS services because you don't traditionally scan the attack surface of your SaaS provider because that's not where the responsibility lies, it's on the SaaS provider. So I think from an Attack surface point of view, outside in, you really need to be looking at not just the, what would I call it, the lowest common denominator which is your network infrastructure and the endpoints. What you think is your, what you actually think is your Internet facing perimeter, but it actually needs to include identities as well. But for me that can kind of from an outside in point of view you've got the likes of, like I said, Shodan Bit Discovery got acquired by Tenable, also a really good external product that's now, I think they call it Tenable Attack Surface Management but it was originally Bit Discovery. There's other products. Wiz also has a external exposure tool Then the thing I really like about the way that Wiz does it is that if you have your DNS records in the cloud, it will enumerate all the resources including the things that potentially don't live on your DNS in your DNS zones.
So for example, it will look at say hey, you've got this database, it's exposed to the Internet and it's not on cordant.com au it's not like SQL cordant, it'll have an Azure Websites or an Azure DNS host name. So that kind of thing is really good. There's other tools as well. There's actually a homegrown Australian one called Asset Note. And I have a bit of experience with Asset Note over the years and I think they do some really good work. They also produce some really good research. To sum up the external side, there's a huge number of these tools, but from my point of view, you definitely want to make sure it includes identities because attackers are no longer just attacking your infrastructure, they're actually just logging into your applications. And that's really hard to defend from because there's no. People are just logging in which it's indistinguishable malicious or quite often it becomes indistinguishable between malicious and benign user activity. From an inside point of view, I guess there's a couple of different ways that I would look at this. I think probably the best tool I've seen is Run Zero. I think it used to be called Rumble and then I think they've. They've recently changed the name to be Run Zero. When I go and look at what tools I would want to be running internally, I definitely want to be focusing on things that are agentless. And that's, I guess, the first thing I look for. Anything that requires an agent to do discovery. Let's think about it. It's a. No unknown if you install an agent on it.
[00:25:18] Tom: Yeah, yeah. And that's how. How often things. Because I'm just thinking back to, you know, our, our first piece of work together and we had a. I can't even remember the name of it, but I know it's still in use today in various organizations. You basically had. Within each subnet you'd actually run an agent on a known box and that would go out and discover things within that subnet of unknown boxes.
[00:25:37] Scotti: Oh, yes. Yeah, that was called. I was thinking you were talking about Heat Service Management. No, the cmdb.
[00:25:44] Tom: But yeah, it's important too. And we should sort of add that the, you know, part of this is to populate the CIS within the CMDB as well is one of the aspects of this outside of security from an infrastructure operations point of view. But do you remember what the thing was called?
[00:26:00] Scotti: Leave it with me, I'll have to come back. I actually, I do remember what it was. I do remember the tool and it was one of the first ones where you could actually ask it in natural language. Show me all the machines running.
It was very cool and it would use. It used a peer mesh to essentially communicate with one another.
[00:26:16] Tom: Yeah, it kind of feels like that. That natural language thing is kind of what I love about Wiz and the way Wiz does things in the public cloud. It kind of did that on prem.
[00:26:24] Scotti: I remember what it's called now.
[00:26:26] Tom: Go.
[00:26:26] Scotti: It's Tanium.
[00:26:28] Tom: Yes, that's it. Tanium. I thought that was pretty cool.
[00:26:30] Scotti: Yeah, look, I haven't heard much from Tanium recently to be fair, but once again I'm not really in the market for internal asset discovery.
[00:26:40] Tom: Was pretty expensive, but it was good.
[00:26:42] Scotti: I'm sure it probably still is, but probably it's still good as well. Let's move on. I'm really interested. Another one of my favorite things here and I see that you've put VCF as an option. Let's talk about load balancing or application delivery.
[00:26:56] Tom: In my mind it's not entirely gone to commodity, but if we take the infrastructure side of things, it's fairly commodity in terms of what things are doing. From a load balancing point of view, you know, you've got traffic coming in, you've got back end sets, you need to drive that traffic for ha and the like.
So from a, from a purely load balancing point of view, if we take the security aspect out of the picture, you know, we see a lot of organizations with F5 for application load balancing and I think that's my gut feel is that's probably still the best in the industry in terms of just no compromise solution for your application load balancing. That said, with something like vcf, if you have invested in that, and to my point earlier around VMware, Broadcom changing the licensing model where you go all in with that sort of all you can eat VCF solution, if you've got load balancing as part of that and you're doing things greenfield and if I, and this is why we have think tanks about it that include all disciplines within our organization, I'd actually be making a case for saying do you actually need F5? Can you use application load balancing capabilities to actually handle that component for you? Because it includes sort of layer four to seven security and the like as well. So that would be. Would prepare to be argued down about that. But yeah, first thing that springs to mind, F5. But I'd be putting up a case for VCF if you've invested in that VMware license.
[00:28:20] Scotti: So from my point of view, I think it really starts with application compatibility. I think there are a whole range of different applications that potentially would run fine. Look, I'll be honest, I know very little about VC load balancing. I am familiar with like elastic load balancing in AWS and equivalent in Azure and the Network and Application load balances.
[00:28:41] Tom: In OCI sort of on par with that and you probably fall into the same.
It's not perfect and there are a few things that it doesn't do to be fair.
[00:28:49] Scotti: Yeah. And so in a lot of cases I look at it and go, most modern built applications, I think it makes total sense. Like I have seen customers go, hey, I'm going to spin up F5s virtual F5s in the cloud. And they go after. After being told I don't think that's the best or most efficient or cost effective way to do it in 12 months time. They can be, yeah, it was good because we could just lift and shift current config. But yeah, we've now migrated because it was killing us because the actual minute and baseline specs is actually quite expensive per hour or even with reserved instances. But for me I look at it and go, your application is compatible in most of the cases with a standard load balancer. I don't think you need an F5. I'll be honest, we're F5. So back in the day when we worked together the first time, this was a pure requirement because we had to migrate applications that were running. Remember they weren't even behind a load balancer. We had to migrate them, we had to change host names, the backend code. We couldn't change things.
[00:29:53] Tom: A lot of rewriting. Yeah.
[00:29:54] Scotti: Essentially we had to make the. It was a translation between what we were presenting to the Internet and how we were canonicalizing. I love that word. And standardizing DNS and folder paths. But the backend applications, which were all Java, were almost impossible, if not, you know, unable to be changed for one or more reasons. So we, there was a lot of rules, so irules, for example, that F5 provides. It's TCL. Anybody that's ever spent a lot of time with an F5 load balance for application delivery knows that it. It offers you capabilities. And I'm not saying they're exclusive to F5, but they. It's definitely the one that I would choose as far as flexibility and capability for more of your legacy style applications. But it's. I look at it as a bit like a Swiss army knife. It do a lot of things. It'll do fraud detection to do a whole bunch of stuff. F5 will sell you a whole lot of licenses.
It really comes down to do you really need it for your applications or not. Similarly to all the other things, specialist skills. Who's looking at it at 2 o' clock in the morning when something is not working so for me, that's kind of it. You also have you're also paying for two, right? Because it's not one device you need two for ha. And then you need two more in a different region for geographic redundancy. So quickly, anybody that's ever purchased an F5 or F5 licensing will know that it's not one license you buy, it's four.
All right, time for another grilling. Which one do you want me to talk about?
[00:31:19] Tom: All right, this is a juicy one because we've actually had some conversations about it this week. Let's go into endpoint protection. EDR, what's your poison here? Scotty, we've mentioned CrowdStrike already, so let's, let's delve into this one a bit.
[00:31:32] Scotti: CrowdStrike Next, can we move on? Not Microsoft Defender? No, I speak slightly in jest here. And yes, we have had some discussions this week around products.
Specifically there was a post put out by Conti Group. So Conti are an apt advanced persistent threat group. And right at the bottom under the Lowell category, it included Microsoft Defender for endpoint. And other than the fact that Microsoft keeps having Microsoft Defender for this cloud Endpoint, you know, there'll be one for AI and Copilot, I'm pretty sure, and one for Recall when that that is misconfigured in environments as well.
[00:32:09] Tom: And Defender for Defender, of course.
[00:32:11] Scotti: Hey, I'm sure, I'm sure it's coming. I'm sure It'll be an E6 license as well. From my point of view, I think the issues with CrowdStrike notwithstanding, around the blue screen of death, CrowdStrike is still my number one. I've worked with it quite heavily.
I'm not a huge fan of the API. I'll be honest, if anyone from CrowdStrike listens to this, I would really like you to simplify the API and produce decent SDKs and decent API documentation that isn't really confusing because even myself as a developer for more than 15 years still really struggled with it and took a long time, a lot longer than it should have to actually make the API work. But from a pure detect and response capability, there is no one in my mind that beats CrowdStrike.
[00:32:51] Tom: I think Microsoft to a degree was unfairly maligned in that, lol. Because there's Defender for endpoint, which is all the way down from the free stuff that comes with Windows through to you get your XDR license through Microsoft and the like. And, and, and it is, dare I say it, good. Better. But I, I agree. CrowdStrike's the Rolls Royce. If I wanted to sleep soundly at night, which I most certainly do, I'd probably be going with CrowdStrike as well.
[00:33:17] Scotti: Yeah. And I think this is back to their view. A lot of the tools that we've talked about today are kind of point solutions. I really like the idea when things Start Converging and CrowdStrike have really done a. I think have done a pretty stellar job in bringing together all the, all the bits. So you have CrowdStrike EDR, you've got CrowdStrike scene, they've got CrowdStrike incident response. So they're starting to bring all of those things together. So if you are looking for those things together, it kind of makes it an easier choice because you've essentially got one, one set of tools that work cohesively, that work well together, that has very similar ways for your team. So you're essentially using. You're not having to spread your team, your skills, your resources and your time across all of those different point solutions that then need integrating and managing and all of the other bits that go along with it. So, yeah, I'm squarely in the camp of CrowdStrike, not Clamav. I didn't see Clamav making even a mention on Conti's list, so clearly it doesn't get used much in the wild.
[00:34:16] Tom: Is Norton Antivirus still around?
[00:34:17] Scotti: Norton is still around, I do believe. I've been into some shops recently and they've tried to sell me a Norton Antivirus license, to which I. I said no politely.
[00:34:26] Tom: That reminds me, there was. There was this joke thing going around. This guy got tickets from, from first level to second level support and the guy actually said, customer is having a problem with their anti Norton virus rather than Norton Antivirus. And the response was, I wish I had an anti Norton virus.
[00:34:41] Scotti: I just, I'm a bit put off by the TV ads where, you know, it's. It's not great when they're saying, yeah, buy our VPN and stop all the hackers. And I'm pretty sure that was how it was pitched. I don't think I've quoted that exactly correctly, so don't hold me to it, but it was like, yeah, run a VPN and you'll stop all the attackers. That's not how the system works.
Yeah, but this is what they're advertising on television. I'm going, people aren't. People just don't know the difference.
[00:35:07] Tom: Not a valid enterprise solution. All right, what's next up for me?
[00:35:10] Scotti: Let's move on so let's talk about backup.
[00:35:13] Tom: I'll take the context here of something that is going to work more, take you through my thought process. So something that's going to work on prem across your IaaS, PaaS, cloud platformers and then into the SaaS world. Probably the most complete solution in that sense that I've landed on and I'm not necessarily a mess, we're not partners or anything like that, but consistently I find ticks all the boxes this day and age is Commvault. They've basically got, they've got a robust and it's going obviously going back many years in terms of their on prem solution and then the base solution which I think they got through acquisition of metallic. It provides you that sort of seamless cross on prem to cloud solution and it supports most key SaaS providers as well. So it will do backups via Salesforce and the like as well. Things that often, hey, it's great that Salesforce manage all of that, but if this is business critical for you and A, you need to take that somewhere else or B, have a doctor planning case for whatever reason, Salesforce goes belly up. You've got that coverage of your key SaaS platforms as well. So for absolute coverage of everything and the ease to recover, Commvault sort of ticks most of the boxes. So that would be my, I guess my safe play in the backup space.
[00:36:33] Scotti: Interesting. So I have, I have experience with Rubrik. You familiar with Rubrik?
[00:36:38] Tom: I've heard of Rubrik. Not operationally though.
[00:36:40] Scotti: So the one thing that I was really impressed about Rubrik is that they'd actually reached out. So I was working at Eric Customer's Environment and they'd said, hey, we found some credentials that we think might belong to someone important. It actually turned out they were correct. And I've, I've never seen, right to this day they are the only vendor or supplier to an organization that I've seen that have actively proactively, like contacted a customer to say, hey, our security team has found something. It was kind of a bit left wing because it's not really in the backup space, but they're obviously investing in proactive security on behalf of their customers. So it was like a, you know, if I had to recommend them, it would be 100%, I think from a backup solution. They also cover cloud and on prem as well. And I'm not sure if they do SaaS but definitely, I think from all the engagement that I had prior to that particular incident and everything afterwards, I can't recommend them enough.
[00:37:36] Tom: And this is a great example of why these sort of think tank sessions that we have are so good, where we have these robust discussions and you know, it's the way we start changing and introducing new experiences to our decision making process. And it may be that we've got a customer that doesn't have a SaaS requirement and let's fragment's sake, say Rubrik, they may have, but if we've got a customer that doesn't have any reliance on that, then Rubrik may tick every other box, may be cheaper and we know there's a good customer experience around that, that would be the contextualized solution for this customer. And it may be as that develops to, that becomes the choice that I go with. And it's the first thought that springs to mind rather than a commvault as well. So I think this was a really good example of two different approaches to the same problem.
[00:38:19] Scotti: So you're not going to recommend Symantec backup exec then?
[00:38:22] Tom: Whilst I have a lot of operational experience with that, I wouldn't want to wish that on my worst enemy.
[00:38:27] Scotti: Fair. All right, let's move on.
[00:38:28] Tom: Although I have used that to successfully recover absolute disasters in the past, so credit where credit's due. It did work as a backup solution.
[00:38:35] Scotti: And I'm pretty sure it's, I'm pretty sure it's still in use today. I actually googled it. It is.
[00:38:39] Tom: It is. Okay, there you go. Okay. It's not quite the elephant in the room, but it's, it's one of the biggest, most important decisions around both the networking and security space firewalls.
[00:38:50] Scotti: This is another ecosystem convergence budget. Like there are lots of things that would factor in here. I think personally have the most experience with Palo Alto. So if it was me and I was implementing it, it would be a no brainer. I also like everybody that works at Palo Alto. I think they've got some really very smart engineers and people that really understand the problem space of their customers and I see that in the products that they've built over the years. So like I said, you and I have like 10 years experience with Palo, but I think if I take it back to what would drive me to, to pick a particular vendor for me. Yeah, this is exactly what I've been saying all along. I think doesn't matter if you, doesn't matter what technology you buy, if you're not using it, you're not maximizing, you haven't set it up correctly. So in the same example with firewalls like this. To your point earlier, there's cheap and cheerful, there's open source, you go like pfsense. If you wanted to go with something completely free. I've got some mates that run it and I've had a good look at it. And you know what, it actually isn't too bad.
[00:39:53] Tom: I've got that at home.
[00:39:54] Scotti: Yeah, I probably should, but I ended up going with Ubiquiti because I just wanted something I could plug in. But look, if I think about the, the operational piece, so what, like Palo isn't cheap, you get what you pay for. So you need to have the budget, you need to have the people that operate it, you need to be actually get the use out of it. Also, like, if you are wanting to kind of buy into one ecosystem, yeah, they, they've got SASE with Prisma Access, they've got the CSPM product. So Prisma, Prisma Cloud, they've got obviously the firewalls, they've got Cortex, which is their SIEM platform, XDR platform. So once again, I think it really comes down to it's not just a decision made in isolation. I think one thing though, from a pure security standpoint, and this applies to all firewall vendors, I think from an organization standpoint, like everybody looks at the firewall as being, you know, this impenetrable thing that is going to sit on the edge of our network and it's going to stop all of the bad stuff. What I think we have seen is, and some vendors are worse at this than others, what we've actually seen is a kind of shift where I think people have been a little bit shaken in their trust of firewalls as being that one device that's never going to fail. We've had critical CVEs, we've had nation states compromising perimeter edge devices, installing backdoors, persistence type mechanisms, where in one case I'm pretty sure it was Barracuda. That said firewalls are completely toast, there's nothing you can do. We can't be sure that anything you do from this point will restore it to a safe state for operations. So you actually need to destroy it. Like that's a bold statement from a vendor. But this is, this is essentially where I think most organizations really need to be considering what is the past history, what are the assurance processes around particular vendors and particular firewall products. And I think at the end of the day it has to be. You really have to factor in, if that was to be compromised, what would you do next? And I know that's not really what we're going to cover today, but that's just my general thought on firewalls.
[00:42:02] Tom: Yeah, I think PA gets the win for mine as well. Not so much because they're a great product, had great experience with them. It's not so much that, it's that with pretty much all the competitors I've had poor experiences.
So to be in the game that long, to have something that I know and trust and have both managed personally and had my team managed for me and had pretty much nothing but positive experiences with it, it's pretty hard to.
[00:42:31] Scotti: Go past pa. Ah, I'm going to go with. Out of the ones that you've got left in your list, which one would you want to talk about?
[00:42:38] Tom: Probably an interesting one is remote access. We're probably entering a world now where it's still needed as a, as a technology but it's no longer the prime way of getting and I'm not talking here necessarily about V VPN access into networks and that's probably more that sort of SASE approach and device based trust and authentication is more moving towards where going but organizations still often have this need for a remote workspace, whether that's to get into particular environments within the organization or for external use or contractors that you bring on.
[00:43:18] Scotti: Are we talking about tools like Remote Desktop? I love Microsoft Remote Desktop. Are we talking about vnc?
[00:43:24] Tom: And that's exactly it. You know, there's all of those things and more and I guess probably from my experience from an infrastructure space, the last 20 odd years have been dominated by Citrix in this space just because of the level of control Citrix gives you and you've got the net scalers that in and of themselves are security devices that can provide that VPN capability that can provide load balancing and the like. So that's another one of those.
You're looking at the holistic view of what technology stack have you bought into. But there's definitely been an exit from Citrix over the last couple of years and you know, it's been a couple of years since we've implemented a new Citrix solution and there it was. It was a bit sad really that the waning support for Citrix within Australia. I still think it's one of those products that sort of ticks every box. It's almost like a VMware where it's still the most capable product in this space in terms of offering absolutely everything and absolute control over things. But I think we've moved past that as an industry and that's reflected in the level of support within country. So I can't hand on heart, sort of say go with Citrix anymore. We've been doing a lot of AVD with customers. So that's basically the Azure based remote desktop solution. If you've got an isolated OT environment, you can still use Windows Remote Desktop internally as a brokered solution with gateway proxy for, for ingress. AVD sort of does that as a service. We've been doing some cool stuff with Windows 11 multi session providing a really good, you know, seamless user experience down to things like, you know, support for teams and zoom and local handoff for all that sort of stuff. So it, it actually works really well. It no longer feels like you're using a, a remote machine. It's a really good experience. It's relatively easy to set up so that, that is fine. If someone says we need to set up a some way to remotely give users a full workspace experience, whether that's external contractors or users connecting in from untrusted devices, I'd be going with AVD and investing in avd.
[00:45:22] Scotti: That's interesting. I think having a, or a remote workstation that you can log into solves a lot of problems. Where I see a lot of organizations these days is that they're just not there. I think certainly I've been looking at remote solutions for customers.
A lot of the time they still just have a vpn. Well, let's look. Even recently in the news in Australia there have been compromises of VPNs and users working from home just connect to a VPN, have full access to everything.
I don't see SASE as the solution here. What I have seen, right. Like if we look at. So Cyberark was one example. I'm not recommending Cyberark by the way, but they have a remote solution. They have.
You can use the remote RDP client which actually kind of runs in the browser. It's a bit clunky. I know there are other kind of SASE solutions that will do it as well. Where I have seen success is through the use of Beyond Trust. So Beyond Trust is a privileged account management solution as well. I guess it's very similar. For those that are familiar with Cyberark, it's very familiar. It'd be very familiar. But it also works as a SaaS product.
It has, in my opinion it's kind of where the we would go if you wanted a remote access solution that also includes included privilege account management because it's not just one of the things most of the time you want remote access, like you just mentioned, running teams on a machine that might connect to an OT environment. And I was, I was freaking out.
[00:46:52] Tom: Not so, you know, with that sort of scenario you'd have, you might have an internal remote desktop farm within your OT environment that you're using for as a jump box. You wouldn't be using your AVD environment to get direct access to your OT environment.
[00:47:07] Scotti: Glad we cleared that up.
[00:47:08] Tom: Yeah.
[00:47:09] Scotti: I think from my point of view, from a security standpoint, beyond trust with having privileged account management, because like I said, most of the time you're wanting to remote into something because it's a high security environment, but it also needs to be accessible to contractors, third parties, employees on prem off site. It's one of those things that if you get it wrong, the consequences can be catastrophic. The other thing for me around privileged account management is usability. I've used CyberArt when we, we implemented it more than 10 years ago because we needed a privileged account management solution. It was really the only one existed back then. I can say looking at it over the last couple of years really hasn't come that far in my opinion. It still has the same kind of infrastructure. If you buy the cloud service, it's just in their cloud, it's still the exact same. Like it really hasn't become a cloud service despite them saying it's a cloud service. I think I had three authenticator apps on my phone for one customer. Like it was not straightforward.
[00:48:08] Tom: That's always a bit of a red flag for me when the cloud solution is just. Not only was it already feeling a bit antiquated on prem, but then the cloud solution is just the exact same thing. Even Citrix didn't do that.
[00:48:20] Scotti: So yeah, in some cases you would have to raise tickets to get them to do certificate lifecycle management tasks that should just be automated or you should be able to do yourself. So there are a whole bunch of things and I'm not trying to bag.
[00:48:31] Tom: Out, it works and it's again very complete in terms of its service offering.
[00:48:35] Scotti: 100% and it's very embedded in a lot of organizations, so certainly in financial services. So it is still a really good solution. But from my point of view, if you are looking for a solution that's easy to use, I would go with beyond trust. And it does some really cool things like hey, you fire up a remote desktop session, it will automatically inject your credentials into the login screen so you don't have to copy and paste and that solves a whole range like I said that the hardest part of implementing any of these PAM solutions or PIM solutions, but not going to talk about pim, is you need to get users to use it, and specifically not the ones in the security team, because they're the ones that might manage it and administer it, but they're not. Primarily, 99% of the people that use the solution will be outside of security.
[00:49:20] Tom: And I'm 100% on that. I found that Cyberark tended to be so clunky that the first thing people did was try to work out ways to get around it and not have to use Cyberark. If something can accelerate and make it easier to gain access, then you're winning. And unfortunately, I found Cyberark actually made it more complicated. So, yeah, I'd love to. Love to learn a bit more about Beyond Trust, actually. Might have to run a session for us.
[00:49:45] Scotti: Yeah, for sure.
[00:49:46] Tom: All right, so look, we've. We've had some common themes come up and we've. We've even mentioned them as we've talked through, you know, some of the. I guess, some of the considerations we have when we decide a product. We've talked about things like buying into an ecosystem and the like. And maybe just to wrap up now, we can. We can sort of talk through some of those key points and some of the why we pick a particular solution over another. I might kick it off so we can have a chat, because I think we're both pretty aligned and similar on some of these things. So for me, it's more than just a technology and what the technology does functionally. So when we talk about things like ubiquity and the fact that it's everywhere, that in and of itself isn't a contributing factor. Just because everyone uses it doesn't mean it's right. You know, take Symantec as a great example of that, or McAfee antivirus.
But what ubiquity gives you, I think, from an operational perspective, is that knowledge and that understanding. And when it comes to resourcing your team and getting support, the more that's out there, the easier it is to support. And when you do have an incident, the easier it is to resolve that incident. So that's where I think ubiquity is key in the resourcing and support component of a technology.
[00:50:58] Scotti: So I think on the ubiquity piece, I'm like, I guess it's kind of aligned with convergence as well. Right? Because if you have a whole range of tools and solutions that work well together. Noting that once again, this Comes down to the size, complexity, makeup, the way you're going. What does this strategy look like for your team and your business? I am a big fan of converged technologies. I'm a big fan of having tools that work really well together because it makes things really simple for the team and what you're actually ending up with better outcomes that occur faster. You actually, if you're thinking about a spiraling up approach as far as maturity models or maturity levels, you're actually, you're going to do that a lot faster. When you've got tools that work really well together and you don't, you spend less time trying to work out why this one thing wouldn't integrate with this other thing. And I've got a really good story around and we'll talk about it at another time about trying to get cyber ARC privileged account management integrated into tenable to do authenticated scanning. I spent, I spent far longer on that than I should have. But once again, if these products were within the same ecosystem, noting there was integrations for this and I should have just worked, but it didn't and there were some really weird edge cases that weren't documented. So I think having having a single ecosystem or as many tools in one ecosystem as possible, noting as long as they meet your requirements, I think that's, that's super important.
[00:52:21] Tom: I think that's a big one. Where you've got.
Part of the consideration we have is the size of your team. And if you have a very large team, then you can afford to have specialists in individual technology stacks. But where you've got a lot of generalists, I'll use Microsoft as an example. Within the market, there are a lot of people that understand general Microsoft technologies. And the fact that using one Microsoft technology bleeds into the other from a consistency point of view actually makes it very easy to both resource and support those. If you have anywhere from a small team to you've only got a couple of resources. If you lose one of those and you're down 50%, it's easier to go to market again and find someone that understands a whole lot of Microsoft products than it is to get someone in who happens to know the five different products. You have to achieve these five different things.
[00:53:12] Scotti: Yeah. Or you end up putting out a job ad that says, hey, we want someone with skills in, you know, 30 different disparate areas across all the disciplines of cybersecurity.
[00:53:21] Tom: Yeah, I think we're not looking for a unicorn, but.
[00:53:25] Scotti: Yeah, but, but we want a unicorn.
[00:53:27] Tom: Yeah. So I think there's a lot of value in. Yeah, you're right. Standardizing and converging to a technology stack there. I mean we mentioned it a couple of times as well. I think it's. It's big for both of us for. For slightly different reasons but. But user friendliness I think is key as well to me working with something that is user friendly. I don't come to work to be frustrated and I don't care how good something is. If it's very difficult to use, my instant reaction is to rile against it. So I think actually user friendliness is an underappreciated value of a piece of software and something that looks nice, feels nice and is easy to use, there's far more value that needs to be ascribed to that and it's a key weighting when I on picking a product.
[00:54:09] Scotti: If I think about it a you don't want to have to have a university degree and to operate a specific vendor's piece of software. That is number one for me hands down. I really like where the getting started. Like the 8020 rule, most of it is just out of the box. It works is a really good place to start. When you've got to spend days, hours, weeks, weekends to really get like it just working and then it's not even really optimized, that's a problem. Or the vendor says, hey, you've got to go and talk to a partner because this is so complex or you've got to buy all this training of which you're going to forget and then you're going to go to the partner anyway and pay even more money. So you've spent money on the tool or the solution or the service. Then you've paid for some training to understand how to use it. Then you've paid a partner to come and help you. When you've kind of butchered it a little bit, then yeah, it becomes a big problem. So for me it's more so about the actual getting to the point where it's operating, it's effective and you're comfortable that it is doing what it's supposed to be doing. But then also like how are you going to support that ongoing? So I think there's lots of elements to it. I really would love to see security companies really focus on that user experience more. Like there are some that we know that do this unbelievably well and it shows. And then there are others that we've also talked about that really need a lesson in UI design and I'm there's So many of these security companies that buy or acquire capabilities and technologies that don't then integrate them, for example. So you end up with a product that says this is one product, but you log into it and then you've got six different tiles and then you click on a tile and you go to a completely different looking thing. Some that looks like it was written in the 90s, some like it was written at completely different languages, completely different systems that barely work well together. Like that's not the type level of integration that people are expecting these days. And I think companies, if you're going to invest and buy and acquire capabilities and technologies to grow, that's awesome. But you really need to make sure that you integrate it well.
[00:56:15] Tom: Yeah. And look, Wiz has been a standout for this recently. Our sort of experience they brought in, was it Daz as defend.
You can't even tell when you're crossing the line into the stuff that was Daz because they've just integrated it so well in there in the user interface and user experience. So that, that's a great example. And yeah, it's, it just doesn't cut it anymore. I think.
[00:56:34] Scotti: Yeah, the people that understand it, I think it was Daz and Jim that they've acquired. You can't tell which is awesome from a user point of view. It's ubiquitous. It's the same experience, it's the same set of APIs, everything's integrated. I don't have to think about how to make things work or spend a lot of time when things break. So I'm really excited to see other companies kind of follow their approach and convergence because at the end of the day it's better for the end user and better for customers. I think we've talked about some really good things, but the last one I really want to touch on is portability and abstraction because I know like we both worked for cloud providers, we do a lot of work with cloud customers and we've talked about tools, some of which are cloud based, some of which are on prem only, some are hybrid. Give me your thoughts on like how does a, how does an organization navigate that whole realm of portability? Because you really, if you go all in with one cloud service provider, the thing that you realize, like VMware is a really good example. VMware, if it was running on all the cloud providers, you could pick up a VM somewhere and move it somewhere else. Right. You've still got the VMware solution as that layer of abstraction. But then cloud service providers don't Particularly like that. They really like customers to be locked into their platform. They. But then they say, oh, but we've got these backup services and everything's redundant. Well, it isn't. We've seen that. We've seen that in Australia with the weather event that knocked out Azure and OCI in the same data center in Sydney, and customers like, hey, why are all my things down now? Because I've actually paid for two cloud service providers, I've done everything right and I'm still in that position where I'm stuck and I can't move somewhere else. So like, how does an organization navigate that?
[00:58:15] Tom: It's almost more of a risk discussion than anything else. Like, I like portability because I hate painting myself into a corner. No matter what it is, I always like it's the oft used term, but agility to be able to pivot. So if things go wrong with one service provider, you can pivot to something else. So I like to look at products that are portable, both from on prem to cloud, for instance, or from one vendor to another. And if you have to introduce layers of abstraction to achieve that, then so be it. But you've really got to look at your business, what you're doing with things.
Maybe there are regulations that require it, for example, things like apra. From a compliance perspective, you have to actually take portability into consideration. And let's say you can't go all in with aws. What happens if things go south with Amazon? You need to pivot to something else. If you've got everything baked into lambda functions, you need to have a solution that you can move those functions to serverless functions to another cloud provider or another solution provider as an example. With something like that, you could take the step back and use an agnostic server functions, the FN project, to handle your serverless function and you can run those on aws, Azure, on Prem, wherever. So this for me is certainly a big consideration. And using things like Terraform rather than cloud formation, if with Terraform it's not just the infrastructure and the cloud services, you can extend that to controlling your firewalls and your switches and routers as well. So you've got that level of abstraction in and of itself helps with that portability. You might need to do some rework in Terraform itself as an example. I know we didn't talk about that, but for me it's when you do that, you're not painting yourself into a corner from a compliance perspective. You're not painting yourself into a corner from a business Continuity perspective. For some customers, it's not actually a concern. So, you know, I sort of mentioned earlier, it's a risk based decision for some customers. If you're a smaller customer and you go all into an ecosystem, it's probably okay, you know, if you control your source code and you're not using some of these necessarily services that you can rewrite and rewrite quickly enough, it's probably not that big a deal. But with the customers that we tend to work with, they tend to be large enterprises, they do have some presence on PREM and in the cloud. And for me, having a consistent set of operations and practices between the two is really important because that gives you that portability of workload, but it also allows your teams.
You get a return of investment in your teams as well. The team that can manage on Prem can also manage things within the cloud environment as well. So there's a multifaceted reason behind why portability and abstraction are key.
[01:00:51] Scotti: It comes down to the security architecture. In engineering, a lot of the tools that we use are portable. So for us in the security space, it's more in the infrastructure architecture than security architecture and engineering space. I don't, I don't see it being so much of an issue from that point of view, but you're right. For me, it also really comes down to like, in some cases you can't avoid it. So if you're using like data analytics services, they aren't ubiquitous across cloud providers, they're just not. So unless you're going to go out to a third party, once again you've got the trade off between convergence or like potentially what you don't realize, even if you go to like a databricks or a datadog, they're probably also running in the cloud in the same regions where your workloads are. So there's a lot of things here that I guess it's a bit of a Rubik's Cube problem ultimately. Yeah, I think it really comes down to how long can you actually remain offline before you need to start thinking? Because for some businesses, you said if it's a couple of hours, some businesses could be a couple of days. I've looked at one recently that said it could be like a certain critical business processes could be offline for like two months because of the schedule in which they do processing of particular portions of data. So in a lot of cases, like it's very business and situation specific.
[01:02:10] Tom: Just talking about these things now, Scott, it highlights that a solution is more than just a technical solution. You can't just say as we've done today, we've sort of spoken about the what, but everything does have to be contextualised around size of the business, risk budget. All these sort of things play into the decision making process. Are we able to redefine the how? And you mentioned it earlier, this is the what component of a how, what, when, why discussion. And it's why these things don't just take hours or days. That yeah, quite often where we're discussing this for weeks, both internally with our customers as well to land on the right solution. But I've had a really fun time discussing some of these things. Again, we've surfaced some things that I'd like to learn more about just in some of the products that you've put forth today and I hope our listeners have got something out of this as well. I think we will follow it up with a part two at some stage just to cover off the areas that we didn't cover off. We started touching on some of those things as well. But they're equally as interesting and if we talk about them in a couple of months time, they may very well have evolved beyond what we were going to talk about today had we had the time. So Scotty, thank you again for a thoroughly entertaining conversation. We'll catch you again soon. We'll catch our listeners again very soon, hopefully. Until then, have a whole lot of fun and stay safe. I think that's a wrap.
[01:03:30] Scotti: It's a wrap!
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.
