Now you can see it. Thanks for joining. We have a little bit of what we did in Zero-Trust, also more data-centric, what we did there, and we'll show you a little bit. I only make the starting ones, so what we do there, and also to show you my colleagues. I have with me, with my team, Zinni and Carsten, which are product managers in our security team, working in security compliance. I'm working in the IT governance department with the colleagues responsible in Deutsche Telekom for the internal IT and to take care of the governance within the IT.
That's some kind of the setting and the framework where we are working, what you can see, and don't want to go through all figures. I think most of you know the Deutsche Telekom group, but I think interesting is in which environment we are working. What you see on the bottom line is we are working in mostly all cloud environments, so our own one, but also the standard clouds with own lending zones where we have to work on.
You see there around about 800 applications where we are dealing with our internal IT, nearly 9,000 employees all over the world, and that's one of the main challenges we want to solve here and want to find a solution also for you. That's the idea behind, so only bringing the targets there, so that's only the three main pillars of our vision of our department for the data strategy to see. We have to fulfill compliance, that's clear. We have all the local regulations, we have GDPR, what all have. We have also some specialties as old public provider, like for example civil servant data.
We have also some older public customers, so classified data, some local contracts, all this data we have to protect and we want to do it without any world-based concept, so coming to the ABBA concept, what my colleagues will show you. But we also have, we are global acting today, so we are acting all over the world and we don't want to have this big world topic for all the systems.
That's why I'm working there and say, okay, we have a new concept where we can work in one system with all the colleagues without doing anything and only fulfilling all the data requirements in one system, what you will see later. And last but not least, we want to simplify it and make it easy, get rid of to have 100k worlds to work with, only have an easy policy design and work with that for all the systems. And that's what the colleagues will show you now, what is our portfolio and how we deal with it. And for that, I hand over to Carsten.
Oh, that was quick. Thank you. Hello everyone, please let me start with an overview about our SAP security landscape. Here we are dealing mainly with four applications. We will have in this session today a deeper insight into the data guard solution powered by NextLabs. The second pillar is our monitoring solution based on security, which here we are talking about, especially event monitoring, if there is suspicious activity in the application so that we are aware about it.
But not only that, also to check the configuration, if the parameters are set in a proper way, fulfilling the requirements has also the right value. And patch management, also one important topic so that we know that the required security fixes are installed and there is no weakness in our systems. GSC for sure, or role shop, where for iPrinciple, by ordering role is given. And a lot of other funny stuff, for sure, firefighter process, also recertification, SOD rule set implemented.
And last but not least, the T-Secure, our in-house development when we are talking about logging into our SAP application via SAP GUI. Here we have a connector to our intra-ID for authentication so that it is not only possible to log in by two-factor authentication with our internal smart card, but also the possibility to use MS Authenticator. And then let us have a look on how we are dealing with protection of the sensitive data.
You know, there are a lot of requirements we have to fulfill, as an example, with the civil servants or in German, Beamtendaten. Here we have the requirement that only German eyes have a look on it and no one else is allowed to see this sensitive data. In that case, role or having only a role is not sufficient. It is not granular enough, so we need to have additional functionality. We made the experience that this UI masking is maybe also not the best solution, especially if every application has to find a way how to deal with it.
Here, it is not secure enough. It is very easy to bypass the masking on the presentation layer and also by filtering out specific data. Application for application has to find a way. That is very, very complex and also, in that case, very expensive. And we have to find a better way. And for that purpose, we are not only dealing with role-based access control, but in addition also to work with attributes of the user to set the proper rights.
For sure, we will never get rid of roles. We will always have roles, but in addition and more and more to work with the attributes. In the example with the civil servants, here we can use the country code of each user and only if the value is DE for the German user, then they are allowed to see also our civil servants data in the systems. Instead of having really additional roles for every country, let's have one role and use the existing attributes which are delivered by our HR systems. And with that short course, please, Zinig, tell us a little bit more about the DataGuard solution. Sure.
Thank you. Thank you, Carsten, for setting the frame.
Yeah, let's move on a little bit. So, now it's becoming a little bit more technical. I will try to explain to you how we tackled and solved the issues and the challenges we had based on a zero-trust solution. But let me start here with a high-level architectural picture, and it's really high level.
So, on the top, you see the presentation layer where typically data requests are being produced by business users using the application UI, but you can also have IT users also using any application UI or also accessing directly the database by some database tools. All this is summarized here on this picture at the top layer. And then on the next layer in the middle, this is what we call the decoupled data shield. This is actually what our solution is about to protect, based on zero-trust policies, which I will explain later on, a certain data.
So, in the middle, the so-called data access enforcers are sitting on each application where we are already live with this solution. And also, the central so-called policy platform is located here in the middle layer, which, at the end, intercepts every data request produced by the users and applies dynamically ABAC-based enforcement if needed. And at the bottom, you see summarized the database or backend layer. This is actually then where the data requests are getting enforced before they are getting executed on the database.
And that's why bypassing in this solution is not possible and the data protection is ensured consistently on all layers. So, to understand that a little bit better, we will dig a bit deeper into this materia. On the next slide, I will try to explain a little bit the flow of ABAC, so how that really works, and what is really crucial and essential to understand the principle and the concept behind it.
So, on the left-hand side, you can see a user interacting with any UI. And what then comes into place is the central platform, the dynamic policy engine, which, at the end, grabs this request and it does evaluation of the data request.
And here, two main dimensions play a crucial role, which you need to tackle and to manage beforehand before even thinking about introducing zero-trust based solutions. So, the one dimension is, of course, the user or identity context.
So, here, we do not rely on the roles and authorizations from the application. Here, we derive real-time individual user attributes, which are stored in a central identity source.
So, this is one thing. So, here, we derive different attributes like described nationality, function, department. It can be any, but they need to be, of course, managed properly.
So, this is, of course, crucial. And then, the data context.
So, in the so-called technical data protection policies, I will explain on the next slide a little bit better, you have to define the data you want to protect. So, this is the second dimension you need to manage before, again, introducing such a solution. You need to know your data, you need to know the regulations, and you need to know how to identify these data.
And then, at the end, what the policy engine does is to check the request from the user against these two dimensions. And on the right-hand side, you can see, then, the possible outputs.
So, the easiest one is the access is allowed because the user is allowed, based on his attributes, to see data he requested. Then, the request gets simply passed by one-to-one. And in the middle, you see, then, so-called conditional access.
So, this is when the user is maybe not allowed to see all data, but only part of it. Then, we apply so-called dynamic masking policies. A typical example is, think of GDPR, or what we, in concrete, do is we protect personal address data of our B2C customers for users who are accessing the system from abroad, from offshore India, for example. And the third possible option or output is that we deny a whole access to the data which has been requested.
So, even more strict than just the conditional access. And a typical example for this is for our B2B customers. We have some which are either from the public sector, and hence classified, or we have also individual B2B contracts saying that there is a contractual obligation that the data is not allowed to leave German eyes, so to say.
And then, for every user who is trying to access this kind of data, they simply won't be able to see this data within one company code, so to say. And the best about this is that it all comes without touching, actually, the application logic, neither the application code, and how that actually looks like in concrete, because it's still, I think, a bit high level. I will try to explain on this more technical slide, even.
Yeah, I've been talking already about this so-called central policy platform. This is what you can see on the left side.
So, this is where the policies, the technical, I'm talking about technical data protection policies, are maintained by so-called policy admins. And these kind of policies are nothing else than rules, or set of rules, which describes for which users, user groups, based on which attributes, which actions should be applied, and which action, in terms of which obligation should be applied, should the data be masked, or should the data sets be filtered out.
And on the right-hand side, you see, in this case, in sub-application, I must admit we are quite sub-centric here today, you see a user accessing the system. This is where we still, and this is what we would like to emphasize, where we still need RBAC principles, so the general access to a system, the general functions from a high level will still be needed, in my opinion, but then the so-called RBAC attributes are coming into place. And this is then when the user starts to interact with the system, executing any transaction, then typically what is the result?
A database request will be the output. And this is actually where then the so-called data access enforcer from our vendor, as a third-party add-on, grabs and intercepts this data request, sends it over to the central platform, which we call here policy decision point, and this is then where the so-called policy evaluation takes place for each request, for each user.
And again, crucial, what I mentioned beforehand, you need to have a central, reliable user attribute source. So we connected this via LDAP and we have this information really for all human identities, but also for non-human identities. And this is really crucial, as I mentioned a few times, and then we retrieve those attributes in addition to, again, what's in the application doesn't play so much a role, because the user has access to the standard functionalities, but then on top, we check based on the user attributes if the user is really allowed to see certain data.
And in this example, he's obviously not allowed, and then what the policy engine does is it optimizes the, we call it optimizing, the data request and sends it back to the application. And then it gets executed against the database, and that's why it is impossible to bypass it, because the magic happens way down, almost on the database level. And as a result, as you can see in this example, the user gets masked values for bank accounts, bank name, in this very simple example, and this is then also displayed on his UI, and hence he has no chance to overrule this principle.
Yeah, having said that, let me move on and just show you also what we achieved so far. So we have already nine applications productive and live with our solution to protect these kind or several kind of sensitive data, and by the end of 2029, we want even to connect 30 applications. And on that journey, this is a pure delivery or rollout plan.
We will, of course, tackle new topics, explore new challenges in the AI world, and so on, and already happy to work on this with our vendor together, because there are also solutions to tackle these challenges in this area. And the concrete benefit for the business, but also for IT, is actually that we have already 500 plus users working from India in our concrete example, fully compliant with protected access to these kind of sensitive data on our critical productive systems.
So that means, like Carsten already said, we are protecting several kind of data, like civil servant data, but also we have B2B contracts, what I mentioned, with those individual contractual obligations. And this is all empowered by around about, yeah, 150 zero trust policies in the central policy platform.
Yeah, so having said that, let's give a short summary. So what are the key takeaways from our perspective? So with this centrally managed data protection, we can support on the one hand side our IT strategy to, yeah, simply globalize operations, yeah, by considering all regulations, all kind of requirements to protect sensitive data, and also support, on the other hand, the same on the business side, because they as well have a huge interest and a strategy to globalize operations, business operations.
With this solution, we prevent actually data breaches before they happen, because as I explained, the logic cannot be overruled, because it's not sitting actually in the application. And it is also, since it's a decoupled approach, yeah, in a no-code approach, it is also quite easy and rapidly to be integrated across SAP, but also in the non-SAP area. As I mentioned beforehand, we are concentrated on the SAP, but we have also non-SAP applications already live with this solution.
Yeah, and last but not least, maybe again, I would like to emphasize that we run a hybrid access control strategy. So RBAC is still essential, in my opinion, so the user needs rights to access the system, but then in addition, if we combine it with RBAC, we are gaining operational efficiency, yeah, in the identity and access management, because we do not have to manage, create so many roles, hence, you know, less approvals, less certifications, better for every manager is happy, yeah, not to re-certify, has to re-certify, those kind of things.
And then with RBAC, we have this dynamic fine-grained context, yeah, of data protection, which is, again, at the end, also auditable. So, because every request, yeah, and every result of any request is getting locked.
So, hence, we are, anytime we can prove, yeah, that the decision made by the policy engine, yeah, was correct for that time. So, the attributes might have changed in the meanwhile, but for a certain point of time, when the user requested the data, the decision was correct based on the user attributes we retrieved back then, when we did a decision. Having said that, we are actually at the end of the presentation.
So, I would like to thank you, first of all, and, yeah, feel free to approach us if you have any questions, remarks afterwards, or maybe right now, if you have some time, looking to the moderator. Yeah, first of all, thank you very much. Unfortunately, you're a bit over time.
So, if you have questions to the guys from, no, it's telecom, no, just kidding.
