Do you know who has access to what?
This is the Identity at the Center podcast.
If you're looking for identity and access management talk,
you've come to the right place. And now on to the show.
Welcome to yet another episode of the Identity at the Center
podcast. Certainly been appreciating the
likes and ratings we've been getting.
If you like what you hear, do us a favor, share the show with
other like minded individuals And you can also e-mail us at
questions at identity@thecenter.com.
I am Jeff and that is Jim's voice you're about to hear.
Jim. Hey, Jeff, survive the
hurricane. It's by the hurricane.
Well, so far anyway. I'm 100 miles inland and that
helped. Yeah.
So then I guess I'm a Hurricane survivor as well too, being up
in the Chicago area. That's right.
Yeah. We're joined today by Morgan
McNamara. She's one of our crack members
of our engineering team here at Identity.
Hello, Morgan. Hey, Jeff, How's it going?
Good. Thanks for joining us today.
Yeah, no problem. So Jeff, I want to clarify by
being a crack member, that doesn't mean you smoke crack,
right? They don't have.
Well, you know, that's a personal question.
I don't think that that's probably right for the podcast.
I think as long as the work gets done, hey man, whatever.
Not that I'm condoning that behavior.
There you go. So today is Thursday.
Do you know what today is, Jim Morgan?
Take a guess other than you know, podcast day.
Thursday there's. It's an olasp day.
It's not that. It is the opening night of the
NFL. Bears, Packers.
My Bears actually are looking good now.
So there's a chance that we might actually beat the Packers
on Thursday Night Football tonight's open season.
I'm very excited about this. Now those teams have probably
played about 100 times. Yeah, and it's relatively even
even though the Packers seem like they've been dominating the
Bears for the last decade or so, the the actual overall record is
relatively close, which is makes it one of the better rivalries.
Yeah, cool. Morgan, do you have a team that
you follow in the NFL? God, out of obligation, I have
to say the Buffalo Bills. All right, on.
Yeah. Go Bills.
My dad is one of the Bills fans, so I get you on that one.
He's from Newfane and Rochester area, so So yeah, the Bills were
his team. Okay.
Yeah, that's like right next to me.
I'm from Buffalo, so try your hardest bills.
Jim, do you follow? The team Eagles.
That's right, Eagles. Of course.
Did you see that the Eagles offensive line did the ESPN Body
Issue? No.
Yeah. So if.
If that's your thing, just not. Clear it's not.
This is the first time in 25 years of NFL football that I'm
not doing a fantasy Football League.
And I gotta tell you, I find it to be quite free.
I'm actually going to be able to watch the games, enjoy them,
rather than wonder, you know, how my running backs did or are,
you know, having second thoughts around not starting one guy and
him on the bench. So.
Yeah, no, no. I stopped doing it about 10
years ago, and I feel the same way.
It was like it's ruining the game for me.
And I did the same thing with fantasy baseball, where it's
like, you know, I was just so concerned with how individual
players were doing it that it was.
You know, ruining the sport for me.
And I'm sure there are a lot of people out there listening,
period. But there are a lot of people
out there listening who play fantasy sports and love it.
And I used to love it. But I'm with you, man.
You know it's it's freeing. Yeah, I just, I don't know what
it is. It just decided not to do it
this year and there's a certain, you know, freedom aspect to it.
Anyway, all right, let's let's actually talk about idea access
management. And get us back on track here.
Today we're going to talk about a topic that was submitted to us
by Neil who listens to the show. Certainly appreciate his e-mail.
Let me go right into here. What he writes, 1 area that I
think would be pertinent to discuss is around the managing
of identity and a multi cloud environment.
There is a growing movement toward vendor agnostic use of
cloud services and this drives some new thinking around how we
approach identity. Do we centralize or distribute
identity management? And he thinks that make a good
subject which I absolutely agree with.
So wanna let's let's start off with you know why do companies
have multi cloud environments. Morgan, do you want to take a
stab at that? And then Jim, I'll chime in.
My assumption would be that, you know, they have different
platforms, different languages that they're using, and they're
trying to sort of sequester each one of those to try and make it
as secure as possible instead of integrating them all together in
a single cloud instance. I think that makes sense.
Yeah, no, that's a good answer. You know, Jeff, what I've found
is most clients that I work with.
Are either in one of two camps, they're either in a single cloud
environment, so they're using something like AWS or Microsoft
Azure. And those are you know
definitely the two that I see the the largest uptake on at
least the the client base that we've been working with or
they're in a multi cloud and they have more than one.
So they have AWS and Azure hosting and so the ones that I
find that are in that second scenario and.
And to be honest, I'm not an expert in the features of a WS,
the features of Azure or any of the other cloud platforms, but
from, you know, the the level that I'm at, the feature, there
seems to be a lot of feature parody.
I'm sure there's people out there pulling their hair out me
saying that, but you know, for the most part I'm finding that
most clients aren't choosing a WS or Azure based on, you know,
this feature or that feature, but more.
Which company they align with better now where I see the, the
situation where a client has multiple clouds, maybe they even
have multiple kind of instances within the same provider.
It's kind of been thrust upon them in that their organization
you know grew through acquisition or merger or they
you know purchase some software that.
That was on one of the clouds and they were already on the
other cloud or that you know some decisions were made within
their organization. One part of the organization
went Microsoft, the other part went a WS.
Now they're coming together and kind of starting to manage IT
together. And so in other words, they're
they're kind of thrust into that situation.
They really choose multicloud. It just kind of happened.
Yeah, I see as a look at like from a use case perspective,
right. If you're and the the idea that
there's different parts of the business that have different use
cases kind of places what you just said if you're on the
SharePoint side or if you're you know e-mail, you're probably
familiar with Azure from a cloud perspective.
But there might be someone who is more on the Google side
because of the strength of the analytic side that they might be
having. So they're more familiar with
that. They might have gone off and
built something Google's Cloud Platform, whereas you know,
developers might be looking at a WS and spinning up, you know,
services there. So pulling things together is
certainly you know part of the challenge I think that comes
along with it, but in my mind I think it's it's, it kind of goes
with that use case, right. So if you're an Office 365 shop,
you're on Azure, you know whether you whether you like it
or not, you're already using Azure from that, from that
approach and then it becomes that that question of okay, well
we're already using here right land and expand, which is you
know the the approach many software vendors will take.
Is why don't you use you know Azure for the rest of your cloud
services whereas company might have you know other pockets of a
WS and that's that's I think that's pretty common.
I think a lot of companies try to consolidate on one.
But I like the security aspect that Morgan you mentioned before
around having things in kind of a little bit of different silo
where you don't have all your keys in one castle.
So yeah, I think there is benefit to that as well, using
the right tool for the job rather than trying to make you
know, one. One service meet all your needs
when it may not, may not be the best for the business.
Yeah, absolutely. If I could just jump in and
mention something interesting that I noticed when you guys
were discussing that was that it's almost like there's this
sort of resistance in a sense to complete migration to cloud
infrastructure because when you think of implementation of a
cloud, it's really dissolving the traditional.
Perimeters that we've seen that have relied on things like a
firewall and VPN, it's just those just aren't as viable
anymore. You know you're looking at a
cross-platform system where you're trying to simplify the IT
stack. That elimination of the
perimeter is gonna demand some sort of seamless implementation
with a centralized user management tool and I.
It almost sounds like companies are kind of afraid to do that,
and they're trying to almost reestablish perimeters where
they just tried to migrate to a fragmentation of it.
Yeah, I think the perimeter's gone at this point.
I think that's a losing effort. If you're trying to establish
printer on the cloud, Jim, what are some of the problems that
you see? If you're taking a multi cloud
approach. Well, I think the the biggest
problem is the same if you have a single cloud approach which is
but you know it's it's obviously compounded.
The base problem is the number of secrets or credentials that
it takes to run a large cloud environment.
You know you have secrets for secrets or credentials for the
console to access infrastructure.
Within your applications, they're embedded within
configuration files or embedded service accounts.
So the volume, the volume of the number of credentials that you
have to manage is in in kind of a controlled fashion just
becomes such a a major effort that that's really the problem.
And when you go to a multicloud, now you've compounded that you
have as many as twice as many secrets that you need to manage.
Mm HM yeah, there's a visibility issue too, right?
If it's not being if the cloud isn't being managed centrally
right, some areas probably have different procedures and
processes and policies for their own cloud, right?
AWS might be managed different than Azure or Google and you may
not have that visibility. To know who has access to what
was really kind of foundational for any IM program which it
would be part of the security strategy.
Yeah, I mean, think of how how much companies struggle to.
Comply with their own policies in terms of password rotation
when it comes to service accounts, you know now you're
looking at a new environment that often times you know a
cloud environment that spun up without information security
having a handson role. Now I'm talking in generalities,
right? Not every organization spun up
their cloud infrastructure that way, but now you've got
thousands of. Credentials that have to be
managed and passwords that need to be rotated in compliance.
And you may or may not have a technology solution supporting
that. So I think that's really the
problem. And then when you have
multicloud, they just picked up and repeated that the same kind
of problem in a second place or or more.
Or you could be talking about an internal private cloud.
No matter how you look at it, the more places that you have to
manage all these credentials, the harder the problem becomes
to. Manage.
So it sounds like an answer might be some sort of
centralization strategy across the cloud or at least from a
management standpoint. I mean that's that's the answer
to you know. So I think this gets to Neil's
question is using you know should we take a centralized
approach or distributed approach.
I'm definitely in the camp of a centralized approach.
I want centralized command to control centralized visibility
and do who has access to what what they've done.
And I want to put together some guidelines or best practices
that I can you know put into effect in in terms of managing
those identities within the cloud.
And you know I've got some some topics that I'd like to dive
into or or kind of best practices that I think that you
know and and kind of taking an approach of you've got to walk
before you run. Obviously, people who are
listening to this podcast could be.
In different organizations that have that are a different point
in their life cycle that have different types of applications
are running in different clouds. So I'm going to kind of start at
the most basic level in terms of here are the approaches that I
think need to be tackled and then we'll get into the more
advanced stuff all. Right, let's hit it.
What's #1? OK, so starting on you know from
the basics strong authentication practices, so.
You know, starting with the assumption that you've got good
practices for managing identity. So just thinking of your
employees, including the population of people who do
administrative developer functions in the cloud, that
you've got good life cycle management or identity
governance practices. For those people today, you know
who works here, who gets access to what And most importantly,
when they leave that, you're cutting off that access if you
have that and you kind of. Centralize that, say around your
Active Directory, then you can plug in your access to the cloud
through your corporate single sign on solution or Pam
solution. I think you know either one of
those technologies is kind of trying to solve this problem,
but what I see the most is organizations starting with
managing the console kind of the management interface for their
cloud and. Regarding that providing single
sign on to that with their SSO solution, so like pop there or
ping or or one login or something like that and then
ideally on top of like a Pam. Solution work with with that
approach as well something. Like, I mean a Pam.
Cyber or Cyber? Yeah, a lot of those, a lot of
those vendors have solutions developed around Azure and AWS
specifically. I think AWS is probably the one
that. I see addressed the most, but I
think every solution that's trying to tackle this problem is
really focused on providing a solution for a WS as well.
It's Microsoft, so yeah, there are there are solutions out
there that would allow you to use your Pam solution, which has
its own set of benefits. Those benefits are kind of more
down the line of. More advanced benefits and what
I was planning on going through at the moment, because what I
wanted to talk about next was, you know with authentication.
So if we're just talking about access to the console at the
moment and providing single sign on using your account that has
good I GA practices around it. That's getting disabled when you
leave the organization. On top of that I want to layer
multifactor authentication because.
You know your your web console is going to be available over
the open Internet, and we want to make sure that we're
providing a very strong authentication to log in.
So you've got MFA, you got strong credentials.
Morgan, I know you had some experience working through AWS.
When you're logging into AWS, did you did you have MFA enabled
when you were trying to get access to the console?
So when I was setting up access to the console, I actually
because I directly signed in through Aws's web browser, I did
not have to do multi factor. Okay.
So that might be a recommendation for a former
former client, a former colleague, right?
Yeah. Really.
Yeah, Really. At this point, password only
isn't good enough, right? I think that's kind of like
preaching something that we say all the time.
You got to put MFA everywhere as much as you can, especially on
the cloud. You know, it's like every week
there's like a new article around how you know, someone's
cloud got breached. You know S3 bucket wasn't
configured correctly and it was exposed.
I mean there's just, there's so many things that can go wrong
and I think that's what scares maybe some of the people who may
be more hesitant to adopt the cloud, going back to a point
where you know, Morgan, you made earlier, but it's coming.
I mean, you just can't start putting, you know, racks and
racks of servers in your environment where you've got to
do a good job of securing access to them.
And you talk about authentication and and I from my
perspective, I look at it as you've got to know what you've
got before you can protect it. So you got to know who has
access to what. You got to know what all the
different counts are. Especially if you're working off
the compounded problem where you're using multicloud and you
have different, you know, vendors get that inventory in
place, know what the accounts are, know what the permissions
are, start to figure out which ones are human and which ones
are machine, right. So a lot of development takes
place, so you want to make sure that you identify.
You know what's actually controlled by a person will
might be more programmatic and then I would look to centralized
as well. So I certainly agree with that
approach. Maybe putting something in front
of it like the SSO solution makes sense, and then using the
MFA that's part of the SSO solution to get access to the
cloud environment in my mind would probably be a good, you
know, first step towards that. Yeah, I mean, that's what I
really. Feel strongly about is that you
know from a console perspective, because I think that's where
someone can inflict the most, the most damage, right?
They can settings, they can allow themselves access to many
of the, you know instances, the server instances or the platform
services through the console. So if they can get into the
console with a very, you know, very strict role or a very high
level role, they could. Do a lot of damage.
So it's kind of basic blocking tackling of using your SSO
solution, MFA, strong password policy and then using any other
policies that make business sense.
I mean there, if you don't, you shouldn't have people accessing
during certain times of the day or from different IP ranges than
your corporate network. Then go ahead and put those
policies in place. Anything you can do to restrict
access to just those folks that should be accessing?
That environment, all the better.
And one of these vendors also have things like conditional
access right, so you can do things around geolocation, you
know, device fingerprinting, you know, that sort of thing.
It's becoming pretty commonplace today, yeah.
Yeah, I remember when that used to be like, ooh wow, we're cool
because, you know, we can do this and others can't.
But now it's almost a standard feature amongst most.
Right, Access management providers.
So now it's kind of looking for ways to differentiate between
those. You know I see things that like
Casha Corp, you know they specialize in you know cloud
management, DevOps that's those sorts of things that might be
interesting to look at. One area that I think is has a
lot of potential would be more of a like a just in time
provisioning of Access where. People don't have permissions
all the time, right. They get them just when they
need them and then those permissions are pulled back or
you know what are the roles are the entitlements are they give
them access. You know there's products out
there like plain ID. You can even do something you
know through it through an IGA tool, identity governance
administration tool like you have potentially sale pointing
or savians or things like Oracle or I BM you know those sorts of
right. It's a lot more complicated
though when you're trying to do it that way because you really
have to know, you know, what are the permissions and then who's
going to approve it. If it's something that's
critical from like a time frame perspective, you know, is that
approver available to put that in there.
We see these challenges sometimes of a privileged access
management side too, right? Just even inside the firewall,
people getting access to servers and there's this stigma of red
tape that kind of goes around privileged access management
processes that could easily, you know, happen on on the cloud
side too. Right.
Yeah, we're, I think privilege access management really gets
you the most mileage is beyond just accessing the console when
you start getting into managing your server instances and
managing the accounts that have access.
So one of the other tips or keys that I have is, you know, making
sure that each person. Who has to access servers has
their own set of credentials that you're not sharing
credentials over a group of people.
So for example, if you're using a Linux instance on on the a WS
EC2 server, those keys should be individually individually
provisioned per person. So private keys should be
private to the user where? Privilege access management
system could be really advantageous when it comes to
managing those instances is to allow temporary access.
Person doesn't actually need to know the password to the account
on that server. And then of course you could set
the the firewall rules on the console to only allow the only
allow. The IP address with the IP range
that the privilege access management server exists on to
actually access the server. So then you have some network
access controls, you know, additional network access
controls guarding access to that server.
So some good and that's kind of basic blocking and tackling for
the enterprise. So a lot of the best practices
for managing your server environment in the enterprise
move over to. Managing the servers in the
cloud as well Jeff, one thing you mentioned about Hoshi Corp,
I mean what I would recommend for anybody who's listening to
go out to their website, watch some of the the videos that they
have posted their their tech talks with their their Co CTO's.
I mean those guys are both really, really bright and and
they really understand the space and they can walk you through a
lot of the ways to approach. Now their focus is primarily I
think around managing DevOps, managing really secrets in the
in the cloud. And the secrets a lot of times
are go back to if you're looking at this from a developer
sampling, you're publishing applications out to the cloud.
But I think that's a lot of what we're talking about today,
managing A multicloud environment.
So I think that's a really good vendor to bring up.
Relative to this discussion, you know I think that DevOps is
something that you don't want to forget about.
How do you deploy apps without hard coding secrets?
So you look at technologies like Hash Core.
It's a way to have your applications programmatically go
out and fetch your secrets rather than having to hard code
them into configuration files. In the same with your DevOps
tools like the Kubernetes not having to hard code all those
credentials. Into into something that can be
seen by multiple people within the organization.
Yeah, that takes a lot of work though too, because if you
haven't built out applications with that in mind, right.
If more of like a legacy type approach trying to go back and
reconfigure applications to use the programmatic means to pull
keys from vaults and those sorts of things can take some time.
So it's definitely not something that happens from an overnight
perspective. But I think I think Ashley Corp
would be a good one to look at. You know maybe something like
Plain ID as well if you're looking for more like a just in
time provisioning. I think they have some
interesting use cases that that might be helpful for people who
are looking at managing access to cloud environments.
The other thing I think you brought up a good point about,
you know, it's a lot of work. I don't think that I am program
manager can go in and and and you know be confrontational if
you will, about trying to implement security.
You really have to partner with the development team.
They have to see the value and having checks and balances and
see the value in. You know, the visibility that
they can get and the manageability that they can get.
A lot of times you run into kind of the mindset that, well,
there's only 10 people in the department.
They've all worked here, you know, 3, three or more years.
We trust them. The thing is, some security is,
you know, not about trusting people, it's about being, you
know? Being able to not have to rely
on trust. It's being sure that you have
the security controls that everybody knows that hey, if you
try to do something, we're going to know about it.
And I think from an IM program manager perspective, the way I'd
look at it is to try to partner with the manager of applications
because I think that, you know, they're going to have to adopt
this technology more or less willingly for it to be a success
and. They should look at the I M team
as a partner. Somebody can provide
administration of that of these platforms and be a proper checks
and balances that. Can allow them to focus on
development and not have to focus on security as much,
right. So I think hopefully that helps
kind of put at least our opinions around that for Neil
and maybe other folks who were having some more questions.
I think to sum it up right, we're we're fans of centralizing
it, but you got to have good policy procedure you know back
ending that you know the right kind of technology approach and
how you'd want to manage the permissions and making sure you
don't forget about humans and non humans, right the
programmatic side of things, DevOps etcetera, getting access
to the cloud. I'd like to kind of pivot back a
little bit to Morgan and kind of talk a little bit about her
background, cuz I think she's got kind of an interesting story
where you know how people, if you remember one of our first
episodes was, you know, how people got into I M most of us
kind of fell into it. And I think Morgan's another
good example of that. Morgan has an amazing LinkedIn
profile, by the way, which I will definitely link in the show
notes. So kudos to you.
Morgan definitely shows off some of the writing skills there.
Maybe you can talk Morgan, about how you got, how you, how you
know, how did you get into I am I guess let's start there.
Yeah, sure. So as I mentioned kind of before
the call, I was an English major, originally graduated and
did some writing for online news journals.
But there was a shift to paying writers in terms of publishing
where, you know, there was no actual monetary value attached
to your quote, UN quote payment. So from there I kind of pivoted
and went into code. Someone who obviously has a
respect for language. I figured the language of
computers might be something pretty fascinating, and I was
not wrong. Definitely in some regards kind
of being a professional student, which I loved, I started
attending the local weekly OWOSS meetings that we have in Austin.
Through that, I met someone who. Is one of the board members for
a hospital application called Open EMR, and that's open source
and charity based. All the developer activity on
that is out of people's own pockets and time through that,
the person who kind of recruited me onto the project saw how.
Willing I was to learn and to kind of experiment with things.
So he kind of threw me towards the AWS implementation where we
migrated the patient document database to Cloud Native and
that's really how I fell into Identity Access Management and
here you are. How long did it take to do that
migration? Gosh, I'm gonna say a couple
months. Maybe two months And that was
what re architecting the application, moving data stores
around. Yeah, my personal involvement
with it was a little more spotty because I was learning and self
teaching and also working on codebase infrastructure at that
point as well with Open EMR. So I was kind of being thrown
around there. I think that's fascinating.
It's such an interesting pivot to go from English major writing
into technology like that, I guess.
What are some of the languages that I guess what was the first
language that you learned on the IT side of things?
Yeah, so when I first got interested in this.
And I say this as in coding in general.
I went to OWASP and I was initially just filling an A
notebook as a dictionary basically with terminology and I
was like OK, does anyone have any recommendations for what I
should start with? And someone said Python, so
that's actually where I started. I wish I would have started with
like. Code Academy's command line,
because my knowledge quickly became kind of Swiss cheese
esque, and they had to go back a lot of times, kind of backtrack
and fill in knowledge holes to understand really why things
were happening and how they happened.
But Python was first, and then I moved on to HTML, CSS, SQL.
That was fascinating. Jim, I think you probably have a
question or two. Yeah, so actually one of the
things I just did want to close out one other last point that I
wanted to make on the best practice.
I think it's just around logging and make sure they have logging
centrally set up to identify problems and and setting up
alerting and it kind of triggers me into another thought so.
One of the things I I started off this discussion around why
organizations end up in multicloud and I said, well the
clouds seem pretty comparable. So in other words, if you're
down kind of the checkbox list of, you know, does it have a
Nosql database, does it have logging, It's like yes, yes,
yes, they all operate a little bit differently.
You know, they mostly follow some open standards and they
have some proprietary connectors and so.
It's probably not super easy to just pick up an application and
run it in both environments and expect that it.
You can't only do that at a very thin level, right?
You have to integrate to the logging solution.
So at at many of the tiers of the application you have to make
them specific to the cloud that you're running in.
And that's why I think it makes it harder to consolidate clouds
as well as like you can't just. Pick up all your applications in
one. If you're using the platform
services of the cloud, you're running everything on server
instances, sure. But if you're using the logging
service of the of your cloud provider, when you migrate that
application from, you know, from AWS to Microsoft or vice versa,
you're going to have to reengineer that application some
to work with the logging service of your new cloud.
So. That was just something I wanted
to throw in there as well is that, you know, the idea of
multicloud will probably be around with us for a long time
because it's not just as easy as moving a bunch of server
instances from one environment to the other.
Yeah, I can't believe it. I totally skipped over the fact
that you gotta be able to prove everything right, So I'm glad
you brought us back to that. No, no problem.
Yeah, actually with that that brings to mind, you know,
identity federation in the cloud trail with AWS where you know
you have a log of information about people who even requested
in based on their IAM identities.
So when you have decentralized logging, you have that single
point of access to all salient logs that are created across
accounts regions. Which is really critical for
security, right? But if it's fractured with a
distributed database, I would think that you really lose a lot
of data integrity because of the complexity introduced there.
And then I would question kind of handling failures.
You know how you distinguish site failure and link failure?
Yeah, and one of the things that the.
Applications across. Across multiple clouds.
So this is one of the things that I've been thinking about is
that if you have a cloud like if one of your goals is to
distribute an environment, distribute an application, I
don't feel like you have to have it running at AWS time.
Microsoft. So if one goes down, the others
available because if you look at AWS or Microsoft, they've got
data centers in around the world.
So I guess you know, if you're really paranoid about your, you
know. The entire company going down,
that's one thing. But you know from a geographical
load balancing perspective, they've got data centers in
different regions of the US and throughout the world.
So my thinking is that you know if you're, if you were starting
out today, I'm like let's start our our migration to the cloud,
you'd pick one vendor and spin up services in.
More than one geographical location?
You wouldn't say Hey, let's go to two different vendors in case
we lose a vendor. Yeah, you don't want to
overcomplicate it, especially if you're just starting out.
Right. And then I mean, if you're going
to go to the cloud, I mean it's kind of like level one is just
spinning up server instances. The real benefit you get is if
you get a level 2, Level 3, which is to leverage the
platform services for your applications.
So if you're using a. A common logging platform.
If you're using a common no SQL database or SQL database, but
it's as a as a service. Again, those services are going
to look slightly different from cloud to cloud or from vendor to
vendor and your applications aren't going to be able to point
exactly the same way across multiple clouds.
Right on. I think that's probably a good
spot. We can leave it for now.
I certainly appreciate the conversation.
Hopefully Neil and others get some value out of what we talked
about today. Morgan, appreciate you taking
the time to join us. Welcome to the team.
Welcome to the party. Yeah.
Thank you for having me, Jim. Go Bears.
Go Bills. Right Morgan.
Yeah, Go Bills. Kind of, kind of.
All right. All right.
We're going to leave it there. Appreciate folks taking time to
listen to us. Hopefully you got some value out
of it. Feel free to like, subscribe,
listen, tell your friends, share the show, and we'll be talking
to you on the next one. You've been listening to the
Identity at the Center podcast. To access all episodes, visit
identity@thecenter.com.