Sam skan podatności nie poprawia bezpieczeństwa. Poprawia je dopiero dobrze ułożony plan działań po skanie. To dlatego w praktyce sam raport jest dopiero początkiem pracy. Jeżeli kończy się na długiej liście wykryć, z której nikt nie wie, co zrobić najpierw, to organizacyjnie niewiele z niego wynika.

Dlaczego raporty często nie pomagają

Najczęstszy problem z raportami podatności jest prosty: są zbyt techniczne dla biznesu i zbyt długie dla operacji. Z jednej strony pokazują dużo szczegółów, z drugiej nie odpowiadają jasno na pytania:

  • co naprawdę jest pilne,
  • co można zaplanować,
  • co jest podatnością realnie groźną w danym środowisku,
  • a co jest tylko informacją, którą warto mieć na radarze.

W efekcie raport ląduje w folderze, a środowisko dalej działa tak samo jak wcześniej.

Jak czytać wyniki sensownie

Najpierw trzeba oddzielić trzy rzeczy:

  1. podatności naprawdę pilne,
  2. problemy istotne, ale możliwe do zaplanowania,
  3. wykrycia, które wymagają weryfikacji lub mają niższy wpływ operacyjny.

Nie każda pozycja z wysokim CVSS oznacza ten sam poziom zagrożenia dla danej firmy. Liczy się też:

  • czy usługa jest publicznie dostępna,
  • czy problem dotyczy systemu krytycznego,
  • czy istnieją już inne warstwy ochrony,
  • czy błąd jest łatwy do wykorzystania w praktyce.

To właśnie miejsce, w którym skan trzeba zestawić z wiedzą o środowisku. Sam raport nie wie, które systemy są krytyczne dla firmy, które można chwilowo odizolować, a które wymagają działania jeszcze tego samego dnia.

Co powinno wyjść ze skanu

Dobrze przygotowane podsumowanie po skanie powinno kończyć się czymś znacznie prostszym niż sam raport:

  • lista rzeczy do poprawy od razu,
  • lista rzeczy do zaplanowania w oknie serwisowym,
  • lista tematów do obserwacji,
  • informacja, gdzie ryzyko jest największe.

To jest moment, w którym raport zaczyna być użyteczny dla firmy.

Jak ustalać priorytety

Największy sens ma priorytetyzacja łącząca trzy perspektywy:

  • istotność techniczną,
  • ekspozycję usługi,
  • wpływ biznesowy.

Przykładowo:

  • publicznie dostępny komponent ze znaną podatnością i prostą ścieżką ataku powinien mieć priorytet wyższy niż problem występujący tylko lokalnie w odizolowanym segmencie,
  • stary system krytyczny dla działania firmy wymaga osobnego podejścia niż mniej istotny host testowy,
  • czasem szybszy efekt daje ograniczenie ekspozycji niż natychmiastowa przebudowa całej usługi.

Jeżeli środowisko wymaga uporządkowania także od strony organizacyjnej, skan warto połączyć z bezpieczeństwem środowiska IT, bo dopiero wtedy wyniki skanu przekładają się na realny plan zmian, a nie na kolejny techniczny PDF.

Co warto robić po każdym skanie

Po każdym pełnym skanie warto przygotować krótkie podsumowanie:

  • co wykryto,
  • co naprawdę jest najpilniejsze,
  • co zostało już zabezpieczone inną warstwą,
  • co planujemy poprawić i w jakiej kolejności.

Dopiero wtedy skan ma wartość operacyjną.

Na co uważać przy interpretacji raportu

  • wykrycia informacyjne nie powinny przykrywać ryzyk pilnych,
  • wynik automatyczny warto potwierdzić na systemach krytycznych,
  • podatność na hoście testowym nie zawsze ma ten sam priorytet co na usłudze publicznej,
  • brak łatki nie zawsze oznacza brak możliwości ograniczenia ekspozycji.

Najczęstszy błąd

Najgorsze, co można zrobić, to potraktować raport jak listę „do wyczyszczenia do zera”. To zwykle kończy się frustracją, bo środowisko produkcyjne nie zawsze da się przebudować od razu. Lepsze jest podejście etapowe: najpierw ryzyka największe i najbardziej eksponowane, potem reszta według realnego wpływu.

Podsumowanie

OpenVAS ma największy sens wtedy, gdy nie kończy się na PDF-ie, tylko prowadzi do decyzji. Sam raport jest potrzebny, ale ważniejsze od liczby wykryć jest to, czy wiadomo, co zrobić najpierw i dlaczego.

Powiązane artykuły

Dobrze ułożony plan napraw zwykle zaczyna się od porządkowania ekspozycji usług. Dlatego naturalnym uzupełnieniem jest artykuł Hardening usług publicznych bez psucia działania firmy.