Freigeben über


Defender for IoT und Ihre Netzwerkarchitektur

Dieser Artikel gehört zu einer Reihe von Artikeln, in denen der Bereitstellungspfad für die OT-Überwachung mit Microsoft Defender for IoT beschrieben wird.

Im Folgenden erfahren Sie mehr über Ihre eigene OT-/IoT-Netzwerkarchitektur. Außerdem wird beschrieben, wo jedes Ihrer Systemelemente in die Ebenen der OT-Netzwerksegmentierung fällt.

Diagramm einer Statusleiste mit hervorgehobenem Text „Planung und Vorbereitung“.

OT-/IoT-Netzwerkebenen

Das Netzwerk Ihrer Organisation besteht aus vielen Gerätetypen, die in die folgenden Hauptgruppen unterteilt werden können:

  • Endpunktgeräte. Diese Geräte können mehrere Untergruppen umfassen, wie Server, Computer und IoT-Geräte (Internet of Things, Internet der Dinge).
  • Netzwerkgeräte. Diese Geräte stellen Netzwerkdienste in der Infrastruktur bereit. Dazu zählen Switches, Firewalls, Router und Zugriffspunkte für das Netzwerk.

Die meisten Netzwerkumgebungen sind mit einem hierarchischen Modell aus drei Ebenen konzipiert. Beispiel:

Ebene BESCHREIBUNG
zugreifen Auf der Zugriffsebene befinden sich die meisten Endpunkte. Diese Endpunkte werden in der Regel von einem Standardgateway und Routing von den oberen Ebenen und häufig von der Verteilungsebene aus bereitgestellt.

* Ein Standardgateway ist ein Netzwerkdienst oder eine Entität innerhalb des lokalen Subnetzes, das dafür zuständig ist, den Datenverkehr außerhalb des LAN oder IP-Segments weiterzuleiten.
Distribution Die Verteilungsebene ist für die Aggregierung mehrerer Zugriffsebenen und die Bereitstellung der Kommunikation an die Kernebene mit Diensten wie VLAN-Routing, Dienstqualität, Netzwerkrichtlinien usw. verantwortlich.
Core Die Kernebene enthält die Hauptserverfarm der Organisation und stellt Hochgeschwindigkeitsdienste mit geringer Latenz über die Verteilungsebene bereit.

Das Purdue-Modell der Netzwerkarchitektur

Das Purdue-Referenzmodell für die ICS-/OT-Netzwerksegmentierung (Industrial Control System, Industriekontrollsystem) definiert sechs weitere Ebenen mit bestimmten Komponenten und relevanten Sicherheitskontrollen für jede Ebene.

Jeder Gerätetyp in Ihrem OT-Netzwerk gehört zu einer bestimmten Ebene des Purdue-Modells, wie in der folgenden Beispielabbildung gezeigt:

Diagramm des Purdue-Modells.

In der folgenden Tabelle werden die einzelnen Ebenen des Purdue-Modells beschrieben, wenn sie auf Geräte angewendet werden, die möglicherweise in Ihrem Netzwerk vorhanden sind:

Name BESCHREIBUNG
Ebene 0: Zelle und Bereich Ebene 0 besteht aus einer Vielzahl von Sensoren, Aktoren und Geräten, die am grundlegenden Fertigungsprozess beteiligt sind. Diese Geräte führen die grundlegenden Funktionen des Industrie-Automatisierungs- und Steuerungssystems aus, wie etwa:

- Steuern eines Motors
- Messen von Variablen
- Festlegen einer Ausgabe
- Ausführen von wichtigen Funktionen wie Lackieren, Schweißen und Biegen
Ebene 1: Prozesssteuerung Ebene 1 besteht aus eingebetteten Controllern, die den Fertigungsprozess steuern und manipulieren, deren Schlüsselfunktion die Kommunikation mit den Geräten der Ebene 0 ist. Bei der diskreten Fertigung stellen diese Geräte programmierbare Logikcontroller (PLCs) oder Remote-Telemetrieeinheiten (RTUs) dar. In der Prozessfertigung wird der grundlegende Controller als Prozessleitsystem (Distributed Control System, DCS) bezeichnet.
Ebene 2: Aufsicht Ebene 2 stellt die Systeme und Funktionen dar, die der Laufzeitüberwachung und dem Betrieb eines Bereichs einer Produktionseinrichtung zugeordnet sind. Dazu gehören normalerweise die Folgenden:

