Dimitri Lubenski, Dr. Jan Herrmann: The Role of IAM within Zero Trust Architectures at Siemens

Now, let us quickly go through the agenda of today's presentation. So we'll start around our motivation for that transition toward zero trust, security model, Siemens. Then I will give you understanding why we are doing that. And what does it mean for us then? Yeah. Talking about architecture and talking about the zero trust core metrics is pretty important. So we will get in touch with that, and then you will get the overall zero trust architecture presented. Obviously it'll be at first high level view.

And I hope to see you maybe in one year to talk about completion of that implementation with more and more details around and yeah, you will see also our next steps in our long journey. So that's also pretty interesting. I'm quite sure. So now what is our motivation around zero trust and how we see the current?

How, which currently do we have around that topic? So, first of all, as you probably know, and there is, I guess there are no exceptions, lots of security models currently are around built around network perimeter security. And we are also not an exception here. We have lots of challenges around telework and in case of mergers and acquisitions, we have to understand how to connect those company to our infrastructure.

In, in case of Caral to getting challenging, to extract them out of this particular infrastructure, there are lots of efforts to all the parameters of these networks and configure all this excess lease and all that kind of stuff. So for us, it's very important to move towards the zero trust architecture and to switch between or from the perimeter based security model to the zero trust where we are focused on the verification of the user and user identity topics in general than device, which gets more and more important in that particular story.

And also all the different, additional informations like protection of identity, like threats method around entities and all that kinda stuff. So for us, the vision is to, for Siemens, Siemens implemented zero trust and enabled, secure integrate digital services. But also Siemens has to be seen as a global leader in the zero trustable product. Cause obviously we're also producing equipment and this treatment also contains security pieces. And we would like to be perceived also as a leader in, in that area.

Now, what are the principles which we set as a cornerstones for zero trust architecture, first of all, connecting from a particular network, doesn't determine which service you can access. So network gets more and more managed and other aspects getting more and more important. Then easy access request must be authentic and authorized adopting the least privilege principle, which is pretty obvious and also very important topic for us. Zero trust access policies are compromised of rules for attribute of users, device and Fu user object.

That means we really collect all the parameters, which we are requiring for the authentication in order to make a decision, whether this particular endpoint can be reached through the user with this device and whether we have other information like compromise and to make this decision and give access or not last but not all network traffic shall be ed, which is also important here to assure the network security aspect. And obviously we'll also lock all security, relevant communication, metadata, and inspect relevant network traffic to assure that we can also monitor all that.

And, and in order to transfer this to the tangible architecture will give you possible words to ya who will explain how we gonna structure that, Right? So let's look bit at the technology. So it was right from the beginning, it was clear that it is a interdisciplinary project and we will touch different security control domains. So obviously identity and access management is in its heart of the co trust program. There it's not only about user authentication, managing the users technically or human users.

It's of course also about bringing in to the game, the story of the endpoint authenticating the endpoint. And then obviously before you can authenticate the endpoint, you must manage them somehow reduce enroll certificates. Also of course, the network topic is, is touching the zero trust program a lot, how to optimize the network, how to get rid of the old barriers. Then we have, of course our backend services and the controls in the backend as well, that need to be taken care of.

Then we have these detection aspects like monitoring, having sensors, doing behavioral analytics so that you can, after you detect that something is going wrong directly near real time, react to such known security states and prohibit access or ask cost application. So you see in the end, there's a lot of security controls that come into place, but in it's hard, I would say identity and access management is, is, is the central piece. But of course it needs an ecosystem, right?

The attributes that you need to control or enforce your access policies come from other systems like the endpoint management, like the detection and analytics area. So you need an ecosystem of different parties that play together so that you achieve your, your objectives in the IM realm. And if we now look a bit more into detail, what is the zero trust score? So we had hard discussions management, obviously thought about a thing. It's a score from one to a hundred, makes it easy.

And you would say from 80 upwards, you are not allowed to, you are only allowed then to get access to some system, but in the end to demystify our trust core is a set of attributes with their own value domains. So for identity, for the user or service identities, we have these four aspects, the identity assurance level. So we base this on the list, 863 specifications.

So IL one, two and three, how strong was the identity proving of the user we have, of course, the authentication assurance, how strong did the user authenticate? We have like different types of accounts we consider in our zero trust access policy. We have also the assignment of users to rose groups or scopes that also play an important aspect. So next to the like this already, what if you go, go back again a second next to the identity of the user.

Of course, now we have the new party, the endpoint state we consider. So an device or like a laptop or mobile and on could have states like unknown. It could Beed meaning you can either identify it or authenticated. Basically the identified thing, we have it for our OT aspects because in OT, proper device authentication as of today is not always possible. So this isn't somehow weak, but still intermediate state. We considered in the it realm. It's more about proper authentication based on certificates. You reach the state of register. And the highest level is on, is compliant.

