ID#46

27.07.2022

Carsten Stöcker, Spherity: Digitales Identitätsmanagement in der Industrie (Teil 1) – ID#46

Zentrale vs. dezentrale Identitätslösungen und ihre Bedeutung für die Industrie: Die Frage „Mit wem tausche ich mich da gerade digital aus – sei es Person, Unternehmen oder auch Maschine“ ist ein fundamentales Thema bei der Digitalisierung, nicht nur zwischen Versicheren, Maklern und Unternehmen. Wir besprechen das Thema „Digitales Identitätsmanagement“ in einem 2-teiligen Podcast mit Carsten Stöcker, Gründer von Spherity. Der erste Teil widmet sich den Grundlagen rund um digitalen Identitäten und Dezentralität, im zweiten Teil wird es um die Bedeutung von Identitäten in digitalen Ökosytemen gehen.
Im Gespräch: Carsten Stöcker und Ansgar Knipschild
Länge: 53 Minuten

Transkript

Ansgar Knipschild: Herzlich Willkommen zu einer weiteren Folge unseres Podcasts. Mein Name ist Ansgar Knipschild und das ist ID – Industrieversicherung Digital. Heute haben wir wieder ein spannendes Thema aus dem Identity-Bereich, nämlich digitales Identitätsmanagement in der Industrie. Die Frage, mit wem tausche ich mich da gerade digital eigentlich aus, sei es eine Person, ein Unternehmen oder auch eine Maschine, ist ein recht fundamentales Thema bei der Digitalisierung. Dazu haben wir heute einen kompetenten Gast dabei, Carsten Stöcker, Gründer von Spherity.

 

Carsten Stöcker: Hallo Ansgar. Ich freue mich, bei dir im Podcast zu sein.

 

Ansgar Knipschild: Sehr gerne. Carsten, könntest du dich einmal in zwei, drei Sätzen ganz kurz selbst vorstellen bitte?

 

Carsten Stöcker: Mein Name ist Carsten Stöcker, ich bin Physiker, ich habe früher lange Zeit bei Accenture gearbeitet über verschiedene Industriezweige hinweg, bin danach zu RWE und Innogy gegangen im IT-Bereich und danach in den sogenannten Innovation-Hub bei RWE und Innogy. Das war insofern ganz prägend für mich, weil da bin ich sehr frühzeitig mit den ganzen Technologien, wie Blockchain, IoT, Machine Learning, moderne Kryptographie, in Berührung gekommen und es geht immer um die Frage, wie kann ich mit diesen Technologien technologiegetriebene, neue, digitale, skalierbare Geschäftsmodelle vorbereiten und angehen, um einen verstaubten Energiekonzern in eine neue, digitale Welt zu führen. Nachdem ich das gemacht habe, habe ich Spherity gegründet. Da werde ich heute viel erzählen aus unseren Erfahrungen rund um das Thema Identitätsmanagement von meinem Unternehmen Spherity. 1:42

 

Ansgar Knipschild: Super, das hört sich spannend an und du bist auf jeden Fall ein Mann der Praxis. Das ist für uns immer ganz interessant, dass wir nicht nur über theoretische Konstrukte sprechen, sondern auch aus deiner Erfahrung, sei es aus der jüngeren Vergangenheit oder aus deinen Stationen vorher. Wir haben schon im Vorgespräch gemerkt, wir haben eine Menge auszutauschen und haben uns daher entschlossen, den Podcast in zwei Teilen zu veröffentlichen. Wir starten heute mit ein paar Basics, Identitäten und Dezentralität. Nicht jeder unserer Zuhörer/Zuhörerinnen ist so tief drinnen wie du oder vielleicht auch ich in Teilen. Von daher müssen wir ein paar grundlegende Sachen vielleicht erklären. Daher dieser erste Basisteil und im zweiten Teil wollen wir dann über das Thema Ökosysteme, dort spielen Identitäten eine ganz maßgebliche Rolle, das Ganze vertiefen.

Aber genug der Vorrede, steigen wir direkt in das Thema ein. Als ich mich in der Vorbereitung ein bisschen mit dir und mit euch beschäftigt habe, bin ich über einen Ted X Talk gestolpert, The Future of Identity, den du gegeben hast. Dort habe ich mir einen interessanten Satz aufgeschrieben: Das Konzept von Identität ändert sich fundamental. Jeder und alles wird in Zukunft eine digitale Identität haben. Starten wir mit der berühmtberüchtigten Frage, was verstehst du unter diesen digitalen Identitäten, besonders im Kontext der Industrie? Warum brauchen wir so etwas für Unternehmen, Maschinen, Algorithmen oder sogar auch Daten? 3:02

 

Carsten Stöcker: Die Frage möchte ich mit einem Satz von Gartner beantworten. Gartner hat gesagt, in Zukunft oder schon heute haben wir dynamisch definierte Wertschöpfungsketten. Was sind dynamisch definierte Wertschöpfungsketten? Das sind Wertschöpfungsketten, wo verschiedene Akteure spontan zusammenfinden. In der Vergangenheit gab es Kunden-Lieferanten-Beziehungen, die über Jahre, Jahrzehnte gewachsen sind. Da gab es Vertrauen, da gab es Quality Inspektoren, da gab es irgendwelche SAP-Systeme, die sich über bestimmte Schnittstellen Datn ausgetauscht haben, dadurch, dass ich meinen Supply Chain Akteur kannte. Wenn ich die Daten bekommen habe, habe ich denen automatisch getraut, weil ich wusste, die sind von meinem Lieferanten, den ich seit zwanzig Jahren kenne.

Diese Welt ändert sich aber jetzt, wenn das dynamisch definiert ist, wenn ich plötzlich mit verschiedenen Geschäftspartnern zusammen agieren muss, die ich vorher noch gar nicht kannte. Die muss ich onboarden. Kann ich die schnell onboarden? Kann ich denen vertrauen? Was sind die Risiken, wenn ich die onboarde? Wenn ich plötzlich mit irgendwelchen Geräten oder Maschinen zu tun habe, zum Beispiel im Mobility-Bereich, dann nennt man das Ganze Vehicle2X. Das heißt, das Vehicle ist quasi das Auto und 2X heißt beliebige Infrastrukturkomponente, Schranke, Ladesäule, Mautstelle, andere Dinge, Mobility as a Service oder ein Kunde, der eine Zugangsberechtigung bekommt, ein Auto zu nutzen im Carsharing-Fall oder wie auch immer.

Die Akteure kennen sich bei diesem Vehicle2X per se vorher nicht. Genauso wie bei neuen Lieferanten, die ich nicht kenne. Das stellt Identitätssysteme vor große Herausforderungen. Offene Identitätssysteme, dass ich plötzlich mit Akteuren agieren muss, die ich vorher nicht kannte. Dazu braucht man neue Technologie und darauf gehen wir gleich ein, wie das denn aussehen wird. 5:04

 

