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 four-part series of webinars directed at government organizations. Through this webinar series, we will be talking about how we can apply identity practice to some typical government settings. One of those settings is the machinery of government changes and how identity governance, or I am 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. As a part of securing machinery of government changes, I am going to start saying MOG. Machinery of government is quite a tongue twister, and it is getting a little bit tiring. So I am going to go to MOG and IGA. When I say MOG, you know I am talking about machinery of government changes. As a part of today's presentation, we will be covering what is a 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. 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. Today we will 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. Second on the list is the challenges of managing a MOG. What are they? What is a MOG? The challenges of managing a MOG. There is a lot of data that changes hands as a part of a MOG, and we will get into the details of that, what the current practice is. I have 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. I have had the opportunity to talk to a lot of public service employees, and I have queried them about how they go about machinery of government changes, and they have been able to share some details. So this is just a bit of a collation of that sharing and just what I thought was the most common. Then we are 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? Let us finish up with how to build a business case. How do we build a business case through the lens of a MOG? 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?" I think a MOG provides a really good place to begin that conversation. One announcement redraws the whole org chart. 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. 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. 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. The result of that is lots of change, lots of staff members maybe changing their job titles, changing their domain or email 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, but we see it in private sector as well. 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. In the public service, it's just pretty much the same thing, but very much in a high volume, right? It happens quite often. 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. You've really got to ask the question for some of those non-human entities as well. We're talking a lot about agents these days and machine accounts. We've talked about third parties, but what happens to the ownership of those agents? There's a lot of questions. What happens to all of the access of the staff and the contractors who have that access? That's really forming the basis of this conversation today in that, pardon me, 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. These are the sorts of the problems 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 timeframe as well. What's the final result of a lot of this? It's being able to still deliver services to citizens effectively. 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. If we have a look at the order of things, just in case you don't know, a MOG order is announced, spreadsheets are compiled. 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. What do they do with these spreadsheets? They collate 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 instructions or operations." Somebody on the service desk has got to work through a lot of different applications and systems. 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. 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. 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 erroneous 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 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? How do we know that the code that is executing on those spreadsheets is good? 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 cannot refer back? How do we audit that? How do we know that this code is good, and what is the reusability of this code? So some really big problems when we are just dealing in the world of spreadsheets. It is okay, though. We have got a good answer. Accounts keyed in. That is the carry on from spreadsheets, and then we have got access copied like for like. This is just something else that I heard quite a lot at 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 we look at somebody else who is similar, maybe a similar manager, similar 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 Model ID in the old mainframe world, where we would just take somebody and replicate that person to then set up that new user. But that is quite erroneous. The world has 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. Number 5 and number 6. So we have also got old access disabled later and cleanup deferred. They are the same, but this is where we are dealing with large volume of change. Today, I could be dealing with the onboarding of some of this large volume, but tomorrow I am going on annual leave, and I will deal with that disabled access later. This sort of stuff happens all of the time. We have a case study that is in the public domain for a New South Wales government department that utilized 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 terminated. 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 is the old let us disable it later kind of factor, or maybe there is other reasons why that was the case. But humans being humans and the way we are, we often get distracted and there is competing priorities that we have 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. 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 is a lot of movement happening at once, let us take advantage of what we would call an event. Let us take advantage of the MOG event so that we can improve our security postures. When the move is manual, the risk is structural. What is the risk? Security privilege creep. We have 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 three different departments but held the accounts and entitlements from their first department. That is the typical scenario for privilege creep. Dormant and orphaned accounts. I have already resigned from the public service, and I have still got active accounts, or I have moved on from one department to another department, but the accounts in my old department are still maintained. From an audit and assurance perspective, this is an audit and assurance nightmare in that the way that we implement our MOGs through scripts, this is not really auditable. Unless there is some kind of audit log that has 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 that data evaporates, and we know that we do not maintain it. I am sure there are 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 is not the majority in this case. Continuity and operational risk. Because of the operation, because of the volume of changes that take place as a part of a MOG, there is always a continuity and operational risk. When we are making bulk changes across a lot of data, there is always some kind of level of oversight in that maybe we misspelled a 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 are a few people on this call who would be kind enough to admit maybe when they arrived to work one Monday, that none of their access was there. Maybe it was unavailable. In the Q&A please put your input. I would love to hear about it. 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 there's always something that results in unexpected. I've got some really good stories about my time in financial services and some of these large changes that we implemented. There was 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. This is pretty big in financial services. 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. The risk there is that you retain access to some data that you shouldn't. 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? 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. 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. Let's bring in identity governance and administration. We're going to talk about the breadth of identity governance. Connect, correlate, govern, automate, prove. That is such a nice workflow, and that's exactly what an identity governance program does. What do 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. An identity governance program connects to all of the target applications and then correlates that data. Correlate is just a fancy word for joining that data to a single identity. 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. Therefore, if I look at Will, I can easily say and make a statement like, "Will has 50 accounts." Okay? Then once we have that model, and you'll hear me talk about the identity model quite a lot, especially on the next slide, then we aim to govern it. We've got this nice model. We can overlay policies, roles, and governance. That's the governance part of IGA. What is governance? 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. You will see this with direct provisioning. 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. 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. Provisioning is really key as a part of this. Think about the volume of changes as a part of a MOG. We are maybe talking hundreds, thousands, hundreds of thousands of changes. Why not just automate it? Why do we need it to be manual, right? 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 one, 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 an ad hoc access request. Then everything is audited as well. When we talk about breadth of identity, we talk about humans, machine accounts, so non-humans. These can include service accounts, RPAs, bots, but I don't think they are directly involved as a part of the MOG. I've got a slide that talks about it a little bit later, and how MOGs and machine accounts kind of have a bit of a peripheral relationship. Then we have third parties. 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. IT consultants are big within the third-party realm. 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 certain entitlements. 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. Therefore, we need to be able to process that person. Then we have last but not least, well, last and least, I suppose, is agents. Agents, they're 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 models and generative AI to help us with all types of automation and tasks. One agent is made up of multiple tools. Tools are the feature within an agent that allow it to gain access to target systems. So maybe you might have one agent with five 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, 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. Therefore, these are highly privileged processes. 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. 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 succession planning as a part of the identity model. Succession planning is probably key within the execution of a MOG. Identity. The breadth of identity is the types of identities that we have. Humans, non-humans, 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. 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. What that identity does is essentially provide a repository to store all of your access information about you and your accounts. 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. 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. 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. We aggregate it into the identity governance system as accounts. 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 one system, and we recognize that. So Will might have three Active Directory accounts and three Microsoft Entra ID 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. A good example of being able to use just those two 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. That is something really easy that can be run as a query against your identity management system. Immediately from that, we can gain value. We can say, "Okay, well, let's disable those accounts." Sure. All right? We've got a better security posture now. Maybe we've reclaimed some licenses and we've saved a little bit of cost. What were those hundreds of accounts that were enabled? Were they costing us money? Were they costing a subscription? Probably. Immediately we can bite down risk and maybe save some money, just by running this simple query just off the top two layers of our identity model. 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. Those entitlements provide different levels of risk. Let's use a very coarse example. Active Directory, domain administrators, highly privileged entitlement. With 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 privileged group to be a member of. 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 intranet, and that's all it grants access to, so that anybody, even guests, can log in to the intranet, just to this one page, to have a look at the lunch order system. 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. If you have a look across 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 grade and apply it to the identity. So you could say, "Let's have a look at everybody. What is the risk? What is their risk rating? Will, because of his membership in these groups, makes him a highly risky identity. Everybody over here, because of their memberships, have a very low-risk rating." This allows us to make decisions about the risk MOG. Maybe those risk ratings can be used 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. 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 MOGs, 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. So they're moving into a new division, make that person re-request their access once they have moved into their new division. I think that's great practice. It prevents permissions creep. It gives your organization 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. 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 email, and a pop-up comes up and says, "Is this public or private information, or is it confidential or top or secret, or is it commercial in confidence?" These are all classification labels that get applied to emails being sent in real time. 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 patterns 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 is your job title, that is 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. 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 do not carry over any transport data with them. 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 up under a single identity allows us to do this. It is 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 us take this as an opportunity to also clean this up." We have got this six-layered system that can be used in a multitude of ways to be able to support MOGs. Okay. If we have a look at the changes, change the top of the stack, the rest recalculates. If we have a look at this all in practice, in action, when a MOG is initiated, we expect that there is going to be some kind of HR or payroll change. There is going to be attribute changes at the top. Those attribute changes are things like maybe your department changes, or your manager, or your job title changes, or maybe your email changes, but maybe that gets dealt a little bit further down under the identity reevaluation, number two. 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 us execute" changes based upon this. Using the identity model. If we go back, we can change his accounts, we can change his entitlements, and we can review his access to data. Any entitlement that has been flagged as being owned by transport, as I move to finance, those entitlements can be removed. And there is controls that are built into identity governance platforms that allow us to do this rather effectively. Every one of these changes is also audited. We go back to that 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 have got good ways of doing it, I do not know. But tell me otherwise. In the queue, add some commentary and say, "Will, you are wrong. We do it all through scripts and it is all audited and everything is perfect." And cool. Okay. The evidence writes itself as a part of this. Imagine taking this four-step process, big change at the top, the ministry directive, HR attributes are changed, identity recalculation, and there is a whole lot of things that we can recalculate against, such as a person's access. We talked about succession of ownership. Should a person still own the accountability for agents and machine accounts? Hey, that is 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 just pieces together and it provides a real valued service as a part of just MOGs for government. The evidence writes itself. Everything is timestamped, everything is audited. I can go back in time and say, "Well, what access did Will have on May 1st, 2024?" 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? 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. Therefore, his access was maybe used as a compromise that helps us understand the blast radius of an incident that may have occurred. Maybe that's just a good example. Let's take a look at some of the controls that are just standard in identity governance platforms. We've got lifecycle management. This is basically an event trigger that executes a workflow upon a lifecycle change. What is a lifecycle change? It's when a person joins an organization. When a person moves within an organization, maybe across departments. It's also when a person leaves an organization. That's the JML there for you. When somebody joins, a series of actions occur to get that person onboarded. Have they got their laptop? Have they got their password? Has their manager been 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 joiner, mover, leaver. Then we have movers. Maybe you wish to build your MOG processes into mover. 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 three attributes changed, let's execute a workflow off the back of that." That workflow can do all sorts of things like maybe disable accounts or remove access or notify managers or the like. Then we have leaver, termination processes. In HR, your record has been terminated, or you've met or exceeded your termination date. These are ways that we can calculate termination. 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 alerts to say that we're all about to do this, and this is that flow. This is what we call lifecycle management, and I would say it forms an essential part of a MOG. In financial services, we would process a divisional change as a termination and rehire. Maybe I am wrong there, but anyway. It is a configuration that we often implement, which is termination rehire. We terminate the identity, delete, disable. 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 re-identify who that same person is, but they have got a different set of attributes that we have pulled in from HR about that person to then recalculate what their access should be on day one post-MOG. Roles in RBAC. RBAC roles is basically role-based controls and roles. Roles encapsulate access. What does that mean? 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 email. Another entitlement gives me access to SharePoint and an intranet 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. Instead of each of those entitlements being granted individually, we encapsulate it in a role. The role then is used as a part of granting access to that park ranger. Instead of being assigned five different things, I am just assigned one thing that then builds efficiency. When you apply that logic across a large scale, like the public service, the efficiencies are huge because you are dealing with a huge number of accounts, a huge number of applications, and a huge number of entitlements. 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. In the case that the role was not automatically assigned, because it is the park ranger role, right? It is assigned to all park rangers. If I request it, I can still gain the access that is contained within that role. Roles can be structured in such a way where they provide on efficiency, so application teams can define their own roles and then those roles can then be encapsulated in much larger, what we call business roles or organizational roles, or functional roles, that encapsulate large groups of access under a single role. You could have a role defined as park ranger, so all park rangers get it. Or defined as a 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. As you can imagine, this provides a lot of efficiency for MOGs as well, especially good for a MOG because roles can be assigned. 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. All of the entitlements that it encapsulates are also removed from my accounts. 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. 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. We have request and approval interfaces as well. 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, therefore, I've got some access. I've got email and intranet access, which is just default. But I need some additional access to gain access to buildings. Then I can go and request that individually, and that access request is audited and approved. We can also define policy and separation. I can take mixes of that identity attribute data and entitlement data and define conflicting access. No person who works in accounts payable should have accounts receivable access. 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. Defining these types of policies could be really valuable for MOGs 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. Therefore, we can define policies that say, well, if you're in department A, you should never have entitlements from department B. 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. 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. 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 the user, for the person, and that new manager has the option of either allowing or removing the access that that person has. 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 privileged access and who doesn't. We always see organizations who perform privilege access reviews for highly privileged entitlements, like domain admins. It's something that you would want to review quite regularly because it's a critical risk that it poses to an organization for members of it. 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. 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. It's a great tool to be able to support activities both pre and post MOG. You would almost use a 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's over entitled. All right. So beyond the org chart, machines, agents, data, and value. Okay. 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. 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 our 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. 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 non-human entities that might exist within your technology systems, that because we've got lifecycle management and JML as a part of a termination flow, we can ask the question, does this person own any of these highly privileged entities? 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 asks the question, "Well, what are these service accounts? What are they doing? Why are they so privileged? Can we disable it?" 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 logins. They do provide a range, a variety of risks because they're normally privileged and they execute our business processes and the like. It's always good to have ownership, and if you're running MOGs, ownership will probably get lost. Let's not lose that ownership lineage. That's what that's about. Data access governance. 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 repositories. 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. With activity monitoring, this is kind of new. Shared Signals Framework, it's a new protocol that is a protocol to formalize event information between technical systems, right? 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 privileged 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. 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 system, from the identity management system through to your security operations center and the SOC, and all the tooling within that system as well. 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. 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's 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." Given 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. There's the license and entitlement reclamation aspect of identity governance and MOGs. 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, continuing on the theme of the business case development. The first one here is weeks on day one, time to get access. So this is more of an intangible cost to the whole process in that somebody, one person, 100 people, 1,000 people might be waiting days or several weeks to regain their access. 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. These inefficiencies might be the result of people waiting to regain access post-MOG process. There's evidence that some of these people are waiting between six and eight 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 one 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 six weeks at an average cost of X and a number of days. Therefore, this is the extrapolated cost of people being ineffective due to MOGs." 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 spitball some numbers together to be able to build it out. Fewer tickets for a MOG. We're talking about thousands of changes potentially, and some of those changes are going to be direct maybe 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. If you implement an identity governance system that has got good joiner, mover, leaver 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 MOGs. 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. When auditors are looking for evidence, they are looking across multiple systems, and they are often working with compliance staff members who are taking screenshots of how access has been set up, and they are collating all that information in documents, and then those documents are sent to the auditors, and there is a better way to do it, and that is through an identity governance system. There is another potentially more tangible cost for compliance officers working with the auditors, just to make sure that they have 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. 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 do not have applications that they do not need as a part of their new job, especially for organizations who adopt a lot of SaaS, there should be an opportunity to reduce the cost in terms of licenses. The last one is exposure closed, cost of a breach, all-encompassing. IBM just released the Cost of Breach Report today, I think that is what it is called, and the cost is going up. The cost is perceived to be maybe low in that it has gone from $4 million per breach to $5 million a breach. The cost of a breach is going up. 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 realm of $100 million. This is the result of class actions, lawsuits, new strategies, new transformation projects, adoption of new software. I am sure it all snowballs into a much larger cost. 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 has 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. We can only expect more. And one factor of a breach is reputational damage. I suppose government systems provide, and technology systems and the systems that we all interact with provide efficiencies in services. 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, therefore we all become less efficient. And if the government can prevent breaches, they maintain trust, therefore we use these amazing systems. So I suppose that the cost is generalized efficiency and reputation and trust in the systems. I'm at the end of the presentation, and I'd be very keen to hear questions. I hope you've been able to key some questions in as a part of this presentation. And yeah, let's answer some of those questions. And yeah, 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. So thank you for-