Before we start, there are a couple of housekeeping items I want to address. Yes, this presentation is being recorded. We'll send it out to everyone who registered, and it will be live and ungated on the Cayosoft website. We'll include a couple of resources as well as the presentation we're walking through today, so you will be receiving these assets later on.

We also have a live Q&A. If you have any questions for our presenters, please don't hesitate to drop them in the chat. I'll be monitoring it, and if they're relevant to the current conversation, we'll bring them up and try to answer them live. If not, we'll hold them and answer them toward the end. We have plenty of time carved out to make sure all questions are addressed.

To help us work through these ideas, we've brought together two great perspectives that complement each other: strategy and execution. I'd like to welcome Craig Birch, Principal Technologist at Cayosoft. Craig spends a lot of time thinking about identity architecture, operational resilience, and what organizations need to do to build substantial identity programs. Throughout today's conversation, he'll help us define the target state and explain the principles behind a strong identity security posture.

We're also joined by Brian, who brings the field execution perspective. He works closely with organizations that are actively trying to implement these strategies while navigating competing priorities and making progress in complex environments.

By the end of this webinar, our hope is that everyone leaves with a clear understanding of where identity risks exist, what meaningful progress looks like, and how to think about moving from exposure to greater control over the next 90 days. Thank you for joining us, Brian and Craig. Let's get started.

With that foundation in place, let's start by defining the standard we're aiming for. If identity is truly critical infrastructure, what does that really mean? What is a Tier 0 priority, and what does good actually look like in practice? Craig, I'd like to ask you the first question. Tier 0 is a term people hear a lot. How should an organization translate that label into operational decisions?

Craig Birch 4:34
Really, the first thing you look at from a Tier 0 perspective is blast radius. If something were to happen in my organization, what's the blast radius? The second is criticality. If a system, service, or platform went down, how would that impact my business?

Traditional thinking around Tier 0 and identity points to Active Directory and Entra ID, but it goes beyond that. When we look at Tier 0, we need to ask: if something were to happen, what is the blast radius to my organization, and how important is that to my organization? If we were hit in this area, would it bring down my business or other mission-critical applications? That's why identity falls into the Tier 0 category.

Drew Fuhrman 5:38
That's really good. Brian, that spurs a question for you. What do you usually see as the biggest obstacle within these organizations when it comes to Tier 0? What does the concept of Tier 0 most commonly collide with from an operational reality?

Brian Botich 6:00
There are a few things. One is the technology itself: What are they using in the environment? Who owns that technology? What are end users experiencing to get to that technology? That's a big thing for them, but so is making sure you're not slowing down the business or creating unnecessary hurdles.

When we start talking Tier 0, that is absolutely critical infrastructure. It could be foundational infrastructure, or it could be mission-critical systems. When you start trying to operationalize those things, there are interdependencies between different areas of the business that really have to function together. That's usually where the friction takes place—trying to get a critical HR system done the way HR wants it, while making sure it still meets the IT requirements and the risk requirements.

Drew Fuhrman 7:05
Another thing that pops up, Brian—and Craig, you too—when we're talking about Tier 0, what evidence would show that an organization is truly protecting its Tier 0 assets, rather than simply calling certain systems Tier 0?

Brian Botich 7:26
It's an interesting question. A lot of it is the way they deliver it. You're seeing a large number of those systems going to the cloud and being delivered in a SaaS format. A lot of that is due to redundancy, and a lot of it is due to operational costs. Many things that used to sit on particular groups of servers in the environment are protected differently now than they were 10 years ago. I think the biggest thing is looking at how to maintain a strict security model without restricting the business, while at the same time having contingency plans if something should happen.

Craig Birch 8:16
You hit on some key things. A lot of mission-critical applications have moved outside the data center. Organizations have put a lot more rigor around monitoring, protection, and high availability, and around really defining what that looks like for the organization. And it's not just, "Can I monitor the Tier 0 asset?" From a recovery perspective, we're seeing a lot of organizations put more emphasis on how they would recover if a Tier 0 asset went down. So you see more rigor going into classifying Tier 0, and then putting the protections in place around it as well.