Ansgar Knipschild: Um das noch einmal mit einem praktischen Beispiel unserer Branche, der Versicherung, zu illustrieren, wenn ich heute zum Beispiel in einem digitalen Netzwerk von Versicherern und Maklern, klassische Akteure, die miteinander Geschäft betreiben, die digital onboarden will, reden wir in der Regel über einen mehrwöchigen Prozess, bisher sehr klassisch gedacht, Unternehmensdaten, vielleicht ein Handelsregisterausdruck oder ähnliche Sachen, bis ich letztendlich zu dem Punkt komme, den ich in der Praxis brauche, zum Beispiel einem Log-In, dass ich in einem System dort tätig werden kann. So verstehe ich gerade deinen Hinweis. Das muss viel schneller gehen, das muss viel dynamischer sein, das muss quasi adhoc gehen. Dazu brauche ich Identitäten, die nicht nur an das eine System gebunden ist, vielleicht von einem Versicherer oder von einem Makler, sondern einen universelleren Anspruch haben. Kann man das so verstehen?

 

Carsten Stöcker: Genau. Das ist ganz interessant, weil es gibt das Network Scaling Law oder das Metcalfesches Scaling Law. Das wurde damals mit Telefonen gemacht. Wenn zwei Leute ein Telefon haben, können sich nur zwei untereinander austauschen, also eine Verbindung etablieren. Wenn es plötzlich vier Leute gibt, die schon Telefone habe, die Anzahl der möglichen Verbindungen geht dann im Quadrat mit der Anzahl der Teilnehmer. Das ist sehr interessant, weil der Nutzen eines Netzwerkes steigt auch mit der Anzahl der Teilnehmer im Quadrat.

Die Kosten sind die Anzahl der Telefone N, aber der Nutzen ist N², weil ich kann N² verschiedene Beziehungen zwischen den einzelnen Teilnehmern eines Telefonnetzes erzielen. Das auf Identitäten übertragen ist ein sehr entscheidender Punkt, weil denke ich klassisch an Identitäten, dass ich sage, ich bin irgendwo registriert, bei Facebook, bei Google, auf der Bosch IoT-Cloud, bei irgendeiner Siemens-Plattform oder sonst etwas. Dann bin ich in der Regel aber auch eingeschlossen in dieses Ecosystem dieser Plattform, weil ich kann nur mit anderen Akteuren von dieser Plattform, die registriert sind, die ongeboarded sind, interagieren und dann ist der Nutzen dieser Plattform beschränkt auf die Teilnehmer.

Wenn es natürlich gelingt, etwas zu finden, was sich beliebige Akteure, egal wo sie herkommen, ob sie auf einer Siemens-Plattform sind oder nicht oder auf einer Bosch-Plattform sind oder nicht oder eine einzelne Person oder nur ein IoT-Device, ein Smart Meter, ein Auto oder wie auch immer, wenn ich es ermögliche, dass diese Akteure Vertrauen aufbauen können, weil es darum geht es im Kern, wenn ich über digitale Identitäten spreche, dass ich den anderen identifizieren kann und Aussagen von dem anderen bekommen kann, wo kommt er her, wann ist er geboren worden, wann ist das Auto produziert worden, wann ist der IoT-Sensor das letzte Mal kalibriert worden, ist das ein Algorithmus, der gebenchmarkt worden ist, irgendwelche Daten produziert, und nur dann, wenn ich über die Lebensgeschichte meines digitalen Counterparts ich verifizierbare Daten habe, kann ich mir überlegen, ob die Daten echt sind und wenn sie echt sind, kann ich mir überlegen, ob ich dem Counterpart vertraue. Im Zweifel kann ich noch ein Risk-Scoring machen, etwas wie Third Party Risk Management oder so etwas, und mit Risikofaktoren und Schwellwerten agieren und überlegen, nur dann, wenn ich genug über die Lebensgeschichte wirklich End-to-End verifizierbar weiß, vertraue ich dem. Das Ganze gilt nicht nur für Unternehmen.

Im Lieferkettengesetz müssen Unternehmen geonboardet werden und ich brauche plötzlich Aussagen, wie nachhaltig ist das, ist da Kinderarbeit, ist da Anti-Bribery, sind diese Sachen alles okay. Wenn das alles okay ist, kann ich den onboarden und ich muss einen Nachweis führen. Das Gleiche gilt natürlich von Maschinen, wo ich Daten herausbekomme, weil es ist heute in Leichtes, wenn ich an eine Flotte von Autos denke oder von Wetterstationen oder Smart Metern, kann jeder beliebige hergehen und Fake-Autos, Fake-Smart-Meter, Fake-Wetterstationen generieren, die auf irgendeinem Marktplatz reinverkaufen, um entweder Geld zu machen, das wäre noch das geringste Übel, oder das schlimmere Übel wäre, um fabrizierte Daten ganz gezielt auf Marktplätze in andere Algorithmen hereinzukommen, um Systeme zu stören und zu manipulieren und die Sicherheit zu gefährden. Damit das alles verhindert wird, brauche ich eine digitale Identität und End-to-End-Verifizierbarkeit über den Lebenszyklus. 9:49

 

Ansgar Knipschild: Ein ganz wichtiger strategischer Ansatz dabei scheint mir Dezentralität zu sein. Du hast vorhin noch einmal die üblichen Verdächtigen, die für zentrales Management von solchen Identitäten stehen, Google, Facebook und Co mehr im Privatbereich, im Consumer-Bereich, aber genauso bei Industrieplattformen, wo natürlich die Betreiber von entsprechenden Plattformen erst einmal für sich die Hoheit über diese Identitäten haben. Ich mache das noch einmal für die Zuhörer ganz plastisch, sie geben die Usernamen und Passwörter, Teile der Identität, an die User ihrer Plattform heraus, die daran gebunden sind, genau wie du vorhin gesagt hast. Warum ist dieser dezentrale Aspekt so wichtig beim Thema von den neuen digitalen Identitäten?

 

Carsten Stöcker: Es gibt einen philosophischen Charakter, nach dem Motto meine Daten gehören mir, meine Schlüssel gehören, ich habe komplette Kontrolle über all das hier, ich entscheide, wann ich welche Daten weitergebe, was die Terms sind, unter denen ich die weitergebe, wie mein Kommunikationspartner das überprüfen und sicherstellen muss, dass die Daten nur auf eine bestimmte Art und Weise weiterverarbeitet werden. Das ist ein ganz wesentlicher Aspekt.

Ein anderer Aspekt ist immer das Thema der Business Confidentiality, der Vertraulichkeit meiner Geschäftsdaten. Wenn ich jetzt einmal einen sehr simplen Fall habe, dass ich ein Produkt habe und das Produkt hat einen auf ihn gedruckten Identifier, wo zum Beispiel Produktidentifikator eine Badge-Nummer und eine Seriennummer darauf ist, und dann will ich irgendwie einmal zu dem digitalen Zwilling von dem Produkt kommen, der die digitale Identität repräsentiert, dann muss ich etwas machen, das nennt man in der Technik ein Look-Up. Das heißt, ich scanne den seriösierten Identifikator ein, ich gehe irgendwo hin, mache ein Look-Up, das heißt, ich frage nach, gib mir zu diesem Identifikator eine Web-Adresse und dann gehe ich zu der Web-Adresse und fordere weitere Daten an, weil ich per se gar nicht weiß von dem Produkt, wer hat das hergestellt, wo ist der digitale Zwilling, wo kriege ich mehr Daten. Alleine nur dieses Thema Look-Up, das ist relativ plastisch, wenn in einer Wertschöpfungskette verschiedene Objekte immer wieder eingescannt werden und Look-Up-Operationen gemacht werden, derjenige, der ein zentrales Look-Up-Register betreibt, der hat natürlich das Google der Supply Chain, weil der bekommt jede Look-Up-Information. Das sind natürlich irgendwelche Metadaten, Verbindungsdaten, aber trotzdem weiß ich, welches Produkt wurde wann durch wen in der Supply Chain gescannt. Das alleine, nur Look-Up, ist ein riesen Business Confidential, das Problem, was als Industrieunternehmen gar nicht haben möchte. Das hat man natürlich bei einem zentralen Ansatz.

