Zarządzanie podatnościami oparte na ryzyku: jak findings stają się właściwymi priorytetami
We współczesnych operacjach IT ustalanie priorytetów podatności wyłącznie na podstawie wyników CVSS nie jest już wystarczające. Zarządzanie podatnościami oparte na ryzyku łączy techniczną dotkliwość z threat intelligence, kontekstem endpointów i znaczeniem biznesowym. Dzięki temu długie listy CVE przekształcają się w konkretne działania naprawcze.
Zarządzanie podatnościami oparte na ryzyku – W skrócie
- Wysoka ocena CVSS opisuje techniczną dotkliwość, ale nie rzeczywiste ryzyko dla własnej organizacji.
- Kontekst oprogramowania i endpointów, których dotyczy podatność, zmienia jej priorytet.
- Ustalanie priorytetów prowadzi do konkretnych działań, takich jak aktualizacje, instalacje i dezinstalacje.
- Proactive Hub łączy informacje o podatnościach ze stanem własnego środowiska IT.
Dashboard nie chroni. Działanie tak. Tak zaczynał się poprzedni artykuł o Auto Remediation. Zanim jednak dział IT może działać, musi zdecydować, od czego zacząć.
W zarządzaniu podatnościami bywa to bardziej złożone, niż można się spodziewać. Skanery i bazy danych bezpieczeństwa stale dostarczają nowych informacji o podatnościach. Nawet jedna nieaktualna aplikacja może generować liczne wpisy CVE. Lista rośnie, ale dostępny czas nie.
Rośnie również presja. Raport Mandiant M-Trends 2026 szacuje obecnie medianę czasu do wykorzystania podatności na minus siedem dni. Oznacza to, że podatności są regularnie wykorzystywane, zanim dostępna jest choćby poprawka.
Dlaczego klasyczne zarządzanie ryzykiem podatności dochodzi do granic swoich możliwości
Większość systemów zarządzania podatnościami kieruje się prostą zasadą: podatności krytyczne znajdują się na górze listy, a za nimi podatności o wysokiej, średniej i niskiej ocenie. Tworzy to wstępny porządek, ale nie jest to triage, który wystarcza w codziennej pracy.
Podatność z wysokim wynikiem CVSS (Common Vulnerability Scoring System) może bowiem dotyczyć aplikacji zainstalowanej tylko na trzech odizolowanych urządzeniach testowych. Tymczasem inna podatność może być technicznie oceniona niżej, ale znajdować się w przeglądarce obecnej na niemal wszystkich endpointach. Może istnieć dla niej nawet znany exploit albo urządzenia, których dotyczy podatność, mogą być używane przez pracowników z szerokimi uprawnieniami.
Aby ustalić wiarygodny priorytet, dział IT potrzebuje zatem dodatkowych informacji:
- Jakie wersje oprogramowania są faktycznie zainstalowane?
- Ile i które endpointy są objęte podatnością?
- Czy istnieją oznaki trwającego wykorzystywania?
- Które urządzenia lub grupy użytkowników są szczególnie narażone?
- Jak złożone i ryzykowne byłoby usunięcie podatności?
W zależności od odpowiedzi kolejność, w jakiej należy je usuwać, może się znacznie zmienić.
Od pojedynczych CVE do usuwania podatności bezpieczeństwa
Wpisy CVE opisują pojedyncze znane podatności. Administratorzy rzadko jednak pracują na tym poziomie. Dystrybuują aktualizację oprogramowania, zmieniają konfigurację albo instalują/odinstalowują aplikację.
Stara wersja oprogramowania może zawierać dziesięć lub dwadzieścia CVE. Na klasycznej liście daje to dziesięć lub dwadzieścia findings. Do ich usunięcia może jednak wystarczyć jedna aktualizacja.
Dlatego sensowne jest przesunięcie uwagi z pojedynczego CVE na podatną aplikację i możliwe działanie. W ten sposób wiele findings można skonsolidować w jedno konkretne zlecenie robocze.
Nie zmniejsza to sztucznie liczby wpisów. Ich znaczenie staje się wyraźniejsze. Administrator rozpoznaje, która aplikacja stwarza ryzyko, gdzie ono występuje i ile podatności można wyeliminować jednym działaniem.
Czym jest zarządzanie podatnościami oparte na ryzyku (RBVM)
Zarządzanie podatnościami oparte na ryzyku (Risk-based Vulnerability Management, RBVM) wykracza poza ocenę podatności wyłącznie na podstawie ich technicznej dotkliwości. Zamiast postrzegać każdą podatność w odosobnieniu, w procesie ustalania priorytetów wspólnie uwzględnia się krajobraz zagrożeń, podatne systemy i kontekst biznesowy.
Rozsądne podejście polega na tym, aby najpierw porównać wykryte aplikacje i wersje z wersjami, których faktycznie dotyczy dana CVE. Następnie odpowiednie podatności wzbogaca się o aktualne threat intelligence.
Obejmuje to
- techniczną dotkliwość,
- znane exploity,
- prognozę prawdopodobieństwa przyszłego wykorzystania,
- oraz kontekst danego środowiska IT (np. system testowy lub system krytyczny dla biznesu).
Daje to dokładniejszą ocenę niż sam wynik CVSS.
Podejście to staje się jeszcze bardziej wartościowe, gdy ocena zostanie następnie połączona z danymi endpointów, których dotyczy podatność. Administrator widzi wtedy, która
aplikacja i wersja są podatne, na których urządzeniach występują oraz jak duża jest potrzeba działania w jego własnym środowisku.
Ustalanie priorytetów podatności – i co dalej? Jak przekształcić wiedzę o bezpieczeństwie w stabilne IT
Jasny priorytet to pierwszy krok. Różnicę robi jednak dopiero właściwe działanie. W naszym Best Practice Guide „DEX & UEM – Praktyczna wiedza IT od IT dla IT” pokazujemy, jak podatne stany oprogramowania przekształcić w bezpieczne i wydajniejsze endpointy.
Nie każde ryzyko wymaga tego samego sposobu usuwania podatności
Wysoki priorytet nadal nie odpowiada na pytanie, jak należy usunąć podatność.
Przeglądarkę lub czytnik PDF można zwykle szybko i na dużą skalę zaktualizować. W przypadku oprogramowania krytycznego dla biznesu może to jednak mieć wpływ na interfejsy, rozszerzenia lub inne zależności. Natychmiastowy rollout na wszystkich endpointach mógłby w takim przypadku wywołać nowe zakłócenia i „digital friction”.
W przypadku standardowego oprogramowania odpowiednia może być w dużej mierze zautomatyzowana aktualizacja. Krytyczne aplikacje są najpierw aktualizowane na wybranych urządzeniach. Dopiero gdy nie pojawią się nowe anomalie, aktualizowana jest kolejna grupa endpointów.
Dzięki temu nawet pilny środek bezpieczeństwa pozostaje pod kontrolą. Ocena techniczna pokazuje, jak szybko dział IT powinien zareagować. Kontekst endpointu i aplikacji pomaga wybrać właściwe podejście.
„Dlaczego podatności nie powinny być postrzegane wyłącznie z perspektywy bezpieczeństwa?”
Robert Klinger (Product Manager): „Ponieważ często przejawia się to w tej samej aplikacji. Nieaktualne oprogramowanie działa na wielu endpointach, jest rzadko używane, ale powoduje obciążenie procesora i wiąże się ze znanymi podatnościami. Ktoś, kto patrzy wyłącznie na bezpieczeństwo, po prostu zaktualizowałby wszędzie. Dzięki kontekstowi endpointów działanie staje się bardziej ukierunkowane: aktywne urządzenia otrzymują bezpieczną wersję, a nieużywane instalacje są usuwane. Security i Digital Employee Experience postrzegają tutaj tę samą aplikację z różnych perspektyw. baramundi Proactive Hub gromadzi te informacje w jednym miejscu.”
Wnioski: od priorytetu do usuwania podatności bezpieczeństwa
Zatem długa lista otwartych CVE nie wskazuje jeszcze, od czego zespół IT powinien zacząć. Dopiero gdy podatności zostaną powiązane z rzeczywistym stanem własnego środowiska IT, ogólny security finding staje się konkretnym i sensownym działaniem.
Po każdym usunięciu podatności następuje weryfikacja: czy podatna wersja została faktycznie zastąpiona, czy nadal są jakieś urządzenia objęte podatnością, czy aktualizacja spowodowała nowe problemy?
baramundi Proactive Hub wspiera zespoły IT właśnie w tym zakresie: podatności są dopasowywane do istniejących endpointów, oceniane pod kątem istotności i konsolidowane w konkretne działania naprawcze.
