Zarządzanie poprawkami i SLA

Priorytetyzacja wskazuje, co należy naprawić; zarządzanie poprawkami to zdyscyplinowany proces, który faktycznie doprowadza te naprawy do końca, na czas i w całym środowisku.

SLAs (umowy o poziomie usług) określają, jak szybko należy usuwać problemy o różnym poziomie ważności. Bez nich pilne naprawy są opóźniane, a odpowiedzialność zanika.

Powtarzalny cykl pomaga utrzymywać aktualność systemów:

• Zidentyfikować dostępne poprawki (zalecenia dostawców, wyniki skanowania).
• Ocenić ich przydatność i ryzyko zastosowania.
• Przetestować je w środowisku nieprodukcyjnym.
• Wdrożyć je w kontrolowanych etapach.
• Zweryfikować zastosowanie poprawki i prawidłowe działanie systemu.

Każdy etap ma przypisanych właścicieli i dowody wykonania, odzwierciedlając szerszy cykl życia VM.

SLA zamienia zamiar w termin graniczny. Określa maksymalny dozwolony czas od wykrycia do usunięcia podatności, z podziałem według poziomu ważności. Przykładowe cele:

• Krytyczne / KEV: 7–15 dni (lub szybciej w przypadku zasobów dostępnych z Internetu).
• Wysokie: 30 dni.
• Średnie: 90 dni.
• Niskie: w miarę możliwości / w następnym cyklu.

Umowy SLA umożliwiają mierzenie czasu zalegania i wywierają presję na zamykanie problemów, a nie tylko ich odnotowywanie.

Czas należy powiązać z rzeczywistym ryzykiem, a nie tylko z CVSS. Krytyczna podatność wymieniona w KEV lub dostępna z Internetu powinna mieć krótszy termin SLA niż podatność o średnim poziomie ważności w zasobie wewnętrznym.

Pomocne są odpowiednie standardy i wytyczne: CISA wymaga od agencji federalnych usuwania podatności z KEV w określonych terminach, a wiele przedsiębiorstw przyjmuje podobnie przyspieszone terminy dla aktywnie wykorzystywanych podatności, niezależnie od wyniku CVSS.

Poprawki mogą powodować problemy. Testowanie na środowisku przejściowym pozwala wykryć regresje, zanim dotkną środowiska produkcyjnego:

• Najpierw zastosować poprawkę do reprezentatywnej grupy testowej.
• Zweryfikować najważniejsze funkcje i wydajność.
• Potwierdzić brak konfliktów z istniejącym oprogramowaniem.

Należy zachować równowagę między szybkością a bezpieczeństwem: w przypadku podatności KEV wykorzystywanej na wolności należy zaakceptować większe ryzyko i zastosować poprawkę szybciej niż w przypadku standardowej aktualizacji.

Wdrażać poprawki falami (wdrażanie pierścieniowe): najpierw do grupy pilotażowej, następnie do kolejnych, większych grup, a na końcu wszędzie. Przed przejściem do następnego etapu należy monitorować stan systemów w każdej grupie.

Zawsze należy mieć plan wycofania zmian: migawki, obniżenie wersji pakietu lub przywrócenie konfiguracji. Jeśli poprawka spowoduje awarię, trzeba móc szybko ją wycofać na czas prowadzenia analizy.

Ręczne instalowanie poprawek nie sprawdza się na dużą skalę. Należy korzystać z centralnych narzędzi:

• WSUS / SCCM / Intune w systemie Windows.
• Narzędzia do zarządzania konfiguracją (Ansible, Puppet, Chef) w przypadku flot systemu Linux.
• Wzorcowe/bazowe obrazy odbudowywane z zastosowaniem poprawek na potrzeby chmury i kontenerów.

Automatyzacja wymusza spójność i skraca czas między wydaniem poprawki a jej wdrożeniem.

Czasami nie można natychmiast zastosować poprawki: z powodu opóźnienia po stronie dostawcy, delikatnego systemu starszego typu lub wymaganego czasu nieprzerwanego działania. W międzyczasie należy zastosować mechanizmy kompensacyjne, aby ograniczyć ryzyko:

• Segmentacja sieci / reguły zapory.
• Wirtualne poprawki za pomocą sygnatur WAF lub IPS.
• Wyłączenie podatnej funkcji lub usługi.

Rozwiązania te zyskują czas, ale nie zastępują na stałe właściwej naprawy.

Systemy po zakończeniu cyklu życia mogą w ogóle nie mieć dostępnych poprawek. Możliwe rozwiązania:

• Odizolować je w ograniczonym segmencie sieci.
• Objąć je ścisłymi kontrolami dostępu i monitorowaniem.
• Zaplanować migrację lub wycofanie z eksploatacji z określonym terminem.
• Formalnie zaakceptować ryzyko rezydualne z datą wygaśnięcia.

Należy udokumentować wszystko, ponieważ nieaktualizowany i nieudokumentowany system stwarza ryzyko audytowe oraz ryzyko naruszenia bezpieczeństwa.

Należy śledzić, czy program faktycznie spełnia swoje zobowiązania:

• MTTR według poziomu ważności w porównaniu z celem SLA.
• Wskaźnik zgodności z SLA (odsetek ustaleń zamkniętych w terminie).
• Zaległe / długo nierozwiązane ustalenia według zespołu i zasobu.
• Pokrycie poprawkami (odsetek aktualnej floty).

Należy raportować według zespołu odpowiedzialnego, aby odpowiedzialność była widoczna, a obszary działające zbyt wolno otrzymywały odpowiednią uwagę.

Po wdrożeniu należy zweryfikować rezultat: ponownie przeskanować środowisko, aby potwierdzić usunięcie CVE i prawidłowy stan systemu, a następnie zamknąć ustalenie, dołączając dowody. Powtarzające się problemy (biblioteka, która wciąż jest ponownie wykrywana, lub chronicznie spóźniający się zespół) należy uwzględniać w doskonaleniu procesu.

Dobrze prowadzone zarządzanie poprawkami zamienia ustalone priorytety ryzyka w mierzalne ograniczenie ryzyka realizowane na czas.

Należy potwierdzić rolę umów SLA dotyczących usuwania podatności.

Zarządzanie poprawkami doprowadza ustalenia o określonych priorytetach do końca poprzez identyfikację, ocenę, testowanie, etapowe wdrażanie i weryfikację, wspierane planami wycofania zmian i automatyzacją. Umowy SLA wyznaczają terminy zależne od poziomu ważności i ryzyka (krótsze w przypadku KEV lub zasobów dostępnych z Internetu), dzięki czemu poprawki są wdrażane na czas.

Jeśli zastosowanie poprawki jest niemożliwe, należy użyć mechanizmów kompensacyjnych oraz udokumentować ograniczoną czasowo akceptację ryzyka. Należy mierzyć MTTR, zgodność z SLA i pokrycie poprawkami, a następnie uwzględniać wnioski w całym cyklu życia.