Cykl życia zarządzania podatnościami u dostawców oprogramowania

Czym jest cykl życia zarządzania podatnościami?

Cykl życia zarządzania podatnościami to powtarzalny proces, według którego dostawca produktu obsługuje podatność w dostarczanym oprogramowaniu: otrzymuje ją lub znajduje, weryfikuje, ustala, czego dotyczy, naprawia, wydaje poprawkę i informuje klientów. W organizacji dostawcy prowadzi go zwykle zespół reagowania na incydenty bezpieczeństwa produktów (PSIRT), a poprawki wykonują zespoły inżynierskie.

Ta strona opisuje perspektywę dostawcy. Zarządzanie podatnościami w IT, czyli skanowanie i łatanie serwerów i laptopów organizacji, ma to samo słownictwo, ale nie te same trudności. Dostawca musi odpowiadać za każde wspierane wydanie w rękach klientów i musi opublikować to, co znalazł.

Etapy cyklu życia

1. Otrzymanie lub wykrycie. Podatności docierają od zewnętrznych badaczy przez Państwa program ujawniania, od klientów, od koordynatorów, takich jak krajowe zespoły CSIRT, oraz z własnego monitorowania: nowa CVE w zależności open source, znalezisko skanera lub test wewnętrzny. Każdą należy zapisać z identyfikatorem śledzenia i potwierdzić odbiór zgłaszającym z zewnątrz.
2. Weryfikacja i triage. Należy odtworzyć problem lub potwierdzić dopasowanie zależności, zdecydować, czy to podatność w Państwa produkcie, i ocenić jej ważność i pilność. To, co nie ma zastosowania, należy zamknąć z uzasadnieniem, które można później pokazać. Sygnały priorytetyzacji, takie jak EPSS i katalog CISA KEV, pomagają uszeregować resztę.
3. Ocena dotkniętych produktów i wersji. Należy znaleźć każdy produkt, wydanie i wspieraną gałąź zawierające podatny kod lub komponent oraz każde wdrożenie u klienta, które z nich korzysta. Ten krok wyznacza zakres poprawki i biuletynu.
4. Naprawa. Odpowiedzialny zespół opracowuje i testuje poprawkę: aktualizację zależności, zmianę kodu lub środek łagodzący, taki jak zmiana konfiguracji, gdy poprawka nie jest jeszcze możliwa.
5. Wydanie poprawki. Należy dostarczyć zaktualizowane wersje dla każdej dotkniętej wspieranej gałęzi, kanałem, któremu klienci mogą zaufać.
6. Informowanie i ujawnienie. Należy opublikować biuletyn określający, czego dotyczy problem, jak jest poważny i co należy zrobić, nadać identyfikator CVE lub się do niego odwołać oraz wskazać zgłaszającego. Formaty czytelne maszynowo, takie jak CSAF i VEX, pozwalają klientom przetwarzać biuletyny automatycznie.
7. Monitorowanie i wnioski. Należy obserwować wykorzystanie i nowe informacje, aktualizować biuletyn i przekazywać główną przyczynę do rozwoju produktu, aby ta sama klasa wad nie została dostarczona ponownie.

ISO/IEC 30111 i ISO/IEC 29147

Dwa międzynarodowe standardy opisują ten cykl życia dla dostawców. Dzielą go na granicy organizacji:

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
Tytuł	Vulnerability handling processes	Vulnerability disclosure
Zakres	To, co dzieje się wewnątrz: weryfikacja, badanie, priorytetyzacja i naprawa	Interfejsy: przyjmowanie zgłoszeń i publikowanie biuletynów
Główna treść	Polityka i organizacja, obowiązki PSIRT, fazy obsługi, kwestie łańcucha dostaw	Role interesariuszy, obsługa zgłoszeń, zawartość biuletynów, koordynacja, polityka ujawniania
Odbiorcy	Dostawcy obsługujący zgłoszone podatności	Dostawcy przyjmujący zgłoszenia i ujawniający podatności

Standardy zaprojektowano do wspólnego stosowania. ISO/IEC 30111 wymienia sześć faz obsługi: przygotowanie, odbiór, weryfikację, opracowanie naprawy, wydanie i etap po wydaniu. Wymaga też monitorowania procesu, poufności informacji o podatnościach i uwzględnienia łańcucha dostaw, ponieważ wiele podatności znajduje się w komponentach, których Państwo nie napisali. Oba standardy to aktualne wydania, potwierdzone przy ostatnich przeglądach ISO, i oba są oznaczone do rewizji.

