#377 - Sponsor Spotlight - Hush Security

This is identity at the center. Welcome to the Identity at the Center podcast. I'm Jeff, and that's Jim. Hey, Jim. Hey, Jeff, how are you? Oh, not so bad yourself. Doing great, You know, every once in a while we get a company that is perfectly game for our space. And today is that day on the Identity at the Center podcast. Yeah, we've got a sponsored episode today. So these are things that we do from time to time with our friends in the industry.

Today we've got Hush Security. They are just coming out of stealth, I believe is how we're kind of looking at this. And we're going to talk with Mika Rabe in a second. But to learn more information about them, you can visit hush dot security slash IDAC. So let's get Mika on here. So Mika Rabe, he is the Co founder and CEO at Hush Security. Welcome to the podcast. Hey, hi, guys. Thanks for having me. Yeah. Thanks for taking the time.

So this is the first time we've had an opportunity to talk with you on the podcast. So let's start with a little bit

with your background. How did you get into the identity and access management space? Well, my background, you know, we're going way, way back. I was, you know, a computer kid. You know, I was spend a lot of time with computers as a growing up. This was my passion for a very long time.

I did some work in this and of course studied in college computer science and electrical science and went into the industry, you know, right then I've done a lot of development roles in my career and then finally moved to product management around 2010, did some virtualization stuff, some cybersecurity, and eventually I kind of landed with a very, you know, unique team. Somewhere around the late 2016, there's a company called Meta Networks and I met a lot of

great peers. We did a very good run with the company. We kind of pioneered ZDMA, so zero trust network access before that term kind of went popular before SSC and Sassy which later came from Gautner. We had a very good run and the company was acquired three years after. And when we got acquired, we, we were, we had a very good hygiene around security and very good

security by design nature. But the Infosec, the company that, that kind of acquired us, wanted us to rotate a lot about your keys and basically every, every key that we have around 2 times or three times to live. And the problem is that, that even if you have a very good, you know, infrastructure with code and automation and, and hygiene around it, what I think is, is always a very, very big problem.

And it always kind of get pushed to the last Friday of the last week of the last month with the last quarter that you're actually allowed to do so. And then you spend the night doing that and hoping that everything kind of went well because there was no tooling around that to make sure that

you know you're doing it. Correctly. And so when we kind of thought about moving out again, the same team and the same people, this was one of the biggest problem that was still resonating, you know, kind of sitting as a chip on our shoulder from the last interaction. And we said, OK, this needs to be addressed.

And so we kind of looked at what other, you know, vendors and startups and incumbents were doing in the field and we didn't find any good solution that can give you the governance and the visibility and basically the operability that this fields deserve. So I love the idea of hope and prayer and wishes as a strategy strategy when it comes to rotating keys. Everybody seems to fall into

that trap at some point. So he kind of mentioned how, you know, Posh kind of positions itself a little bit. How did you come up with the name of the company? So as as we deal with identity and basically with secrets, and so Hush was kind of a fun on, you know, where they didn't we we're well making the secrets go away. So kind of a, you know, Hush, it's a, it's a kind of a playful way of talking about it took us a while to get there, but we were very happy when we struck that one.

And most importantly, the URL was available right? So Hush Talk Security is a great URL to have. Available for the right place, obviously, but yes. So I, I think I mentioned, you know, early on that you guys are just kind of coming out of self. I get that right, Because I, I think you guys are a little bit relatively new to the scene. Maybe it's not kind of right away, but tell me a little bit

about that journey coming. You know, I guess coming out to the public and saying, hey, here we are and here's what we do. Yes. So we've been working, you know, for for a year now on this product which is destructive. I think it's very unique in the industry that hasn't been a platform that that or solution that is doing what hash is doing. And so we were excited the bit to keep it the secret at the beginning.

But then later on we will really wanted to kind of brag and tell the industry and the world what we're doing and that there is a way to do things differently, which actually makes security people happy and operation people happy, which is very rarely the case. And so, yeah, we did come up out of sales, launched a product and the company a week ago, a lot of fun, fair. And that we're, you know, happy and excited for the next, the next chapter, you know?

So Mika, we hear that term stealth all the time. Can you kind of explain to me what, what it meant to be yourself? Does that mean that, you know, you guys didn't have customers that you're working with or like you're building the product? How does that What does stealth mean? It means a lot of thing, but but for us, it means that we wouldn't, we didn't want to tell yet what we're doing and the way, the novel way that we

