Microsoft Defender för IoT-komponenter

Microsoft Defender för IoT-systemet är byggt för att ge bred täckning och synlighet från olika datakällor.

Följande bild visar hur data kan strömmas till Defender för IoT från nätverkssensorer och källor från tredje part för att ge en enhetlig vy över IoT/OT-säkerhet. Defender för IoT i Azure-portalen tillhandahåller tillgångsinventeringar, sårbarhetsbedömningar och kontinuerlig hotövervakning.

Diagram of the Defender for IoT OT system architecture.

Defender för IoT ansluter till både molnbaserade och lokala komponenter och är byggt för skalbarhet i stora och geografiskt distribuerade miljöer.

Defender för IoT innehåller följande komponenter för OT-säkerhetsövervakning:

  • Azure-portalen, för molnhantering och integrering till andra Microsoft-tjänster, till exempel Microsoft Sentinel.

  • Driftteknik (OT) eller Enterprise IoT-nätverkssensorer för att identifiera enheter i nätverket. Defender for IoT-nätverkssensorer distribueras antingen på en virtuell dator eller på en fysisk enhet. OT-sensorer kan konfigureras som molnanslutna sensorer, eller helt lokala, lokalt hanterade sensorer.

  • En lokal hanteringskonsol för centraliserad hantering och övervakning av OT-sensorer för lokala, luftspända miljöer.

OT- och Enterprise IoT-nätverkssensorer

Defender för IoT-nätverkssensorer identifierar och övervakar kontinuerligt nätverkstrafik över dina nätverksenheter.

  • Nätverkssensorer är specialbyggda för OT/IoT-nätverk och ansluter till en SPAN-port eller ett TAP-nätverk. Defender för IoT-nätverkssensorer kan ge insyn i risker inom några minuter efter anslutningen till nätverket.

  • Nätverkssensorer använder OT/IoT-medvetna analysmotorer och Layer-6 Deep Packet Inspection (DPI) för att identifiera hot, till exempel fillös skadlig kod, baserat på avvikande eller obehörig aktivitet.

Datainsamling, bearbetning, analys och avisering sker direkt på sensorn, vilket kan vara idealiskt för platser med låg bandbredd eller anslutning med hög latens. Endast telemetri och insikter överförs för hantering, antingen till Azure-portalen eller till en lokal hanteringskonsol.

Mer information finns i Distributionssökvägen för Defender for IoT OT.

Molnanslutna jämfört med lokala OT-sensorer

Molnanslutna sensorer är sensorer som är anslutna till Defender för IoT i Azure och skiljer sig från lokalt hanterade sensorer på följande sätt:

När du har en molnansluten OT-nätverkssensor:

  • Alla data som sensorn identifierar visas i sensorkonsolen, men aviseringsinformation levereras också till Azure, där den kan analyseras och delas med andra Azure-tjänster.

  • Microsofts hotinformationspaket kan automatiskt skickas till molnanslutna sensorer.

  • Sensornamnet som definieras under registrering är det namn som visas i sensorn och är skrivskyddat från sensorkonsolen.

När du däremot arbetar med lokalt hanterade sensorer:

  • Visa data för en specifik sensor från sensorkonsolen. Om du vill ha en enhetlig vy över all information som identifieras av flera sensorer använder du en lokal hanteringskonsol.

  • Du måste ladda upp eventuella hotinformationspaket manuellt till lokalt hanterade sensorer.

  • Sensornamn kan uppdateras i sensorkonsolen.

Mer information finns i Hantera OT-sensorer från sensorkonsolen och Hantera OT-sensorer från hanteringskonsolen.

Defender för IoT-analysmotorer

Defender för IoT-nätverkssensorer analyserar inmatade data med hjälp av inbyggda analysmotorer och utlöser aviseringar baserat på både realtidstrafik och förinspelad trafik.

Analysmotorer tillhandahåller maskininlärning och profilanalys, riskanalys, en enhetsdatabas och en uppsättning insikter, hotinformation och beteendeanalys.

Till exempel modellerar principöverträdelseidentifieringsmotorn industriella kontrollsystemnätverk (ICS) för att identifiera avvikelser från det förväntade "baslinjebeteendet" genom att använda beteendeavvikelseidentifiering (BAD) enligt beskrivningen i NISTIR 8219. Den här baslinjen utvecklas genom att förstå de regelbundna aktiviteter som sker i nätverket, till exempel normala trafikmönster, användaråtgärder och åtkomst till ICS-nätverket. Det dåliga systemet övervakar sedan nätverket för eventuella avvikelser från det förväntade beteendet och flaggar eventuella principöverträdelser. Exempel på baslinjeavvikelser är obehörig användning av funktionskoder, åtkomst till specifika objekt eller ändringar i konfigurationen av en enhet.

Eftersom många identifieringsalgoritmer har skapats för IT i stället för OT-nätverk hjälper den extra baslinjen för ICS-nätverk till att förkorta systemets inlärningskurva för nya identifieringar.

Defender för IoT-nätverkssensorer innehåller följande huvudanalysmotorer:

Name beskrivning Exempel
Motorn för identifiering av protokollöverträdelser Identifierar användningen av paketstrukturer och fältvärden som strider mot ICS-protokollspecifikationer.

