Appropriate Level of Assurance - A Foundation for Proper CIAM

I work for the largest insurance company in Scandinavia and Baltic countries, which is if insurance, and we strive to be the digital first company. It means that in some countries we rarely have some offices just really mainly working online. And we have a motto of trust is our backbone. And insurance, it's all about trust. Because we sell promises, we have to be trusted, but especially in digital channels, we need more trust and authentication is something which brings more trust there into our communication with the customers and also partners.

So to ensure we maintain a proper level of privacy, data protection, fraud prevention, and constantly changing the le legal landscape, not that alone. Also, authentication is something which unlocks really nice and smooth customer journeys for, for our business to provide to the customers. And just a quick, quick over quick really quick overview of, of technological landscape or, or behind the authentication services. Within our infrastructure, across all countries, we operate for the means of different business teams deliver delivering services to customer or partner facing services.

We have established like an internal broker service for authentication services, which is connected to all the different identity providers widely used in the respective countries. So they all are connected to the same like hub. So we simplify lives of our teams. So we isolate them from the burden of connecting to each and every provider. So what they just have one pipe for that. And we take this burden on us within IM team and within i m's overall, IM stack this identification and authentication service is something which unlocks the capabilities for proper identity management.

So the authenticated customer gets into the context of our relationships and for authorization services to equip user with the proper permissions to access data and to act upon this data at that specific moment in time. So I would say that in fact, authentication is the most mature service in the stack and it's the key for all others, other services to work properly for us, for the benefits of even our customers. But it hasn't been that way before because we experienced a lot of inconsistencies before. So in authentication domain specifically.

And because originally each team was responsible and was dealing with their authentication problems themselves. So they build their own ways to authenticate. They had their own ideas how and when they should be authenticating customers and users. And this was due to, and, and inconsistencies appear due to different level of expertise of knowledge, of experience in the teams due to different needs of the businesses and risk appetite of the, each part of the business.

Each country or even each business area would have different legal set up, which also introduced more uncertainties and different timeframes, tech time constraints and technical constraints and, and legacy systems like mainframes. And so what, and world was also and is constantly changing around. So what used to be good is not anymore. So threat landscape was changing and is changing and also legal frameworks are developing and coming upon us. We need to deal with that. So this all was causing a lot of inconsistencies and we are very fragmented in authentication before.

And this exposed us to the risks which were not really clear. So because we had no good governance around that kind of risks, and therefore they cannot, could not be managed properly. And we brought different people into our like initiative into four workshops for, for this initiative, from business, from legal, from data privacy office, from i, it, and Im obviously architects to find a way to establish a more clear guidelines and or standards or policies for the teams to follow.

So it, but in the way that it's not just forcing on police in them, but to be helpful and useful for them in everyday life when they prepare deliveries to deal with authentication. So we at the same time wanted to leave flexibility for them to innovate, not to restrict them within the predefined boundaries. And when we started, we just looked around what do we have? And we had one term which was widely used around so strong authentication. So everybody was using it, but we couldn't find, and it obviously had never been defined in our company what, what it meant.

So, and it meant different things to different people. So, and that was a problem. It was a kind of shield from the problem. So we just was hiding behind that and let's, we started with it. So let's just try to define what song authentication meant or means for us. We ended up that obviously we need to, to tell what's important, what is good and what is bad authentication.

So, okay, that, and this is not from the book, this is just the list created like organically by, by, by us. So okay. We needed to know what the real life identity of the person is. It's important for us, yes. For our business. Okay. We need to know how this authentication method generates some secret for the user to authenticate and how this secret is being bound or connected to the verified identity. It is important.

How do, how is the secret then protected throughout its lifecycle and when it's used as a proof of possession. So how, how do we get this like evidence from the user during an authentication session? How do it was important also, how do we manage the authentication authenticated sessions? So creating terminating sessions and also what, how is the end of life of the secret handled by this particular method. So when the secret is expires or is being revoked, these all things work obviously important for us.

So, and this would be the answer, whether the method is good or not good for us, of course, good. Now good was not sufficient, like split. So we ended up, we were inspired by ISO standard, but we didn't take this like one to one. We adjusted it to towards our needs. And we ended up with three levels of authentication, low, substantial and high. And it was important to create down to earth definition of what is this level of assurance for IT teams and also for technically minded business people to understand it easily, why and what is a substantial level of assurance or high or low.

And it, I would say this is so often used in com in internal communication that it's, it's, it's the key element of the whole guidelines. Yeah. And when we de when we was over with this job, we've suddenly got the definition of strong authentication. Now it's either substantial or high level of assurance. You can keep using this term if you want.

So, but now it has its own definition. Finally, that was also a good delivery. And when we have definition, we have defined the requirements, okay, we can, we could now land every method towards its home level of assurance, like substantial high or low.

So, and the team can now pick, okay, if I need substantial, that's the way to go. However, one main question was not answered yet. So which level of assurance do I need for my service in this point? So because it, that's the main question. And this is where we couldn't avoid being specific about insurance, insurance industry. And we also, since we wanted to keep it simple, let's make it simple.

We tried, we, and we, we, we actually have done this, we listed all the different data types, which we normally process within insurance business do domain, so like policies, claims, health, data per like person's data, cars, you name it in insurance. And we mapped each and every data type to the level of assurance. So which we would minimum require in order to this type of data to be exchanged with remote party, with user or with customer or partner.

