So, welcome and I'm very happy that I can talk to you right now about a really important subject, Cyber Resilience for IDM or Identity and Access Management. I'll show you some practical approach.
Okay, we'll start right now. First introduction, my name is Eleni Richter. I've got a degree as Wirtschaftsingenieur, a degree in engineering from University of Karlsruhe and you can see I look like the typical German engineer. And I'm more than 20 years around in different positions at EnBW as IT Security Manager, IT Consultant, System Designer, Project Manager and IT Architect. And right now I'm Chief Architect of the Identity and Organizational Data Management System at EnBW and I'm also lecturer for IAM and Cyber Security Architecture at Luzern University of Applied Science and Arts.
And what I brought with me is, because I'm an engineer and architect and we love to draw, so I brought you my sketchbook with some drawings on the subject. This time it's Cyber Resilience. Cyber Resilience, I'll introduce it as a new approach to reduce dependencies and complexity for IAM. We'll look at some motivation and practical definitions of Cyber Resilience, take a look at costs and benefits, some actors and use cases.
Of course, we take a look at zero trust and Cyber Resilience and finally some useful building blocks, which you might want to take home and think about. Important note, all models are based on well-known practice and general knowledge and all examples are completely fictional.
Well, moving into the cloud, who is not moving into the cloud, raised the expectations to finally leave the on-premises silos and all their problems behind. So, what's happening?
First, we'll start with a little quiz. Can you spot the differences between those two pictures? On the left side, we got those legacy silos and on the right side, well, we got those cloud silos, which means moving into the cloud didn't change so much in my experience.
Well, and if we go further on, identity management, the ideal, perfect landscape, it's the joiner-mover-leaver process. So, we got a data source like an HR system or it could be in the B2C context, a shop system or a customer relationship management system.
There, we transport the data into the IAM system and then you make it ready for the business to consume. That's the perfect process.
And now, we got reality means, we got hybrid scenarios, we got vendor lock-in situations, we got heavy centralized dependencies on cloud services and we move those problems to the next level, which means reality usually looks like this. You started somewhere with your central active directory, then you got an entry because you had to move to the cloud and then it didn't work for everything.
So, you got your CMs, you got something for the B2B subject and there's a business case which needs something else and everything is depending on everything. Okay. And I put it in a little more abstract way. We got a network of multi-dependencies, we got a heavily distributed system. It is an open system because we got internet, we got data sources which are out of our control and we got the usage and consumption. On the other side, we either can't control completely and nevertheless, we got the time factor. Those things are changing and it's an open system.
Maybe the changes are outside, you can't control them. Your HR system is moving into the cloud and you got to adapt your IDM system. And of course, we got, since we're in a modern world, we got AI, we got more complex systems which have nice reaction possibilities, which have very nice security possibilities, but which means those systems are adapting. This takes us to the lesson, modern identity and access management is complex.
Complex, inhomogeneous, multi-part system, distributed system, partly out of control. Sounds like horror. And the next thing is, complexity cannot be solved by simple patterns like high availability, transactions or centralization. It just doesn't work.
So, resilience is a suitable pattern to cope with that. So, we'll take a look at that. Resilience, short definition, the ability of a system to react to stress and restore its function.
So, that means, accept that things go wrong. Let's say, an example, one of your data sources messes up with the SCIM and delivers wrong data and you've got a mess in your IDM system. Accept that you cannot control everything. SAS via Internet is not controllable. You can have an SLA, but you can't have an SLA with the Internet. Unforeseen things will happen. Let's say the new HR system is in the cloud. You can't foresee it and the HR department is doing what they want.
Now, you've got to see where you stay with your IDM system. There will be unavoidable stress, changes driven by your cloud provider. Microsoft keeps changing things in EntroID.
I mean, you could call them and tell them that they should stay, but they won't. In a complex environment, these things are normal. They just happen. You can't prevent them.
So, we got external sources of stress and intrinsic sources of stress within the system. And the reasons for stress are uninspected, unintended, incorrect, error, malfunctions, or malicious interaction. Everything which is in color red is some sort of stress which can happen. A highly resilient system, that means a system that has the ability to react to heavy stress and to different sorts of stress in a way that time and effort needed to restore its function are minimal. That would be nice if you could achieve this for an identity and access management system.
So, costs and benefits of cyber resilience. I'll start with the costs. Resilience. If you build a resilient system, it's difficult to handle because you will have non-deterministic parts inside and a complex behavior by itself. In general, it will be slower in the reaction time, but it is more sturdy. It's difficult to understand because its behavior is very unusual.
And, well, we've got to face it, there's poor support by prefected tools, and it's really difficult to find tools, especially in the IDM field. And that means you will have to have investment in implementing resilience requirements. But there are some benefits.
Well, if we take a look at the timeline here, which I put on the bottom, and we've got a system which has a function, in our case it's an IDM system. And down there, if you have absolutely no function, now this one has no function. If you have no function, that's on the bottom line, and if we are up there, we have full function. And I put in a point of stress. Okay. A less resilient system has a recovery phase which looks like this.
So the system is completely functioning, functioning, functioning, and then something bad happens, and it breaks down, and you have no function at all, and then you are heavily restoring the system, looking for your backups, it's hectic, and you've got a lot of stress, and then you're up again, and the system is functioning. That's the typical behavior of a not-so-resilient system. If we have a more resilient system, things will look like this. So the system is working, and then something really bad happens, and it just makes an oop, and then it's up again, and it will block again.
That's very nice. That's what we like to achieve. So this part, this rectangle, is showing the recovery phase.
Of course, it is shorter if you have a more resilient system. And good resilience enables you automation. An autonomously running system is possible. You can build an automatically recovery as possible. You've got more reliability, react to many types of stress, stress has less impact, and needs less time to recover, and it copes with complexity. It works in real-world scenarios, in heavy world scenarios, and in distributed open scenarios. And you've got more degrees of freedom. There's less time pressure, especially when it's up to repairing something, and there's less design pressure.
So understanding resilience in identity access management. We have a resilient system down here, shown, and things happen. We got a data delivery failure, maybe a deployment of a new core, some abnormal data distribution, wrong data update, any unforeseen change somewhere in the cloud or whatever, and the resilient system, it will take a little functional breakdown, but it will somehow manage to work, or to work around, or to adapt to this situation. So that is unusual behavior, and it's sometimes heavy for the people to understand.
If you have ops, the operating, the administrator stuff, well, they see errors and failures in the system, it's a non-deterministic behavior. We got adaptive parts, it's distributed, and well, they think, oh, shouldn't we do something about that?
Usually, all these peaks which go down, all these minimums, they are catastrophes for them, but no, stay calm, it's a self-healing system, so operating is much less stress. We have no operative time to pressure, we have time to analyze.
From a developer's perspective, well, the developer will face a lot of incomprehensible, or in his mind of view, point of view, unnecessary requirements, very strange things he has to implement that might give him some question marks, but he's quite happy, because if he understands, that makes sense, because we'll create a system which is stressless and more flexible, and that makes it much easier to develop. If you want to change one part, you can just take it out and exchange it by another part, because downtimes do not matter that much.
Well, the auditors, they have to face some unusual compliance measures. Maybe they're missing some infrastructure measures, but they have to be convinced that a different way of achieving compliance is also possible. And management, of course, business person, well, they're questioning, we do not have high availability.
No, we do not have, but that doesn't matter. That means standard KPAs might not work, but we've got to focus on business.
So, from zero trust to cyber resilience, we all know zero trust, which I put in a very short way, never trust, always verify. It is originally used in cyber security. It means never trust a single security measure, like a fireball or a perimeter security, or something like that. Always verify every access in an explicit way.
Okay, why not apply zero trust principle to an identity and access management system? I mean, we've got our very simple join and move a leafer process, and we put a zero trust principle to the integrity of an IAM system. Never trust a single functionality, always verify every subsystem functionality in an explicit way.
So, that means in every part of this process, we can have points where things go wrong, and we should not only check in the very beginning at the input, and maybe we'll check at the output. No, our data is going through a system, and it will reach several steps, and we should control each step we're going through.
So, we have a lot of checkpoints. We should put zero trust on the integrity of IAM data. Whenever processing IAM data, check any input and any output on every subsystem you have. Not only once when data is entering your IAM system, but every step in each subsystem. You can also put it up to algorithms. Maybe you've got algorithms which do calculate some compliance aspects, which do calculation of roles or whatever. Are the algorithms working as expected? Never trust a single algorithm. Always verify in the local context of the next step you're processing. Zero trust process integrity.
Are the processes and each subprocess working as expected? Never trust a subprocess. Always verify. Effect? The greatest possible mistrust in your own identity and access management system.
So, you don't like it anymore. Okay, that's somehow strange.
I mean, usually we like our systems, and we have trust in them because we built them. No, we have absolute distrust. You don't like it.
So, and you got many checkpoints inside the identity and access management system that went at the border of the system. Use these checkpoints as trigger to create reactions. Build the ability to react to stress and restore the affected function, which might be inside the system. And if you have this, you have resilience because resilience is the ability of a system to react to stress and restore its function.
So, if we take a look at the data management part, identity and access management is a data-driven business. Resilient process for data management. That could look like this. We got our resilient system, and I put some principles up here, which might help you to get an idea how to build a resilient system. Distributed redundancies. Any part of the system may fail. Each subsystem should have its own set of data to work with, which means if one part of the subsystem fails, the others can still work because they have their own data to work on. Last known good.
Data in a subsystem stays valid until it's replaced by fresher data. So, if you've got a problem in the supply of fresh data, you still have the old data from yesterday to work on.
See, reconsolidation. Data in a subsystem may be corrupted. A regular should-is adjustment should be in place, so anything which goes wrong will be automatically repaired. Thresholds and plausibility checks. Reject any data which is not plausible for the given business context. AI can give us a lot of potential here in this case. And the KISS principle. I think it was in one of the keynotes. Keep it simple. Keep it small and simple. Build system out of small and simple subsystems, which you can easily control. And F and G.
Reduce dependencies with a suitable system design and lose coupling regarding business context, not only infrastructure. Those two points were a main subject of my last year's talk, so maybe you take this PowerPoint out and take again a look at it. And I'm happy to discuss some of these ideas with you. I can't go into a deep dive, but we'll take a resilience from the IDP part, which I also like very much. This management part was mainly about the data. Now we go for the IDP part, identity.
We got a central, usually a central identity provider, single sign-on, and it grants access to the application, maybe even some role management and access inside the application. Okay, well known. The underlying data from a resilient management.
Okay, maybe we've got it. We've got our identity and access management processes, which are really resilient, and we put this data into the IDP so the application can use it.
Well, let's look at some anti-patterns. Anti-patterns are things, really bad ideas you shouldn't do. Anti-pattern number one, single point of failure. All applications depend on one IDP. Who has two IDPs?
I mean, we usually have one. It's the idea about single sign-on.
Okay, but that's what we are doing. We're all centralizing it into one IDP. Next anti-pattern.
Well, as a reaction, since this single point of failure is very important, why not put a next IDP, next make a cluster, and a high availability solution. That's a very traditional solution.
Okay, it reduces at this point the probability of an infrastructure failure, but nothing else. If the data is messed up, the data is messed up. The cluster won't help you, and we still have this poor meantime for recovery.
So, let's think about something else. Ah, the modern version of the traditional HR cluster. The more modern version looks like this. Can you spot the difference? We got a cloud IDP, and it's kind of an HR cluster plus internet.
Well, it changes something, because in this case, at this point where things go wrong, it's not the fault of the IT department. If you go into the cloud, it's the cloud provider's fault. That's success. But in fact, if you have a problem, it won't be the cloud provider's fault.
Well, it's the internet's fault. You can try to sue the internet. Everyone has an SLA with the internet.
Okay, it doesn't look very good. And so, cloud redundancy, if you have multiple clouds, well, monoculture is prone to errors. That's also right for IT, and usually you have a very tight coupling regarding the data inside the IDP.
So, there should be something else. So, we'll take a look at how could it be if we would have, I would dream of a really resilient IDP landscape.
Well, some ideas here get a resilient mesh out of loosely coupled distributed heterogeneous identity providers. Of course, combined through a highly resilient IAM system, which means your application, think about if they are capable of multi-IDP connectivity. Maybe you want to use a different provider and you want to stay only with one provider, use various technologies.
And for really critical infrastructure, since I'm working at an energy supplier, we have a lot of critical infrastructure, you should consider having small self-sufficient IDPs for really critical applications, which can work in a case in a really bad incident, which can work in a kind of island mode. So, patterns for IDPs, distributed redundancy, that one is easy because the functionality of the standard protocols and IDPs, that works quite good. Last known good, easy, standard functionality of an IDP and an IDP is able to have persistent data and to cache it and to work on it.
C for reconsolidation, that's the job for the IAM system. And thresholds and plausibility checks, depending on abilities of IDP and IAM from possible up to impossible up to standard.
KISS, again, keep it small and simple. This is really a heavy one. There is a real risk of overloading the IDP with other functionality. Since zero trust is pushing into the landscape on the architectures, we tend to use the IDP for everything. It's the general firewall, it's the security measurement, we put the intrusion detection and the intrusion prevention system, we put the control for our devices. Everything is going inside the IDP, so there's a real danger in overloading it.
And we'll, of course, reduce dependence in loose coupling. That is depending on selected technology and topology. And avoid monoculture.
Well, that is up to you, but costs might be a problem. If you've got one cost-intensive IDP, which is nice and working, will you buy another one from another vendor? Will you get one from open source, freeware?
Okay, but then you've got an operating task. Okay, summary. Resilience is more than just high availability. It's a concept to cope with complexity. And it's an essential part of good architecture. It's a benefit for business because it enables system design in complex distributed environments.
And, well, the introduced practical approach might give you an idea what you could do in your IAM landscape to reduce complexity and to reduce dependencies. The patterns, of course, are simplified. They will need some adaption to your company's situation.
So, are there any questions? Do we have still time? A little bit. Three minutes, I think.
Well, thank you very much, Eleni. I really like this sketchbook style. So many ideas on a single slide. So many takeaways.
So, if the audience got any questions, you will get the microphone. Hi. Thank you for the words. I think it's overall very hard to disagree with all all your ideas, but they might be a bit idealistic.
So, how would you go about having that remark from me? Yes, yes.
Very nice, yeah. Well, we had the answer. We built our own identity and access management system and it complies with the things I've been showing. Here are a lot of vendors around.
I would, well, tell the vendors, take a look at it. It's possible. Maybe you want to rethink your own IAM system and you want to place things in it.
And, of course, start simple. For example, having different IDPs as a backup is not so complex. That is something which is easy to achieve. And then you've got to sort out what is really critical, what is less critical, and what is nice to have and take a look at the really critical systems you have and think about how much resilience can be afforded, how much resilience do we want. But it is a kind of, you've got to, it works better if you start it from the beginning.
If you have an already built system, a monolithic classical silo in a classical cluster or whatever, it might, you might find it really hard to reshape it so it will be resilient. So, maybe you want to take out some aspects which are really important for you and redesign those aspects. Can I follow up? Just to follow up.
So, you don't have any internet provided services? No. That you are not in control of?
No, but I'm around here in the next two days. So, if you'd like to talk to me, you're welcome.
Well, thank you very much again.