- Operator- oder Mensch-Maschine-Schnittstellen (MMSs)
- Alarme oder Warnsysteme
- Prozessverlauf und Batchverwaltungssysteme
- Arbeitsstationen im Kontrollraum

Dieses Systeme kommunizieren mit den PLCs und RTUs in Ebene 1. In machen Fällen kommunizieren sie oder teilen Daten mit den Systemen und Anwendungen des Standorts oder Unternehmens (Ebene 4 und Ebene 5). Diese Systeme basieren hauptsächlich auf Standard-Computerausrüstung und -Betriebssystemen (Unix oder Microsoft Windows).
Ebenen 3 und 3,5: Umkreisnetzwerk auf Standort- und Fertigungsebene Die Standortebene stellt die höchste Ebene von industriellen Automatisierungs- und Steuerungssystemen dar. Die Systeme und Anwendungen auf dieser Ebene verwalten standortweit die Automatisierungs- und Steuerungsfunktionen der Fertigung. Die Ebenen 0 bis 3 werden als kritisch für den Betrieb von Standorten angesehen. Zu den auf dieser Ebene vorhandenen Systemen können beispielsweise die folgenden gehören:

– Fertigungsberichte (beispielsweise Zykluszeiten, Qualitätsindex, vorausschauende Wartung)
– Standorthistorie
- Detaillierte Produktionsplanung
– Betriebsverwaltung auf Standortebene
– Geräte- und Materialverwaltung
– Patch-Startserver
– Dateiserver
– Fertigungsdomäne, Active Directory, Terminalserver

Diese Systeme kommunizieren mit der Produktionszone und teilen Daten mit den Unternehmenssystemen und -anwendungen (Ebene 4 und Ebene 5).
Ebenen 4 und 5: Geschäfts- und Unternehmensnetzwerke Ebene 4 und Ebene 5 stellen das Standort- oder Unternehmensnetzwerk dar, in dem die zentralen IT-Systeme und -Funktionen betrieben werden. Die IT-Organisation verwaltet auf diesen Ebenen direkt die Dienste, Systeme und Anwendungen.

Platzieren von OT-Sensoren in Ihrem Netzwerk

Wenn Defender for IoT-Netzwerksensoren mit Ihrer Netzwerkinfrastruktur verbunden sind, empfangen sie gespiegelten Datenverkehr, z. B. von SPAN-Ports oder Netzwerk-TAPs. Der Verwaltungsport des Sensors wird mit dem Geschäfts-, Unternehmens- oder Sensorverwaltungsnetzwerk verbunden, wie für die Netzwerkverwaltung über das Azure-Portal.

Beispiel:

Diagramm eines verwalteten Switches mit Portspiegelung.

In der folgenden Abbildung werden demselben Netzwerk wie zuvor beschrieben Defender for IoT-Ressourcen hinzugefügt, darunter ein SPAN-Port, ein Netzwerksensor und Defender for IoT im Azure-Portal.

Diagramm des Purdue-Modells mit Defender for IoT-Komponenten.

Weitere Informationen finden Sie unter Beispiele für OT-Netzwerkkonnektivitätsmodelle.

Identifizieren von interessanten Datenverkehrspunkten

Aus Sicherheitssicht sind in der Regel die Schnittstellen interessant, die eine Verbindung zwischen der Standardgateway-Entität und dem Kern- oder Verteilungsswitch herstellen.

Durch Identifizieren dieser Schnittstellen als interessante Punkte wird sichergestellt, dass Datenverkehr, der von innerhalb des IP-Segments nach außen fließt, überwacht wird. Stellen Sie sicher, dass auch fehlender Datenverkehr berücksichtigt wird, also Datenverkehr, der eigentlich das Segment verlassen sollte, aber dennoch im Segment verbleibt. Weitere Informationen finden Sie unter Datenverkehrsströme in Ihrem Netzwerk.

Wenn Sie eine Defender for IoT-Bereitstellung planen, sollten Sie die folgenden Elemente in Ihrem Netzwerk berücksichtigen:

Aspekt Beschreibung
Spezielle Datenverkehrstypen innerhalb eines Segments Berücksichtigen Sie insbesondere die folgenden Datenverkehrstypen innerhalb eines Netzwerksegments:

Broadcast-/Multicast-Datenverkehr: Datenverkehr, der an eine beliebige Entität im Subnetz gesendet wird.

Mit dem Internet Group Management-Protokoll (IGMP) wird das Snooping in Ihrem Netzwerk konfiguriert, es gibt jedoch keine Garantie, dass Multicast-Datenverkehr an eine bestimmte Entität weitergeleitet wird.

