Software Inventory Message and Attributes (SWIMA)

SWIMA to specyfikacja protokołu, a nie program, który instaluje się samodzielnie. Określa komunikaty żądania i odpowiedzi, którymi wymieniają się system oceny (strona, która chce wiedzieć, co jest zainstalowane) i punkt końcowy (komputer, którego oprogramowanie jest spisywane) podczas sesji oceny stanu bezpieczeństwa. Specyfikacja ustala strukturę komunikatu oraz atrybuty, które musi mieć każdy rekord oprogramowania. Dzięki temu dowolny zgodny klient i dowolny zgodny serwer mogą ze sobą współpracować, bez względu na to, kto zbudował każdą ze stron.

Celem jest wyeliminowanie zgadywania przy zbieraniu inwentaryzacji oprogramowania. Zamiast tego, by narzędzie monitorujące analizowało zastrzeżony format emitowany przez agenta, SWIMA daje obu stronom wspólny, wersjonowany schemat komunikatu. Samo wykrycie oprogramowania pozostaje zadaniem automatycznego wykrywania zasobów IT; SWIMA standaryzuje sposób raportowania wyniku.

SWIMA działa jako typ komunikatu w ramach protokołu IF-M (Interface for Message) architektury TNC. Protokół ten jest przenoszony przez szersze ramy Network Endpoint Assessment (NEA), używane do kontroli dostępu do sieci i sprawdzania stanu punktów końcowych.

W praktyce wymiana przebiega według schematu żądanie-odpowiedź, z opcjonalną subskrypcją:

1. 1

   Żądanie

   System oceny prosi o całe oprogramowanie, jego część albo tylko zmiany.

2. 2

   Odpowiedź

   Punkt końcowy zwraca pasujące rekordy ze standardowymi atrybutami.

3. 3

   Subskrypcja

   Opcjonalnie punkt końcowy wysyła komunikaty, gdy oprogramowanie zostanie zainstalowane, zaktualizowane lub usunięte.

SWIMA została zaprojektowana do współpracy ze znacznikami identyfikacji oprogramowania (SWID). Znacznik SWID to standard towarzyszący, który nadaje każdemu zainstalowanemu produktowi strukturalny rekord tożsamości: nazwę, wersję, wydawcę i unikalny identyfikator znacznika, zwykle osadzony przez instalator samego oprogramowania. Znacznik SWID oznacza jeden program. SWIMA to transport, dzięki któremu punkt końcowy przekazuje zbiór takich znaczników lub dowody z nich wyprowadzone każdemu, kto o nie zapyta. Obie specyfikacje mają działać razem: SWID określa, jak wygląda rekord oprogramowania, a SWIMA określa, jak jest raportowany.

Punkt końcowy bez znaczników SWID dla danej aplikacji może nadal zostać poproszony o inne zebrane dowody, na przykład o oprogramowanie zidentyfikowane przez własny zestaw atrybutów rekordu SWIMA. Najsilniejsze i najlepiej współdziałające wyniki dają jednak programy oznaczone znacznikiem SWID przesyłane transportem SWIMA.

Oba standardy obejmują różne części tego samego zadania. Tabela pokazuje, którą część obsługuje każdy z nich:

SWIMA to formalna, współdziałająca specyfikacja, a nie de facto standard branżowy. Większość komercyjnych narzędzi do inwentaryzacji zasobów IT i zarządzania punktami końcowymi zbiera dane o zainstalowanym oprogramowaniu za pomocą własnych, zastrzeżonych protokołów agentów i zestawów atrybutów, jak System Center Configuration Manager (SCCM). Niektóre mapują te dane opcjonalnie na pola w stylu SWID lub SWIMA, aby wymieniać je z łańcuchami narzędzi rządowych lub opartych na standardach.

SWIMA mieści się w szerszym przedsięwzięciu Security Automation and Continuous Monitoring (SACM). SACM standaryzuje sposób, w jaki organizacje ciągle weryfikują stan bezpieczeństwa swoich punktów końcowych, zamiast polegać na okresowych ręcznych audytach. Typowi odbiorcy danych SWIMA to:

Większość nieporozumień wokół SWIMA zaczyna się od pytania, czym ona jest. W projektach zarządzania oprogramowaniem powtarzają się trzy błędy:

• Szukanie SWIMA jako narzędzia do zainstalowania, podczas gdy to tylko format komunikatu.
• Zakładanie, że każda aplikacja ma znacznik SWID. Oprogramowanie bez niego może nadal być raportowane innymi dowodami, ale najmocniejsze wyniki wymagają oprogramowania ze znacznikami.
• Oczekiwanie, że SWIMA zastąpi agenta inwentaryzacji. Większość produktów zachowuje własne protokoły agentów i mapuje dane na SWIMA tylko wtedy, gdy integracja tego wymaga.

Zacznij od pytania, na które inwentaryzacja ma odpowiedzieć: jakie oprogramowanie działa na jakim punkcie końcowym i jak szybko ta odpowiedź musi się zmieniać. Jeśli wystarczy miesięczna lista, standardowy format komunikatu niewiele daje. Jeśli inne narzędzia muszą reagować na każdą instalację lub usunięcie, raportowanie w stylu SWIMA się opłaca. Po stronie produktu inwentaryzacja oprogramowania w Anexet odczytuje zainstalowane programy przez własne agenty na stacjach roboczych, a dane pozostają w infrastrukturze klienta.

W praktyce SWIMA ma największe znaczenie tam, gdzie organizacje muszą wykazać współdziałający, znormalizowany ciągły monitoring, na przykład by spełnić federalne wytyczne dotyczące automatyzacji. Rzadko jest codziennym mechanizmem zbierania danych w typowym komercyjnym produkcie inwentaryzacyjnym.