Risk-Based Approach to Defining IAM Requirements [Intermediate]

Thank you for the opportunity to discuss this. I have been in the IAM space for about 15 years, and I have seen the evolution from an organization looking at IAM from an IT efficiency and security perspective.

This new, at least now relevant, NIST 2 regulation or external regulation and other EU directives which are coming are bringing this compliance perspective to more front on this area. So maybe some pre-warnings. This is of course a topic which is also maturing at Fortum, but I want to have this opportunity to tell how we are approaching compliance and compliance reporting, and how do we organize or modify our responsibilities for compliance reporting. So that's kind of the setting here. No definite truth, but I think the understanding of how do we want to go forward on these capabilities.

So a few words about Fortum. We are a Nordic energy provider. Last year we generated about 46 terawatt hours of clean CO2-free power using our nuclear and hydro plants in the Nordics. So we have in Finland nuclear plant and hydro and also wind farms for that consideration. And maybe some of you have heard Fortum earlier. Some years ago we were kind of trying to acquire Juniper. So it was in the German news that time, I would assume. So as Fortum's power generation and heat production in Finland, Sweden, and Poland is part of this NIS2 directive, and kind of the energy sector, energy focused.

So we are a critical entity in that sense. So we are under this NIS2 regulation. It's good to mention, of course, before we have had other kind of different kind of regulation coming from, let's say, Stuk, the Finnish nuclear kind of agency, and also other regulation, either government, national, or our internal controls. Going there. So in our kind of how do we approach this IDX management and the risk-based is that I sum it up in three categories. So we need to verify the user identity when they are accessing our data and applications.

So having that different levels of trust depending on the use case. How do we better control the data access? So end of the day, the IT and OT systems, what we have in Fortum, they control, they have our company data and operations. So we need to have a kind of better control of why are persons accessing our systems, and based on these kind of policies and guidelines, which I'm going to talk about.

And then, of course, improve and maintain security. And then the compliance alignment, which is kind of the, I would say, has been a raising theme over these years now. And how do we kind of approach this?

So, of course, we have the kind of, as we are in an IAM conference, so we have the kind of the technical capabilities of IAM services and the technical capabilities through the IAM operations. But from looking kind of how do we start building that kind of compliance and enforcing the compliance to the systems. So the kind of statement of applicability that we need to be kind of, we need to formalize what kind of controls and requirements are there to applications.

And this is typical to an organization that in high level that they know that, okay, internally we are using ISO 27,000 and there are some other regulations, but there's really kind of this kind of a mapping of what are the exact security control requirements what we have for the applications. So mapping these regulations, internal, externals, to the organizational scope and applications what we have in different regions and in different environments is kind of the, I would say, the focal point.

And building those kind of what are the different kind of, and visualizing that kind of, of course, the application teams, these are the exact requirements that you need to fulfill and also communicating then to the leadership, but again, these are kind of like what are the requirements. So I think that this kind of evaluating the control applicability is the kind of the focal, what we are building in the long term. And then how do these kind of applications then fulfill those control requirements?

Then the centralized services, what our team provides, providing the IGAs and BAMs and ADs and enter IDs. So those are ways for the applications to teams cost efficiently fulfill those control requirements. But it's more like that we end of day are interested that the control requirements are fulfilled either in the application or using the kind of the centralized services. And part of our, let's say, the area where we are now improving our maturity and capability is also in this kind of like the centralized support services.

So how do we better communicate to the teams that these are the kind of the risk-based kind of requirements for your particular application and the data, what is in the system? And our team provides, we define these guidelines so that they are kind of fulfilling the requirements, but also are kind of, let's say, consumable by the application teams, which, of course, always have their normal business things to do. So they don't need to be kind of experts on regulations.

And then when implementing those controls, then involving the business side of the kind of application who are kind of whose data and processes are managed in the application, and then the IT operations who are then more kind of implementing those controls for the applications. So it is, to me, it's a good kind of high-level picture to show what kind of capabilities, non-technical capabilities that you need to also understand what are in play to fulfill the kind of from left to right to really kind of map those. And what I'm now focusing more is actually the IAM guidelines.

So what is the kind of the risk-based kind of approach on defining, like, what are the exact requirements? And our guideline is based on these four, let's say, IAM control categories. And many of you might have kind of guessed that these are very much having taken kind of inspiration from the NIST digital ID guidelines. So looking at the kind of ID assurance, authentication assurance, and the federation assurance. And we have kind of complemented that with the kind of the authorization part with what the NIST doesn't, to my understanding, have.

