He built his own plane. And his own identity system.

Hello So our guest today, Mike Julian, leads Information Security at Wynn Resorts, one of the most iconic hotels and my personal favorite on the Strip. Anyone who knows Mike knows that the man loves aviation. Not just flying, he built his own plane from scratch. Took him 28,000 hours driving across the states, collecting parts from different people and then bolting the whole thing together piece by piece.

That's obsession. And in a few minutes from now, for the second time in my life, trust me, I don't know why I'm doing this, I'm getting on the plane with him again. Oh, and yesterday, he casually mentioned that he had to take the entire plane apart and put it back together because of some technical issue. Totally not scaring me. Things you do for your company.

So Mike, before Pranay asks you some detailed questions, I want you to paint a base of picture right because a lot of people don't realize this but Wynn Resorts is a multifaceted complex operation hospitality you're also doing gaming online lots of different roles in the organization different facilities all over different continents Europe Middle East what is your day-to-day life like

oh man it depends on the day and it depends on what's going on but in general, probably the biggest part of my job is running the identity side of it. So there's constant access requests. We have somewhere in the area of 25,000 employees right now.

That's it?

UAE. When the UAE comes online in the spring, they'll probably increase by 7,000 or 8,000. Okay. And there's only a team of four people that run access.

Is that including you?

No. Okay. Yeah, I do give access here and there, but they do it all day, every day. And on any given day, we will receive somewhere in the neighborhood of a thousand access tickets. And that's people coming on board, people getting off boarded, people transferring within the company to different job roles. They require different access. And there's no way to do that without a massive amount of automation.

Wow. You know, there's several levels of approval depending on if it's, you know, like if a line level employee submits a ticket, their manager has to approve. If a manager submits or somebody, you know, supervisor or above, it goes to the application owner directly. Application owner approves as soon as it's ready to go. It goes on the board. And then if it's an automated, if it's something that we have automated, then it will pull out the board usually within 10 minutes. Apply the access, close the ticket, send the email to the user, let them know.

That's quite a process. You have a lot of technicians to different vendors on location doing all these things, too. Like, how do you keep track of that, too?

Yeah, vendors are difficult. The onboarding of vendors, you know, we obviously have, you know, companies that we hire out third party development companies and stuff like that, where we have developers coming in for a certain project from one of the largest development houses. They all need to be onboarded. We require either we do a background check on them or their company does a background check. if they're accessing gaming systems, they have to have a gaming license. That's a whole other process.

You have to get fingerprinted. So we track all that. They go into certain. We have vendor job codes, essentially gaming and non-gaming. So they might be, you know, development, non-gaming. Then they don't need a gaming license, development, gaming.

Then HR will send them through a gaming process. And then there's an entire process that we have built that's getting more and more automated every day on how to bring those vendors in. And so project managers will send whoever on the vendor side handles the onboarding. They'll send them the sheet that they fill out. Essentially, it's a link to a form. They fill out the form. It goes to HR.

HR onboards them. As soon as they get onboarded into our HR program as a vendor, we automatically bring them in to ServiceNow. And then there's a bunch of automated processes that take place to issue them an Active Directory account. and then the project manager will submit, we call them eKARFS, but they'll submit access requests essentially for those vendors. And then, you know, hopefully it's automated. You know, most of them is automated.

I want to talk about the vendors you said, because I think there's a particular case that is very unique to your business, especially around the vendors having privileged access. So a lot of these, again, maybe you know this, of course, better than I do, but do you have some vendors like IGT, Konami and a bunch of the, you know, the gaming equipment providers, right? And in your case, especially they do have privileged access to those systems. They might have real time or maybe some physical access to those systems as well. Is that still a part of, I mean, the third party privileged access is still a part of the governance program or?

Very rarely will they have administrative rights on a critical system. If they need to work on something, generally they are working with an employee where they're essentially, the employee is kind of their hands. They're saying, they're kind of communicating what they want done to the employee or by the employee, and then the employee will, on a screen share or whatnot, they'll accomplish the task for the most part. There are exceptions, obviously. Some of those things require change control, so they can't just do them, right? They have to kind of get, you know, a lot of times, you know, change control is kind of dynamic.

And so a lot of times they don't necessarily know it needs to be done. and so they need to kind of explore through the system to figure out what configuration needs to be changed. That employee that they're working with will submit a PCR, a production change request, and then that needs to go through a set of approvals in order to be approved. And then once it is, there'll be a time when they can do it. If they have to take down a system for a period of time, obviously that's an issue. So that all needs to be scheduled with the business.