Broadcast- und Multicast-Datenverkehr wird in der Regel an alle Entitäten im lokalen IP-Subnetz gesendet, einschließlich der Standardgateway-Entität, und wird daher ebenfalls abgedeckt und überwacht.

Unicast-Datenverkehr: Datenverkehr, der direkt an das Ziel weitergeleitet wird, ohne die gesamten Subnetzendpunkte zu überschreiten, einschließlich des Standardgateways.

Überwachen Sie den Unicast-Datenverkehr mit Defender for IoT, indem Sie Sensoren direkt auf den Zugriffsswitches platzieren.
Überwachen beider Datenverkehrsströme Beim Streaming von Datenverkehr an Defender for IoT lassen einige Anbieter und Produkte einen Richtungsstrom zu, was zu einer Lücke in Ihren Daten führen kann.

Es empfiehlt sich, beide Richtungen des Datenverkehrs zu überwachen, um Netzwerkkonversationsinformationen über Ihre Subnetze zu erhalten und insgesamt eine bessere Genauigkeit zu erzielen.
Suchen des Standardgateways für ein Subnetz Für jedes interessante Subnetz ist der interessante Punkt jede Verbindung mit der Entität, die als Standardgateway für das Netzwerksubnetz fungiert.

In einigen Fällen gibt es jedoch Datenverkehr innerhalb des Subnetzes, der nicht vom regulären interessanten Punkt überwacht wird. Die Überwachung dieser Art von Datenverkehr, der nicht von der typischen Bereitstellung überwacht wird, ist insbesondere in sensiblen Subnetzen nützlich.
Atypischer Datenverkehr Für die Überwachung des Datenverkehrs, der nicht anderweitig von der typischen Bereitstellung überwacht wird, sind möglicherweise zusätzliche Streamingpunkte und Netzwerklösungen erforderlich, wie z. B. RSPAN und TAP-Geräte für Netzwerke.

Weitere Informationen finden Sie unter Datenverkehrsspiegelungsmethoden für die OT-Überwachung.

Beispieldiagramm für Datenverkehr

Das folgende Diagramm zeigt ein Beispielnetzwerk in einem Gebäude mit drei Etagen. In der ersten und der zweiten Etage befinden sich Endpunkte und Switches, während sich in der dritten Etage außer Endpunkten und Switches zusätzlich Firewalls, Kernswitches, Router und ein Server befinden.

  • Datenverkehr außerhalb des IP-Segments wird durch eine blaue gepunktete Linie dargestellt.

  • Interessanter Datenverkehr ist rot markiert. Dies kennzeichnet die Orte, an denen Netzwerksensoren platziert werden sollten, um diesen interessanten Datenverkehr an Defender for IoT zu streamen.

Diagramm des Datenverkehrs im OT-Beispielnetzwerk.

Datenverkehrsströme in Ihrem Netzwerk

Geräte, die Netzwerkdatenverkehr auslösen, ordnen die konfigurierte Subnetzmaske und IP-Adresse einer Ziel-IP-Adresse zu, um das Ziel des Datenverkehrs anzugeben. Das Ziel des Datenverkehrs ist entweder das Standardgateway oder eine andere Stelle innerhalb des IP-Segments. Diese Zuordnung kann auch einen ARP-Prozess auslösen, um die MAC-Adresse für die Ziel-IP-Adresse zu finden.

Basierend auf den Ergebnissen der Zuordnung verfolgen Geräte ihren Netzwerkdatenverkehr entweder als Datenverkehr innerhalb oder außerhalb des IP-Segments.

Verkehr BESCHREIBUNG Beispiel
Datenverkehr außerhalb des IP-Segments Wenn das Datenverkehrsziel nicht innerhalb des Bereichs der Subnetzmaske gefunden wird, sendet das Endpunktgerät den Datenverkehr an das Standardgateway, das für die Weiterleitung des Datenverkehrsstroms an andere relevante Segmente zuständig ist.

Jeglicher Datenverkehr außerhalb eines IP-Segments wird über ein Standardgateway geleitet, um das Netzwerksegment zu überqueren. Dies ist der erste Hop im Pfad zum Ziel.

Hinweis: Durch Platzieren eines Defender for IoT/OT-Netzwerksensors an diesem Punkt wird sichergestellt, dass der gesamte Datenverkehr, der außerhalb des Segments verläuft, an Defender for IoT gestreamt wird, analysiert wird und untersucht werden kann.
– Ein PC ist mit der IP-Adresse 10.52.2.201 und der Subnetzmaske 255.255.255.0 konfiguriert.

