Fortinet zaleca pilne wdrożenie poprawek dla kilku rodzin swoich produktów, choć szczegółowe komunikaty zapowiada dopiero na 10 listopada. Zapowiedź z 21 października i wydania z 22 października dają administratorom podstawę do działania już teraz. Dla organizacji problemem jest także to, czy potrafi zatwierdzić zmianę przed publikacją pełnego opisu podatności.

Wyobraź sobie, że producent drzwi dostarcza nową część zamka i wskazuje modele wymagające wymiany. Szczegółowy opis wady ma opublikować później, żeby właściciele zdążyli zamontować poprawkę. Osoba zarządzająca budynkiem musi zdecydować, czy znane instrukcje wystarczają do zamówienia prac. To analogia do decyzji przed zespołami utrzymującymi Fortinet, a nie opis konkretnej luki. W dokumentacji zmiany może zabraknąć numeru CVE, ale są nazwy produktów i wersje docelowe. Procedura, która przyjmuje wyłącznie zgłoszenia z kompletem technicznych szczegółów, może zatrzymać pracę mimo ostrzeżenia producenta. W takim przypadku właściciel usługi powinien rozstrzygnąć, jakie dowody wystarczą do uruchomienia pilnej ścieżki aktualizacji.

Wersje naprawcze są znane przed pełnym komunikatem

Według zapowiedzi Fortinet z 21 października pakiet obejmuje poprawki o krytycznej i wysokiej wadze. Dotyczy FortiOS, FortiManager, FortiAnalyzer, FortiMail i FortiAuthenticator. Przykładowo w gałęzi 7.4 producent wskazuje FortiOS 7.4.13 oraz FortiManager i FortiAnalyzer 7.4.12. Szczegółowe komunikaty PSIRT mają pojawić się 10 listopada.

Nie znamy jeszcze z tego komunikatu dokładnych mechanizmów poszczególnych podatności. Nie zastępujmy tej niewiedzy domysłem, że każda umożliwia przejęcie urządzenia bez logowania. Australijskie ACSC w alercie z 23 października zaleca priorytetowe aktualizacje i podaje, że nie ma dodatkowych szczegółów poza publicznymi informacjami Fortinet. W tym samym alercie stwierdza brak wiedzy o aktywnym wykorzystaniu tych luk w Australii. To ograniczone geograficznie ustalenie, nie globalna gwarancja.

W naszej ocenie niepełny opis mechanizmu powinien wpływać na język raportu, ale nie unieważniać instrukcji naprawy. Można uczciwie napisać, że zespół aktualizuje wskazany produkt zgodnie z zaleceniem producenta, a szczegóły techniczne pozostają nieopublikowane. Taka informacja wystarczy do przypisania pracy, ustalenia terminu i zapisania powodu decyzji. Nie wymaga dopisywania własnego scenariusza ataku.

Do uruchomienia pilnej zmiany może wystarczyć wiarygodna instrukcja naprawy, nawet gdy pełny opis podatności jeszcze nie istnieje publicznie.

Gałąź 7.4 nie oznacza konkretnej wersji urządzenia

Zestawienie Fortinet pokazuje, dlaczego zapis samej gałęzi oprogramowania nie wystarczy do oceny zakończenia prac. Dla FortiOS i narzędzi zarządzania numery docelowe różnią się nawet w tej samej gałęzi 7.4. Proponujemy, aby administrator porównywał pełny numer wydania z tabelą producenta i zapisywał wynik dla każdego urządzenia. Ogólne stwierdzenie „używamy aktualnej siódemki” nie daje podstawy do odbioru zadania.

W takiej kontroli pomagają dwa pola w zgłoszeniu: wersja przed pracami i wersja odczytana po ich zakończeniu. Obok powinno znaleźć się potwierdzenie działania usługi, za którą odpowiada aktualizowany produkt. Ten zapis pozwala następnemu administratorowi ustalić, co wykonano, bez odtwarzania rozmów na komunikatorze. Jeżeli część urządzeń czeka na termin, administrator powinien je wymienić wprost, zamiast oznaczać cały pakiet jako ukończony.

Fortinet uprzedza też, że aktualizacja FortiManager Cloud może wymagać działania ręcznego. Dlatego nazwa usługi chmurowej nie powinna zamykać pytania o odpowiedzialność klienta. Proponujemy sprawdzić zakres usługi i właściwą instrukcję dla danego wdrożenia. Osoba prowadząca zmianę powinna wiedzieć, czy oczekuje działania dostawcy, czy ma wykonać je we własnym panelu.