Das Letzte, ich habe es vorhin schon einmal angesprochen, wo ich gesagt hatte, es gibt verschiedene Plattformen, Akteure können an verschiedenen Plattformen teilnehmen, was passiert, wenn der Akteur auf einer anderen Plattform tätig ist. Das versteht man unter Dezentralität, dass ich immer mit Standards arbeiten muss. Man kann sogar argumentieren, das ist ein Begriff, der aus der Wissenschaft kommt und ein bisschen abstrakter ist, dass dezentrale Identität eine Metaplattform ist, die nur auf der Basis von Konventionen zu vereinbarten Standards besteht. Das ist jetzt interessant, weil ich Alice als einen Wertschöpfungskettenakteur oder -akteurin habe, die auf der Siemens-Plattform sind, Bob auf Facebook und Charlie meinetwegen bei Google. Wenn Alice, Bob und Charlie aber hergehen und sich diese Standards definieren, wie macht man Identität, wie macht man digitale Signaturen, wie sind Daten zu interpretieren, wie kann ich Kommunikation zwischen meinen Softwarekomponenten herstellen, wenn diese Standards erfüllt sind, können sich Alice, Bob und Charlie, die auf völlig verschiedenen Plattformen sind, plötzlich anfangen zu unterhalten und verifizierbare Daten auszutauschen.

Im Kern geht es immer darum, kann ich überprüfen, kommen die Daten immer authentisch von einem anderen Wertschöpfungskettenakteur und sind die Daten nicht manipuliert worden. Dazu braucht man die Standards und dafür braucht man digitale Signaturen an der Stelle. 14:33

 

Ansgar Knipschild: An der Stelle einmal die Frage, die im Rahmen von der Basis-ID, vielleicht hat der eine oder andere dieses Thema in der Presse verfolgt, Ende letzten Jahres ein Projekt von der Bundesregierung, nämlich wie funktioniert die Beglaubigungen von solchen Identitätsmerkmalen in so einem dezentralen Mechanismus, auch im Rahmen der Corona-Zertifikate und dem Scannen gegenüber Dritten. Ich habe einen Impf-Ausweis ist vielleicht noch einmal eine Analogie. Ich habe eine Identität, ein Identitätsmerkmal, Persönlichkeit, Corona oder beim Unternehmen andere Sachen, und jetzt sagt ein Dritter mir gegenüber: „Gib mir die einmal bitte.“ Woher weiß ich in einem dezentralen System, dass der Dritte, der mich gerade fragt, „Gib mir einmal bitte Merkmale von dir“, wirklich derjenige ist? Denn, das hast du vorhin herausgearbeitet, wir haben nicht mehr ein zentrales System, das an einer Stelle sagt, das ist wirklich wie Siemens, ich nehme nur einmal die vorhin gefallenen Namen, das ist völlig egal, aber da kommen wir immer an so einen spannenden Punkt, den ich aus Gesprächen mit Kolleginnen und Kollegen kenne, die sagen: „Wie soll das funktionieren? Wenn jeder sich selbst Identitäten ausstellen kann, kann jeder sagen, ich mache jetzt einmal die Siemens, gibt diese in Anführungsstrichen Fake-ID vor und dann kann ich wunderbar Informationen irgendwo ziehen.“

Das ist nicht unbedingt nur ein technisches Problem, sondern ein organisatorisches Problem. Was wird da gerade in dem Bereich der digitalen Identitäten diskutiert? Was sind da die Lösungsansätze? 15:59

 

Carsten Stöcker: Es gibt aus meiner Sicht zwei sehr unterschiedliche Lösungsansätze. Der erste ist, dass man mit sogenannten Vertrauensdomänen arbeitet, dass man sagt, man vertraut Qualified-Trust-Service-Providern. Die Bundesdruckerei hat eine Tochter namens D-Trust. Wenn alle in dem Ecosystem der sogenannten D-Trust trauen, weil man weiß, die D-Trust ist vom TÜV zertifiziert und weiß nicht von sonst wem noch zertifiziert und die legt alle Conformance- und Compliance-Dinge offen und da gab es nie Probleme, dann kann man der D-Trust trauen.

Wenn Unternehmen eine digitale Identität brauchen, können die Unternehmen dahingehen und einmal ein sogenanntes Identity Proving oder eine Identitätsüberprüfung machen, bei Menschen würde es Know Your Customer Überprüfung heißen, und das Gleiche gilt für Unternehmen. Das heißt, das Unternehmen hat ein Stück Software, was man häufig Identitätsbrieftasche oder Identity Wallet und diese Identitätsbrieftasche ist nichts anderes als das, was Menschen haben, wenn sie ihr Portemonnaie haben. Darin habe ich auch Führerschein, Personalausweis, Krankenversicherungskarte und so. Das Gleiche gibt es natürlich für Unternehmen. Das Wichtige, das A und O ist immer dieser Initial Trust. Woher weiß ich, dass das Unternehmen das Unternehmen ist? Da kann man natürlich auf Trust Domains zurückgreifen, weil ich weiß, dass ich der D-Trust traue und dass die das immer auf Basis eines extremen Vertrauensniveaus diese Überprüfung durchführt, und jemand zeigt mir einen D-Trust-Identitätsnachweis vor, dann kann ich sagen, das Unternehmen ist das Unternehmen, weil D-Trust hat es gesagt. Natürlich gibt es Wettbewerber von der D-Trust, die etwas Ähnliches machen.

Es gibt verschiedene Qualified-Trust-Service-Provider. Das ist alles in eIDAS beschrieben, wenn man auf Standardtechnologie geht. Jetzt entwickelt sich die Technologie gerade weiter. Die ganzen Unternehmen, ob es Bundesdruckerei ist oder InfoCert aus Italien oder andere Unternehmen, die beschäftigen sich alle mit der dezentralen Technologie aufgrund dieser Netzwerkeffekte, dieses N², was ein riesiger makroökonomischer Nutzen ist. Da kann ich jetzt erstmal D-Trust trauen oder InfoCert aus Italien. Aber es gibt noch mehr Trust Domains. Zum Beispiel kann ich hingehen und sagen, ich vertraue der GS1. Die GS1 stellen Identifikatoren aus für Unternehmen, für Standorte, für Produkte, die standarisieren Kommunikationsprotokolle und so weiter. Wenn ich der GS1 traue, ein Supply Chain Use Case, wo häufig Unternehmen sich sogenannte GS1-GLNs, Global Location Numbers, hin und her schicken, das kann ein Unternehmen repräsentieren, kann eine Abteilung, einen Standort repräsentieren, das Problem Stand heute ist, in der digitalen Kommunikation könnte ich hier eine GLN von AEG oder etwas hereingeben, aber keiner weiß, ist es wirklich AEG oder nicht, hat der vorher einer eine GLN hineingeschrieben.

