Z pamiętnika admina #4

Raport podatności, który miał 200 czerwonych punktów

„Z pamiętnika admina” to cykl artykułów opartych na autentycznych doświadczeniach – bez podręcznikowej teorii, za to z konkretami prosto z placu boju. 

Pełna lista odcinków: tutaj

Skaner skończył pracę w nocy. Rano w skrzynce czeka raport. PDF ma kilkadziesiąt stron, eksport CSV setki wierszy, a dashboard świeci czerwienią.

Kilka pozycji ma severity critical, trochę high, dużo medium i trochę low, które też wyglądają groźnie, bo mają długie nazwy i numer CVE.

Menedżer pyta:

Co łatamy najpierw?

To jest pytanie, na które raport skanera nie odpowiada.

Raport mówi, co znalazł. Nie mówi, co jest najważniejsze dla Twojej organizacji. Ta różnica decyduje o tym, czy zespół realnie zmniejsza ryzyko, czy tylko walczy z kolorem czerwonym.

Najgorsza możliwa odpowiedź brzmi:

Posortujmy po CVSS.

Miara CVSS (czyli Common Vulnerability Scoring System) jest użyteczna, daje wspólny język i pomaga porównywać podatności. Nie zna jednak Twojej sieci. Nie wie, czy usługa jest wystawiona do Internetu, czy działa w odizolowanym segmencie. Nie wie, czy system obsługuje produkcję, czy jest zapomnianym labem.

Nie wie też, czy wykorzystanie podatności jest praktyczne w Twojej konfiguracji, czy masz WAF, segmentację, VPN, EDR albo inną kontrolę kompensującą potencjalne problemy. Nie zna właściciela systemu, dostępności poprawki ani tego, czy zmiana może wywołać przestój w działaniu firmy.

AI nie naprawi brakującego kontekstu, AI może ten błąd tylko przyspieszyć.

Jeśli wrzucisz raport do modelu i napiszesz „zrób TOP 10”, prawdopodobnie dostaniesz ładną listę. Będą nagłówki, uzasadnienia i priorytety. Lista będzie wyglądała jak plan.

Jeżeli punkt wyjścia stanowi tylko raport, w efekcie otrzymasz plan oparty na niepełnym obrazie świata.

Priorytetyzacja podatności wymaga połączenia kilku rodzajów informacji:

• wyniku skanera;
• ekspozycji usługi;
• krytyczności zasobu;
• właściciela systemu;
• kontekstu biznesowego;
• możliwości praktycznego wykorzystania podatności;
• dostępności poprawki;
• ryzyka zmiany;
• okna serwisowego;
• mechanizmów kompensujących (czy też mitygujących);
• wymagań audytowych, kontraktowych lub regulacyjnych.

Dopiero na takim materiale AI zaczyna zwracać sensowne wyniki.

Jak z raportu zrobić plan działania?

Najpierw porządkujemy wynik skanera i uzupełniamy każde znalezisko o informacje, których sam skaner nie ma.

Sprawdzamy między innymi:

• czy system jest publiczny czy wewnętrzny;
• czy to produkcja, test czy lab;
• kto jest właścicielem biznesowym;
• w jakim segmencie działa usługa;
• czy istnieje znany sposób wykorzystania podatności;
• czy jej wykorzystanie wymaga uwierzytelnienia;
• czy usługa jest krytyczna;
• czy istnieje obejście tymczasowe (np. virtual patching, o którym opowiadałem w ramach Akademii NIS2/KSC);
• czy poprawka wymaga przestoju (restartów lub większych operacji).

Dopiero wtedy prosimy model o propozycję priorytetów. Polecenie nie powinno brzmieć „posortuj”. Powinno wymuszać oddzielenie faktów od hipotez, pokazanie brakujących danych i uzasadnienie każdej rekomendacji.

Przykładowe polecenie:

Oddziel fakty od hipotez. Zaproponuj TOP 5 działań. Dla każdego podaj uzasadnienie oparte na ekspozycji, możliwości wykorzystania podatności, krytyczności zasobu, ryzyku zmiany i brakujących danych. Nie sortuj wyłącznie po CVSS.

To ostatnie zdanie jest ważne, bo model ma naturalną skłonność do eleganckiego porządkowania. Tymczasem poprawna odpowiedź czasem brzmi:

• „Tego nie wiemy”.
• „Najpierw zapytajmy właściciela”.
• „Najpierw zmniejszmy ekspozycję”.
• „Poprawka jest ryzykowna, więc zastosujmy obejście i zaplanujmy okno”.
• „Najpierw potwierdźmy wersję, bo skaner mógł zinterpretować baner”.

Najważniejszy krok: przegląd ze strony admina

Admin albo inżynier bezpieczeństwa patrzy na propozycję modelu i ją poprawia:

To jest critical, ale dotyczy wyłącznie labu, więc spada niżej.

To jest medium, ale usługa jest publiczna i łatwa do wykorzystania, więc idzie wyżej.

Dziś nie wgrywamy poprawki. Ograniczamy dostęp z Internetu i zakładamy zgłoszenie do właściciela ERP.

Po takiej operacji mamy już TOP 5, szybkie działania, właścicieli usług, tickety do założenia, znamy ryzyka i rzeczy do sprawdzenia, mamy komunikat dla menedżera i następny krok do wykonania. To jest coś, z czym można iść na spotkanie, a nie tylko powiedzieć: „mamy dużo czerwonego”.

Co może zrobić AI?

AI dobrze pomaga w przygotowaniu pierwszego szkicu. Grupuje podobne podatności. Streszcza opisy. Wyciąga powtarzalne technologie. Proponuje tytuł ticketa. Przygotowuje komunikat nietechniczny dla użytkowników.

Nie zna jednak Twojej tolerancji ryzyka. Nie wie, że system „tymczasowy” obsługuje proces, którego nikt nie chce dotykać przed końcem miesiąca. Nie wie, czy właściciel ma zasoby, żeby zrobić zmianę. Nie podejmuje odpowiedzialności za priorytet.

Dlatego szablon priorytetyzacji powinien wymuszać język decyzji, a nie tylko język opisów CVE. Przydatne pola to między innymi:

Public exposure, Asset criticality, Known exploit, Auth required, Business owner, Compensating controls, Patch complexity, Proposed action, Human review note, Ticket link.

Bez takich pól model wróci do języka severity, bo to najłatwiejszy porządek.

Jak rozmawiać o tym z menedżerem?

AI może pomóc także w komunikacji. Techniczny raport mówi: „CVE-XXXX, vulnerable component, severity high”. Menedżer potrzebuje usłyszeć:

Mamy trzy rzeczy do zrobienia w tym tygodniu, dwie ograniczamy konfiguracją, jedna wymaga okna serwisowego, a pięć pozycji zostawiamy po weryfikacji jako niższy priorytet.

Efekt tego podejścia to nie tylko lista napraw, to zmiana prowadzenia dialogu. Zamiast „dlaczego mamy tyle czerwonego?” pojawia się:

Co realnie zmniejszy ryzyko w ciągu najbliższych 72 godzin?

Raport skanera jest początkiem. Plan zaczyna się wtedy, gdy wiadomo, co robimy najpierw, dlaczego, kto to robi, jak mierzymy efekt i co odkładamy świadomie (i kiedy do tego wrócimy).

Krótko mówiąc – AI może pomóc przygotować materiał, ale to admin bierze odpowiedzialność za priorytety.

~Maciej Szymczak