So how quickly, so if a technician does leave the floor, like how quickly does IT know about it?

Oh, like if their contract expired or not?

Or maybe even one of the employees on the poker floor, for example, maybe.

Yeah, vendor, it doesn't really matter. It's the same process, essentially. As soon as HR terminates them, then the HR system changes their status to terminated. And then they come down and then it revokes automatically. we have an attestation of everybody's access down to role and application. And so as soon as they go from active to terminated, termination script runs that sends out revoke requests to my team for every single one of those applications, most of which are automated, some of which have to be manually actioned.

And so my team will go in and remove that access. And then obviously we have the governance side, the GRC side, and they check, you know, they audit on a quarterly basis all of our in-scope. So we have a collection of in-scope systems, either for Nevada Gaming, SOX compliance, which if you work with large companies, they all have to have SOX compliance. And so those systems get audited every quarter, and they'll discover if anything was missed or somebody was termed and that access wasn't revoked. They'll discover it. They'll issue what they call an exception to me. We'll clear the access, and then we do what's called hindsight testing to make sure that between the time when they were termed and the time that we discovered it, that there was no nefarious activity that happened.

I thought I'd call it, but you said, or someone said that worked in the gaming industry, that one of the biggest security access, like sensitivity areas is cage cashier. Did you ever hear that term? The cage cashier? More important than having this building to this person than the CIO. Is that true? Is that the right term? Is that cage cashier? Yeah, cage cashier.

The ones that you bring your chips to, that's the cashier, right? You bring in their chips, they issue anger. cage but there's a lot of data that they need to enter when that happens right and there's also a compliance piece for the irs if you're cashing out more than ten thousand dollars you have to you have to go through what's called Title 31. so essentially they're when you start getting above ten thousand dollars per transaction they want to ensure that you're not laundering money through the casino and that uh you're not uh you know somebody that shouldn't be allowed to you know

And it's pretty unique to their business, I think, because usually the ops risk or the IT risk usually comes from the leadership executive people mostly. But in their case, it's the people on the floor, they are the ones who actually contribute a lot of ops risk. Because like I said, a mistake at the cashier's end will probably lose the money. That's usually not the case with most other enterprises that like for example, tech. If you compromise, let's say one of the executive accounts, they're probably going to lead to more IT and you know, sort of audit risk more than OPS risk. But in their case, it's the other side. I want to talk to you about the segregation of duty, especially because I think you guys track it really well in your business, right?

How do you look at the SOD risk that comes out of let's say people like you said, people who are like down at the, you know, the lowest levels in the org, right? on the floor, people on the, let's say, managing your hotel chains and all of those, right? Because typically what we are seeing is SOD for a tech enterprise or mostly it's usually restricted to the business teams and especially the ones with a lot of sensitive access. Yeah. In your case, it's down to like the lowest levels of the org. Yeah. So is that more difficult or trickier than the other examples that you have seen?

So we handle segregation of duties. So we work with internal, we have an internal audit team and also a GRC team. So GRC kind of works with us to satisfy internal audits requirements. Internal audit works with an external auditor like EY or Deloitte or name your big four to make sure that we satisfy their requirements. And then internal audit and GRC kind of work together to funnel it all the way down from where the rubber meets the road, which is where I work, all the way up to make the ultimately external audit happy, right?

Okay. And so they do a lot of work to determine which roles and which app where you can't have both of these. You can't have the ability to post a transaction and issue a check or whatever that would be. Wouldn't that be nice, right? Whatever that example is, right?

I deserve a bonus.

Yeah, because then you could issue yourself a check, right? And that would be bad. And so they've identified those segregation of duty violations or what would constitute a segregation of duty violation. And then because of how we handle access on the front end with the concept of a matrix, each job code, each position number, right? So if you have cage cashier, right, at the Wynn, that's a position number. And if you have this position number, this is the access that you're allowed to have. And they can't request the access that would constitute a segregation of duty violation.

It's actually possible that they could request the modification of the matrix to give that position code. but that would immediately be flagged as segregation of duty issue. So you can notify that. And then we actually notate in the matrix itself, so just for the viewers, how we run the matrix is there's two sides to it. There's the left side, which is your position, right, cage cashier, to roll in the application. So let's say you have like administrator and then you have a position and then there's a yes, no matrix that says that this position code is allowed to have this role in this application.