In Zukunft wird es so sein, dass die alle digital unterschrieben werden müssen. Das ist ein Riesenunterschied. Das heißt, ich habe Vertrauensdomänen, wo Dinge digital unterschrieben worden ist, da entstehen auch sogenannte Vertrauensketten, darauf können wir vielleicht gleich noch einmal eingehen, was eine Vertrauenskette ist und wo es das heute schon gibt, und im Rahmen von der Vertrauensdomain weiß ich dann, ich vertraue der GS1 und wenn die gesagt hat, das ist das Unternehmen mit der Global Location Number oder D-Trust hat gesagt, das ist das Unternehmen oder ich kann genauso sagen Bundesanzeiger Verlag. Bundesanzeiger Verlag hat auch viel. Die könnten auch solche Credentials über Unternehmensidentität ausstellen, könnten sie selber machen, könnten sich einen Standard bedienen.

Es gibt die sogenannte Global Legal Entity Identifier Foundation. Die kennt man aus dem Financial Services Bereich, weil sobald ich Finanzmarktgeschäfte tätige, brauche ich diesen sogenannten LEI-Code, Legal Entity Identifier. Die GLEIF ist quasi eine Non-Profit-Organisation, ein bisschen analog zu GS1, nur sehr fokussiert auf die LEIs, die überlegt sich auch gerade, wie kann man das mit Identität verknüpfen, das mit elektronischen Signaturen verknüpfen. Wenn jetzt Bundesanzeiger mit so einer GLEIF-Domain, das Unternehmen hat diesen Legal Entity Identifier, kann ich nachschlagen, komme sogar direkt auf die Handelsregistereinträge und kann noch weitere Informationen bekommen, wie Political Exposed Persons, PEPs, ist das Unternehmen auf einer Sanction List, ist das Unternehmen In-Liquidation, letzter Geschäftsbericht, alles digital unterschrieben und so gibt es noch weitere Vertrauensdomänen, teilweise industriespezifisch, zum Beispiel der BDEW, der gibt BDEW-Nummern aus. Wenn ich dem BDEW traue und den Prozessen, wie die das machen, traue, habe ich wieder eine Vertrauensdomain. Oder TÜV oder wie auch immer. Dann kann ich als Unternehmen mir Aussagen über mein Unternehmen geben lassen aus verschiedenen Vertrauensdomänen, die ich anderen vorzeigen kann. Wenn ich denen sowohl ein GLEIF-Credential, ein D-Trust-Credentials, einen Bundesanzeiger- und einen TÜV-Credential gebe oder meinetwegen ein Sparkassen-Credential mit meiner IBAN-Nummer, oder einen anderen Bank-Credential, kann der andere das alles durchverifizieren und plötzlich Vertrauen aufbauen.

Alleine dieses IBAN-Thema: Es gibt Payment Processing, wo über Social Engineering versucht wird, bei Zahlungsläufen in Großunternehmen bei zweistelligen Millionenzahlungen plötzlich einmal eine andere IBAN hereinzuschmuggeln. Das braucht Payment Processing und wenn man verifizierte IBAN-Nummern hat, dann entfällt das. Da hat man natürlich mit zentraleren Institutionen zu tun, die innerhalb einer Trust Domain machen, aber ich selber kann diese Aussagen nehmen und überall hintragen und muss nie mehr wieder erneut KYC’ed werden, meine IBAN-Nummer prüfen und so weiter. Das wird einmal gemacht und dann kann es wiederverwendet werden. Das ist natürlich ein großer Vorteil.

Dann gab es noch die andere Variante, Ansgar, darauf will ich kurz eingehen, dieses Web of Trust, dass man sagt, man will das auch nicht, sondern es ist wie in Social Media im Web. Das heißt, ich selber bin auf LinkedIn, mache bestimmte Posts, andere liken diese Posts, andere reposten das und dadurch, dass andere mit mir interagieren und ich eine Historie aller meiner Interaktionen habe, kann natürlich ein Dritter hingehen, analysiert die Historie meiner Interaktionen und kann sich mit meinem Algorithmus sich überlegen, was ist hier meine Reputation und kann ich dem trauen. Das heißt, das wird sehr bottom-up ohne diese zentralen Vertrauensdomänen.

Selbst in sozialen Netzwerken, die entweder dezentral organisiert sind oder über verschiedene Plattformen hinausgeht, funktioniert das heute nicht, dieses Web of Trust. Deswegen wird es im Industriebereich eher schwierig und vor allem dann, wenn ich Compliance-Anforderungen habe, wo Conformance-Kriterien sind. Das bekomme ich dezentral gar nicht hin, weil ich kenne teilweise irgendwelche anderen Partner, die Aussagen über mich machen. Einen anderen Geschäftspartner kennt die faktisch nicht und woher weiß der, dass die dann gute Prozesse haben, den man trauen kann. Aufgrund des Themas Compliance fällt das aus unserer Sicht erst einmal flach und deswegen braucht man dezentrale Identität und die Vertrauensdomänen. Da wird erst einmal kein Weg darum herumführen. Vielleicht, Ansgar, sollten wir gleich noch einmal darauf eingehen, warum digitale Signaturen so wichtig sind. 24:15

 

Ansgar Knipschild: Okay. Wenn ich das noch einmal ganz kurz zusammenfasse, gerade diesen ersten Ansatz, der für die Industrie wirklich praktisch unausweichlich ist, wir brauchen diese Identitätsgeber, würde ich zusammenfassen, es sind mehrere, wir haben verschiedene. Du hast vorhin Beispiele genannt: Das kann Bundesdruckerei sein, das können aber durchaus auch Industrieunternehmen sein, Lieferanten oder Leute, die zertifizieren und ähnliches.

Die Summe der beglaubigten Identitätsmerkmale macht nachher die Gesamtidentität von einem Unternehmen oder von einer Maschine aus und ich kann mir vorstellen, je mehr solche Attribute ich habe, je mehr bestätigte Identitätsmerkmale ich habe, umso vertrauenswürdiger werde ich natürlich.

Ein Unternehmen, das sowohl von seinem Steuerberater eine Einkommensgröße attestiert bekommen hat als Beispiel und vielleicht noch vom Finanzamt die Umsatzsteuer digital über entsprechende Identitätsmerkmale bestätigt hat, wird bei einem Onboarding sagen, du hast so und so viel Umsatz glaubwürdiger dastehen als jemand, der das gar nicht hat.

 

Carsten Stöcker: Sehr gut.

 

Ansgar Knipschild: Vielleicht ist das dieser Mittelweg von ganz ohne zentrale oder teilzentrale Aspekte kommt man nicht aus, aber vor allen Dingen die Summe mehrerer solcher Attribute, die durch ganz verschiedene Businessbrillen betrachtet wird, macht es wertvoll und stärkt die Identität.

 

Carsten Stöcker: Das ist mega zusammengefasst. Man spricht heute in Wertschöpfungsketten häufig von Back-to-Birth Traceability oder Lifecycle Transparency. Die Summe aller dieser überprüfbaren Aussagen oder Credentials, Zertifikate ist quasi Back-to-Birth Traceability oder meine Lifecycle Transparency. Ob ich das teile oder nicht und mit Business Confidential und Privacies sind noch einmal andere Sachen, aber die Summe ist mein digitales Ich als Unternehmen, als Maschine oder als Objekt.

