Meine Gedanken zum Endpoint - Schutz

 Endpunkte sind alle Elemente eines IIoT-Systems, die sowohl Rechen- als auch Kommunikationsfähigkeiten haben und funktionale Fähigkeiten zur Verfügung stellen. Dabei kann es sich um Edge-Geräte, Kommunikationsinftastruktur, Cloud-Server oder irgendwas dazwischen handeln. 

Jeder Endpunkt hat unterschiedliche Anforderungen und Hardware-Einschränkungen, die sich auf das erreichbare Schutzniveau auswirken. Die Sicherheitsmechanismen und- Techniken sollten auf die Endpunkte je nach ihren spezifischen Funktion und ihren Sicherheitsanforderungen angewendet werden.

Endpoint Protection stellt die Verfügbarkeit, Vertraulichkeit und Integrität der vom Endgerät ausgeführten Funktionen sicher.

Die Endpoint Protection sollte mindestens diese Sicherheitsfunktionen berücksichtigen:

Endpoint Physical Security bietet physischen Schutz des Endpunkts mit Mechanismen zum Schutz vor Manipulationen und Diebstahl, um unkontrollierte Änderungen oder das Entfernen des Endpunkts zu verhindern.

Endpoint Root of Trust bietet eine Grundlage für die Sicherung anderer Funktionen am Endpunkt, von der Hardware bis hin zu Anwendungen einschließlich Firmware, Virtualisierungsschicht , Betreibssystem, Ausführungsumgebung und Anwendung. Außerdem bietet sie Vertrauen in die Identität des Endpunkts.

Die Identität eines Endpunkt basiert auf den inhärenten Eigenschaften eines Endpunkts, die ihn von anderen Endpunkten unterscheiden. Die Identität muss mit Beweisen oder Zeugnissen untermauert werden, die die Identitätsbehauptung bestätigen und als Referenzen bezeichnet werden.

Endpoint Integrity Protection stellt sicher, dass sich der Endpunkt in der Konfiguration befindet, die für eine vorhersehbare Ausführung seiner Funktionen erforderlich ist.

Die Endpoint Access Control stellt sicher, dass eine ordnungsgemäße Identifizierung , Authentifizierung und Autorisierung durchgeführt wird, bevor Ressourcen oder Dienste gewährt werden.

Endpoint Secure Configuration and Management steuert die Aktualisierung von Sicherheitsrichtlinien und- Konfigurationen auf dem Endgerät, einschließlich Upgrades und Patches für bekannte Sicherheitslücken.

Die Überwachung und Analyse von Endgeräten umfasst Integritätsprüfungen, die Erkennung von bösartigen Nutzungsmustern, Denial-of-Service-Aktivitäten, die Durchsetzung von Sicherheitsrichtlinien und Analysen, die Sicherheitsleistungsindikatoren verfolgen.

Endpoint Data Protection bietet Kontrollen zum Schutz der Integrität, Vertraulichkeit und Verfügbarkeit der Daten.

Endpoint Security Model and Policy regelt die Implementierung von Sicherheitsfunktionen auf dem Endpunkt.

Sicherheitsbedrohungen und Schwachstellen auf Endgeräten

Endgeräte haben viele potenzielle Schwachstelle, die für böswillige oder unbeabsichtigte Fehler anfällig sind.

Wie in der Abbildung dargestellt gibt es in jedem der folgenden Bereiche ein breites Spektrum an Bedrohungen und Schwachstellen in verschiedenen Aspekten der Endgeräte.

1 => Änderungen an Hardwarekomponenten und Konfiguration

Die Integrität der Hardware muss während des gesamten Lebenszyklus des Endgeräts gewährleistet sein, um unkontrollierte Änderungen an den Hardwarekomponenten zu verhindern. Eine mögliche Schwachstelle der Hardware ist die Aneignung eines Teils der Hardwareressourcen. Der Endpunkt muss in der Lage sein, sich vor unbefugtem Zugriff und der Vereinnahmung von Schlüsselressourcen wie Speicher, Verarbeitungszyklen und privilegierten Verarbeitungsmodi zu schützen.

2,3 => Abfangen oder Überschreiben des System-Boot-Prozesses