Sequencing the Work: The 30-60-90 Day Structure

Drew Fuhrman 9:01
That's a really good point, Craig, and a good way to transition to our next topic. When we're talking about Tier 0, the target state is protection that matches the potential blast radius you mentioned earlier. The challenge is how to get there without trying to solve every identity problem simultaneously. That's where sequencing becomes important, and it's what we're going to break down across this 30-, 60-, 90-day structure. Craig, what is the risk of attempting all three of these phases at the same time?

Craig Birch 10:04
I hate to use the phrase "boil the ocean," but if we try to boil the ocean and solve all of this in one big bite, it usually never gets done—or it doesn't get done to the level it should. And if it doesn't get done, teams often don't go back to it. Then we have a half-baked program.

So I would say don't try to bite this all off in one shot. You really need to treat this as a program, and it's continuous. It's not just 30, 60, 90 days, and we'll get into why it's continuous down the road. But it should be sequenced, and it starts with getting visibility into your assets and what your organization is going to define as mission-critical, or Tier 0. From an identity perspective, don't just classify things by asset or infrastructure, either. You need to look at the entire ecosystem. Brian, what are your thoughts on that?

Brian Botich 11:12
I agree. I think the biggest thing in the first 30 days is having an internal assessment or audit of your environment. A lot of times, we run into customers who have worked on their environments for 10, 15, 20 years. As the environment changes, they take for granted that everything's okay because everything's still working.

We have to be able to come in and get a true lay of the land: here's the critical infrastructure, here are the critical applications, here are the critical users or elevated administrative users. Same thing with groups—making sure we know who has access to what. And that's not just people anymore; it's evolving into the conversation around AI and non-human identities just as much. We have to make sure we understand what we're working with before we can ever dive in and start making changes.

Drew Fuhrman 12:19
That's a really good call.

Craig Birch 12:20
From what you're seeing, how long does that assessment usually take for an organization? You're living this on a daily basis.

Brian Botich 12:29
It depends on the size of the organization. Smaller organizations—and I'd classify those as 5,000 users and below—can typically get it done in one to two weeks. Bigger organizations tend to take longer because they have bigger internal support staffs that we have to coordinate with to get that information back.

It's a lot easier when we can go to one security team, or one Microsoft team, for example, to find out what the Active Directory structure looks like—the groups, the security groups, and everything that falls into that. But in large companies with 25,000 or 50,000 employees, those same types of teams are spread out, and there might be two, three, or four groups we have to do that exercise with over and over. So that could take upwards of 30 days, but it's typically one to two weeks.

Drew Fuhrman 13:30
Brian, I have a question. In those larger organizations, there are a lot of support teams—a lot of cooks in the kitchen. Are there specific commitments you want to get from the organization to help support these projects and make sure they're moving in accordance with a 30-, 60-, 90-day structured plan like this?

Brian Botich 13:57
Certainly. A lot of that usually needs to come from the C-level, or thereabouts, to help drive the process. There are two big keys to this. One is communication. Everybody has to communicate—amongst themselves internally at the customer site, and also with our teams doing the work, so there's a workflow back and forth. We may meet with individual stakeholder groups, but each of those groups needs to understand what the others are asking of this project.

The other is having somebody at the upper levels of the organization say, "Yes, this is a priority. We need this information. We need to do this." That's what keeps a lot of this on track.

First 30 Days: Stop Flying Blind

Drew Fuhrman 14:39
That makes tons of sense. So let's dive into the plan and look at the first phase: the first 30 days. This phase isn't about fixing everything. It's about replacing assumptions—going back to the audits you were talking about, Brian, and making sure we're not assuming too many things—so that everybody has a shared picture of the identity estate.