approach things. So we first of all, we did the, you know, a patent, we're still have a patent pending for the way that we address identity for machines. And then we kind of there was a lot of competition in the space

and a lot of them are kind of in, in my mind, they are kind of missing the target. They are doing a very tactical thing, a very short sighted thing that that can help in the short term. But but you know, thinking about how to reduce the technical debt and how to go into a better approach. And this is something no one has done yet. And so we kind of wanted to keep that, you know, hushed for, for some time.

And then once the product is ready to go out with, with a ban in the meantime, that doesn't mean that we can acquire customer. We do have for paying customer and, and several more, you know, and, and our pipelines. And now we can actually expand, you know, the, the, the, the go to market. And this is exactly what this launch is about. Oh yeah, I'm biased, but this is a great way to to launch anything.

It's coming out of the podcast, so you know, you'll have thousands of people that are kind of tuned in for this. I'm going to put my jaded CSO hat on here. And you mentioned the competition. You know, there's a lot of products in the IM space and you know, the the hard question that I always like to ask is, So what makes you guys special? Like what is it that you think that's hush apart from others that are looking to approach, you know, the same or maybe similar problems in the space?

So I think first of all, most out of vendors addresses visibility only, right. And so this is very important definitely for seesaws in a lot of in a lot of companies. They want to understand 1st and see where the problem is, where where the bodies are buried, so to speak. And but then the next part of that is that you actually need to a mediate that. So if your solution you know is the one that opens 500 GLT because this is not what seesaws

are are actually looking for. So the first thing that sets us apart is that we are looking for remediation or prevention of those problems, right. Not only to show them we do have a comprehensive way of, of discoverable and visibility, but what we are looking for strategically is to change the way that things are done and to help our customers basically

avoid those problems, right? You can think, you know, other companies have done that in the past, for example, you know, crowd Psych and Sentinel one developing an EDR writing, then building a better antivirus, right? So a jump or you know, just shifting the way that that the solution is being done can, can yield much better result.

And I think strategically, this is exactly what Tash is going to do. The other side, the other part of the vendors that that we are actually competing against is, is in a way the votes provided right The the one that actually was safeguarding the secrets up until now. But the secrets have have grown in such a scale that votes are not keeping up with that pace. The era where static secrets where you know, fuel and and and the rotations were, were were

very far about are long gone. And with the scandal we have

today, definitely with the Gente kind of coming in and tearing through the roof of that, we need a better solution and one that addresses the scale and is future proof. Yeah, I mean, I'm, I'm glad you brought that part up about the vaults. I mean, like I said in the intro, I love the name Hush Security.

And when I first heard about it and that you guys are taking on secretless access management, I thought this is totally like in that space of managing secrets faults or getting a new twist on it. But I also thought this sounds like a play on non human identities. And I'm wondering if those kind of get confounded what you guys are doing with the secretless access management and non human identities. And if they do get confounded, what is the difference between those two?

It's a good question. I think the term non human identities is kind of somewhat abstract and and a little confusing. But the idea behind it is basically static keys that machines use when they authenticate or create trust with other machines, right? And so every time in one machine needs to talk to another, definitely if it's not in the same, you know, namespace or even in the same data centre or physically or virtually, it needs to establish some kind of trust.

And this trust, there are many ways to do that, typically an API key or or a certificate or a username, password and so forth. So I think the term NHI kind of refers in to to all of those, but there is a confusing element to it because because it talks about identities and well as well and secrets are not always identities. Sometimes there is the identity of the machine, which is one thing and then there is a

secret, which is another. So I'm a little bit resenting that that that term, but it's accepted in the industry. And for me it talks about basically legacy static keys enabling machine to talk to another machine. Yeah, I definitely hope I didn't offend you with that comparison. But you know, I think, yeah, I think the non human identities is a good umbrella term. It incorporates a lot of things.

That's kind of what I'm trying to get at, which is what is the problem that your clients are trying to solve. And I'm wondering, you know, with that description, are there certain types of clients that use this? So in other words, organizations do a lot of custom development? Or can you use this with pre packaged software as well? Basically, there are a lot of approaches that you can take in order to, you know, improve your posture with regard to non human

