Defender för IoT och din nätverksarkitektur

Den här artikeln är en i en serie artiklar som beskriver distributionssökvägen för OT-övervakning med Microsoft Defender för IoT.

Använd innehållet nedan för att lära dig mer om din egen driftteknik (OT)/IoT-nätverksarkitektur, och var och en av dina systemelement hamnar i lager av OT-nätverkssegmentering.

Diagram of a progress bar with Plan and prepare highlighted.

OT/IoT-nätverkslager

Organisationens nätverk består av många enhetstyper, som kan delas in i följande huvudgrupper:

  • Slutpunktsenheter. Kan innehålla flera undergrupper, till exempel servrar, datorer, IoT-enheter (sakernas Internet) och så vidare.
  • Nätverksenheter. Hantera infrastrukturen med nätverkstjänster och kan omfatta nätverksväxlar, brandväggar, routrar och åtkomstpunkter.

De flesta nätverksmiljöer är utformade med en hierarkisk modell med tre lager. Till exempel:

Skikt Description
Åtkomst Åtkomstlagret är där de flesta slutpunkter kommer att finnas. Dessa slutpunkter hanteras vanligtvis av en standardgateway och routning från de övre lagren, och ofta routning från distributionsskiktet.

* En standardgateway är en nätverkstjänst eller en entitet i det lokala undernätet som ansvarar för att dirigera trafik utanför LAN- eller IP-segmentet.
Fördelning Distributionslagret ansvarar för att aggregera flera åtkomstlager och leverera kommunikation till kärnskiktet med tjänster som VLAN-routning, tjänstkvalitet, nätverksprinciper och så vidare.
Core Kärnskiktet innehåller organisationens huvudsakliga servergrupp och tillhandahåller snabba tjänster med låg svarstid via distributionsskiktet.

Purdue-modellen för nätverksarkitektur

Purdue-referensmodellen för industrial control system (ICS)/OT-nätverkssegmentering definierar ytterligare sex skikt, med specifika komponenter och relevanta säkerhetskontroller för varje lager.

Varje enhetstyp i ditt OT-nätverk hamnar på en viss nivå av Purdue-modellen, till exempel som du ser i följande bild:

Diagram of the Purdue model.

I följande tabell beskrivs varje nivå i Purdue-modellen när den tillämpas på enheter som du kan ha i nätverket:

Namn Beskrivning
Nivå 0: Cell och område Nivå 0 består av en mängd olika sensorer, ställdon och enheter som ingår i den grundläggande tillverkningsprocessen. Dessa enheter utför de grundläggande funktionerna i det industriella automatiserings- och kontrollsystemet, till exempel:

- Köra en motor
– Mäta variabler
– Ange utdata
- Utföra viktiga funktioner, till exempel målning, svetsning och böjning
Nivå 1: Processkontroll Nivå 1 består av inbäddade styrenheter som styr och manipulerar tillverkningsprocessen vars nyckelfunktion är att kommunicera med nivå 0-enheterna. I diskret tillverkning är dessa enheter programmerbara logikstyrenheter (PLC) eller fjärrtelemetrienheter (RTU:er). Under processtillverkning kallas den grundläggande styrenheten för ett distribuerat kontrollsystem (DCS).
Nivå 2: Tillsyn Nivå 2 representerar de system och funktioner som är associerade med körningsövervakning och drift av ett område i en produktionsanläggning. Dessa omfattar vanligtvis följande:

– Operatörsgränssnitt eller gränssnitt för människa-dator (HMIs)
– Larm eller aviseringssystem
- Processhistoriker och batchhanteringssystem
- Kontrollera arbetsstationer i rummet

Dessa system kommunicerar med PLC:er och RTU:er på nivå 1. I vissa fall kommunicerar eller delar de data med system och program på plats eller företag (nivå 4 och nivå 5). Dessa system baseras främst på vanlig databehandlingsutrustning och operativsystem (Unix eller Microsoft Windows).
Nivå 3 och 3.5: Nätverk på platsnivå och industriellt perimeternätverk Platsnivån representerar den högsta nivån av industriell automatisering och kontrollsystem. De system och program som finns på den här nivån hanterar platsomfattande industriella automatiserings- och kontrollfunktioner. Nivåer 0 till och med 3 anses vara viktiga för platsåtgärder. De system och funktioner som finns på den här nivån kan innehålla följande:

