Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les agents de sécurité Defender pour IoT collectent des données et des événements système à partir de votre appareil local et envoient les données au cloud Azure pour traitement.
Remarque
Defender pour IoT prévoit de mettre hors service le micro-agent le 1er août 2025.
Si vous avez configuré et connecté un espace de travail Log Analytics, ces événements s’affichent dans Log Analytics. Pour plus d’informations, consultez Tutoriel : Examiner les alertes de sécurité.
Le micro-agent Defender pour IoT collecte de nombreux types d’événements d’appareil, notamment les nouveaux processus et tous les nouveaux événements de connexion. Le nouveau processus et les nouveaux événements de connexion peuvent se produire fréquemment sur un appareil. Cette fonctionnalité est importante pour une sécurité complète. Toutefois, le nombre de messages envoyés par les agents de sécurité peut rapidement atteindre ou dépasser votre quota de IoT Hub et les limites de coût. Ces messages et événements contiennent des informations de sécurité très précieuses qui sont essentielles à la protection de votre appareil.
Pour réduire le nombre de messages et les coûts tout en maintenant la sécurité de votre appareil, les agents Defender pour IoT agrègent les types d’événements suivants :
Traiter les événements (Linux uniquement)
Événements d’activité réseau
Événements du système de fichiers
Événements de statistiques
Pour plus d’informations, consultez Agrégation d’événements pour les collecteurs de processus et de réseau.
Les collecteurs basés sur les événements sont des collecteurs qui sont déclenchés en fonction de l’activité correspondante à partir de l’appareil. Par exemple : a process was started in the device.
Les collecteurs basés sur un déclencheur sont des collecteurs qui sont déclenchés de manière planifiée en fonction des configurations du client.
Traiter les événements (collecteur basé sur les événements)
Les événements de processus sont pris en charge sur les systèmes d’exploitation Linux.
Les événements de processus sont considérés comme identiques lorsque la ligne de commande et l’id utilisateur sont identiques.
La mémoire tampon par défaut pour les événements de processus est de 256 processus. Lorsque cette limite est atteinte, la mémoire tampon se cycle et l’événement de processus le plus ancien est ignoré afin de libérer de la place pour l’événement traité le plus récent. Un avertissement d’augmentation de la taille du cache est enregistré.
Les données collectées pour chaque événement sont les suivantes :
| Paramètre | Description |
|---|---|
| Timestamp | La première fois que le processus a été observé. |
| process_id | PID Linux. |
| parent_process_id | Le Linux PID parent, s’il existe. |
| Commandline | Ligne de commande. |
| Type | Peut être , forkou exec. |
| hit_count | Nombre agrégé. Nombre d’exécutions du même processus, pendant la même période, jusqu’à ce que les événements soient envoyés au cloud. |
Événements d’activité réseau (collecteur basé sur les événements)
Les événements d’activité réseau sont considérés comme identiques lorsque le port local, le port distant, le protocole de transport, l’adresse locale et l’adresse distante sont identiques.
La mémoire tampon par défaut pour un événement d’activité réseau est 256. Pour les situations où le cache est plein :
Appareils Eclipse ThreadX : aucun nouvel événement réseau n’est mis en cache tant que le prochain cycle de collecte n’est pas lancé.
appareils Linux : l’événement le plus ancien est remplacé par chaque nouvel événement. Un avertissement d’augmentation de la taille du cache est enregistré.
Pour les appareils Linux, seul IPv4 est pris en charge.
Les données collectées pour chaque événement sont les suivantes :
| Paramètre | Description |
|---|---|
| Adresse locale | Adresse source de la connexion. |
| Adresse distante | Adresse de destination de la connexion. |
| Port local | Port source de la connexion. |
| Port distant | Port de destination de la connexion. |
| Bytes_in | Nombre total d’octets RX agrégés de la connexion. |
| Bytes_out | Nombre total d’octets TX agrégés de la connexion. |
| Transport_protocol | Peut être TCP, UDP ou ICMP. |
| Protocole d’application | Protocole d’application associé à la connexion. |
| Propriétés étendues | Détails supplémentaires de la connexion. Par exemple : host name. |
| Nombre d’accès | Nombre de paquets observés |
Collecteur de connexions (collecteur basé sur les événements)
Le collecteur de connexions collecte les connexions utilisateur, les déconnexions et les tentatives de connexion ayant échoué.
Le collecteur de connexions prend en charge les types de méthodes de collecte suivants :
APPLIANCEP et SYSLOG. L’INTERFACEP intercepte les événements interactifs SSH, les événements telnet et les connexions de terminal, ainsi que tous les événements de connexion ayant échoué à partir de SSH, telnet et terminal. Si SYSLOG est activé sur l’appareil, le collecteur de connexions collecte également les événements de connexion SSH via le fichier SYSLOG nommé auth.log.
Modules d’authentification enfichables (PAM). Collecte les événements de connexion SSH, telnet et local. Pour plus d’informations, consultez Configurer des modules d’authentification enfichables (PAM) pour auditer les événements de connexion.
Les données suivantes sont collectées :
| Paramètre | Description |
|---|---|
| operation | L’un des éléments suivants : Login, Logout, LoginFailed |
| process_id | PID Linux. |
| User_name | Utilisateur Linux. |
| Exécutable | Appareil terminal. Par exemple : tty1..6 ou pts/n. |
| remote_address | La source de connexion, soit une adresse IP distante au format IPv6 ou IPv4, soit 127.0.0.1/0.0.0.0 pour indiquer une connexion locale. |
Informations système (collecteur basé sur un déclencheur)
Les données collectées pour chaque événement sont les suivantes :
| Paramètre | Description |
|---|---|
| hardware_vendor | Nom du fournisseur de l’appareil. |
| hardware_model | Numéro de modèle de l’appareil. |
| os_dist | Distribution du système d’exploitation. Par exemple : Linux. |
| os_version | Version du système d’exploitation. Par exemple, Windows 10ou Ubuntu 20.04.1. |
| os_platform | Système d’exploitation de l’appareil. |
| os_arch | Architecture du système d’exploitation. Par exemple : x86_64. |
| agent_type | Type de l’agent (Edge/Autonome). |
| agent_version | Version de l’agent. |
| Nic | Contrôleur d’interface réseau. La liste complète des propriétés est répertoriée ci-dessous. |
Les propriétés nics sont composées des éléments suivants :
| Paramètre | Description |
|---|---|
| type | L’une des valeurs suivantes : UNKNOWN, ETH, WIFI, MOBILEou SATELLITE. |
| Vlan | Lan virtuel associé à l’interface réseau. |
| Fournisseur | Fournisseur du contrôleur de réseau. |
| info | IPS et MAC associés au contrôleur de réseau. Cela inclut les champs suivants : - ipv4_address : adresse IPv4. - ipv6_address : adresse IPv6. - mac : adresse MAC. |
Base de référence (collecteur basé sur un déclencheur)
Le collecteur de la base de référence effectue des vérifications CIS périodiques et a échoué, réussi et ignoré case activée résultats sont envoyés au service cloud Defender pour IoT. Defender pour IoT agrège les résultats et fournit des recommandations en fonction des défaillances éventuelles.
Les données collectées pour chaque événement sont les suivantes :
| Paramètre | Description |
|---|---|
| Vérifier l’ID | Au format CIS. Par exemple : CIS-debian-9-Filesystem-1.1.2. |
| Vérifier le résultat | Peut être Fail, Pass, Skipou Error. Par exemple, Error dans une situation où le case activée ne peut pas s’exécuter. |
| Erreur | Informations et description de l’erreur. |
| Description | Description du case activée de CIS. |
| Assainissement | Recommandation de correction à partir de CIS. |
| Gravité | Niveau de gravité. |
SBoM (collecteur basé sur un déclencheur)
Le collecteur SBoM (Software Bill of Materials) collecte régulièrement les packages installés sur l’appareil.
Les données collectées sur chaque package incluent :
| Paramètre | Description |
|---|---|
| Name | Nom du package. |
| Version | Version du package. |
| Fournisseur | Le fournisseur du package, qui est le champ Mainteneur dans les packages deb. |
Événements périphériques (collecteur basé sur les événements)
Le collecteur d’événements périphériques collecte les connexions et les déconnexions des événements USB et Ethernet.
Les champs collectés dépendent du type d’événement :
Événements USB
| Paramètre | Description |
|---|---|
| Timestamp | Heure à laquelle l’événement s’est produit. |
| ActionType | Indique si l’événement était un événement de connexion ou de déconnexion. |
| bus_number | Identificateur de contrôleur spécifique, chaque périphérique USB peut en avoir plusieurs. |
| kernel_device_number | Représentation dans le noyau de l’appareil, non unique et peut chaque fois que l’appareil est connecté. |
| device_class | Identificateur spécifiant la classe de l’appareil. |
| device_subclass | Identificateur spécifiant le type d’appareil. |
| device_protocol | Identificateur spécifiant le protocole de l’appareil. |
| interface_class | Si la classe d’appareil est 0, indiquez le type d’appareil. |
| interface_subclass | Si la classe d’appareil est 0, indiquez le type d’appareil. |
| interface_protocol | Si la classe d’appareil est 0, indiquez le type d’appareil. |
Événements Ethernet
| Paramètre | Description |
|---|---|
| Timestamp | Heure à laquelle l’événement s’est produit. |
| ActionType | Indique si l’événement était un événement de connexion ou de déconnexion. |
| bus_number | Identificateur de contrôleur spécifique, chaque périphérique USB peut en avoir plusieurs. |
| Nom de l’interface | Nom de l’interface. |
Événements de système de fichiers (collecteur basé sur les événements)
Le collecteur d’événements du système de fichiers collecte des événements chaque fois qu’il y a des modifications dans les répertoires de surveillance pour : création, suppression, déplacement et modification de répertoires et de fichiers. Pour définir les répertoires et les fichiers que vous souhaitez surveiller, consultez Paramètres spécifiques du collecteur d’informations système.
Les données suivantes sont collectées :
| Paramètre | Description |
|---|---|
| Timestamp | Heure à laquelle l’événement s’est produit. |
| Mask | Linux masque d’inotify lié à l’événement du système de fichiers, le masque identifie le type de l’action et peut être l’un des suivants : Access/Modified/Metadata changed/Closed/Opened/Moved/Created/Deleted. |
| Path | Chemin d’accès au répertoire/fichier dans lequel l’événement a été généré. |
| Hitcount | Nombre de fois où cet événement a été agrégé. |
Données de statistiques (collecteur basé sur un déclencheur)
Le collecteur de statistiques génère diverses statistiques sur les différents collecteurs de micro-agents. Ces statistiques fournissent des informations sur les performances des collecteurs au cours du cycle de collecte précédent. Parmi les statistiques possibles, citons le nombre d’événements qui ont été correctement envoyés et le nombre d’événements qui ont été supprimés, ainsi que les raisons des échecs.
Champs collectés :
| Paramètre | Description |
|---|---|
| Timestamp | Heure à laquelle l’événement s’est produit. |
| Nom | Nom du collecteur. |
| Événements | Tableau de paires au format JSON avec description et nombre d’accès. |
| Description | Indique si le message a été envoyé/supprimé et la raison de la suppression. |
| Hitcount | Nombre de messages respectifs. |
Agrégation d’événements pour les collecteurs de processus et de réseau
Fonctionnement de l’agrégation d’événements pour les événements de traitement et d’activité réseau :
Les agents Defender pour IoT agrègent les événements pendant l’intervalle d’envoi défini dans la configuration de la fréquence des messages pour chaque collecteur, tels que Process_MessageFrequency ou NetworkActivity_MessageFrequency. Une fois la période d’intervalle d’envoi écoulée, l’agent envoie les événements agrégés au cloud Azure pour une analyse plus approfondie. Les événements agrégés sont stockés en mémoire jusqu’à ce qu’ils soient envoyés au cloud Azure.
Lorsque l’agent collecte des événements similaires à ceux qui sont déjà stockés en mémoire, l’agent augmente le nombre d’accès de cet événement spécifique pour réduire l’empreinte mémoire de l’agent. Lorsque la fenêtre de temps d’agrégation s’écoule, l’agent envoie le nombre d’accès de chaque type d’événement qui s’est produit. L’agrégation d’événements est l’agrégation des nombres d’accès d’événements similaires. Par exemple, l’activité réseau avec le même hôte distant et sur le même port est agrégée en tant qu’événement unique, au lieu d’être un événement distinct pour chaque paquet.
Remarque
Par défaut, le micro-agent envoie des journaux et des données de télémétrie au cloud à des fins de résolution des problèmes et de surveillance. Ce comportement peut être configuré ou désactivé via le jumeau.
Prochaines étapes
Pour plus d’informations, reportez-vous aux rubriques suivantes :