Der Endpunkt-Boot-Prozess kann durch Änderung der Firmware-Schnittstelle zwischen der Hardware-Plattform-Firmware und dem Betriebssystem, wie z. B. dem Unified Extensible Firmware Interface (UEFI) oder dem Basic Input/Output System (BIOS), verändert werden. Änderungen an den Bootloads sind eine weitere Bedrohung, da sie die Integrität des Endgeräts gefährden könnten, indem sie nicht autorisierte oder unsichere Versionen des Betriebssystems starten. Angriffe auf dieser Ebene könnten auch den normalen oder sicheren Startvorgang des Endgeräts, die Erkennung aller Hardwareressourcen und die Schaffung einer soliden Vertrauensbasis für die Sicherung anderer Komponenten beeinträchtigen.

4,5 => Kompromisse bei Gastbetriebssystemen, Hypervisoren und Separationskerneln:

Diese Softwareschichten steuern die Zuweisung von Hardwareressourcen an Anwendungen. Angriffe auf diese Schichten können das Verhalten des Systems verändern, die Umgehung von Sicherheitskontrollen durch Informationsflüsse ermöglichen, das Verhalten des Systems verändern, die Umgehung von Sicherheitskontrollen durch Informationsflüsse ermöglichen und Angreifern einen privilegierten Zugriff auf Hardware- und Softwareressourcen von Endgeräten ermöglichen. Sobald der Angreifer Zugang zu dieser Ebene erlangt hat, hat er die Möglichkeit, den gesamten Software-Stack zu beeinflussen und die auf dieser Ebene eingebauten Sicherheitskontrollen weiter zu verändern.

7,8,9 => Unerlaubte Änderungen an der Anwendungssoftware oder der offengelegten Anwendungsprogrammierschnittstelle (API)

Endpunktanwendungen sind häufig das Ziel von Malware oder eines Angreifers, der versucht, den Endpunkt zu infiltrieren und zu kompromittieren. Die Ausführung bösartiger Anwendungen oder das Überschreiben von Anwendungs-APIs kann sich negativ auf die Vertrauenswürdigkeit des Endpunkts auswirken. Offengelegte APIs sollten auch gegen Denial-of-Service-Angriffe geschützt werden, bei denen der ständige Zugriff von nicht autorisierten Benutzern die Reaktionsfähigkeit und den Zugriff auf die offengelegten Funktionen einschränken könnte.

10 => Schwachstellen des Verteilungsprozesses

Fehler und potenzieller bösartiger Code können auch als Teil des Bereitstellungsprozesses in den Endpunkt eindringen, z. B. durch falsche oder bösartige Installationsskripte, abgefangene Kommunikation oder nicht autorisierte Ersetzung eines Pakets auf dem Update-Server. Die Verringerung möglicher Endpunktkonfigurationen bei umfangreichen Endpunktbereitstellungen ist wichtig, um die Komplexität und die Schwachstellen im Bereitstellungsprozess zu reduzieren.

11 => Unerwünschte Änderungen an Endpunktdaten

Daten auf dem gesamten Endpunkt, von der Low-Level-Firmware bis hinauf zum Software-Stack, stellen einen wichtigen Bereich für Schwachstellen dar. Zu diesen Schwachstellen gehört der unbefugte Zugriff auf unternehmenskritische oder private Daten. Angreifer können das Verhalten des Systems durch Einspeisung falscher Daten beeinträchtigen. Denial-of-Service-Angriffe auf den Datenzugriff können die rechtzeitige und genaue Ausführung der Endpunktfunktionalität behindern, was zu kostspieligen Ergebnissen führt.

12 => Verstoß gegen das Überwachungs- und Analysesystem

Ein Angreifer könnte sich Einblick in die Funktionen des überwachten Systems verschaffen. Beispielsweise könnte ein Angreifer Überwachungsdaten so verändern, dass es so aussieht, als ob ein bestimmtes Ereignis nicht eingetreten wäre. Die Modifizierung der Sicherheitsprotokolle und Überwachungsdaten kann zu unentdeckten Schwachstellen oder gefährdeten Zuständen führen. Infolgedessen würden Angreifer von einer Abdeckungslücke profitieren, indem sie die Hardware und Software von Endgeräten kompromittieren oder nach einem Angriff Beweise für ihre Aktivitäten vernichten.

13 => Schwachstellen in Konfiguration und Management