This is what you created. Yep. And then on the right hand side, it's the role to permission. So we would say, so to control, to make sure that you don't just create a role that says view only, that has administrative rights on a bunch of stuff, we control that as well. And so we have a collection of permissions that we have identified in the application that need to be on the matrix because it either gives you the ability to modify, delete, add, anything that's beyond a read-only role. And then if any of the role and then GRC checks this every quarter, they look at the role and then they make sure that the role has the exact permissions that are listed on the matrix and no one has modified those permissions during that quarter. And if they do, then we remediate it either by modifying the matrix because it's needed or removing the permission from that role.

Wow. And this matrix, is that defined for every application or is that defined for internal ones?

We're getting to every, it's a lot of management to run for every application. Of course. We have somewhere in the area of 500 applications. Wow. And it grows every day, right? Somebody wants a new tool, somebody's buying a new thing.

You know, AI is coming up now, everybody's using it. They want to test different ones. All those get brought in as applications. They all have roles, they need access. And so it'd be very difficult to keep up with it. You know, for sure, all of our audited- critical ones all of our audit application because that is the they call it a artifact so the artifact that they use to audit the application is the matrix so they say this is what's been approved by the application owner and ultimately the cso and the CFO this is what they say is allowed in this application and then they audit it to that standard

and so they find the biggest challenge in creating this process

um biggest challenge it's just it's honestly it's a day-to-day management and making sure that you have a full attestation of what everybody has in real time. And somebody who has the ability to grant you that access, an administrator in the program, grants you the access outside of my system. When that happens, I don't know that you have the access. Because the way that I know that you have the access is that you submitted an access request, it was approved, my team actioned it, and now your record reflects that you have that access. Because I'm not pulling it real time. Although with some, I have almost the ability to do it now. We're getting to the ability where we're able to pull it real time from the applications itself.

And then the ultimate goal is I know all the access that exists. Somebody gives you access outside my system. I discover it immediately and I revoke the access. Okay. And then eventually they'll tell on themselves. They'll call IT. I keep giving this guy this role and it keeps getting revoked.

I don't understand what's going on. And they're like, well, you're not following the process, right? So we kind of funnel them into the process. But the hardest part is that management piece, right? Because ultimately what ends up happening is if I don't know about that, right? Right. And you leave the company.

Right. Let's say it was even allowed in the matrix and everything was good, right? Let's just pretend like you were allowed to have that role. You just didn't have it. And somehow somebody gave you that access outside of my process. What would happen is you leave. I would revoke all the access that I know about.

And I would not revoke that one because I didn't know to revoke it. There was no revoke request submitted because I didn't know on the front end. So, and so then GRC would find you in an audit, right? So GRC might audit that application and they'd say, oh, we fired Ron back in, you know, January. And today, it's March 31st or April 1st, and he still has the access. Why would a terminated employee have this access? And then, and then we, you know, we revoke, we remediate it, we revoke the access, and then we just go check to make sure that you didn't actually use that access somehow.

Okay. But we've implemented SSO. And so when we revoke your, you know, your access, your general access, you can no longer access anything else either. So the account exists, but you can't use it, right? But we still try to keep it clean. We do audit it for that access and that account should not exist. And so we remove the access to keep everything clean.

Was it hard to kind of incorporate the on-prem, the older tech, the old legacy into this?

Yeah, we have a lot, especially gaming. We have a lot of legacy and this is kind of all gaming companies. When I was at Boyd, we were using AS400 mainframes for their lodging management system, that old IBM.

Can you see they're still here?

Virtualized, you know, it's virtualized now. It's not using the old hardware or anything, but they're still using that legacy stuff. And it's very difficult to get those organizations to adopt modern standards. Like we want-

It's a ticketing system, right?

Yeah, we want to see SSO single sign-on through SAML. Usually it's SAML 2. It's a single sign-on framework that you operate within. And ideally, we have SCIM provisioning, which gives you the ability to push groups from my system to your system. So I can put you in an Active Directory group, right? And that can translate to a role in an application. And so it will automatically create. So as soon as I put you in that Active Directory group, it syncs up to Application ABC, right?

Okay. So you have fine-grained access to everything.

Well, it just gives me the ability to automatically grant you the access, right? Because I don't have, you know, there's a lot of companies out there that have what they call just-in-time provisioning, which is where, hey, you know that Wynn is your customer, and I've registered WynnLasVegas.com or WynnResorts.com. And so if your email, which is usually your user identity in any given application, if your email ends with Wynn Las Vegas, I know that you're my customer. And so if you log in as Ron at WynnLasVegas, I automatically create you account, right? However, that account doesn't have any permissions or it has a basic user permission, right? What SCIM provisioning allows me to do is have very fine-grained control of when I create that account because I don't have to wait for you to log in, right?

