Według CERT Polska sierpniowe biuletyny obejmują 943 podatności w rozwiązaniach Oracle oraz komponentach używanych przez te produkty. W komunikacie z 19 sierpnia zespół wskazuje możliwość przejęcia instancji, zdalnego wykonania kodu i dostępu do bazy danych z wysokimi uprawnieniami. Dla polskich organizacji korzystających z Oracle to powód, by powiązać ewidencję produktów i ich zależności z właścicielami usług oraz planem testów aktualizacji.

Czy na pytanie o zakres aktualizacji Oracle wystarczy odpowiedź: „mamy listę aplikacji”? Spróbujmy na jej podstawie wskazać komponent wymagający sprawdzenia, jego wersję i osobę odpowiedzialną za usługę, która z niego korzysta. Jeżeli wykaz kończy się na nazwie produktu, pozostawmy te pytania otwarte. Proponujemy potraktować komunikat CERT Polska jako sprawdzian użyteczności inwentaryzacji: przy wybranej aplikacji dopisać jej komponenty, a przy nich ustalenia potrzebne do zaplanowania zmiany. Nie zakładajmy przy tym, że wszystkie 943 podatności dotyczą naszego środowiska. Zacznijmy od tego, co da się potwierdzić dla posiadanych produktów, i osobno zapiszmy brakujące informacje o zależnościach. Taki zakres sprawdzenia przekażmy właścicielowi usługi do uzupełnienia.

Zakres 943 podatności obejmuje również komponenty

Jak podaje CERT Polska, liczba 943 obejmuje rozwiązania Oracle i używane przez nie komponenty. Odnosząc tę informację do własnej ewidencji, sprawdźmy oba poziomy: produkt oraz jego zależności. Przy każdej rozpoznanej pozycji zapiszmy wersję i wynik porównania z informacją o podatnych wersjach. Brak danych o komponencie oznaczmy jako zadanie do wyjaśnienia.

Wskazane przez CERT Polska skutki to możliwości związane z podatnościami opisanymi w komunikacie. Nie przypisujmy przejęcia instancji, wykonania kodu ani dostępu do bazy każdej aplikacji w wykazie. Dla konkretnej instalacji ustalmy najpierw, której podatności dotyczy ocena i na czym opiera się powiązanie jej z używaną wersją.

Liczby 943 nie używajmy jako liczby poszkodowanych firm czy ofiar. Przy poszczególnych usługach raportujmy wynik własnej weryfikacji, z podaniem sprawdzonego produktu i komponentu. Z komunikatu nie wynika potwierdzenie aktywnych ataków; nie przedstawiajmy możliwych skutków jako opisu zdarzenia, które już nastąpiło.

Przy Oracle inwentaryzacja powinna prowadzić od nazwy aplikacji do komponentu, wersji i właściciela aktualizacji.

Ewidencję Oracle sprawdźmy na konkretnej usłudze

Procedurę zestawmy z praktyką bez przypisywania organizacjom nieudokumentowanych zaniedbań. Wybierzmy usługę korzystającą z Oracle i przejdźmy przez jej dostępne zapisy. Jeżeli procedura wymaga aktualizacji, poprośmy o wskazanie pozycji w ewidencji, której ta praca ma dotyczyć. Następnie sprawdźmy, czy opis obejmuje komponenty używane wewnątrz aplikacji oraz ich wersje. Wynik tego przeglądu będzie podstawą oceny własnej dokumentacji.

W roboczym zestawieniu umieśćmy nazwę usługi, produkt, komponent, wersję i osobę odpowiedzialną za dalsze ustalenia. Przy brakującym wpisie wskażmy konkretnie, czego jeszcze nie wiadomo. Oddzielmy komponent nierozpoznany od takiego, którego wersję już porównano z informacją o podatności. Nie zamykajmy zadania tylko dlatego, że nazwa aplikacji znajduje się w wykazie.

Jeśli dostępny spis Oracle nie pozwala ustalić zależności, zaplanujmy jego uzupełnienie dla wybranej usługi. Poprośmy o potwierdzenie, skąd pochodzi informacja o wersji. W raporcie z przeglądu zachowajmy również zakres sprawdzenia, aby ocena jednej aplikacji nie uchodziła za wynik dla całego środowiska.