Eine Schwachstelle im Konfigurations- und Verwaltungssystem kann durch eine unsachgemäße Zugriffskontrolle auf das Konfigurationsverwaltungssystem, das Einfügen nicht autorisierter Änderungen in das System oder die Beschädigung von Aktualisierungsnutzdaten entstehen. Aktualisierungen der Endgeräte sollten so geplant und verwaltet werden, dass die Zahl der verschiedenen Betriebskonfigurationen begrenzt und die Fragmentierung der Flotte verringert wird.

14 => Unkontrollierte Änderungen der Sicherheitspolicy und des Modells

Änderungen der Sicherheitspolitik und der abgeleiteten Sicherheitsmodelle stellen eine ernsthafte Bedrohung für das System und seine Endpunkte dar. Ebenso sind Schwachstellen in der Sicherheitspolitik ein Bereich, der von potenziellen Angreifern ausgenutzt werden kann.

15 => Schwachstellen in der Entwicklungsumgebung

Die Einführung von Schwachstellen während des Lebenszyklus der Softwareentwicklung kann die IIoT-Systeme anfällig für Angriffe machen. Diese Schwachstellen können während der Architektur, des Entwurfs oder des Schreibens des Codes eingeführt werden. Die Verwendung anfälliger oder bösartiger Bibliotheken oder nicht vertrauenswürdiger Entwicklungs-Frameworks kann dazu führen, dass sie in den resultierenden Code des IIoT-Systems aufgenommen werden.

Meine Gedanken zum Security Framework

Industrielle Internet-of-Things-Systeme (IIoT) verbinden und integrieren verschiedene Arten von Steuerungssystemen und Sensoren mit Unternehmenssystemen, Geschäftsprozessen, Analysen und Menschen. Diese Systeme unterscheiden sich von herkömmlichen industriellen Steuerungssystemen, indem sie umfassend mit anderen Systemen und Menschen verbunden sind und so die Vielfalt und den Umfang der Systeme erhöhen.

In der Vergangenheit beruhte die Sicherheit vertrauenswürdiger Industriesysteme auf der physischen Trennung und Netzwerkisolierung anfälliger Komponenten sowie auf der Unklarheit der Entwurfs- und Zugangsregeln für kritische Kontrollsysteme. In den letzten Jahrzehnten haben die zunehmend erschwingliche Rechenleistung, die allgegenwärtige Konnektivtät und die sich entwickelnden Datenanalysetechniken die Tür zur Konvergenz von Kontrollsystemen, Geschäftssystemen und dem Internet geöffnet.  Diese Konvergenz begann im kleinen und wurde zunächst für die Fernüberwachung und -Verwaltung von Systemen genutzt, weitete sich aber schnell auf die Auswertung und Analyse von Betriebsdaten für Leistungskennzahlen zur Vorhersage von Ausfällen, die Optimierung von Flotten und die Durchführung von Software-Upgrades aus der Ferne aus. Diese Konvergenz hat die Produktivität, Effizienz und Leistung der bestehenden Betriebsprozesse erhöht und die Schaffung neuer Möglichkeiten zur Nutzung von Betriebsdaten ermöglicht, wodurch jetzt und in Zukunft ein Mehrwert für das Unternehmen entsteht.

Doch mit diesen Gewinnen sind auch Risiken verbunden. Unternehmen müssen diese Risiken ernst nehmen; um ihr IIoT-System vertrauenswürdig zu machen. Der Einsatz von Sensoren und Aktoren in einer industriellen Umgebung ist keine typische IT-Erfahrung , ebenso wenig wie Systeme, die viele Organisationen und Organisationssysteme umfassen. IT und OT priorisieren die Systemeigenschaften unterschiedlich. So ist beispielsweise die Ausfallsicherheit in der IT weniger wichtig als in der OT, und die Sicherheit ist in der OT weniger wichtig als in der IT wie in der Abbildung dargestellt.

Ein System der Industrie der Dinge (IIoT) weist durchgängige Merkmale auf, die sich aus den Eigenschaften seiner verschiedenen Komponenten und der Art ihrer Interaktionen ergeben. Die fünf Merkmale, die sich am stärksten auf die Vertrauensentscheidungen eines IIoT-Einsatzes auswirken, sind Sicherheit , Zuverlässigkeit, Widerstandsfähigkeit und Datenschutz. Diese werden als zentrale Systemmerkmale bezeichnet. Andere , z.B. Skalierbarkeit, Benutzerfreudnlichkeit, Wartungsfreundlichkeit, Übertragbarkeit oder Zusammensetzbarkeit, können im Allgemeine ebenfalls wichtig sein.

