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.