Listen to Identropy's Jim McDonald and Jeff Steadman on their podcast at "Identity at the Center".

PODCAST34
 
Both Jeff and Jim have over a decade of experience in the Identity & Access Management space and guide companies on their IAM Program journey through Identropy's Advisory Services arm.
 

In this episode, Jeff and Jim talk with Esteban about the approach he takes in managing IAM risk for his organization.

The Institute of Internal Auditors (IIA) Position Paper: 

The Three Lines Of Defense In Effective Risk Management And Control

Brought to you by identropy.com

Want to join the conversation? Leave us a message here: anchor.fm/identity-at-the-center/message or email us at questions@identityatthecenter.com .

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 #34 Full Transcript:

Identity At The Center #34 - IAM Risk Management with Esteban

Jeff: Welcome to the Identity At The Center podcast. I'm Jeff. And that's Jim right there. Hey, Jim.

Jim: Hey, Jeff. Doing this call today from home. I got my mask on, so hopefully my audio is clear. I know there's nobody around me. I just completely paranoid.

Jeff: Well, it's a fashion statement.

Jim: Yeah exactly. I look really good in my mask.

Jeff: You're like those rock stars. Right. That whereas like that mask over their face and the other shirtless. It's just totally, totally unique vibe.

Jim: Yeah. I could take my mask and I could put like one of those cool tribal tattoos on it. Now that's a really good idea. That's why people tune into the podcast for ideas like that.

Jeff: Ideas like that. And the visuals disturbing as they might be that they may invoke. So we were in the middle of have a break of travel. I know you were in New York last week and I was in San Francisco for the RSA Conference. It sounds like we've both survived at this point.

Jim: Yeah, getting a little worrisome. But I mean, we're road warriors. So what are we going to do?

Jeff: Well, you got your mask in buckets of hand sanitizers, which is becoming increasingly harder to find. But I'm sure will supply will ease up, too.

Jim: It's just alcohol gel. So it's not like it's really that hard to manufacture I think.

Jeff: Yes, that's the whole thing, those where is it coming from? Is going to get there. So we have a guest today. We've got Esteban he manage an Identity and Access Management or an analytics firm. Welcome to the podcast. Esteban.

Esteban: Hello, thank you. Pleasure to be here.

Jeff: Great. So I know that we're gonna have a couple different things we talk about today, but before we dive into that, maybe you can talk a little bit about how you got into the IAM field is that's typically how we start.

Esteban: Sure, absolutely. So I started out on the technical side. I worked as started up in a long time ago in the help desk and worked my way up through several different companies and did system administration, system engineering. And recently of a few years ago, I was specializing in messaging and Microsoft messaging with the exchange and I got into a project where we were doing e-mail consolidation from different companies were consolidating into one email system. In a way that system was designed architecturally was that we were gonna use password sync so that the outlook clients would be able to connect from different domains and to that domain we were hosting the email system.

So I kind of fell into it because I had to get those accounts to sync and I was looking for ways for that to happen. And that's one of the functions of IAM, to maintain the password synced between accounts. I didn't know it at the time, but I started looking at different ways to do it. I was good at scripting with PowerShell. So I did a lot of scripts to manage attributes in accounts so that they weren't sync between different domains. And it's a number of domains, right? So like around 50 at the time. And so there was a lot of work there and then that evolved, too. Well, it's taking up all my time to get this to work, right. What tools are available in the organization that can help manage this? And we had at the time we don't have this anymore where we had a CA identity manager and nobody really owned it. So it kind of took ownership of that. And what I mean by nobody owned it that I couldn't identify who the subject matter expert. So a De facto after a couple of months after years. So people just started asking me about the system and I had some answers and before you knew it, I owned it, that was a subject matter expert.

It's funny Jeff, to show off when we meet with clients for the first time. I can hear your voice booms IAM here and all the blank stares you get like, what does that mean? It means she's just like bones talking about.

Jeff: Yeah, exactly. I was just thinking too, if you're scoring at home and this was like our first episode was out of people get into IAM I'm gonna count Esteban and hopefully he will agree is that you kind of fell into it. Is it something that you kind of just started? Would that be fair?

Esteban: Absolutely. I fell into it and I started using the word IAM myself. And other people started using it and it became a thing here.

Jeff: Well, I feel better about that. One argue the other position, but I have all the data points that I like. Let's say that most people fall in IAM.

So why do we talk a little bit about, you know, What is your current role like? What do you when I say you manage IAM for an analytics firm. You talk a lot about your day to day and your role.

