Software Inventory Message and Attributes (SWIMA)

SWIMA es una especificación de protocolo, no un software que se instale por sí solo. Define los mensajes de solicitud y respuesta que intercambian un sistema de evaluación (la parte que quiere saber qué está instalado) y un endpoint (la máquina que se inventaría) durante una sesión de evaluación de postura. La especificación fija la estructura del mensaje y los atributos que debe tener cada registro de software. Por eso, cualquier cliente y cualquier servidor conformes pueden interoperar, sin importar quién construyó cada lado.

El objetivo es eliminar las conjeturas en la recolección del inventario de software. En lugar de que una herramienta de monitoreo interprete el formato propietario que emite cada agente, SWIMA da a ambos lados un esquema de mensaje único y versionado. Encontrar el software sigue siendo tarea del descubrimiento automatizado de activos de TI; SWIMA estandariza cómo se reporta el resultado.

SWIMA funciona como un tipo de mensaje dentro del protocolo IF-M (Interface for Message) de la arquitectura TNC. Ese protocolo se transporta sobre el marco más amplio Network Endpoint Assessment (NEA), que se usa para el control de acceso a la red y las verificaciones de postura.

En la práctica, el intercambio sigue un patrón de solicitud y respuesta, con una suscripción opcional:

1. 1

   Solicitud

   El sistema de evaluación pide todo el software, un subconjunto o solo los cambios.

2. 2

   Respuesta

   El endpoint devuelve los registros coincidentes con los atributos estándar.

3. 3

   Suscripción

   Opcionalmente, el endpoint envía mensajes cuando se instalan, actualizan o eliminan programas.

SWIMA está diseñada para trabajar con etiquetas de identificación de software (SWID). Una etiqueta SWID es el estándar complementario que da a cada producto de software instalado un registro estructurado de identidad: nombre, versión, editor y un ID de etiqueta único, normalmente incrustado por el instalador del propio software. Una etiqueta SWID identifica una sola pieza de software. SWIMA es el transporte que permite al endpoint entregar un conjunto de esas etiquetas, o evidencia derivada de ellas, a quien las pida. Las dos especificaciones están pensadas para usarse juntas: SWID define cómo es un registro de software y SWIMA define cómo se reporta.

Un endpoint sin etiquetas SWID para una aplicación determinada todavía puede recibir la solicitud de reportar otra evidencia recopilada, como software identificado mediante el conjunto de atributos del propio registro SWIMA. Sin embargo, los resultados más sólidos e interoperables provienen de software con etiqueta SWID combinado con el transporte SWIMA.

Los dos estándares cubren partes distintas del mismo trabajo. La tabla muestra qué parte maneja cada uno:

SWIMA es una especificación formal e interoperable, no un estándar de facto de la industria. La mayoría de las herramientas comerciales de inventario de activos de TI y de gestión de endpoints recopila los datos de software instalado con sus propios protocolos de agente y conjuntos de atributos, como el System Center Configuration Manager (SCCM). Algunas asignan esos datos, de forma opcional, a campos de estilo SWID o SWIMA para intercambiarlos con cadenas de herramientas gubernamentales o basadas en estándares.

SWIMA forma parte del esfuerzo más amplio de Security Automation and Continuous Monitoring (SACM). SACM estandariza cómo las organizaciones verifican de forma continua la postura de seguridad de sus endpoints, en lugar de depender de auditorías manuales periódicas. Los consumidores típicos de los datos de SWIMA incluyen:

Gran parte de la confusión sobre SWIMA empieza en la pregunta de qué es. En proyectos de gestión de activos de software aparecen con frecuencia tres errores:

• Buscar SWIMA como una herramienta para instalar, cuando solo define el formato del mensaje.
• Suponer que toda aplicación tiene una etiqueta SWID. El software sin etiqueta puede reportarse con otra evidencia, pero los resultados más sólidos requieren software etiquetado.
• Esperar que SWIMA reemplace al agente de inventario. La mayoría de los productos conserva sus propios protocolos de agente y asigna los datos a SWIMA solo cuando una integración lo necesita.

Empiece por la pregunta que el inventario debe responder: qué software se ejecuta en cada endpoint y con qué rapidez debe cambiar esa respuesta. Si basta una lista mensual, un formato de mensaje estándar aporta poco. Si otras herramientas deben reaccionar a cada instalación o eliminación, el reporte al estilo SWIMA se justifica. Del lado del producto, el inventario de software de Anexet lee los programas instalados mediante sus propios agentes en las estaciones de trabajo, y los datos permanecen en la infraestructura del cliente.

En la práctica, SWIMA importa más donde las organizaciones deben demostrar un monitoreo continuo, interoperable y estandarizado, por ejemplo para cumplir con lineamientos federales de automatización. Rara vez es el mecanismo de recolección cotidiano dentro de un producto comercial típico de inventario.