identities. But there is there are no good tools that takes you all the way. So there are kind of the separate places where you can kind of improve a certain element of what you do. But up until now, there are no tools to do it. The vaults, you know, themselves, they become a little

smarter over time. So they can do some more thing. They can give you more auditability and so forth. The NHI, you know, visibility has become a little better. It's not perfect yet, but but it is getting, getting there. But eventually the, the work to actually in, in the case of legacy stuff, right? So where you can, you need to go

into a better solution. For example, when you walk in a cloud native environment like let's say AWS, you're using ILM words, you're using policy to manage access and trust between machine. And that works great. It has been working for I think more than a decade in the same way. But when you're getting outside of AWS, right, you have the workload in AWS that needs to talk to a SAS, for example, that system doesn't apply anymore.

And so you're stuck with this kind of legacy way of, of doing it. And today there are no, there are no good tools that can help you do that with breaking without breaking the legacy world. I think there has been several attempts to do so. For example, Spiffy is one of the standards that is trying to, to, to kind of make a, a revolution here. But I believe that Spiffy is not yet is that a big is, is that

backed by enough? Sorry, it's not backed by yet enough big players in the ecosystem and there is not enough momentum behind it. And so if someone can take the the elements of Spiffy and the principle of it and apply it in a way that doesn't break your, your code and your and your business, then I think this is exactly what what we're trying to build and what needs to be built.

It's interesting because a lot of what you're saying and Spiffy's, you know, I think back to our episode with Felix Catons and he just came on to talk a lot about different approaches for machine identities in the authentication space and Spiffy and that's kind of a cross cloud platform, whereas what you have is a lot of proprietary solutions. Think that Google's solution for vaulting is based on Spiffy, but for the most part it's proprietary solutions.

You guys are approaching it differently and you're also taking on the on premise to software as a service, which I think is should be kind of clear to everybody. Like that's a problem that, you know, how are you solving it today, right? Unless you're kind of building your own solution, it's pretty hard to solve. So I'm, I'm kind of thinking that I might have answered my own question from the next question, but it's why is this hitting now? Why are people trying to solve

this problem now? I mean, it seems like the problem's been around forever, right? So why is it coming home to roost? Yeah, I think it's, it's an excellent question.

We've been using, you know, API keys and and secrets and NHI basically since then. The invention of software in a in a way the issue with that is that when we used to work in monolithic, you know, on Prem that was manageable. It was very few of those because all the software was kind of packed and neatly together and trust between those companies

were inferred or or assume. But as we kind of transform to the cloud, right and and if now software is physically and virtually in different places in the world, now you need to establish trust between them. And so we needed a lot more of those NH is and if you take into consideration that after that came the infrastructure is called in the automation kind of revolution, then all of those are scripts and and tools that needs more, even more of those keying and, and artefacts.

And so it kind of grew dramatically back then. And now as as we discussed before, we are entering the the agentic area and agentic by definition need a lot of very, very wide access into everything SAS as your, your data centre, your cloud and so forth. And so we are on the verge of another very, very big surge. Interesting.

And I think This is why now is the time that companies and vendors and analysts are kind of saying, OK, this is, you know, it's going to break very, very soon if it hasn't broken already. And look, for example, just what happened with this sales loft drift incident that happened just a few weeks ago. The company was able to exfiltrate sales, loft AWS account and from there they're extracted O OS, which is basically another type of NHI is a is a is a kind of a static key.

And they stole seven hundreds of those from everyone in the industry. And I'm talking about, you know, Titans as well as small companies like Palo Alto and Cloudflare and and you know a lot, a lot of others, which has a very good security minded product. So you can say that, you know, this is something that like an oversight of something like that. It it's a proof that the architecture and the system is

completely broken, right? So that the proof is, is that someone broke all the the big security companies in the world and that means that the architecture is failing us. So we need to move into something that works a little bit. Yeah, Yeah. No. I mean, it's a great point that you're bringing up. Thinking from the practitioner's

perspective. I'm, I'm wondering, it almost sounds like the case is being made that obviously there's a transition period, but this being is the case that I won't need a separate secrets fault in the future. If I'm going down this hush route, do I eventually just

