Przez lata zarządzanie podatnościami opierało się na założeniu, że obrońcy mają wystarczająco dużo czasu, aby zareagować przed atakującymi. Luka była ujawniana, zespoły bezpieczeństwa oceniały zakres problemu, testowały dostępną poprawkę, uzgadniały okno zmian i wdrażały aktualizację w środowisku produkcyjnym. Po zakończeniu tego procesu ryzyko miało zostać zamknięte. Ten model nadal jest potrzebny, ale coraz częściej nie odpowiada warunkom, w jakich działają współczesne organizacje.
Dlaczego tradycyjny model przestaje wystarczać
Przedsiębiorstwa korzystają dziś z tysięcy powiązanych systemów, aplikacji, baz danych, kontenerów i zasobów sieciowych działających w środowiskach hybrydowych oraz wielochmurowych. Część z nich obsługuje usługi generujące przychody, doświadczenia klientów albo kluczowe procesy operacyjne. Nie można ich po prostu wyłączyć w chwili udostępnienia aktualizacji. Poprawka musi zostać sprawdzona pod kątem zgodności z aplikacjami, zależnościami technicznymi i wymaganiami organizacji. W środowiskach regulowanych mogą być potrzebne dodatkowe testy, zatwierdzenia i uzgodnienia.
Jednocześnie informacje o nowych podatnościach rozchodzą się szybciej niż wcześniej. Publiczne komunikaty, badania bezpieczeństwa, przykładowe koncepcje wykorzystania luk i dane o zagrożeniach mogą być analizowane na całym świecie w ciągu kilku godzin. Microsoft wskazuje, że luka ujawniona rano może jeszcze tego samego dnia stać się przedmiotem aktywnego skanowania lub prób wykorzystania. Nie oznacza to, że każda podatność zostanie natychmiast zaatakowana, ale skraca czas, w którym organizacja może bezpiecznie przeprowadzić pełną remediację.
- Obrońcy muszą ocenić, które systemy są podatne i jak zmiana wpłynie na ich działanie.
- Poprawki trzeba często przetestować przed wdrożeniem do środowiska produkcyjnego.
- Aplikacje krytyczne mogą wymagać zaplanowanego okna zmian albo czasowego ograniczenia działania.