We're calling this phase Stop Flying Blind. Brian, I'll stay with you. In the first 30 days, what has to happen so the organization stops guessing about where identity risks live? You touched on this when you talked about doing an audit. Can you dive into that a little more for us?

Brian Botich 15:35
Certainly. For most organizations, whether or not they have a true IGA system, it really comes down to their Active Directory, because that's the main focal point for authentication and, a lot of times, authorization as well. In today's day and age, a lot of applications are AD-integrated to some degree, and access to those applications is usually granted through group membership.

I actually had this conversation with a customer two days ago. They had 4,000 groups for 13,000 employees, and those groups controlled 90% of their applications. Most companies look at identities as the individual user—my account, Craig's account, your account, Drew. But underneath that name, you might have 50, 100, or 200 groups you're associated with that give you access. You have to understand where all of those access points lie.

If you have nested groups, for example, and users nested six levels deep into a group, you may find somebody who has access to the accounting system—and it turns out they're in production somewhere. Should they have access to it? It's things like that we have to understand. That goes to Craig's point about blast radius: how far-reaching can this get if something goes sideways and an account with elevated permissions gets breached? That's really where it starts.

Drew Fuhrman 17:27
Craig, talk to us a little more about how you identify your Tier 0 identities. Are there certain criteria teams should use to determine which identities, privileges, and dependencies are truly Tier 0?

Craig Birch 17:48
If we focus on Active Directory and Entra ID, there are clear definitions of which groups and roles are Tier 0. But that's where organizations get it wrong, because they're only basing it on what Microsoft states. We need to extend this to things like ADFS and Active Directory Certificate Services, and beyond that, to other identity management or identity monitoring solutions that are in place. Those are Tier 0 assets as well.

The other challenge is that organizations often look only at group membership. There are hidden permissions inside these environments that allow Tier 0 access, and those have to be part of your audit—permissions like Active Directory ACLs, or Entra ID applications with API permissions that can lead to Tier 0. Brian, you mentioned it today—I didn't want to bring it up, but you did—AI. Once we start talking about agentic identities inside Microsoft ecosystems, some of those could be Tier 0. I haven't seen any to date, but there could be some out there.

We need to stop saying that only the built-in Microsoft groups—domain admins, schema admins, global admins—are Tier 0. It goes well beyond that. A lot of organizations also create their own groups and tiering practices, and they define Tier 0 there. I've brought it up before: Intune administration should be a Tier 0 classification because of its blast radius. If we go back to controlling the blast radius, there are a lot of things outside of Active Directory that can increase it.

Drew Fuhrman 20:06
Craig, you talked a bit about agentic AI agents coming into the environment. I want to use that to transition to this final bullet point. What is normal? What should we consider a useful baseline at this point?

Craig Birch 20:30
From a "normal" perspective, it obviously varies, and Brian will get into this, I'm sure. But you want to be able to baseline what your normal Tier 0 activity looks like and then put controls around that activity—things like PIM for Entra ID, just-in-time privileges, and the principle of least privilege. Normal will vary from one organization to the next, so you really need to understand what your Tier 0 infrastructure is, what your Tier 0 access is, and what normal activity looks like within your organization. Brian, do you want to give some insight here?

Brian Botich 21:15
Sure. Drew, you've got it in the title of the slide: Stop Flying Blind. The problem is that most organizations are building the airplane in flight. A lot of organizations have been around for a long time—20, 25 years or more with some of their current technologies and infrastructure—and that's constantly changing. That's why, by day 31 and on, you need a good idea of what you're looking at. The biggest thing is understanding where that is and working together to put those controls in place. In some cases it takes a lot of input from the organization, because it's a shift in the mindset of what they've typically been doing.

Craig Birch 22:17
One thing I'd also say—and I think Brian was alluding to it before—is that it's going to vary based on your business. Let's say I'm running SAP in my organization, and it's mission-critical. To me, that's a Tier 0 application, so access to that application becomes Tier 0. That's why I say it's more than what we typically think of from an Active Directory or Entra ID perspective. It goes back to understanding what your business is doing and what your mission-critical applications are. Then, from an identity perspective, what groups and roles are being granted elevated access into those Tier 0, mission-critical systems?