eliminate the secrets fault? I think that's a very good assumption, right? So as I said, look at look at what happened. I think it's a very it's a very good example and a very good metaphor. Look what happens in the human space, right? When I want to access Salesforce today, my company Salesforce when I 10 years ago, I used to go to the my admin, it would create a username and password for me in Salesforce.

He would send that to me, which is, you know, something that is risky because how do you send that through an e-mail, through an SMS, through whatever means that that's the first risk. And then it's my responsibility was to keep those username and password presumably in one of those password, you know, manager that we used to have like 1 pass or LastPass or and so forth. And hopefully that that is enough. But today the situation is

completely different. I when I want to access Salesforce, I'm asking my admin and it's putting forth a policy saying mija can access Salesforce. And the only thing I need to do is go to Salesforce and just log in with my IDP, whether it's Google or Octa or Ping or or Entra or Microsoft. And so this is exactly the, the kind of past we want to, we want to take the, the machine access

through. We want to write policies rather than deal with taking a key, sending out to engineering, putting that in a vault and pulling, pulling it out of the vault when we need it. So, yes, so, so in my vision, in my view of the world, when you're using a system similar to what we're developing, you don't need to vote anymore. We had Darren Rolls on the podcast recently and he talked about, you know, for, for the big incumbent firms, they're not

as motivated to innovate. I, I think what I'm hearing about from you is like true innovation potentially shaking up the industry. I think this story resonates really well with practitioners, architects. Technology leaders as they kind of understand, well, this is a game changer, don't get on board. It's a little bit of a different cell. As you move up the chain of command within organizations, you get to that C-Suite and you know, the people who all went to

the budget, if you will. So I think that's one of the things that with your perspective clients, you're really going to have to help make that case. And have you already thought through that problem? I mean, what is the business case that you coach your prospective clients through to make to people who are not the techies, who are not hands on and and love them to technology?

I think eventually the, the, the thing that resonate most well with those guys is, is the value that, that you bring to them, right? They will not do anything that doesn't hold a, a very good value for the company and for

the way they work. So if we're keen, if we can reduce the risk for them, reduce the labour that they need to do, reduce the, the, the, the cost of ownership for managing volts and for managing the processes around around the sea, managing access reviews and so many other things. If we can just reduce that and produce that in a very simple, automated and invisible way, I think this is where they're

going to buy it in, right? Because it will resonate because of the great values that that the product brings to the table. So it's one thing to get the executive buy in. Great, now I've got it. I was just saying work. You know, what's the, how does the platform go about identifying these machine accounts and setting up whatever it is, you know, if it's a graph database or some other thing, right. To say, OK, here's all the

accounts that exist. The environment, that's the visibility part of it. But how does this actually work? How do you go about collecting that information from someone's environment? Right. So we have multiple ways of doing that.

The first of which and then the most trivial one, one that is actually used by other vendors as well is that we we're basically connect to, with with AP is through to our customers infrastructure, to our code repositories, to our, to their success. We scan and we read everything that we can, the metadata about the the non human identities or the secrets and the keys that they have there. So we get that and that brings us the initial kind of a database or inventory of what we have.

That stage on it's own, it's mandatory part of the journey, but it's definitely not the last because first of all, there is a lot of noise around this or a lot of stuff that we scan that is not relevant for our customers. And then the the second thing is that if you read only the stuff that you know about, then by definition you are missing all the stuff that you don't know about, right?

And so to that end, we developed a set of, of runtime technology sensors very lightweight that we can deploy with our customers. And that gives us observability of every authentication and every interaction between machine that happens within the customer environment, whether it's cloud or on Prem and so

forth. And so that is the first step for us. It's first to understand that the world that the universe of the of any choice for the customer produce the report from that first of all, the comprehensive audit log and second of all, a posture for each one of them so the customers can address the critical stuff that they have. And this is for us only the beginning, because this will allow us to kind of transform this customer into a policy based approach.

So we take that, we do the mapping right, we do the baselining of everything that they have and then we can move that thing to a policy based approach where the customer only manages from this point and on only manages policies rather than secrets. So sounds like the end goal here is to get that inventory, whether it's on Prem or cloud, I'm assuming, and then turn to PBAC, right. Policy based access controls through that, Yeah. Are there other methods of access control that maybe apply

