TOP
SSV Software Systems Register  Register
Log in to check your private messages  Log in to check your private messages
Startseite FAQ Search Mitglieder Profile  Log in 
SSV Support-Forum
Common IoT Application Architecture (CIAA) …

 
Post new topic   Reply to topic    SSV-Forum Forum Index >>> RMG/941
<<< Previous topic - Next topic >>>  
Display posts from previous:   
Author Message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 17.12.2022, 21:19    Post subject: Common IoT Application Architecture (CIAA) … Reply with quote

Hallo Forum.

Viele IoT-Anwendungen sind ursprünglich aus einem Proof of Concept (PoC) entstanden und wurden solange verändert, bis ein gewisser Grad an Praxistauglichkeit und Anwendernutzen existierte. In diesem Zustand werden sie nun genutzt und auf Grund veränderter Kundenanforderungen ständig weiterentwickelt. Die Folge dieser Vorgehensweise ist vielfach eine relativ schlechte Dokumentation der Gesamtzusammenhänge. Das macht sich häufig erst bemerkbar, wenn auf Grund zunehmender Cybergefahren die Schwachstellen und Risiken einer bestimmten Anwendung systematisch analysiert werden sollen, zum Beispiel im Rahmen einer Bedrohungsanalyse bzw. Bedrohungsmodellierung (also bei einem „Cyber Threat Modeling” – solche Aktivitäten sollen Schwachstellen aufzeigen und die Entwicklung geeigneter Gegenmaßnahmen bewirken).

Um das Threat Modeling für IoT-Anwendungen zu vereinfachen und eine Lernkurve für wirkungsvolle Gegenmaßnahmen zu ermöglichen, haben wir die Common IoT Application Architecture (CIAA) entwickelt. Es gibt zwar bereits zahlreiche Definitionen und Beschreibungen zum Thema „Anwendungsarchitekturen im Internet der Dinge“ usw. Sie wurden allerdings aus völlig unterschiedlichen Gründen entworfen. Bei der CIAA geht es primär um eine Optimierung der Cybersecurity durch eine wirkungsvolles Bedrohungsmodellierung bzw. Bedrohungsanalyse.

Die folgende Abbildung visualisiert die einzelnen Bausteine und Verbindungen der CIAA-IoT-Anwendungssicht (sie bildet das CIAA-Template). Die gesamte Applikation wird als End-to-End-Lösung dargestellt. Links unten ist ein Device-Endpunkt (IoT Device), rechts der Web Client eines menschlichen Nutzers (User) oder eine andere IT-Anwendung zu finden. Zwischen diesen beiden Punkten sind eine validierbare Authentizität bzw. Datenintegrität sowie eine kontextbezogene Vertraulichkeit erforderlich.



IoT Device: Sensoren, die Daten erfassen und Aktoren, die Aktionen ausführen (beispielsweise ein Ventil schließen oder öffnen, um den Durchfluss einer Flüssigkeit zu steuern).

Device Hub: Kommunikations- und Datentechnisch der Knotenpunkt für die Verbindungen zu den einzelnen Sensoren und Aktoren.

Device Logic: Laufzeitumgebung mit Softwarefunktionen, um den Datenfluss zwischen den Sensoren und Aktoren sowie übergeordneten Datenbankfunktionen zu ermöglichen.

Database: Sammelbegriff für die Speicherfunktionen einer IoT-Applikation. Die jeweiligen Implementierungsdetails der Datenbankfunktionen werden durch die individuellen Anforderungen bestimmt.

Business Logic: Laufzeitumgebung mit Softwarefunktionen, um den Datenfluss zwischen den externen Nutzern und Anwendungen sowie den Datenbankfunktionen einer IoT-Anwendung zu ermöglichen.

Web Server: Kommunikations- und Datentechnisch der Knotenpunkt für die Verbindungen zu den externen Nutzern und weiteren Anwendungen.

