CERT Polska w komunikacie z 25 sierpnia informuje o podatnościach Cisco Crosswork oraz Cisco Secure Workload; dla tego drugiego produktu komunikat obejmuje wariant SaaS i instalacje lokalne. Dla organizacji korzystających z tych produktów zadaniem jest rozdzielenie odpowiedzialności za aktualizacje oraz zebranie potwierdzeń odnoszących się do używanego wariantu. Informację o usłudze dostawcy i stan własnej instalacji oceńmy osobno.

Czy odpowiedź „dostawca zajmuje się aktualizacjami” wystarczy, by zamknąć sprawę podatności Secure Workload? Zanim ją zaakceptujemy, ustalmy, czy dotyczy usługi SaaS, instalacji lokalnej, czy obu wariantów używanych przez organizację. Komunikat CERT Polska daje konkretny powód do takiego rozróżnienia: obejmuje oba modele wdrożenia. Proponujemy więc zacząć przegląd od przypisania każdej używanej usłudze lub instalacji osoby, która potwierdzi jej stan. W tym przeglądzie oddzielmy wykonawcę aktualizacji od osoby zbierającej dowody dla organizacji. Przy Secure Workload pytanie o odpowiedzialność powinno prowadzić do ustalenia, kto wykona zmianę, skąd otrzymamy potwierdzenie i do którego wdrożenia będzie się ono odnosiło. Tak sformułowane zadanie pozwala określić warunek jego zakończenia.

Crosswork i Secure Workload wymagają osobnego sprawdzenia

Według komunikatu CERT Polska w Cisco Crosswork występują błędy SQL injection oraz uwierzytelniania. W Cisco Secure Workload opisano błędy kontroli dostępu i wstrzykiwania poleceń, a zakres informacji obejmuje SaaS oraz instalacje lokalne. Przy przekazywaniu alertu administratorom zachowajmy to przyporządkowanie: nazwa produktu powinna towarzyszyć opisowi problemu, którego dotyczy.

Na potrzeby przeglądu Crosswork zapiszmy, które używane instalacje sprawdzamy. Dla Secure Workload dodajmy do tego rozróżnienie modelu wdrożenia. Nie przenośmy ustalenia dotyczącego SaaS na instalację lokalną bez jej weryfikacji. Jeżeli organizacja korzysta z obu wariantów, przygotujmy osobne miejsca na wynik sprawdzenia każdego z nich, nawet gdy koordynuje je ta sama osoba.

Szczegółowy przebieg wykorzystania tych błędów pozostawmy poza oceną wykonania aktualizacji. Informacje o rodzajach podatności nie opisują zdarzenia w konkretnej organizacji. W przeglądzie Crosswork i Secure Workload skupmy się zatem na pytaniu, jakie wdrożenia mamy i jakie potwierdzenia ich stanu zebraliśmy. Nie przypisujmy użytkownikom produktów incydentu na podstawie samej informacji o podatnościach.

Potwierdzenie aktualizacji Secure Workload powinno wskazywać konkretną usługę SaaS albo konkretną instalację lokalną.

Status „zaktualizowano” powinien wskazywać wdrożenie

Jako test własnej procedury rozważmy hipotetyczne zgłoszenie dotyczące Secure Workload, zamknięte po otrzymaniu wiadomości o aktualizacji usługi SaaS. Jeśli organizacja używa również instalacji lokalnej, przed zamknięciem całego zadania zażądajmy osobnego potwierdzenia jej stanu. To propozycja kontroli procedury; komunikat CERT Polska nie opisuje takiego zaniedbania u konkretnego użytkownika.

W zgłoszeniu dotyczącym Secure Workload zapiszmy, czego dokładnie dowodzi otrzymana wiadomość. Czy identyfikuje usługę używaną przez organizację? Czy potwierdza wykonanie aktualizacji, czy dopiero jej plan? Czy podaje wersję, której dotyczy potwierdzenie? Gdy odpowiedź pozostaje nieznana, odnotujmy brak i przypiszmy jego wyjaśnienie osobie prowadzącej kontakt z dostawcą.

Dla lokalnego Secure Workload oraz używanych instalacji Crosswork poprośmy administratora o zapis wersji po zmianie, datę sprawdzenia i wskazanie instalacji. Ustalmy również miejsce przechowywania tego zapisu, aby osoba odbierająca zadanie mogła go odszukać. Przyjmijmy zasadę, że samo przesłanie alertu, zaplanowanie prac lub przypisanie wykonawcy nie wystarcza do oznaczenia aktualizacji jako zakończonej.

