SailPoint, Inc. (SAIL) Earnings Call Transcript

Hello, and welcome to my session. My name is Will Harrington. I am an Identity strategist for SailPoint. And today is going to be the first of a 4-part series of webinars directed at government organizations. And through this webinar series, we'll be talking about how we can apply identity practice to some typical government settings. And one of those settings is the Machinery of Government changes and how identity governance or I'm going to say IGA systems can be impactful and very useful as a part of Machinery of Government. In future webinar recordings, there will be discussion around how identity governance can be integrated with cybersecurity as well as another session on AI in identity governance and what the impact of that is as well as the final recording in the series will be about building a business case. So as a part of Securing Machinery of Government changes, I'm going to start saying MoG, Machinery of Government is quite a tongue-twister and it's getting a little bit tiring. So I'm going to go to MoG and IGA. But when I say MoG, I'm talking about Machinery of Government changes. And as a part of today's presentation, we will be covering what is the Machinery of Government change. This is a government webinar. So I hope all of the people who are attending today know exactly what a Machinery of Government change is. Those of you who are coming in from the private sector that a Machinery of Government change is just like a reorg. So if you are dealing with a lot of reorgs in your organization, then maybe the same logic can apply to you. And certainly, this information presented today is interchangeable between government and private. But today, we'll be talking about reorgs in the context of Machinery of Government in a government setting and the public sector is going to be getting a lot of attention as a part of this. So the challenges -- so second on the list is the challenges of managing a MoG, right? What are they? What is the machine? What is a MoG? The challenges of managing a MoG, like there is a lot of data that changes hands as a part of a MoG, and we'll get into the details of that. What the current practice is. I've had the privilege of presenting at several public sector network events in Melbourne, Adelaide and Sydney at the moment, and I will be presenting in Brisbane. And I've had the opportunity to talk to a lot of public service employees, and I've queried them about how they go about Machinery of Government changes, and they've been able to share some details. So this is kind of just a bit of a collation of that sharing and just what I thought was the most common. And then we're going to get into the good part, which is talking about how identity governance or IGA systems can be used as a part of facilitating MoG changes, what can we automate? And let's finish up with how to build a business case. How do we build a business case in through or through the lens of a MoG. Like a MoG is a big part of government. It happens all the time. Then there must be some way we can use that information and use that volume of change and the inefficiency of the process to be able to say, okay, well, if I don't have an identity governance system, how can I frame the data to then serve the purpose of building a business case for maybe the implementation of an identity governance system. And I think a MoG provides a really good place to begin that conversation. So one announcement redraws the whole org chart. So just like I said earlier, a MoG is a reorg. This is where election results or we have a new ministry where there are policy shifts and portfolio changes, but this is something we just saw in Victorian Government in the last week, where we have a new premier. And as a part of having that new premier, there's a new set of ministers with new portfolios, and those portfolios are merged together or divested or moved to other ministers. And that is really at the heart of Machinery of Government because it is those ministers who will then organize the reorganization of those departments and staff to make them more efficient and make them more effective in serving the ministerial outcomes. So that it makes it easier for them to be able to communicate with their departments and affect change really as a part of serving in government. So the result of that is lots of change, lots of staff members changing their -- maybe changing their job titles, changing their domain or e-mail domain suffixes, changing their HR attributes, who their reporting line managers could be. There are many ways that people can move throughout an organization. And we see this quite a lot, not just in the public service, and we see it in private sector as well, like quite often, I'm quite close to working with Financial Services Institutions, so FSIs. And every year, there would be a bit of a reorg here and there and managers would change and people would need to reapply for their jobs. And in the public service, it's just pretty much the same thing, but very much in a high volume, right? So it happens quite often. And as governments change, everything likes to get reorganized. This isn't exclusive to just employees, but contractors that might be serving in departments as well. Systems and access need to move to the correct department. And you really got to ask the question for some of those nonhuman entities as well. So we're talking a lot about agents these days and machine accounts. We kind of talked about third parties, but what happens to the ownership of those agents? Like so there's a lot of questions. What happens to all of the access of the staff and the contractors who have that access, and that's really forming the basis of this conversation today in that sometimes that access is retained. Sometimes people keep accounts that they shouldn't. Sometimes accounts remain enabled. Sometimes people hold that access and maybe sometimes that access is used as a part of a threat vector, right? So these are the sorts of the problem that we're trying to solve as a part of a MoG change. Once again, entitlements, they provide access to records that could be classified as private. The people who do move from one department to another or who change from one government to another, should they retain access to those same records? How do you manage that effectively? How do you do that in such a way where everybody there's a large volume of change that occurs at a particular time, and that change needs to occur within a particular time frame as well. So what's the final result of a lot of this. It's being able to still deliver services to citizens effectively. So making sure that the public service can still operate at the rate of efficiency that they do, but also be able to perform these MoGs and still deliver on the SLAs to the public. So if we be able to look at the order of things, just in case you don't know, a MoG order is announced, spreadsheets are compiled. And this is something -- and this is a common thread of conversation that I had with a lot of the attendees to these PSN events is that they said that they dealt with MoGs just through a lot of spreadsheets. And what do they do with these spreadsheets? They collect names, roles and access that has been captured. And a lot of those spreadsheets either just get directly submitted to the service desk for someone on the service desk to then manually implement those changes and say, I've got a list of 30 names with access add and revoke kind of instructions or operations and somebody on the service desk has got to work through a lot of different applications and systems. So Active Directory could be representative for hundreds of applications. And then we might have more direct access in SaaS applications like Salesforce or we might be working directly with a database as a database administrator. So the service desk needs to be able to iteratively work through these lists and add and remove the access as required. Operationally, that's incredibly inefficient, like that manual labor, that manual effort, it is certainly open to mistakes. I might miss a line. I might miss a piece of access that needs to be removed. I might miss a piece of access that should be added. There could be mistakes in that spreadsheet as well. There might be just an [ error in the ] key entry in one of those spreadsheets that breaks access for a particular user or a user can't necessarily be set up because of the quality of the data that's being submitted. Also, I've spoken to some people at these PSN events that really -- they said they do spreadsheets, but we do all the spreadsheets through PowerShell scripts or scripts. And that's also common as well. But where's the auditability of that? So how do we know that the code that is executing on those spreadsheets is good, right? How do we know that there's not something in that code that is not missing something or maybe that code is really good at adding access or not removing access. What are the guidelines for this code? Who owns it? What if the person who wrote that code leaves the public service and we can't find -- we can't refer back, like how do we audit that? How do we know that this code is good? And what's the reusability of this code? So some really big problems when we're just dealing in the world of spreadsheets. It's okay, though, we've got a good answer. Accounts keyed in, right? So that's the carry on from spreadsheets. And then we've got access copies like-for-like. This is something else that I heard quite a lot of these government events as well is that, well, how do I set up a user in their target environment, like in their target department? Well, the way that we do it is like we look at somebody else who is similar, maybe a similar manager, similar to the department, similar cost center, similar job code, something like that, and then we just copy and paste that user. So that is what we would call like Model ID in the old mainframe world where we just take somebody and replicate that person to then set up that new user. But that is quite erroneous. The world kind of moved on from Model ID, and it does present an opportunity for permissions creep or over entitling a person as a part of setting up their access #5 and #6, okay. So we've also got old access disabled later and clean up the third. They're kind of the same, but this is where we're dealing with large volume of change. Today, I could be dealing with the onboarding of some of this large volume. But tomorrow, I'm going on annual leave, and I'll deal with that disabled access later. This sort of stuff happens all of the time. We have a case study that's in the public domain for a New South Wales government department that utilize an identity management system. And the first use case they decided to knock over with that identity management system was to detect all HR records that are set to terminate, but those people still have active accounts. That government department was able to find 800, I think, around about 800 accounts that were still active for terminated HR records. That's the old, let's disable it later kind of factor or maybe there's other reasons why that was the case. But humans being humans and the way we are, we often get distracted and there's a lot of competing priorities that we've got to deal with. And so cleanup gets deferred. Old access gets disabled later. What does that mean? It creates exposure for our organizations in the form that a hacker may gain access to one of these highly privileged accounts or just simply dormant active accounts and then use that account for lateral movement. And if nobody is really asking the question of what is this account? And why is it there? Then it tends to just sit there. I see this in the public and private sectors all the time. But we have controls. We have the ability to be able to rein that in using identity management systems to be able to build controls around that and to make things better and especially in a MoG sense. So we can think of the MoG as an opportunity to perform a cleanup, improve security, buy down a bit of risk, the opportunity is there. Given that there's a lot of movement happening at once, let's take advantage of that what we would call an event, take advantage of the MoG event so that we can improve our security postures. So when the move is manual, the risk is structural, right? So what's the risk, security, privilege creep. We've already talked about this. As people move through the MoG process, as they move through departments, sometimes users and identities retain their access. For whatever that reason, maybe the person on the service desk forgot or they missed it or they were unaware of some particular access. Those entitlements are accumulated over time. I think I heard a story about somebody moving across 3 different departments but held the accounts and entitlements from their first department. That is the typical scenario for privilege creep, dominant and orphan accounts. So I've already resigned from the public service and I'm still -- I've still got active accounts or I've moved on from one department to another department, but the accounts in my old department are still maintained as [indiscernible]. From an audit and assurance perspective, this is an audit and assurance nightmare in that like the way that we implement our MoGs through scripts is not really auditable, right? So unless there's some kind of audit log with -- that's been output to a text file that has been saved somewhere, which everybody knows about that auditors can then gain access to or we put that text file into some kind of central data lake, then the data evaporates. And we know that we don't maintain it. Well, I'm sure there's some really good administrators out there who have a good file or folder with all of these logs about all of the changes that occurred as a part of a MoG. But I would say it's not the majority in this case. So continuity and operational risk because of the operation, because of the volume of changes that take place as a part of a MoG, there's always a continuity and operational risk. When we're making bulk changes across a lot of data, there's always some kind of level of oversight in that maybe we misspell the department name or we removed the wrong entitlement or we added the wrong entitlement or we put the wrong domain suffix in for a cohort of users. We could be dealing with 2 users or we could be dealing with 2,000 users. And maybe there's a few people on this call who would be kind enough to admit maybe when they arrive to work one Monday that none of their access was there. Maybe it was unavailable. In the Q&A, please put your input. I'd love to hear about it. And there are no doubt incidents that have occurred as a part of dealing with this large volume of change, dealing with a lot of data, inputting it into our technology systems, having an expectation of how our technology systems have been set up and what we expect to work and that results in something -- there's always something that results in unexpected. We've got some really good stories about my time in financial services and some of these large changes that we implemented. It's just a little bit of oversight in maybe a test case that just got missed and it resulted in a SEV 3 or a SEV 2. So this is pretty big in financial services, and we don't want those. But these things happen and doing things manually and step-by-step spreadsheet-based processes increases that operational risk. Data loss and privacy as well. So the risk there is that you retain access to some data that you shouldn't. So data has classifications. Is it public? Is it private? Is it production or is it development data? Or is it private data or is it subject to GDPR or SOX or some kind of compliance obligation that we might have. And as you move between departments, you may retain access to some of that data, and you could potentially be in breach with privacy legislation as a part of that. So there could be some kind of legislative risk against your department, maybe because of that exposure because somebody retained access that they shouldn't. Okay. So the risk is there right across the tiles. So let's bring in identity governance and administration. We're going to talk about the breadth of identity governance. Connect, Correlate, Govern, Automate, Prove, like that is such a nice workflow. And that's exactly what an identity governance program does. [indiscernible]. We connect to HR. We connect to all target applications. You might have Active Directory, which is representative of hundreds of applications or Entra, which is representative of hundreds of applications as well. You might have Salesforce and SaaS applications and on-premises applications. These all applications, you might have one or many accounts in each of those applications. So an identity governance program connects to all of the target applications and then correlates that data. So correlate is just a fancy word for joining that data to a single identity. So we connect to all of your sources and we form an identity. In this case, Will Harrington, and I've connected to all the target applications and gathered all of Will Harrington's account information and correlated it to Will. So therefore, if I look at Will, I can easily say and make a statement like Will has 50 accounts, okay? So then once we have that model, and you'll hear me talk about the identity model quite a lot, especially on the next slide. And then we aim to govern it. So we've got this nice model, we can overlay policies, roles and governance. So that's the governance part of IGA. What is governance? So if I go to request access, my manager approves that access, that's governance. That's a control point. And so that provides auditability. It proves why I have that access. Other governance could be an access review that takes a snapshot of me and my access, which my manager or an application owner goes through the list and says, Will should or shouldn't have that access. Identity governance also provides automation. So you'll see this with direct provisioning. So I talked about manual fulfillment and scripts to provision in target applications. Identity governance systems have hundreds of connectors. And these connectors provide direct connectivity into your targets. And that direct connectivity allows our systems to create accounts, disable, update, delete, move accounts, add entitlements, rename accounts, all of those account management and maintenance kind of operations can all be performed and executed from the identity governance system. So provisioning is really key as a part of this. Think about the volume of changes as a part of a MoG. We may be talking hundreds, thousands, hundreds of thousands of changes. Why not just automate it? Why do we need it to be manual, right? So we can easily automate when we connect to all of those target systems. We can also automate the onboarding of new staff members and making sure that when they start on day 1, they have access and they have access relevant to their job function. It doesn't have to be detailed access. It can be just enough so they could do 60%, 70% of their job. And then for that remaining 30%, they can request that additional access, what we would call like an ad hoc access request. And then everything is audited as well. So when we talk about breadth of identity, we talk about humans, machine accounts, so nonhumans, these can include service accounts, RPAs, bots, but I don't think they're directly involved as a part of the MoG. I've got a slide that talks about it a little bit later and how MoG's and machine accounts kind of have a bit of a peripheral relationship. Then we have third parties. So third parties fall into identity governance as well. You might have a cleaner that needs access to the buildings or you might have a broker that accesses your systems to provide a service on behalf of the government. You might have IT contractors like myself that access your systems to implement new applications and implement and digitize business processes. So IT consultants big within the third-party round. So you've got many ways that you can consider third party. These are basically people who are not coming through your HR system that have access to your IT systems. Often I see this as just a guest account in Entra, but that guest account has been given some entitlements and entitlements. And look, these accounts, as we stated earlier, should be included as a part of your MoG process as well. You might have an IT contractor in one particular department and they are then being moved to another department or the formation of a new department, maybe it's just a new domain name. So therefore, we need to be able to process that person. And then we have, last but not least, well, last and least, I suppose, is agents. So agents are getting a lot of chat these days. They're helping us do our work. They're automating business processes for us. They use large language model and generative AI to help us with all types of automation and tasks. One agent is made up of multiples. Tools are the feature within an agent that allow it to gain access to target systems. So maybe you might have 1 agent with 5 tools. And within those tools, that could provide additional information to the agent through connectivity to a data repository, maybe SharePoint, maybe an Amazon S3 bucket, maybe a data lake, maybe a database and maybe it executes a business process. These are what the tools do. In order for tools to execute, they need some kind of credential to be able to authenticate into systems. So therefore, these are highly privileged processes. And one thing that's probably worth calling out, this is a government session. So APRA recently set some high-level guidelines around the governance and the management of agents, and they've pretty much said that you need to draw a line of accountability. So what that means is that agents need to be owned by a human. What happens when that human moves from one department to another. We need a succession plan. So we can talk about like succession planning as a part of the identity model. And succession planning is probably key within the execution of a MoG. So the breadth of identity is the types of identities that we have, humans, nonhumans agents and third parties. Now we look down the identity model. So we've got the width. Now we have a look at the depth. We aggregate data from an authoritative source. So in this case, it's always a system of record like HR. HR, when I speak to government clients, they always talk about CHRIS21. CHRIS21 seems to be very popular within government, and that is your HR system, and we often connect to that system to get the authoritative attributes about you. So what are those authoritative attributes? Those are attributes like your first name, your last name, your preferred name, your middle name, your manager, your department, your cost center, your start date, your end date, everything that we can learn about you. Are you on leave? Are you on long service leave? Have you been suspended? Are you under investigation or something like that? All of that data matters. We use that data to form an identity view of you. So what that identity does is essentially provides a repository to store all of your access information about you and your accounts. So once we have that identity created, that identity is created with attributes. Those attributes are your HR information, and that is what starts to provide the identity management system with context. And context is key as a part of MoG changes, and we'll talk about that flow of information in a second. But once we have your identity created, we aim to connect to every target system. So I mentioned this earlier, your salesforces, every application that you've got within your department or your organization. We connect to all of those applications. That could be tens of applications. It could be hundreds, it could be thousands of applications. And we aggregate it in to the identity governance system as accounts. And then we sort through all of those accounts and connect those accounts to the relevant identity. So Will might have 20 accounts across 10 different systems. So I might have multiple accounts in 1 system, and we recognize that. So Will might have 3 Active Directory accounts and 3 Entra accounts. They serve a different purpose. They're meaningful. They're there for a reason, but we still need to connect them to the identity because they're relevant in order to be able to detect and run policy against Will. So a good example of being able to use just those 2 items of data, identity and accounts. If we think about that Department of Customer Service example, where the first query they wanted to run within their identity management system is show me everybody who is terminated in HR, right, authoritative source, the top-level information gets pushed down. Everybody who is terminated in HR, who has an active account, okay? That is something really easy that can be run as a query against your identity management system. So immediately from that, we can gain value. We can say, okay, well, let's disable those accounts, sure, all right. So we've got a better security posture now. Maybe we've reclaimed some licenses and we've saved a little bit of cost, like what were those hundreds of accounts that were enabled. Were they costing us money? Were they costing us subscription? Probably. So immediately, we can buy down risk and maybe save some money just by running this simple query just off the top 2 layers of our identity model. So this next layer down is entitlements. Every account, I might have 20 accounts. Each of those accounts might have 20 entitlements, 400 entitlements that I've got spread across my 20 accounts. And those entitlements provide different levels of risk. Let's use like a very course example, Active Directory, domain administrators, highly privileged entitlement. With it, it brings a high or a critical level of risk because if I am a member of domain admins, it basically gives me the keys to the kingdom. It allows me to access other applications. It allows me to perform lateral movement. It allows me to create my own accounts. It allows me to do everything. It allows me probably to access any application that uses Active Directory as authorization. So highly, highly privileged group to be a member of. So that's an example of an entitlement. The same works at the other end of the scale as well. There might be entitlements that simply grant access to the lunch order system on the Internet. And that's all grants access to so that anybody, even guests can log in to the Internet just to this one page to have a look at the lunch order system. So this is an entitlement that doesn't really carry with it much risk, but it's still there so that we can look at risk as a whole per identity. So if you have a look across Will Harrington's 400 entitlements, Will Harrington's 400 entitlements we can then analyze each of those entitlements, analyze the risk they bring to a particular identity. And then we can take that risk rate and apply it to the identity. So you could say, let's have a look at everybody and what is the risk, what is their risk rating, right? So Will, because of his membership in these groups makes them a highly risky identity. Everybody over here because of their memberships have a very low risk rating. So this allows us to make decisions about the [ recent ] MoG. Maybe those risk ratings can as a part of the MoG process. But I would say the more important thing would be to use because we've got knowledge of entitlements, we know that as a part of a MoG that if somebody moves between departments, whether an entitlement belongs to an application or belongs to a particular department or a government organization. And so we can say, okay, well, you're moving from transport to health, terrible example probably. So therefore, why do you need all your transport access, let's remove it. So we've got a view of the entitlement, we can remove your entitlement. And if there's one common AD account between transport and health, then you can keep your account, but we remove all of your transport entitlements. So it's good to be able to work at that entitlement level, especially for MoG's because as a part of a MoG, once again, I see it as an opportunity to buy down risk to remove people's access. Having come from financial services as well, when staff members moved across divisions, so if you went from retail banking to wholesale banking or institutional to retail banking or whatever that divisional move was, the action was to immediately remove all of that person's access, just remove it, right? So they're moving into a new division, make that person re-request their access once they have moved into that new division. I think that's great practice. It prevents permissions creep. It gives your organization an opportunity to be able to remove access, remove risk, improve security. Every entitlement is protecting something. It's protecting a business process, it's protecting a button, it's protecting a data, it's protecting a database, it's protecting something, it's protecting access to it. And in the case of data, we have the ability to be able to look at data and look at the classification labels that are applied to data. So a classification label is maybe something that you set when you send an e-mail and a pop-up comes up and says, is this public or private information or is it confidential or top secret or commercial-in-confidence like these are all classification labels that get applied to e-mails being sent in real time. This is the same applies to data. So sometimes when you submit a file into SharePoint, you do get prompted to apply classification labels. Sometimes there are background crawlers that interrogate that data and apply classifications based upon what has been crawled within that data. So if it detects private information such as a name or a phone number or an address or a tax file number, these patents can be identified and then classification labels can be automatically applied to that data. Those classification labels can then be promoted to the entitlement. So then you can ask questions or you can basically say, well, show me all entitlements that are storing or protecting secret information or show me all entitlements that are protecting production information, just as another label. So then you can build policy and ask questions of the identity governance system that uses that data mix, HR context and data context. So top down and bottom up, you can ask an example question could be, show me everybody who has access to the Board papers, okay? That's your classification, who is not on the Board? That is your HR context. Maybe that's your job title, that's maybe in your job description or in your division or however you are modeled as a Board member within HR can then be cross-checked against the data that is available to the person from the entitlement. So this allows, as a part of a MoG for an analysis to be performed so that as people move from transport to finance that they don't carry over any transport data with them. So as they move into the Department of Finance that they now no longer have access to their transport data and building out these models and correlating accounts and modeling entitlements and rolling all this data under a single identity allows us to do this. So it's a good way of validating the MoG post-move, even analyzing the MoG pre-move as well to say, okay, well, these are all our people. These are all the mistakes in data that people have today. Let's take this as an opportunity to also clean this up. So we've got this 6-layered system that can be used in a multitude of ways to be able to support MoG's. Okay. So if we have a look at the changes -- change the top of the stack, the rest recalculate. So if we have a look at this kind of all in practice in action, when a MoG is initiated, we expect that there's going to be some kind of HR or payroll change. There's going to be attribute changes at the top. So those attribute changes are things like maybe your department changes or your manager or your job title changes or maybe your e-mail changes, but maybe that gets dealt a little bit further down under the identity reevaluation. So number [indiscernible]. So those big changes happen at the top, we aggregate the data. The identity management system then evaluates this information and it says, okay, well, Will has changed his department from transport to finance. Therefore, let's execute changes based upon this. So using the identity model. So if we go back, we can change his accounts. We can change his entitlements, and we can review his access to data. So any entitlement that has been flagged as being owned by transport as I move to finance, those entitlements can be removed. And there's controls that are built into identity governance platforms that allow us to do this rather effectively. Every one of these changes is also audited. So we go back to that kind of scripting example where some awesome person has written a script that does all these changes, but how auditable is this? And where is the integrity of this file? And maybe you've got good ways of doing it. I don't know. But tell me otherwise, in the Q&A, add some commentary and say, Will, you're wrong. We do it all through scripts and it's all audited and everything is perfect and cool. Okay. So the evidence writes itself as a part of this. So imagine taking this 4-step process, big change at the top, the ministry directive, HR attributes are changed, identity recalculation and there's a lot of things that we can recalculate against such as a person's access. We talked about succession of ownership. So should a person still own the accountability for agents and machine accounts, that's a great time to recalculate. Access changes as well, like the entitlements that belong to a particular business process for one particular department, you now no longer need that. Why should you keep it? This is the ultimate question as a part of a MoG, is permissions creep? Let's remove it. Let's just take the opportunity to remove that access, nice and automated. We're not going to overburden the service desk because it's all directly provisioned because we can connect to those target environments. It's pretty amazing, really that it all kind of just pieces together. And it provides a real valued service as a part of just MoG's for government. The evidence writes itself. Everything is timestamp, everything is audited. I can go back in time and say, well, what access did Will have on May 1, 2024. And that would allow me to then be able to provide accurate audit evidence. Was Will's account used as a part of lateral movement by a hacker yes or no, or what access did he have at that point in time? Oh, he had domain admins at that point in time, but he's now a manager, so he now no longer has it. So therefore, his access was maybe used as a compromise that helps us understand the blast radius of an incident that may have occurred. So maybe that's just a good example. So let's take a look at some of the controls that are just standard in identity governance platforms. We've got life cycle management. This is basically an event trigger that executes a workflow upon a life cycle change. So what is the life cycle change? It's when a person joins an organization. So when a person moves within an organization, maybe across department. It's also when a person leaves an organization. That's the JML there for you. So when somebody joins, a series of actions occurred to get that person onboarded. Have they got their laptop? Have they got their password? Has their manager being notified? Have we applied roles, step 2 there to that person. So what we would call birthright roles provide you generalized access, maybe it's access that by virtue of simply being employed, you get that access, and that's what maybe a role can cover as a part of join and mover, lever. And then we have movers, right? So maybe you wish to build your MoG processes into mover. So this is where maybe your manager changes, your job title changes, your department changes. Any of these combinations either individually or combined together can be used as a trigger to then say, okay, well, because these 3 attributes change, let's execute a workflow off the back of that. And that workflow can do all sorts of things like maybe disable accounts or remove access or notify managers or the like. Then we have lever, termination processes. So in HR, your record has been terminated or you've met or exceeded your termination date. So these are ways that we can calculate termination. And then what do we do? We execute a workflow. We disable accounts. We delete accounts. We move accounts into the correct organizational unit in Active Directory. We notify people. We raise alert to say that we're all about to do this, and this is that flow. So this is what we call life cycle management. And I would say it forms an essential part of a MoG. So in financial services, we would process a divisional change as a termination and rehire. So we would terminate the person. Maybe I'm wrong there. But anyway, it's a configuration that we often implement, which is termination rehire. So we terminate the identity, delete the -- not so much delete, disable the accounts, move the accounts, remove all the relevant access. And then we rehire, which is basically processing the person through a joiner event again. We reidentify who that same person is, but they've got a different set of attributes that we pull in from HR about that person to then recalculate what their access should be on day 1 post-MoG. So roles and RBAC, for RBAC roles is basically role-based controls and roles. So roles encapsulate access. And what does that mean? So in order for me to be a Park Ranger, I might need 10 different entitlements. One of those entitlements gives me access to the building. Another entitlement gives me e-mail. Another entitlement gives me access to SharePoint and an Internet page. Another entitlement gives me access to a Teams channel that I use to communicate with my colleagues. Another entitlement gives me access to payroll. So instead of each of those entitlements being granted individually, we encapsulate it in a role. So the role then is used as a part of granting access to that Park Ranger. So instead of being assigned 5 different things, I'm just assigned one thing that then builds efficiency. So when you apply that logic across a large scale like the public service, the efficiencies are huge because you're dealing with a huge number of accounts, a huge number of applications and a huge number of entitlements, so it has this compounding effect across the entire public service for being able to deliver efficient access requests. Roles can also be requested through request catalogs. So in the case that the role wasn't automatically assigned because it's the Park Ranger role, right? So it's assigned to all Park Rangers. If I request it, I can still gain the access that is contained within that role. And roles can be structured in such a way where they provide on efficiency. So application teams can define their own roles and then those can then be encapsulated in a much larger, what we call like business roles or organizational roles or functional roles that encapsulate large groups of access under a single role, so you could have a role defined as Park Ranger. So all Park Rangers get or defined as legal clerk or defined as support worker or whatever it is across the public service, you can define a person's access based on their job function. This is probably the most efficient way of granting access because it encapsulates a lot of entitlements in order to be able to do the job. So as you can imagine, this provides a lot of efficiency for MoG's as well, especially good for a MoG because roles can be assigned. So therefore, as those HR values change at the top level of the stack, when they change, when I change my title from Park Ranger to Fisheries Officer, whatever it is, then the role that is assigned based on my job title Park Ranger, when my title changes to Fisheries Officer, that role is lost and all of the entitlements that it encapsulates are also removed from my accounts. But then I gain the Fisheries Officer role and therefore, I gain all of the entitlements that are included as part of being a Fisheries Officer. So this is simply by changing those higher level values that access is automatically reassigned and reapplied based on the actions and the data that exists at that top level. So we have request and approval interfaces as well. So in the case that access can't be automatically assigned based on a job function or an application, I have the option of being able to go to a central familiar common portal to request access in order to be able to do my job. I've just started as a Fisheries Officer. So therefore, I've got some access, I've got e-mail and Internet access, which is just default, but I need some additional access to gain access to buildings. So then I can go and request that individually and that access request is audited and approved. So we can also define policy and separation, so I can take mixes of that identity attribute data and entitlement data and define conflicting access. So no person who works in accounts payable should have accounts receivable access. So that would be what we call a separation of duties policy, and these can be defined in the system and the identity model can be used as a part of it. So defining these types of policies could be really valuable for MoG's and the public service in that as you move from one department to another, we know what your job title is and we know what department you're in. So therefore, we can define policies that say, well, if you're in department A, you should never have entitlements from department B. And that would be a policy that we can define within the system. That policy can execute a workflow, it can execute notifications. It can automatically remediate that problem through either disabling the access or removing the offending access and just notifying the correct people to make sure that things are then rectified and done properly. And then we have user access reviews. This is a snapshot in time for an individual and what access they have at that point in time. We often see this in financial services as well, where a person's job title changes. So then upon a job title change, the new person's manager or let's say, a manager change, the new person's manager then is presented with a list of all access and entitlements for that -- for the user, for the person, and that new manager has the option of either allowing or removing the access that, that person has. So user access reviews are often used as an audit artifact and organizations with highly privileged access are often subject to or obligated to performing user access reviews so that they can guarantee who has a privileged access and who doesn't. So we always see organizations who perform privileged access reviews for highly privileged entitlements like domain admins, something that you would want to review quite regularly because of its critical risk that opposes to an organization, so members of it. So people review this group quite often, and it's the user access review process that does it. But in the context of a MoG, this could also be used as a supplementary process that post-MoG changes, the -- all managers then review their direct reports access to make sure that nothing has carried over that they shouldn't have. It is an opportunity for those managers to remove access that is not required for their team to be able to do a particular job. So it's a great tool to be able to support, support activities both pre and post MoG's. So you would almost use the user access review pre-MoG to clean up access to make sure there's fewer items to begin with to have to worry about. And then post-MoG do another UAR so that any manager changes that have occurred as a part of the MoG, they then take responsibility for their direct reports and make sure that everybody has the correct access and nobody is over entitled. All right. So beyond the org chart, machine agents, data and value. Where do we go? What do we have here? A MoG moves more than people, these capability. Okay. So this is kind of like peripheral items of the MoG, so succession planning for machines and agents. As a part of good security practice, good identity governance, we like to build ownership structures so that any time a machine or a service account is created or an agent is created that we can attribute it to a human, to a person so that if an agent goes rogue, if a service account is used for a hacker's lateral movement, if a service account has been compromised, we can go to the owner of that account and say, what is this? What if a service account is pinging a system or whatever it is, the system is. We've got that ability to be able to draw lineage back to a person so that somebody can be accountable for it. And as a part of a MoG, this is kind of peripheral, but as people move departments and cross divisions and change their titles and jobs and whatever those large volume changes are, if you now no longer are accountable for some of these nonhuman entities that might exist within your technology system, that because we've got life cycle management and JML as a part of the termination flow, we can ask the question, does this person own any of these highly privileged entities? And if the answer is yes, who is the next logical owner? Is it that person's manager? Is it the application owner? Is it the divisional lead? Is it the security officer? Is it the CISO? It could be many. It could be whatever you define, but at least you've got a succession plan for these privileged entities so that they never go unowned because there's nothing worse than having service accounts that nobody knows who the owner is and somebody asked the question, what are these service accounts? What are they doing? Why are they so privileged? Can we disable it? And nobody ever wants to disable these accounts because they don't know what they're going to break, and they don't know where they're being used. Maybe they don't log in. Service accounts don't typically log in. So you can't track them for no log-in. So they do provide a range, a variety of risks because they're normally privileged and they execute our business processes and the like. So it's always good to have ownership. And if you're running MoG's, ownership will probably get lost. Let's not lose that ownership lineage. So that's what that's about. Data access governance. So this is another peripheral capability of identity management that allows the MoG process to check ownership and permissions on data pre-MoG and then post-MoG . This could just be a validating task that says, okay, well, the changes that we expected to make were made and the people who we expected to lose access lost access, the people we expected to gain access, gained access into their new files and repository. So data governance tied into identity can certainly be used as a part of MoG processes even if it is just there to validate access. Then we've got activity monitoring and shared signals framework. So with activity monitoring, this is kind of new shared signal framework, a new protocol that is a protocol to formalize event information between technical systems, right? So an event could be from an end-user device management system that says a particular computer or server is out of patch level, right? It's not up to date with its patching. So therefore, let's send an event to the identity management system to remove any entitled or proved access that, that person might be or let's contain that account so that the blast radius is reduced, and it can't be used as a vector for a compromise or a breach. So this works both ways in that the identity management system can use the shared signals framework and can send activity and event information from the HR the system through -- from the identity management system through to the security operations center and SOX, the SOX and all the tooling within that system as well. So in the event that we do identify an identity with a lot of highly privileged accounts with a lot of highly privileged entitlements, we can change the risk level of that person. We can say, Will has gone from medium to critical risk rating as an identity, and we can then share that information with the SOC. So then the SOC if, for example, detects that person logs in from a foreign country, can then perform its conditional access policies and say, well, let's downgrade this person to access based upon the risk rating generated by the identity management system and by where this person is logging in from, let's treat this person a little bit differently because they provide an unreasonable level of risk to organizations. And given sort of the morale aspect of Machinery of Government changes, maybe it presents a higher level of risk in that people through insider threat, maybe choose to exfiltrate data at a particular point in time. These sorts of signals can be detected and automations and workflows can be executed from identity management or the SOC to be able to lock down accounts in order to prevent incidents before they occur. Then there's the license and entitlement reclamation aspect of identity governance and MoG's opportunity to review all accounts that are no longer needed and disable and remove those accounts so that you may reclaim some cost as a part of that MoG process. So once again, see the MoG for an opportunity, not just an operational burden. Okay. And so continuing on the theme of the business case development. And the first one here is weeks on day 1 time, time to get access. So this is more of an intangible cost to the whole process in somebody, 1 person, 100 people, 1,000 people might be waiting days or several weeks to regain their access. And there's evidence of this in the VPS, the Victorian Public Service report published by Helen Silver at some point last year. It provides an example of operational inefficiencies due to movement of staff amongst departments. And these are -- these inefficiencies might be the result of people waiting to regain access post-MoG process. And there's evidence that some of these people are waiting between 6 and 8 weeks to regain their access. So that is downtime and inefficiency. If you had an identity governance system, you'd be able to automate that process, direct provisioning, let's not wait on the service desk to fulfill a ticket. Let's make sure that people have all of the access they need on day 1 to be able to do their jobs. It's easy to build a business case around this because you can build out your estimations. You can say, okay, well, there's these 1,000 people who are sitting around for 6 weeks at an average cost of x and a number of days. So therefore, this is the extrapolated cost of people being ineffective due to MoG's, right? So if you're building that business case, these are some really good numbers. And they tend to snowball very quickly when talking about people just waiting to gain access to systems. It's easy to sort of spit some numbers together to be able to sort of build it out. Fewer tickets for a MoG, we're talking about thousands of changes potential and some of those changes are going to be direct today through your scripts and provisioning but some of those are going to result as tickets. What is the cost of a ticket? So this is something that is a bit more of a tangible cost. So you might have 10 service desk staff members that take 100 days to be able to implement the volume of changes that flow down from the MoG. You could easily calculate a cost per ticket to be able to process all of that. So that's a tangible cost. And if you implement an identity governance system that has got good join and mover, lever flows as well as direct provisioning to a lot of target systems, that means fewer tickets. It means less people waiting, but it also means you need fewer people on the service desk to be able to perform the operations that flow down from those MoG's. So that follows on to manual provisioning effort as well. Audit and compliance, often auditors, internal or external auditors will audit your systems for how somebody got access to something. And when auditors are looking for evidence, they're looking across multiple systems. And they're often working with compliance staff members who are taking screenshots of what -- how access has been set up and they're collating all that information in documents and those documents are sent to the auditors. And there's a better way to do it, and that's through an identity governance system. So there's another potentially more tangible cost for compliance officers working with the auditors to make sure that they've got all the audit evidence and artifacts together. If you can be more efficient in that process, it means you need fewer people to assist the auditors in getting that data. So more of a tangible cost. And the last one there is license reclamation. Once again, take the opportunity of a MoG to review who is active or who is relevant for a particular department and making sure that they don't have applications that they don't need as a part of their new job, especially in SaaS, especially for organizations to adopt a lot of SaaS, there should be an opportunity to reduce the cost in terms of licenses. And then the last one is exposure close, cost of a breach, all in pink, IBM just released the cost of breach report today, I think that's what it's called, and the cost is going up. And the cost is perceived to be maybe low in that it's gone from $4 million per breach to $5 million a breach. So the cost of a breach is going up. But if we have a look and scan the media and the press for some very high-profile breaches that have occurred in Australia, big insurance company, Medibank, Latitude, Optus, Medibank, I just checked an article recently, and the cost is somewhere in the round of $100 million. So this is the result of class actions, lawsuits, new strategies, new transformation projects, adoption of new software. I'm sure it all snowballs into a much larger cost, but the cost of a breach is much higher than $5 million. I highly recommend the IBM report and that you read it and check it out. It's become a bit of a staple for our talk tracks every year, but it's not surprising to see the cost is going up, and we can only expect more breaches to occur with Agentic technology and AI being used as a part of the offensive approach to exfiltration of data from organizations. So we can only expect more. And one factor of a breach is reputational damage and I suppose government systems like provide and technology systems and the systems that we all interact with provide efficiencies in services like I can lodge my tax or I can complete the census or I can show my driver's license ID all through these great government systems. But if I don't trust those systems, I'm not going to use those systems. So therefore, we all become less efficient. And if the government can prevent breaches, they maintain trust. So therefore, we use these amazing [indiscernible]. So I suppose that the cost is generalized efficiency and reputation and trust in the systems. So I'm at the end of the presentation, and I'd be very keen to hear questions. I hope you've been able to keep some questions in as a part of this presentation. And yes, let's answer some of those questions. And yes, thank you. Also, we have a white paper called Securing Machinery of Government changes, and we'll provide a link to that in the chat box.