60 Days: Acting on Findings and Limiting Blast Radius

Drew Fuhrman 23:13
I think you both did a really good job of describing what Tier 0 assets should look like and how to start identifying them. At the end of those 30 days, the goal is to have a very clear understanding of where identity risk really lies. But visibility alone doesn't reduce risk. The next phase, the 60-day mark, is about acting on what was discovered and limiting the potential impact of any compromise—limiting that blast radius, which is becoming a common theme across all of these phases. Craig, how should organizations prioritize when they have more findings than they can reasonably address in the next 30 days? We've talked a lot about blast radius—is that how you want to prioritize?

Craig Birch 24:20
You do want to start with blast radius. I call it severity: if something happened in my organization, what's the severity of that particular finding? The other factor is ease of remediation. If I were to perform this remediation, would the remediation itself bring high or medium risk to the organization? Can you put some kind of risk classification on the remediation? And if something goes wrong, do you have the ability to recover from that remediation?

So start with blast radius, and then look at it from a business-impact perspective. If something is critical—Tier 0—but low risk to remediate, focus on that. We can take that bigger risk off the table much faster than something that could have a wider impact on the organization when we perform the remediation. And if I'm going to move forward with something that could have a high impact, or any impact, I need a backup plan to roll back the remediation.

That's where people get stuck. A lot of organizations see all these findings and they're overwhelmed. They don't have the expertise, or they just don't have the time to perform the remediations. Maybe we found some service accounts with elevated rights, or service principals in the organization. We know those are tied to applications, and remediating that service account could bring the application down. If I don't have a good understanding of what that application does and how it's interacting with that account, that's a huge risk to the organization. Brian, you live this on a regular basis with your team.

Brian Botich 26:52
We do. A couple of things happen. To touch on bullet point three, making the trade-offs explicit is a big thing. When you look at how to make these changes, one, it goes back to the communication piece. Two, a lot of companies weigh speed versus coverage. How fast can we do it? That depends on a number of things, one of which is usually change control. There's some kind of process that has to happen. We can't just turn off permissions or reset them to a certain level to shrink standing privilege. There has to be a change management board or review, and it might have to go through security or risk management. That process just takes time.

The other piece—how do I put this delicately—is that internal politics come into play. Groups and application owners have handled things a certain way for a long time, and we all know how much users love change. We hear them scream every time Outlook changes the ribbon. When you start changing privileges and telling them, "I know you're used to doing it this way, but you're going to have to tweak that a little," it creates tension, and it can create additional issues that then require communication to your end-user population.

So when you prioritize, it's about where you can get the most value from changes in the shortest amount of time with the least impact. Grading that out is tricky sometimes. Something might be a 2 out of 10 impact on end users but an 8 out of 10 on the security scale, so it becomes a no-brainer. But when something has a huge security impact and really tightens things up, yet it's going to hurt end users at a 9 out of 10, that becomes more of a communication campaign and an internal campaign to get folks on board, because a lot of times they're resistant to the change.

Craig Birch 29:37
Most of these changes aren't frictionless. Whatever you choose to do, you're going to cause some kind of friction for somebody. And as you said—I didn't think about organizational change management, and I should have—that comes into play too. Putting myself back in the days when I was doing remediation, that was a big thing: What change does this bring to my end-user population? Could we put a compensating control in place instead of doing this remediation? Is there another way of handling it?

There are a lot of things that come into play, and it's more art than science. When you add in some of the politics and normal business operations, it's not as easy as you'd think, especially when you get into deep remediations. Let's say we have a significant security finding that's been in our environment for 20 years and has never had any kind of exposure. When you bring it up—not to the security team, but to the business team—they say, "It's been like this for 20 years. It's fine. We've never had any issues. If you make this change now, it's going to have a much greater impact on the business, and we're willing to accept that security risk." That's why the risk advisory board comes into play as well.

