Zero Trust at Deutsche Telekom

Zero trust does not mean absolute mistrust, but rather the replacement of implicit trust assumptions with explicitly modeled trust relationships. Instead of trusting the internal network across the board, each trust relationship is consciously defined, for example with an identity provider token. Large organizations typically divide Zero Trust into six areas: Network, Identities, Devices, Data, Applications and Monitoring.

Key Takeaways

• Zero Trust does not mean “trusting no one”, but rather replacing implicit trust with explicitly modeled trust relationships: Who trusts whom, why and on what basis?
• Before tokens and authorization rules can scale, the identity provider landscape must be consolidated. Telekom has reduced the number of identity providers from 30 to 3.
• Zero Trust in large organizations needs a common definition. Without it, the same concept in a room with ten people will produce eleven different opinions.
• The entry point is where an external request crosses your own trust boundary: What must be present at this point, and who must be trusted to make an informed authorization decision?
• Security initiatives make progress in existing organizations if they are linked to ongoing business objectives. Cost-saving programs offer a win-win situation because zero trust measures deliver directly measurable effects.

Zero Trust is a buzzword that every role understands differently

Zero Trust does not have a shared definition. If you go into a meeting with ten colleagues and ask what zero trust means, you will come out with eleven opinions. This is precisely the starting point for any serious project on the subject.

The term marks a trend that is forcing companies to rethink their security concept. But each role interprets it from its own perspective. A networker sees an insecure intranet and demands new hardware. System architects wave it off and consider their system to be secure.

Waldemar Schäfer from Telekom warns against repeating an old mistake. With SOA, an ESB was sold with the promise that you now had a decoupled architecture. The term carried the expectation, but the technology did not fulfill it. To prevent this from happening with Zero Trust, a company must first define what it understands by this.

Zero trust does not mean no trust, but explicit trust

Zero in Zero Trust is not meant literally. The guiding formula “Always verify, never trust” logically contradicts itself: To verify something, you have to trust the data you’re checking against.

The real point is the difference between implicit and explicit trust. Zero trust prohibits implicit trust. Instead, every trust relationship is modeled explicitly.

An example: An API trusts the token of an identity provider. This is a consciously modeled relationship, not a tacitly assumed “the intranet is already secure”. The question is always: Which parts of the infrastructure do you strategically trust and which do you not?

This adds a new perspective for architects. Previously, data flows, logical views and process views were modeled. Zero Trust adds another dimension: Who do you trust where, and why?

Six aspects on which Telekom bases Zero Trust

Deutsche Telekom has broken Zero Trust down into six areas: Network, Identities (IAM), Devices, Data, Applications and Monitoring. These six aspects form the common framework on which the various teams are working.

The impetus was a clash of perspectives. Waldemar was responsible for the authorization of APIs, while an existing Zero Trust initiative was mainly concerned with identity providers, some network and devices. Both were talking about the same word and meant different things.

The solution was to sit down and define the areas together. Having a shared definition is a prerequisite for making the concept sellable in a large organization. No specialist department stands at the ready and is happy about new security features.

Tidying up before securing: consolidate the identity providers first

Before APIs start checking identity tokens, the number of sources must be reduced. Otherwise, the very chaos that you are trying to prevent at the API level will arise at the token level.

Deutsche Telekom found around 30 identity providers for employees alone, plus B2B and B2C. If APIs were to start trusting all of these sources, the complexity would multiply. The first measure was therefore consolidation: from 30 to 3 strategic identity providers.

These three had to support modern protocols so that teams would want to use them voluntarily. Tailwind came from management and from an ongoing audit. If the pressure from outside is already there, it is easier to implement a clean-up campaign.

How Telekom is rolling out Zero Trust: building enablers, connecting consumers

The roll-out path is iterative, not a big bang. Enablers are provided, then consumers are gradually added. It doesn’t work against the big bang in a large organization.

A second driver was the decision for devices to go online. This led to the question of what this means for applications. There are several landing zones with different levels of protection, and the infrastructure must secure the applications so that they are Internet-enabled. This is not trivial: the question is not whether you will be attacked, but when and to what extent.

The next steps are being taken at the API gateway. The tokens are to be standardized there, and a separate team will manage the authorization policies centrally. The first proof of concepts have been completed and further milestones will follow release by release.

Standardization is a question of level. The higher up you standardize, the longer it takes and the more complex it is. The lower down, the faster and more pragmatic. As a result, a requirement ends up as a story, but at different levels: first at system or hub level, then at team level.

If a security requirement lands directly with the teams without any lead time because a security officer demands it tomorrow, chaos ensues. That’s why every requirement starts with the system and hub architects before it is passed on to the teams.

Security loses out to features if the mind change is missing

The biggest hurdle is not the technology, but the attitude of the teams. You join a team, Zero Trust explains, and are told: Fine, but we’re already secure.

Mindchange starts with questions instead of statements. Who do you actually trust? A, B, C, D. Once that’s been drawn up, the next question follows: Have you checked what security level these places have, how well they are protected? If the answer is no, then your own security level is just as high as that of the weakest trusted party.

This change rarely lasts. It all sounds plausible at the conference, but then the pressure of the features comes back in everyday life. You have to do security, but you think you’re pretty good. This is exactly where it is decided whether the concept will work.

You listen to something and think it’s good. But when you come back, the pressure comes with the features. Security is always in a battle against features.

• Waldemar Schäfer

If you want to win over teams, you don’t use authority to persuade them. The typical “The Chief Architect says you must” rarely works. What works: ask, use the pressure of data privacy and information security and offer concrete help. Look, this is the enabler, this is how I bind you. Help beats announcements.

Where to start: Protect crown jewels and seek win-win initiatives

The entry point comes down to two criteria. The first is the data. Protect the crown jewels, i.e. the data that is particularly worth protecting, and look there first.

The second criterion is a business initiative that creates a win-win situation. It is difficult to implement a security initiative alone. Coupling it with a project that already has momentum makes it easier.

At Telekom, this was a cost-cutting initiative. If an application consumes data with a higher protection class, the requirements increase: no operation in the public cloud, operation from Germany, higher costs. This raises the question of whether the application really needs this data. If the date can be removed, the protection class drops and the costs fall. This is exactly where cost savings come into play, making the protection comprehensible instead of just promising it.

The first practical step: sit down at the API and ask who you trust

If you want to get started, start with your own trust boundary. Mentally sit down on the API and ask: What do I need to be able to authorize?

That means in detail: What data do I need, in what quality, how quickly, and how do I access it? Latency and performance come afterwards. The starting point is the realization that the API is the first point at which a foreign, potentially malicious request comes in. That’s where trust ends. What do I need to have ready there, and who do I trust to go further?

However, there is one step before that, and that is the real sticking point: recognizing that zero trust is a buzzword that needs to be defined. For some, it is clear that you have to do it, for others it means something completely different. This common sense has to be shifted so far downwards until we start again from the very beginning to define it together.

Not every area can be secured equally well

Structured domains are the easy part. APIs with a clear structure can be authorized well with policies, here the model works cleanly.

It is more difficult with unstructured data lakes. If all data is thrown into a lake to create added business value, there is no structure on which reliable authorization could be based. There is not yet a ready answer for this case.

This is not a contradiction to the approach, but its consequence. Not all concepts are at the same level of maturity. The first step is to have a strategy and an enabler and then to go broad with the enabler in parallel. The current challenge lies precisely in this phase, from the proof of concept to the broad market.