– Produktionsrapportering (till exempel cykeltider, kvalitetsindex, förutsägande underhåll)
- Växthistoriker
– Detaljerad produktionsschemaläggning
– Hantering av åtgärder på platsnivå
– Enhets- och materialhantering
– Korrigeringsstartserver
– Filserver
- Industridomän, Active Directory, terminalserver

Dessa system kommunicerar med produktionszonen och delar data med företagets system och program (nivå 4 och nivå 5).
Nivå 4 och 5: Företags- och företagsnätverk Nivå 4 och nivå 5 representerar platsen eller företagsnätverket där de centraliserade IT-systemen och funktionerna finns. IT-organisationen hanterar tjänsterna, systemen och programmen direkt på dessa nivåer.

Placera OT-sensorer i nätverket

När Defender för IoT-nätverkssensorer är anslutna till nätverksinfrastrukturen får de speglad trafik, till exempel från SPAN-portar (Switch Mirror) eller nätverks-TAP:er. Sensorns hanteringsport ansluter till företags-, företags- eller sensorhanteringsnätverket, till exempel för nätverkshantering från Azure-portalen.

Till exempel:

Diagram of a managed switch with port mirroring.

Följande bild lägger till Defender för IoT-resurser i samma nätverk som beskrevs tidigare, inklusive en SPAN-port, nätverkssensor och Defender för IoT i Azure-portalen.

Diagram of the Purdue model with Defender for IoT components.

Mer information finns i Exempel på ot-nätverksanslutningsmodeller.

Identifiera intressanta trafikpunkter

Vanligtvis är intressanta punkter ur ett säkerhetsperspektiv de gränssnitt som ansluter mellan standardgatewayentiteten till kärn- eller distributionsväxeln.

Genom att identifiera dessa gränssnitt som intressanta punkter ser du till att trafik som färdas inifrån IP-segmentet till utanför IP-segmentet övervakas. Se även till att överväga att sakna trafik, vilket är trafik som ursprungligen var avsedd att lämna segmentet, men som hamnar kvar i segmentet. Mer information finns i Trafikflöden i nätverket.

När du planerar en Defender for IoT-distribution rekommenderar vi att du överväger följande element i nätverket:

Att tänka på Description
Unika trafiktyper i ett segment Tänk särskilt på följande typer av trafik i ett nätverkssegment:

Broadcast/Multicast-trafik: Trafik som skickas till en entitet i undernätet.

Med IGMP (Internet Group Management Protocol) konfigureras snooping i nätverket, men det finns ingen garanti för att multicast-trafik vidarebefordras till någon specifik entitet.

Sändnings- och multicast-trafik skickas vanligtvis till alla entiteter i det lokala IP-undernätet, inklusive standardgatewayentiteten, och omfattas därför också och övervakas.

Unicast-trafik: Trafiken vidarebefordras direkt till målet, utan att hela undernätets slutpunkter korsas, inklusive standardgatewayen.

Övervaka unicast-trafik med Defender för IoT genom att placera sensorer direkt på åtkomstväxlarna.
Övervaka båda trafikströmmarna När du strömmar trafik till Defender för IoT tillåter vissa leverantörer och produkter en riktningsström, vilket kan orsaka en lucka i dina data.

Det är mycket användbart att övervaka båda trafikriktningarna för att få information om nätverkskonversation om dina undernät och bättre noggrannhet i allmänhet.
Hitta ett undernäts standardgateway För varje intressant undernät är den intressanta punkten alla anslutningar till entiteten som fungerar som standardgateway för nätverkets undernät.

I vissa fall finns det dock trafik i undernätet som inte övervakas av den vanliga intressanta punkten. Övervakning av den här typen av trafik, som annars inte övervakas av den typiska distributionen, är särskilt användbart för känsliga undernät.
Atypisk trafik Övervakning av trafik som annars inte övervakas av den typiska distributionen kan kräva extra strömningsplatser och nätverkslösningar, till exempel RSPAN, nätverkstappar och så vidare.

Mer information finns i Trafikspeglingsmetoder för OT-övervakning.

Exempel på trafikdiagram

Följande diagram visar ett exempelnätverk i en byggnad med tre våningar, där den första och andra våningen rymmer både slutpunkter och växlar, och husslutpunkter och växlar på tredje våningen, men även brandväggar, kärnväxlar, en server och routrar.

  • Trafik som färdas utanför IP-segmentet visas med en blå streckad linje.

  • Intressant trafik är markerad i rött och anger de platser där vi rekommenderar att du placerar nätverkssensorer för att strömma den intressanta trafiken till Defender för IoT.

Diagram of sample OT network traffic.