here? Can we use things like attributes? And I don't know if I wouldn't want to go role based, I would wish that my worst enemy. But, you know, help me how I guess how configurable or how flexible is the model to say, you know, policies are good for this, but maybe there are certain machine accounts or machine identities or whatever maybe that can't be managed that

way. Maybe it's a different way to manage it. So first of all, we address the identity and attestation of the identity very, very closely. We use Fifi as as the base of our attestation technology, right. So this is, you know, already proven in battle and has been widely used in internally as as we discussed before, but we use that as a way to attest the identity. So first of all, to check which, what is the machine, you know, and and this goes to a variety

of ways of doing attestation. But this problem is already solved by spiffy, which is which is great and it's already available. The second part of it is is to to pair through a policy to pair the right key for that identity. And on top of doing that we can also put some conditional access into it, right? So for example, is the machine compromised? We can take that information from other vendors like Cal Styke or Wiz or OCA.

So we know if that if that workload is coming from a machine that is OK green lighted or maybe the other way around is being compromised. We don't want to allow it to access acidic data. We can take other conditional access our rules like you know the time of day, the geography,

the IPS and so forth. And so we are kind of adding, we are, we are building a very strong identity and then adding some conditional access rules and then after that, you know, we've kind of elevated all of the all of the security several

notches up already. When we talk about the product itself, right, Hush, I think about machine identity management. It has a bunch of different components to it. There's the account life cycle, authentication, right, authorization, logging, kind of everything that goes along with it. Does this cover all of that or are there areas that you tend to focus on specifically or maybe doesn't matter depending on the

data you can get? I would assume right, maybe there's more data for a cloud platform versus maybe an on premise platform. Speak to me a little bit about when we talk about machine identity management, like what are the areas that we're specifically covering here? I think there's definitely differences between, you know, cloud, which is a lot more, more, more drain and structure than the and systematic than legacy system like Contra and V sphere and so forth. In the cloud.

And definitely in modern environment like Kubernetes, we've got a lot of information, a lot of attributes, a lot of identity hints that we can use and we leverage that. And, and that kind of tends to go down as you go into the, into the older stuff, right? And so if it's a virtual machine, then we use a different set of, of attributes. If it's going to on Prem and, and, and virtual machines that are there, you know, we have a different way of, of dealing

with that. So it, it gets better as the, as the, as the environment is more modern and we typically work a lot faster and better there. But we do support legacy environments as well. Yeah, in in to your questions about authentication and authorization and so forth. So we cover most of those layers in, in, in one way or another.

So first of all, authentication for sure, because we are the facilitator of authentication and we can also cover some aspects of authorization because we can provide different keys with different scopes for which one of those workloads. So we cover an aspect of that as well. Yeah, I'm sorry, there, there was another part of that question. I I missed it. No, I think you cover cover it all. I think it put us on a data, right. How, how much data can we get for this stuff?

And maybe that is, is, is that a minimum bar to be able to utilize a platform like this? Do I need a certain level of data for this to run or stand this run in like a simple vaulting format where you know as much as we, you know, dump down on it. Sometimes there is some value that we set in some sort of shared vault. So no, no, no minimum here, as long as we have one workload. It could be as simple as a script, you know, running in Bash or Python that is trying to access another machine.

We will see that and we will address that and we can control the way that it's done. We can govern that and we can give it, apply the right identity to it and the right secret. And if it's allowed, we will let it pass. Then it could be as as as

complex as a, you know, very complex environment with multiple clusters of Kubernetes and databases and interconnects on top of meshes, you know, like NTNS and so forth. Basically we are agnostic to that. At the end of the day, we are looking at very strong data identity of the corner and then at the service of trying to access and we find and match the right key to it if there if if it's allowed. Mika, I'm kind of wondering how your clients are to measure success.

In other words, how do they know that they're succeeding? And then, of course, how do they communicate that to the leaders of their organization that the money's being well spent? We're actually making progress. And what what is progress? What does progress look like? What does success look like? So first of all, visibility for the first time they have an entire view of all their environments and the way that secret is being consumed and used.

Basically success looks like lower, lower time to remediate less incident, full auditability and basically the ability to to, to create additional and new at scale the workload that are accessing and trusting addition other machines. So basically machine access, it's scale very, very easy compared to how it's done today, which is cumbersome, labor