Durchgängige Sicherheit bei IIoT-Systemen

Die Implementierung eines Systems für das industrielle Internet der Dinge (IIoT) muss eine durchgängige Sicherheit vom Rand bis zur Cloud bieten. Dazu gehören die Härtung von Endgeräten, der Schutz der Kommunikation, die Verwaltung und Kontrolle von Richtlinien und Updates sowie die Nutzung von Analysen und Fernzugriff zur Verwaltung und Überwachung des gesamten Sicherheitsprozess.

Die Sicherheit von IIoT-Systemen sollte sich so weit wie möglich auf Automatisierung stützen, aber Menschen müssen in der Lage sein, mit der Sicherheitsimplementierung zu interagieren, um den Status zu überwachen, Analysen zu überprüfen, bei Bedarf Entscheidungen zu treffen und Änderungen und Verbesserungen zu planen. Brauchbare Verwaltungs- und Kontrollsysteme können zur Sicherheit beitragen, indem sie Bedienerfehler reduzieren.

Bausteine der Sicherheit

Die funktionale Sichtweise des Sicherheitrahmens umfasst sechs interagierende Bausteine. Sie sind in drei Schichten organisiert. Die oberste Schicht umfasst die vier zentralen Sicherheitsfunktionen:

Endpunktschutz

Schutz der Kommunikation und Konnektivität

Sicherheitsüberwachung und -Analyse

Verwaltung der Sicherheitskonfiguration

Diese vier Funktionen werden durch eine Datenschutzschicht und eine systemweite Sicherheitsmodell- und Richtlinienschicht unterstützt.

Diese drei Schichten bilden die funktionale Sichtweise des Sicherheitsrahmens für das industrielle Internet.

Der Endpunktschutz implementiert Verteidigungsfunktionen auf Geräten am Netzwerkrand und in der Cloud. Zu den Hauptanliegen gehören physische Sicherheitsfunktionen, Cybersicherheitstechniken und eine zuverlässige Identität. Endpunktschutz allein reicht nicht aus, da die Endpunkte miteinander kommunizieren müssen und die Kommunikation eine Quelle der Anfälligkeit sein kann.

Der Kommunikations- und Konnektivitätsschutz nutzt die autorisierende Identitätsfunktion des Endpunktschutzes, um die Authentifizierung und Autorisierung des Datenverkehrs zu Implementierung.

Kryptographische Techniken für Integrität und Vertaulichkeit sowie Techniken zur Kontrolle des Informationsflusses schützen die Kommunikation und Konnektivität.

Sobald die Endpunkte geschützt sind und die Kommunikation gesichert ist, muss der Systemzustand während des gesamten Betriebslebenszyklus durch Sicherheitsüberwachung und -Analyse und kontrolliertes Sicherheitskonfigurationsmanagement für alle Systemkomponenten aufrechterhalten werden.

Diese ersten vier Bausteine werden durch eine gemeinsame Datenschutzfunktion unterstützt, die sich von den ruhenden Daten in den Endpunkten bis zu den bewegten Daten in der Kommunikation erstreckt und auch alle im Rahmen der Überwachungs- und Analysefunktion gesammelten Daten sowie alle Systemkonfigurations- und Verwaltungsdaten umfasst.

Sicherheitsmodell und -Governance regeln, wie die Sicherheit impementiert wird, und die Richtlinien , die die Vertraulichkeit, Integrität und Verfügbarkeit des Systems während seines gesamten Lebenszyklus gewährleisten. Es regelt , wie alle Funktionselemente zusammenarbeiten , um eine durgängige Sicherheit zu gewährleisten.

In weiteren Blogs werde ich die verschiedenen Bausteine und ihr Zusammenspiel genauer beschreiben.

Meine Gedanken zur Event based Architektur

 Wie in so vielen Dingen ist die Natur ein großartiger Architekt und hat sich diese Konzepte ausgedacht, lange bevor Entwickler und Architekten überhaupt daran gedacht haben.

Spinnen nutzen seit Jahrtausenden erfolgreich ereignisbasierte Konzepte. Ereignisgesteuerte Architekturen bieten die Möglichkeit, hocheffizient und in Echtzeit über relevante Änderungen informiert zu werden und darauf zu reagieren.