Trafikflöden i nätverket

Enheter som utlöser nätverkstrafik matchar den konfigurerade nätmasken och IP-adressen med en mål-IP-adress för att förstå vad trafikens mål ska vara. Trafikens mål är antingen standardgatewayen eller någon annanstans inom IP-segmentet. Den här matchningsprocessen kan också utlösa en ARP-process för att hitta MAC-adressen för mål-IP-adressen.

Baserat på resultatet av matchningsprocessen spårar enheterna sin nätverkstrafik som antingen trafik inom eller utanför IP-segmentet.

Trafik Description Exempel
Trafik utanför IP-segmentet När trafikmålet inte hittas inom undernätsmaskens intervall skickar slutpunktsenheten trafiken till den specifika standardgateway som ansvarar för att dirigera trafikflödet till andra relevanta segment.

All trafik som färdas utanför ett IP-segment flödar via en standardgateway för att korsa nätverkssegmentet, som ett första hopp i sökvägen till målet.

Obs! Om du placerar en Defender for IoT OT-nätverkssensor ser du till att all trafik som färdas utanför segmentet strömmas till Defender for IoT, analyseras och kan undersökas.
– En dator har konfigurerats med en IP-adress 10.52.2.201 för och en nätmask på 255.255.255.0.

– Datorn utlöser ett nätverksflöde till en webbserver med mål-IP-adressen 10.17.0.88.

– Datorns operativsystem beräknar mål-IP-adressen med intervallet med IP-adresser i segmentet för att avgöra om trafiken ska skickas lokalt, inom segmentet eller direkt till standardgatewayentiteten som kan hitta rätt väg till målet.

– Baserat på beräkningens resultat upptäcker operativsystemet att för IP- och undernäts peer (10.52.2.17 och ), är 10.52.2.0 segmentintervallet – 10.52.2.255255.255.255.0.

Resultatet innebär att webbservern inte ligger inom samma IP-segment som datorn och att trafiken ska skickas till standardgatewayen.
Trafik inom IP-segmentet Om enheten hittar mål-IP-adressen inom undernätets maskintervall går trafiken inte över IP-segmentet och färdas inom segmentet för att hitta målets MAC-adress.

Den här trafiken kräver en ARP-lösning som utlöser ett sändningspaket för att hitta mål-IP-adressens MAC-adress.
– En dator har konfigurerats med en IP-adress 10.52.2.17 för och en nätmask på 255.255.255.0.

– Den här datorn utlöser ett nätverksflöde till en annan dator med måladressen 10.52.2.131.

– Datorns operativsystem beräknar mål-IP-adressen med intervallet med IP-adresser i segmentet för att avgöra om trafiken ska skickas lokalt, inom segmentet eller direkt till standardgatewayentiteten som kan hitta rätt väg till målet.

– Baserat på beräkningens resultat upptäcker operativsystemet att för IP- och undernäts peer (10.52.2.17 och 255.255.255.0) är 10.52.2.0 – 10.52.2.255segmentintervallet .

Resultatet innebär att datorns mål-IP-adress ligger inom samma segment som själva datorn och att trafiken ska skickas direkt i segmentet.

Implementera Defender för IoT-distribution med en enkelriktad gateway

Om du arbetar med en enkelriktad gateway, till exempel Vattenfall, Owl Cyber Defense eller Hirschmann, där data passerar genom en datadiod endast i en riktning, använder du någon av följande metoder för att förstå var dina OT-sensorer ska placeras:

  • Placera dina OT-sensorer utanför nätverksperimetern (rekommenderas). I det här scenariot tar sensorn emot SPAN-trafik via dioden, endirigering från nätverket till sensorns övervakningsport. Vi rekommenderar att du använder den här metoden i stora distributioner. Till exempel:

    Diagram of placing OT sensors outside the network perimeter.

  • Placera dina OT-sensorer i nätverksperimetern. I det här scenariot skickar sensorn UDP-syslogaviseringar till mål utanför perimetern via datadioden. Till exempel:

    Diagram of placing OT sensors inside the network perimeter.

    OT-sensorer som placeras inuti nätverksperimetern är luftspade och måste hanteras lokalt. De kan inte ansluta till molnet eller hanteras från Azure-portalen. Du måste till exempel uppdatera dessa sensorer manuellt med nya hotinformationspaket.

    Om du arbetar med ett enkelriktat nätverk och behöver molnanslutna sensorer som hanteras från Azure-portalen ser du till att placera dina sensorer utanför nätverksperimetern.

Nästa steg