intensive and and very risky. So continuing on with the the kind of the thread that Jeff was pulling on the how, how do I take of security and roll it out in my organization? Like where do people start? What is the the first building block and then where do they take it from there? Are you, I used to say to the customers that when you have the right people in the room, then it's very easy to do it right.

You need the the guys with the permission to, to the infrastructure, to the sauces that you have. And if you have all those guys, you know, lined up, which is sometimes hard to do in very big enterprises, then it's very easy. You can connect whatever we do the the connector that we have to your SAS, to your IS, to your infrastructure, to your databases and we start scanning everything minutes after that. You already have very good

results. So the initial, the initial scanning then to deploy the the London technology, again, it kind of depends on the environment. And basically you're deploying a sensor. So it's very easy in some environment like Kubernetes in, in other environments like Z, NS or compute, there is a different approach to that. A lot of ways to do it, some of them is some of them a little, a little less.

And then once you do that, once you deploy everything, then you start seeing the real, the real picture kind of taking place. And this is very dependent on the size of your, of your operation, right? And so for example, if there's an authentication event that happens only once a month because you're rendering like a digest, monthly digest, then you need to wait for that for that monthly event to occur.

But all the other stuff, millions of other authentication event that's happening every minute, you will start seeing those right away. And that that would be the initial start of of this of the process where you see the report and you see the posture and everything that you need to know from the discovery phase. And then on top of that moving into into the ponces and just there is nothing else to do

after that. It's basically to sit and wait for any unders to come your way, seeing that someone is is actually doing something that they shouldn't. Let's pick on that a little bit. So you you use a very interesting word to me, which is scanning. So you're scanning the environment. When you're scanning the environment, what are you looking for? I'm looking basically for every machine that is talking to another machine and within that, what secret is being used when they talk, right?

And so, so basically we're, we, it's a combination of scanning and monitoring. We do some agent scanning. So we scan your code base, for example, your Git repository, right? So we want to know if you put any hard coded secret there. So this is scanning domes, scanning your collaboration up like JIRA and Teams and Slack and so forth. But we also monitor and observe. So that's the runtime part of what we do. We look at every authentication event that happens.

We, we look at the identity of the caller. We do, we look at the identity of the of the service that they are calling and we are taking the the map of everything that happens basically around that happening that with the metadata coming from the from the engine test scanning, we get a very,

very distilled inventory. We don't the right information in it. That's very interesting. So I can, I can totally get what you're saying now with visibility and you have a good picture of what's going on and you start to identify where you have weaker controls from an identity and access perspective. Now you can report on that. What else can you do? Like eventually that the practitioner has to go about remediating that, right? So what's the approach then? Is that like the next level

within the Hush platform? Yeah. So, so some, some of our customers, they only interested in the discovery pump, right? Some say, so they say, I just want to know where I am. I want to make sure there are no risks. So if there are, I want to remediate them. But my argument, and I think Felix made, made a very similar argument when you, when it was on your podcast, is that using those kind of of, of keys and, and NH is this is the wrong way because of the, of the scale of

where they are today. Just trying to chase and remediate the stuff that you have is just is, is not scalable. And it, and it, it, it's definitely not a way to build a complex environment like today. And so we do have that part as well. And we give that in where some of our customers, you know, this is where they are. But what, what hash is really doing and how we really want to change the way that that software is being done is that we want to move you away from,

from needing to remediate that. Because once you don't use NHI or static keys anymore, you just use policies, then everything, all the risks attached to those NH is, is going away with it. And that is the narrative, that is the vision that that we are bringing to the market and to the industry. And I think there's 11 sentence that Felix said that that kind of strucks me very well. It was kind of funny. It said friends don't let friends use NHIS, right?

Like this is this is not the way you want to go. You need to, you need to move, you know, the way that you think about software and the way that you that you manage access. Yeah, normally I book our guests, but Death hit a Grand Slam with getting Felix on the podcast, and that's definitely

one that got a lot of attention. You know, with all that said, you know, the visibility, it does seem like look, I mean, I get to see so perspective of, you know, just to make visibility because I think it's very hard to solve a problem when you don't know what the problem is. But then you've got this next level of actually remediating

problem. Going back to my earlier questions about like how do we communicate our success in the organization given those factors, given all that, can we attach, you know, metrics to any of that? Can we set long term goals and then show progress towards those in terms of like OK, Rs and things like that?