Brian Botich 31:22
To add to your sentiments there, Craig, it is a bit of an art. For organizations like ours that do this all the time and see a lot of different environments, it becomes as much an exercise in working with the people who run these systems as it is an audit. We do it in our personal lives, too. My wife came to me and said, "I want to paint the walls in the house." I said, "Why? We just did that." We all see little changes like that, and there's sometimes a natural resistance. But when you explain the method, the ideas, and the reasoning behind a change, folks are much more open-minded than if you just come in and say, "We're shutting this door and making a change." Here's why we have to. That's where a lot of the nuance and the art comes in with these kinds of projects.

90 Days: Sustainable, Governed, Recoverable, and Provable

Drew Fuhrman 32:29
It's always tough finding the compromise between what's good for the business and what's good for securing your environment. We do need to keep moving, but it's important to remember that at the end of the 60 days, the goal is not to say, "We've made compromise impossible." That's not what we're trying to say. What we're saying is that if something is compromised, the consequences are more contained after those 60 days.

That's a good transition into our last phase, the 90-day mark, where we ask whether those controls are sustainable, governed, recoverable, and provable. Craig, why are recovery readiness and change control inseparable from identity security? I think that would be interesting to understand a little more.

Craig Birch 33:40
From a recovery readiness perspective: if you've focused on understanding your Tier 0 and gone through remediation, but you don't have any real-time change control or change monitoring in place, you'll often drift back to your previous state.

The other thing is recovery itself. You think you're going to catch things through monitoring, but something always slips through. We have to be prepared: if something does slip through and impacts one of our mission-critical—or Tier 0—assets, what does recovery look like? And then you need to be able to prove you've done that recovery. A lot of organizations say they have recovery plans in place and that they're ready to recover their Tier 0, but it's only been done on paper. It's never been fully tested. If you can't recover, you can't really say it's completely governed or fully protected.

Drew Fuhrman 35:09
That's a good transition to a question for Brian. We're talking about confidence and control. Craig touched on this, but can you talk about the difference between having a documented recovery plan and being genuinely able and ready to recover if you're compromised?

Brian Botich 35:36
It's always the "it works on paper" approach—it's documented. Then there's whether it works in practice, and in practice is the big key to the whole thing. When you talk about recovery, most folks have DR plans. Then you ask them, "When was the last time you actually did a DR test?" If they did one, it might have been a year ago. So how do you know it's going to work when you need it? I tell customers all the time: When was the last time you checked the air pressure in your car's spare tire? Nobody thinks about it until they need it. Having it is the big thing, but so is readiness and continuous checks.

There's a difference between confidence and comfort in a solution. I can be comfortable with a solution, but how confident am I that it's going to be there and ready to work when I need it? That's part of the planning process.

I want to make a point here. When you talk about identity projects—looking at Tier 0, reducing risk factors and blast radius, and all the things we've talked about so far—what you achieve in those 90 days isn't necessarily completion, because of a lot of the factors we've discussed. You can have some things done, but you've got to plan to complete the rest. That plan will have measurable deliverables, timeframes, tasks, and milestones that need to happen to get there. To use what Craig said earlier about boiling the ocean, that's exactly how a lot of customers look at it: "We've got a lot of work to do. How do we do it?" You take it in pieces and in stages. This could happen over the next 12 to 18 months in some cases, depending on internal priorities, parallel projects, change control, executive sponsorship, and budgets, which come up quite a bit. But we can lay all of that out within 90 days and say: we know what you need to protect, we can show how you can control it and prove that it's controllable, and you can have confidence that it's going to be there—not just comfort with an idea.

Drew Fuhrman 38:24
I want to double-click on the operational practices and timelines you're talking about. Are there common best practices you've seen work well for the organizations you've helped set these structures up with?

