[podcast] Ron's IAM Program Framework
In this episode, Jim and Jeff talk with Ron about the IAM program framework he is developing and some of the challenges some organizations face when it comes to IAM context and operations.
We hope you enjoy this episode and please subscribe to our podcast for updates on new episodes!
LISTEN HERE or read the full transcript below.
*Disclaimer from Identropy: These transcripts are produced using automated tools, so may not be an exact word-for-word transcription. (i.e. - if you read something that sounds wrong, it's the tool's fault!) As always, for a better experience, please listen to the actual podcast.
Podcast #42 Full Transcript:
Identity at the Center #42 - Ron's IAM Program Framework
Jeff: Welcome to the Identity at the Center podcast. I'm Jeff and that's Jim. Hey, Jim.
Jim: Hey, Jeff. How's it going?
Jeff: Not too bad, yourself?
Jim: Livin the tremendous Friday. On the day we recording here. And that means tomorrow's Saturday!
Jeff: Is it? I don't know. Every day is a weekend, and I thought there was an article this week that Spotify released some like listening trends. And they've basically said that every day is a week is a weekend.
Jim: Every day is a weekday. Because I think the last two weekends I was on my laptop working because when you work from home, it feels like you're always at the office.
Jeff: Yeah, I think work life balance may be a challenge that people are facing right now. And I think it's just something that I've gotten accustomed to as I really, you've got your normal work week and then, based on whatever else is going on, you're probably working on the weekend as well, just like anyone else. So we've got a guest today. He is the man, the myth, the legend. Ron Keys, one of our crack, IAM consultants here at Identropy. Welcome to the show, Ron.
Ron: Thank you very much. It's a pleasure to be here. And tokie of myths, the legends, you guys, the myths, the legends yourselves, that IAM a little bit disappointed in the facilities these facilities are frugal. Where are the audio engineers with the recording studio.
Jeff: We don't have a green room. Right. There's no pastry's. We'll just chalk that up to kov it. How about that?
Ron: All right. That may be a convenient excuse, but yeah, I was expecting a lot more.
Jim: Ron, I do want to clarify this. You entered the identity at the Center podcast, not the Joe Rogan podcast. We don't have five million listeners. We have five listeners.
Jeff: Right. So the budget is commensurate to you, to the number and listenership.
Ron: So I'll reset my expectations.
Jeff: I appreciate that. And so if you want to help Ron and help the show. Right. Share the show with other people so that he get a pastry budget. That would be nice.
Ron: And Jeff, I do have to compliment you on the account above 30 now, I've been listening to previous podcasts and there was some missing I think it was 28 or 29. But now everything is being corrected. So congratulate.
Jeff: Yeah. You know what? The first season we had kind of like we tried to shoot for one every week. And then there was one week where we actually did two. We were at a conference and thought, okay, well, maybe break it up and 10 a week. The first day at a conference, second day, the conference, I called it like he was like 14.1 And 14.2. And then it became a real hassle because it was like, all right, well, we're off one now and then just kind of snowballed. So I just took season two, which officially started, I guess, this January twenty. I just took the opportunity to just let's go back to the number of episodes we have is a number of episodes time, because I was also screening out the introduction because sometimes we record things and then publish a little bit out of order. So I'd say I think there are a couple episodes earlier this year where I was like, oh, this is episode 30. And it was actually like 31 or 29 or some like that. So. So now, peeling back the fourth wall here a little bit. I don't even mention what show number that says because I want to have flexibility to make sure that I don't screw it up. So we end up publishing this. Yeah, it's Friday. The intention is to publish this on Monday, which is the fourth. Hopefully that will, make the cut. And then I don't have to worry about trying to edit out, some weird thing was like, welcome to identity at the center podcast. And then you hear like a voice over with the right number where it is, that's just me making it easy for me.
Ron: You realize I'm merely saying this so that I can prove I'm on one of the five listeners.
Jeff: You're a hard core listener. We need to get you like a T-shirt or something.
Jim: Speaking of conferences, Jeff, a lot of the conferences are pretty much every conference, it seems like that's upcoming this summer. Is now going to be hosted virtually. And I think that might be a good topic to kind of review on our next podcast, some of the details around that. But I registered this week. News came out that the KuppingerCole European Identity Conference EIC is going to be virtual and it's free events, I went on registered, the only issue is if you are a U.S. base. The Times are European based. So there's the six hour time difference. So to be on the start of the conference would start at three a.m. Easter. I don't know. How might I add hard core? You're doing pretty hardcore, but I think my might get up early and try to, have my coffee at like five A.M. and catch most of it.
Jeff: Cool. Let me know how that goes.
Jim: I will do that.
Jeff: There's a couple of things we want to get to, I think. But I guess opening question for any guests that we have is the standard, how did you get into identity and access management? So, Ron, how'd you get into IAM?
Ron: Well, I'm going to give you the standard answer that previous people have given you. I just fell into it. I have an accent. Apparently, people tell me that when I came over to the USA in nineteen ninety five and one thing I wanted to get into was consulting some sort of technology consulting. So I applied to a consulting organization based in Boston, just outside of Boston, in Cambridge. And their activities were in security operations, developing security plans, I.T. service management, management consulting projects that were large scale outsourcing projects and integration and standardization of infrastructures, all those types of areas. So I gained a lot of good information there. However, that company did not survive the 2000 downturn and it eventually closed its doors, which was very unfortunate because I learned so much in that consulting organization. I then joined the company that was essentially a startup at the time. In self-service password management, there was very little in fact, I don't think there was any sort of self-service password management at the time. So that was their main forte, and then I moved into account provisioning and then I moved into access certification and role management and so forth. So that was really the starting point of IAM, although it wasn't recognized as IAM. It did in the early times. But then it became a separate area of discipline, though, fell into it, and then moved to one or two other companies, all in the IAM space. And there's also the IGA space as well. But we're focused on. IAM here. So that's my history in a nutshell. Just fully into it, just gradually within two IAM product Vendor and then moved on from there.
Jeff: I think that lends support to my theory that most people in IAM are falling into it. What you think, Jim?
Jim: Yes. The accidental career choice. But it's a great space to be in and no matter how you land again. The interesting thing. So we had our last podcast. We had somebody speaking about managing access management and servers.
And I kind of came up through a very technical path and made some zigs and zags into program management and things like that. But not everybody starts out very technically.
Ron is giving an example of how he kind of started his path. And by the way, Ron, you did say you came here to United States from another country. I don't think you mentioned which country it was.
Ron: There was Australia.
Jim: Yeah. And what city were you in?
Ron: I was in Melbourne.
Jim: Living the good life.
Ron: Yeah. And like you, I was very tactical when I was there. And when I moved to the states to move into consulting, I had to make a conscious decision to get out of the very technical area and move into a consulting type area.
Jim: OK, well, that's interesting because Jeff, for example, did not come out of the very technical area, came out of more the customer support area.
But it's interesting that we're all now helping companies develop their IAM strategy. And so one of the reasons that we wanted to have you on the on the podcast today, Ron, is that you've been working on kind of formalizing a framework that you used to help with the engagements that you're working on. And when I think of a framework, I'm more or less thinking of kind of a checklist or a way of viewing a problem, making sure you have all. A way to organize it, and as you were describing it to me, I very much thought it in that light as well, but maybe you could give us a two minute elevator pitch on the framework thing you've been working on, and we can dialogue about that.
Ron: Definitely. So when people talk of a program, what constitutes that program? And IAM is a program or needs to be a program if it's not already a program. And so you do need that structure. How do you formulate in your mind the areas of IAM that need to be considered? And there's two main dimensions for IAM. And that's the contextual dimension. And the other one is the operational dimension.
And the contextual dimension is essentially this static part of the organization. What commitment is the organization making to IAM? What is the governance architecture? These are all what I'll call contextual elements because they set the stage or set the scene where IAM is instantiated within the company.
And then you have the operational expect the day to day operations in IAM terms, the lifecycle management of uses audit and reporting and then the other standard operational aspects. User support and user awareness. And so are the main elements, the two dimensions, the context and the operational. And then from there down, you drill into the specific areas of focus that you bring.
Jeff: Is there a particular place that you'd like to start when it comes to either implementing or talking about how an organization has their framework set up if they have one at all?
Ron: Yeah, and I think that's the important thing. So whenever we go into an organization, they may be strong in some aspects and weaker in others. And depending on the organization, they'll have different aspects that their strongest team, not everybody wants to implement in IAM program straight up. It's not a thought, but once you begin talking to them and explaining it to them, they then get that different perspective, that high level perspective of what they need to start thinking about. And when you put it down in front of them, the eyes get wide. They want you take a look there are a number of areas that need to be focused on.
Jeff: I think 10 times the scope is much bigger than maybe people realize that the second and third quarter of effects may be right that can domino, if you're not following a plan or at least have a strategy, become very tactical. Right. And then, whether it's sooner or later, you tend to not support the positions maybe that you've taken in the past with some of the stuff that you've worked on.
Ron: And, I'll give you a recent example where most companies, because I've worked with IAM vendors all the time. And by the way, I have only ever worked with vendors. I've never been on the customers. Sometimes I think is a gap. But I've always enjoyed working with vendors and seeing all the different customer environments. But typically because as IAM, we get cold in full lifecycle management, they want to automate the processes, use the processes, on boarding and off boarding. And that's usually the starting point. And it's only once you get in and start talking to the organization that you realize there's gaps in other areas. One recent example was a company wanted to do lifecycle or is doing lifecycle management. And I wanted to have it automated in a better way. So I asked, where's the termination policy just so that we can align the automation with the termination policy? Well, turns out there was no approved termination policy to drive the requirements for automation, but then we needed to start talking about policy. And so one thing can lead to the other. And eventually there's a realization that, hey, this thing is a little bit bigger than what I originally thought. And Jim, I suspect you've found the same when you have gotten the customer.
Jim: Yeah, I think a couple thoughts from having, one of the big items when it comes to developing a strategy is how far do we take it? Well, the words if you have you're looking at provisioning, for example, how much automation is appropriate for our organization. It's easy just to sit down or everything should be automated. You should have roles for every day and just make everything best in class. That's not always the right answer for organization. And so what I like, kind of the model that attracts me is kind of a maturity model, understanding where you are today and understanding where you need to get to do kind of be a level that's appropriate for the organization. And then I think it needs to be supported by that operational model that you're talking about, one, which is that there's no finish line in IAM, so you let's say you define what the appropriate level of automation is for your organization to commit to user lifecycle management, for example. And you have some provisioning. Well, new applications are going to on line site patient or off line the automation technology that you implemented is going to need to be upgraded. New regulations are going to come down the pipe.
You may find that, you didn't get it 100 percent right in terms of what needed to be automated. You might find that new to automate a few more things, to reduce the burden on your staff. Was just looking at one aspect, which is automation, like provisioning and deep provisioning, for example. And that's where you have to have an operational plan that provides you the ability to keep up with it. And so often when I see with organizations and kind of, especially large organizations that took on IAM, five to 10 years ago, they run into a situation where they implemented what was a best class IAM technology at the time, but didn't do it with consultants. All the consultants split. They maybe had some staff that the staff is no longer there or they are reassigned to other things and then they haven't upgrade the system in years. And people hate it because it's not even that maybe the technology is old and needs to be replaced. So maybe the problem is that the technology was implemented and then it wasn't given the proper care and feeding. And so to me, that's what having a good operational plan is all about, which is how are you going to continue? Well, there's a couple of things to offer. There's the management aspect. I'm just talking about like the technology aspect right now. How are you going to maintain this system? And doesn't mean just rebooting servers when they go down. But how are you going to do break fix and enhancements and upgrades and other, you know, future integrations?
Ron: Right. And it's some people refer to IAM as a duty.I prefer to characterize it as a continuum because to me, a journey implies the beginning and the end. And as you say, there is no rule into IAM. It's a continually changing area either in technologies, best practices, regulations, whatever. So that's why the commitment is so important, because it is a duty. It's not just a implement set and forget type situation. That's something that you do need to run and maintain and modernize over a period of time.
Jeff: I would say from my operations, experience Jimmy hit. The most important thing is the care and feeding of your systems, having been in that position where, budgets are cut or, you know, patching isn't done, whether it's from a server standpoint or from an application perspective. Nothing will kill an awesome software, and this is just IAM, Anything unless you keep up with it. So, I think it's incumbent on if you're going to do IAM. Make sure you treat it as that continuum. I'll throw it out there for my true detective fans. You know IAM is a flat circle. So, you're always continually in some mode of plan, build and run. And that's just the way it's going to be. You know, if you're running it, you're going to have feedback coming from customers of your services, whether internal or external. And you've got to make changes. You need to get those into the plan and then build those out and then release them and then is kind of constantly going around and around. And then something new is going to come along and, you know, thrive. Throw everything out the window and, start fresh from a strategy perspective or from a deployment perspective. So you have to be prepared to support it for the long haul, for sure.
Ron: Yes. And Jim, you mentioned companies is some large companies may have entered into IAM five, 10 years ago. I'm sure that if you look at the vendors who are around 10 years ago and those companies invested in those vendors, how many of those vendors is still around? Because there's been new entrants into the market. Products and so forth. So, yeah, there needs to be that constant run and maintain care and feeding and modernization.
Jim: I was thinking of a particular client who implemented Oracle Identity Management. And it definitely had a bad reputation within the organization.
But I really didn't feel like the product was the sole reason for that. I mean, look, I'm not going to wave the flag for that product, but the situation.
This particular client was they planned on all the care and feeding being done by consultants and they had an undertrained level of full time staff. And when that consulting budget got cut, kind of the example Jeff gave the system just didn't get upgraded, didn't get enhanced. And people really hated it. And it's just not a winning model. Even with the best technology out there in Lluvia, the most up to date and the kind of the winner, it's there's more to it than that.
Jeff: Here's a side question for you guys. How long do you think IAM Technology should last in an environment? Just a gut feeling. Five years, 10 years. Do you think is a good timeframe to say, yeah, we got our money out of that? Let's focus on one technology. Let's say IGA, for example, Identity Governance Administration, because there's a lot of technology that can last for years and years. But if you're going to buy an identity governance platform, something like a SailPoint or Saviynt and Omada, how long do you think you should get out of it?
Jim: That is a tough question. And I'm trying to think through the history.
Right. If you plot a technology 10 years ago, you surely would have been running it on your own servers. So is the question that you're still with the same vendor or is it that you're still running the same implementation? Because, certainly if you buy something, say you bought SailPoint 10 years ago and you haven't upgraded it, or even if you upgrade the software, you're still running it on Prem. That's an old model now. You got 10 years out of it. I think most people would say bravo to you. My feeling is if you get less than five years out of it, there is either a mistake in what you purchased or how you implemented or how you set up your program. I think if you got 10 years out of it, bravo, because that means you pick the winner and you got in to the curve in terms of the delivery model at the right time.
I mean, you can still buy SailPoint most IGA solutions in a delivery model that's on Prem. That may not even be the case. Three, four years down the road.
I would expect that, is going to be limiting on prem options. More or more of it is just either being in the cloud as a software, as a service or in a host of models. So I'll give you the classic consultant answer, which is it depends.
Ron: I've been thinking as you've been talking and I think that five to 10 year timeframe is probably about it. One of the reasons I say that is if something was architected and there's very few who is still independent, that they could get acquired or whatever. But the architecture of 10 years ago, when the product it is designed, it's architected based on the technologies at the time, the architecture of the time, and then the company will expand and add to it. And eventually you'll get to the point where some of the new technologies that are coming out now, like II machine learning, risk assessments and so forth, incorporating some of these new capabilities and newer functions within their product. That was I could take that 10 years ago, that using technologies of 10 years ago, it becomes problematic for the vendors they, need to start shoehorning functionality into something that maybe should be rewritten. They don't want to rewrite because the investment has already been made. And the last thing they want to do is rewrite according to modern protocols, modern architectures and modern coding types standard. So, I do see that there is some lifetime where a vendor product may become obsolete.
Jeff: Yeah, I think I agree, but I think it's somewhere in that five to 10 range is if you've done a good job. Less than five. I think so. Somewhere there was an error made. And I think, you're seeing some these vendors also come up with different products. Right. They may have started as an on-prem solution and now they're getting into delivery models, SaaS type model, something like that, or service so that the landscape continually changes. But I think that's something that people need to think about is how long should they be getting out of it? Right. These are not ten, fifteen, twenty plus year, things like a mainframe. Right. Or some sort of, COBOL database, despite what our government might be using, those things are a little long in the too different if you want to continue to be competitive, you probably only need to re-evaluate, how long do you want these technologies in there? So digressed a little bit. But, when it comes back to the operations standpoint, I think that's always important, too, is the assumption is that you're going to keep these products fed right or whatever it is, whether it's and it's not just products. I guess it's the program itself, right. That it's adequately resourced from a people funding perspective, that you've got the appropriate policies and procedures and those will change over time as well. Standards OpenID didn't exists until the last couple of years and think for SAML before that. And, at some point block chain, maybe we'll make an enterprise appearance. I'm still not convinced on that one, at least at this point. But things like Self-sovereign identity, and the ways to manage that. There's always something new. I think as long as, organization recognize that and is adaptable, I think they'll have a lot better chance of being successful from a program perspective.
Ron: Yes. And certainly some of those items you mentioned, like Block Chain, you bring your own ID, is definitely worth watching closely. But this jury is still out as to how they're going to be applied, definitely worth watching.
Jeff: So we've got IAM in context, IAM in operation and I'm calling this Ron's IAM program framework. Do we want a better name? Or is that how we're going to brand it?
Ron: Well, yeah. One of the trade markets.
Jeff: I feel like we need to like, come up with a better term than a framework, because if we go Ron's IAM program. Right. It's RIP our IP, which maybe isn't so great.
Ron's IAM program execution or ripe. Right. Is your program ripe.
Ron: The possibilities are endless.
Jeff: No, exactly. Make sure no one steals that domain name. Go register that now. All right. Is there anything else that you want to bring up, Ron or Jim, regarding this program framework around context in operation?
Jim: Well, there is one thing that we're champed on before we jumped on the recording. So I wanted to bring that out. I think, Ron, how would you frame the discussion? Like what is the role of information security And IAM? Kind of talk through that and then I'll give my two cents.
Ron: As I said earlier to me, information security is essentially a set of policies to drive the underlying activities IAM the DLP you name it, information security drives those elements. The complexity of IAM in it. Let me take a step back, a lot of these technologies, DLP, SIM and so forth. They are technologies for the Information Security Group or the IT group. They don't extend that to the user community. And also, they have fairly isolated in that they perform a specific purpose in a specific area. IAM has a number of integration points. It reaches out. It crosses hours or silos within an organization. It's very, very cross-functional to do a DLP solution. You put it in and it's not cross-functional, but everything about IAM cross-functional. And therein lies the complexity of IAM. And so IAM is is one thing that becomes more user visible or more cross-functional. And that's where the complexity of IAM.
Jim: Jeff and I get asked on our projects all the time where it is IAM along because I think you brought up the point, which is that it's like an application or middleware. It's not just security. And should information security run, should desktop support run it? I don't think there's any one right answer. But one thing it does create is a bit of a bit of a challenge that information security is primary purpose is to set the policies and standards for proper cyber security for the organization and then to police it. And so then they become in a position with the. With that IAM platform that they are not only the ones who are providing the service, but they're also the police over that service. And so that can create a conflict of interest. I think a primary purpose just cannot be lost sight of that. I think of a great example of that with this shift of everything out to Amazon Web Services and Microsoft Azure and all the cloud hosting, and they move in to DevOps and the need to push security management out to the folks or actually, performing the operations no longer can we just centrally manage all the security because it's moving too fast and it's too widely dispersed. It's just like IT can't do every, can't manage every application, every Web site and every piece of technology throughout the organization, because a lot of organizations, all they do is manage technology, everything that they do.
Their product is technology. So IT can't be the only ones who manage technology. The business has to at some level manage technologies by going back to those DevOps model is that is moving so fast. Developers have to integrate security into their processes. Infrastructure teams have to integrate security into their processes, and information security needs to be the police overseeing that. You've got to insist on the tools that give them the visibility in the means that they'll understand and be able to consume that data because there's so much security data being produced by organizations these days that can't be lost sight of. And information security may have a delivery function, right? It may be a service provider in many ways, but it can create a conflict of interest. So I still see I would say most organizations IAM still in the umbrella of information security. I think that's OK. But you just have to understand that it has the potential for conflicts of interest and you should have a strategy around that, which should be that is not the same individuals who are responsible for delivering a service and providing the service to the organization and then policing their service.
Ron: And I think you're exactly right about the speed of things in the cloud and DevOps. And I think it's worthy of another discussion of how IAM as good to support and accommodate that new world as it is moving very, very fast. And there are a lot of other security implications.
And I think the traditional management, through the management, through traditional IAM products is currently not keeping up with the DevOps and the security required in the cloud, AWS is in all these other.
Jeff: Some interesting products out there that have popped up over the last few years to help with things that CashCorp and CloudKnox is one that I looked at that I thought was really good. So I think it's an evolution and it's part of that. Again, that flat circle continuum of, the cycle of improvements and being able to adapt with it. Today, I feel like someone has to own it. That's my name requirements. Someone owns it.
Ron: And it's to be interesting to watch all these products like CloudKnox and so forth, and how the traditional IAM vendors work is going to be consolidation of the industry and cooperation of capabilities or products into traditional vendors. That's going to be interesting to watch how the industry emerges over time.
Jeff: I know I spent a lot of consolidation last year, as I would imagine that, as the big behemoths continue to grow, I continue to until it to acquire areas that they feel like our strategic to their growth some years.
Ok. Ron or Jim. Anything else that you guys want are bringing up before we wrap it up for this week?
Jim: I'm ready to wrap it up and start the weekend.
Jeff: Yes. You guys are open enough this weekend.
Ron: They are. I mean, Massachusetts was still closed down.
Jeff: Yeah, same here in Chicago everywhere. We're closed down too little to at least the end of May. Jim in Georgia, which is opening up if it hasn't already soon, right?
Jim: Yeah. So you can get a haircut if he'd made an appointment. I mean, all the work is underreported, Jeff, is all the rules that exist within, you know. Yes. You can have people sitting in at a restaurant. Most restaurants do not have table seating. The reason is that the rules around it are so strict in terms of and the waiters and stuff can't touch food.
And when it comes to, you know, the haircutting that only some people can be within the building at a certain time. So it's not as open as maybe people think.
Jeff: Yes, the social distancing thing, I think it's really difficult to enforce. So it'll be curious to see how that little experiment plays out. I think there's good news for everybody, though, is Domino's is putting a sticker on their pizza boxes, if it's been tampered with. So if anything positive has come of this recent commercial indicates that once it comes out, the other no human touches it.
Jim: I guess that's more of a Marvel Little Caesars guy myself or I like I'll get my local place are much better.
Jeff: Right. Or make your own right.
Jim: Absolutely. That's pretty much been the case lately.
Ron: And I'm seeing Jim is a test case. And we're going to be watching Jim very closely.
Jim: Somebody has to do it.
Jeff: I'm going to put a Web cam right on Jim and just watch for symptoms. All right. Well, I think that's a good spot. We'll leave it for this week. Appreciate everyone out there listening. I want to thank Ron for helping out with this episode and joining us. It's always great to have you back here soon. And hope you folks stay happy and healthy. And we'll talk to you all on the next one.