Web Client: Benutzer und weitere Anwendungen, die sich einer bestimmten IoT-Anwendung zuordnen lassen. Sie sind in der Regel die Datenkonsumenten, allerdings vielfach auch Datenquellen (z. B. neue Firmware-Dateien eines Softwareentwicklers für die Over-the-Air (OTA)-Updates der IoT Devices).

VG KDW


Last edited by kdw on 18.12.2022, 17:34; edited 3 times in total
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 18.12.2022, 14:50    Post subject: Wie wird das CIAA-Leitbild angewendet? Reply with quote

Hallo Forum.

Am Anfang einer Bedrohungsmodellierung bzw. Bedrohungsanalyse stehen die alternativen Fragestellungen „Was wurde entwickelt?“ (falls die Bedrohungsanalyse nachträglich erfolgt) bzw. „Was wird entwickelt?“ (wenn eine Bedrohungsanalyse bereits im Vorfeld oder parallel zu einem Entwicklungsvorhaben durchgeführt wird). Zielführend mit Blick auf eine Bedrohungsanalyse ist, die einzelnen (Teil-) Anwendungen zu betrachten und eine Grobbeschreibung mit Skizzen anzufertigen, in denen die wichtigsten Funktionsbausteine und deren Beziehungen untereinander erkennbar sind. Vernetzte IT-Applikationen bestehen häufig aus einem Datenerfassungs- und einem Datennutzungsteil. Vielfach gibt es darüber hinaus noch weitere Aufgaben (beispielsweise „Konfigurationsdatenänderungen“). Zu jeder Einzelaufgabe gehören wichtige Bausteine, die untereinander Daten austauschen.

Für die CIAA-Anwendung auf eine reale IoT-Applikation wird das zuvor beschriebene Modell als Template betrachtet. Der CIAA-Einsatz besteht darin, alle Funktionsbausteine aus der Grobbeschreibung mit den Skizzen inklusive der Kommunikationsbeziehungen untereinander auf das CIAA-Modelltemplate zu mappen. In dem dabei entstehen Gesamtbild lassen sich auch die unterschiedlichen Betriebsorte zu den Einzelfunktionen kennzeichnen (siehe z. B. Umrahmung mit der roten gestrichelten Linie in der folgenden Abbildung). Für die weiteren Schritte der Bedrohungsanalyse ist die Kenntnis zu den Besonderheiten der Standorte sowie die Abgrenzung dieser Orte untereinander von großer Bedeutung.



Das CIAA-Bild einer Anwendung soll für alle Beteiligte eine möglich einfach verständliche Sicht der Zusammenhänge zum Daten- und Informationsfluss zwischen den einzelnen Bausteinen ergeben und im nächsten Schritt einer Bedrohungsanalyse als Vorlage für das Datenflussdiagramm (DFD) dienen. Beim Betrachten einer solchen Abbildung lassen sich darüber hinaus auch ohne umfangreiches Expertenwissen allgemeinverständliche erste Fragestellungen zu möglichen IT-Sicherheits-Angriffsszenarien formulieren. Zum Beispiel:

1) Was passiert, wenn jemand einzelne Daten in der Datenbank des digitalen Zwillings verändert?

2) Wird der Web Client (Webbrowser) wirklich von der Person benutzt, für die sie sich ausgibt?

3) Wie problematisch ist es, dass zwischen den einzelnen Funktionsbausteinen unverschlüsselte Daten übertragen werden?

VG KDW
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 19.12.2022, 12:36    Post subject: Wie könnte eine Beispielanwendung aussehen? Reply with quote

Hallo Forum.

Stellen wir uns einfach mal eine industrielle IoT-Anwendung vor, die mit Hilfe eines digitalen Zwillings den Betrieb sowie die Service- und Wartungsaufgaben von Maschinen und Anlagen optimieren soll. Siehe hierzu auch https://www.ssv-comm.de/forum/viewtopic.php?t=1596 (Intelligenter Service-assistent für Maschinen und Anlagen).