Zarząd powinien otrzymać stan prac dla każdego wariantu

W informacji zarządczej o Crosswork i Secure Workload proponujemy pokazać zakres użycia, odpowiedzialną osobę oraz podstawę oceny stanu aktualizacji. Dla SaaS wskażmy osobę, która uzyska potwierdzenie od dostawcy. Dla instalacji lokalnej wskażmy wykonawcę zmiany i osobę sprawdzającą wynik. Jeżeli podziału obowiązków jeszcze nie ma, nazwijmy go otwartym zadaniem.

Przy Secure Workload uzgodnijmy wcześniej, jaki dokument lub zapis będzie podstawą odbioru prac dotyczących każdego wariantu. Poprośmy o potwierdzenie wersji usługi SaaS i instalacji lokalnej, jeśli organizacja używa obu. Jeśli nie uda się uzyskać oznaczenia wersji usługi, zapiszmy tę informację jako nieustaloną i określmy, kto wyjaśni ją z dostawcą. Nie wpisujmy wersji na podstawie przypuszczenia.

Do notatki o Crosswork i Secure Workload nie dopisujmy szacunków strat ani czasu przestoju. Sam opis podatności nie daje podstaw do takich wyliczeń. Zamiast deklarować koszt aktualizacji, zlećmy jego ustalenie właścicielowi konkretnego wdrożenia, jeśli jest potrzebny do decyzji. Raport powinien jasno oddzielać zebrane potwierdzenia od zadań, które dopiero czekają na wykonanie.

Odpowiedzialność za ocenę stanu Secure Workload przypiszmy także wtedy, gdy aktualizację wykonuje dostawca usługi SaaS.

Komunikat CERT Polska jest punktem wyjścia do własnej kontroli

Polskim punktem odniesienia jest komunikat CERT Polska z 25 sierpnia. Informacje o podatnościach nie określają liczby krajowych użytkowników Crosswork ani Secure Workload. Nie pozwalają również przypisać polskiej organizacji konkretnego incydentu. W informacji wewnętrznej zachowajmy więc rozróżnienie między zakresem ostrzeżenia a ustaleniami dotyczącymi własnych wdrożeń.

Dla polskiego odbiorcy proponujemy rozpoczęcie od przekazania komunikatu CERT Polska osobom odpowiedzialnym za wymienione produkty. Do wiadomości dołączmy prośbę o wskazanie używanego wariantu i podstawy potwierdzenia aktualizacji. Jeżeli odbiorca nie odpowiada za dany produkt, poprośmy o ustalenie właściwego właściciela zadania. Nie zastępujmy tego ustalenia ogólnym przekazaniem alertu do całego działu.

Co z tym zrobić w poniedziałek

Każdą z poniższych czynności ogranicz do 30 minut. To przygotowanie i sprawdzenie zakresu prac przy Crosswork i Secure Workload; wykonanie aktualizacji wymaga odrębnego zadania.

  1. Rozpisz używane wdrożenia. W dostępnej ewidencji wyszukaj Crosswork i Secure Workload. Przy Secure Workload oznacz SaaS lub instalację lokalną. Braki zapisz jako nieustalone i wskaż osobę, która uzupełni ewidencję.
  2. Przypisz odpowiedzialność. Dla SaaS wskaż osobę zbierającą potwierdzenie od dostawcy, a dla instalacji lokalnych wykonawcę aktualizacji i osobę odbierającą wynik. Zapisz brakujące ustalenia oraz termin ich wyjaśnienia.
  3. Zbierz dostępne potwierdzenia. Do każdego wdrożenia Crosswork i Secure Workload dołącz posiadany zapis wersji i stanu aktualizacji. Tam, gdzie go brakuje, przygotuj konkretne zapytanie do dostawcy lub administratora; pozostaw status otwarty do weryfikacji.

Dla Secure Workload przyjmijmy odrębne warunki potwierdzenia aktualizacji SaaS i instalacji lokalnej. Crosswork również powinien mieć przypisane dowody dotyczące używanych instalacji. O zakończeniu przeglądu decydujmy na podstawie tych zapisów, z jawnym wskazaniem każdej informacji, której nadal brakuje.

Źródła

  1. CERT Polska: Podatności w produktach Cisco Crosswork oraz Cisco Secure Workload, publikacja: 25 sierpnia 2026.

Redakcja cyberinsight.pl.