Brian Botich 38:28
We do. It depends on the organization and their type of business. For example, if we're talking about this with a hospital or healthcare organization, it's very different than with a manufacturing organization, and some of that depends on how the business operates. A hospital runs 24/7. It's ultra-critical—in some cases, Tier 0 applications could literally mean life or death if folks don't have access to them or something happens. A manufacturer may run one or two shifts a day, Monday through Friday. If something happens, they'll lose a lot of money because they can't produce, but they have a little more wiggle room to recover or remediate.

So best practices are going to be a little industry-specific, but there are some universal underlying themes. One of the key ones you hear a lot right now is Zero Trust, or least privilege. The two are different concepts, but they go hand in hand. With best practices, you adapt them to the customer's needs and how they fit in the environment. It's not one singular best practice; it's putting several together based on the technology and the industry.

Drew Fuhrman 40:19
That's great. Craig, anything you want to add on best practices you've seen while working on structures like this?

Craig Birch 40:28
I'm going to go back to the identity side. For most organizations, the biggest bang for the buck is eliminating standing permissions inside their identity environments and moving to least privilege and Zero Trust—and it all plays together, so don't take that out of context. Really move to just-in-time access, where there are no standing privileges for Tier 0 infrastructure.

And it's not just about standing privileges. Just-in-time access for Tier 0 should require another level of approval. It shouldn't be me just requesting something; I should have to go through an approval process. That process does two things. It shows that I requested the access, that I have a need for it, and that someone verified that need. It also gives me a documented record for audit purposes showing that the access was granted and, more importantly, that it was taken away. So: I request Tier 0 access, there's an approval process, it's time-bound, and the access goes away. That's the first thing I would do. And going back to the assessment, I would look at every area in identity that could allow a takeover of my Active Directory or Entra ID environment—a total breach state.

The same thing applies to recovery. We have to treat recovery as part of Tier 0 and apply the principles of least privilege and, more importantly, Zero Trust to our recovery process. You asked why recovery readiness and change control are inseparable from security. As you said—and it's right on the slide—if you can't recover it and you can't govern the change, you really can't say you have control over Tier 0 at all, because that's the foundation. I could go in and do all this remediation, and unfortunately, Brian could go behind me and undo that change. If I don't have any monitoring of that change, or he didn't go through a formal change or approval process, I might not know it happened. I think I'm good, and when I find out I'm not, it's usually not good for me, because I'm reporting it to senior leadership—or worse, publicly, because we've had a larger cyber incident. I know I went a little off task there, but when we think about it from an identity perspective, those are the things that matter most.

Drew Fuhrman 43:45
Makes sense to me.

Brian Botich 43:46
It does, and I want to add one thing—Craig is spot on with this. This is where evaluating business processes is so important. Here's an example. Part of the identity conversation is joiner, mover, leaver: What happens when somebody comes into the organization? What birthright entitlements and privileges do they get? In a lot of companies, a person gets hired and entered into an HR system, which then feeds identity systems so a lot of automated things happen with those birthrights.

What often happens is that as soon as that employee is flagged as active, they get created in these systems. But in some organizations, they flag the employee active even though they're not starting for another week. Today is the 24th; they may not start until the 1st of the month. So now you have a potentially active user in your environment who isn't even working there yet. That becomes an attack surface, as well as an audit problem, since there's a requirement that only actual active employees on the job have access.

That's where the just-in-time access Craig was talking about makes a world of difference. They've officially been hired as of the 24th, but until 7:45 on the morning of the 1st, we don't need to give them anything they can actually use. Just-in-time applies to birthright privileges, but also to applications—especially Tier 0 applications. I don't need access to that application at this moment, but an hour from now, when I go to log in, the privileges are created based on whatever policies apply. That's a very big part of this conversation right now, and a lot of customers aren't used to it because it's a nontraditional conversation in this area.

Beyond 90 Days: The Identity Maturity Curve

