Identity at the Center is a weekly podcast all about identity security in the context of identity and access management (IAM). With a combined 30+ years of IAM experience, hosts Jim McDonald and Jeff Steadman bring you conversations with news, topics, and guests from the identity management industry.
Do you know who has access to what?
You’re listening to the Identity at the Center podcast. This is a show that talks about identity and access management and making sure you know who has access to what. Let’s get started.
Welcome to the Identity at the Center podcast. I’m Jeff, and that’s Jim. So, we’re going to get into our topic and our guest today, but before we do that, do we have any other news or notes that we want to bring up, Jim?
Yes, LinkedIn is my favorite social media channel, and I guess I am linked in with a lot of folks from the IDSA, the Identity Defined Security Alliance —their website is IDSAlliance.org, and I bet you’d find a ton of great blogs, and a lot of great information. They have their webinar called Identity Matters: Applying an Identity-Centric Security Strategy in Healthcare, May 6, 12 noon Eastern Time, 2021.
Seems pretty fitting, seeing as we’re called Identity at the Center. I think we would probably support that. IDSA does a lot of good work. So, support those guys.
Yes, they definitely do.
So, we’ll put a link to that in the show notes so people can check it out, but why don’t we get into our main topic for today, which is a very deep philosophical discussion. Maybe that’s where we start off with, talking about the Semantic Web and ABAC, or attribute-based access control. I’d like to introduce Evan Gertis. He is a penetration tester with NetFoundry — also from the very, very small world that we live in, also in Augusta, Georgia, along with Jim, so you never know who is going to be in your backyard. Welcome to the show, Evan.
Thank you, Jeff. Thank you, Jim. Thank you, guys, for having me on the show. I’m really excited to be here.
Thanks so much for joining us, and as this is your first appearance with us, our initial question is always, how did you get into the space of information security and identity and access management? Is it something that you chose or did it choose you?
I’ve been giving that question some thought here, and for people who have watched the movie Avatar, there’s this point where Jake Sully goes up to this banshee. He is told that the banshee will choose you — you don’t get to choose it. In so many ways, that was how my career in information security had started. As a young kid, I was playing Command & Conquer. My favorite Command & Conquer game was Command & Conquer: Red Alert 2 — Yuri’s Revenge. I love the cut scenes in that game. I live for it. I live for the bad acting — it was wonderful. I really enjoyed playing the multiplayer part of that game. You could set up Russia and South Korea and stuff, and there’s always a finite amount of money. That was frustrating as a young kid, because I wanted to buy all of the factories, all the stuff.
So, as we were going through the files, I found that there was an INI file in there. I didn’t know what it was, but I recognized the dollar amount for the starting amount for any of these multiplayer games. So, I changed that, and then I restarted the game, and I realized I could actually just make money. I could just make money by changing this file. That happened to be something that I brought up in a job interview out of college, so definitely, it’s one of those experiences that shaped me. It will never go away — I’ll always think about it. I think that was the first taste. Then, from there on out, it just started to take on a life of its own.
I love the Red Alert story, because that was something that we played too when we were younger. So, now you’re working with NetFoundry as a pen tester. Can you tell me a little bit about NetFoundry and what they do? I know that they have some play in the zero trust space, but maybe you can educate our audience at a very high level as to what NetFoundry does?
Yes, for sure. I wholeheartedly believe that we are the best zero trust networking-as-a-service platform that’s out there right now. You can download one of our clients, and you can connect to your cloud resources. To go into all the details, I don’t really think we want to do that, but basically, once you build a network, you can add services to that network, and once you have a client installed on your computer, you’re able to access it. It’s really cool. We’re working on cutting-edge here — we’re really trying to make our product more accessible for IoT — but, yes, that’s basically NetFoundry in a nutshell. We’re a zero trust networking-as-a-service platform. You just download a client, and you can connect your service in the cloud.
Very cool. How did your pen-testing background and role help serve that furtherance of security in the zero trust world?
That’s a great question. As a penetration tester for a startup, you’re going to have a lot of different roles. You definitely can’t be scared of responsibility. When my manager comes to me and says, “Hey, we’ve got to crack down on application static code analysis — how are we going to do this?” you’ve got to think outside of the box. So, I’ve introduced automation tools, I’ve introduced code scanning tools and then I do manual penetration testing. A lot of classic tools. One of my favorites is Burp Suite. If you are a penetration tester, you’re a bug bounty hunter — whatever — Burp Suite is where it’s at. A lot of those tools are in there. It’s pretty great.
In researching your background for the podcast today, I noticed that you have a website, so feel free to pump that, but, reading through it, I got the sense that you think very deeply about things. You want to be an educator. You talked about wanting to teach at a community college. I think that’s great having that desire to share information. We talked earlier — preparing for the show, you talked a lot about the Semantic Web: Web 3.0. As much as you can, kind of bring that down for the rest of us to understand the evolution from Web 1.0, 2.0, 3.0, and what the Semantic Web means for us.
Jim, I’ll first say I’m humbled that you think I’m a deep thinker. A lot of the stuff on my website — I have quotes from different philosophers and whatnot, but those are people who inspired me. I can’t take credit for their thoughts, but I do love sharing that, and I appreciate that you think that I think deeply. That makes me feel good. I don’t know if I do.
To start with the Semantic Web, this is going to go back to my education. I got my degree in physics — I studied at the University of North Carolina, Chapel Hill, and got my degree in physics there. I was around a lot of physicists, and I was introduced to the concept of networking while I was working at a nuclear lab there. So, I had to make a step, and I started to get into networking, and I learned about Tim Berners-Lee, who everyone knows is the founder of the internet. He is a physicist, has quite a claim in all of this. I started to read more about his biography, his background — and if anyone is interested, look up some of his ideas on Wikipedia, which is a wonderful resource for anyone who is trying to learn more about the Semantic Web. There’s a lot of documentation out there.
I don’t want to make this into a really complicated topic. The Semantic Web, it’s saying that at some point, the internet is going to become machines talking to machines, and they’ll handle our everyday transactions. It won’t be user-generated content. Right now, we’re in this Web 2.0 phase where people are uploading content. A hypothetical scenario that we could look at for the Semantic Web is, imagine a machine that makes video content and then serves that to another machine, and then people just watch that. Is that possible? That’s what the Semantic Web is. That’s really far out there. Does that answer your question?
It’s an interesting example. I’m wondering, with Web 3.0, the Semantic Web, I think of the Internet of Things and, of course, what the implications are with that from a security and from a privacy perspective. I’d even like to back it up to Web 2.0, because we had a discussion earlier. You mentioned Wikipedia is user-generated content, and I was bringing up the societal-good-and-bad discussion. My perspective, having teenagers, is, they’re locked into their phones, and they’re doing TikTok or Snapchat, and they’re just — it feels like it’s hard to influence them in the same way that my parents influenced me, because they’re so locked in to all these influencers that are coming through to them in these other social media platforms. Jeff, I thought, brought up a great point, though, with Wikipedia — Jeff, if you want to jump in and state your case on behalf of the good of user-generated content.
Yes, I was thinking about from an optimist’s perspective, there are certainly downsides when it comes to social media. I think a lot of this is more individual. You can have a great experience with anything on the Web, and you can have a terrible experience with anything on the Web. It really does boil down to the personal touch that’s being influenced there. But I think of the greater good of things like Wikipedia, where this used to be the Encyclopedia Britannica. You’d go out and say, “Oh, I have this version from this year,” and your data was only as good as that year.
Now, you’ve got all the information of the world at your fingertips — it is curated by volunteers all around the world. Of course, there are times when someone will go in and update a Wikipedia: My favorite examples are when someone in the sports world completely dominates another team and somebody updates, “Oh, and Tom Brady completely owns” whatever team is out there. It lives in there as a version for a certain amount of time, usually not very long. Then it self-corrects or self-heals, because you have this group of people who are doing nothing other than just making sure information is right and accurate, are making those updates.
I think something like that is being a great use of it and contributing user content. There’s YouTube. There are podcasts like this. We are contributing content out there — we hope that it’s correct. A lot of times, what we’re talking about is opinion or our own experiences. So, how do you validate something like that, where, “Well, this is what I’ve experienced — this is what Jim has experienced and what Evan has experienced”? There’s always going to be some disconnect around that, but I see the good and the bad of it. I don’t have kids, so I don’t have to worry about the influence of influencers doing stupid things on the internet, which, in my mind, that’s always taking place. There’s always been knuckleheads. Now, it’s just that there’s a platform for anybody to put out there whatever they’re putting out into the world. It’s just a lot easier to consume. I guess that’s my two cents on it.
Yes, it’s a great rap. Evan, I don’t know if you have anything you wanted to say on that topic?
I think Jeff made some really good points there. I’ve noticed that there’s the ability to decide whether this is a good thing or a bad thing. We can look at something, and we can say, objectively, this is good or this is bad, and that comes from within us. I think you made a really good point there, Jeff. My personal take — I can’t speak for everyone — I really agree with you. I also can definitely see where you’re coming from, Jim, that there are negative impacts from social media. There really are knuckleheads out there. If we’re not proactive in setting an example ourselves, we’re going to run into problems with people who are creating this negative influence. We definitely don’t want that.
I think you brought up a really good point. Now, when we’re talking about SAML and OpenID Connect and these authentication methods, are you talking about these use cases in the context of federation?
Well there are some human flows within those protocols, and especially SAML, but especially in OAuth2, where there are some machine-to machine-flows, does that really become the standard we build on going forward for years to come, to support the Internet of Things, or do you even have a perspective on that?
That’s a really deep question. I have thoughts on that, and I’ll keep it as simple as possible: We have Sally and Jeff, who work in finance, and in traditional role-based access control, Sally and Jeff have this privileged access to finance resources. Now, if we extend that to machine-to-machine — let’s say Sally and Jeff are now machines, so these are finance machines in the cloud — the way that I see attribute-based access control being applied here is (and we’re already saying this is the Semantic Web, because they’re machines), they’re tagged with “finance.” They talk to resources that have that tag: “finance.” So, this concept of tagging things and then setting the least-privileged access on the tag is the way that these things are going to talk to each other. That’s my idea. If we could imagine that there’s a Sally-and-Jeff machine with the tag “finance,” and then they’re talking to a bucket or they’re talking to another instance that has that tag, “finance,” then that would be attribute-based access control.
When it comes to this idea of tagging people and, well, not people — now we’re talking about machines — how do we set it up so that this is secure in the real world? We have a whole bunch of data around things and people, and when you’re trying to connect systems at the machine level, usually, the machine is expecting data in a certain format. It needs to be parsed a certain way. There may not be language-interpretation methods that are trying to decipher a text field that may not be formatted a certain way. How do we approach that from a process of being able to enable this from a more Semantic Web approach, where you have machines that talk to machines that are going to expect certain things? Is it an API? Is it a standard? Is it both? Is still to be determined? Where do you see that heading?
That’s an awesome question. It is still to be determined. There’s a huge opportunity for this. We’re just starting to see the starting stages of this. Actually, at NetFoundry, we ran into this issue when we were trying to design something that allowed a bunch of end points to talk to services. We noticed very quickly that trying to do this with traditional role-based access control, we ran into problems where it wasn’t scalable. So many machines, so many services —how do you scale it? Then that’s where we started to fall into attribute-based access control — tagging a set of clients, and then tagging a set of services and saying, “Oh, if they have the same tag, then they can talk to each other.” That is actually being done with an API.
So, when it comes to ABAC, attribute-based access control, and RBAC, role-based access control, from a development standpoint, how does this look from a machine perspective? When do you use one or the other, and where does it make sense where ABAC is a scenario where you want to use that primarily, maybe as a method to drive authentications or authorization, whatever it may be — data versus the RBAC side of things?
Like with so many things, this comes down to cost — cost, and return on investment. If it makes sense to work with something newer, like attribute-based access control, that’s going to cost more money. I do believe in my heart that setting up the proper security controls in the beginning will lead to saving money in the long run. I do believe that’s how that works. It comes to an evaluation from management. They need to make the decision on whether role-based access control is going to be scalable enough for them to use.
Also, there might be a limitation. There might not even be ABAC — it might not even be an option. Using AWS, you can actually use ABAC in AWS. I think that’s a great place to start. If people started to use AWS, if they do want to learn more about this, that would probably be the place to start. We use it in NetFoundry as well. If you are looking to connect cloud resources to clients, you can definitely check out what we have. AWS documentation is very solid — looking through that, and then figuring out whether it’s going to be worth the return on investment. In my opinion, if you got 10 people connecting to the resources, role-based access control, no problem. Are you designing an education system that’s going to have thousands of students connecting to you, tons of educational resources? ABAC might be the way to go.
I see ABAC being more policy driven. You can automate based on some of these attributes, and it doesn’t make sense to automate something for 10 people unless it’s the right 10 people, or maybe there is some sort of compliance thing that needs to be associated with it.
I see RBAC and roles being a precursor to the ABAC side of things — meaning, you don’t have a lot of automation driving decisions that, say, because I am Jeff and I am in the Chicago area, this is what I get or this is what I can do. If you have a system where you need to do that and you have that data available, and it’s able to be interpreted by other machines or things — bots, whatever it may be — then it makes a lot more sense.
Otherwise, you get into this position where you have role-based access control, and Jim, feel free to correct me if I’m wrong, but every company that we talk to says, “Oh, yes we want to go to RBAC.” And then, when they realize how hard it is and how much work they need to do to even get to that state, it becomes very difficult to even get to that area and to do it effectively, because RBAC is not something that you can let really die on the vine — especially, if you want to live in the world of the principle of least privilege, you have to be constantly recertifying roles.
Accesses come and go — how do these things make sense? If you’re driving it from an attribute perspective and you have automation that’s picking up on those different attributes, you can probably get away with being more granular from an access perspective, because you’re relying on a machine somewhere to interpret that and say, “OK, Jeff is no longer in Chicago — he has decided that he is going to retire to Denmark” or something like that. So, now my access changes as a result of that attribute change. Other things might not have changed, but it could be that thing. Jim, from your perspective, does that make sense when we’re talking about where the leverage between ABAC and RBAC fits, or do you see it differently?
The RBAC approach is very centrally driven, in that somebody has to be going in and creating, and pruning and, like you said, recertifying roles, whereas the attribute-based approach is more or less a onetime setup where you’re passing attributes to the applications. In either case, the application is either determining from a role or from an attribute. What access do you have to the applications? There is that extra step from a central perspective in developing roles. Most organizations don’t need only one or the other — a combination of the two, especially in large organizations, can work very well where you’re using roles where you get a lot of leverage from it. You’re using an attribute-based approach where either you want to provide more autonomy to the application teams or you just don’t have the commitment from the business to manage roles in a holistic way.
The thing is, if you develop roles and then you don’t manage them, they can become more of a hindrance than they provide value because at that point, you think they’re providing you security, when actually, they’re not being managed, people are staying in roles they shouldn’t be in, the owners of the roles aren’t clear and things like that. You’re better off without roles.
I think you bring up a good point. There is no one-size-fits-all. The best approach is, you have a blend of what works for you. Maybe you have some attributes, and maybe you have some roles, maybe you have some of both — maybe shade one or another. This is something that also can change as the organization changes. You may decide that, yes, you do have the opportunity to be more data driven in some areas, and others where you decide, “No we want to have this a little bit more tightly controlled and go through a specific process or workflow,” whatever that might end up being, because it doesn’t make sense to put the full power of an attribute policy or something associated with that.
Evan, when it comes to how you see that working in the real world, do you have any idea, any experience, as far as what you’ve seen from your perspective and how you’ve seen organizations tackle that?
I want to go back to something that you brought up. You brought up your observation about industry being reluctant to embrace this attribute-based access control. Where do you think this fear is coming from?
Good question. I’m not sure. My perspective is that it’s probably based on immaturity from an IAM capability standpoint within an organization. A lot of organizations, frankly, struggle with doing good, proper identity management. They might have some custom processes or tools, or they’ve got a bunch of IAM heroes in the background that are making everything work, but it’s not really managed.
In the real world, where most people would struggle is, “Yes, we’d love to be automated. We would love to have policy based. We would love to have all those other kinds of tools and technologies out there.” But in the real world, funding isn’t infinite, so there are choices that have to be made, typically from an IT perspective, of where you want to put the spend. Resources aren’t infinite, so you have to figure out who is going to be able to work on this type of stuff. I see it as not necessarily the industry side of it. It’s more of the business, and the industry is a reflection of the business — meaning, what are the capabilities and services that are ready to be consumed — and that’s why sometimes you’ll see a great technology comes out, and it’s ahead of its time, because business just wasn’t ready to pick it up.
That’s where blockchain might be from an identity perspective for an enterprise. Certainly, there are use cases out there for, obviously, cryptocurrency, and now we’ve got nonfungible tokens and things like that. I still haven’t seen an enterprise inside-the-firewall use case for that yet. I’m sure it’s going to come at some point. I don’t know when, what or what it looks like for now, but that’s where the reflection comes in, as I think it’s more of a realization that the business typically just isn’t ready for it — or at least most businesses aren’t.
How about you, Jim? What are your thoughts on where this fear from industry is coming from?
I think it comes down to control. I made the case earlier that RBAC requires a lot more central management than ABAC, but even ABAC is a centralization strategy: You’re pulling these attributes into a central authorization store, and then, when somebody authenticates the application, you’re passing the attributes to the application. They’re being interpreted, and security is being applied.
The traditional model is that each application has a user management interface and that through that user management interface, I apply authorizations, whether it’s attributes, roles, groups — however you want to call it. For applications to give that up to a central store, there’s got to be something in it for them. There are all kinds of dynamics that can happen within an organization of why people don’t want to give up control. A lot of times, it’s fiefdoms. A lot of times, it’s the central team has had some failures in the past, or “You can’t do it as good as we can do it.” In my experience, that’s what I found the most — it’s a matter of control.
Really awesome thoughts on that. I think that you both brought up really good points. It’s something I’ve been thinking about, trying to understand. I think you made a really good point, Jeff, when you said that we have this ideal image of what identity access management is supposed to look like, and then we get into the thick of it, and it’s like, “OK, wow — we have so many problems here. What is the first fire we’re going to put out?” Going back to what you were saying, the first question that you had asked me is, “When do you use role-based access control? When you use attribute-based access control?” My hope is that ABAC will help remedy that whole problem of managing so many different roles. That’s what I’m hoping. I say that because day to day — doing that, day to day managing it — takes up a lot of time, and like you said, there are finite resources. It’s not infinite. We have to make decisions.
We’ve been talking about the Semantic Web. What’s next? What comes after the Semantic Web? Are we all just Neo in The Matrix at that point?
I think that’s when we get to Deus ex Machina?
Something like that. Yes.
Yes. So, what comes after the Semantic Web? It’s such a deep question. I’ll take your perspective here. I would hope that after the Semantic Web, people are going to have more education available. They’re going to be able to teach themselves things more quickly. We’ll have little systems that we can keep with us that will help us extend our memory rather than just constantly entertain ourselves. I do feel like a phone, in so many ways, helps us extend ourselves. It’s an extension of our thinking. I’m so grateful for being able to open up my phone and say, “Hey, I’ve got this question. What’s the answer to this?” I pop up my phone. I can’t even imagine: What was someone thinking in the 1800s when they had to solve a problem?
This is your teacher back in math school saying, “You’re not going to have a calculator all the time.” Guess what? We do.
We do. I think after the Semantic Web, we’ll have a sort of indexing machine. I remember my sixth-grade technology teacher always said, “Evan, the purpose of technology is to make life easier.” My humble vision is that after the Semantic Web, life is going to get easier. We’re going to have machines talking to machines, and it’s going to be something that’s going to benefit people. I really can’t imagine what’s going to happen.
Think of this scenario: the self-driving cars, and the intelligent mapping. I’m not sure what that’s called — social maps: “Hey, there’s a traffic accident up ahead,” and it calculates the route, but the cars are out. Also, having to take up what’s going on around them, and all of that data has to go to some kind of central store to be processed, and then distributed back out, and decisions have to be made. What becomes wild is that the technology, in order to support all of that, still needs to exponentially grow the processing power. The network bandwidth, the ability to store all of that data, it’s intense.
Going back to what Jeff was saying with attribute-based access control: the amount of management, the amount of tinkering that has go to into that. If we can think about the scenario that you just described, a potential car accident, and that’s being communicated to a rescue machine, we got to make sure that that’s accurate.
One other thing that comes to mind is, at the company that Jeff and I work for, we’re putting together an IoT steering committee, with a large group of us coming from the IAM side of things, because so much about IoT comes down to security. The thing was, when we were originally talking about it, we were doing this vendor analysis — “What IAM vendors play in the IoT space?” — and a lot of the focus was on authentication.
One of the things that came out in our conversation is, it’s more than just authentication. It’s not only authorization, but it’s also registration: How do you register the device? Those are the use cases that started to make IAM so complex, even when you’re just talking about human beings. It’s not just single sign-on. It’s, how do you get access in the first place, and then, how do you make sure that the access remains appropriate over time? Really interesting.
We’ll wind up revisiting this topic on the podcast in the future as things evolve, and as this IoT steering committee spawns some ideas for Jeff and me, we’ll continue to bring them to the podcast as topics to discuss.
Yes, we may not have all the answers, but at least we know what questions to ask, or at least start to think about to have the conversations, which — sometimes, that’s the answer itself: “Hey, we haven’t really thought about this before. What are we going to do about it?” You can start thinking about what’s next. I see natural language processing is the next field of “How do we get to that Star Trek future where I can tell a computer exactly what I want in my own natural language and voice commands, instead of having to remember, ‘Hey, so and so’ to prompt something to pick up on your voice, and then speaking a very specific set of commands.
I see that as the next level of ABAC — being able to have that translation layer. Now, where you’re saying, “OK, I’ve got these different attributes. These different machines are talking to each other. How do I let them translate that data back into something that a human will naturally be able to articulate and say, ‘Here’s what I’m trying to do’?”
Then, the hard part is, how do you then make the computer understand, “Oh, that means XYZ in XYZ order for only XYZ person”? I think that’s where the challenge comes in, and it’s great to start thinking about where things are going to go, because behind all of those decisions are the different IAM controls that are controlling the access to each of those individual bits of information to say, “OK, yes, you are allowed to say, ‘Earl Grey tea, hot’ into the computer” and have the replicator spit it out. Maybe it’s because it’s my voiceprint or my biometric that’s knowing who I am. I don’t have to say I’m Captain Jean-Luc Picard. I am authorized to have Earl Grey tea — “Make it now,” or anything like that. It just knows who I am. It’s maybe a present sensor, but all of this is data flying behind the scenes.
We talked about how you leverage that data to be able to make decisions on it. The policy construction has to be rock-solid. You can’t have tinkering of third parties coming in and changing policies, especially if we start to look at life-and-death decisions around “This is the real world.”
I think about automated driving. At some point, someone is going to have to think about the scenario where I’m going to crash into a pole if I keep going. If I turn right, I’m going to hit the baby in the carriage. If I turn left, I’m going to hit a kid on a bicycle. How are you supposed to teach AI those types of scenarios? What happens if someone starts to tinker with the attributes that control those scenarios and those variables that go into the calculation and say, “Well, we think you have an 87% chance of survival if you hit the tree in front of you because of all the other safety mechanisms” versus potentially having other serious ramifications to the left and right of you. So, this is all data that flies behind the scenes. It’s real-time, it’s split-second, and any change in the access to any of those variables can have catastrophic consequences.
I really like how you framed that. I think the thing I noticed is the simplicity with what you just described, how the world is evolving — that it just one endpoint talking to another endpoint. The thing that we’re trying to understand is, how do we assign identities to the endpoints? How do we say, “This endpoint should be able to talk to this endpoint?” That’s the problem that we’re trying to solve. I think you’re absolutely right. I think that putting in a strong-at-any-access management solution into a system before it evolves into something super complicated will help save money in the long run. I think that that is a very serious thing for people to consider: How much money do we really want to spend on the solution? People cost money, machines cost money, reworking costs money — all those things are very expensive.
You brought up really good points. I haven’t even touched on all of the potential consequences of machines talking to machines, but just getting that basic concept down of “This thing can talk to this thing because it has access.” I don’t know, Jim, what are your thoughts on ABAC for the scenario that Jeff described there?
I’m sitting here thinking, “This is a fun conversation, thinking about the future.” Jeff brought up the Star Trek: The Next Generation scenario. That really got me thinking. You can guarantee that 50 years from now, people are going to look back on us and think we were like cavemen. I was around working on Y2K issues and literally thinking to myself, “Why were they so lazy that they only stored two-digit years?” But that was the constraint they had at that time. It’s easy to sit there in the future and look back and just shake your head. I guarantee people will look back at this time and think, “Oh, my gosh, they were cavemen.”
I think about when I still see, “Oh, you use eight-character usernames, because our systems can support that.” That was the decision someone made 30 years ago on a mainframe or something, and they only coded a certain amount of memory for that.
We certainly waxed poetic and philosophical today.
Yes, definitely went down the philosophical route, for sure. We definitely did.
I think you’re coming up on time here, and I want to be respectful of your time, Evan. I certainly appreciate you taking the opportunity to jump on with us and talk through some of these scenarios. Jim, any final words you want to throw out there for the audience?
Well, I was just thinking as you’re talking about how the IoT has evolved. We may not know all the answers, but I think that’s why we bring on guests like Evan to fill in those gaps for us. We definitely don’t know everything, but hopefully, we can bring people onto the show who do know more than us and can help educate our audience. Evan is a listener, and that was how he found us. I put a call out there to our other listeners: If you’re interested in being a guest on the show and you’ve got some topic that you feel like you have enough expertise to help educate the listener base, the IAM practitioners of the world, reach out by LinkedIn, and connect to Jeff and me on LinkedIn. We’re both pretty active. Evan, you’re on LinkedIn as well — I’m sure you’re open to connection requests as well.
Yes, for sure. I’m super grateful for you guys having me on the show. It has been a pleasure. You guys are hilarious. I just love the conversation and the community that you guys are driving here. It’s awesome.
Identity talk is just a laugh-a-minute. It’s super entertaining. We try to take that spin as much as we can. I think that’s a pretty good spot that we can probably leave things for this week. Evan, we really appreciate your time. Thanks for listening in the first place, and thanks for being on the show as well and contributing to this great experiment that we’re doing in this wonderful world of podcasting. Jim, as always, I appreciate your insights.
With that, we’ll go ahead and wrap it up for this week. You can visit the show at Identityatthecenter.com. You can follow us on Twitter @IDACPodcast. As Jim mentioned, we’re all on LinkedIn, and we’ll have links in the show notes. You can connect with us there as well. Don’t hesitate to reach out. We’re always happy to talk IAM, or anything — just have a conversation about it and see where it takes us. With that, we’ll go ahead and leave it. We appreciate everyone for listening. We’ll talk with you all in the next one. Thanks.
Thanks for listening to the Identity at the Center podcast. If you like what you heard, don’t forget to subscribe, and visit us on the web at Identityatthecenter.com.