I have already made it. As soon as the access is approved, I have already put you in the group automatically. through automation. I've dropped you in that Active Directory group or name your access company. And that information has been forwarded over to the application that creates your account and then also puts you in the group that I want.

So if you're in the admin, like application ABC dash admin, then you get admin permissions automatically in the application. And honestly, it's not that hard. It's a very simple framework. It's not very complicated. It's usually JSON calls back and forth. But a lot of companies don't do it and don't want to do it.

In some cases, they charge like 10 times the money for it.

Yeah, and there's actually a website somewhere where they list, it's like the naughty list for people who charge more for that simple security SSO.

Yeah, because they give you the enterprise.

Oh yeah, because you have the enterprise plan and the only thing it gives you as SSO.

Okay, so Mike, you are a builder. I don't know if I've told you that before, right? Have you told that before? Okay, so you've built planes because basically commercial operations didn't meet your expectations. You wanted to build your own, right? Yeah.

Okay. We took that same attitude to your IT security operations at the Wynn and you built your own identity governance process platform using ServiceNow, right? Okay, because you didn't really find anything in the marketplace that you wanted for that. So as a builder, walk us through like what you were thinking to go through this process and think that you can even accomplish this. Did you think you could when you first started? And how did you even convince your manager?

I knew it was possible. I didn't convince him. He told me that I will be doing this. Yeah. You'd have to meet David Taberski, but yeah, this is all out of his head. Oh, wow.

Yeah. Well, he was already in the process when I showed up. So he already kind of had the vision in his head. But as you guys know, as you guys run a startup, right, the gap between I have this vision and then a competent product is vast, wide, and hard to navigate. And so, yeah, it's just like anything else. You eat the elephant one bite at a time, you know, playing's a good example, right? There's 18,500 rivets, and there's probably a manual on how to build it that's as thick as a couple of encyclopedias.

Did you read the manual or just wing it? Yeah, just be like, yeah, these two look like they go together.

Yeah, so, and then especially when you're building, this is honestly, in comparison, it's easy, right? Because you have a defined roadmap. You say, hey, you put piece A and piece B together and you use these rivets and this technique and you just follow the instructions. because on my day-to-day life, I don't get instructions. I get a destination that we wanna get to. Okay. And then I need to figure out how to get us there, right?

Or it would be as if I showed up into your house and said, here's some aluminum, build me a plane. Oh. Right? That's far more difficult than, you know, here's an instruction manual and some pre-punched, pre-shaped, pre-drilled parts. Right. Follow this and build me a plane, right? I could not from scratch, you know, I'm not an aeronautical engineer, I cannot from scratch build a plane, but even if I could, it would obviously take way longer to, you know, engineer and test and, you know, and make those mistakes.

And I think we're, you know, everybody's kind of your plane and the system at the same time.

Oh, the system is never done. The plane is almost never done either. Yeah. But I mean, I imagine at some point in the faraway future, the plane will be at a state where it is complete.

However, I don't believe that the system will ever be complete. There is always advancements. There's always improvements. We didn't like the system that the users have to go through to submit the requests for access. And so we built a new system.

So how many people did it take you to build, let's say this, like what are the manners?

Oh, it's hard to say. We were using outside developers for a while. And we got to the point where we were asking for things that were very difficult for them to provide. just from a skill standpoint. And so, you know, we kind of had this vision and they're like, oh, that's going to be really hard.

And they were, you know, kind of guesstimating on how many hours something would take and they were often wrong. And they would say, well, this quote is for this product, but it contains this many hours. And they would always go over. And it became a point of contention where we almost were trying to force them and to be like, you have to tell me how much this is going to cost. And they were like, we don't honestly know.

So how many years did it take you guys to reach a place where it's mostly automated?

Five.

Did you have any challenges, maybe not disasters that happened during this process, but something that you can share?

Automation's fantastic. It lets you do things at a speed that's not human, right? Like we close a thousand tickets-ish a day. That's not, well, you could do it with humans, but I would need a room full of them, right? So it also works against you. If it goes in the wrong direction, it goes in the wrong direction really quickly.

