Collecte d’événements du micro-agent
Les agents de sécurité Defender pour IoT recueillent des données et des événements système sur votre appareil local et envoient ces données au cloud Azure à des fins de 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 apparaissent dans Log Analytics. Pour plus d’informations, consultez Tutoriel : examiner des alertes de sécurité.
Le micro-agent Defender pour IoT collecte de nombreux types d’événements d’appareil, dont des événements liés à de nouveaux processus et connexions. Ces types d’événements peuvent se produire fréquemment sur un appareil. Si cette capacité est importante pour assurer une sécurité complète, le nombre de messages que les agents de sécurité envoient peut rapidement atteindre ou dépasser les limites de quotas et de coûts de votre IoT Hub. Ces messages et ces é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 regroupent les types d’événements suivants :
Événements liés aux processus (Linux uniquement)
Événements liés à l’activité réseau
Événements de système de fichiers
Événements 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 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 les déclencheurs sont des collecteurs qui sont déclenchés de manière planifiée en fonction des configurations du client.
Événements liés aux processus (collecteur basé sur un événement)
Les événements de processus sont pris en charge sur les système d'exploitation Linux.
Ceux-ci sont considérés comme identiques lorsque la ligne de commande et le userid sont identiques.
La mémoire tampon par défaut des événements de processus s’élève à 256 processus. Lorsque cette limite est atteinte, la mémoire tampon est recyclée et l’événement de processus le plus ancien est ignoré afin de libérer de l’espace pour le dernier événement traité. Un avertissement pour augmenter la taille du cache est journalisé.
Données collectées pour chaque événement :
| Paramètre | Description |
|---|---|
| Timestamp | Première fois que le processus a été observé. |
| process_id | PID Linux. |
| parent_process_id | PID parent de Linux, s’il existe. |
| Commandline | Ligne de commande. |
| Type | Peut être fork ou exec. |
| hit_count | Nombre agrégé. Nombre d’exécutions du même processus, pendant le même laps de temps, jusqu’à ce que les événements soient envoyés au cloud. |
Événements liés à l’activité réseau (collecteur basé sur un événement)
Les événements liés à l’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 lié à l’activité réseau est de 256. Dans les situations où le cache est plein :
Appareils Eclipse ThreadX : aucun nouvel événement réseau n’est mis en cache jusqu’au début du cycle de collecte suivant.
Appareils Linux : l’événement le plus ancien sera remplacé par chaque événement nouveau. Un avertissement pour augmenter la taille du cache est journalisé.
Pour les appareils Linux, seul IPv4 est pris en charge.
Données collectées pour chaque événement :
| 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 | Somme des octets RX agrégés de la connexion. |
| Bytes_out | Somme des 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. |
| Hit count | Nombre de paquets observés |
Collecteur de connexion (collecteur basé sur les événements)
Le collecteur de connexion collecte les connexions utilisateur, les déconnexions et les tentatives de connexion ayant échoué.
Le collecteur de connexion prend en charge les types de méthodes de collecte suivants :
UTMP et SYSLOG. UTMP intercepte les événements interactifs SSH, les événements telnet et les connexions à partir d’un terminal, ainsi que tous les échecs de connexion à partir de SSH, de telnet et d’un terminal. Si SYSLOG est activé sur l’appareil, le collecteur de connexion collecte également les événements de connexion SSH via le fichier SYSLOG nommé auth.log.
Modules d’authentification enfichables (PAM) Collectent les événements SSH, Telnet et de connexion locale. Pour plus d’informations, consultez Configurer les modules d’authentification enfichables (PAM) pour auditer les événements de connexion.
Les données suivantes sont collectées :
| Paramètre | Description |
|---|---|
| opération | L’une des valeurs suivantes : Login, Logout, LoginFailed |
| process_id | PID Linux. |
| user_name | Utilisateur Linux. |
| Exécutable | Appareil terminal. Par exemple, tty1..6 ou pts/n. |
| remote_address | Source de la 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)
Données collectées pour chaque événement :
| Paramètre | Description |
|---|---|
| hardware_vendor | Nom du fournisseur de l’appareil. |
| hardware_model | Numéro de modèle du périphérique. |
| os_dist | Distribution du système d’exploitation. Par exemple : Linux. |
| os_version | Version du système d’exploitation. Par exemple, Windows 10 ou 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. |
| Cartes réseau | Contrôleur d’interface réseau. La liste complète des propriétés est indiquée ci-dessous. |
Les propriétés des cartes réseau sont composées des éléments suivants :
| Paramètre | Description |
|---|---|
| type | Une des valeurs suivantes : UNKNOWN, ETH, WIFI, MOBILE ou SATELLITE. |
| vlans | Réseau local virtuel associé à l’interface réseau. |
| vendor | Fournisseur du contrôleur de réseau. |
| info | Adresses IP et Mac associées au contrôleur de réseau. Notamment les champs suivants : - ipv4_address : adresse IPv4. - ipv6_address : adresse IPv6. - mac : adresse MAC. |
Référence (collecteur basé sur un déclencheur)
Le collecteur de référence procède à des vérifications CIS périodiques, dont les résultats de type Échec, Réussite et Ignorer sont envoyés au service cloud Defender pour IoT. Defender pour IoT agrège les résultats et fournit des recommandations en fonction des éventuelles défaillances.
Données collectées pour chaque événement :
| Paramètre | Description |
|---|---|
| ID de contrôle | Au format CIS. Par exemple : CIS-debian-9-Filesystem-1.1.2. |
| Résultat de la vérification | Peut être Fail, Pass, Skip ou Error. Par exemple, Error dans une situation où le contrôle ne peut pas être effectué. |
| Error | Information et description de l’erreur. |
| Description | Description du contrôle depuis CIS. |
| Correction | Recommandation pour la correction depuis 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 |
|---|---|
| Nom | Nom du package. |
| Version | Version du package. |
| Fournisseur | Fournisseur du package, qui correspond au champ Maintainer dans les packages deb. |
Événements périphériques (collecteur basé sur un événement)
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 | Moment où 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 chaque fois que l’appareil est connecté. |
| device_class | Identificateur spécifiant la classe d’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 | Moment où 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 liés au système de fichiers (collecteur basé sur un événement)
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 fichiers que vous souhaitez surveiller, consultez Paramètres spécifiques au collecteur d’informations système.
Les données suivantes sont collectées :
| Paramètre | Description |
|---|---|
| Timestamp | Moment où l’événement s’est produit. |
| Masque | Masque d’inotification Linux lié à l’événement du système de fichiers, le masque identifie le type de l’action et peut être l’un des éléments suivants : Access/Modified/Metadata changed/Closed/Opened/Moved/Created/Deleted. |
| Chemin d’accès | 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 statistiques (collecteur basé sur un déclencheur)
Le collecteur de statistiques génère différentes 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. Les exemples de statistiques possibles incluent le nombre d’événements qui ont été envoyés avec succè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 | Moment où l’événement s’est produit. |
| Nom | Nom du collecteur. |
| Événements | Tableau de paires au format JSON avec description et nombre de résultats. |
| 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 liés aux processus et les événements liés à l’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, par exemple 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 poussée. 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, il augmente le nombre d’accès de cet événement afin de réduire l’empreinte mémoire de l’agent. Quand la fenêtre de temps d’agrégation se termine, l’agent envoie le nombre d’accès à chaque type d’événement survenu. 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 un seul événement, au lieu d’avoir un événement distinct pour chaque paquet.
Notes
Par défaut, le micro-agent envoie les journaux et les données de télémétrie au cloud à des fins de résolution des problèmes et de supervision. Ce comportement peut être configuré ou désactivé via le jumeau.
Étapes suivantes
Pour plus d'informations, consultez les pages suivantes :
- Configurations du micro-agent
- Examinez vos Alertes de sécurité IoT.