Die meisten Spinnen sind sehr effiziente Räuber. Sie setzen eine Vielzahl von Strategien ein, um Beute zu fangen. Die häufigste ist das verwenden klebriger Netze. Die Methode des klebrigen Netzes zum Fangen von Beute ist diejenige, an der wir hier interessiert sind.

Nachdem die Spinne ihr Netz gesponnen hat, wartet sie darauf, dass sich die Beute darin verfängt. Die Spinne spürt den Aufprall und den Kampf eines Beutetiers durch Vibrationen, die durch das Netz übertragen werden. Nachdem sie eine Vibration wahrgenommen hat, bewertet die Spinne , ob die Vibrationen von einem Beutetier oder von etwas anderem verursacht wird, das die Spinne nicht interessier, wie z.B. ein Blatt. Wenn sich ein Blatt in einem Spinnennetz verfängt , ignoriert die Spinne diese Veränderung in ihrem Netz einfach. Wenn jedoch ein Beutetier 

Die Beute oder das Blatt im Netz ist ein Ereignis - eine bedeutende Veränderung des Zustands des Spinnennetzes.

Das Spinnennetz ist der Even-Broker, der Ereignisse über die Schwingungen des Netzes transportiert.

Die Spinne ist der Event-Consumer. Sie wird über wesentliche Änderungen des Netzstatus informiert und reagiert entsprechend den erhaltenen Informationen.

Nun zu den Bausteine Event based Architektur

Eine Event based Architecture ist eine Softwarearchitektur, die Ereignisse als zentrales Mittel für die Interaktion zwischen ihren Softkomponenten verwendet. Die umfasst die Erfassung, Kommunikation, Verarbeitung und Persistenz von Ereignissen. Bei Softwarekomponenten in ereignisgesteuerten Architekturen handelt es sich in der Regel um Microservices, aber es können auch andere arten von Software-Systemen das ist der Vorteil der event-based Architektur.

Ereignisgesteuerte Architekturen stellen einen architektonischen Ansatz dar und basieren. Nicht auf einer bestimmten Programiersprachen. Tatsächlich kann eine ereignisgesteuerte Architektur in fast jeder modernen Programmiersprache erstellt werden. Ereignisgesteuerte Architekturen eignen isch hervorragend für verteilte Softwareumgebungen und ermöglichen eine minimale Kopplung. Diese natürliche Verbreitung von ereignisgesteuerten Architekturen wird noch dadurch verstärkt, dass ein Ereignis - eine signifikante Änderung - fast alles sein kann. Daraus ergibt sich eine große Anzahl von möglichen Ereignisquellen.

Komponenten von ereignisgesteuerten Architekturen

Ereignisgesteuerte Architekturen bestehen aus einer sehr begrenzten Anzahl von Architekturkomponenten wie folgt:

Event producer

Der Eignisproduzent ist die Quelle des Ereignisses und sendet das Ereignis aus, um anzuzeigen , dass es eingetreten ist. Der Ereignisproduzent weiß nur, dass das Ereignis eingetreten ist; er weiß nicht, wer sich für das Ereignis interessiert oder wie die interessierten Parteien auf die Information über das Ereignis reagieren werden.

Event broker

Der Ereignisbroker ist ein Vermittler, der Ereignisse vermittelt und verwaltet. Wenn man es mit den Definitionen sehr genau nimmt, kann der Broker sogar als optional betrachtet werden, wenn der Produzent ein. Ereignis-Broker eingesetzt werden.

Event consumer

Ereigniskonsumenten sind Softwarekomponenten, die wissen müssen, dass ein Ereignis eingetreten ist, und sich in der Regel beim Ereignisbroker anmelden, um über Ereignisse informiert zu werden.

Die Kombination dieser begrenzten Anzahl von Komponenten kann zu hochkomplexes und leistungsfähigen Architekturen führen, die sich durch extreme Skalierbarkeit und Flexibilität auszeichnen.

Daten und Events oder Events und Daten?

Früher gab es einen klaren Fokus auf Daten, z.B. zunächst in Backend-Systemen und später in Data Lakes. Die Quelle der Wahrheit war klar: Die Daten standen im Vordergrund, und die Landschaften und Systeme folgten einem datenorierten Modell. Im Rahmen dieses Modells wurden Teilmengen von Daten gesammelt, gespeichert und so effizient wie möglich abgerufen.