And especially with the system that you're constantly making changes to, and sometimes the change that you make affects something over here that's unintended. And so you might accidentally break a process down, that you weren't intending to break with this other change over here, and now all of a sudden, oh yeah, now we're not issuing termination tickets for some reason because something changed. It's any software problem, right? Some software that you interact with changes the way that they present information to you through an API, they change terminated from a T to the word terminated, right? That would be a problem for me because I'm looking for the T and now it says terminated and I don't have a way to handle. I don't have an error handling that's robust. I wasn't predicting that they might do that in the future.

And so, you know, there's constant bugs that we discover and we fix, you know, you try to fail forward, right? And you try to be sure that you're not breaking anything. So, you know, we have testing environment and all the normal development stuff. But, you know, mistakes still happen. And we've been just improving it, you know, through you build to an idea and then you test it in the real world, right? There's always a...

Feedback.

Yeah, you need a feedback loop of how well is this working well? How can we make it work better? You know, you go out and you put it out to the business and you ask for suggestions from them and they say, well, you know, I need to submit. Sometimes we bring on a new application and they need to submit access for 50 people. Well, they have to fill this form out 50 times. That seems silly.

Why? Because, well, you can't add multiple people to the form. It's for one person. All right. So how do we... Okay. All right.

So I understand. Yeah. It sounded like a good idea at the time, but there's now more requirements. So now we need to make a way for them to add multiple people or maybe teams of people automatically, or maybe everybody that works for you. Birthright management is another example, right? And typically, we would handle that manual. And the business owners would be like, well, I need all my people to have exactly this.

And there was this massive spreadsheet of position numbers and the various 25 applications that this one needs and this one, and then my access team handles birthrights. And then it was just this, they would end up in these long meetings and then they would end up having to do it. So we gave them a way to do it, manage it themselves. Like what process could you put in place to enable a supervisor to manage the birthrights on their own where they can go into a system and say, oh yeah, you know, this, you know, access administrators work for me. I know access administrators need these 50 different accesses, access of 50 different applications. And so I wanna have that done automatically so that every single time I hire one, I don't have to go through and add 50 things.

I wanna just happen on day one so they hit the ground running when they show up. And how do you enable somebody that's maybe not even technical to manage that, right? And how do you handle the approvals on the other side? Because birthrights, in our mind, they're deemed approved, right? I don't want to have to go through an approval process because then what ends up happening is the employee starts. And then they are waiting maybe two or three days after they start for all the various approvals to go through.

And you don't want to have that happen. And so what you want to do is approve it on a per job code basis. And you say, cage cashiers require this access. And then you go to the application owners and say, do you agree that all cage catchers should have this role in your application? And they say, yes, I agree. And so you have to build that process. And you kind of run into those edge cases that you don't think about.

Pretty incredible.

Have you done an estimate as to how many manual hours you saved by putting this process together?

Oh, no, but a lot. And you can imagine that's a relatively large number. You know, it's somewhere in the area of tens of thousands of man hours that have been saved through automation. And not only on the front end, right? Because the actual work to do it is just one equation. Humans make mistakes. Computers, unless you program it wrong, don't make mistakes.

And so the GRC tickets on the other side of that equation would be massive because you're going to have people make mistakes. They're going to give the wrong access. They're going to forget to submit the ticket. you're gonna have all these various human factors that are involved in it that are gonna affect it. And then also you have the lost time on the business side. Because you have a cage cashier that can't do their job because they're waiting for an access ticket to be managed. When I arrived three years ago, I've been there just at three years.

When I arrived, the average time between when an access request ticket was submitted and it was closed was seven days. Seven. And the access administration team, their answer to it was just to throw manpower, right? So we were like, oh, the tickets are high and we need to hire a contractor. And we used to have a manager over there that no longer works with us. I used to run around, the tickets are high.

The tickets is like the British are coming. And so I sat him down and he was older and he was very set in his way. So like the way to get tickets done is to drive the team to do the tickets. No, the way they get tickets done is to figure out what you can automate and automate it if you can. Today, the average amount of time between a ticket being submitted and a ticket closed is four hours. Four hours. Yeah, so we went from seven days to four hours.

Now, how much money does that save on the business side or maybe man hours of paying people sitting there that aren't doing anything?

It's really hard to calculate, but a massive amount. I'm sure someone has. Massive amount. Massive amount on the initial granting side, massive amount on the governance side where they're not discovering those human mistakes, and mass amount on the business side where they're getting efficiencies back because they're getting access they need.

Now, if you hit your goal is four hours, like are you happy with that or do you want to beat that?

The time is more than acceptable for the business, right? Obviously, immediately is better, right? You're always chasing zero. What I would like to get is to get to more automation. And the problem with legacy systems that casinos very often operate with is that they don't have any form of SSO. They don't even have LDAP.