Inne frameworki mają tę samą strukturę. FIRST PSIRT Services Framework grupuje pracę w wykrywanie podatności, triage i analizę, naprawę oraz ujawnianie, a IEC 62443-4-1 obejmuje zarządzanie aktualizacjami bezpieczeństwa i defektami w swoim cyklu bezpiecznego wytwarzania produktów przemysłowych.

Role

• PSIRT lub zespół bezpieczeństwa produktu: odpowiada za proces, przyjmuje zgłoszenia, wykonuje triage, koordynuje poprawki i publikuje biuletyny. Zob. CRACI dla zespołów PSIRT oraz czym PSIRT różni się od CSIRT.
• Zespoły produktowe i inżynierskie: odpowiadają za kod, opracowują i testują poprawki oraz dostarczają wydania.
• Zarządzanie wydaniami: decyduje, które wspierane gałęzie otrzymają poprawkę i kiedy.
• Obsługa klienta i komunikacja: zajmują się pytaniami klientów i odbiorcami biuletynu.
• Dział prawny: doradza w sprawie ujawniania, umów i zgłoszeń regulacyjnych.
• Strony zewnętrzne: zgłaszający, koordynatorzy, tacy jak CERT/CC lub krajowy CSIRT, opiekunowie dotkniętych komponentów oraz klienci, którzy muszą wdrożyć poprawkę.

Terminy i SLA

Nie istnieje jeden wymagany harmonogram. Większość dostawców ustala wewnętrzne cele według ważności, a zewnętrzne publikuje w polityce ujawniania. Typowa struktura:

• Potwierdzenie zgłoszenia z zewnątrz w ciągu kilku dni roboczych.
• Triage w ciągu kilku dni, aby zgłaszający i odpowiedzialny zespół wiedzieli, na czym stoją.
• Naprawa w terminie zależnym od ważności i wykorzystania, najkrótszym dla krytycznych znalezisk i wszystkiego, o czym wiadomo, że jest wykorzystywane.
• Ujawnienie, gdy poprawka jest dostępna, lub w uzgodnionym terminie, jeśli poprawka się opóźnia.

Zewnętrzna presja wyznacza granicę. Badacze często ustalają termin ujawnienia (Google Project Zero daje dostawcom 90 dni), a regulacje dodają własne: unijny Cyber Resilience Act wymaga od producentów niezwłocznego usuwania podatności i wyznacza terminy zgłaszania tych aktywnie wykorzystywanych (zob. czego wymaga CRA). Gdy podatność jest już wykorzystywana, jak w przypadku zero-day, każdy etap przebiega w najkrótszym terminie.

Gdzie cykl życia się załamuje

Większość opóźnień nie dotyczy pisania poprawki. Wynikają z niewiedzy o tym, co dostarczono.

• Niewiedza, które wydania zawierają komponent. W bibliotece pojawia się nowa CVE. Które z zeszłorocznych wydań ją zawierają i którzy klienci z nich korzystają? Bez zapisu dla każdego wydania zespoły przebudowują stare tagi lub ręcznie przeszukują repozytoria, a lista dotkniętych wersji w biuletynie jest zgadywaniem.
• Zależności przechodnie. Wiele podatnych pakietów nie zostało przez Państwa wybranych. Trafiają jako zależności przechodnie kilka poziomów niżej, więc przeszukanie manifestów ich nie znajdzie.
• Szum zależności deweloperskich. Skanery odczytujące lockfile zgłaszają frameworki testowe i narzędzia buildu, które nigdy nie są dostarczane. Każde z nich kosztuje czas triage i zasypuje ważne znaleziska.
• Komponenty poza menedżerem pakietów. Pliki binarne pobierane przez skrypty buildu, obrazy bazowe i komponenty dostawców w ogóle nie pojawiają się w lockfile.
• Niejasna odpowiedzialność. Znalezisko bez odpowiedzialnego zespołu czeka. Triage kończy się dopiero wtedy, gdy poprawka ma właściciela.
• Poprawki, które się nie utrzymują. Podatna wersja wraca przez inną zależność lub starą gałąź, ponieważ nic nie powstrzymuje jej przed wejściem do następnego buildu.

Metryki