Esteban: Sure. So like I said, when I started out in the technical side, I was working in the IT department and I was focused on getting things to work. But there's a security aspect to this, right?

And I started to get involved more in the managing the controls of security because of audit. Right. Audit would get a finding. There was no one available to answer it. So I would jump and say, hey, I know about that. Here's the reason why the accounts weren't terminated, for example. And so  I would create a report and the administration. All right. So that's really how I got into administration. And so I did identity administration, because there was a maturity level or very low maturity level. They put it that way. There was a law maturity level in provisioning. So there was a lot of manual work. There was manual terminations. There was a lot of work was done that helped us,  some ownership was in other departments or access management of applications. Access management to a specific domain would be done by one group as opposed to a centralized IT organization. And at one point in time, the organization decided, you know what, this is really part of security. So I was asked to come part of the security department. Right. Which is distinct from IT reports separately, completely separate from IT. It doesn't report up to the CIO. It reports up to the risk and compliance.

Jim: Let me push you there, if I could Esteban, so I do see that in certain organizations and what I'd say probably in the majority of organizations, I see information security within IT, do you have in your mind, What are the pros and cons of having information security with the IT versus outside? Because for me, having information security outside of IT, kind of enforces that concept of the watchdog. It's,  not the  fox guarding the hen house, a true watchdog guarding the hen house, watching out for the fox. What are your thoughts when it comes to.

Esteban: So there's a service delivery aspect to IAM and a security aspect to it. Right. So let's take password resets, for example. If someone calls in because they need access, they lock their account, they need to reset the password. They expect to call the help desk and get the answer and get the accounts unlocked right away or get the password changed as a service. Expect that to happen as a routine. A routine call now on the security side. The whole reason we have passwords in first place is to prevent unauthorized users to get in or is people guessing the password. So there's the security aspect side. Someone has to determine what the policy is. How long? How many tries is it going to take for the password to lock up the account? How often do you have to change your passwords? That's all built in to the operational management. Right. What I called the first line of defense. It's all built in. It's operated by the Help Desk. In most cases. And that's the security aspect of it. So the operational or service delivery aspect of that operation is an expectation of sort of like a SLA. If I call in, I said I shouldn't be questioned. I should just get it, get access to my account. But there's a reason why. Why That your account locks up if you don't know your password. Right. You might not be the person that is trying to get access to the proper account.

Jim: Yeah. That's an interesting perspective. And Jeff, I know you've seen this do the delivery of these services versus that watchdog function when it comes to IAM, IAM is a little bit different than maybe, you know, infrastructure services and things like that. I believe in them. I mean, a lot of times IT is delivering this service, whereas information security has an oversight function. It would have. What have you seen or what are your thoughts there?

Jeff: Yeah, I think, I still see IAM rolling up formation security and from a security rolling up the IT as the most common, but it's not unheard of to have it roll up to something like risk compliance or even legal in that one. I guess I don't really care so much where it rolls up on to. To me, it's more about does that organization have enough? You know, the security team have enough organizational impact, whether it's any access management having the right to use the will push forward policy procedure, best practices or whatever it may be. I've seen things where CISOs are buried down within an IT organization and, they report to like an infrastructure person. And you've seen CISOs that report directly to the CIO or the CEO. So I don't know if this is really the right or wrong way to do it, as long as that person has enough authority to drive changes with the organization. That's part of the more for. Politically you'd want to be buried that law, but you know, with any organization I would say, the higher the better just because it assumes some level of authority within the organization.

Jim: Yeah. And I've seen situations where CISO's they don't have any direct reports and I keep driving all the change. And the CISO is more of just a policy center. I've also seen a situation where a CISO owns a lot of IT services, including IAM and one of the pros. And you know, if we talk about the concept, that situation is that, CISO would be responsible for approving security testing, for example.

And, when you're approving security testing and you've got you're the certain standards, this kind of testing, those must be performed, all the high risk items are resolved before going live, etc. And when you're a watchdog, we can kind of stick to hear the guidelines. Now, all of a sudden you're a CISO and you have to deliver to a commitment that you've made about going live on whatever March 1st. And you're IAM team comes to you and says we're not you know, we've got these high issues and things like that. And now the CISO is stuck.  I can either stick to my framework or I can meet my commitment of going live on time. And so it's a tricky situation. And I think from the standpoint of, as this consultants whose people say does what is best practice. And I think we see it working well in multiple different scenarios. But I think you need to understand the pros and cons when you go into that and kind of choose the model that makes sense for your organization.