Ten sam obowiązek doprecyzowania dotyczy zewnętrznego serwisu. Zlecenie aktualizacji Fortinet powinno wskazywać produkty, które obejmuje, oraz sposób potwierdzenia wykonania. Jeżeli wykonawca utrzymuje wyłącznie część infrastruktury, klient potrzebuje właściciela pozostałych urządzeń. To rekomendacja organizacyjna, nie zarzut wobec konkretnego usługodawcy.

Ograniczenie dostępu daje czas na zaplanowanie zmiany

ACSC przytacza zalecenia ograniczenia dostępu administracyjnego HTTPS i SSH do zaufanych adresów oraz odsunięcia administracji FortiManager od internetu. Fortinet podkreśla, że środki tymczasowe nie zastępują aktualizacji. Zespół powinien więc zapisać osobno wykonaną zmianę dostępu i termin wdrożenia właściwej poprawki.

Naszym zdaniem decyzja o przesunięciu aktualizacji powinna mieć właściciela i datę ponownej oceny. W przeciwnym razie działanie tymczasowe może zostać jedynym śladem reakcji. Raport „ograniczono dostęp” mówi o wykonanej czynności, ale nie rozlicza instalacji nowej wersji. Osoba zatwierdzająca wyjątek powinna otrzymać informację o obu zadaniach i o przyczynie, która uniemożliwia zakończenie drugiego.

Każde odroczenie poprawki powinno wskazywać właściciela decyzji, warunek jej zmiany i termin powrotu do sprawy.

Zalecamy przygotować kopię konfiguracji i uzgodniony plan powrotu do pracy z osobą, która zna wdrożenie. Terminu aktualizacji nie powinno wyznaczać samo oczekiwanie na 10 listopada. Powinny go wyznaczać rozpoznana ekspozycja, instrukcja producenta i warunki wykonania zmiany. Nie obiecujemy przy tym, że dowolną infrastrukturę da się naprawić bez przerwy. Taką ocenę musi wykonać administrator konkretnej usługi.

Polski odbiorca powinien ustalić uprawnienia do pilnej zmiany

Dla polskiej firmy utrzymującej Fortinet przez partnera dobrym początkiem jest potwierdzenie, kto może zatwierdzić prace poza zwykłym harmonogramem. Proponujemy zrobić to na podstawie obecnego komunikatu, bez czekania na kolejny dokument. W zgłoszeniu można wskazać tabelę producenta, pełny numer używanej wersji i osobę odpowiedzialną za dostępność usługi.

Nie wyprowadzamy z australijskiego alertu obowiązku prawnego dla polskich organizacji ani terminu ustawowego. To źródło informacji technicznej i zaleceń, które klient powinien odnieść do własnego wdrożenia. Po publikacji komunikatów PSIRT 10 listopada zespół powinien wrócić do otwartych pytań. Proponujemy już teraz przypisać komuś tę kontrolę, aby zapowiedziany dokument nie trafił wyłącznie do skrzynki osoby akurat nieobecnej.

Co z tym zrobić w poniedziałek

  1. W 20 minut sprawdź jedno wdrożenie Fortinet. Zapisz produkt i pełny numer wersji, porównaj go z tabelą producenta i wskaż administratora odpowiedzialnego za zmianę.
  2. W 30 minut przygotuj pilne zgłoszenie. Ustal osobę zatwierdzającą, termin, kopię konfiguracji i sposób sprawdzenia usługi po aktualizacji. Oznacz urządzenia wymagające osobnych prac.
  3. W 20 minut rozlicz środki tymczasowe. Potwierdź z administratorem zakres ograniczenia dostępu oraz datę właściwej aktualizacji. Dodaj przypomnienie o sprawdzeniu komunikatów 10 listopada.

Zapowiedź Fortinet daje organizacji konkretną pracę do wykonania przed pełnym ujawnieniem szczegółów. Dobrze przygotowane zgłoszenie pozwala działać bez udawania, że znamy mechanizm każdej luki. O zakończeniu decyduje potwierdzona wersja i sprawdzona usługa, a otwarte pytania powinny mieć właściciela.

Źródła

Redakcja cyberinsight.pl.