Can you introduce Dr. Ya Hamman and Demetri. Lubinsky from Siemens for the next presentation. Welcome.
So welcome everybody to this presentation on our Siemens zero trust program. My name is Dan Hamman. I'm leading together with DRI the architecture work stream. I'm part of an, I am expert group as obviously I am, as we've seen as second is one of the central Porwal pieces of, of such a co trust program. And Dmitry is head of technology and innovation in it. Strategy area. Good. So what will we talk about in the upcoming minutes? And we'll start very briefly as a lot of people continue to repeat what, what the zero trust story motivates. So just briefly touched this or motivation why we have that program, then explain what co trust means for us, because it turns out it's not that clear or people have very different viewpoints on what it is. So make that clear. Then we look at what our co trust core is about.
Walk briefly through the architecture we have today and plan to come live in the upcoming years and, and to close lend with this journey overview. And we we'll do this together and share a bit and walk you through the slides. Good to start with. I said, very briefly, we once had this pyramid. We have the intranet and the outside world. Now we have people working from home, not only due to Corona, but that haven't before we have a lot of clarification. So things that were operated in our data centers get got moved to the cloud to all clouds, probably that exist are very popular. We have a lot of mergers acquisitions, a lot of external partners that spontaneously, or for short period of time collaborate with us. So this needs to be supported. And so obviously all these changes, we said, no, we need a more flexible approach.
And that's why we jump to the zero trust security model. And then it's very hard. What does it mean? It is you not only authenticate the user by the factors that are well known? No, you also authenticate its device and you leverage additional information you have on that user, on that device. Compliance states com compromised states of the account of the device before you grant access to an application. And target obviously is every access with a resource, with a service with data needs to pass the zero trust access policies, good asset before, right? The zero trust Parum, we've defined a couple of principles that lead. And then this term zero trust architecture, it's a special kind of security architecture that orchestrates different security controls to achieve good security and identity and access management of human users. Technically users of the devices of things is in its heart.
Then you authenticate these things, you authorized them. So obviously I am is the centerpiece, but as said, you need endpoint protection management systems, right? Like in tune so that you know, which state this device, you also need to reorganize your network to allow access from everywhere. Every time to your services, wherever the people are backend security. There's something to think about. Especially in service mesh areas, we need to monitor intensively, the traffic to get behavior analytics and, and threat intelligence in a position to be, to have secure, valid information on suspicious activities going on. And so all this needs to come together to reach that zero trust, security architecture, and obviously in a large company, this is not easy to achieve because it's a highly cooperative project that you need to spin up and you need the commitment of all of these teams, the trust core at the beginning management and vision.
This is a integer from one to 100, and this is it. We worked out that this is too simplifying and not what we need. So we have a set of attributes that form, that trust core, and in for identities, we have the identity assurance level. So this is based on the N 860 C stuff. So identity proving, how good was the identity proving when the person got enrolled onboarded at Siemens, we have the authenticator assurance level. So this is saying, how strong did you authenticate or good were your authenticators? Was it just a user and password? Was it a UBI key? Was it like a smart cart and the pin biometrics and so on? So this is expressed by this authenticator assurance level authenticator type role in group assignments are minor categories, but also define how much trust is put into some actor. We have the endpoint state, which can be either completely unknown, never saw, never uses device before you can register your device.
That starts adding an identity to that device. You can authenticate with that certificate mainly sorry. And last highest endpoint status is compliant, which is composed is a aggregated value based on the attributes you see sketch below, what is the operating system up to date is the virus can on your firewall, well configured and all such things. Drive the compliance state next to these most static things. We have these user account compromise. So this is as a set before if our defense group or other threat intelligence providers tell us our young user account is showing up in botnets and, and, and showing different different applications, suspicious behavior. Of course you get flagged, and this is incorporated in your zero trust access policies. And similarly for the endpoint, right? When you have an IP address from the tone network or your IP address in the morning at eight was in Russia. And at nine, it is in China. Doesn't look too good. So then there are metrics that resulted in a certain leather regarding this compromised value endpoint compromised value. And that is leveraged in the access policies to grant access to a service with a certain criticality. Good. And so
Over
To you for a few
Sets. So now taking over to the practical side of the world. So, so far, so just how the model around zero trust looks like. That means how your authentication should be looking like and all other aspects around. But now let's take a look on the practical side of the implementation and how we are going to apply that in our zero threat journey. So, first of all, looking at that picture, you will see how most of the companies will start a zero trust journey. So you have maybe one or multiple identity providers. They are centrally available in the company. They are capable to enforce multifactor authentication and do lots of adaptive stuff. So depending on where you are coming from, which data is available, you can sometimes offer multifactor authentication. Sometimes you will, will not do it because of other things, but the main messages, you have a single sign on system, which is offered within the organization.
And that's your starting point. And there is where we also starting here with the wave zero. That means we have that capabilities and we would like to move them to the next stage towards zero trust. Now, looking at that at the next step, what we are going to introduce, first of all, we will start with introduction of the device data during valve indication process. That means first thing is we would like to use the signals out of devices and device information in order to apply that information during valve indication process. And that is one of the main challenging topics. So whenever you're talking to different vendors available here on the stage, you're also selling different products. You will see that there are lots of limitation in this area, which causes us to work around to, to introduce new and specific solutions, to close the gaps in that area.
And as a topic which we are going to achieve here is including detection, data and detection attributes. That means if we have an information that something is compromised, an identity to a device, we would like to be able to apply that information during self indication, to prohibit access or the change, the way how the user will authenticate. Again, in that area, there are lots of different products available. And sometimes the transparency is pretty challenging to understand whether they are of benefits or not. But clear statement here that we have to move to, to reach a zero trust goal. We have to move to that direction and use this information during the authentication process to increase the security of the system, as well as introduces zero trust capabilities. Now, looking at that pictures very important also to include the capabilities of zero trust based network access.
It means whenever a user is establishing a connection to one or another beacon system or establishing the network connection to a resource, it is also important to include zero trust capabilities as well in that, in that access. That means for establishing the connection, you have to enforce the device and user identity posture. And before establishing that connection check, also that information, additionally, last but not least in many companies, there are OT networks like production networks or R and D networks, which are also required to be accessible. And there should be accessible also in the zero trust fashion. That means even there, you have to enforce and check all the attributes which we manage here mentioned here. And there is exactly the point here that in the next stage of our journey, we will enable that access to run on the zero trust level and will also include the capabilities to achieve that one.
Good. So this is what we ended up in wave one. So now the next step was, as you saw, maybe before we had zero trust and enabled IDPs and zero trust enabled connectivity service. So obviously every service being behind such an IDP or being federated with such an IDP, so I'm relying party or, or IDC relying party did get enforced the zero trust policy at the time the token was issued, but then subsequent access. So the granularity was on that service level. Okay. But not perfect. What we aim for is to do the transactional. So every action you might wanna differentiate, let's say a read might be okay with an unmanaged device, but if it does a delete or an update, you wanna see a managed device or compliant device, for example. And so, so this just zero trust enabled ID piecing was not sufficient.
And also this C scale connectivity tunnel, allowing the traffic to flow through if the zero trust policy. So it's a service edge doing IM and then forcing the zero trust policy, basically. So also this does not help to enforce this action or resource level dependent authorization. So you see now this micro parameter, obviously you need an application that can handle such a micro parameter. So this is more for self-built service measures up with APIs, web apps also, where you would then simply add this micro parameters, think about a side car where you have a, a cone, some, some micro parameter, and then APA some authorization system next to it that enforces as your trust policy per request based, but still based on the signals on user identities or endpoint identities on from threat detection. So this is one extension that's happening there. Similarly, we are not in the first year we focused on the user devices like Linox I Android iOS and Mac and touch things.
And obviously we have a lot of applications. You also pointed this out in, in service to service communication scenarios or machine to machine communication scenarios. As you have it often in, in industrial IOT, this is a bit changing, of course, the high level story, same. You wanna authenticate your application now being the actor, not the target. So this means the application needs that identity, but you use different identity systems normally, and this is more dynamic. You also might have different credentials. So, and also the agents to detect if the machine is compliant or not compromised, there's different software you use for this. So this is therefore happening in the second wave. And also when we look at the OT endpoint, of course, getting security into the OT world is time consuming. So we have this approach that we have endpoint edge OT endpoint, edges as the parameter in front of this component, handling the security.
So this, this gets your trust enabled. Meaning can be a target of communication from outside, can be the target starting point of a communication to the outside. So very similar to our applications on the left, they are just a special type of application. I would say further regarding the identities, as said at the beginning, we have this identity proving our identity assurance level as one dimension of our trust score. This is also thing that got is handled in wave two, as this takes more time to at a global scale, get sound identity, proving happening in a more heterogeneous dynamic company. Good. So these are the central things. Note, maybe that before in the wave one, we had PDPs like the policy engines and forcing the zero task policies behind the IDPs behind air connectivity service for Northstar connectivity. Now we have it per application because these are decentral PDPs PDP living in the next to the micro parameters.
So this topic of policy management becomes even more important to handle it well centrally. So there's one central policy management service, and that gets these policies get distributed down to conditional access, the ping pong door, or the Opus running in the microservice stack and not easy, but this is important so that you have central control. Also, you decentrally enforce the policies. And what's also important is that this is not about only central management of the policies. You also need to handle your, your trust cause centrally and push down the context information to these decent ones, because it would not be performed enough to go to from China to Frankfurt, to ask for a user's identity proving level. Also this is to handled and then the next wave. So we have a lot of relations between signal, producers and consumers. So to simplify this, giving the growing number of, of parties in that zero trust architecture, there is this upcoming probably you all heard about this Cape initiative, synchron signaling between producers and consumers of these things. So we hope that the support by vendors grow in that standardized direction, consuming tokenized attributes of detection, engines, or IDPs, or whoever is, is producing things so that we can consume this. And we also aim to harmonize our still distributed knowledge basis on let's say, device compromise states of the various CDCs we have. And so on into a more central higher available graph type of central repository.
Exactly. And just looking at the architectural picture, that's a pretty long time journey, which we have to pass. And while having that journey already in place, we have some lessons learned and something which we would like to pass to you if you are starting the zero trust program and would like to have some takeaways, which we, we had since our journey. So first of all, which is very, very important in that regard is that zero trust is not implemented within one year or two months. That some, there are some managers we would like to maybe transfer some money to a vendor, and that is done. It is not done. It's very long time journey where it's very important to include all the possible experts from identity provider, from device management, from network, from defense application development, service owners and so on. And you have to prepare the whole organization.
You have to assure that everyone works together, understand your model of the zero. Trust means what you selected to be your ultimate goal, to implement that in your zero trust journey and all the people have to work on that particular topic in order to solve that for their organization. And another thing which is important I guess, is to establish a common standard in the company and understanding what data trust means. And I, and we can recommend to take needs as a foundation for you just to say, there is exactly what we understand on the zero trust and main topics, which are important here is authentication assurance level. How you define that in your organization, identity assurance level, how you clean your identity, waters, guest, identity, waters, whatever you have to define that in the scope of your organization, and really build the solutions around of that one and device, state device status.
Also a very important topic to be included in that concept. And you have to understand how you will address that in your organization. Now, having that said, yeah, lessons learned moving forward, what we learned from that particular journey and what could be useful for you as well. First of all, if you are talking to vendors, you have to understand that all the products they're trying to sell zero trust, but they are covering some aspects of it. There is no product which covers everything and you can just deploy it and you are zero trust ready. So that means applying that products. You have to figure out how you address important things for your organization. Like if you have to solve application onboarding, if you have lots of applications, which have to be onboarded in that environment, you have to sync through how you're gonna apply user self services and or application all self services to bring application into that environment.
How you're gonna handle device compliance and device state in that area. Do we want to manage the devices? Do we want to apply other tools to assure that during the authentication, you, you have all the information required for making a decision, whether the, the device is illegal to reach a destination or not very important to double check the support for needs attributes like identity assurance level or other topics, authentication assurance level, whether it's covered in the product and can be exposed to applications. So applications can process this data then transparency in the threat intelligence. So just walking through the stage here, seeing lots of vendors, offering threat intelligence capabilities to check the behavior of the user impossible travels and all that kind of stuff. There are also AI models built around that. So the products can evaluate lots of possible metrics and make the decision.
However, it's very hard to understand how many false positives are in that decisions, how efficient that products are and what end of the day that will bring to your security. So you have to check that and try to figure out whether that brings lots of benefits and whether you understand the model, which is applied for that particular solution. And last but not least, we were talking here already about bring your own devices and all possible models, models with bring your own identity, bring your own devices, combination of those, and also including our inviting the guest and that particularly challenging aspects, because we see that in lots of solutions, especially that one is not addressed the way that we can say there is fully zero trust ready. So we require some years ahead to address this to the way that is really compliant to the zero trust in the term, how we see that and heaven that said be prepared to build workarounds, to introduce special solutions, which will close the gaps in that journey till all the products will really deliver what we expect to be here, to be MIS compliant and to be fully zero trust rating.
And that's it from our site.