Vielleicht noch einmal eine Sache dazu: Wir hatten ein bisschen über Unternehmen und ein bisschen über Maschinen gesprochen. Du hast es gerade gesagt, die Summe aller dieser Aussagen, angenommen es ist eine Wetterstation und ich weiß, wer hat es hergestellt, wer hat es deployed, wer hat gesagt, dass die Wetterstation da ist, wo sie ist, wer hat die Wetterstation kalibriert, wenn ich diese drei Aussagen habe und ich nachher Daten aus dieser Wetterstation bekomme, die ich verknüpfen kann mit diesen Aussagen, Hersteller, wo ist installiert, wer hat installiert, wer hat kalibriert, sind natürlich die Daten aus dieser Wetterstation viel mehr wert, weil ich viele Risiken ein bisschen eingrenzen kann. Das ist ganz interessant. Daran denkt heute noch keiner. Häufig sagt man, ich habe ein Credential von irgendjemandem. Ein COVID-Credential, was nichts anderes ist, es ist nur eine andere Technologie, bin ich getestet worden oder nicht, und dann traue ich dem oder nicht. Aber das hat viel mit Risiko zu tun, weil das ist keine binäre Aussage, selbst wenn ich es kryptographisch überprüfen kann, dass dieses Testpass-Credential von einem bestimmten Arzt ausgestellt worden ist und das Robert-Koch-Institut unterschrieben hat. Das heißt, das war die Teststation, das ist kryptographisch unterschrieben worden von dem Teststationenbetreiber und ich kann dem dann trauen.

Kryptographisch ist alles okay, aber in der realen Welt gibt es verschiedene Risiken: Ist die Identität der zu testenden Person wirklich richtig überprüft worden? Hat man der den richtigen Aufkleber gegeben? Hat der Test versagt? Was hat der für eine Sensitivität? Sind die Tests vertauscht worden? Hat einer einen menschlichen gemacht? Das ist ein ganz interessanter Aspekt. Viele Leute denken heute naiv, wenn ich es kryptographisch überprüfen kann, ist es richtig. Aber in einem Geschäftsprozess sind Risiken darin. Das heißt, eigentlich muss ich jede dieser digital geschriebenen Aussagen immer mit einem Risk Score unterlegen. Das ist genau, was du sagst. Wenn ich digital unterschriebene Aussagen aus verschiedenen Vertrauensdomänen habe, kann ich natürlich wunderbares Risk Scoring machen.

Nachher kommen wir noch einmal auf das Thema Maturity der Technologie und wo steht das Ganze, aber das Thema Risk Scoring über verschiedene Vertrauensdomänen ist noch relativ unbeackert für diese ganzen Nutzungs-Cases. Das wird auf jeden Fall kommen und das hat viel mit Insurance-Propositions zu tun. Das sind Themen, wo unsere Leidenschaft daran hängt, die hoffentlich auch für unsere Hörer hier heute zu hören sind. 28:54

 

Ansgar Knipschild: Gut, hier haben wir natürlich einen wunderbaren Punkt zum Thema digitale Versicherung, digitale Industrieversicherung. Wenn wir uns vorstellen, dass demnächst solche Risk Scorings, wie du sie genannt hast, also vielleicht Begutachtungen von Industrieanlagen oder von Teilen, von Komponenten, die heute von Risikoingenieuren durch Versicherer zum Beispiel durchgeführt werden, und wo es ein wahnsinniges Thema ist, dass jeder Versicherer seine eigenen Risikoingenieure wieder in das Feld schickt, weil er vielleicht die Versicherung bepreisen muss. Wenn er sich heute darauf verlassen könnte, schau einmal, hier ist erst einmal entsprechend digital beglaubigt, ein Zertifikat, das sagt, diese Anlage wurde am so und so vielen von dem und dem, der wiederum auch vertrauenswürdig ist, geprüft und für sicher befunden, das kann ein TÜV-Zertifikat, ISO-Zertifikat oder was auch immer sein, kann man von der Fantasie her auch im Versicherungsbereich schon überlegen, jetzt kann ich digital das Risiko ganz anders bewerten, weil ich die Summe von digitalen Einschätzungen oder Bewertungen da habe. Das ist superspannend. 29:50

 

Carsten Stöcker: Da möchte noch einmal anhaken an der Stelle. Wo steht es heute? Heute haben diese Unternehmen alle Datenbanken, darin sind viele Terrabyte, ich weiß nicht, was danach kommt, und das Problem bei all diesen Datenbanken ist, dass ich keinen Herkunftsnachweis der Daten habe. Wo kommt das Datum her und ist das Datum auf dem Kommunikationsweg zu mir, wo ich es hereingeschrieben habe, verändert worden oder vielleicht sogar in meiner Datenbank verändert worden und ist das Datum überhaupt noch gültig? Ist es vielleicht wiederrufen worden? Das ist ein Riesenproblem, dass ich das nicht überprüfen kann.

Bei der digitalen Identität geht es genau darum, digitale Unterschriften, Signaturen einzuführen. Das heißt, wenn mein Geschäftspartner mir ein digital signiertes Datum gibt, kann ich es, bevor ich es in die Datenbank hereinschreibe, kann ich einmal prüfen, war das überhaupt der Geschäftspartner, passt die digitale Unterschrift, das sogenannte Public Key Cryptography, zusammen, gehört diese Unterschrift zu dem Geschäftspartner, hat der es wirklich unterschrieben. Das heißt, ich kenne das Thema Authentizität der Daten.

Das Zweite ist, wenn eine Unterschrift nicht zusammenpasst, kann es daran liegen, dass jemand die Daten manipuliert hat. Das heißt, das Thema der Datenintegrität kann ich, je nachdem wie ich es machen, klar können sich kryptographische Algorithmen ändern, aber, je nachdem wie ich das mache, kann ich viele Jahre und Jahrzehnte überprüfen, ob die Daten nicht verändert worden sind. Das Dritte, was man mit digitalen Unterschriften machen kann, ich kann Mechanismen einführen, ob diese Daten widerrufen worden sind. Das heißt, wenn ich einen Supplier geonboardet habe oder etwas Anderes und ich arbeite mit dem und möchte ein halbes Jahr später wieder gucken, ist noch alles in Ordnung mit dem, dann überprüfe ich den Widerrufsstatus der Daten und stelle fest, die sind widerrufen worden. In einem Fingerschnipp, wenn ich feststelle, die sind wieder widerrufen worden, bricht die Vertrauenseinschätzung, der Counterpart, hier zusammen, weil diese Daten nicht mehr gültig sind. Dann muss ich eventuell noch einmal neu diese Daten anfordern. Das ist natürlich gerade für solche Bewertungen wichtig und da geht es sehr viel um digitale Unterschriften. Genau, das werden wir weiter vertiefen. 32:17

 