Metryka	Co pokazuje
Czas do potwierdzenia	Czy zgłaszający otrzymują odpowiedź w terminie podanym w polityce
Czas do triage	Jak długo znalezisko czeka, zanim ktokolwiek będzie wiedział, czy ma znaczenie
Czas do naprawy, według ważności	Jak szybko dostarczane są poprawki, od odbioru do dostępnego wydania
Czas do biuletynu	Jak długo klienci czekają na informacje po poprawce
Udział w terminie	Czy wewnętrzne SLA są dotrzymywane, zwłaszcza dla znalezisk krytycznych i wykorzystywanych
Backlog według wieku	Które znaleziska utknęły i gdzie
Odsetek „nie dotyczy”	Ile pracy triage idzie na znaleziska, które nie mają zastosowania

Każdy etap należy mierzyć osobno. Długi czas naprawy często okazuje się długim czasem szukania dotkniętych wydań.

Cykl życia oparty na zapisie tego, co dostarczono

Każdy etap po triage zależy od wiedzy o tym, co zawiera każde wydanie. CRACI uruchamia Państwa buildy GitHub Actions na własnych runnerach i rejestruje pakiety faktycznie pobrane przez każde zadanie, łącznie z zależnościami przechodnimi, pakietami przywróconymi z cache CI i zależnościami, których nie wymienia żaden lockfile. Każdy SBOM ma stan kompletności i jest eksportowany w CycloneDX lub SPDX.

CRACI stale ponownie ocenia monitorowane SBOM-y i agreguje je z wielu buildów i repozytoriów, a SBOM-y dostawców można dodać, aby kupione komponenty były monitorowane razem z Państwa własnymi. Gdy pojawia się nowa CVE, historia buildów pokazuje, które wcześniejsze buildy zawierały podatną zależność, bezpośrednią lub przechodnią, dzięki czemu znają Państwo okres narażenia, a widok inwentarza pokazuje, które wersje oprogramowania są wdrożone w których produktach. Zespoły bezpieczeństwa wykonują triage znalezisk w CRACI i przekazują je zespołom odpowiedzialnym za poprawkę, CRACI obsługuje VEX, a bramki polityk mogą blokować buildy zawierające określoną CVE, aby naprawiona podatność nie wróciła. Zob. śledzenie podatności.

Cykl życia zarządzania podatnościami: najczęściej zadawane pytania

Jakie są etapy cyklu życia zarządzania podatnościami?

Dla dostawcy produktu: otrzymanie lub wykrycie podatności, weryfikacja i triage, ustalenie dotkniętych produktów i wersji, opracowanie naprawy, wydanie poprawki, publikacja biuletynu, a następnie monitorowanie i wnioski. ISO/IEC 30111 nazywa te fazy przygotowaniem, odbiorem, weryfikacją, opracowaniem naprawy, wydaniem i etapem po wydaniu.

Czym jest ISO/IEC 30111?

ISO/IEC 30111:2019 to międzynarodowy standard procesów obsługi podatności. Daje dostawcom wymagania i zalecenia dotyczące przetwarzania i usuwania zgłoszonych podatności w ich produktach i usługach, od polityki i roli PSIRT po fazy obsługi i kwestie łańcucha dostaw.

Czym ISO/IEC 30111 różni się od ISO/IEC 29147?

ISO/IEC 29147 obejmuje część zewnętrzną: przyjmowanie zgłoszeń i publikowanie biuletynów. ISO/IEC 30111 obejmuje wewnętrzną obsługę pomiędzy nimi: weryfikację, badanie, priorytetyzację i naprawę. Oba mają być stosowane razem. Stronę 29147 opisuje skoordynowane ujawnianie podatności.

Czym jest triage podatności?

Triage to krok, w którym zespół bezpieczeństwa potwierdza, że zgłoszona lub wykryta podatność jest prawdziwa, ocenia, jak jest poważna i pilna dla Państwa produktu, i przekazuje ją zespołowi odpowiedzialnemu za poprawkę. Dobry triage zamyka też znaleziska, które nie mają zastosowania, z zapisanym uzasadnieniem.

Czym zarządzanie podatnościami produktów różni się od zarządzania nimi w IT?

Zarządzanie podatnościami w IT polega na łataniu systemów, z których korzysta organizacja. Zarządzanie podatnościami produktów obsługuje wady oprogramowania, które organizacja buduje i dostarcza innym, więc dodaje kroki, których zespoły IT nie mają: ustalenie, których wydanych wersji to dotyczy, dostarczenie poprawki klientom i poinformowanie ich w biuletynie.

Jakie metryki powinien śledzić proces obsługi podatności?

Czas do potwierdzenia zgłoszenia, czas do triage, czas do naprawy i czas do biuletynu, każdy według ważności, a także udział znalezisk mieszczących się w wewnętrznych celach, otwarty backlog według wieku i liczbę znalezisk zamkniętych jako niedotyczące produktu.