Catch this episode on YouTube, Apple, Spotify, Amazon, or Google. You can read the show notes here.
Zero Trust is seen as many things, but a seamless and easily adoptable strategy is not often one of them. That is unless you develop an MVP or minimal viable product approach to building a ZT strategy. And for that, we bring in an expert who is well-versed on the topic. An expert who wants security teams and leaders to understand that perfection is the enemy in this equation.
Like any big project, you need to start small. You need to break down projects into manageable pieces, that can be done in isolation. Bonus points if you can spread those tasks out amongst other teams since you'll increase the overall velocity of the project.
This week on Adopting Zero Trust (AZT) we chat with Kane Narraway, the head of Head of Enterprise Security at Canva. Prior to his current role. Kane has been adopting Zero Trust for around a decade, starting with the UK government, and later to organizations like Shopify, Atlassian, and BT. You could say he’s seen a thing or two, and has absolutely been part of the evolutions occurring within cybersecurity and Zero Trust. Kane walks, crawls, and runs us through how he has built out Zero Trust strategies and recommends where organizations get started.
TL;DR
Kane Narraway advocates for a non-traditional approach to implementing Zero Trust. Instead of spending years on planning, he recommends having something in place within 6-12 months and then iterating and building on it.
Kane's approach to implementing Zero Trust is a practical one. He emphasizes focusing on protecting the most critical applications first and iterating from there.
Start the implementation of Zero Trust by bucketing applications into risk tiers and focusing on protecting the most critical applications first.
He acknowledges the challenges faced in implementing Zero Trust, especially when he started about 10 years ago when there were no vendors. However, in the last two years, he recommends using a vendor instead of building a solution yourself.
Kane mentions cloud-first vendors like Okta and Cloudflare as providing solutions pretty close to Zero Trust. He also recommends Microsoft as a good solution for organizations already in the Azure ecosystem.
Neal remains the champion of Lord of the Rings trivia, and stumped the question bot that apparently got its own answer wrong.
Editor’s Note
As a user of Canva (it’s where I generate a lot of the graphics for the show), I selfishly wanted Kane on the show; however, I am so glad we got some time to pick his brain because I am now more confident in some of the unreleased IP we store in there remain secure. And on that note…
Neal and I may or may not be toying with the idea of creating a new type of conference. The test run will likely be entirely virtual, and if successful, I’ll try to build a physical aspect down in Charleston (SC). If you would be interested in speaking, please reach out. Most of the presenters will be hand-selected, though. If you also have strong opinions on things you’d like to see at a cybersecurity conference, also reach out and let us know. We also expect to keep it small and focus on a combination of information accessibility and building connections.
The Non-Traditional Approach to Zero Trust
While working at Canva, Narraway explained his unique approach to implementing Zero Trust in organizations. His experience with Zero Trust includes building it at Shopify, Atlassian, and a few smaller consultancies and startups.
His approach is slightly less traditional than what you might see in many places. Instead of spending two to three years planning, he advocates having something in place within six to 12 months and then iterating, building, and taking more of a builder approach than this sort of architecture approach. The focus is building the minimum thing you need to get the biggest security bang for your buck as soon as possible.
Risk-Based Approach to Zero Trust
When implementing Zero Trust, Kane suggests starting by bucketing your applications into risk tiers. "Where is our most sensitive data stored?" is a question he recommends asking. From there, you take another layer above that and you go, "What controls access to our most sensitive data?"
For example, Microsoft Intune, MDM might not store any data, but it is certainly going to control access to your machines. And then your machines are going to then access your data stores. You need to think maybe one, maybe two steps back. But he strongly believes in taking that risk-based approach and working out what you care about the most and then focusing on that stuff.
Kane’s MVP for Zero Trust Adoption
Though Kane chatted through his approach to building a Zero Trust MVP, his recent blog post really spells this out:
This is how I recommend most companies split down their project, but of course, things can and should be moved around based on risk and criticality.
Stage 1 - Limit access to critical resources from only hardened, company-managed devices.
Stage 2 - Deal with BYO, contractors, exception management and more. This stage is really dealing with all of the exceptions from Stage 1, you can split this down into sub-stages if needed.
Stage 3 - VPNs, On-Prem, Physical Systems and SASE. This stage won't apply to every company and some may move parts to Stage 1 depending on criticality of data.
Stage 4 - This is where you operationalise your setup, with metrics, data and testing. I've seen too many zero trust setups fail because of a rogue production change that wasn't caught soon enough.
Challenges in Implementing Zero Trust
While discussing his journey in implementing Zero Trust in organizations, Narraway highlights the challenges faced in the market space. Back when he started about 10 years ago, there were no vendors at all, and teams had to build their own systems, learning and iterating from each other. There was a lot of work, effort, and maintenance involved.
However, the situation has changed dramatically in the last two years. Today, he recommends using a vendor instead of building a solution yourself. He believes that cloud-first vendors like Okta and Cloudflare provide solutions that are pretty close to Zero Trust. He also mentions Microsoft as a good solution for organizations that are already in the Azure ecosystem, mainly because of how easy it is to deploy.
Today, he recommends using a vendor instead of building a solution yourself, and no, VPNs are still not aligned with the concept.
Narraway's approach to implementing Zero Trust is a practical and risk-based one. He emphasizes focusing on protecting the most critical applications first and then iterating from there. Despite the availability of vendors in the market today, organizations need to carefully consider their specific needs and constraints when choosing a solution.
Transcript
This transcript was automatically created and is undoubtedly filled with typos. As usual, we blame the machines for any errors.
Elliot: Hello, and welcome back to Adopting Zero Trust or AZT. I am Elliot, your producer alongside Neal, your host. And today I will not lie. I am really jazzed up and hyped up about this. Not just because of where our guest comes from. And it is a thing that I use on the daily, including for our podcast, but because of how he has positioned and put some perspective around the concept of zero trust.
If you are familiar at all with how organizations have built strategies and concepts around zero trust, it is a little drawn out to say the least there. I don't know. In the last week, CESA announced an entire new zero trust office that they're putting together. There's books around it and it just looks like years upon years to be able to achieve something and Is that really like the way that we want to position things if it is absolutely crucial and critical?
So that is all to say today we're going to be discussing zero trust in an MVP or I don't know, a most viable security perspective. We'll figure out that. I'll hand that off to the guests to be able to actually communicate that. So without further ado Cain, if you could introduce yourselves and give maybe a little bit of background and then we'll go from there.
Kane Narrawway: Yeah, absolutely. I'm Kane. As Elliot said, I think he likes it because I live in New Zealand and so I think there's going to be some Lord of the Rings trivia that might come up in this podcast as well. We'll see how that goes. Currently I'm working at Canva. So for those who don't know, Design Company that does presentations, docs, that kind of thing.
And we're currently in the process of building out Zero Trust there, but my experience with Zero Trust has been building it at Shopify, at Atlassian, and a few smaller consultancies and startups along the time. And so the idea is that yeah, maybe I take a slightly less traditional approach than what you would see in many places and build.
Sort of, I don't want to say hacky, but build the minimum thing that you need to get the bank, the biggest security bank for your buck as soon as you can, basically. So rather than spending two, three years doing the planning, actually having something in place within six to 12 months and then iterating, building and taking more of a builder approach than this sort of architecture approach.
Elliot: Absolutely. So you nailed it. That is exactly what you're and it's not just because you're amazing beard and yes, the New Zealand thing is cool too. But that is the focal point. And of course, as per usual, Neal, we'll take you down some other rabbit hole, I'm sure. And we'll probably ask you for 30 other return visits to the show.
That is absolutely crucial because it is not really something that people have communicated effectively of how to develop this in a way where you can attack something, show impact and value, which in cybersecurity, it's always treated as like the cost center. And, you got to do more with less and all that good stuff.
In George Finney's book, Project Zero Trust. It talks about that to an extent, but it still talks about a much longer cycle. And it sounds like from your perspective that you're able to attack one strategic thing, show impact, and then, maybe expand from there. But I'd love to maybe expand upon that a little bit.
What does that look like for you? Outside of maybe some kind of hacky things like, is it based on impact? What's the outcome that you're looking for with this philosophy?
Kane Narrawway: It's a, it's a good question. I think it really depends on the organization, but. I always start these projects out by sort of, bucketing your applications into sort of risk tiers, and thinking, does this have any sensitive data and what that means to different companies will be very different.
An approach I personally like is splitting down your data into user generated content, PII and splitting that into internal and external PII. And then you really dive down into. Where is our most sensitive data stored? And then from that, you take another layer above that and you go, what controls access to our most sensitive data?
So for example Microsoft Intune, MDM might not store any data, but it is certainly going to control access to your machines. And then your machines are going to then access your data stores. And you need to think maybe one, maybe two steps back. But I do think taking that risk based approach and working out what you care about the most and then focusing on that stuff.
And so the way I normally recommend Zero Trust is, it is a cake, you can cut it into as many slices as you want. It's gonna depend on how big and how complex the company is and that kind of thing. But I always recommend that the first sort of slice that you cut is protecting your most critical applications and making sure that you can only access them from legitimate corporate owned devices, because the idea is that you probably don't want people accessing AWS, GCP or customer data with their personal mobile phones.
And we've seen all sorts of breaches where, you know, like a Plex server got breached in one company, and then they pivoted from the Plex server to the work account, and then from there into the corporate like network. And so, I always find just, you're better off protecting those things as soon as you can, and then worrying about the other stuff later than spending three years without protecting a single thing.
Elliot: Interesting. So are you more or less using your. Let's call it a risk register to help prioritize where you would attack this, or is it more specifically those examples that you highlighted are like, these are typically like the lowest hanging fruit that we need to attack and cover or is it more internalized and prioritized in another format?
Kane Narrawway: Silence.
I've got really sensitive customer data.
And it's stored in Zendesk for customer support or something like that. But maybe customer support agents need to be able to access things from their mobile in order to test customer queries. And so, you may not have corporate mobile devices at that point. You might only have personal devices.
And so you might say, this is super critical. We definitely do want to protect it, but we can't do it now. And so you need to make those trade offs almost. And so then you might say. Okay. I'm going to create my own standard underneath of the sort of risk register of the company. I'm going to have deviations from that standard, and I'm going to explain those deviations as to why.
And then you may come back to those in later iterations where you start to, to clean up some of the prior things that you've left as exceptions.
Elliot: All right, Neal I'm going to hand this out to you. I feel like this is your world now.
Neal Dennis: Okay.
I'm going to go backwards here with some of the stuff you mentioned.
So you talk about the risk register. So for those in a normal world, risk register, I think is more or less right about way to talk about the overall risk profile that hopefully the C suite everybody bought into, right? So in my world, that translates into requirements for protection in zero trust world that also loosely maps out in theory to the similar aspects of where we should be going.
And I think real quick key takeaway is, and the whole goal of this larger conversation today is bite sized chunks make large impacts the more you do, like the quicker you're able to get to those pieces, right? So like you mentioned, a little bit of a pie section, take a little piece, figure out what's hypercritical.
Don't try to build a massive plan around the entire architecture. Try to figure out how to build a plan around that one little snippet and then you can get to the rest of it as you move forward. At least proof of value. So with that, I think some of the things for me personally, these baby steps what's your personal approach then?
Where what we've seen and what I think there is one you on this call where we have most people take a three year program to your program approach to things and they don't start doing anything right. Yeah. So let's say if you're trying to push for value or you're trying to push for funding or whatever it is, you want to do something, but you don't obviously want it to be three years out before you're able to start implementation.
How would you
Elliot: to
Neal Dennis: someone to approach this to say, hey, give me 100 grand for this, even though I know I need 10 million for this later, but let's get the money today for this one little piece. What's the risk kind of conversation balance look like in your mind?
Elliot: about
Kane Narrawway: good question, right? And this is actually something I see in a lot of zero trust rollouts where. They start and then they lose steam maybe halfway because either they were staffed up with contractors or they got people in from IT and developers. And then those people then have other priorities that are maybe higher and they, they move off back to their original teams and you get this sort of engine that was moving really fast.
And it slows down as time goes on. And so I think there were two approaches that could work depending on the company. I think. You can absolutely set the three year plan. I think that you just need to have deliverable stages where you're being like, yes, we're going to do this, then, and this, then, and this, then, and you can say, look, in three years, we're going to have zero trust, um, network architecture that is at this standard, and I'll probably talk about this a little bit later, but I always recommend, um, aligning yourself to some sort of framework or standard so you know.
Let's say we pick NIST and we say, Hey, we're going to be like level three on the NIST zero trust standard. And, in three years we'll be at five. And so, that's one approach and that's the sort of more plan everything first, then get going, but don't plan too much, if that makes sense.
I think the other approach you can do is you can just say, Hey, we're gonna. Like we're going to protect this stuff. Like we're going to protect our most critical applications. Once we have completed that, we will then reevaluate and see if going beyond actually makes sense for the company, because, some startups heavy in the BYOD space, they might have more flexible requirements.
They may not even have the need to actually build security to full zero trust standards where you have this data and context access and all that stuff. Like just might not be worth the time. And that's the other approach, so chunking it into those groups, having very, set deliverables each time, and then re going back for funding the next time.
Neal Dennis: So I think on that note, the microtization of your requirements. And in your effort, so let's get back to the illusion of three, four year programs for rollouts, but you want to show value prop now, and this leads into a different question about scale of economics. Obviously, if you're a massive company with a hundred employees, all working on zero trust modeling and rollout, just do it.
But if you're a smaller companies or normal company, or it's the one person that's getting asked to do stuff, for the sake of that guy, keeping his job next year. I think your mentality and the approach of let's just focus on one key thing, we'll build that, and then we'll build policy to fit the rest of the things as we go.
Because the construct is all still at the core of the same, right? So if you do it around critical infrastructure, you're already building policy that you can apply towards these other endeavors downstream in theory, at least fundamentals, right? It's just flipping what you're trying to protect and how you're rolling it out.
So I think for most people understanding bite sized chunks. Don't try to do it all in one large plan if it's literally just you doing it.
Kane Narrawway: Absolutely, and I'm not an advocate of doing no planning and just jumping in and going, Hey we'll probably work it out. I think the granularity is the difference. I might build a project and I might say, we're going to build public key infrastructure, and We're going to support all of our devices and we're going to build sort of access criteria for them.
And you find a lot of people will go too granular with it. They won't be happy with, we're going to have a project to build PKI. They just want to know everything now. They're going to want to know like, how long do the certificates live and how are we going to do revocation? And will it connect up to all of our MDMs and stuff like that?
And I think you just need to accept that. Yes, these things will probably work, you'll probably get through it. You may have to do more work than you expected sometimes. You may have problems with vendors, where they don't support the thing you need, and you might have to push them early to get them to start building things.
But, if you get too into the weeds, you, like I say, you'll just spend too long planning, and by then Some new tool will have come out, you will have released some stuff internally, and then that's more stuff you've got to add into the plan, and then you just end up planning forever, right?
Neal Dennis: I like that one. We had a wonderful quick chat about technology on LinkedIn. And who's really at fault. But that, that being said, I'm not going to repeat my quote from LinkedIn
Elliot: I will, if you want,
Neal Dennis: Yeah.
Elliot: I built a, an entire website to troll those people and I think it was like top zero trust. com. If you click it, it's zero trust EDR or whatever. And you go to, it's sorry, it's not actually a product.
Neal Dennis: tangent incoming. Okay. And here we go.
Kane Narrawway: Ahead, I'm interested to hear because I think I missed this one.
Neal Dennis: Obviously, so yeah Elliot loves to troll the trolls basically. We've got these, like you're aware of having done this countless times now you go out and you start looking for, it doesn't have to be just zero trust, start looking for a solution because it's the latest flavor, like LLM and AI right now, and chat, GPT related stuff, magically every vendor that's a top security performer magically has something in their marketing slick. She's, this is LLM, APT or API. They're APT ish wannabe, but flavor of the day stuff, right? But it's all bull crap. Most of the times it's just them repackaging old things and slapping a label on it.
So it has built a wonderful site and interactions around those types of engagements and, let's get you the single pane of glass API LLM model for your EDR solution that does zero trust out of the box. Things like that being said, interactions on LinkedIn, having to deal with that, I'm going to ask you a question at the end of this, but I'm going to get to the point tech stack, to be fair to the ones who do actually have a legit solution, because there are obviously those are out there.
They come out of the, they say, Hey, there's a lot of zero trust startup companies. There's a lot of companies that have hardcore folks on zero trust. And one of the mentions on LinkedIn was I don't remember exactly what he said, but I remember what I said to say it was. He was always trying to show that it's not really necessarily the tech.
It's maybe what we do with the tech. He was like it's always the tech, it's whatever. And, I commented back to some extent to some effect that, it's. Probably not necessarily the tech so much as how you're implementing the tech that really makes it suck. It's like selling you a Brillo pad and you're using it for toilet paper.
It's not my fault what you get in the end. And so that being said, your experiences on this journey, so you've done this a few times and probably enough where at least at the beginning, there wasn't necessarily the marketing hype probably around the term. So you might've been looking at. Some of the basics, maybe from the foresters and stuff like that, right?
For the original terms. So I'm curious on this. What's your experience within the market space for what you've had to deal with from building something more holistic within your own world versus being able to actually go out there and procure a technology that. Said zero trust and you really be able to follow implementation plan based off of what they suggested and getting what you expected.
Kane Narrawway: Yeah, that's a great question. To take you back to where I started maybe 10 years ago now, I was doing security for the UK government, and we were building Zero trust then, like it looked very different. Like we did have VPNs and some of that stuff. So technically it wasn't zero trust as we know it today.
But we had certificates on our machines. We were accessing the VPN with the certificates. We were doing posture checks on our devices. We had segmentation on our network and all of this stuff. And could you say we had a zero trust network? I think no, because the target has moved and the idea of zero trust now is like a sass first world.
Unless you believe this sort of sassy stuff. Like to me, sassy is, it's like a place on the way to zero trust. And you may stay there, but you may never get to zero trust entirely. Like you might stop there and just go, Hey, this is good enough for us. Not everyone has to do Zero Trust. That's totally fine.
Just accept it and maybe don't call it Zero Trust, I think. But sorry to get back into your thing. Yeah. Like when I started this, just there were no vendors at all. I think Google had just released their white paper. On how they built beyond corp. And it was very much Oh, that's interesting.
And I think me and a few other people in a few companies all started building our own things and we were learning and iterating from each other. And so it was very much like a small closed off group at that point. And then I think some vendors started entering the market, but back in those days, it was very much
first,
python scripts to just check what OS version you're using like it didn't really work And how you wanted it to be I think only today would I say in the last two years maybe that
United States,
asked me two years ago on what tool should I use?
I'd say don't use a tool build it yourself if you have the resources if you ask me today I would say, please do use a vendor like don't build this yourself because Having gone through that It's it's a lot of work. It's a lot of effort. It's a lot of coding, sort of maintenance. And I think that, the vendors do pretty good.
And it depends what you want. There are cloud first vendors like the Octus and the cloud players of the world where, they don't give you zero trust out of the box, but it's pretty close, same with Microsoft as well. I actually think if you are in Azure using Microsoft, like Windows devices.
And, your 365 and all of that, Microsoft is probably the best solution for you because it's so easy to deploy. It's just so easy because they just control the entire ecosystem. Whereas I think a lot of people approached it from the, Hey, we already have a network and we want to get to zero trust.
We've got all this on prem stuff. So maybe let's use the more like Zed scalers, Palo Altos, do the sassy thing. And. Maybe that's good enough for us or maybe we'll use that to kickstart us and Keep us going until we can move all that stuff to cloud if we ever do that. So Yeah, I guess that's my thoughts.
There's a lot there to digest I think
Neal Dennis: No, I think that's a fair hot take. And I, we were laughing cause you mentioned a very good point about VPNs, not zero trust. And that's also something that Elliot for the last two and a half, three years now has been nonstop on, on social media. Every time someone says, Oh yeah, for your zero trust policy, just implement this VPN and then Elliot is.
I think he's got this on hot search or something on LinkedIn. I don't know, but I see my feet come across. Someone mentioned VPN and zero trust and Elliot's right there going, no, I don't think you understand what this word means. But,
Kane Narrawway: It's it's very common and This is maybe a tangent but a lot of zero trust. Things today, they have an agent that you install on your device and it's like a VPN client and use the whole secure web gateway thing where you have an IP address and then you connect into those services and you're essentially doing IP and our listing and part of me just goes, ah, like this is, this hurts.
This is like going back to how we used to do things 10 years ago. And I know there's very valid use cases for doing that. If you need to protect APIs where they don't have SAML. That's probably the only way really was the only good way I've seen. But, yeah, it's something I don't want to do unless I have to because I'm always like we should be better than this But there is nothing better yet
Neal Dennis: yeah, that makes total sense. So on some of those notes with the tech stack and the growth. So I think that's actually maybe a good transition. So we talk about tech and the failures. We talk about VPNs and the failures. So from a starter package perspective we started alluding to this before we went down the toilet paper route, but when we're getting started.
So we mentioned small company versus big company. And, once again, your background, small companies, big companies as well.
A
What's been maybe some of the bigger hurdles for you at either stage or have they been comparable when you've been getting started irrespective of scale of the company when you've been working into this mentality or have there been substantially different hurdles based off of scale that you've had to really consider when going forward?
Kane Narrawway: collection of problems for smaller companies is resources and money So for example with zero trust setups, you generally need the idea of corporate devices, right? Not BYOD. So you're gonna have to convince a CEO or a CFO We need to buy I don't know, 100, 200, 500 MacBooks or Windows machines or whatever that they're gonna use.
And, usually that is the difficult part, I find. It's the, hey, we need to pay for something that already works, but it's a security thing. And I think that, you can point to a lot of breaches in the past and you can say this is what can happen and things like that, but it's really getting that point across.
Yeah. I do think it's a lot easier though. Like if you are a single IT and security person in a company of a hundred that only has Azure, I'll just use as an example, but any cloud tool would work. You could probably do this in a week, to be honest with you. Like it does not take that long.
If you have your devices already set, you've got an MDM. You may not be managing them perfectly and you've got the cloud stuff, you can turn on Azure Conditional Access, you can deploy certificates to those devices, off you go. It's when you get into those larger companies where I think the complexity and the tech debt tend to be big problems.
So the more on prem and office stuff you have, the harder it's going to be. The more distributed your developers are, if you are a developer shop. Makes it harder. So if you have different squads and I don't know, maybe some code on GCP and some in AWS and some are using Cloudflare workers or something.
That's three different platforms. And if you have Windows and Mac and Linux and all of these other things, now you've got three MDMs that you've got to support. And so you're ending up doing the same work like 20 times because of all of these different groups that you need to deal with.
And this may be spicy but I think that you need to bring those groups down. And so if you have 10 Linux users in your company do you really, do they really need to be using Linux? Can you just get rid of it? Because it's going to cause you a whole bunch of problems just supporting those 10 devices.
And so I do recommend as much as possible, simplify. And people will scream and shout and say, no, we need these things. Just look at it from a business perspective, do you need to test for Linux users? Maybe you build some software for Linux and Windows and Mac. Yeah, you probably do need those machines.
Maybe you can move them to the cloud and you can isolate them and have the sandbox isolated workloads. And that may be a better approach than supporting those devices. I think there's one more problem that I find. And again, I think it's a bit of a spicy one, but it's politics, of course. It depends on the company in question.
I would say in my experience in the past, I've had very little issues personally, but I have heard of teams having big problems. I don't want to call out network teams because I've led network teams. I have friends in network teams. I love my network teams, but I've heard of people having experiences where you're saying we VPN anymore.
We're going to use this other thing. And then they get protective because that's the thing they're managing today. And it's not like we're replacing the VPN and you don't have a job. It's, we're changing the way it works. You're going to have to maybe change how you operate. Like maybe you are managing less complex firewalls and on prem networks.
And you'll be moving to more like cloud agent support, more desktop stuff. If you've been doing. Networks for 20 years, maybe you don't want to do that or or whatnot. So I do think you need to bring those teams on board and get them in and get everyone aligned to the same goal where you're going to end up getting.
Bogged down in politics and people not doing what you need them to do and all of that stuff. And like I said, I think that's, yeah, I don't want to say that's more common in traditional companies, but the larger things are, the more distributed they are, the more likely you're going to have it.
Neal Dennis: Yeah, politics are great, ain't they? So that does bring to mind a wonderful question Elliot had on the primer sheet. I think this is a really good question. So normally I don't ask Elliot's questions on the primer sheets. I just go through them and if he likes them, he can come back to them. No, I'm kidding.
That, that makes it, so we talk about obviously implementation strategies, some of the hurdles there, like you just mentioned, people, person problems, stuff like that, tech stack stuff. By the way, you're not getting rid of my Linux, but you can try. The one thing here I think is neat to think about is the
Elliot: so. So
Neal Dennis: the awareness factor of when you think your company's ready for this.
And in reality, I think the answer is everyone's ready for it. They just need to realize it. But do you think there's some kind of key? Key elements within these companies you've been at before that were legitimate tippers for, Hey, let's, we need to be serious about this and go forth with this zero trust mentality, or were there opportunities there where you're like maybe not today, but give yourself six months because you do really need to have X, Y, and Z beforehand kind of stuff.
Yeah.
Kane Narrawway: Yeah that's a hard one, to be honest, like I, I do think that, you may occasionally come across something where you're like, we can't do this now, or it's not a priority. Now. I do think you should be quite critical on what those things are like just because someone says, you can't take away my Linux machines.
Don't just say, okay, then I'll whatever, I think you need to,
At it from a business perspective. And that's where leadership support comes in, right? If you have a head of engineering who knows the ins and outs of this, so maybe they could say Oh, we actually don't need that.
Like we can move that to, to AWS or something that can use VMs or something else. Then that's probably the approach you're going to take if you don't have leadership support and they're like, Oh no. We love our engineers, obviously, but maybe they're not willing to make those trade offs. You probably will struggle.
And that's where I see a lot of these people like start and then get bogged down halfway and they get bogged down in things like this. I do think that you can make trade offs though, right? I have seen people in the past just exclude certain devices from their Zero trust checks, for example. If you're coming from a macOS device, you need a certificate, you need to be on the latest version, you need to have antivirus and stuff. When it comes to something like Linux, you might say Okay we don't have an MDM, but maybe we can install certificates manually. Maybe the numbers are small enough. Maybe we can just have EDR in place, and that'll get us to 80 percent of where we need. At least we've got data on those machines. Then maybe we can't control the exact operating system versions, but we can at least see, we can report on it.
Like I say, I think. I wouldn't take this approach without a little pushback, but if there was significant pushback or there was good business reason to do this, then that's something I would consider.
Neal Dennis: So another quick curiosity question when we think about cost benefits, obviously we know, we all agree, cost benefit analysis is ridiculously, your ROI on this involvement and effort is always on the plus side when done appropriately. However, comment, when you've gone in and you've looked at current security stacks in dollars, and you've looked at what you're having to either rip and replace, update, change, manage, add to, are you looking at a net.
Increase of a substantial portion for implementation sometimes, or are you looking at a wash and to your point, you already mentioned that, if you're in certain cloud solutions, it's probably a flick of a button in some cases today, right? And not necessarily cost. It's just you changing a little bit how you do business.
But in the grand scheme of things, when you go through these process flows, is it a net wash? Is it typically a little bit more on the cost center side of the house as a whole? Or are we able to sometimes maybe even save a buck or two because we're implementing better for you? Tooling and streamlining that tooling to more effect.
Kane Narrawway: Yeah it's honestly going to depend on the company and stuff like that, right? I do think these things tend to cost a little more compared to your existing tooling that you have in place. it cost more when you factor in incidents that you're having and things like that and the cost of the people and the response and the time?
Hard to verify this. It's going to depend on all sorts of things. But I would probably argue that you should try and do that as best you can. And I'll go into a very key example, I think. So when it comes to Zero Trust. This is simplifying it a bit, but we tend to think of identity devices and SAS, I think, or apps, I would say for people who have network stuff, maybe network would be its own pillar for those.
going to
Identity is I don't want to call one out as my favorite or most important, but it's identity. Like when you look at most breaches that happen in real life that have caused stuff, it's stuff like phishing, it's credential stuffing. It's identity based attacks, right? And so I do think when you are building your MVP, identity should be the first thing you do and then everything else.
And identity and identity and SaaS and networks are tied together because you need to prevent access to these things using the identity. But it is something where I think that it is worth the investment. And like I say to dive a bit deeper Something like YubiKeys.
If you can roll out YubiKeys or security keys in general that's going to cost you a lot of money. Like they cost depends on the type, but anywhere between 20 and 60 bucks per person. And then you're going to have breakages. You're going to have contractors that maybe only have them for a while before they send them back and stuff.
It's going to add some overhead to IT to send these out and whatnot. But it's going to just almost entirely stop phishing in, in your enterprise. So is that cost worth the trade off for you? Like how many incidents have you had in the past year, two years, three years that have been a result of this?
And could also start thinking then about our detection and response team have been dealing with all of this stuff and they've been building alerts in Nocta and Microsoft for phishing and. All of this kind of stuff, they can now maybe focus their efforts on detecting malware and other stuff.
And then you're getting more value out of that team because they no longer have to worry about this stuff as much. Of course, there's still going to be a few things, but it's not going to be as critical.
Neal Dennis: That makes sense. I, I'm not going to lie. I know YubiKey helps obviously with the phishing piece, but because of my background, my response to helping that poor employee who's clicking yes, no, maybe, and all the email crap that comes in is to get them an orchestration device. But the hilarity being the cost of that tool, depending on the scale of your organization is probably about the same as what it would be depending on how large, like if you're in a couple of thousand.
Employee based orchestration tool just to help do that one thing is probably going to cost the same as if you did put up YubiKeys for everybody.
Kane Narrawway: You can do passkeys as well today on mobile, and they aren't as good as These single device pass keys like, like security keys, there's still ways they can be compromised. Like you can compromise the one password account or the Google account that those keys are stored in, but they're better than push.
They're better than authentication apps. They're certainly better than SMS and call. And so. That's something you might also want to consider because that's much easier, much cheaper to implement than buying a 60 security key for every single person in the company.
Neal Dennis: Oh, he knows a guy though. He can get him on discount. Now, I would love to see a completely FIDO compliant only environment in that same sense. Talking about GovSpace and tokenized accesses and things like that. Yeah. There's Elliot with his YubiKey. Uh. Coming from the government side, I think it's fun to talk about this in the private sector when not saying that the government here in the States got it right in the 90s, early 2000s, but the concepts that we're playing with today, even though they're being defined as what they are, like a PKI and your CAC, we had chip enabled physical security card, right?
And then you had an RSA token on top of that, that you walked around with every time you were in a security environment. So you had two out of the three. Right off the bat that you needed for authentication. Good luck. And when they implemented the CAC procedures alone, they implemented that like YubiKey.
They implemented that because of phishing issues and nail fording issues, all this other fun stuff. And then things tanked overnight when they went global with that policy. That being said, so thinking about scale of economics, thinking about growth and cost benefit analysis, I think that, that's a really good take.
I don't think we've really ever asked anybody kind of Their thoughts on the value props out right on this. We also have only had a couple of people that I think that have done this from a practical app perspective more than at one facility. There's a lot of people we've talked to that have done this and they've done really large journeys and they've done a couple of focus journeys, but we haven't had someone that's done it multiple times.
I think really, so it's neat perspective wise from you to go down that rabbit hole with this. I appreciate that. I've got maybe one more thought here, and it's back to the journey based perspective. When you're going down the rabbit holes from your side of the house, is Zero Trust a never ending journey?
Or is it a, in the sense of, I know we've got to update things, stuff obviously has to update, you got to do routine stuff, but is it really a never ending journey where once you set this three year plan, it's really a 20 year plan until you quit the company or die? Or is it a can you truly, have an end state where it is more maintenance than implementation at some point in your livelihood?
Yeah,
Kane Narrawway: It's a really good question. I don't think it's been around long enough for anyone to really truly say we're done, we've got this in the bag. Like every system I've built in the past, like I still speak to the old teams. They are still carrying on with improvements and things like that, like there is always more to do, but I think when you look at it, a lot of it would probably just be like new technology that needs to come in and stuff like that.
We're giving everyone Chromebooks now, and so we need to support that. And so that's another thing that we have to build out, or we've got new apps coming in constantly, but I do think that you will probably have an initial sprint. And then you'll get to the place that you need to be, and then you'll maybe reduce your headcount by, I don't know, anywhere between 10 and 50%, and then you'll roll into a more maintenance mode.
I do find that kind of sad, almost, in a way. I do find that sort of Zero Trust, if I was to like I say, slice and dice it, you've got your really basic policy based decisions where you're saying, you Is this user one of our corporate devices? Do they have the latest version? Etc.
And then going beyond that, there's this idea of contextual access and thinking more about all the data in all the systems that we have these days. So you can say, Elliot has absolutely never gone an access snowflake in his life, and now suddenly he's in there every day downloading all of our data.
Maybe that's a bad thing and he shouldn't have access. Of course, that's beyond making sure people only have access to do the things they need. But there's certainly some interesting things from like a customer perspective as well. So thinking like maybe I'm a support engineer and I support customer A and B, but then suddenly I go and access C's data using like an emergency token or something, because someone was out was that verified?
And so I think that. That's probably where we're going now. I feel like that's definitely buzzwordy. Just saying yeah, we're going to use data to make it better. But that is what I see a lot of people working on today. And I find that the sort of the return on investment when you get into that is maybe lower.
You're getting more into detections and alerting more so than prevention. But, I don't think anyone apart from maybe. Google and a few others have really started looking into that stuff. And actually there's one other thing where for the people who do have networks, like I say, we don't really truly have zero trust yet, right?
Because you still have a segmented network where there's some inherent access and you just try and make these as small as you can. The idea of having a one to one device to connection mapping rather than having these micro segmentations could be interesting. Google have been working on something in that.
They released a. Another white paper in their BeyondCorp series, I think last year or maybe the year before. Really interesting, worth taking a read, seeing what they're doing. I would love to see the network vendors start thinking about it this way. But they are not financially motivated, let's say, to do something like that, I think.
So I think it'll probably be a startup or something that, that starts thinking about that.
Neal Dennis: that makes sense. Can't just jump on the Eagle and ride it all the way to Mount Doom. Easy things to do. No, that, no, I appreciate it. That's solid insight. So I think the one last piece for me in this, for my brain at the moment, and then I'll maybe throw it back over to Elliot. From an adoption perspective, getting started, just, kind of fair reminders for everyone.
Don't, we're not necessarily saying don't waste your time on a three year plan. We're also not saying wait for the three year plan to be finalized to start on what you could be doing today, Impact. Everybody's journey is obviously a little different. Everybody's got to find a place to start. And then at the end of the day, just try to figure out what chunks you can bite off of now to show some kind of benefit.
And to your point, focusing on the identity access piece, I think that's a really good call out. I think those are typically easier wins to figure out, who and what's logging into what, why, and then set up your policies around that. But on the, you alluded to this a minute ago, enterprise versus SAS side of the house.
And. One last quick question to grow on that from an enterprise modeling perspective, in house on prem difficulties versus SAS based solutioning in your mind. What is there an echelons of difficulty or should, grant it's going to be similar policy and procedures, but implementation and impact. Do you see that being more difficult left, right of that vertical as a whole?
I'm asking a lot of Elliot questions today. I might, I didn't even look at that document for more than 30 seconds. I know this is a question on that document. I'm very proud of myself right now. If that is a brain, I drank my brain juice this morning, but yeah, I, so left, right at the vertical back on point, the road goes on non, but when you're looking at it, enterprise versus SAS implementing either side of the vertical, is it easier to control your SAS stuff versus the stuff that's on the enterprise layer?
Kane Narrawway: Yeah, just start with Sass, is what I'll say. If you have both, just start with Sass and like going MVP as well.
You know, you've probably got really sensitive stuff on prem, especially if you're a bank, you're probably talking mainframes that, I don't know, have the Excel spreadsheets that keep our financial systems together on there or something.
But. It's just harder, right? And I think a lot of those systems are probably written in COBOL and all sorts of wild stuff. And I talked about this in my blog on like writing an MVP, but you've got a few different approaches. You can decide to like YOLO, all in on SAS, try and move to cloud.
Whether it's a lift and shift or a rebuild or whatever, it's like seeing how many services that you've got, how painful it would be to move them. Do you have the experience required? If you can't do that, just do sassy, right? Like just whack some sort of proxy in front of them. It'll get them into your zero trust stuff.
So you're at least doing checks. It's not perfect because like I said, there's still a network behind it, even if you don't want to think about that. And so someone could compromise. Something around there, but realistically what's going to happen is a device is going to get compromised with something like malware and then they're going to pivot in there instead.
As long as you're doing as good device checks as you can, somehow, that's fine. This'll hurt you speaking about this, actually, Elliot, but a previous place where I had a friend who worked I heard that essentially what they did, was they built Zero Trust for their SaaS stuff and then they kept the VPN for their on prem stuff and they just rebuilt all the same checks in there.
So they literally had the same certificate checks on the VPN, the same SaaS check or the same sort of device checks, all of that, and they just had their network off. And only 30 percent of the company or something needed to access anything on there. It's small. But it's less, right? It's not 100%.
VPN. And don't let perfection be the enemy, is what I'm saying I guess here.
Neal Dennis: That's all I got. And I guess one more little anecdote, the road goes ever on and on down from the door. And all that jazz. So get started, get moving, and do something productive. We did make a warning at the start of this episode, and I've only dropped twice. And that's what we get when we get someone in Kiwiland.
Elliot: You didn't think I was going to let it end there, right? Instead of the usual, I've got one big last question that could spin off into a 30 other directions. I want to be really annoying and cheesy. So okay, we're going to start with you. I've got one question. What is the name of Gandalf's horse?
And I can give you options if we need.
Neal Dennis: can tell you exactly
Elliot: Yeah, I know you know, but
Kane Narrawway: That is actually one that I don't know. Maybe if you give me a few options, I might be able to guess.
Elliot: I'd look through like 30 of like questions like yeah, you can figure it out All right, Mr. Oats Lil Jimbo Knight Rider or Shadowfax. Is
Neal Dennis: Oh,
Kane Narrawway: It's Shadowfax, I think, right?
Elliot: that right, Neil?
Neal Dennis: that is very accurate. Lord of all horses.
Kane Narrawway: It was, it was down there somewhere in the back of the
Neal Dennis: And just to be politically correct here, he is not Gandalf's horse. Shadowfax allows Gandalf to partake in his presence. Shadow Facts is officially owned by no man or Meyer or Ishtari. So anyway, there we go.
Kane Narrawway: I
Neal Dennis: right back.
Kane Narrawway: this is totally off topic, but I recently went to the Weddell Workshop here in Auckland. It's the people who built a lot of the designs and stuff behind the movies. And at the end of it, there's like the typical shop, right? And usually I just walk through and I don't care at all. But there it was.
It was a huge one of, like a huge replica of Sauron's mace and it was like 700 bucks or something like that and it was huge and I was like, Ah, it'd be great to have that on the wall, wouldn't it,
Neal Dennis: yeah. Yeah, it would. Oh
Kane Narrawway: Home defence as well, it's a dual use. Yeah.
Elliot: that have also built them because last Halloween, I went to Sauron, I had a drywall stilts and a one, which also was a terrible idea. And I also ran like 80 miles the day before it. So I was trying to not tonight, I got it right over there. I'm not going to reach over and grab it since mostly everyone listens, but I don't know, I got some dude to build like a really cool Sauron out of some foam core.
Yeah, so just saying there's some pretty good replicas of the mace on Etsy. Probably 500, 700 bucks though.
Neal Dennis: love it. And for those actually still listening at this point in the record, while the movies and what Peter Jackson did are phenomenal and should never be remade for what they were, the books are obviously always better. Yeah, we'll leave it at that, but.
Elliot: I don't know. Hold on. I'm going to pick a scab. What are your thoughts on the Amazon version?
Neal Dennis: that can I cannot use the words
Elliot: Got it. All right.
Neal Dennis: it here.
Kane Narrawway: Let's finish there before
Neal Dennis: mostly PG.
Elliot: They spent a lot of money and it looks pretty. I'll leave it there. But with that means we are at the end of this episode. I have taken us off track, unlike But that's your role, Neal. So Cain, thank you so much for being here. We really appreciate your perspective. I also will recommend if you all do not follow Cain on LinkedIn, that is where I ran into his post about Zero Trust MVPs, and he attends to share some pretty smart and intelligent things that I think a lot of us can grow and learn from, so go stalk him on there, follow him, whatever.
But there's some good stuff there, point in that direction. Anyways, that said, can't thank you again. We really appreciate you being here. Help us walk through this. This is a perspective and a area of focus we just haven't covered before. So it is always really neat to be able to see that there's just a million different ways to pull this conversation apart.
Kane Narrawway: Absolutely. Thanks for having me. It's been great.
Neal Dennis: Thank you, sir.
Canva's Kane Narraway on Building a Zero Trust MVP