Ansgar Knipschild: Ja, auf jeden Fall. Ich würde ganz gerne einmal in die Praxis kommen. Wir haben ein paar Grundlagen gelegt, wir haben ein paar Konzepte verstanden und jetzt würde ich gerne konkret werden im Sinne von hast du vielleicht einmal ein praktisches Beispiel für unsere Zuhörer, wo dieses Handling von digitalen Identitäten zumindest ansatzweise schon funktioniert? Im Pharmabereich hast du ein Beispiel dabei oder vielleicht könntest du da an einem wirklich nachvollziehbaren Beispiel beschreiben, wo das heute schon funktioniert. 32:45

 

Carsten Stöcker: Ich würde am Anfang erst einmal auf das Thema Pharmaindustrie eingehen. Man muss es so sagen, was ich vorhin gesagt hatte, alle mit allen, das N², das Netzwerk Scaling Law und Alice, Bob und Charlie von verschiedenen Plattformen. Das heißt, man kann diese Identitätstechnologie auch als Ecosystem-Technologie betrachten. Das heißt, es macht nur dann Sinn, wenn Partner in einem Ecosystem alle diesen Standard nutzen. Dann funktioniert es. Dann kann jede Software diese Standards speichern und es kann Vertrauen aufgebaut werden. Das ist immer sehr schwierig, Stand heute, diese Stecknadel im Heuhaufen zu finden, wo hat man ein vollständiges Ecosystem, wo man diese Technologie adopten kann. Da sind wir von Spherity, wir sind ein SAP.iO Partnerunternehmen, haben viel mit der Pharmaindustrie zusammengearbeitet und im Rahmen der Compliance und Risk Kohorte bei SAP sind wir auf das Thema der Authorized Trading Partner in den USA gekommen. Das ist insofern ganz spannend, da kann man auch einmal die Zeiträume verdeutlichen. Das geht sicherlich jetzt schnell.

Die Obama-Administration hatten 2013, also vor fast zehn Jahren, einen sogenannten Drug Supply Chain Security Act in das Leben gerufen und Ziel war es, Betrug in der Pharma Supply Chain zu verhindert, also dass Leute gefälschte Produkte hineinbringen, dass Leute Produkte, die irgendwo anders aus dem Verkehr genommen worden sind, woanders hin, weil die schlecht sind oder es andere Probleme gibt, woanders hinbringen und da weiterverkaufen, das nennt man (Sell Returns), oder dass die Kartelle, in Amerikaner brauchen mehrere Millionen Schmerzmittel, Methadon, Morphin und so etwas, aber auf Rezept bekommen es nur 200.000 Amerikaner. Was macht der Rest? Der Rest wird beliefert von den Kartellen aus Mexiko und so. Das sind alle illegale Methadon- und Morphinlieferungen und da geht es sehr viel um das ganze Thema Tracing und Identität. Was hat die Obama-Administration gemacht? Sie hat vier Dinge eingeführt: Erst einmal müssen alle Produkte serialisiert sein. Serialisiert heißt, die Produkte brauchen einen kleinen QR-Code, den ich einscannen kann, und dann bekomme ich Produktnummer, Badge-Nummer, Seriennummer, die eindeutige Seriennummer des Produktes.

Übrigens, dass man einmal ein Gefühl für die Kosten hat, das sind sogenannte 2D-Datenmatrizen, also QR-Codes nur ein bisschen anders dargestellt, und das kann ein großes Pharma-Unternehmen einmal hundert Millionen kosten, global eine Serialisierungsstruktur umzusetzen, nur um serialisierte QR-Codes daraufzudrucken.

Das war das Erste. Das Zweite, was die Obama-Administration gemacht hat, war, zu sagen, wir müssen die Produkte verifizieren können. Das heißt, ich scanne sie ein, mache dann, wie eingangs gesagt, diesen Look-Up, wer hat es überhaupt hergestellt, weil es gibt einen Hersteller, Divestitures und Acquisitions, dann ändert sich, wem das gehört, einen Hersteller, es gibt Contract-Manufacturing und irgendwelche anderen Manufacturing-Konstrukte. Das heißt, es ist erst einmal per se nicht einfach zu wissen, wer hat es hergestellt und wo finde ich die Daten dazu. Das ist das Thema Look-Up. Das ist ganz interessant. Die Pharma-Unternehmen haben sich 2018 oder 2019, das genaue Jahr kenne ich leider nicht, dafür entschieden, aus Business-Confidentiality-Gründen zu sagen, wir machen ein dezentrales Look-Up auf Basis von einer Distributed-Ledger-Technologie, Blockchain, ohne zentrale Instanzen zu nutzen. Dann können die das im Prinzip jetzt einscannen, gehen zum Hersteller und der Hersteller guckt in seiner Datenbank nach, weil es sind alles zufällige Seriennummern, ist das wirklich eine Seriennummer, die von mir kommt und die nur einmal verwendet wird, oder ist es eine Fake-Seriennummer, weil ein Angreifer müsste entweder mit Fake-Seriennummern angreifen, was bei einer Verifikation von so einem Produkt auffallen würde, oder er müsste eine existierende Seriennummer kopieren, was ebenfalls in der Supply Chain auffallen würde, weil die dann mehrmals auftaucht. Das kann man mit Geldrucken übrigens vergleichen, weil bei Geld stehen Seriennummer darauf, die zufällig erzeugt sind, und weitere Security Features, die auf einem Geldschein sind, die man unter UV-Licht sieht oder Wasserzeichen, verschiedene Farbspiele, Hologramme und so weiter. Das gibt es in der Pharmaindustrie nicht. Da gibt es nur die Seriennummern.

Jetzt kommt das Nächste dazu, das nennt man Authorized Trading Partner, dass gesagt worden ist, wenn ein Großhändler einen Verifikations-Request an einen Hersteller schickt, soll Bitteschön der Großhändler nachweisen, dass er überhaupt autorisiert ist. Das heißt da Authorized Trading Partner. Das heißt, hat der eine Lizenz von einem der Bundesstaaten in den USA, überhaupt pharmazeutische Produkte im Großhandel zu vertreiben. Er muss das bei jeder digitalen Interaktion nachweisen. Das ist das, was in den USA gerade in Produktion geht. Da wurden Standards geschaffen, das alles abgestimmt und N*N-Testing mit der kompletten Industrie gemacht. Das geht gerade in den USA in Produktion, dass in jeder digitalen Interaktion immer dieser Nachweis mitgeschickt wird, vom Großhändler zum Hersteller, vom Apotheker zum Hersteller, weil die müssen das auch verifizieren, bin ich ein Authorized Trading Partner ja oder nein und dann geht es nachher noch weiter, dass man ganze Tracing-Request sieht, wo welches Medikament und so weiter. Das führt hier ein bisschen zu weit. Aber für die Supply Chain Security ist das ein Riesenschritt nach vorne.