I mean, they got nothing. They got, listen, if you want access to that, but you have to, your guys have to go in there and they have to create the account and they have to give it the access. And they are, they are not changing. They are, we, you know, no amount of begging is helping. We're trying through, there's a, in gaming for like slot machines and card shufflers. There's a gaming, there's a gaming certification that goes through GLI, Gaming Labs International, it's called.

Okay. And they certify these machines. And gaming organizations, at least in places that are governed by the Nevada Gaming Commission or other states, we have to buy certified slot machines. We can't just throw a slot machine on the floor that takes your money. There's very defined rules that we have to operate in. trying to have a gaming software division of that, where the gaming software has to go through that.

And then we're trying to force them into SSO and things that we want from a security perspective by influencing GLI to put those in their regulations. And so there's multiple ways that you can come at it, but ultimately there's just not brand new gaming companies that run ticket in, ticket out, and ATMs and stuff like that coming online. every day. And so we're kind of stuck with the legacy providers at a company our size and we do what we can. And so outside of them not having anything, the only other way to do this is with robotic process automation. Now what's left, I have to either influence the company to implement SSO or I have to use robotic process automation. I have no other choice.

They don't have an API that I can interact with. They don't have SSO. They don't have LDAP. I'm stuck. And so RPA is my only choice. However, as you guys know, RPA is very difficult to manage because the button, they move the button, they change the color, they make any update whatsoever, everything breaks, they add stuff.

And I have problems even outside the RPA world where, because I have such good control over my roles and my permissions, where companies will make, some SaaS application will make an update, which will add permissions and add roles automatically that have those permissions that are on my matrix, and therefore now my matrix is wrong. And GRC comes back with this laundry list of violations, of exceptions, because it wasn't on the matrix. And I would have to monitor the release notes for 500 applications. It's very hard, right? So maybe some kind of AI that automatically looks, I give them a list of the applications we use, and then if it looks through the release notes, every software release that they send out, and then it tries to identify the addition of roles or permissions. And then we can try to get ahead of it.

Imagine that for like an internal tool as well, right? Your business team could add a new role all by themselves. Yeah. And you wouldn't even be aware of it.

Yeah, that happens. That happens sometimes. People will modify roles. They have the permissions to do so and they'll modify a role because, oh, I was just trying to help the business.

And I'm like, well, Mark, I need you to tell me when you do that because it causes me a lot of work. If you tell me in the front and I can modify everything before GRC finds it, it's a lot easier for me. You're causing me a lot of work. You might be helping somebody else out, but you're hurting me. So, I mean, come to an agreement.

And sometimes you may have to yank their access. I mean, you give them a warning. At some point, there has to be teeth. But, yeah, it's very difficult.

I actually want to dive deeper a little bit on the part where you said the automation stops and the manual efforts sort of kick in, right? So who are these people who are the first line of defense when it comes to some of those manual requests? Is it your team?

Yeah, it's the access administrator team. So they have a supervisor and three access administrators, and that's all they do is close all of the tickets that I don't have the ability to close automatically due to those legacy systems.

And I'm guessing those problems exist because there's no SCIM, there's no API. And then the only way around it is RPA, which takes a very long time to implement. And so, you know, sometimes it's just, it's less time consuming depending on the volume of tickets to do it manually.

Yeah, and that's essentially where it stops for me. If I could do it all automated, I would. If I could wave magic wand and not need an access admin team, I think you'll probably always need them because you're always gonna have problems because sometimes it's not so black and white as like, oh, I need this role. What the user knows is that they need to do something in the app. Correct. They don't know necessarily which role they need.

And so they ask for a role and it gets approved and they get granted and they go and try to do the thing that they've tried to do and it didn't work. Now what do they do? Who do they call? What are they gonna, you know, they may not know who the application owner is, the application owner themselves may not know. I mean, some of these applications have thousands of different permissions. And so the Access Admin team is that kind of like last, you know, last line of defense of like, Who do I call when I just, I need to be able to do this thing.

What role do I need? And they're the experts on those applications because they deal with them all day and they know the roles and the permissions and they can fix that for that employee and say, oh, actually, you need this role. Like, okay, well, I've already submitted for you. So be nice to your access admin team. Yes. Yeah, yeah.

How does the audit sort of look at those systems? Like, for example, if you have to do audit for, let's say, those handful of systems which are not automated today, how would that experience look like for your team? Is that your team doing that?