– Der PC löst einen Netzwerkflow zu einem Webserver mit der Ziel-IP-Adresse 10.17.0.88 aus.

– Das Betriebssystem des PCs berechnet die Ziel-IP-Adresse mit dem Bereich der IP-Adressen im Segment, um zu bestimmen, ob der Datenverkehr lokal, innerhalb des Segments oder direkt an die Standardgateway-Entität gesendet werden soll, die die richtige Route zum Ziel finden kann.

– Basierend auf den Berechnungsergebnissen ermittelt das Betriebssystem, dass der Segmentbereich für IP- und Subnetzpeer (10.52.2.17 und 255.255.255.0) 10.52.2.010.52.2.255 lautet.

Die Ergebnisse bedeuten, dass sich der Webserver nicht im selben IP-Segment wie der PC befindet und dass der Datenverkehr an das Standardgateway gesendet werden sollte.
Datenverkehr innerhalb des IP-Segments Wenn das Gerät die Ziel-IP-Adresse innerhalb des Subnetzmaskenbereichs findet, überquert der Datenverkehr nicht das IP-Segment, sondern bewegt sich innerhalb des Segments, um die MAC-Zieladresse zu finden.

Dieser Datenverkehr erfordert eine ARP-Auflösung, die ein Broadcastpaket auslöst, um die MAC-Adresse der Ziel-IP-Adresse zu finden.
– Ein PC ist mit der IP-Adresse 10.52.2.17 und der Subnetzmaske 255.255.255.0 konfiguriert.

– Dieser PC löst einen Netzwerkflow zu einem anderen PC mit der Zieladresse 10.52.2.131 aus.

– Das Betriebssystem des PCs berechnet die Ziel-IP-Adresse mit dem Bereich der IP-Adressen im Segment, um zu bestimmen, ob der Datenverkehr lokal, innerhalb des Segments oder direkt an die Standardgateway-Entität gesendet werden soll, die die richtige Route zum Ziel finden kann.

– Basierend auf den Berechnungsergebnissen ermittelt das Betriebssystem, dass der Segmentbereich für IP- und Subnetzpeer (10.52.2.17 und 255.255.255.0) 10.52.2.0 – 10.52.2.255 lautet.

Die Ergebnisse bedeuten, dass sich die Ziel-IP-Adresse des PCs im selben Segment wie der PC selbst befindet und dass der Datenverkehr direkt im Segment gesendet werden sollte.

Implementieren der Defender for IoT-Bereitstellung mit einem unidirektionalen Gateway

Wenn Sie mit einem unidirektionalen Gateway wie Waterfall, Owl Cyber Defense oder Hirschmann arbeiten, bei dem Daten durch eine Datendiode nur in eine Richtung geleitet werden, verwenden Sie eine der folgenden Methoden, um zu verstehen, wo Ihre OT-Sensoren platziert werden sollten:

  • Platzieren Sie Ihre OT-Sensoren außerhalb des Netzwerkperimeters (Empfohlen). In diesem Szenario empfängt Ihr Sensor SPAN-Datenverkehr über die Diode, unidirektional vom Netzwerk zum Überwachungsport des Sensors. Es wird empfohlen, diese Methode in großen Bereitstellungen zu verwenden. Zum Beispiel:

    Diagramm, das zeigt, wie OT-Sensoren außerhalb des Netzwerkperimeters platziert werden.

  • Platzieren Sie Ihre OT-Sensoren innerhalb des Netzwerkperimeters. In diesem Szenario sendet der Sensor UDP-Syslog-Warnungen an Ziele außerhalb des Perimeters über die Datendiode. Zum Beispiel:

    Diagramm, das zeigt, wie OT-Sensoren innerhalb des Netzwerkperimeters platziert werden.

    OT-Sensoren, die sich innerhalb des Netzwerkperimeters befinden, haben ein Air Gap und müssen lokal verwaltet werden. Sie können keine Verbindung mit der Cloud herstellen oder vom Azure-Portal aus verwaltet werden. So müssen Sie diese Sensoren beispielsweise manuell mit neuen Threat Intelligence-Paketen aktualisieren.

    Wenn Sie mit einem unidirektionalen Netzwerk arbeiten und mit der Cloud verbundene Sensoren benötigen, die über das Azure-Portal verwaltet werden, stellen Sie sicher, dass Sie Ihre Sensoren außerhalb des Netzwerkperimeters platzieren.

Nächste Schritte