CERT Polska w komunikacie z 14 września opisuje błąd przetwarzania XML w PAN-OS. Według zespołu atak może prowadzić do wykonania kodu z prawami root na PA-Series lub odmowy usługi na VM-Series. Dla zarządzających bezpieczeństwem to powód, by rozdzielić ocenę wdrożeń sprzętowych i wirtualnych, a przy usługach chmurowych osobno ustalić zakres ryzyka oraz odpowiedzialność za aktualizacje.

Czy odpowiedź „sprawdzamy PAN-OS” wystarczy, żeby ocenić reakcję firmy na ostrzeżenie? Poprośmy o doprecyzowanie, jakie wdrożenie sprawdzamy, kto ustala dostępność jego interfejsów i kto odpowiada za cykl aktualizacji. Proponujemy potraktować komunikat CERT Polska jako początek takiej rozmowy. Na jej potrzeby przygotujmy osobne pozycje dla sprzętu, maszyn wirtualnych i usług chmurowych, o ile występują w organizacji. Przy każdej zapiszmy potwierdzone ustalenia oraz pytania pozostające bez odpowiedzi. Wynik przeglądu oprzyjmy na ustaleniach dotyczących poszczególnych wdrożeń. Zarząd powinien otrzymać informację dotyczącą konkretnego wdrożenia, z osobą odpowiedzialną za dalsze ustalenia i terminem ich przekazania.

Błąd XML w PAN-OS wymaga rozróżnienia skutków

W opisie CERT Polska wspólnym punktem jest błąd przetwarzania XML. CERT przypisuje każdy skutek do innego produktu: wykonanie kodu z prawami root dotyczy PA-Series, a odmowa usługi dotyczy VM-Series.

Przygotujmy oddzielne pytania o konsekwencje dla własnego środowiska. Przy PA-Series poprośmy zespół o ocenę scenariusza wykonania kodu z opisanymi uprawnieniami. Przy VM-Series zlećmy ustalenie, czego w organizacji dotyczyłaby odmowa usługi. Przewidywany czas przerwy i kwotę strat oszacujmy na podstawie ustaleń dotyczących konkretnej instalacji.

Ocenę ryzyka PAN-OS przypiszmy do rodzaju wdrożenia, zanim stanie się podstawą decyzji zarządu.

Opis mechanizmu traktujmy jako podstawę pytań technicznych. Własną ocenę konsekwencji oznaczmy osobno, aby odbiorca wiedział, które ustalenia pochodzą od CERT Polska, a które wymagają pracy zespołu.

Przegląd dostępu wymaga potwierdzenia wykonania procedury

Dla PA-Series i VM-Series proponujemy zestawić zapisy procedury z ustaleniami dotyczącymi rzeczywistego wdrożenia. Jeżeli dokumentacja przewiduje przegląd dostępu, poprośmy o wskazanie interfejsów objętych sprawdzeniem, zakresu dostępności i daty ostatniej weryfikacji. Gdy takich ustaleń brakuje, zapiszmy zadanie ich pozyskania. Ocenę wykonania procedury oprzyjmy na potwierdzeniach z przeglądu dostępu do konkretnego urządzenia lub maszyny wirtualnej.

Poprośmy osobę techniczną o ocenę znaczenia ustalonej dostępności dla badanego wdrożenia i o wskazanie podstaw tej oceny.

W zestawieniu zadań oddzielmy również zaplanowanie pracy od potwierdzenia jej wykonania. Przy zadaniu zamkniętym poprośmy o dowód odnoszący się do konkretnego urządzenia lub maszyny wirtualnej. Przy zadaniu otwartym wskażmy wykonawcę oraz oczekiwany wynik.

Cykl aktualizacji potrzebuje przypisanej odpowiedzialności

Przy sprzęcie, maszynie wirtualnej i usłudze chmurowej postawmy osobno pytanie: kto może wykonać aktualizację, kto uzgadnia jej termin i kto potwierdza zakończenie? Odpowiedź dla każdego wdrożenia potwierdźmy przez sprawdzenie podziału obowiązków. Proponujemy wpisać te role do zestawienia wdrożeń, nawet jeżeli w danej organizacji wszystkie zadania ostatecznie przypadną tej samej osobie.

Przy usłudze chmurowej ustalmy najpierw jej zakres i właściwy podział odpowiedzialności. Samo zestawienie skutków dla PA-Series oraz VM-Series nie rozstrzyga sytuacji takiej usługi. Ocenę możliwych następstw i harmonogram prac ustalmy osobno dla tej usługi. Poprośmy opiekuna usługi o potwierdzenie, jakie informacje o cyklu aktualizacji może uzyskać i kto je zweryfikuje.

Wymagajmy wskazania wykonawcy aktualizacji i osoby, która potwierdzi jej zakończenie.

W decyzji zarządczej zapiszmy także pytania, które pozostały bez odpowiedzi. Jeśli termin albo odpowiedzialność pozostają nieznane, przypiszmy im właściciela wyjaśnienia. Koszt ewentualnej przerwy pozostawmy do oszacowania przez organizację na podstawie ustaleń o jej wdrożeniu.

CERT Polska daje punkt odniesienia dla krajowych odbiorców

Polskim punktem odniesienia jest komunikat CERT Polska z 14 września. Przy przekazywaniu go kierownictwu zachowajmy rozdział między ostrzeżeniem o możliwości ataku a potwierdzeniem incydentu. Źródło nie potwierdza ataków wykorzystujących tę podatność.

Proponujemy, by odpowiedź własnego zespołu na komunikat CERT Polska podawała, co dokładnie sprawdzono. Wskażmy, które wdrożenia rozpoznano i dla których dostępność interfejsów oraz odpowiedzialność za aktualizacje wymagają dalszych ustaleń. Przy braku odpowiedzi zachowajmy status „nieustalone”, zamiast uznawać daną pozycję za bezpieczną lub zaatakowaną.

Priorytet prac zaproponujmy na podstawie ustaleń o własnym wdrożeniu i wypiszmy pytania, na które jeszcze nie ma odpowiedzi.

Co z tym zrobić w poniedziałek

  1. Rozdziel wdrożenia PAN-OS. Poświęć do 30 minut na przegląd dostępnego wykazu infrastruktury. Oznacz sprzęt, maszyny wirtualne i usługi chmurowe. Pozycje bez rozpoznanego typu zapisz do wyjaśnienia. Zakres tego przeglądu ogranicz do informacji już dostępnych w wykazie.
  2. Zbierz pytania o interfejsy. W ciągu 30 minut przejrzyj dostępne zapisy o dostępie do PAN-OS. Wskaż brakujące potwierdzenia i osobę, która sprawdzi stan faktyczny. Wynikiem ma być lista zadań z terminami ich wykonania.
  3. Przypisz cykl aktualizacji. Przez 30 minut sprawdź dostępne przypisania odpowiedzialności dla poszczególnych wdrożeń. Zapisz wykonawcę, osobę potwierdzającą zakończenie oraz znany termin. Brakujące ustalenia skieruj do wyjaśnienia, osobno dla każdego rodzaju wdrożenia.

Przy PAN-OS wymagajmy decyzji odnoszącej się do konkretnego wdrożenia i potwierdzonego zakresu odpowiedzialności. Rozpoznanie różnic między środowiskami powinno poprzedzać wspólną ocenę ryzyka. Niewiadome dotyczące dostępu i aktualizacji pozostawmy widoczne, z właścicielem oraz terminem wyjaśnienia.

Źródła

Redakcja cyberinsight.pl.