Wir machen das Thema Authorized Trading Partner. Das heißt, wir müsse die Identität der Pharma Supply Chain Akteure überprüfen können, Identitätsnachweise, Identitäts-Credential ausstellen und sogenannte Authorized Trading Partner Credentials. Das machen wir in den USA mit Partnern, weil es ein entsprechendes Ecosystem ist und dieser Use Case geht da in Produktion at Scale und da sind 60.000 Supply Chain Akteure von betroffen. Warum ist das USA, wir sind ein deutsches Startup? Das hängt damit zusammen, dass man immer verschiedene, kritische Erfolgsfaktoren braucht, um überhaupt etwas in Produktion zu überführen. Man braucht bei einer Ecosystem-Technologie ein komplettes Ecosystem, man braucht educated Ecosystem-Partner, weil ansonsten müssten wir die zwei Jahre educaten, beibringen, wie funktioniert das mit der Kryptographie und warum dezentral und dies und das. Das machen die alles schon und mussten wir daher nicht mehr machen. Dann brauchen die einen Business Case und man braucht so etwas wie Retrofitting. Das heißt, ich kann sehr einfach existierende Infrastrukturen durch eine einfache API-Integration umstellen, ohne in Anführungsstrichen Accenture-Buse zu allen Unternehmen zu schicken, die in den IT-Systemen herumschrauben. Das braucht man nicht. Das ist wirklich das Einmalige, dass diese kritischen Erfolgsfaktoren zusammenkommen.

Der vorletzte kritische Erfolgsfaktor, den ich noch nennen möchte, ist, die Drug Enforcement Agency hat den Unternehmen allen schon eine Identität gegeben. Das ist für uns natürlich vorteilhaft. Wenn wir jetzt die Identität von 60.000 Unternehmen als Startup überprüfen müssten, das wäre schwierig, das mit entsprechenden Compliance-Anforderungen umzusetzen. Die Drug Enforcement Agency, die man aus den Filmen kennt, die Leute mit den Kanonen und DEA hinten auf dem Rücken, sind hingegangen, haben die alle überprüft und haben denen eine digitale Identität gegeben, die wir einfach nachnutzen.

Der letzte Erfolgsfaktor ist, es muss ein simpler Use Case sein. Der Use Case ist simpel und von daher sind wir da in den USA sehr weit gekommen, was sehr erfreulich ist. Das wäre dann der Use Case. 40:52

 

Ansgar Knipschild: Das ist superspannend. Wir kommen auf weitere Use Cases im zweiten Teil, du hast das Stichwort Ökosysteme schon genannt, zu sprechen. Ich würde gerne zum Abschluss noch dein Stichwort zum Thema APIs nennen. Wir haben uns jetzt stark über Identitäten, über Zertifikate vielleicht unterhalten, aber irgendwann muss man zwischen diesen Systemen in Realtime immer wieder die Informationen austauschen. Das heißt, man benutzt APIs. Das kennen wir von klassischer Technologie. Auch hier hat man die Aufgabe, wie bekomme ich das sicher und skalierbar gemanagt hin, insbesondere wenn das immer mehr wird, wenn das in Realtime passiert. Was gibt es da für Konzepte, um gerade in Zeiten von vermehrten Cyber-Angriffen, von erhöhten Risiken, die sich beim Öffnen von Schnittstellen nach außen ergeben? Wie kann ich dort immer mehr externen, digitalen Zugriff auf meine Systeme erlauben, Stichwort Zero Trust Architecture? Das ist ein Begriff, den wir im Vorgespräch hatten. Was sind da die aktuellen Überlegungen?

 

Carsten Stöcker: Es ist gut, dass du die APIs nennst, weil interessanterweise habe ich jetzt über den Anwendungsfall in Amerika gesprochen, aber in Deutschland gibt es auch solche Sachen wie Gaia-X, Catena-X und noch weitere X-Projekte, wo das Thema der Identität genau auf den Prinzipien, die ich bis hier beschrieben habe, erst abstrakt und dann am Beispiel US-Pharma Supply Chain, aber genau diese Technologiearchitekturprinzipien werden in all diesen Projekten mit integriert und zugrundegelegt. Da geht es um Cloud, um Integration, existierende Systeme und um API-Integration. Das ist das sehr Interessante, dass man erst einmal sich überlegt, wie kann ich die APIs überhaupt standarisieren. Das ist das Erste. Das ist auch für Sicherheit schon wichtig.

Wenn es verschiedene Lösungsanbieter gibt, wäre es toll, wenn die APIs standarisiert sind, weil dann kann ich die Lösungsanbieter für digitale Identität in Anführungsstrichen einfach austauschen, wobei das einfach in Anführungsstrichen zu hören ist. Das heißt, ich kann die austauschen. Es ist standarisiert, ich kann mich darauf verlassen und die Standarisierung führt natürlich auch zu dieser Interoperabilität, Datenportabilität, dass alle miteinander sprechen können. Das heißt, ich als Unternehmen nehmen einen digitalen Identitätslösungsanbieter, kann den über APIs integrieren, dann sprechen schon einmal meine Systeme diese neuen Identitäts- und Vertrauensstandards, meinetwegen später bei Gaia-X und Catena-X und diesen und anderen Sachen zugrundeliegen. Das ist schon einmal super.

Der zweite Aspekt ist, jetzt kann ich mit meiner Software sehr einfach sprechen, jetzt müssen sich die Softwaren die Identitätslösungen, manchmal wird von Agenten gesprochen, sogenannten Identitätsagenten, die müssen sich untereinander unterhalten können. Auch das geht über APIs und über Standards. Das Interessante ist, dadurch, dass ich mit digitalen Signaturen arbeite, ist schon einmal ein Aspekt wichtig.

Wenn sich zwei Software-Lösungen unterhalten und es richtig signiert ist, weiß ich immer, die Software-Lösung des anderen, die mir Daten schickt, die sind nicht manipuliert worden, weil die sind digital unterschrieben worden. Das muss von dem anderen gekommen sein, ist authentisch von dem und die sind auf dem Weg zu mir nicht manipuliert worden. Das ist alleine schon ein ganz entscheidender Faktor. Ich kann immer annehmen, dass das Internet unsicher ist. Sobald ich die digitale Signatur überprüfe, kann ich mir sicher sein, auf dem Weg von meinem Geschäftspartner zu mir sind die Daten nicht manipuliert worden. Das hat schon mal eine Security-Komponente und dann kann man solche Sachen wie Man-in-the-Middle-Attacken ausschließen. Das ist schon einmal eine gute Sache. Dann kommt natürlich dazu, dass man bestimmte Conformance-Kritierien, Sicherheitsanforderungen zu erfüllen hat, insbesondere beim Thema Schlüsselmanagement. Das ist ganz entscheidend, weil ich hatte eingangs gesagt, digitale Unterschriften, sogenannte Public Key Cryptography, das heißt, ich habe einen öffentlichen Schlüssel, den jeder einsehen oder kennen kann, ich habe einen privaten Schlüssel, den ich absolut geheim halten muss, den ich nur beim Signieren verwende und der niemals nach draußen gelangen darf, weil, wenn mein Schlüssel nach außen gelangt, ist das Identitätsdiebstahl, kann sich jeder für mich ausweisen.

Das ganze Thema des sicheren Key-Management ist ein extrem wichtiges Feature an der ganzen Sache. Darauf sind wir heute nicht eingegangen, wie die Technologie funktioniert und wie der andere weiß, dass alles okay ist. Ich kann beispielsweise über Protokolle überprüfen, ob der andere den Schlüssel in Hardware ist, es gibt Secure Element und Hardware Security Module, das sind so Fachbegriffe, aber da ist der Schlüssel in Hardware drin und der Schlüssel kann praktisch nicht da herauskommen, weil er in der Hardware drin ist und es gar keine Möglichkeit gibt, den herauszubekommen. Jetzt kann man überlegen, mit Side-Channel Attacken und Röntgenstrahlung herauf- und herunterfahren von Strom und dann etwas messen. Vielleicht bekomme ich Informationen über den Key, dafür braucht man aber die Hardware und das ist extrem aufwendig. Das ist diese Sache. Wenn ich jetzt überprüfen kann, das ist Hardware, der ich vertraue und der Schlüssel ist darin, dann weiß ich, das ist auch so der Fall.