Protokollöverträdelser inträffar när paketstrukturen eller fältvärdena inte uppfyller protokollspecifikationen.
En avisering om ogiltig MODBUS-åtgärd (funktionskod noll)" anger att en primär enhet skickade en begäran med funktionskod 0 till en sekundär enhet. Den här åtgärden är inte tillåten enligt protokollspecifikationen och den sekundära enheten kanske inte hanterar indata korrekt
Principöverträdelse En principöverträdelse inträffar med en avvikelse från baslinjebeteendet som definieras i inlärda eller konfigurerade inställningar. En avisering om "Obehörig HTTP-användaragent" anger att ett program som inte har lärts in eller godkänts av principen används som EN HTTP-klient på en enhet. Det kan vara en ny webbläsare eller ett nytt program på enheten.
Industriell identifieringsmotor för skadlig kod Identifierar beteenden som anger förekomsten av skadlig nätverksaktivitet via känd skadlig kod, till exempel Conficker, Black Energy, Havex, WannaCry, NotPetya och Triton. En avisering om misstänkt skadlig aktivitet (Stuxnet) anger att sensorn upptäckte misstänkt nätverksaktivitet som är känd för att vara relaterad till den skadliga stuxnet-koden. Den här skadliga koden är ett avancerat ihållande hot mot industriell kontroll och SCADA-nätverk.
Avvikelseidentifieringsmotor Identifierar ovanlig kommunikation från dator till dator (M2M) och beteenden.

Den här motorn modellerar ICS-nätverk och kräver därför en kortare inlärningsperiod än analys som utvecklats för IT. Avvikelser identifieras snabbare, med minimala falska positiva identifieringar.
En avisering om periodiskt beteende i kommunikationskanalen återspeglar periodiskt och cykliskt beteende för dataöverföring, vilket är vanligt i industriella nätverk.
Andra exempel är överdrivna SMB-inloggningsförsök och PLC-genomsökning identifierade aviseringar.
Identifiering av driftincidenter Identifierar driftsproblem, till exempel tillfälliga anslutningar som kan tyda på tidiga tecken på fel i utrustningen. Aviseringen "Enheten misstänks vara frånkopplad (svarar inte)" utlöses när en enhet inte svarar på någon form av begäran under en fördefinierad period. Den här aviseringen kan tyda på en enhetsavstängning, frånkoppling eller fel.
Ett annat exempel kan vara om kommandot Siemens S7 stop PLC skickades aviseringar.

Hanteringsalternativ

Defender för IoT har stöd för hybridnätverk med hjälp av följande hanteringsalternativ:

  • Azure-portalen. Använd Azure-portalen som en enda fönsterruta för att visa alla data som matas in från dina enheter via molnanslutna nätverkssensorer. Azure-portalen ger extra värde, till exempel arbetsböcker, anslutningar till Microsoft Sentinel, säkerhetsrekommendationer med mera.

    Använd även Azure-portalen för att hämta nya installationer och programuppdateringar, registrera och underhålla dina sensorer i Defender för IoT och uppdatera hotinformationspaket. Till exempel:

    Screenshot of the Defender for I O T default view on the Azure portal.

  • OT-sensorkonsolen. Visa identifieringar för enheter som är anslutna till en specifik OT-sensor från sensorkonsolen. Använd sensorkonsolen för att visa en nätverkskarta för enheter som identifierats av sensorn, en tidslinje över alla händelser som inträffar på sensorn, vidarebefordra sensorinformation till partnersystem med mera. Till exempel:

    Screenshot that shows the updated interface.

  • Den lokala hanteringskonsolen. I luftgapade miljöer kan du få en central vy över data från alla dina sensorer från en lokal hanteringskonsol med hjälp av extra underhållsverktyg och rapporteringsfunktioner.

    Programvaruversionen i den lokala hanteringskonsolen måste vara lika med den senaste sensorversionen. Varje lokal hanteringskonsolversion är bakåtkompatibel för äldre sensorversioner som stöds, men kan inte ansluta till nyare sensorversioner.

    Mer information finns i Distributionssökväg för hantering av ot-sensorhantering med luftgap.

Enheter som övervakas av Defender för IoT

Defender för IoT kan identifiera alla enheter, av alla typer, i alla miljöer. Enheter visas på inventeringssidorna för Defender för IoT-enheter baserat på en unik IP- och MAC-adresskoppling.

Defender för IoT identifierar enskilda och unika enheter på följande sätt:

Typ Beskrivning
Identifierad som enskilda enheter Enheter som identifieras som enskilda enheter är:
IT-, OT- eller IoT-enheter med en eller flera nätverkskort, inklusive nätverksinfrastrukturenheter som växlar och routrar

Obs! En enhet med moduler eller backplanskomponenter, till exempel rack eller fack, räknas som en enda enhet, inklusive alla moduler eller komponenter för bakplan.
Identifieras inte som enskilda enheter Följande objekt betraktas inte som enskilda enheter och räknas inte mot din licens:

- Offentliga IP-adresser för Internet
- Grupper med flera uppsättningar
- Sändningsgrupper
- Inaktiva enheter

Nätverksövervakade enheter markeras som inaktiva när ingen nätverksaktivitet har identifierats inom en angiven tid:

- OT-nätverk: Ingen nätverksaktivitet har identifierats under mer än 60 dagar
- Företags-IoT-nätverk: Ingen nätverksaktivitet har identifierats på mer än 30 dagar

Obs! Slutpunkter som redan hanteras av Defender för Endpoint betraktas inte som separata enheter av Defender för IoT.

Nästa steg