Was SWIMA standardisiert
SWIMA ist eine Protokollspezifikation und keine Software, die man für sich allein installiert. Sie definiert die Anfrage- und Antwortnachrichten, die ein Bewertungssystem (die Seite, die wissen will, was installiert ist) und ein Endpunkt (der Rechner, dessen Inventar erfasst wird) während einer Sitzung zur Bewertung des Sicherheitszustands austauschen. Die Spezifikation legt den Aufbau der Nachricht und die Attribute fest, die jeder Software-Datensatz enthalten muss. Damit können beliebige konforme Clients und Server zusammenarbeiten, unabhängig davon, wer die jeweilige Seite gebaut hat.
Ziel ist es, Raterei bei der Erfassung des Software-Inventars zu beseitigen. Statt dass ein Überwachungswerkzeug das proprietäre Format jedes Agenten auswerten muss, erhalten beide Seiten ein gemeinsames, versioniertes Nachrichtenschema. Das Auffinden der Software selbst bleibt Aufgabe der automatischen Erkennung von IT-Assets; SWIMA standardisiert, wie das Ergebnis gemeldet wird.
Wie ein SWIMA-Austausch abläuft
SWIMA läuft als Nachrichtentyp innerhalb des Protokolls IF-M (Interface for Message) der TNC-Architektur. Dieses Protokoll wird über das übergeordnete Framework Network Endpoint Assessment (NEA) transportiert, das für Netzzugangskontrolle und Zustandsprüfungen eingesetzt wird.
In der Praxis folgt der Austausch einem Anfrage-Antwort-Muster mit optionalem Abonnement:
- 1
Anfrage
Das Bewertungssystem fordert die gesamte Software, eine Teilmenge oder nur Änderungen an.
- 2
Antwort
Der Endpunkt liefert passende Datensätze mit den Standardattributen.
- 3
Abonnement
Optional sendet der Endpunkt Nachrichten, wenn Software installiert, aktualisiert oder entfernt wird.
SWIMA und SWID-Tags
SWIMA ist für das Zusammenspiel mit Software-Identifikations-Tags (SWID) ausgelegt. Ein SWID-Tag ist der ergänzende Standard, der jedem installierten Softwareprodukt einen strukturierten Identitätsdatensatz gibt: Name, Version, Herausgeber und eine eindeutige Tag-ID, die meist vom Installationsprogramm der Software selbst eingebettet wird. Ein SWID-Tag kennzeichnet ein einzelnes Stück Software. SWIMA ist der Transportweg, über den ein Endpunkt eine Sammlung solcher Kennzeichnungen oder daraus abgeleitete Nachweise an denjenigen übergibt, der sie anfordert. Beide Spezifikationen sind für das Zusammenspiel gedacht: SWID legt fest, wie ein Software-Datensatz aussieht, und SWIMA legt fest, wie er gemeldet wird.
Ein Endpunkt ohne SWID-Tags für eine bestimmte Anwendung kann trotzdem aufgefordert werden, andere erfasste Nachweise zu melden, etwa Software, die über das Attributset des SWIMA-Datensatzes erkannt wurde. Die stärksten und am besten interoperablen Ergebnisse entstehen jedoch aus Software mit SWID-Tag in Verbindung mit SWIMA-Transport.
SWID-Tags und SWIMA im Vergleich
Beide Standards decken unterschiedliche Teile derselben Aufgabe ab. Die Tabelle zeigt, welchen Teil jeder übernimmt:
| Fähigkeit | SWID-Tag | SWIMA |
|---|---|---|
| Kennzeichnet ein Softwareprodukt mit Name, Version und Herausgeber | ||
| Legt die Nachrichten fest, die Software-Datensätze transportieren | ||
| Ermöglicht es dem anfragenden System, eine Teilmenge oder nur Änderungen abzufragen | ||
| Wird meist vom Installationsprogramm der Software selbst eingebettet |
Wo SWIMA eingesetzt wird
SWIMA ist eine formale, interoperable Spezifikation und kein faktischer Industriestandard. Die meisten kommerziellen Werkzeuge für IT-Asset-Inventar und Endpunktverwaltung erfassen installierte Software über eigene proprietäre Agentenprotokolle und Attributsätze, etwa System Center Configuration Manager (SCCM). Manche ordnen diese Daten optional SWID- oder SWIMA-ähnlichen Feldern zu, um sie mit behördlichen oder standardbasierten Toolketten auszutauschen.
SWIMA ist Teil des übergeordneten Vorhabens Security Automation and Continuous Monitoring (SACM). SACM standardisiert, wie Organisationen den Sicherheitszustand ihrer Endpunkte fortlaufend prüfen, statt sich auf periodische manuelle Audits zu verlassen. Typische Abnehmer von SWIMA-Daten sind:
| Abnehmer | Was er mit den Daten macht |
|---|---|
| Netzzugangskontrollsysteme (NAC) | Prüfen die installierte Software, bevor entschieden wird, ob ein Gerät sich verbinden darf |
| Plattformen für kontinuierliches Monitoring | Lassen Werkzeuge verschiedener Hersteller in eine gemeinsame Monitoring-Pipeline einspeisen |
| Werkzeuge für Schwachstellenmanagement | Gleichen installierte Produkte mit bekannten Schwachstellenhinweisen ab |
Typische Fehler
Viele Missverständnisse über SWIMA beginnen mit der Frage, was es überhaupt ist. Bei Projekten zur Software-Asset-Verwaltung treten drei Fehler häufig auf:
- SWIMA als installierbares Werkzeug suchen, obwohl es nur das Nachrichtenformat definiert.
- Annehmen, jede Anwendung besitze ein SWID-Tag. Software ohne Tag lässt sich zwar über andere Nachweise melden, die stärksten Ergebnisse erfordern aber gekennzeichnete Software.
- Erwarten, dass SWIMA den Inventar-Agenten ersetzt. Die meisten Produkte behalten ihre eigenen Agentenprotokolle und ordnen Daten SWIMA nur zu, wenn eine Integration es verlangt.
Wo man anfängt
Beginnen Sie mit der Frage, die das Inventar beantworten muss: Welche Software läuft auf welchem Endpunkt, und wie schnell muss sich diese Antwort ändern? Reicht eine monatliche Liste, bringt ein standardisiertes Nachrichtenformat wenig. Müssen andere Werkzeuge auf jede Installation oder Entfernung reagieren, lohnt sich SWIMA-artige Meldung. Auf Produktseite liest die Software-Inventarisierung von Anexet installierte Programme über eigene Agenten auf den Arbeitsplätzen aus, und die Daten bleiben in der Infrastruktur des Kunden.
In der Praxis ist SWIMA vor allem dort wichtig, wo Organisationen nachweisen müssen, dass ihr kontinuierliches Monitoring interoperabel und standardisiert ist, etwa um behördliche Vorgaben zur Automatisierung zu erfüllen. Im Alltag eines typischen kommerziellen Inventarprodukts ist es selten der Mechanismus der Datenerfassung.
Eine Standardnachricht hilft nur, wenn beide Seiten sich einig sind, was ein Software-Datensatz bedeutet.
Anexet Team