Jeff: Yeah. I come from organizations where the CISO, a lot of service delivery. And, if an organization can't trust their CISO and you got other problems than me. It isn't. Sure, there's going to be things that may affect service delivery when it comes to do things of production or not being ready or serving, security checklists, etc., but ultimately it's a risk decision. And just like any other business, whoever heads up that art is going to make a decision based on that. And ultimately, if things work out great, if they don't know, they're on the hook for responsible for it. So I think anybody who is in a position of approving things like that needs to understand that. And hopefully they do, by the time they reach that level.

Jim: Imagine the scenario where you're rolling out a brand new IAM platform. You're spending twenty five fifty thousand dollars a month in consulting. You've delayed the go live twice already. You've committed to a new goal out of date. You get there and now you're having some issues that are within your power to grant an exception for. So that's the best scenario. And I think you're right. I mean, it comes down to integrity, but it's also, Potential conflict of interest.

Jeff: Yeah, it's certain I can certainly see where that might be. Esteban you were talking about operational management. And I know that before we started out, I guess you were talking about three lines of anthrax risk management and how that's affecting your IAM program.

Operational National was number one. What was number two and number three? I mean, we can dive into a little bit around those other topics.

Esteban: Sure. So the second one is actually called the second line of defense. And that's more. Yeah, I haven't made the I did not make this up. So I hope it does come from my institution of internal orders, I believe. But I find it very useful because as I look at the program and I work on developing it. I use the model of the three line of defenses and I'll describe the second one  is really overseeing risks. Right. I look at the second line offense as somewhat more independent from operational management with the controls exist so that there's latitude in the ability to perform monitoring and assign accountability. So in operational management, there are system owners, right? There's also data owners, business owners. And sometimes they don't know who they are. Right. So with some independence and some monitoring and risk management aspect to the IAM program, you're easier able to identify and communicate to the business that you're the probable owner of this resource. And this is why I. So the metrics you can show them the location of data  systems that are not claimed by anyone, you can say, is this your system? If it's not, then whose is it? Should we decommission it? Does it belong to any is that orphaned and so on? So that's  where that type of thought process off to me falls in the second line of defense. I take a step away from operational management. I have a chance to independently look at the environment, examine the data collected. Set up monitoring. Right. And then go back to the business and mainly really determine. Talk to the business. Talk to the system owners. Make sure that those risks are assigned to someone so they can be managed.

Jim: And yeah, we talked about this a little bit before us launch. So you maintain some sort of risk register. Right. And you talk about then kind of what form it takes and what are the different data points that are collected in a risk register.

Esteban: Right. So. So just to be clear, we do work. We have what we call information risk officers. And they maintain a risk register. Right. So it's  not specialized risk register. It's the overall organizational risk register. Where for example, if I can't find the owner of a resource, I can't assign ownership or accountability. And nobody takes it. Well, that's  a risk. That needs to be escalated up to senior management. And that's where the risk register kicks in. So I work with my information risk officer for the line of business. Right. Identify the risk. A document that. And then they bring it up in senior management meeting.  So like that. They can accept that nobody owns a resource. Right. And they can't be governed or we can't do any access or views on it. And at least they know and they have to either accept that or try to mitigate or come into getting on a plant.

Jim: And that's excellent. So you're saying The risk register IAM, the impression I'm getting is that it goes beyond just IT risk. There's probably other forms of risk, certainly within your organization. My experience with the grocery store is to the key levers within that our likelihood and impact of arrest. So, we could talk about. Right. Well, Corona virus could it impact our ability to deliver IP services. What is the likelihood that is going to happen? You know, you could do something like high, medium, low. And then what is the impact in terms of cost impact to the business or ability to provide services which could be related back to cost you something similar in your research?

Esteban: Well, absolutely. So there are risks that may merit a lot of effort, time and money. All right. And there are risks that may be acceptable. What I don't want to get involved in is making the actual decision as we're trying to step away from being the risk owners. So that we can have that second line of fence oversight over the organization. So going back to assigning ownership. Right. Or a resource or a process. You were able to present the risk. And together with the information risk officer, we can determine what the risk level is and what the risk owner really. We get together with the business, the risk owner, and determine what the level of the risk is. And we document that in the risk register and then the risk register still contains the elements of information that determines whether it's the recommendations are made to accept the risk or to elevate the risk and re mediate the risk.

