Hello, everyone. Welcome to our exclusive virtual event series, ID:30. Today, we have 30 minutes of blazing insights to help you successfully navigate the unique challenges of approaching IGA program needs from both a technical and a strategic level to ensure businesses' and users' needs are achieved. Our speaker today is One Identity's Senior Global Strategist, Robert Kraczek.
With more than three decades of security experience, Robert has worked with customers in all major industries, as well as local, state, and federal governments. His interest in identity governance started as a cryptographic communications specialist with the US military in the late '80s, and that interest continues to this day. Welcome to ID:30.
Thanks, and welcome, everybody. I appreciate you all taking the time to spend-- spend a few minutes to talk about a very important topic in the IGA space, and that's how to adopt and adapt to the ever-changing environment of identity governance administration. Today we're going to talk about some interesting topics I hope will-- hope interest you in approaching an IGA solution or an IGA program from a different perspective than maybe you're doing it today.
But before we start, I wanted to ask a yes or no question. If you've been involved in an IGA program, has it gone as well as you thought it would? Just put a Yes or No in the chat. I want to see how many people have had success and how many people have had maybe some mediocre experiences.
And I think that when you're involved in these types of programs, it's very important to be honest about your expectations. And as we go through the different phases or different types of IGA approaches, you'll find that everybody's had similar experiences to your own. Some yeses, some noes. No.
Yeah, so those of you who've added your answers-- some haven't done one, some haven't had a bad experience, some have-- it varies depending on your expectations for what you want out of the program. So today, when I was approached to do this session, I thought about the three major types of approaches I've seen in the field in the past couple of decades of working with customers, either as-- or working with technology either as a customer, as an implementer, or as my role today as a vendor.
The first one we're going to talk about is building an IGA program from the end user experience. This is usually the simple path. You take your end user requirements, and you adapt them to some piece of software-- in this case, an identity governance solution. And it's a great path to take. You make-- you think you're making the users happy.
Users typically want one button. They don't want to be involved in the technology at all. They want to just come into work, hit a couple of buttons, get their tasks done, get single sign on to everything, and then go home. They want to be-- they want the technology to be silent, behind the scenes, without any sort of interference into their daily lifestyle.
Well, when you design an IGA program from that approach, you're going to run into a few difficulties. The first is making something simple to the user is extremely complex in the back end in a lot of cases. Yes, you can provide them an icon that will get them to something that they can request. But think about all the processes and workflows that need to happen behind the scenes to make that happen.
So if you look at my graphic here on this first slide, you see a traffic jam. There's traffic going everywhere. There's no lights. People are walking in the middle of the street. It's total chaos.
But maybe this works for the end user. It doesn't work for the people who need to manage the traffic and need to get where they need to go, like first responders, fire, rescue, whatever, police. There needs to be process in place, or you're just going to continually have a scope creep-- program of scope creep, where you have limited workflows, no governance capabilities. It's going to be untenable. You're not going to be able to maintain the solution. It's going to be something that's complete chaos.
Case in point-- I recently worked with a customer-- I won't name names-- who implemented a solution six years ago. And they took this path-- they took the path of, well, let's just make that users' experience easy. Let's make the user experience as simple as possible so that they can get their work done.
Well, in order to do that, they had-- they spent at least a year and a half implementing this all-you-can-eat type of user-centric approach to identity governance that ended up being unsupportable. Fast forward six years later, they've had attrition on staff. Nobody wants to support the solution. The vendor has notified them that their way out-of-date and that they're not even going to be supported as a product in just a few months. So they're in a-- they're in a tough spot.
What do they do? They have to go back to RFP, and they have to reassess what they want out of the solution and have the vendors rebid on these same use cases. And they really haven't gotten to the main meat of the problem with it, which is, you need to understand the process, need to understand what you're trying to do from a business perspective before you look at what the end user really needs.
And so that leads us to the second use case, and that's what happens when you build a solution that is only built from the IT perspective. So you're not taking into account the end user perspective, and you're not taking into account the business processes that are behind what the end users are trying to do.
This is typically done through hubris, and it's done in a closed cycle system, where the IT folks say, you know what, based on the troubled tickets we have and the conversations we've had with the business and the end users, we're going to attempt to role our own solution. And the way we're going to do that is we're just going to build it and then give it to them, and they're going to have to comply to what we've built.
Well, that works really well because no users will use it. I have a customer a few years ago who did just this. They took a popular IGA solution, and they essentially built what they thought the people would need, and then they rolled it out. They didn't have executive sponsorship. They didn't have any business processes in mind. They had-- it was basically a break/fix type of IGA solution where they had identified broken things that they were fixing all the time. They built a solution around that, and they said, here you go. Here's your fix for all these problems, and everybody said, that's great, but our problems have changed and our processes have changed. We're not using it.
And they spent over a million and a half dollars on the software and another $2 million on implementation, and they had 46 users in the system. And this is an actual customer that did this. And I've also had another experience where a customer built their own solution in this same type of bubble because they had a very large development staff, and that didn't work either because they ended up building something that was bypassed by the business. Workarounds were created. People eventually created their own scripts. It was just complete chaos because the IGA program was too rigid, and it didn't have executive sponsorship or business process involved in the design and implementation of the solution.
So that's number two. Let's talk about number three. The third one is, in my opinion, the best path, and that's where you take business process, you take the concerns of the business, and you define what those are, and then you apply those to what the users are asking for, and then you place that all that information into a piece of technology.
And the technology in this case is in IGA product that I would consider a solution. And that solution is only about 20% of the entire process. So you take concerns of the business, you identify those as business processes that you can map over to the individuals working at that business. And then you match those together in a work-- in a technical workflow, in a technical approach that then you can then implement in the technologies you're going to involve in your IGA program.
That's the most logical approach, and that's the approach where you're going to see the most success. And typically, that approach is paired with, say, a DevOps practice or continual service improvement in ITIL, or an Agile practice, with some modifications perhaps. Maybe Scrum. There's a lot of processes you can apply to this to create a logical path and flow to this type of solu-- to this type of approach.
Which leads us to, how do you approach that final or third stage-- or third approach? And that's with phases. So you have to be very careful when you're approaching an IGA program that you don't get into a scope creep trap, or you're addressing political or emotional needs that other folks in the organization maybe have different perspectives that you have to deal with. Changing business dynamics during the process. You want to make sure that you have very fixed phases that are easily attainable.
And I don't care if it's 1 through 5 or 1 through 20, make sure that when you're rolling out an IGA program into your organization, you not only have your business processes identified and the user needs identified and the technology identified, but you've identified at what stage, what piece is going to be enabled, designed, enabled, and implemented.
So it's pretty difficult sometimes to prioritize these types of initiatives because you have so many different dynamics involved in the business. But if you can address these expectations and have a limited scope for your first phase and second phase and so forth, you'll end up with a program that you can continue to support.
If you go back to my first two examples of businesses that didn't follow this type of approach, you end up with dead end products that were either out-of-date and not being used because the users didn't want to use them anymore, or they were never used in the first place because they were designed in a bubble. So one thing-- another thing you have to take into consideration when you're looking at a phased approach is that an IGA solution is not a tool. This is a tool. This is a wrench I bought to take an axle nut off a Ford Focus or a Volvo or something, and I use it for a lot of things. Righty-tighty or lefty-loosey. That's it. That's a tool.
An IGA product as part of a program, and the product is really a solution that never is finished. And I'll be honest, it's never done because the IGA program and the solutions involved in that program are always evolving or should always be evolving with the business. You should always have an approach that you can take that you can reassess what the program is doing on a regular basis-- quarterly, weekly, monthly, whatever is best for your business-- to insure it's providing the best value.
Because at the end of the day, the IGA program should be an integral part of the business. It should be sponsored and be approached from the perspective of, well, how is it going to benefit the business and make it profitable, more efficient, whatever your goals are? That should be the approach, and that's why the third option-- approaching the project from the people, process, and technology perspective-- is the best approach.
So with that, I wanted to open up with a little survey and see what kind of answers we get. So if you take a look at the survey on your screen here, you'll see, we have, which of the following security solutions is the priority across your enterprise? And we see automated enterprise provisioning was in the lead temporarily. Now it's automated enterprise governance. It's got a heavy lead. Single sign-on, surprisingly enough, is not in the lead like it was in my morning session with our peers in Europe. Very interesting.
So if we take a look at that result, you'll see that automated enterprise governance has won the race. That's interesting to me because in my earlier session this morning, single sign-on won the race. So we have to ask ourselves why that is and why is that the case?
I feel that maybe this audience has a better handle on how governance is supposed to work within the organization. Maybe they just don't like single sign-on. Maybe they were already doing enterprise provisioning. Very interesting.
So if we lead into the next slide here, you'll see that IGA initiatives are not just switched on. When you're talking about an IGA initiative, it could be from a provisioning/deprovisioning perspective, from a governance perspective, like we just had in the survey, which was the clear winner. Access reviews, which are part of the governance. Separation of duties cycle is governance. Password resets-- there's lots of features and functions that are implemented as part of an IGA program that you have to take into consideration.
But one thing that I found a lot of customers-- the trap they fall into is they feel like there's an end state to these initiatives and that they're just simply switched on. These functions are looked at from the perspective of a point of view of they're a static service, and that's not the case. They're always evolving. Whether it's changing password policies, whether it's changing governance policies because of acquisitions or divestitures in your business, whether you need to do more risk adverse separation of duty cycle processes because you've identified a need within your business, these are all things that are being changed and modified on a regular basis.
An IGA solution, like I stated before, is a living, breathing thing. It has no end date, and it has equal parts of people and process with a smattering of technology. It's really a visual technological representation of your business. IGA programs kind of have to. If they don't adapt, they're going to die a slow, painful death. And I could give you numerous anecdotes of, either in a competitive situation or just viewing from the perspective of an actual customer, how programs like this have died because of lack of sponsorship and lack of innovation after they've been implemented.
So, let's talk about how an IGA program's technology is perceived. The technology is typically perceived as a team effort, or it should be. So what I mean by that is, all too often, I run into customers where they have one full-time identity governance person and like one half-time person, and they've got a smattering of contractors.
And to me, while that may oftentimes breed some sort of success, it's really a team effort. You should have not only good technological solutions in place that represent your business processes and the people that are involved in those business processes, but the IGA program should be a business-level strategic initiative. There should be no orphaning of that solution. It should be first and forefront-- foremost in the business's mind, just like a CRM solution or any other type of business-focused solution, because you're involving the people and processes of your business to ensure that it's operating as efficiently as possible.
So if you look at the pit crew here, everybody's working around the race car, and the race car really represents the IGA program. It is something that everybody should be involved with. And that goes back to DevOps or ITIL or whatever else you want to take to do continual service improvement.
So with IGA, you have to think about it this way-- it's not rocket science, it's harder, and I'll tell you why. A rocket goes up, it comes down. You have physics involved. You have a definite mission in mind, and you have a process that's defined and people that are defined with roles. This is something that you need to understand when you're building out these programs that there's a lot of psychology that takes place in these programs.
You have people that have maybe changing priorities and views. You have business processes that might actually be at odds with each other. The technology is really the easiest part. It's defining that technology and how you want to build out the solutions within that technology that is truly what you need to be looking at.
Now we have another survey. So what is your top business driver when onboarding cloud applications? And we have enable end user self-service, provision users into new SaaS applications, manage access to these new-- looks like end user-- enable user self-service. Again, completely different from a-- oh, here we go. Unify on prem and cloud management, manage access to these new SaaS applications. OK, it looks like manage access to these new SaaS applications is a clear-- is currently the clear winner. All right.
So that's another interesting one. This morning, it was-- it was actually unify on prem and cloud management. So very interesting to me. I would thought unify would've won, so OK. So managing access, that's a very important function as well.
So let's move on to talking about why technology is the easiest part. And again, making the end user's experience easy is the hardest part. So you have to understand that processes-- business processes and the people involved have a new-- they have a nuanced approach to IGA. Meaning, one person's approach to what's easy to them is not necessarily easy to another person's approach.
So it's very important when you're doing this, when you're approaching an IGA program, you do usability studies for an end user perspective, you conduct assessments from the highest level of business to the end user, and you ensure that you're compiling these interviews and surveys in a way that makes sense to an implementer-- whether it's you in-house or whether it's a services partner or both. Making-- you must understand the business perspective of why you need to do this before you even attempt an IGA program.
If you do it from a technology perspective, you're going to fail. If you do it simply from the end user perspective, you're not going to have a great experience, and you'll probably fail. You need to understand everything that's involved in the program before you start.
And if you do this, happy users will follow. I can almost guarantee it. I won't make a 100% promise, because there's always things that may happen in the background that might derail your best intentions. But if you follow these steps and you take-- and you ensure that your perspectives has results from all core pieces of the business, you define what the value is to the business, and you've done these process assessments and interviews and surveys, you've created a big picture that you can then implement in your IGA solution. So success is defined by milestones, review processes, perceptions by the business-- again, sponsorship is very important. You'll ensure that you have a successful program.
So again, it's not a tool, it's a strategic business-level program. It's something that is not a wrench. So, again, a wrench-- tool. IGA program-- not-- not a tool. It's a business-focused solution. If you can create this big picture view, and you've gotten all perspectives in place, and you start the implementation in a phased approach, and you've answer it in one of the most important questions is, is this money well spent? If yes, then you're going to have a successful program.
And with that, I'd like to line up a Ninja Tip that we have that I asked the pre-sales folks to build, which is taking a business-level process and applying it to a technological solution. It's been reviewed by the key stakeholders, and it's been implemented in the IGA solution. So I hope you find this useful.
[MUSIC PLAYING]
This story is about a software developer named Dan. One day, Dan notifies his manager that he intends to leave the company. Dan's manager thanks him for service and logs into the company's identity management system to start the process to get Dan off-boarded.
The request process is simple, and mandatory information is provided for Dan's ticket-- the most important piece of information being Dan's scheduled termination date. This information is submitted into the system and sets off many actions behind the scenes. One of the most important of these actions is that the identity managed platform context the company's ticketing system in order to create a ticket for the human resources department.
The human resources department completes their tasks and updates the ticket status, and the identity management platform will check in and get that information and update its status accordingly. This is very important because behind the scenes, things like company policies and everything else are being interpreted and handled by the identity management platform. This becomes very important later on because there are many restrictions imposed on employees when they go to leave the company.
One of these being, in an advanced case, software developers who are leaving do not get to access sensitive servers, such as servers that contain or store source code. Dan attempts to do this by going to the server and, using the privileged session management technology the company uses, he goes through the normal process of doing that, submits his request, but this system doesn't just operate on information within itself. It actually checks in with the identity platform behind the scenes.
And because of this, it's able to see that Dan is a departing employee. And because he is a departing employee, he is in a restricted status. This causes an immediate notification to Dan's manager, asking him to approve or deny this request.
Dan's manager denies that request, of course, and sets in motion a series of other actions. These actions include beginning the process of shutting down Dan's access immediately. Things like disabling accounts, removal of entitlements, and many other things that relate to Dan's account usage in the company.
If we look at Dan's master information, the system has also flagged Dan as being a security risk. This is very important because now that we've identified Dan as a security risk, other safeguards are now imposed that lockout and prevent inappropriate use of Dan's accounts and other credentials. So the point of all this is that by having your privileged session technologies and identity management technologies working together, you can have a much more intelligent view of how to keep track of things like this when employees are departing your organization to safeguard your company's assets and intellectual property.
All right, so hopefully you found that useful. I thought that was an interesting use case involving an IGA solution, as well as privileged access management solution to solve a business problem. It's very easy to identify business problems. Sometimes it's difficult to implement them in a technological solution that makes sense from a big picture view. And I think that was one that was interesting to me because it was a deprovisioning solution or a deprovisioning use case, but it had a twist because you had someone trying to take intellectual property after they put in their notice.
So with that, that wraps up our quick session. I'd like to answer any questions that you have, and it looks like we have one already. If you're doing a phased approach, how do you decide where to start?
So that comes down to identifying what's important to your business from not only a business process perspective, but what's technologically feasible at that time? So what I mean by that is, you might have a business process that you'd like to-- that you'd like to implement like the one we just saw. But in order for all that governance process to happen, you're going to need to maybe establish some provisioning and deprovisioning capabilities to the systems involved.
So a lot of times, when you look at some of the IAM or IGA maturity models on the market, you'll see that usually phase one or the first level of maturity is your simple provisioning and deprovisioning approach. So I would look at that as a suggestion or guideline. Take a look at what's important to the business, and then also take a look at what's technologically feasible with what technology obtained and what you can do from a system perspective and then prioritize from there.
Got another one here-- can you interface with an HR system like Workday to initiate the termination workflows in Identity Manager? Yes, you can. So we have the ability to interface with popular HR systems like Workday to instantiate a deprovisioning process or provisioning process into Workday or SAP or PeopleSoft or any number of them.
And so the second follow-up to that is that we saw in the Ninja Tip. So, yeah, we could. We could actually reverse what we just did. So in the Ninja Tip, we were deprovisioning someone and then detecting that they were taking or attempting to download intellectual property. Well, we could flip that on its head, and we could provision someone in the same process and give them access to the intellectual property through either a folder level access or through an Active Directory group.
Any other questions? I have a question for the audience. For those of you who have been involved with an IGA program or are going through one now, what approach are you taken to the program from a standards perspective? Are you using something-- are you using ITIL or are using Agile or, heaven forbid, Waterfall or Scrum or DevOps? I'm curious if anybody is using any of those best practices implementing their IGA processes. And I don't know if anybody-- I don't see anybody actually using their implementation processes.
So another comment is-- sounds like there's-- a good IGA strategy should be consider this critical to the business as your CRM, ERP, et cetera, part of the business process and ongoing. That's a great comment. So a lot of times when we're speaking to customers, IGA, again, is put into the bucket of a tool, or it's put into the corner and takes second or third precedence to something like an SAP implementation or an ERP implementation.
And it really should be involved in that SAP implementation, for instance, because, let's say, for instance, you're going to be upgrading SAP in the next few years. You have to-- you're going to be forced to go to R4 or you're going to be using some HANA stuff or SuccessFactors or whatever. You should seriously consider wrapping your IGA practice and program into that initiative. Because nine times out of 10, the HR-- the needs of the HR system drive how you're developing your provisioning and deprovisioning processes in an IGA product. Great question. Great comment.
So another comment from what I asked earlier about using ITIL or Agile or DevOps, Todd said, they never use best practices and it bit him later. Yeah, that's pretty common. Especially some of the earlier ones, for those of you who've been around the line who have been through a longer-lived IGA program, maybe a decade ago, Waterfall was the big thing. And Waterfall is where you trickle out features as they're developed. That's a nightmare for an IGA process because some features may step on another, and you end up with the first approach to IGA, which is the simple path, where you're just implementing and user features as they come out.
Completely unmanageable. So, yeah. Yeah, you should always look at-- especially DevOps is very popular right now, and I think it's a great approach because you're evolving operations in the business overall into the process.
How, thank you. I appreciate you joining. So I don't see any other questions. I'd like to offer up-- if any of you are in the audience, feel free to reach out to me, Robert Todd Kraczek. And we'll have the contact info on the session. But feel free to reach out if you have any questions about approaching your IGA program, I'd be more than happy to help wherever I can and offer advice as needed.
[MUSIC PLAYING]
33:59
