Zarządzanie podatnościami oparte na ryzyku: jak na podstawie wyników ustalić właściwe priorytety

Sam panel kontrolny nie zapewnia ochrony. Działanie – tak. Tak zaczynał się poprzedni wpis o automatycznej remediacji (otwiera się w nowej karcie). Zanim jednak dział IT będzie mógł podjąć działania, musi zdecydować, od czego zacząć.

W zarządzaniu podatnościami często jest to bardziej skomplikowane, niż się wydaje. Skanery i bazy danych bezpieczeństwa ciągle dostarczają nowych informacji o lukach. Nawet jedna przestarzała aplikacja może generować mnóstwo wpisów CVE. Lista się wydłuża, ale czas, który masz do dyspozycji, nie.

A presja rośnie. Raport (otwiera się w nowej karcie) Mandiant M-Trends 2026 (otwiera się w nowej karcie) szacuje, że średni czas do wykorzystania luki wynosi obecnie około minus siedmiu dni. Oznacza to, że luki są regularnie wykorzystywane, zanim w ogóle pojawi się łatka.

Systemy zarządzania podatnościami zazwyczaj działają według prostej zasady: na górze są krytyczne luki, a potem te o wysokim, średnim i niskim poziomie zagrożenia. To pozwala na wstępne uporządkowanie, ale nie jest to selekcja wystarczająca w codziennej pracy.

Bo luka o wysokiej wartości CVSS (Common Vulnerability Scoring System) (otwiera się w nowej karcie) może dotyczyć aplikacji zainstalowanej tylko na trzech odizolowanych urządzeniach testowych. Tymczasem inna luka, choć technicznie oceniona niżej, występuje w przeglądarce na prawie wszystkich punktach końcowych. Może nawet istnieje już znany exploit dla tej luki, albo urządzenia, na których się ona znajduje, są używane przez pracowników z szerokimi uprawnieniami.

Aby ustalić wiarygodny priorytet, dział IT potrzebuje więc dodatkowych informacji:

• Jakie wersje oprogramowania są faktycznie zainstalowane?
• Ile i jakie punkty końcowe są zagrożone?
• Czy są jakieś oznaki, że ktoś z tego właśnie korzysta?
• Które urządzenia lub grupy użytkowników są szczególnie narażone?
• Jak pracochłonne i ryzykowne byłoby usunięcie tego problemu?

W zależności od odpowiedzi kolejność, w jakiej trzeba je usunąć, może się znacznie zmienić. 

Wpisy CVE opisują poszczególne znane luki w zabezpieczeniach. Administratorzy rzadko jednak działają na tym poziomie. Rozpowszechniają aktualizację oprogramowania, zmieniają konfigurację albo instalują/odinstalowują aplikację.

Stara wersja oprogramowania może zawierać dziesięć czy dwadzieścia wpisów CVE. Na klasycznej liście daje to dziesięć czy dwadzieścia zgłoszeń. Jednak do usunięcia tych luk w niektórych przypadkach wystarczy jedna aktualizacja.

Dlatego warto skupić się nie na poszczególnych wpisach CVE, a na aplikacji, której to dotyczy, i możliwych działaniach. W ten sposób kilka zgłoszeń można połączyć w jedno konkretne zadanie.

Nie zmniejsza to sztucznie liczby wpisów. Ich znaczenie staje się bardziej zrozumiałe. Administrator rozpoznaje, która aplikacja powoduje ryzyko, gdzie się ono pojawia i ile luk można wyeliminować jednym działaniem.

Zarządzanie podatnościami w oparciu o ryzyko (RBVM) wykracza poza ocenę podatności wyłącznie na podstawie ich technicznej wagi. Zamiast patrzeć na każdą podatność osobno, przy ustalaniu priorytetów bierze się pod uwagę sytuację zagrożenia, systemy, których to dotyczy, oraz kontekst biznesowy.

Rozsądnym podejściem jest najpierw zestawienie wykrytych aplikacji i wersji z faktycznie dotkniętymi wersjami z bazy CVE. Następnie odpowiednie luki uzupełnia się aktualnymi informacjami o zagrożeniach.

Obejmują one

• stopień zagrożenia technicznego, 
• znane exploity, 
• prognozę prawdopodobieństwa przyszłego wykorzystania luki,
• oraz kontekst danego środowiska IT (np. system testowy czy krytyczny dla działalności). 

W ten sposób uzyskuje się dokładniejszą ocenę niż na podstawie samej wartości CVSS.

Podejście to staje się jeszcze bardziej sensowne, gdy ta ocena zostanie następnie powiązana z danymi dotyczącymi zagrożonych punktów końcowych. Administrator widzi wtedy, która aplikacja i wersja są zagrożone, na jakich urządzeniach się znajdują oraz jak pilne jest podjęcie działań w jego środowisku.
 

Nawet wysoki priorytet nie mówi jeszcze, jak należy usunąć lukę w zabezpieczeniach.

Przeglądarkę czy czytnik PDF zazwyczaj da się szybko i szeroko zaktualizować. Natomiast w przypadku oprogramowania o kluczowym znaczeniu dla firmy może to wpływać na interfejsy, rozszerzenia lub inne zależności. Natychmiastowe wdrożenie na wszystkich punktach końcowych mogłoby tu spowodować nowe zakłócenia i „cyfrowe tarcia (otwiera się w nowej karcie)”.

W przypadku standardowego oprogramowania w niektórych sytuacjach sprawdzi się w dużej mierze zaautomatyzowana aktualizacja. Aplikacje o krytycznym znaczeniu aktualizuje się najpierw na wybranych urządzeniach. Dopiero gdy nie pojawią się żadne nowe problemy, aktualizację przeprowadza się na kolejnej grupie punktów końcowych.

W ten sposób nawet pilne działania związane z bezpieczeństwem pozostają pod kontrolą. Ocena techniczna pokazuje, jak szybko dział IT powinno zareagować. Kontekst punktów końcowych i aplikacji pomaga w wyborze odpowiedniego postępowania.

Długa lista otwartych CVE’ów nie mówi więc jeszcze, od czego powinien zacząć zespół IT. Dopiero gdy powiążesz luki z faktycznym stanem swojego środowiska IT, ogólne ustalenie dotyczące bezpieczeństwa IT zamieni się w konkretne, sensowne działanie.

Po każdej remediacji następuje kontrola: czy podatna na atak wersja została faktycznie zastąpiona, czy nadal są dotknięte tym problemem jakieś urządzenia, czy aktualizacja spowodowała nowe problemy?

baramundi Proactive Hub (otwiera się w nowej karcie) wspiera zespoły IT właśnie w tym zakresie: luki w zabezpieczeniach są porównywane z istniejącymi punktami końcowymi, oceniane pod kątem istotności i łączone w konkretne działania remediacyjne.