Die IoT Device für dieses Beispiel wird durch ein Edge Gateway realisiert, das zum einen mit der Datenschnittstelle einer Maschinensteuerung verbunden ist und zum anderen über externe Sensoren mit zusätzlichen Live-Daten versorgt wird. Dieses Edge Gateway liefert periodisch vorverarbeitete Zustandsdaten an einen MQTT Broker im Internet, der den Device Hub bildet. Alle eintreffenden Daten werden von einem Softwaremodul, der in einer Python-Laufzeitumgebung (Device Logic) ausgeführt wird, in eine Datenbank (Database) geschrieben. Sie dient als virtuelles Datenabbild der Maschine bzw. Anlage.

Auf der gegenüberliegenden Seite des CIAA-Templates kann sich ein PC oder ein Smartphone jederzeit per Internet als Web Client mit dem Web Server der IoT-Anwendung verbinden. Durch die Client-Authentifizierung lässt sich feststellen, welche Maschine und somit welcher digitale Zwilling bzw. welche Datenbank mit dem Web Client verknüpft und somit für die Sitzung zu benutzen ist. Über anwendungsbezogene WSGI-Softwarefunktionen (WSGI = Web Server Gateway Interface), die in Python erstellt wurden und als Business Logic dienen, kann der Web Server auf die Datenbank des digitalen Zwillings zugreifen und dem Web Client eine Übersicht zum aktuellen Maschinenzustand präsentieren.

Zu den WSGI-Softwarefunktionen gehört auch ein Condition-Monitoring-Baustein (CM Watchdog), der durch einen Zeitgeber periodisch aktiviert wird, um einen Überwachungsdurchlauf auszuführen. Dabei werden Daten zum aktuellen Maschinenzustand mit einem externen Modell abgeglichen und klassifiziert. Falls sich durch diesen Überwachungsprozess relevante Abweichungen ergeben, lassen sich veränderte Sollwerte an die Maschinensteuerung übermitteln.

VG KDW


Last edited by kdw on 20.12.2022, 12:59; edited 1 time in total
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 20.12.2022, 12:58    Post subject: Das Datenflussdiagramm (DFD) … Reply with quote

Hallo Forum.

Zu jeder Bedrohungsanalyse gehört ein Datenflussdiagramm (DFD), aus dem die externen Entitäten, Prozesse, Datenspeicherfunktionen, Daten- und Informationsflüsse sowie Vertrauensgrenzen hervorgehen. Für die DFD-Erstellung existieren verschiedene Symbole und Notationen. In einem SSV-DFD werden Entitäten durch Rechtecke, Prozesse mittels Kreise und Speichersysteme durch zwei waagerechte Linien, die parallel zueinander verlaufen, dargestellt. Im Inneren dieser Symbole ist jeweils eine Beschriftung zu finden. Der Datenfluss wird durch Pfeile gekennzeichnet. Zur Darstellung der Vertrauensgrenzen werden strichpunktierte Linien verwendet. Die folgende Abbildung zeigt ein DFD für die zuvor beschriebene Beispielanwendung mit dem digitalen Zwilling zur Optimierung des Betriebs sowie der Service- und Wartungsaufgaben von Maschinen und Anlagen. Dabei wurde nach den folgenden Regeln vorgegangen:

1) Jeder einzelne Prozess sollte mindestens einen Eingang und einen Ausgang besitzen.

2) Ein Datenspeichersystem muss einen eingehenden und einen ausgehenden Datenfluss haben. In einigen Fällen wird der eingehende Datenpfad aus Vereinfachungsgründen weggelassen (z. B. ein Speicher für statische Webseiten).

3) Daten, die in einer Datenbank gespeichert werden, müssen mindestens einen Prozess durchlaufen.

4) Alle Prozesse eines DFD besitzen einen Datenfluss zu einem anderen Prozess, Datenspeicher oder einer Entität.

5) Daten, die in einem System gespeichert werden, müssen immer einen Prozess durchlaufen.

