Software Inventory Message and Attributes (SWIMA)

SWIMA è una specifica di protocollo, non un software che si installa da solo. Definisce i messaggi di richiesta e risposta che un sistema di valutazione (la parte che vuole sapere cosa è installato) e un endpoint (la macchina di cui si fa l'inventario) si scambiano durante una sessione di valutazione della postura. La specifica fissa la struttura del messaggio e gli attributi che ogni record software deve contenere. Qualunque client conforme e qualunque server conforme possono quindi interoperare, chiunque abbia realizzato ciascun lato.

L'obiettivo è eliminare le congetture dalla raccolta dell'inventario software. Invece di far interpretare a uno strumento di monitoraggio il formato proprietario emesso da ogni agente, SWIMA offre a entrambi i lati uno schema di messaggio condiviso e versionato. Individuare il software resta compito della scoperta degli asset IT; SWIMA standardizza come il risultato viene riportato.

SWIMA opera come tipo di messaggio all'interno del protocollo IF-M (Interface for Message) dell'architettura TNC. Il protocollo viaggia sul framework più ampio Network Endpoint Assessment (NEA), usato per il controllo d'accesso alla rete e per le verifiche di postura.

In pratica, lo scambio segue uno schema richiesta-risposta, con una sottoscrizione facoltativa:

1. 1

   Richiesta

   Il sistema di valutazione chiede tutto il software, un sottoinsieme o solo le modifiche.

2. 2

   Risposta

   L'endpoint restituisce i record corrispondenti con gli attributi standard.

3. 3

   Sottoscrizione

   Facoltativamente, l'endpoint invia messaggi quando un software viene installato, aggiornato o rimosso.

SWIMA è progettato per funzionare con i tag di identificazione del software (SWID). Un tag SWID è lo standard complementare che assegna a ogni prodotto software installato un record di identità strutturato: nome, versione, editore e un identificativo univoco del tag, di solito incorporato dal programma di installazione del software stesso. Un tag SWID identifica un singolo pezzo di software. SWIMA è il trasporto che permette a un endpoint di consegnare una raccolta di queste etichette, o le evidenze che ne derivano, a chi le richiede. Le due specifiche sono pensate per essere usate insieme: SWID definisce com'è fatto un record software, SWIMA definisce come viene riportato.

Un endpoint privo di tag SWID per una certa applicazione può comunque ricevere la richiesta di riportare altre evidenze raccolte, come il software identificato tramite l'insieme di attributi del record SWIMA. I risultati più solidi e più interoperabili, però, derivano dal software con tag SWID combinato al trasporto SWIMA.

I due standard coprono parti diverse dello stesso compito. La tabella mostra quale parte gestisce ciascuno:

SWIMA è una specifica formale e interoperabile, non uno standard de facto del settore. La maggior parte degli strumenti commerciali di inventario degli asset IT e di gestione degli endpoint raccoglie i dati sul software installato con protocolli di agent e insiemi di attributi proprietari, come System Center Configuration Manager (SCCM). Alcuni associano facoltativamente questi dati a campi di tipo SWID o SWIMA, per scambiarli con catene di strumenti governative o basate su standard.

SWIMA rientra nello sforzo più ampio Security Automation and Continuous Monitoring (SACM). SACM standardizza il modo in cui le organizzazioni verificano in modo continuo la postura di sicurezza dei propri endpoint, invece di affidarsi ad audit manuali periodici. I consumatori tipici dei dati SWIMA sono:

Gran parte della confusione su SWIMA nasce dalla domanda su cosa sia. Nei progetti di gestione degli asset software ricorrono tre errori:

• Cercare SWIMA come uno strumento da installare, quando definisce solo il formato del messaggio.
• Dare per scontato che ogni applicazione abbia un tag SWID. Il software senza tag può essere riportato con altre evidenze, ma i risultati più solidi richiedono software etichettato.
• Aspettarsi che SWIMA sostituisca l'agent di inventario. La maggior parte dei prodotti mantiene i propri protocolli di agent e associa i dati a SWIMA solo quando un'integrazione lo richiede.

Parti dalla domanda a cui l'inventario deve rispondere: quale software gira su quale endpoint, e con quale rapidità questa risposta deve cambiare. Se basta un elenco mensile, un formato di messaggio standard aggiunge poco. Se altri strumenti devono reagire a ogni installazione o rimozione, un reporting in stile SWIMA è giustificato. Lato prodotto, l'inventario software di Anexet legge i programmi installati tramite i propri agent sulle postazioni di lavoro, e i dati restano nell'infrastruttura del cliente.

In pratica, SWIMA conta soprattutto dove le organizzazioni devono dimostrare un monitoraggio continuo, interoperabile e standardizzato, per esempio per rispettare le linee guida federali sull'automazione. È raramente il meccanismo di raccolta quotidiano di un tipico prodotto commerciale di inventario.