Composants Microsoft Defender pour IoT
Le système Microsoft Defender pour IoT est conçu pour fournir une couverture et une visibilité étendues de diverses sources de données.
L’image suivante montre comment les données peuvent être transmises en continu dans Defender pour IoT depuis des capteurs réseau et des sources de tiers pour fournir une vue unifiée de la sécurité IoT/OT. Defender pour IoT dans le Portail Azure inventorie les ressources, évalue les vulnérabilités et surveille continuellement les menaces.
Defender pour IoT se connecte à la fois aux composants cloud et locaux, et est conçu pour la scalabilité dans les environnements de grande taille et géographiquement distribués.
Defender pour IoT inclut les composants de supervision de la sécurité OT suivants :
Portail Azure, pour la gestion et l’intégration cloud aux autres services Microsoft, tels que Microsoft Sentinel ;
Capteurs réseau de technologie opérationnelle (OT) ou IoT Enterprise pour détecter les appareils sur votre réseau. Les capteurs réseau Defender pour IoT sont déployés sur une machine virtuelle ou une appliance physique. Les capteurs OT peuvent être configurés en tant que capteurs connectés au cloud, ou entièrement locaux, gérés localement.
Une console de gestion locale pour la gestion centralisée des sites OT dans des environnements locaux en air gap.
Capteurs réseau OT et IoT Entreprise
Les capteurs réseau Defender pour IoT découvrent et supervisent en permanence le trafic réseau sur vos appareils réseau.
Les capteurs réseau sont spécialement conçus pour les réseaux OT/IoT, et se connectent à un port SPAN ou un TAP réseau. Les capteurs réseau Defender pour IoT peuvent fournir une visibilité sur les risques en quelques minutes une fois la connexion établie au réseau.
Les capteurs réseau utilisent des moteurs d’analytique prenant en charge l’OT/l’IoT et DPI (Deep Packet Inspection) à 6 couches pour détecter les menaces, telles que les programmes malveillants sans fichier, sur la base des activités anormales ou non autorisées.
Les collectes de données, le traitement, l’analyse et les alertes se font directement sur le capteur, ce qui peut être idéal pour les emplacements avec une bande passante faible ou une connectivité à latence élevée. Seuls la télémétrie et les aperçus sont transférés pour la gestion, vers le portail Azure ou une console de gestion locale.
Pour plus d’informations, consultez Chemin de déploiement OT de Defender pour IoT.
Capteurs connectés au cloud et capteurs locaux
Les capteurs connectés au cloud sont des capteurs connectés à Defender pour IoT dans Azure. Ils diffèrent des capteurs gérés localement comme suit :
Quand vous avez un capteur réseau OT connecté au cloud :
Toutes les données détectées par le capteur sont affichées dans la console du capteur, mais les informations d’alerte sont également fournies à Azure, où elles peuvent être analysées et partagées avec d’autres services Azure.
Les packages Microsoft Threat Intelligence peuvent être envoyés (push) automatiquement aux capteurs connectés au cloud.
Le nom du capteur défini lors de l’intégration est le nom affiché dans le capteur. Il est en lecture seule à partir de la console du capteur.
En revanche, lorsque vous utilisez des capteurs gérés localement :
Vous pouvez afficher les données d’un capteur spécifique à partir de la console du capteur. Pour accéder à une vue unifiée des informations détectées par plusieurs capteurs, vous pouvez utiliser une console de gestion locale.
Vous devez charger manuellement tous les packages de renseignement sur les menaces dans des capteurs gérés localement.
Le nom des capteurs peut être mis à jour dans la console du capteur.
Pour plus d’informations, consultez Gérer les capteurs OT à partir de la console des capteurs et Gérer les capteurs OT à partir de la console de gestion.
Moteurs d’analytique Defender pour IoT
Les capteurs réseau Defender pour IoT analysent les données ingérées en utilisant des moteurs d’analytique intégrés, et déclenchent des alertes basées à la fois sur le trafic en temps réel et le trafic préenregistré.
Les moteurs d’analytique fournissent des services Machine Learning et une analytique des profils, une analyse des risques, une base de données d’appareil et un ensemble d’informations analytiques, de renseignements sur les menaces et d’analyses comportementales.
À titre d’exemple, le moteur de détection de violations de stratégie modélise les réseaux des systèmes de contrôle industriels (ICS) afin de détecter les écarts par rapport au comportement attendu comme « base de référence », en utilisant la Détection des anomalies comportementales (BAD) comme décrit dans le document NISTIR 8219. Cette base de référence est développée avec la compréhension des activités régulières se déroulant dans le réseau, comme les modèles normaux de trafic, les actions de l’utilisateur et les accès au réseau ICS. Le système BAD surveille ensuite le réseau à la recherche du moindre écart par rapport au comportement attendu et signale toute violation de stratégie. On compte, comme exemple d’écarts de la base de référence, l’utilisation non autorisée de codes de la fonction, l’accès à des objets spécifiques ou les modifications apportées à la configuration d’un appareil.
Comme de nombreux algorithmes de détection ont été créés pour l’informatique plutôt que pour les réseaux OT, la base de référence supplémentaire pour les réseaux ICS permet de raccourcir la courbe d’apprentissage des systèmes pour les nouvelles détections.
Les capteurs réseau Defender pour IoT incluent les moteurs d’analyse suivants :
| Nom | Description | Exemples |
|---|---|---|
| Moteur de détection de violation de protocole | Identifie l’utilisation des structures de paquets et des valeurs de champ qui ne respectent pas les spécifications de protocole ICS. Une violation de protocole se produit lorsque la structure de paquets ou les valeurs de champ ne sont pas conformes à la spécification de protocole. |
Une alerte « Opération MODBUS illégale (code de fonction zéro) » indique qu’un appareil principal a envoyé une requête avec le code de fonction 0 à un appareil secondaire. Cette action n’est pas autorisée conformément aux spécifications du protocole, et l’appareil secondaire peut ne pas gérer correctement l’entrée. |
| Violation de la stratégie | Une violation de stratégie se produit lorsqu’il y a un écart par rapport au comportement de la ligne de base défini dans les paramètres appris ou configurés. | Une alerte « Agent utilisateur HTTP non autorisé » indique qu’une application qui n’a pas été apprise ou approuvée par la stratégie est utilisée comme client HTTP sur un appareil. Il peut s’agir d’un nouveau navigateur web ou d’une nouvelle application sur cet appareil. |
| Moteur de détection de programmes malveillant pour l’industrie | Identifie les comportements qui indiquent la présence d’activités réseau malveillantes via des programmes malveillants connus, tels que Conficker, Black Energy, Havex, WannaCry, NotPetya et Triton. | Une alerte « Suspicion d’activité malveillante (Stuxnet) » indique que le capteur a détecté une activité réseau suspecte connue pour être liée au programme malveillant Stuxnet. Ce programme malveillant est une menace avancée permanente qui vise le contrôle industriel et les réseaux SCADA. |
| Moteur de détection d’anomalies | Détecte les communications et comportements machine à machine (M2M) inhabituels. Ce moteur modélise les réseaux ICS et nécessite donc une période d’apprentissage plus courte que l’analytique développée pour l’informatique. Les anomalies sont détectées plus rapidement, avec un minimum de faux positifs. |
Une alerte « Comportement périodique dans le canal de communication » reflète le comportement périodique et cyclique de la transmission de données, ce qui est courant dans les réseaux industriels. D’autres exemples incluent les tentatives de connexion SMB excessives et les alertes détectées par l’analyse PLC. |
| Détection d’incidents opérationnels | Détecte des problèmes opérationnels, tels qu’une connectivité intermittente, qui peuvent indiquer des signes précoces de défaillance de l’équipement. | Une alerte « L’appareil est soupçonné d’être déconnecté (pas de réponse) » est déclenchée lorsqu’un appareil ne répond à aucun type de demande pendant une période prédéfinie. Elle peut indiquer un arrêt, une déconnexion ou un dysfonctionnement de l’appareil. Un autre exemple pourrait être la commande PLC stop Siemens S7 qui recevrait des alertes. |
Options de gestion
Defender pour IoT offre une prise en charge des réseaux hybrides à l’aide des options de gestion suivantes :
Le portail Azure. Utilisez le portail Azure pour obtenir une vision centralisée des données ingérées depuis vos appareils via des capteurs réseau connectés au cloud. Le portail Azure fournit des éléments supplémentaires, comme des workbooks, des connexions à Microsoft Sentinel, des recommandations de sécurité, etc.
Utilisez également le Portail Azure pour obtenir de nouvelles appliances et mises à jour logicielles, intégrer et gérer vos capteurs dans Defender pour IoT et mettre à jour les packages de renseignement sur les menaces. Par exemple :
La console du capteur OT Visualisez les détections pour les appareils connectés à un capteur spécifique à partir de la console du capteur. Utilisez la console du capteur pour visualiser une carte du réseau pour les appareils détectés par ce capteur, une chronologie de tous les événements qui se produisent sur le capteur, transférer les informations du capteur à des systèmes partenaires, etc. Par exemple :
Console de gestion locale. Dans les environnements hermétiques, vous pouvez obtenir une vue centrale des données de tous vos capteurs à partir d’une console de gestion locale, au moyen d’outils de maintenance et de fonctionnalités de génération de rapports supplémentaires.
La version logicielle sur votre console de gestion locale doit être égale à celle de votre version de capteur la plus récente. Chaque version de la console de gestion locale est rétrocompatible avec les anciennes versions de capteur prises en charge, mais ne peut pas se connecter à des versions de capteur plus récentes.
Pour plus d’informations, consultez Chemin de déploiement de la gestion des capteurs OT en air gap.
Appareils surveillés par Defender pour IoT
Defender pour IoT peut découvrir tous les appareils, de tous les types, dans tous les environnements. Les appareils sont répertoriés dans les pages Inventaire des appareils de Defender pour IoT en fonction d’un couplage d’adresses IP et MAC uniques.
Defender pour IoT identifie les appareils seuls et uniques comme suit :
| Type | Description |
|---|---|
| Identifiés comme des appareils individuels | Les appareils identifiés comme des appareils individuels sont les suivants : Les appareils IT, OT ou IoT avec une ou plusieurs cartes réseau, y compris les appareils d’infrastructure réseau, comme les commutateurs et les routeurs Remarque : Un appareil avec des modules ou des composants de fond de panier, comme des racks ou des fentes, est comptabilisé comme un seul appareil, y compris tous les modules ou composants de fond de panier. |
| Non identifiés comme des appareils individuels | Les éléments suivants ne sont pas considérés comme des appareils individuels et ne sont pas comptabilisés par rapport à votre licence : - Adresses IP Internet publiques - Groupes multi-cast - Groupes de diffusion - Appareils inactifs Les appareils surveillés par le réseau sont marqués comme inactifs lorsqu’aucune activité réseau n’est détectée dans un délai spécifié : - Réseaux OT : Aucune activité réseau détectée depuis plus de 60 jours - Réseaux IoT Entreprise : Aucune activité réseau détectée depuis plus de 30 jours Remarque : les points de terminaison déjà managés par Defender for Endpoint ne sont pas considérés comme des appareils distincts par Defender pour IoT. |