Jeff: So that's the second line of defense. Risk management first line was operation management. What's the third line?

Esteban: So the third line is pretty much audit. All right. So. Collecting artifacts right to what audit comes in and accept wants to look at your operations, having the ability to easily produce artifacts, having good auditory else. These are things that you do would do in the first line of entry that or your second line offense. That's it would fall to you. You would actually the way I would look at it is I would make sure that the first line of defense as a second I'm the fence operator, I would make sure there's  a good audit trail on all the management controls. So then what audit comes in? We can produce these artifacts for what they're. Ask you anything that they're asking for. But here's  why I think about this. Really? And why brought it up in the first place? Third line of defense. What I notice over the years, what's been happening is that audit would come in, look at the controls, examine it, and they would find gaps. Right. They would find gaps in risks and ask us to re mediate it. So what would happen if we start fixing things. And in effect, instead of designing controls or IAM who would be reacting? Right.

We would be doing security by audit. I would say instead of buying of security by design. And then you can get stuck in a mouse wheel doing that over time, because they can compound over time. If you're not monitoring if you're not evaluating risk or designing security into your first line of defense or audit will come over and point it out. Right. So it takes an extra effort to spot things that should be improved. Like being able to see blind spots from your second line of defense vantage point that you sometimes cannot do as owner of a control. Right. Because you're busy running the business. You're just operating the controls. You're managing you're just responding to the cue that say if you're the helpdesk right, you are interested in resolving as many issues as you can. With the processes there in place, but you're not necessarily spending a lot of time looking at the risk and as a second line of defense operator, you're spending more time in the oversight function to be able to spot those were stuck before the third line defense kicks in and finds it, or you.

Jeff: Feel like sometimes audit controls can be a little bit like sticking your fingers in holes in the boat and you end up with so many different holes and so many different fingers. And it's like, OK, well, if it's not by design secure, then you're going to run out of bugs put in there. So I can see.

Esteban: And I think in a lot of thought went into, well, how do we manage that? Because we're so busy operating our controls and responding to evolving situations that are based a lot on service delivery. Some of its security. But when audit season, I would call a colleague comes in. Sometimes we find things that we weren't aware of because we didn't have continuous on during on a particular item like, let's say, for example, terminations. So if audit finds that an account was terminated on time. If we tell them all they get terminated 24 hours after their termination date and you have a management control that does that, let's say, out automatically with your identity management system. You don't think about it a lot. Because you have the system is taking care of it. You don't think about it until audit comes in and find something that hasn't been terminated for over that time period that you told them does.

Jeff: Yeah. Then it becomes a matter of what happened with that, right? Trace backwards. Okay. Well, you know where they terminated in the HR system having an error and sometimes it happens. Maybe, something's broken. I've seen things where Know Control highlights an area where for some reason the IGA application didn't function as it was supposed to.

And I've also seen it where, it's a process breakdown. Ahead of that, where the IGA application did exactly what was supposed to do, it just never received the information.

Esteban: Absolutely. And usually over time, as we've matured the terminations and functionality and the IGA system, it's usually a process issue. Right. When the process changes, it's in the HR system or in HR in general or even finance. Right. If finance codes change, it's multiple departments that get involved in provisioning. And if something changes there, you may not spot it without good monitoring. So setting up monitoring from the perspective of a second line of defense function ahead of audit, you don't have to respond to audits as much as you normally would have to. At least that's the goal.

Jim: And I've got a comment and then a question. So as you're talking about this, I'm taking a lot of what you're talking about with the audit is no complaint should then whether it's compliance with regulations or compliance with your own policies and standards. I'm also thinking that, we as IAM practitioners can only live within the realm of a complaint, only boxer check. We need to make sure that the environment is secure and that ought to be probably our most important driver. Thinking, I've just a couple random boxes. You're talking thinking about identity governance as kind of a backstop to that so that if processes don't succeed, you're going to catch that this account was never deactivated in the first place. So, really, to me, that's one of the biggest benefits that you get from identity governance. And I talked to myself one away, then identity governance serves the role of monitoring. But you mentioned monitoring a few times. And I wanted to get from you. What are the components in monitoring that you're talking about here?