Mit dem Aufkommen der ereignisgesteuerten Architekturen hat sich der Schwerpunkt von Daten auf Ereignisse verlagert. Die Frage ist nun, wie weit diese Verlagerung gehen soll. Einige sagen, dass jetzt Ereignisse am wichtigsten sind und dass die Quelle der Wahrheit in erster Linie aus Ereignissen besteht, während Daten nur die zweite Quelle sind. Es gibt zwei Schulen von ereignisgesteuerten Architekturen: die ereignisprotokollbasierten Architekturen, die bis zu einem gewissen Grad Ereignisse an die erste und Daten an die zweite Stelle setzen , und die ereignisbrokerbasierten Architekturen, die immer noch Daten an die erste und Ereignisse an die zweite Stelle setzen.

Diese beiden Ansätze beruhen auf zwei unterschiedlichen Mechanismen, nämlich Pub/Sub und Event Streaming :

Ereignis-Broker-basiertes Messaging 

Dieser Ansatz stützt sich auf ein Veröffentlichungs- und Abonnementkonzept (Pub/Sub) , das auf Abbonnements beim Ereignisbroker aufbaut. Nachdem ein Ereignis eingetreten ist, wird es veröffentlicht, und die Abonnenten werden benachrichtigt. Ein Ereignisbroker übernimmt die Rolle des Vermittlers, führt aber kein Protokoll.

Nachdem das Ereigniss konsumiert wurde, gibt es in der Regel keine Möglichkeit, das Ereignis erneut abzuspielen. Die Quelle der Wahrheit sind bei diesem Ansatz also immer noch die Daten. Ereignisse können als Echtzeit-Auslöser für die Druchführung von Aktionen mit den Daten betrachtet werden. Bei diesem Ansatz sind sowohl Benachrichtigugnsereignisse als auch Datenereignisse möglich, wenn man es genau nimmt.

Ereignisprotokoll-basiertes Messaging

Dieser Ansatz stützt sich auf ein Ereignisprotokoll und schreibt alle auftretenden Ereignisse in dieses Protokoll. Die Ereignisse werden in der Regel für einen bestimmten Zeitraum im Ereignisprotokoll gespeichert.

Ereignisprotokoll ermöglichten es Ihnen, Ereignisse auszuspielen, um den Zustand Ihrer Anwendung anhand der protokollierten Ereignisse zu reproduzieren. Dies wird als Ereignisprotokollierung bezeichnet, wenn Sie nur Ereignisse protokollieren, oder als Event Sourcing, wenn Sie in der Lage sind, den Zustand der Anwendung aus diesen protokollierten Ereignisse zu reproduzieren. Bei diesem Ansatz gilt also: Ereignisse vor Daten . Die Ereignisse sind die Quelle der Wahrheit. Ereignisse müssen bei diesem Ansatz als relevanten Daten enthalten und daher Datenereignisse sein.

Bei den Daten und Ereignissen gibt es einen höchst interessanten Unterschied in Bezug auf das Alter. Daten altern gut, aber Ereignisse nicht. Das bedeutet, dass auch alte Daten immer noch die Quelle der Wahrheit sind, so dass die höchste Priorität darin besteht, keine Daten zu verlieren. So ist beispielsweise die Adresse eines Geschäftspartners , die vor Jahrzehnten in ein ERP-System eingegeben wurde, immer noch gültig , sofern sie nicht aktualisiert wurde. Bei Ereignissen ist das anders. Je jünger ein Ereignis ist, desto wertvoller ist es; je älter es wird, desto weniger Wert hat es. Bei ereignisgesteuerten Architekturen geht es in erster Linie darum, so schnell wie möglich auf Ereignisse zu reagieren. Dies gilt sowohl für Ereignisbroker als auch für eriegnissprotokollbasierte Ansätze.

Vorteile und Herausforderungen der ereignisgesteuerten Architektur

Vorteile:

Lose Kopplung

Extreme Skalierung und hoher Durchsatz

Inkrementelles Wachstum

Fehlertoleranz

Erkenntnisse in (real)Echtzeit

Geringe Latenz

Effiziente Abläufe

Vorhersage

Herausforderungen

Überwachung und Verständnis

Verfolgung und Fehlersuche

Maskierung von Fehlern

Sicherheit der Daten

Zentraler Ereignisbroker

Synchrone Abfrage