Właściciel usługi powinien zatwierdzić zakres testów

Możliwość przejęcia instancji, wykonania kodu czy dostępu do bazy z wysokimi uprawnieniami, wskazana przez CERT Polska, wyznacza tematy do rozmowy o ryzyku. Dla własnej usługi poprośmy o ocenę, jakie znaczenie miałby właściwy dla niej skutek. Kwotę ewentualnych strat i czas potrzebny na aktualizację pozostawmy do ustalenia na podstawie danych organizacji. Komunikat nie rozstrzyga tych wartości.

Przy rozpoznanej podatnej wersji Oracle przypiszmy osobę przygotowującą zmianę oraz właściciela usługi, który uzgodni zakres testów. W planie zapiszmy, jaki produkt lub komponent obejmie aktualizacja, jakie działanie aplikacji obejmie test i kto potwierdzi wynik. Termin prac ustalmy razem z zakresem, a nierozstrzygnięte zależności zachowajmy jako jawne pytania do wyjaśnienia.

Plan aktualizacji Oracle powinien wskazywać zmieniany komponent i osobę potwierdzającą działanie usługi po zmianie.

Do decyzji o aktualizacji dołączmy kryterium zakończenia testu. Wskażmy oczekiwany wynik dla wybranego działania aplikacji oraz sposób jego zapisania. Gdy zakres komponentów pozostaje niepełny, poprośmy właściciela usługi o wskazanie, które ustalenia trzeba jeszcze uzyskać przed zatwierdzeniem planu.

Polski komunikat przełóżmy na zadania własnej organizacji

Dla polskich organizacji punktem odniesienia jest komunikat CERT Polska opublikowany 19 sierpnia. W informacji dla kierownictwa zachowajmy atrybucję liczby 943 i opisanych skutków. Obok nich przedstawmy ustalenia dotyczące własnych produktów Oracle, z wyraźnym wskazaniem, które wersje i komponenty zweryfikowano. Nie wyciągajmy z ogólnej liczby wniosku o skali podatności konkretnej firmy.

Proponujemy przygotować odpowiedź na komunikat w postaci zestawienia usług i zadań. Dla każdej sprawdzonej usługi podajmy zakres rozpoznania, właściciela dalszych prac oraz stan przygotowania testów. Przy pozycjach bez ustalonej wersji zapiszmy termin wyjaśnienia. Przy zaplanowanej aktualizacji wskażmy osobę odpowiedzialną za potwierdzenie jej wykonania. Tę samą zasadę zastosujmy do produktu i jego komponentów, aby zakres raportu odpowiadał zakresowi ostrzeżenia CERT Polska.

Co z tym zrobić w poniedziałek

  1. Sprawdź wpis jednej usługi z Oracle. W ciągu 30 minut przejrzyj dostępną ewidencję. Wypisz produkt, rozpoznane komponenty i zapisane wersje. Zaznacz brakujące dane; wynikiem ma być zakres dalszej weryfikacji tej usługi.
  2. Przypisz odpowiedzialność za ustalenia. Poświęć do 30 minut na sprawdzenie dostępnych przypisań właściciela wybranej usługi i wykonawcy aktualizacji. Przy brakujących danych o komponentach zapisz osobę, do której skierujesz zadanie, oraz proponowany termin odpowiedzi.
  3. Przygotuj szkic testu aktualizacji. W ciągu 30 minut zapisz dla tej usługi proponowany zakres zmiany, działanie aplikacji do sprawdzenia, oczekiwany wynik i osobę zatwierdzającą. Nierozpoznane wersje oznacz jako wymagające ustalenia; szkic przekaż właścicielowi do uzgodnienia.

Przy Oracle wymagajmy, by decyzja o aktualizacji dawała się powiązać z konkretnym komponentem i usługą. Od właściciela oczekujmy potwierdzenia zakresu oraz wyniku testów. Uzupełnienie ewidencji uznajmy za zakończone dopiero wtedy, gdy dla sprawdzanej pozycji można wskazać dalszą pracę i osobę za nią odpowiedzialną.

Źródła

Redakcja cyberinsight.pl.