Yeah, so segregation of duties as you put on before. So I, we have two directors under our CISO, so he runs the GRC team that watches me. So I don't provide both the access and the governance because then I might have the ability to be like, oh, sweep that one under the rug, right? And so we try to automate their processes as well, right? That's, it's a very manual process. They have to log into the applications, they have to pull reports.

If we can pull that report through an API or some automated fashion, we will, right? And so they have exactly enough people, enough manpower to do all the audits they need to do in three months. Well, that means that everything's only getting audited every three months. But what if you could automate the process, you could audit it every hour, right? Or a minute or real time. And now, you know, as in your example, what happens when somebody modifies a permission? I get notified immediately and the system reverses their change.

And then they eventually tell on themselves because they're going to call the help desk and be like, what's wrong with my app? I keep adding this permission and it keeps deleting it. What's going on? Are we hacked? No, we're not. I put in a system to make sure that you don't do exactly what you're trying to do.

So the next call is with HR?

Yeah. Well, now I don't even have to involve HR. You just can't do it.

So Mike, I want to segue into the next segment, which is around M&As, the mergers and acquisition part, right? And I'll be honest, the first time I heard the M&A side of the story when it comes to identity governance was at a Gartner conference when I think one of the big four partners was on the stage and he was describing how complex the whole M&A process is. And especially when, you know, there's an acquirer, there's an acquiree, and then the two entities have to merge together. They have to audit everything and all of those things, right? You went through acquisition of a company called Byte and you were leading their security operations at that time. So how was that process for your team and for you?

Yeah, I spent a lot of time on both sides of the table of the M&A process, both as the acquiree and acquirer. And it's painful every time. It's both sides. It's difficult. It's probably harder as the person buying the company, because especially, you know, usually you're larger. You're usually have more robust processes in place, but you essentially have this kind of governance framework, identity framework, kind of the way that you run your systems, and you're bringing on a company that obviously doesn't do it that way.

I mean, maybe in a perfect make-a-wish and like, oh yeah, you guys already do all this stuff that we do, and you already use all the same applications that we use. Wow, this is amazing. Come right on. Walk right in. Yeah, and so it never happens that way. And so what ends up happening is you have to do big, long meetings to try to figure out the lay of the land, right?

The first step is you got to figure out what are you guys doing now, right? How do you guys run it? What's your process, right? And then you take your process and you say, okay, between these two processes, where do we meet in the middle? Where do we let you run your own things? And then the process goes is, you know, you got to figure out what needs to be handed off, you know, because like, let's say if the Wynn acquired, you know, we acquired Mayfair.

Mayfair, I don't, you know, they were using outside services for most of their cybersecurity, but if they had a cybersecurity team, there needs to be a decision like, okay, well, you need to hand us over your stuff. And then are we keeping you there? Are we bringing you onto our team? Or are we just, you know, are you going to stay for a certain amount of time and then everybody's going to leave? You have to, that's obviously decisions above my head, but essentially that's what you have to figure out. You figure out the lay of the land and then you figure out what needs to change.

And a lot of times, maybe you're not using the same EDR, endpoint detection response software, right? Are we going to let you finish out your contract with who you have now and then switch you over? Are we going to switch you over immediately because our cybersecurity team knows our product better than the other, the product that you're using? How do we want to handle it? So it's a case by case and it's just a lot of time and it's very arduous and a lot of times it takes, you know, in some cases years. To, you know, from the date that you acquire a company to the date that they're completely onto your systems, it might be years.

And is there a pressure from the business side that you need to complete this faster or something?

Most of the pressure is not necessarily to mend, like to meld the processes together. Most of the pressure is to keep the business running while you do this, if that makes sense, right? Because it just depends massively, right? And so it's kind of a case case, but usually they want it to keep running and they don't want you through this process of trying to integrate to hobble the company and prevent them from being able to operate.

Okay, Mike, we had to hear about your background and the identity space, present day challenges, successes. It's wonderful. But what about the future of identity? What do you see?

I think with the sprawl of applications, some legacy, some not, I think automation is going to continue to drive the market. Obviously, like AI enablement is going to be important, something along the lines of what you guys do, which allows us to issue RPA into legacy programs without the massive management overhead. I think by and large, large companies utilizing AI in general will want to decrease workforce. And I think that as the pressure to decrease the number of people and also accomplish more work product gets pushed down, companies are gonna have to go out there and find solutions like what you guys offer in order to maintain that status quo that they're expected to meet. They're gonna be told to essentially do more with less people and then you start running out of options relatively quickly.