Drew Fuhrman 46:06
That's really good. Thank you, Brian and Craig. I want to keep us going because we only have about 15 minutes left—time really flies when you're talking about a 30-60-90 day plan. You can do a lot in 90 days, but that's not the end. We're not going to say, "All right, we're done, everything is secure and under control after 90 days." This is really an on-ramp to a more measurable and sustainable identity operating model. So let's look at this identity maturity curve. Craig, where do most organizations realistically land on a curve like this after 90 days?

Craig Birch 46:58
It's going to depend on the organization, and Brian will back me up on this, but I think they'll be at level 2 or level 3. When you look at it, there are different areas where they could be further along. For example, in understanding which accounts are privileged, they may be at level 4—managed—but still be developing in other areas. So there's no easy way to gauge everything from an identity perspective, because there are so many different areas. If I say privileged identity is the one area we're going to focus on, by day 90 I could be at level 4 and working toward optimized. But if it's not privileged identity and it's just hygiene, I might still be in the defined or developing stage.

Brian Botich 48:17
Craig is spot on. We do a lot of identity workshops for customers, and part of what we do during those first 30 days is working through this maturity model to understand where they are and where the real improvement points are. Craig's right: most customers, on average, are somewhere around 2.5 to 3. Occasionally you'll get customers between 3 and 4, but I've maybe seen one customer who was closer to 4 than to 3, because there's so much new going on and you have to be very identity- and security-forward to get there. A lot of companies aren't quite there yet, so they're in the developing or defined area quite a bit.

Drew Fuhrman 49:12
Brian, I want to circle back to something we talked about in phase one, the first 30 days, when we discussed what commitments you need from the organization to be successful. You said ownership from the C-suite. Now I want to talk about setting expectations. What's a realistic maturity jump we could typically see within this 90-day structure? We don't want to say we're going to take you from level 1 all the way to level 5. Where does this really land?

Brian Botich 49:50
Generally, in 90 days you can get at least one level. I've seen two in some areas, to Craig's point, but as an overall whole, it's jumping from one level to the next. Going from developing to defined is very doable. Defined to managed is doable too, but it depends on a number of things. One is the change control process—making sure the changes can actually happen in that time frame. There may also be additional solutions that need to be put in place to help with those controls, whether that's management, auditing, or governance tools. Microsoft gives you a great foundation, but it doesn't give you everything you need, and that makes a big difference in how quickly you can jump levels.

The Identity Security Scorecard

Drew Fuhrman 50:57
That's a really abstract concept—this idea of maturity and where you are within your identity environment. We want to make it more useful than just saying, "Here's where you are," so we want to give our attendees some baseline levels and a scorecard to review. This scorecard helps evaluate the practices that most directly affect identity risk and blast radius. Brian, I'll stay with you. In your experience, which category is most likely to look acceptable at first but falls apart when the actual process is examined?

Brian Botich 51:45
It's funny, because depending on the organization, it could be any one of these. For most customers, the most defined is often role-based access—whether they've actually implemented it can be a different scenario. Access requests are a big one, and that ties closely to privilege management: How are we handling access requests to certain information? A lot of companies will have separation of duties and change visibility, with clearly defined roles in systems to track some of that.

Recovery readiness is a big one, because everybody's got a DR plan, but how viable is that plan when things hit the fan? That's where the rubber meets the road. So recovery readiness and role-based access are probably the two most critical. If something happens and you have to recover, you need to make sure the people who need to get to the systems to do the recovery can get to them—and the recovery has to be successful at the same time.

Drew Fuhrman 53:11
That's great. We're getting close to wrapping up, so Craig, one last question before we go into final thoughts and takeaways. If an attendee is looking at the scorecard right now, which category do you think would be the most uncomfortable to answer, and why? Be honest—this is a safe space.

Craig Birch 53:40
I think there are two. A lot of us think we have least privilege under control, and then we find out we don't. The other one is recovery. I've been in numerous DR drills, and every time we thought we had it right, there was something new we learned in the recovery. We had everything down on paper, and we rehearsed it—like Brian said, maybe once a year—and that rehearsal doesn't go as planned. It takes longer than it was supposed to, and we find new findings.

