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?
It is a relatively low bar, yes.
I feel safe in that one.
Yes, I feel safe with it too. We do what we do, and there are a lot of good shows out there. I encourage you to check them out — things like Identity Unlocked, with our friend Vittorio. I’m sure there are others out there that make a lot of sense for folks. Yes, we’ve been doing this for a while, and hopefully we’ll keep the ball rolling. With a lot of that shameless promotion out of the way, why don’t we get to today’s topic? I think what we’re thinking today is, we really want to talk around the business and identity and access management. How does the business interact with an IAM program and teams involved, and vice versa? To that, we’re also setting a new show record, where we’re actually going to have two guests on with us today. I would first want to welcome Pierce Chakraborty. He’s a colleague of ours here in Protiviti’s Digital Identity practice. Welcome, Pierce.
Thanks for having me, guys.
One of my perspectives on IAM, and why I think IAM is so cool — and I’ve worked in different areas of IT, from the back-room technology up to ERP systems — is because IAM really requires an understanding of and a feel for the business more than almost any other area of IT, except for maybe ERP, where you’re really entrenched in how the business works. I wanted to know, do you feel the same way, Bryan? Give us a little bit of perspective on how you think IAM empowers the business, helps the business run more efficiently, more effectively, and whatever other touchpoints you see.
I agree. Even devoid of a tool, with the manual efforts to do access management, we have to know so much about so many different systems across so many different departments in the business that we’re usually that single point where other groups come to us and ask us questions that on the surface really shouldn’t be our responsibility. But because we have had to accumulate and craft that broad knowledge in order to do our jobs, we become a resource for other groups.
That only helps reinforce the idea that yes, we are here to support the business. Without the business, there wouldn’t necessarily be a need for us, but it means we have to keep in mind that, yes, we need to approach things with security in mind, but we also have to enable people to do their job, and do it with as few roadblocks in their way as possible. That’s my attitude — how I’ve always approached information security as a whole. It’s like, “Let’s find a solution that actually provides a benefit, rather than just a hurdle for people to get over.”
The business — hopefully, we’ve fostered some relationships along the way. You’re really only going to succeed in IAM if you do get their support from the top down. As in most information security, if you’re trying to push something from the bottom up, it’s going to struggle. Hopefully, we’ve leveraged ourselves to have a good relationship and have trust in the people that you work with so that when we start talking about how we can help the business, they will be our partners and they will say, “Well, yes, let’s do this together. What do you need from us? What information do you need? What resources can we help you get?” so that’s it’s a cohesive two-way communication and not just, “Hey, we’re going to implement this, and you’re going to like it whether you want it or not.”
Yes, I’ve got a perspective on that as well. Two of the ideas that come to mind, for me — like you, I’ve been in this industry for a long time, and I’ve seen the evolution where in my beginning days in security and in IAM, the quote-unquote smart business executive looked at security as “It’s overhead.” Probably, I was more industry specific. I wasn’t in financial services at the time, but even then, it was like, “Security is an additional cost.” I don’t think anybody thinks that anymore. Everybody realizes that it’s a dangerous world we live in. That was point number one about the business, which I think is that now, executives get it, and they’ve realized the importance. When you talk about an IAM program, and they’re like, “Oh, my God. Here’s this security guy trying to get more money”— it’s more than that.
Number two, I think even at the grassroots level, when you’re trying to implement something like role-based access control — or it can be as simple as access request — it requires that the business buy in and participate and, to use a modern phrase, be present. They’ve got to think it’s important, these roles that they’re building. They’ve got to own these roles, and they’ve got to say IAM is important. IT can’t push role-based controls on the business. The business has to own it, or it’s a two-way street. What do you think of that?
You hit the nail on the head with the ownership. I think anyone who gets into the IAM world learns quickly that your technical and business owners don’t necessarily know what you expected them to know. It’s usually an effort of discovery on both parts, but especially, getting into role-based access, that definitely has the flow from the business owner down. We’ve all been in those environments where these 32 people all have the exact same title, and they report to the same person, but their roles are not the same. We’ve got to work with those businesses to find a way to categorize them more logically so that we can apply role-based access control and not have it be one-size-fits-all, then the auditors come in and say, “Oh, this is not good. Why did these people have all this access?”
I’d like to get Pierce’s and Jeff’s perspective. Pierce, why don’t we start with you?
I think you guys hit the nail on the head. Bryan and I spent the majority of the last year working on buy-in. We spent a decent amount of time getting the business to see the value in identity. I think a lot of that comes down to security versus functionality, where the most common thing is — see, as the business, we don’t want to necessarily stop them from doing their job, but we’re just trying to protect them while they do their job.
As times continue, that whole walking that line between the two, I think one thing that we’ve seen is that that’s been the biggest challenge, that we just want to make sure that we’re socializing correctly across the enterprise. When you look at the different components within IAM, when you look at PAM and when you look at the nuances that come in, you learn that all these new methodologies and everything that’s coming out, they’re changing the way of life. You’re evolving the way of life for end users and administrators, and getting the business to buy in and see it and say, “I see — you’re doing this new methodology, and, yes, my way of life is changing. But at the end of the day, you’re making me be able to do my job faster, better and more accurately while being protected.” That’s a win. That story — as practitioners, we need to do a better job of explaining that to the business overall.
I think you guys hit it all pretty much right on the head. I see it as a very symbiotic relationship between the business and IT in general, but we’re talking about IAM. There’s a lot of interplay between an IAM program and the businesses that they are supporting. We see a lot of issues where the business is in charge of doing an access review, for example, and they end up rubber-stamping it because they have no idea what they’re approving. It’s some gobbledygook IT-speak coming out of a SQL database somewhere that is not friendly, unless you really know what you’re looking at. It goes to a manager. Someone here is like, “Sure, it looks OK to me. I don’t want to break anything if I say no,” so they leave it in place.
That symbiosis that takes place between the business and IAM is that, yes, it’s the business data. They should be responsible for it. They should drive how the processes should be working to make sure that it’s meeting their needs, but it’s also on the IAM program to provide them with enough information to make educated decisions, give them the tools to be successful in their role, whether it’s an approver or if they’re making a request for access or for onboarding or offboarding, any other things that are happening from an IAM perspective.
The other thing, too, is, you have to be really smart about the resources, whether it’s time, money, people — nobody has unlimited of any of those things, and you’re usually constrained by at least one, two or maybe even all three of those things. You want to make sure that you don’t waste people’s time. Don’t overpromise and underdeliver. You take advantage of SMEs when you need them, and you free them up when you don’t. You don’t try to automate the entire world. Automate stuff that makes sense, and let the rest play out. Don’t solve a 1% problem and have that hold up progress when you could be doing a whole lot more for 80% of the issues that are out there.
Technology is really a small part of IAM. It is mostly business process and the relationships and the people around it. The technology supports those things that are out there. I think that leads to some of the challenges that we’ve seen out there from the business — and it could be functionality, it could be user experience, it could be security, and sometimes those are in opposite directions and forces that are pushing each other.
I’m curious, Bryan, from a challenge perspective, what are some of the challenges that you’ve seen from the business when it comes to integrating an IAM program, whether it’s a specific process or a specific technology that’s associated with that, that you’ve come across?
The biggest hurdle is getting the time from these other people — they’re just as busy as we are — and then, when you get their time, making sure they’re fully engaged with you and it’s not just “I’ll meet with you to get this over with.” I try to upload — or prepare people to know that there’s a lot of heavy lifting involved with this up front, but after we get all of these parameters established, then things become much easier — things will flow. You’ll actually realize the true benefit of this environment, but it’s not just an easy plug-and-play, and you’re done — working with the business, making sure they understand what our goals are, and that goal should be to make their life easier, ultimately, because when their life is easier, my life is easier. Getting the information you need in order to truly deploy their application or their system in the tool and not have to go back multiple times to get extra information that they just didn’t think was important.
I always put that on both of our shoulders — that, well, I may not have communicated well enough that we need everything. But sometimes, we’ve learned a few hard lessons where some people are very protective of their systems, and they’re afraid to tell you everything, because they don’t know what you’re really going to do. Again, you’ve got to try to develop those relationships. I’ve also learned sometimes those are not handled well over email. You’ve got to literally get in that meeting and talk with them. Probably, a lot of people have these relationships where the email exchanges are very terse and almost combative. Yet, you get in a meeting, and everyone’s so happy to see each other and more than happy to help. You try to leverage what you can to get the job done.
It’s hard to convey tone in an email, right? Emoticons have helped — I’m a big fan of animated GIFs and things like that to carry on conversations — but it’s important to make sure that you recognize time is a value for people. You said that very well, Bryan: People are busy, and you’re not the only one that has things that have to get done. They’re not at your beck and call, typically, so you’ve got to be smart with that time. Do you ever come across issues when it comes to business processes and sometimes, how that might affect configuration in a product versus customization, which might take you down a rabbit hole that you don’t want to go down from a technical perspective?
All the time. As I alluded to earlier, it’s amazing, when you start digging these trenches and trying to lay your foundation, that the people you thought knew the systems don’t know the systems, so you’ll start developing a process. Based on all your information, it should be a simple ABC and you’re done. Somewhere along the way, there’s a right-hand turn that happens that you weren’t expecting. Now, there’s a whole new group involved in this process that you thought was a single source. You try to leverage what do you know, and how does that flow into this, and does it flow from anything else, or does your effort impact other things, too? Maybe you can get a benefit by leveraging all of these pieces together to put in your quiver for later use. But business processes are never as simple, quick and easy as you might think they will be.
Do you ever run into any challenges from an ownership perspective? I think this concept of the business owning the data is sometimes foreign to some of the clients that, at least, we’ve worked with in the past. It’s not a hard-and-fast rule, but there are a lot of times where the business may toss things over the IT wall and say, “Well, you figure it out.” What are some of the challenges you’ve seen around that and some of the ways that you approached it?
The usual access management — “Well, don’t you know everything? Can’t you decide?” It’s like, “Well, no. We’re not here to make the decisions based on our feelings of the day.” We have hard-and-fast rules and parameters that we use. Sometimes, when we’re talking to these business owners and we’ll ask them some of those technical questions, they’ll look at us with a blank stare and tell me basically, “I’ll have to get back with you on that one.” It depends on the person. You can let them go do their legwork, or, more appropriately, you probably should say, “Well, let’s go find that person and talk to them together.” It’s better to get that information firsthand rather than have someone translate it to you, and it’s completely wrong by the time you get it. “Trust but verify” is a good approach.
Yes. I think ownership can be a scary thing, especially if you don’t really know what you’re signing up for and there might be a hesitancy to say, “Yes, I’ll own it.” Only the brave will go there without doing their due diligence. Pierce, what are some of your thoughts when it comes to challenges that an IAM program might get from the business?
Bryan, I think this might hit a little close to home, but from the work that we’ve been doing, a lot of the challenges seem to be level-setting expectations and resource bandwidth, and understanding that an IAM project is not an assessment. It’s not going to be done. It’s not going to be fixed within two days or three days. With an IAM implementation or an IAM project, there’s a lot of complexity, a lot of layers, and we need adequate time and investment. It’s a heavy lift up front, but the reward is there at the end of the tunnel.
I believe that most people, when they get pulled in for requests — everyone has a day job, everyone has stuff they have to do. A lot of times, these projects come in and out, people say, “That’s great. Let me go do them.” Then they say, “I’m sick of doing it.” It’s fair, because their stuff is piling on from their day job. Balancing that out and understanding that, yes, the first few weeks is not going to be easy and there’s going to be a lot of work to do — a lot of discussion and a lot of challenging the norm. That’s why identity seems to be heading toward as it innovates. Having that gap of understanding constraints, understanding — “Let’s lift this. Let’s lift this giant boulder up. Once we lift it, it will be a huge sigh of relief for the program overall.” I think that’s been the main focus that I have seen for a number of years, and it’s been very consistent. It’s a harder problem to fix than most people realize.
It’s funny you used the boulder analogy. I think of the boulder getting picked up, and I think, “What are all the things that are crawling underneath that we didn’t know about?” I’m curious — Pierce, your thoughts, then back to Bryan and then we’ll go to Jim — there’s an expectation that when you come into an organization, whether it’s consulting, or as an IAM program manager or just as any part of the IAM chain, that you’re going to have all the answers. You’re going to have them right away. You’re going to know everything and how to solve every single problem. I don’t think that’s a realistic expectation.
My thought process is, when we’re talking with folks around IAM, it’s “We’re going to start putting questions out there. We may not have the answers, or they may not be readily apparent, but that’s OK.” We need to start understanding what we don’t understand to be able to fix those types of things. I’m curious if that’s something that you guys have seen as well in your experiences. Pierce, we’ll start with you, and then go to Bryan.
I’ll put it this way: I don’t think Elon Musk even has all the answers. The reason I am saying that is, if you look at the questions and the landscape, remember the thing I said earlier that identity, specifically, is such a unique beast because it’s in the heart of so much that the business does, without even realizing that it is in the back end. It’s one of those things where having identity be at the position it is, people expect you to know “How does SAP work? How does ServiceNow work? How does an ERP work? How does all of this plan, and how does it play in identity?”
Very rarely can one person ever answer all that. They might be able to answer at a very high level, but doing deeper, there needs to be a ton of collaboration, a ton of people, and it takes an army to build an empire for this. My experience is that you need to collaborate, collaborate, collaborate to get the answers for this. The other problem with that is, if it’s one person giving you all the answers, you’re only going on one person’s view, which doesn’t tend to end well.
It’s not as diversified. Bryan, what about yourself?
Well first of all, I need to rethink this relationship with Pierce, because I was under the assumption he did know everything. All kidding aside, that’s true. Yes, I think Pierce is right: There’s a lot of heavy lifting. There are a lot of components that have to go together. As we alluded to before, your resource owners probably don’t know everything that you had hoped that they would know. Developing those relationships where you can discover the information together and leverage it is good. I also think it’s important that you define small elements for success, rather than having the big end result always hanging over your head, so that you can show there’s progress, there’s success and we’re building on that success as we go. If you only see the end of the tunnel, you’re going to miss all of those important steps along the way.
Jeff, when you went through this question, you broke it into three parts: There’s the ownership of IAM, the customization versus configuration and user experience versus security. Let me give my elevator pitch on each one. When it comes to ownership, my perspective is that it’s the IAM program’s responsibility to put a good process and a good set of tools in place, but it’s the business’ responsibility to decide who gets access to what. I think we, as IT professionals, want to step up and fill the void, but I think we have to be careful not to step into the role of “We’ll decide who gets access to what.” That leaves the business not responsible if something happens — if the wrong person has the wrong access. It’s got to be in the right hands for the decision to be made, and IT’s role is to then put it in a context so that the right decision can be made for the person with rubber-stamping access and the provisioning of that access happens. That’s my perspective on that one.
In terms of customization versus configuration, my perspective is — and I did ERP before I got into the IAM space — let me give my ERP example: You go and buy SAP, and they’ve got a best practice for creating a purchase order. You say, “Well, that’s not how we do purchase orders. We do purchase orders in this 26-step process. We’re going to make SAP do purchase orders in this 26-step process. Can you do it?” Maybe, maybe not. Let’s say you can. You still wasted, in my opinion, a whole lot of effort, a whole lot of time, customizing the purchase order process, which you bought SAP for because they have a way of doing it.
Look, every time you make a customization decision like that, it has tentacles. Maybe in the end, you did make the right decision to go custom. That’s a business decision in the moment, but if you make that decision too many times, you wasted your money going out and buying a software package. At the end of the day, you’re going to wind up spending a whole lot more money every time you need to upgrade that software, which is going to happen at least every two years.
The third thing that you talked about was user experience versus security. This is the age-old balance of security user experience. Every time you improve the user experience, you drop security. Every time you improve security, user experience gets worse. That’s the old paradigm. It’s still a valuable way to think about things, but there are a lot of improvements that have taken place within our industry, where some new features — things like passwordless authentication — that actually improves security because now you’re forcing the route of a trusted device being used instead of a password, and we know passwords stink. Now, it’s easier for me to log in, because all I have to do is push a button on my phone, but it’s also more secure because it’s not relying on some super password that could end up in a leak.
Another example would be the institution of risk in identity governance process — identity governance and administration — whether it’s using risk as a vector to determine how many people need to approve, or if an access request even needs to be approved at all. Jeff and I love to use this example: “If a role gives you access to read the lunch menu, who cares?” You don’t even require it being written. That’s a trivial example, but take it up a level: Is there a point— some types of access, some levels of access — where if it’s being requested by somebody who works for your company, the manager of the employee, does it really even need to be approved? Some cases, the answer is yes. Other cases, you might be able to say no.
Now, what’s the benefit of that? The benefit is that you start getting away from that person who has a whole bunch of people reporting to them getting overwhelmed with their approving access 25 times a day. They get into rubber-stamping just because of what we call access fatigue.
Those are my thoughts, and obviously, when it gets to those things like risks and passwords, those are level two, level three features within the IAM space, but I think it’s starting to break away from that paradigm that you’re choosing security or user experience. There are actually opportunities where you can improve in both. I wanted to see if any of you guys have any comments on anything I just said.
Yes, you hit on part of that in your customization, configuration area. The view is, sometimes, we’re in assembly line: Give me the information, and I’ll crank this out. Give me the information, I’ll crank this out. We should be able to take a step back and say, “Is that the best way to do this? I think we could streamline this, or come up with a better way that benefits everyone.” Hopefully, your other experience you’ve gathered over your lifetime in IT and IAM would help you recognize some of those areas where you can have a gain before you even put it into place in your tool.
One other area I wanted to get into is, because we’ve talked about the impact to the business — how IAM can impact the business, how business can impact IAM. We talked about how to get there. I feel one of those things that we do when we develop our IAM strategy — everybody’s looking to get buy-in, buy-in, buy-in. We want to have a strategy on buy-in.
My perspective on gathering buy-in is about bringing people to the table, hearing what they have to say. I’m not afraid to ask people, “How do you think this can be done better?” Maybe I’m the identity management subject-matter expert who’s at the table, maybe I know what is considered quote-unquote best practice, but you may have something to say here. Obviously, you’ve been thinking of this problem too. What are your ideas for solving the problem? Bryan, I’ll throw it to you. How do you think the IAM team can partner better with the business overall, and what are your thoughts in terms of that engagement of the business?
It is about partnership, and that implies to me that you can ask questions and actually listen to what the answers are. Good question. “What are your pain points? Is there anything we’re doing here that we can make your life easier? Are we so focused on that end result that we’re missing part of your other job duties that we could accommodate if only we knew about them?” Getting good dialogue — sometimes, even just having a chat and not even talking about IAM at all — is helpful, getting a better idea of “What do you really do? I don’t have a clue what you do in your role on a daily basis. All I know is how we’ve been discussing it in terms of the deployment on the tool. Tell me about your role. Tell me about all the things you do and all the people you interact with.” Sometimes, you can gather some really good information that way. It may not help you directly with that person in that task, but you may get some information that helps you with someone else down the road.
Pierce, what about you? What are your thoughts in this area about building buy-in and engaging with the rest of the business?
Just going with what you and Bryan said, I can’t emphasize that enough. Bryan, especially when you look at where you and I were in 2019, before we got the buy-in that we got, how much of a hurdle we had to get through, and what we had to dig through, and how much easier it got once we got the business to align and say, “Yes — you know what? This makes sense. Let’s do it. We see it.” Then they saw value. Without it — without collaborating to that extent and being transparent with the business — identity programs will fail.
They’re one of the most crucial things to building a sustainable program that people will also adopt and like, which is huge, because you don’t want to design something and everyone says, “Hey, this sucks. We don’t want it,” then rip it out in a year or two years — that happens. Having that layer of transparency — those honest long conversations, collaborating with the business and realistically showing them what your vision is — and seeing, do they hate it? Getting that blunt feedback is the healthiest thing you can do to build out an IAM program.
Yes, I think this is an opportunity to leverage relationships. Part of being a good IAM program manager or team member is making relationships with the business, with counterparts, building trust with those organizations and with your own team so that when you say something’s going to get done, it’s going to get done, and you’re not going to leave someone out there that’s hanging. I think that’s an important part too — the relationship aspect of it and being able to leverage things that you’ve built up. Sometimes, it’s a little bit tougher if you’re new to the organization: You’re walking in, you’re going to have to basically start from zero, or if you’ve been there for a while, you might already have relationships. You might have some not-so-great relationships because previous projects might not have gone as well, but it’s OK to get smarter. It’s OK to get better. I think that’s an area that is also ripe for exploiting where it is appropriate.
I know we’ve been running long here, but I want to make sure that we have time to give final thoughts before we close it out for this week. Bryan, why don’t you let us know if there’s anything that you think that you can add to the conversation that people can chew on out there?
Being identity professionals, we all understand the importance of this space, but not everyone else quite understands that. Then, sometimes, we run under that guise of information security as a whole, and everyone’s tired of hearing the fear, uncertainty and doubt factor. We have to communicate clearly, and don’t forget to accent the benefits that we’re working toward — that this is to help everyone on both sides of this coin. Not just “We’re doing it for us, and you guys, you don’t have a choice.” Communication — you can never talk too much about fostering good communication.
I like that. How about you, Pierce?
I completely agree with what Bryan said. At the end of the day, we’re empowering the business. I think when you take your first IT course, when you read your first IT book, you’ll read that IT is about empowering the end users. For a lot of work we do, that’s the business, and understanding how we can help them, leverage them, but also protect them from all the bad things that make the front page headlines. That’s the balancing act that we will continue to evolve, and hopefully, we can get to a point where everyone will see, “This IAM project is actually making my life easier. Simple example: I don’t have to remember passwords. I don’t need to request for roles. Compliance — it’s all system generated. No more Excel spreadsheets. Yay!” I think Bryan likes that example the best, but it correlates at the end of day to all that umbrella. I think as we go forward, it’s important not to lose sight of that.
Thank you. Hey last thing from me is, everybody, as I always do, open to connecting on LinkedIn? Please send me the connections and Jeff a connection. Pierce and Bryan, are you guys open to connections on LinkedIn from our listeners?
Well, with that, that’s a good spot that we could leave it for this week. I will have links in the show notes to all of our LinkedIn profiles to make it easy to connect. Don’t forget: Identity Management Day 2021 is April 13, and you can visit the show at IdentityattheCenter.com. We’re on Twitter @IDACPodcasts. With that, we’re going to go ahead and leave it. Thanks for listening, and we’ll talk to you all on the next one.
Thanks for listening to the Identity at the Center podcast. If you liked what you heard, don’t forget to subscribe, and visit us on the web at IdentityattheCenter.com.