Software Inventory Message and Attributes (SWIMA)

SWIMA est une spécification de protocole, et non un logiciel que l'on installe seul. Elle définit les messages de requête et de réponse qu'échangent un système d'évaluation (la partie qui veut savoir ce qui est installé) et un endpoint (la machine dont on fait l'inventaire) pendant une session d'évaluation de posture. La spécification fixe la structure du message et les attributs que chaque enregistrement logiciel doit porter. Tout client conforme et tout serveur conforme peuvent donc interopérer, quel que soit le constructeur de chaque côté.

L'objectif est de supprimer les approximations dans la collecte de l'inventaire logiciel. Plutôt que de faire analyser par un outil de supervision le format propriétaire émis par chaque agent, SWIMA donne aux deux parties un schéma de message commun et versionné. La découverte des logiciels reste le travail de la découverte des actifs IT ; SWIMA normalise la manière dont le résultat est remonté.

SWIMA fonctionne comme un type de message à l'intérieur du protocole IF-M (Interface for Message) de l'architecture TNC. Ce protocole est porté par le cadre plus large Network Endpoint Assessment (NEA), utilisé pour le contrôle d'accès réseau et les vérifications de posture.

En pratique, l'échange suit un schéma requête-réponse, avec un abonnement facultatif :

1. 1

   Requête

   Le système d'évaluation demande tous les logiciels, un sous-ensemble ou uniquement les changements.

2. 2

   Réponse

   L'endpoint renvoie les enregistrements correspondants avec les attributs standard.

3. 3

   Abonnement

   En option, l'endpoint envoie des messages lorsqu'une installation, une mise à jour ou une suppression a lieu.

SWIMA est conçu pour fonctionner avec les tags d'identification logicielle (SWID). Un tag SWID est la norme complémentaire qui donne à chaque produit logiciel installé un enregistrement d'identité structuré : nom, version, éditeur et identifiant de tag unique, généralement intégré par le programme d'installation du logiciel lui-même. Un tag SWID désigne un seul logiciel. SWIMA est le transport qui permet à un endpoint de remettre un ensemble de ces étiquettes, ou les preuves qui en découlent, à celui qui les demande. Les deux spécifications sont faites pour être utilisées ensemble : SWID définit la forme d'un enregistrement logiciel, et SWIMA définit la manière de le remonter.

Un endpoint sans tags SWID pour une application donnée peut tout de même être sollicité pour remonter d'autres preuves collectées, comme un logiciel identifié grâce à l'ensemble d'attributs de l'enregistrement SWIMA lui-même. Les résultats les plus solides et les plus interopérables viennent toutefois de logiciels étiquetés SWID combinés au transport SWIMA.

Les deux normes couvrent des parties différentes d'un même travail. Le tableau montre ce que prend en charge chacune :

SWIMA est une spécification formelle et interopérable, et non une norme de fait du secteur. La plupart des outils commerciaux d'inventaire d'actifs IT et de gestion des endpoints collectent les données logicielles avec leurs propres protocoles d'agent et jeux d'attributs propriétaires, comme System Center Configuration Manager (SCCM). Certains associent ces données, en option, à des champs de type SWID ou SWIMA, pour les échanger avec des chaînes d'outils publiques ou fondées sur des normes.

SWIMA s'inscrit dans l'effort plus large Security Automation and Continuous Monitoring (SACM). SACM normalise la manière dont les organisations vérifient en continu la posture de sécurité de leurs endpoints, au lieu de s'appuyer sur des audits manuels périodiques. Les consommateurs typiques des données SWIMA sont :

Une grande partie de la confusion autour de SWIMA vient de la question de ce qu'il est. Trois erreurs reviennent souvent dans les projets de gestion des actifs logiciels :

• Chercher SWIMA comme un outil à installer, alors qu'il ne définit que le format de message.
• Supposer que chaque application possède un tag SWID. Un logiciel sans tag peut tout de même être remonté par d'autres preuves, mais les résultats les plus solides exigent des logiciels étiquetés.
• Espérer que SWIMA remplace l'agent d'inventaire. La plupart des produits conservent leurs propres protocoles d'agent et ne font correspondre leurs données à SWIMA que lorsqu'une intégration le demande.

Partez de la question à laquelle l'inventaire doit répondre : quel logiciel tourne sur quel endpoint, et à quelle vitesse cette réponse doit-elle évoluer ? Si une liste mensuelle suffit, un format de message standard apporte peu. Si d'autres outils doivent réagir à chaque installation ou suppression, un reporting de type SWIMA se justifie. Côté produit, l'inventaire logiciel d'Anexet lit les programmes installés grâce à ses propres agents sur les postes de travail, et les données restent dans l'infrastructure du client.

En pratique, SWIMA compte surtout là où les organisations doivent démontrer une supervision continue, interopérable et normalisée, par exemple pour répondre à des recommandations fédérales en matière d'automatisation. Il est rarement le mécanisme de collecte quotidien d'un produit d'inventaire commercial classique.