Jetzt kommt noch etwas Anderes dazu, das ist das Thema Zero Trust Architecture. Das ist ein Prinzip vom NIST, das ist in Anführungsstrichen das BSI, Bundesanstalt für Sicherheit in der Informationstechnik quasi Deutschland, aber NIST ist quasi aus den USA. Die machen noch ein bisschen mehr, aber die legen solche Cyber-Dinge fest und die haben das Konzept der Zero Trust Architectures definiert, wo man versuchen will, Vertrauen in bestimmte Komponenten zu eliminieren. Man muss dazu sagen, Zero Trust ist ein bisschen irreführend, weil man muss immer irgendetwas vertrauen. Aber im Gegensatz zu anderen Architekturen ist Vertrauen ist nur woanders. Vertrauen ist nur woanders, aber Vertrauen ist drin. Deswegen ist Zero Trust ein bisschen irreführend. Der Joe Biden hat Anfang des Jahres eine Executive Order übrigens unterschrieben. Es gab sowieso schon viele Cyber Security Attacken und Cyber Warfare. Das war noch vor dem Krieg in der Ukraine. Er hat eine Executive Order unterschrieben und gesagt, alle Behörden müssen eine Zero Trust Architecture Strategie machen.

Zero Trust Architecture hat drei Elemente: Das Erste ist Enhanced Identity Governance, also genau was wir vorhin hatten mit den Trust Domänen und den Anforderungen, wie wird das gemacht. Das ist Enhanced Identity Governance. Das Andere ist Microsegmentierung, dass ich irgendwie auf Netzwerkebene etwas mache und nur irgendwie vertrauensvolle Partner zusammenschalte. Das lassen wir weg. Das ist zu kleinteilig und sehr schwer at Scale umzusetzen. Aber Enhanced Identity Governance hatten wir diskutiert.

Das Letzte ist wieder ein technischer Begriff. Da steht drin Software Defined Perimeter. Das ist jetzt interessant, weil es da um den Aspekt der API-Endpunktsicherheit geht. Das heißt, ich kriege eine Anfrage geschickt an meinen API-Endpunkt von einem Supply Chain Akteur und die möchte ich beantworten. In der Fachsprache heißt das, ich kriege einen Request, ich möchte einen Response senden. Ich darf aber nur den Response senden, wenn ich den anderen authentifiziert habe, ist das wirklich die Partei, von der ich den Request erwarte und die sie vorgibt zu sein, und auch autorisiert habe, darf der das überhaupt.

Wir hatten vorhin das Thema der Authorized Trading Partner. Es gibt Beispiele in der Energiewirtschaft, da spricht man plötzlich von Eligible Parties. Die Rolls Royce Leute, Turbinen im Flugzeug Bereich, hatten einmal solche Sachen, Export Compliance. Es wäre toll, wenn einer bei einem API-Request mir einen Nachweis schickt, dass er nicht aus Iran kommt, dass ich vollautomatisiert die Export-Compliance habe. Da gibt es beliebige Beispiele wie Sand am Meer zur Autorisierung. Oder es ist eine Maschine von ZF und ich erwarte hier als ZF-Maschine im Sinne von Remote-Maintenance, dass ein Remote Maintenance Operator zu mir kommt. Da ist die Frage, ist das ein Mitarbeiter bei ZF, gehört der zum Remote Maintenance Team, ist der autorisiert, diese Arten von Maschinen zu warten, ist der trainiert, ist das Trainingszertifikat noch gültig und ist der überhaupt noch angestellt? Das könnte ich als Maschine überprüfen. Darum geht es bei den Zero Trust Architekturen, dass ich Aussagen derjenigen, die bei mir auf etwas zugreifen wollen, eine Response haben wollen, die Daten haben wollen, die sich zum Portal einloggen wollen, dass die sich korrekt ausweisen können, dass ich dann nur den Zugriff gebe, wenn der korrekte Ausweis stattgefunden hat.

In der Zero Trust Architecture wird das als Software Defined Perimeter bezeichnet. Aber es nichts anderes, als dass sich meine Counterparty mit ihrer Unternehmens- oder Maschinenbrieftasche ausweist und kontext- oder anwendungsfallspezifische Autorisierungs-Credentials mitgibt und ich nur dann den Zugriff gebe.

Das Thema API-Endpoint Security ist deswegen so wichtig, weil das ist die größte Angriffsfläche. APIs wachsen exponentiell. Das ist die größte Cyber-Angriffsfläche, die APIs. Einmal ein Beispiel: Ich habe das bestgeschützte Unternehmensnetzwerk mit zentralen IT-Security-Komponenten. Ich habe nur einen IoT-Device darin, eine SIM-Karte, was in meinem Unternehmensnetzwerk drin ist, und dieses eine Device ist in das Internet exposed und schon kann ich bei einer API-Endpoint-Vulnerability auf das eine Device zugreifen und bin im kompletten Unternehmensnetzwerk drin. Dann ist natürlich Feierabend. Was die Zero Trust Architecture Prinzipien auch sagen, ist, wir vertrauen nicht dem eigenen Unternehmensnetzwerk.

Jede Ressource in dem Unternehmensnetzwerk muss in der Lage sein, Anfragen, ob aus dem Internet, von außen oder innerhalb des Unternehmensnetzwerks anfangen zu überprüfen, wer ist das und ist der autorisiert. Das hat natürlich sehr viel mit Cyber-Risk und diesen Sachen zu tun. Diese Grundgedanken sind auch Ideen von Gaia-X, Catena-X und Co. Das Thema Zero Trust Architectures ist da zentraler Bestandteil. 51:57

 

Ansgar Knipschild: Super. Carsten, vielen Dank für diesen kleinen Ausflug in den Maschinenraum, der gezeigt hat, dass auch auf dieser Ebene Schnittstellen-APIs noch einiges zu tun ist. Wir haben damit gute Grundlagen gelegt für unseren zweiten Teil. Wir haben heute ein bisschen die Grundkonzepte kennengelernt rund um digitale Identitäten, ID-Zentralität und zum Schluss den Blick auf die APIs. Wir machen jetzt den Break vom ersten Teil unseres Podcasts. Wir machen beim nächsten Mal mit dem Thema Identitäten und Ökosysteme weiter. Du hast an einigen Stellen schon ein paar Stichworte gegeben. Es bleibt mir nur, noch einmal vielen Dank für dieses spannende Gespräch zu sagen. Ich glaube, dass unsere Zuschauer und ich in der letzten knappen Stunde eine Menge gelernt haben. Noch einmal vielen, lieben Dank, Carsten, an dich und ich sage einmal bis demnächst. 52:40

 

Carsten Stöcker: Ansgar, danke dir für die Einladung, es hat mir Spaß gemacht und bis zum zweiten Teil.

 

Ansgar Knipschild: Super. Vielen Dank, Carsten. Mach es gut. Ciao.

 

Carsten Stöcker: Ciao.