6) Nur Prozesse verändern Daten, ein Datenspeichersystem hingegen nicht.



Das DFD-Beispiel betrachtet nur eine Teilaufgabe: Eine IoT Device als externe Entität liefert per MQTT-Publish-Operation die Maschinen- und Sensordaten an einen MQTT-Broker-Prozess. Die eintreffenden Daten werden per MQTT-Subscribe (also Ereignisgesteuert) an einen weiteren Prozess (MQTT-2-DB) übermittelt. Dieser bereitet die Daten entsprechend auf und schreibt sie in eine Datenbank (DB).

Auf der gegenüberliegenden Seite kann sich ein Benutzer mit einem PC oder Smartphone als externe Entität jederzeit mit dem Web-Server-Prozess verbinden. Dafür wird das HTTPS-Protokoll verwendet. Zu jeder einzelnen Nutzeraktivität gehört somit ein HTTPS-Request- und eine HTTPS-Response-Operation. Die statischen Komponenten der Webseiten, die dem Nutzer im Rahmen einer Sitzung präsentiert werden, stammen aus einem Datenspeichersystem (Webseiten). Für die dynamischen Inhalte, also z. B. die Daten zum Zustand einer Maschine, wird vom JavaScript-Code einer Webseite der WSGI-Prozess mit den entsprechenden Parametern aufgerufen (WSGI = Web Service Gateway Interface). Dieser Prozess liest die benötigten Daten aus der Datenbank.

Zu den WSGI-Softwarefunktionen gehört auch der Condition-Monitoring-Watchdog (CM Watchdog), der an Hand eines externen Modells (siehe Datenspeicherfunktion „CM Modelle“) den aktuellen Maschinenzustand mit den Daten des digitalen Zwillings überwacht. Falls sich durch die Überwachung neue Sollwerte ergeben, lassen sich diese per MQTT an die IoT Device weiterleiten.

VG KDW
Back to top
View user's profile Send private message
kdw



Joined: 05 May 2006
Posts: 1460

PostPosted: 22.12.2022, 17:43    Post subject: Die Administratoren … Reply with quote

Hallo Forum.

Zu jeder IoT-Anwendung gehört auch mindestens ein Administrator. Häufig sind sogar mehrere Personen mit Sonderrechten für unterschiedliche Teilaufgaben zuständig. Der eine kümmert sich gesamtheitlich um die IoT Devices, ein anderer um die Anwendungssoftware und die Datenbanken in der Cloud, ein dritter um die Serverplattform, auf der die Cloudservices implementiert wurden usw. Auf jeden Fall muss man sich verdeutlichen, dass auch im IoT-Umfeld ein Administrator uneingeschränkte Zugriffsrechte auf alle Teile der Anwendung besitzt und auf Grund seiner Rechte neue Benutzer und Devices anlegen, löschen sowie deren Zugriffsrechte verändern kann. Die folgende Abbildung visualisiert, wie Administratoren in die Common IoT Application Architecture (CIAA) einzuordnen sind.



Aus der Darstellung geht hervor, dass ein Administrator in der Regel nicht die gleichen Benutzerschnittstellen nutzt, die z. B. von einem „normalen User“ beim Zugriff auf die Anwendung verwendet werden. Mögliche Alternativen für den Administrator sind SSH-Client-Verbindungen oder eigene webbasierte Schnittstellen (z. B. das SSV/WebUI), die ausschließlich für Management- und Konfigurationsaufgaben entwickelt wurden und somit außerhalb des Anwendungsfokus liegen.

VG KDW
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    SSV-Forum Forum Index >>> RMG/941 All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

SSV Software Systems GmbH

Dünenweg 5
30419 Hannover

Fon: +49(0)511  ·  40 000-0
Fax: +49(0)511  ·  40 000-40

sales@ssv-embedded.de


Impressum    ·    Datenschutz    ·    AGB

© 2023 SSV SOFTWARE SYSTEMS GmbH. Alle Rechte vorbehalten.

ISO 9001:2015