Good point.

What's your view on non-human identities?

I think that non-human identities are in some cases more important than human identities. A lot of times they're more privileged. They're not monitored as well. They have some limitations as far as multi-factor authentication, for example. You can't have a computer. There's ways to do it, but it's just, by and large, the industry has taken the same approach that they took with human identities and then tried to apply it to non-human identities. That's hard to do.

A lot of times, it's not effective. You kind of have to handle them differently. You have to assign some form of ownership, some form of secure password rotation, which is very difficult in some cases. You might have that hard-coded password in 20 different systems that if every single time you have to rotate it every 90 days, we'll say you have to go into every single one of those 20 systems in order to change that password. And that's maybe something that you could accomplish with automation, although heavy lift, you might have 10,000 non-human identities, access to 100,000 systems. And you have to add a state, everything that you have currently, and then you have to be able to figure out exactly what's using those accounts. And then you have to be able to, in an automated fashion, rotate that password.

This is great. There's more systems for you to build.

Yeah. Yeah. I mean, waving the magic wand and coming up with, in a perfect world, what would I have? And then the difference between that and reality is the chasm that we're trying to, you know, that you guys are trying to cross, that I'm trying to cross every day.

And it's just, you know, it's a constant fight between resources, time, you know, because, you know, I would love to just sit around and pontificate about the future. You know, a lot of CISOs like to do that. Oh, I have some ideas, general direction, but not actually have to do any of it. But I can give you a lot of really good ideas, but where the rubber meets the road, where you have to actually make that idea reality is very difficult. And a lot of times you go outside and grab a company that's doing something online so you can leverage to make your overall vision a reality.

What are some of the examples of non-human identities that you think are more specific to your business? For example, a typical tech enterprise will have service accounts, shared accounts, and service principals and all of that, right? I have heard of a scenario where in an oil and gas industry, for example, the helmets that people wear when they go on the rigs, they constitute non-human identities because they have certain IDs on those helmets that have to be worn by service professionals, right? Are there any specific non-human identities that you have seen in your line of business?

Well, I think large, you have a lot of strange edge cases in large businesses. A lot of times you'll have employees that don't have Active Directory accounts. And then they need to share a machine, right? And so in order to make that happen, you need, you know, the concept is generally a generic account, right? So where you have something like all of our pit bosses need, you know, there's a computer in the pit that tracks the players. As they give you the player card, it tracks how much coin in, how much coin out, right?

All these metrics that casino operators care about. And those pit bosses are constantly changing out or, you know, sometimes a dealer has to jump in and relief. He has to go to the bathroom. You know, there's a lot of edge case scenarios where you end up having to have like some generic identity, right? That's big in large organizations. You know, obviously everything that runs, you know, everybody likes to automate everything.

Automation of anything requires some form of access into a system. a lot of times with high privileges in order to maybe deprovision a user or provision a user or make modifications to Active Directory. And so you have to be very careful. The easy way out is, you know, and we see this on a daily basis where we'll have, you know, some software that we bought, some SaaS company, and they'll say, oh, we need API access into your Azure platform and we need admin. Absolutely not. You need to figure out exactly what permissions you use and only those permissions we will be giving you. And you can't take the lazy way out and just say, well, it just works if you give them admin.

And you see that a lot. Well, if we just give it all the permissions, then suddenly I don't have to do any work and it just works. However, on the other side, because you could have supply chain attacks, that company could get compromised, which compromises you because they're storing the identity. The problems are vast and wide. There's a lot of solutions out there with AI to be able to, I've seen products out there that look at non-human identity and say exactly what permissions is it using in this application. So maybe it has admin right now, and we know it only uses these three permissions, and then I might be able to send an alert into the SOC or the access team to say this account's over-provisioned, and here's exactly what it needs because I'm seeing the actual communications between these two programs.

Are you talking about our platform?

There's some solutions. Possibly Iden. Iden is a good solution for that. Nice. So there's solutions to the problem. It's just a very difficult problem to tackle. And build it yourself versus go out into the market and find something. You find an avenue that you can sell into and build it and they will come.

so mike you know we certainly appreciate you you're such an interesting innovative person we loved capturing your background to a degree we loved highlighting a little bit of the work that you did here we saw you do a little work on the plane appreciate that by the way i just want to let you know we really appreciate you this has been a valuable learning process for us i hopefully all the listeners out there feel the semi i think they will so awesome thanks so much all right Thanks Mike.