Esteban: So in the examples I've used the most basic form of monitoring because comparing reconciling the HR systems with the access system. Right. Making sure that and that's a challenge because like most companies, employees and consultants or contractors, contingent workers are managed separately, separate processes from the auto perspective, it should work the same whether they should either have access. When they're supposed to have access or they shouldn't. And if finance manages contingent workers separately, then HR does because HR is more concerned with management of the regular employees. Then I have to develop governance processes. To monitor any discrepancies between finance and HR To catch contingent workers that don't belong in the system.

Jim: Yeah, I think contingently workers is a big one. I mean, my experience with running through audits is normally. All right. Well, let's use myself as an example. Jim McDonald is terminated on such and such a date. And now we're going to check a few systems to make sure that his account was shut off. My bigger concern from a security standpoint is, well, Jim McDonald was a system administrator. Maybe he created some accounts and test accounts and things like that. Even if his front door access is turned off. What if he were able to somehow get onto the network or just, provide those network provide those application credentials to somebody else? And you have now a weak point within your system. To me, that's one of the big benefits of governance, is we're not just looking at Jim McDonald's HR account. His main idea or even just like his domain administrator, I. But we're also going to each application point. All the accounts are entitlements into a system. We're obviously marry up the  obvious, the Jim MacDonald main account. But now we've got a bunch of other accounts said don't seem to fit to an individual. Somebody who's got to tie those accounts off to a person or somehow those accounts need to be managed and fucking machine to machine accounts. Trust accounts and shared administrative accounts. Somehow we need to make sure from a security perspective, they might not get caught by audit, but we need to make sure that those accounts get shut off. And that's a big benefit of a well-designed governance program.

Jeff: Yes I agree with that because I think sometimes auditors are enough, but I don't think that's really what you're saying Esteban is. If you've got your risk management framework, your compliance functions and your orders and your operations between the three, you should be covering, not only what is, but what should be with any environment, though, between technical controls and business process. The goal is to be more secure. And that's pretty much what you'll be looking for.

Esteban: Absolutely. But that's getting ahead of audit, right? Because they they've also been evolving. I've noticed and the scope of audits have been getting ever more sophisticated. And it's only a matter of time that you start looking at like RPA accounts, which are being deployed into finance.

Jeff: RPA is robotic process automation.

Esteban: That's correct. So the robotic accounts are very similar to the human accounts in that they're interactive, right? Can you set them up to log in and do functions as humans? But they're not meant to. So they need to be managed. Right. And if they're involved in activities that are regulated, there are socks regulated, then scope of audit increases and setting up governance over non-human accounts becomes much more and more.

Jeff: Yeah. And we had a our last show, we talked about a little bit about Internet of Things. And I think that all input. I think that's probably a good way to break it right now. I certainly appreciate it. Know you spent with us here yet again those three lines, the defense's case. People want to recap police operation management, risk management and audit side of things. One, two and three. Esteban or Jim. You guys, anything else that you'd like to add to that before we wrap up?

Jim: Yeah, just one quick question. First one, you mentioned the standard framework that you reference. Can you recap That was.

Esteban: Sure, so there's a publication from the Institute of Internal Auditors. It's called a position paper for 2013. So if you Google that IIA it's an Institute of International Auditors Position Paper 2013, you'll find what I've been looking at to think about how to develop my program based on the front lines of defenses.

Jeff: What was that number again?

Esteban: So it's the name of it. Institute of Internal Auditors Position Paper 2013.

Jeff: I will look for that. And put that into the show notes hopefully. So you can reference that as well. All right. I think that's a good place to leave it right now Esteban appreciate the time you spent with us here today. And I look forward to talking to you in the future.

Esteban: It is a pleasure.

Jeff: We'll talk to you, I'm sure, at some point sooner rather than later. Yeah, stay safe out there. Keep listening. And if you like what you heard, don’t forget you can listen to more episodes at identityatthecenter.com. And we're always looking for feedback  or just general comments. Send those to questions@Identityatthecenter.com and I'll see you all in the next one. Thanks!

 

 

 

 

Jim McDonald & Jeff Steadman

Jim McDonald & Jeff Steadman

Jim McDonald is a professional with over 15 years leading teams through business-critical technology initiatives. Technical Strategist, Leader and Champion of Change with history of crossing organizational boundaries, cultivating strategic alliances and building consensus and alignment among diverse constituents to leverage IT as strategic asset and deliver solutions that rejuvenate and advance global business’ financial performance. Also as part of our advisory practice and with over fifteen years in the identity and access management space behind him, Jeff Steadman helps develop realistic IAM strategies and provide vendor agnostic recommendations to move the needle on IAM maturity for organizations large and small.