The direction of the data flow also matters because these can be very much different requirements depending on who is sharing data towards us or from us. And this table looks really simple and straightforward. So data type and then direction. And then you pick it low, substantial. And of course it was also obvious that we cannot be distinctive for each cell in this table. It's not possible to cover everything and to predict everything because there are other consideration of, or factors which need to be considered in some cases.

So in that case, we decided to go to suggest to use general principles, which is kind of common sense, but still needs to be defined. And, and in fact it's, it, it tells you that please go for higher level of assurance whenever you deal with sensitive data or larger data sets or you are combining several multiple data types, or you want to update data records in our systems.

So that's, that's where we need more trust in the relationships. So it's, it's had, it has risk-based approach behind, but we need to phrase it in a simple word. And of course the weakest point in the, like this supply chain defines the overall level. So we want it also to extend these guidelines towards our partners because we, the process or the use case usually crosses different companies towards the way to the customer.

So, and once we've got these guidelines, we now try to implement or consider these guidelines when we do integrations towards partners. So it's by design should be there. And we also try to embed requirements similar or very close to, to what we have defined into our legal setup with partners. So that's important. So we try to raise the awareness to raise the responsibility of each party from keeping up with these needs to ensure good level of trust in authentication.

It's not always perfectly possible of course, and because the chains used to be long, so we cannot reach maybe every partner, but still we do our best to, to accommodate this. And the life is not perfect, of course. So otherwise we wouldn't be doing this.

So, but we want to be, become better with every step in every day. So, and therefore we, we are realistic, we allow exceptions and, but, and exceptions are our vulnerabilities in fact. So it's vulnerability. But what we want, we want this vulnerability to clearly understood, documented, and managed so that at some point we, or, or we can that in, in, but that we can mitigate the risk maybe in some other way, maybe not fully, but at least partially. And at some point we could also totally avoid and, and just fix it.

So this way we still become better even when we have exceptions and in order to bring some dynamics into this. So how do we actually make it alive? So we need some, some dynamics into this.

So to, to apply guidelines to raise the awareness to, to, to make use of guidelines. We decided to, to integrate and to be part of what we internally co-production assessment process. This is a kind of change advisory board where diff people with different expertise meet like architects, cloud security, I-A-M-A-P-I, data privacy office offices. So we meet and we suggest, we guide teams into how to bring their delivery to production properly, consistently and in alignment with our needs or corporate requirements or, or best practices.

And we try to keep this process really also good as, as a good supportive tool for the company, for, for the teams because we, we fill the gaps of ex of, of knowledge or of experience in these particular areas for the team. So we are helpful that we try to be helpful with that. And this is where we also have these IAM reviews and this is where we can detect and also make the exceptions create except trigger the exceptions so we all get better.

So, and by introducing authentication guidelines, it, it was not enough to just create document. Here it is, please follow.

So, and nobody reads it, nobody remembers it. So we wanted to different outcome, therefore we started in fact with trying out our ideas without really strongly enforcing them first. So we lived with it for about a year. We collected feedback, we incorporated feedback into the new versions of, of these like definitions, form of, or wordings so the teams feel comfortable and really like appreciate what we do. And it's, it's a lot about training, raising awareness, guiding teams rather than just posting documents.

So of course you need like the technology in place and also what's important, this strong marriage and friendship with the business and legal, honestly, we are, we are best professionally best friends with legal people. They like us a lot and we like them. So we attend each other's conferences and we support each other. That's a strong marriage, I would say. And and they often, they're also not only tech-minded, they're also business-minded so we can rely upon them. So they're not just restricting, they're really looking for solutions and that, that, that's awesome. Yeah.

And it's all about risks. You need to be realistic and, and and down to earth.

So, and apply common sense, sense very often. And you can try to standardize what is what, what can be standardized. And by doing this, we in fact improve and the uniformity of how we authenticate. We don't overdo and we do at least what's needed with authentication. And we enable together with identity and authorization services, we really enable like a 360 degree view of the customer for the business. So they can create like really outstanding or, or, or amazing experiences for the customers.

That's, that's what we want to do in our business and also to maintain, to rely upon us for compliance. That's it. Thank you very much. Thank you so much. I'm a big admirer of that kind of framework approach. It sounds very comprehensive and collaborative. So I do see a question I put in the app. I don't know about you guys, but does anybody in the room have questions that they wouldn't have put in the app? Yep. Lemme give you this Just about the registration process in one of the slides. Is that always in person?

Because you mentioned something about a registration officer, Sorry, I can't hear you badly. Can you please The registration process, is it always in person Registration for Onboarding, I think, right?

Yeah, it looked like it was a primary Document. In this case.

We, we, we don't do onboarding for the authentication method because we mainly consume the existing methods which are spread across the countries. People are using those for different services in their lives. So our job is to find which method is good or not. And in fact, sometimes teams come and say, oh, in this country we have this so popular method, let's use it for our service guys. Let's check it against the, if, which level of assurance does it land to? That's our job. We land it and we see if it's good or not.

So another question I wanna pose then is, so you're defining all these customized levels of assurance essentially for your business and you have a lot of partners and external IDPs. How was it communicating all those definitions to them and you know, were they receptive and do you have any tips for the others who have similar ecosystems? You know, we, we want to get the real good results. So the good level of trust, if we just throw the standard ISO standard at them, I believe they will just draw and, and and skip it.

So if we make the wording really user and people friendly, we have better chances of explaining what we really want and why we want it. So therefore we believe that like making a copy of, of an adjusted copy of level of assurance definitions helps a lot to achieve the goal, rather to be very like formally like adhering to the standard, right? A carrot rather than a stick perhaps. Well help me thank Mikhail for this presentation. It was very insightful. Thank you very much.