On least privilege, we think we're following it across the board, but we're not, because we don't know what our exposure is to begin with. We haven't done the full assessment to understand what privileges are in the environment. And this is one of the things I want organizations to understand: in the identity world, in Active Directory, privilege is anything more than Domain Users, in my opinion. If I have more than read access in an application, that means I have some kind of privilege. Outside of Active Directory, even read access to some areas could be a privilege, but I'm going to keep it at the identity level from a Microsoft perspective, because read is normal. So if I have more than domain user access—or more than read—that's a privilege. A lot of organizations struggle here. They think they have it, but they haven't achieved least privilege the way they thought they had.

Final Thoughts

Drew Fuhrman 55:32
That's helpful. Thank you, Craig, and thank you, Brian. We have about five minutes left, so hopefully there's a little time for final thoughts. Brian, can you give us a few final takeaways on how organizations are securing their identity across this structure, and where they can go from there?

Brian Botich 55:59
Let me equate this to something real-world. Anybody who has talked to a distance runner, like a marathon runner, will hear that the hardest two miles are the first and the last. These projects are exactly the same. It's those first steps of getting the project off the ground—that first mile. At that point you've hit your stride, and the rest is pretty easy until you get to the last mile, because that's where the nitty-gritty, tougher things come into play and you have to tie it all together. But they're not as bad as a lot of people think.

When you go into these projects, it helps to be able to look at things objectively and to have somebody like us come in and say, "Let us walk you through this." We help you see the forest for the trees, because we've seen so many environments and understand the nuances out there, while working with a customer who understands the nuances of their own environment better than anybody. That collaboration makes a world of difference, because you need that outside perspective. For a lot of customers, it's also validation: 80 or 90% of what you're doing is fantastic and it's working. Let's fix the other 10% to get you the rest of the way there. That's the biggest difference. And tying together all the concepts we've talked about is easier when they're put in a context that relates and applies to you.

Drew Fuhrman 58:01
That's great. Craig, final thoughts from your side?

Craig Birch 58:07
Start. That's the biggest thing you can do—start your journey. If you don't start, you can't even begin. I would start with privilege: What are the privileged identities in my organization? What are my Tier 0 assets? Start there by getting visibility. Once you have visibility, you can understand what kind of assessment you need to determine whether those are properly secured and governed. If they are, you can move to the next one, and that becomes easy.

As I said, a lot of organizations hire someone to come in and do an assessment, they get the findings, and then they don't know where to begin—or they're afraid to begin because they're afraid of breaking something. You just have to take it one piece at a time, and you can get to a secured environment. In 90 days, you will be in a much better position than if you hadn't started on day one. I can guarantee you that.

Drew Fuhrman 59:20
That's great. Thank you, Craig, and thank you, Brian. Really appreciate you both. I'm not seeing any questions in the chat, so we can go ahead and wrap up, since we're already at time.

Before we leave, I want to point out that we have several assets available for anyone attending live or watching this webinar on demand. We'll send these assets out in a follow-up email, along with a link to the recording, probably by Monday at the latest, once we get the videos produced and online. We'll get them to you as fast as we can. XMS has a really nice Gartner white paper on guiding you to a comprehensive identity and access management state, like we talked about—Brian is an expert there. And Cayosoft has a couple of solutions to help with some of the challenges you may be facing in securing your identity environment.

Craig, Brian, one big thank you. I know it's a lot of work putting these sessions together, so I really appreciate you both taking your time and sharing your experience and expertise with us and the community. And thank you all for staying on today. We know everybody is busy. I hope you all have a great rest of your afternoon, and please reach out to us if you have any challenges supporting or building your identity infrastructure over the next 90 days. Thank you all. Take care.

Brian Botich 1:01:01
Thank you.

Craig Birch 1:01:01
Thank you.