Loading summary
Transcript36 lines
- [00:03]
A
Hello everyone, this is Tom Uren. I'm here with a Risky Business News sponsor interview. Today I have with me Fletcher Heisler of Authentic. G' day Fletcher, how are you?
- [00:12]
B
Very well, thanks, Tom.
- [00:14]
A
Authentic maintains an open source RDP called Authentic. And you sell the sort of commercial value added proposition, but people can just go take Authentic and use them for free. Is that the.
- [00:27]
B
Yeah. So Authentic started as an open source project almost seven years ago. Past few years we've stood up Authentic Security, the public benefit company behind Authentic. And so we're maintaining that, but also building on that with an enterprise version that has all of the integrations and compliance, bells and whistles and so forth that a big company might need as well.
- [00:48]
C
Right.
- [00:48]
A
So one of the things I've been wondering about, Fletcher, is every now and then there'll be some big significant cybersecurity incident and it'll turn out that they've been backing up something like Active Directory in a way that in retrospect looks kind of insane. So the most recent event I'm aware of was Aeroflot. Aeroflot got hacked. It had quite a significant disruption for a while, a few days at least. And the story I heard, which is unconfirmed, is that they just had two servers that were backing up to each other. But at the other extreme there was Maersk who was hit, the logistics company who was, was hit back in, I think it was 2015 or something like that. And they had 140 servers that were backing up to each other. And you can sort of see that two doesn't seem enough. 140 before you were struck by a self replicating worm, you could go, yeah, that seems like a reasonable strategy. So if you had gone into a company like Maersk or Aeroflot, for example, what would your advice be about backing up and failover and strategies to deal with that?
- [01:59]
B
Yeah, So I don't know all the details of Maersk. And you know what the 140 servers were doing. I imagine they're at least geographically spread out, but you have to.
- [02:09]
A
Yeah. So the story is famously the worm wiped out all but one, which was in Africa, and it was saved because there was a power outage. So it wasn't online at the time.
- [02:20]
B
Happened to not be connected at the time. Right, yeah, yeah. So you kind of have to think, think about the potential risks and diversify your options there based on what might possibly happen as the most catastrophic outcome. True of an identity provider, true of any other critical infrastructure for a business. I think we've Seen this, the more common, maybe less phenomenal use case is just a SaaS provider for identity or anything else that goes down and then your employees can't access any of their applications or whatever else. Maybe it's data loss or something like that. And so companies have started saying maybe we need multiple idps or maybe we need some other sort of backup strategy. Now we need orchestration layers to make sure that those things synchronize with each other and inevitably you kind of end up with single point of failure still or you're relying on some third party and kind of hope that it works.
- [03:19]
C
Right, right.
- [03:20]
A
I guess from a SaaS provider we'll have some sort of SL, right. Where they say 99 point, whatever. In my experience those are always optimistic. And it still means several hours of downtime every year, which I guess you've got to figure out is that acceptable or not?
- [03:39]
B
Yeah. Is it acceptable if none of our employees can get to anything for an hour or two every year? That's a high nines uptime, right?
- [03:47]
A
Yeah.
- [03:47]
B
And that's also kind of uptime versus reliability. What if service is degraded? You can technically use it, but you know, practically speaking maybe not so much. So what we've seen is, you know, someone using authentic on PREM plus in the private cloud or even across multiple cloud providers. You know, we have these, the kind of concentration and hyperscaler risk as well of well, AWS went down, you know, maybe even we had some cross region set up. But now something feels like it's, you know, if it's not our fault. But that still means we can't get our work done right. So we've had folks on the healthcare side like we work with a 911 center, you know, in the state of Washington who has six or seven different ISPs, so they have lots of different service providers for the Internet. But if Internet goes out entirely, they can't use an idp, you know, IM as a service over Internet. Literally things are on fire. They need to still have identity and so they're using that strictly on prem as well as those backups to say regardless of the scenario, we have backup access and even if we don't have Internet at all, we can still access our systems. So depends on the scenario. But I think it's also kind of being able to switch over to a completely different architecture or location or whatever that looks like if you're looking for that sort of ultimate resiliency in your infrastructure.
- [05:23]
C
Right, right.
- [05:24]
A
I guess you raise an interesting point in that there's all these dependencies everywhere on different service providers. And I suppose the argument would be that an IDP is so fundamental that that's one of the ones you should have a backup strategy for first. Is that the way you would think about it?
- [05:44]
B
I would think so. If you can't access anything or do anything as an organization without your idp, which is really the gateway to access of all your other applications and what else is there? The best alternative is maybe sort of a fail open scenario, which is certainly not the secure solution to just say now let's turn off sso.
- [06:07]
A
Right.
- [06:08]
B
But yeah, it's kind of fascinating to me how often folks are willing to say this is a single point of failure and we'll just hope that it keeps running.
- [06:17]
C
Right.
- [06:18]
A
It's interesting to me from a business risk management perspective that if AWS or Google Cloud or Azure falls over as a manager, you can say, well, the rest of the world is also in trouble. It's not unique to me, it's not my problem. But if my IDP falls over and I don't have a backup problem problem, that's on me. That feels like something on a risk matrix that directly you're responsible rather than you can wash your hands.
- [06:49]
B
Yeah, yeah. It's that sort of trade off to make. I think even just from a business perspective though, like we're very aware that an IDP is sticky, it's tough to manage that migration and so forth and so that's good and bad. But if you're IDP triples your cost all of a sudden now what? You can't just turn it off. So being able to have multiple options available to you is very important.
- [07:16]
C
Right.
- [07:17]
A
I guess your pitch would be that Authentic's a reasonable cost way of getting that redundancy regardless of who else you're using.
- [07:26]
B
Yeah, well, with everything being source available, the vast majority of it being open source, we have some folks say we're a smaller company, we haven't been around as long. What if we just disappear or pricing changes or something like that? That's just as likely, if not much more likely to happen with a legacy or larger IAM as a service provider. But the nice part with Authentic is you can just keep running it, the code is yours, you're not relying on us. The vast majority of cases, obviously we have lots of customers receiving support and so forth, but they can just keep running Authentic. So having that fail safe built in is also a nice way of de risking the process.
- [08:12]
C
Right, right.
- [08:13]
A
And so people, when they come to you Is it because they've been burnt in some sort of recent incident? I would have thought that this is one of those things that you don't think about until it happens. For a lot of people. Yeah.
- [08:27]
B
I think a lot of the time it's sort of the slow burn of we're spending more and more engineering hours and more and more dollars on something to kind of get the last mile of functionality out of there and. Or some of that reliability concern of we don't have any power over how this product operates at the sort of even just individual feature level where you can much more easily customize things with an authentic build. The math right the first time, automate everything entirely. It's all built as infrastructure, as code. You have access to all the APIs, so you really own it. You can have that full access instead of. I think a lot of folks at scale start hitting the walls of functionality or lack thereof of another system.
- [09:15]
C
Right.
- [09:16]
A
I. This is making me wonder about if we're kind of hitting the limits of cloud services in the sense that the promise I suppose was that you could chuck away all your on prem stuff and that you would just have cloud based services and that would be good enough. But now you're really saying that, well, cloud based services are great, but if you want to have true resilience or failover or backup, then you probably need an on site thing as well. Is that the, how strong are you about that?
- [09:48]
B
You know, we're, we haven't discounted the idea of offering our own versions of, you know, cloud based or managed host and things like that. But really the inbound demand has been so strong for folks saying no, this is very fundamental to, to what we do. And for a lot of companies it's also, you know, we run within AWS or whatever, you know, their infrastructure looks like. Being able to run containers that use all of the same tooling is a lot easier to integrate with than a black box SaaS solution that you don't actually have full access to. You can't actually automate fully things like that. So there is that initial. Yes, you have to stand up a container in a database that we make as easy as possible. But beyond that first step, you actually have sort of total cost of ownership and maintenance can be a lot lower because it is yours to do with as you need to rather than kind of having to duct tape on top continuously.
- [10:49]
C
Right.
- [10:49]
A
Okay. So I suppose the way I'm thinking about that is that if you're using someone else's solution, they'll change it as they see fit for their business. And so what you're saying is that with Authentic you change it as you see fit for your business?
- [11:08]
B
Yeah, I think the open source, source available and sort of community driven side is a big benefit there too. Okta got to where they are in the market by having a vast catalog of integrations. You can just plug it into all your applications. We still don't have a catalog as big as that, but I would say we get more and more teams saying this isn't using all the newest attributes or there's some other signal that turned up here. When can you implement that? And they just have to wait on Okta to do so. Whereas within Authentic, we can much more rapidly develop those individual integrations with our customers and then they can customize them further. They don't have to wait on anything. So whatever data you need to map in or out of Authentic is entirely up to you. So we can work with them in cases of deeper technical integration very quickly. I like to bring up workday as an example that it's a bit of a behemoth. We didn't previously a customer asked, we had one ready in a week and a half an integration there. So being able to turn that over very quickly and then also allow the customer to not even have to wait for us just to say here's a new signal that got added. Let's add that to our data attributes is a much more powerful and sustainable way of keeping up with the tight of applications.
- [12:33]
A
That's very interesting, Fletcher. Fletcher Heisler, CEO of Authentic, thank you very much.
- [12:39]
B
Thanks so much, Tom. Thanks for having me.