Seems to me like that's goals and objectives and, and hitting those, that's the language of the C-Suite, you know, 2 point O if you will, or like that's what people are talking today about, which is objectives. It seems to me that all this data that you're creating, this visibility, this ability to remediate in progress over time, that speaks exactly to achieving those objectives. I think that's spot on. You know, eventually the, the sea level, they want to see, you

know, some kind of KPIs, right? And how do you achieve them? And so things like, you know, fixing the problems, like reducing the time to fix an incident, that's definitely something you want to do. The time for fixing an identity related breach, I think I read somewhere is around something like around 40 days. So you have a problem, you need

to fix that. That takes 40 days in in the way that we envision Nano one identity future is that you don't you don't have that time because you're not even using the same language or the same construct to to manage it. So you want to reduce that to zero. You want to reduce the number of incidents that you have and of course you need to reduce, you need to improve the posture and reduce the risk that you have within your environment.

So the first thing, for example, that we do, we scan everything and we show you the, the amount of risk that you have. For example, you have, you know, where the key that is being used in, you know, hundreds of or 10s or hundreds of environments. And we've seen that. And so this is a very big risk because if one of those environments get compromised, that means that all of your infrastructure get compromised.

So we show you that and we show you very easily how you can overcome that and remediate that if this is on what you want or move to a parallel system where those risks doesn't exist at all. You know, Jeff and I are identity practitioners at heart and I think, you know, all this data, having it, it might cost some sleepless nights. That'll what'll really 'cause the sleepless night is knowing you have a problem, but not knowing how big the problem is.

That will just give you anxiety. So I mean, listening to everything we've talked about, I think there are a lot of our listeners who are interested. They want to learn more. How do they learn more? Definitely using the link that you can provide. They're going to #security sending us a notes, pinging us on LinkedIn.

Many ways to come to us. We have a great good marketing would be happy to jump on a call, you know, explain and walk out walk through the solution and also give some free assessments so we can check the posture on you know what are what they have today and just for them to to see. What are the risks that are lurking in their environment?

And it's so often that we go into a colon and and the other, you know, the guy on the other side said, no, no, no, we are, we are completely, you know, very hygiene here. We, we keep everything in the vault. Nothing is, is out. You know, we know where everything is. And then you scan it and they're like, OK, so maybe I don't have anything.

And I used to, I used to say the beginning of the journey that I, I'll give you a butter of Scotch if we don't find anything, you know, as you said, but and I haven't given any, any battle for the last year within this journey. I'll think about those Scots. I don't really have an environment for you to say, but you know, I know that you guys are setting up a URL hush dot security slash IDAC, like the podcast name. I know you're going to have some

something out there. I don't know if you want to reveal what that's going to be now, but if folks go out there, there will be something that they can get started with, right? Absolutely. So whenever you reach out to us and through this link, we can jump on a call and we can, we can have our team give you a complete assessment of your NHI posture and you know, happy to take it on. Awesome. Now you guys, do you guys do the conference circuit?

We will. We're we're studying with Gartner IIM conference in in December and we've got some other ones lined up as well. Well, we'll definitely see you in Gartner. So that'll be a good time to get the official fist bump of gratitude for being on on with us. So Mika, this has been the easy part of the podcast. The hard part is now I have a very challenging question for you, and that is pancakes or waffles. Pancakes or waffles? Definitely pancakes about hesitation, this kind of kind of

memory, right? Yeah, without hesitation. And I'm seeing my mom, you know, it's it's it's the weekend in the mornings I wake up, she give me she serves up some fresh pancakes. What what more sweet memory than this? You can ask well before, right? Well, and and they're just delicious. So I, I have thoughts on this. Let me go to let me go to Jim first, because I have a feeling he thinks he knows what I would pick. But Jim can take or waffles.

I don't think you can go wrong with either one, right? I mean, I I'm a huge fan of both pancakes and waffles, but I will say I do think that waffles are meant as carriers of butter. They serve no other purpose but to put butter in your mouth in large quantities which. A bottling delivery.

System a butter delivery system. Thank you. You're going to go with waffles, and I think you're going to say the same because they can be paired with one of your favorite meats. Yes. So yeah, I'm, I'm a big fan of chicken and waffles, but I'm going to shock you and I'm going to say pancakes. And here's why It's very difficult to find a good waffle. You can get good pancakes pretty much anywhere. It's much simpler, I think to prepare. It's more consistent. That's what I'm looking for.