We're compliant. And we have dedicated attributes stating the degree of compliant, according to some device management policies as depicted here, right, is disc encrypted is viable.

On end on, on the right side, you see further two domains of attributes that talk about the, the detection aspects. So is the account compromised? Was the suspicious sign activity by that account or does our defense center know about suspicious activity by that user? Or is he involved in an incident and therefore sets a corresponding value to this user con compromise drum and similarly for the endpoints, right? We have then things like is the IP address, the, of the machine part of a botnet, is it known to be malicious?

Are there strange geolocation hopes, all these things then come into place and all that together makes up our trust core. And it is in the end used by the zero trust access policies reinforce to ground access to services or not. And now on the next slide, which is, of course, if you could switch to the next one there it's in the short time, we have, it's hard to go through all the aspects of just catch the most important aspects. So in the middle, you see an it end point and the user wants to intake act with some backend services using his browser or certain apps to do so when he hits.

So there are two cases, the one is the application is directly integrated with the IDP. So it's a modern application. It has support for modern authentication mechanisms and protocols like Sam, or also really connect it's directly integrated. So when this user tries to hit the backend service, it gets redirected. You do your authentication. And now the new thing is you not only do the user authentication, but you also do the endpoint authentication in the same authentication event then before. And you see our, the trust policy enforcement for this year is integrated behind the IDP though.

That means the P P enforcement points starting the access control process. Ask the question, shall I issue an some assertion or an access token given the current situation. And then the zero trust policy gets enforced. So you are then maybe allowed to access a service if your device is authenticated, if your device is compliant, not compromised. The user authenticated with MFA, according to a L three and so on. So the such conditions are enforced per service, and then you get the token. And with this token, you would then be able to access the corresponding service.

We'll see in the, in the next step slides. And at the end that it will be extended this approach by decentral authorization systems, right in front of the service to enhance and allow for action based and more fine grant access policy enforcement. But for this fiscal year, this is a starting point where we focus on. So I said at the beginning, this is case one where you have applications that are capable of being internet or zero trust, ready, meaning they are hardened enough to be internet facing and have IM support.

Of course, there is a set of applications that are not in that state. They were part of the internet and not meant to be published outside. And I have not adequate IM support. So to address these type of services in end, we have in the interim way of tackling this, and this is what the screen box gateway or software defined networking service is about. So think about, for example, set scale, private access, right, a tunneling system, doing some connectivity service. And so we add our, your trust policy enforcement to the Slayer.

So the, the tunnels you establish from the end point to the service edge and from the service edge, choose the service are the routing through these tunnels is only granted. If the zero trust policy is met as defined by the corresponding service owner. So this is maybe same thing also to highlight that the zero trust policies will be configured by the service owners in the service service manner to allow for scalability and flexibility. Good.

So I, now we went through the middle part in the end on the right, I guess it's clear that the attributes that need to be fetched to enforce such policies on device state and device compliance. So they will be pulled from the endpoint management services on the right. So we have a bunch, they are federated. Also we have cases where we have partners and so we can integrate their compliance information in our process. And below we see them, we have our detection services from the defense insert center that are leveraged to grant intelligent authorization decisions, OT.

I would skip for now to go into more detail in the end, the OT is D special. There's different types of endpoints and different protocols. One thing to notice maybe that we have endpoint edges in this year as a first step to introduce your trust there. And they are the end point of where the zero trust communication ends or starts, and they are security enabled. And then you get forwarded to the less security capable endpoint in the factories. So now when we look at last slide, what will come next?

Basically we try to get rid of this software defined networking solution, like set PAAC scaler, right? Because this is somehow a hard liner for zero trust might say, no, this is still somehow relying on the network. Maybe not the physically, but the virtual one.

So yes, it is a compromise. Yes, it enables micro segmentation. It enforce zero trust policies, but still you have a parameter also virtual one. So we wanna eliminate this and have most applications really being natively enabled. And is your trust enabled meaning integrated with our central IDPs? The other thing is, of course, for the OT components, the newest ones already start incorporating security, but there's a longer journey to make sure that all products understand security and understand and comply to zero trust principles.

Another thing we haven't tackled yet is the east west topic like beyond product. So our microservice architectures brings zero trust principles into these runs. When services communicate with other services or APIs, fine grant authorization. I manage mentioned this before, right? To enforce your trust policies per transaction on an action and more fine grant services is another billing block to add.

And instead of pulling these attributes from our sources like device management and defense, the idea is to make this more interactive, have centralized security knowledge basis, and a more continuous tokenized zero trust model to have really fresh data in a reliable fashion. And by this, I would close this short rush through the architectural aspects of our co trust architecture. And I guess we have a minute or so left for, for questions. So we're happy to answer if there are any.