So also looking at the different levels of authorization, like how the authorization needs to be managed. And using these four kind of components that we see that IAM-related controls can be fulfilled. So looking at there's kind of either if it's a kind of customer-facing consumer application, an IT application used by our employees, or in OT systems by our kind of operational people, but also the partners doing the maintenance. So that's kind of the how do we structure and the kind of conclusion or kind of how do we kind of communicate these.

Then we have the kind of the how do we set those kind of IAM requirements for the data access. So based on these kind of four categories, assurance kind of levels or categories. And we take the data classification of what kind of data the system has. And this sets the baseline requirements that the application needs to implement. So of course the business owners and application teams, they can set more stringent or stricter controls. But we are looking for like setting the baseline across our IT and OT landscape to ensure that the minimum criteria is met.

And I think the important here is that data classification, and of course this is something that kind of we in the IAM team cannot control by ourselves. So we need to kind of work with the data team, with the IT service management team, that the other processes are in place and our IDSM data, metadata for the application is correct. But that's kind of the input what we take and then define these kind of minimum controls. So for example, if you look at access rights authorization, so baseline minimum requirement is that there needs to be a judicial contract in place.

So if a customer or employee or subcontractor, we need to have a formal kind of contract in place to ensure the access. Then it might be that based on that job role, they might get some automatic access to the application if it's more low priority, that priority application. But then we can start adding more controls if it's more like confidential or more medium criticality. So having that single approval or having multi-level approvals.

And then, so that's the idea that setting these kind of basic requirements. So I think that authentication, so looking at the single factor, multi-factor, session length, then digital identity, looking at the kind of the, for some use cases, it might be some demo site that the identity can be just email-based, email verified identity. But if you go more and more deeper, then we need to start having kind of in-person checks of who you really are and so on.

The fourth one actually is quite interesting and something easily overlooked, is this kind of the craft network configurations or the federation insurance. So how do we ensure that the data, the user data and entitlements which are passed on to the application on these federated sessions, so that those are encrypted properly and the tokens are protected, that they cannot be hijacked. So that's an area that related cryptography on that, so that we are maintaining the trust on those sessions transfers.

So this is actually the kind of the, it seems kind of very simple kind of matrix, but I think that having the, this is what we have seen that this is actually a quite simple way of communicating the requirements for the application team. So of course, having like hundreds of application teams, they don't have kind of a time to kind of learn what specific controls I need to implement, but just kind of simplifying using the data as a driver, which is the data classification, which is set by the business.

And then, if the business classifies the data on this level, so it has these effects on the usability and kind of how persons access the, need to authenticate and kind of get access rights. Now that we have set the kind of, let's say, the basic foundation, like these are the kind of the rules we need to set, then there's of course the kind of the people part and the process part. So maybe some of you have heard this kind of a three line of defense framework, which is used in risk management.

So in the first level, so in the first line of defense, so you have the kind of operational team who's managing that particular application. So user is requesting access to an application. There might be that person's supervisor, manager involved, but then it goes to the system manager for that particular application, who operates on behalf of the data owner, who typically comes from the business side.

So, and these parties are kind of, are responsible for the daily operations, so how accesses are given and revoked and the least privilege is happening. But in order to ensure that this process is happening, accesses are given and accesses are removed. So we have our kind of a internal second line, the IAM compliance here. And these are kind of your typical, like if you think like in a CISO team, so that they are more like they're kind of ensuring that this process is working, and also that the improvements are done on the process.

And then also ensuring that auditors, internal, external, the third line is kind of working with them. How is our process working? So mapping these, identifying the stakeholders, and using this three line of defense framework, which separates the duties and assigns who is responsible for what, is a very essential way of ensuring that the process continues and goes forward. So just a kind of summary.

So, so far our kind of a, let's say learnings and recommendation. So you need to have that governance framework. So what I just told about the, and applying that three line of defense model, so that you have kind of, and also how do you communicate and work with different stakeholders? Then streamline IAM operations. So that's more like the kind of where tooling helps you.

Okay, is the kind of access request, can they be included in the service in our portal, or how difficult for some of the DevOps team is to kind of manage their resources, and also having the visibility for managers and others on the permissions. And then thirdly, compliance and risk management. So having that second line, IAM compliance, looking at that the process is working, kind of that there's improvements are done, and also ensuring that we are kind of able to do the compliance reporting for the leadership, but also for external and internal auditors. So thank you.

That's my kind of presentation on this.