But a very good waffle. And I'm, I'm more of a Belgian waffle myself meal, maybe some bacon bits in it, maybe, you know, some, some walnuts or pecans on tops and syrup. And of course, you know, some fried chicken. Chicken and waffles is my favorite. But because it's so hard to get right, I feel like pancakes are a safer bet. But I'm like you, I don't discriminate. I will eat either. The correct answer is both, of course.

So we all failed this one. But I'm going to go with pancakes purely just for the consistency factories. I feel like we can get those pretty good anywhere I go. Does that shock you at all, Jim? No, not actually, not that you give them the full explanation. And you said both was the right answer. I mean, I'm, I'm in your lane, man. I will say this. One thing we left out of this whole conversation was, you know, pancakes. Are they buttermilk pancakes? You could get chocolate chip pancakes.

You could get blueberry pancakes. I will tell you, I had this experience where I was in Big Sur, CA. I mean, one of the most beautiful places that I've been on this earth. And I found this little bed and breakfast kind of place like just off the side of the road and they had blueberry pancakes. And one of my projects in retirement is to go going to be to find this place is the best blueberry pancakes I've ever

had, fresh blueberries. And I say the blueberry pancake was 50% pancake and 50% blueberry. So Mika, where do you fall on that? Do you like a plain pancake, or do you put things into your pancake like chocolate chips or blueberries? Definitely a plain, plain pancake kind of guy. This is the basics. You don't mess with that. You you give it, you maybe put some, you know, chocolate on top

of it and some ice cream. But the pancake you need to make it, you know, basic and and as it should as it should come. I'm with you on this button. I, I am not a chocolate chip pancake, a blueberry pancake. Just give me a good pancake and some nice Maple syrup, maybe a little bit of powdered sugar. You know, I like to eat healthy. So if I'm going to have my pancakes, I don't want butter on there. It doesn't need it. I, you know, I don't need any anything else. You know, it's, it's, it's a

health food. As long as you don't put the butter on it. That's the way that I kind of approach you. I'm, I'm kind of a purist in this. And the same way with security, right? You need, you need to do it the right thing, the right, the right course.

And you know, it's the same with pancakes, man. Yeah, if the product is good enough, you don't need these all the other shiny things like chocolate chips and blueberries etcetera, right? It should be a stand alone food. That can live on its own. That's. My my thought. Right, very well put. I was OK with what you said. Like you said, no butter and no, no butter. Like we're not friends with me anymore, Jeff. It's just too much.

It's it's, it doesn't need it. You know, the butter doesn't really add anything for me. I just need a syrup delivery mechanism. And that's what the pancake is. It's the, it's the delivery truck for, you know, a, a nice, you know, I'll say like a vanilla Maple syrup. That's that's pretty good. That's what I'd go with. But Jim, if you do find that BNB, I'd be happy to to get that that address from you. So to to me. I, I wanted to close out. That was the hardest question.

You passed by the way, by by picking, you know, pancakes and a plain pancake to boot. So, you know, congratulations. We're going to have links in our show notes, not the pancakes, but to your LinkedIn profile, but also to hush dot security slash IDAC so people can go check that out. Mika, thank you so much for spending time with us today. Any final thoughts before we wrap up? No, I think I'm excited, you know, first of all, to, to talk to you and I've been listening to you for a while.

So definitely feels like a serene in a way. I'm happy to for you guys to have me and I'm excited for the next chapter of fashion, you know, bringing our mission to to the industry and changing the way things are done. Yeah, I'm looking forward to seeing you at Gartner as well and seeing how things progress from there. So we'll go and wrap it up for this week. You can find us on the web at IDAC podcast.com.

Like subscribe to all best fun stuff, you know, share with friends, share with enemies, doesn't matter. As long as they're liking subscribing, watching or listening, that's all we care about. So with that, we're going to leave it for this week. Thanks for watching and or listening and we'll talk with you all in the next one. You've been listening to Identity at the Center. We hope you've enjoyed the show. Make sure to like, rate and review, and we'll be back soon.

But in the meantime, hit the website at identity@thecenter.com. See you next time on Identity at the Center.