Polityka bezpieczeństwa to nie dowód, że proces KSC działa
Mam politykę zarządzania podatnościami. Mam skaner, który codziennie sprawdza, czy któreś CVE wykryte na moich maszynach trafiło do katalogu podatności wykorzystywanych w atakach. Skaner chodził, polityka obowiązywała, a odpowiedź, którą dostawałem, była nieprawdziwa.
Sprawdzenie porównuje moje podatności z kopią katalogu KEV, czyli listy prowadzonej przez amerykańską agencję CISA, na którą trafiają podatności z dowodami wykorzystania w prawdziwych atakach. W pomiarze z 19 września katalog miał 1716 pozycji. Moja kopia miała 390, bo synchronizacja nigdy się nie uruchomiła. Odpowiedź "żadne CVE z twojej floty nie jest w tym katalogu" powstawała więc z porównania z niecałą jedną czwartą listy i brzmiała dokładnie tak samo pewnie, jak brzmiałaby prawda.
Po uzupełnieniu katalogu wyszło siedem unikalnych CVE w 95 instancjach na pięciu maszynach. Wszystkie siedem występuje na trzech maszynach wystawionych do internetu, a dwa z nich, oba w pakietach jądra, także na dwóch maszynach wewnętrznych. Pełne wyliczenie opisałem w tekście o tym, co siedzi na dziewięciu zwykłych serwerach.
Nic się nie zapaliło na czerwono. Z punktu widzenia mechanizmu wszystko było w porządku: pytanie zadane, odpowiedź zwrócona, status zielony.
Dlaczego to jest problem audytowy, a nie tylko mój
Gdyby ktoś zapytał mnie wtedy, czy sprawdzam podatności pod kątem aktywnego wykorzystania, odpowiedziałbym "tak, automatycznie, codziennie". Odpowiedź byłaby prawdziwa. Miałbym na to politykę, miałbym zrzut ekranu i miałbym logi pokazujące, że sprawdzenie się wykonało.
Dopiero drugie pytanie pokazuje różnicę: wobec ilu pozycji katalogu to sprawdzenie się odbyło.
Art. 10 ust. 2 ustawy o KSC zalicza do dokumentacji bezpieczeństwa dokumentację normatywną i operacyjną, a ust. 4 opisuje tę drugą jako zapisy poświadczające wykonywanie czynności wymaganych przez dokumentację normatywną. Polityka jest jednym z dokumentów normatywnych i opisuje zamiar. Zapis operacyjny ma pokazać wykonanie.
Z mojego przypadku wynika trzecia warstwa, której ustawa nie nazywa, ale którą warto sobie dopisać: zapis operacyjny potrafi być zielony i jednocześnie obejmować ułamek zakresu. Mechanizm wykonał się poprawnie i objął jedną czwartą katalogu, a jedno z drugim nie ma nic wspólnego.
Zasada i jej dowód
Stąd praktyczna kontrola, którą sobie po tej historii ustawiłem. Przy wymaganiu, które ma mierzalny zakres, sprawdzam osobno dwie rzeczy: czy czynność się wykonała i jak daleko sięgnęła.
Weźmy zdanie "wszystkie systemy są regularnie skanowane". Dowodem wykonania jest historia skanów, dowodem zakresu porównanie tej historii z inwentarzem. Sama historia nie odpowiada na pytanie, czego w niej nie ma.
Jeżeli polityka mówi "podatności krytyczne mają termin", zapis powinien pokazać datę wykrycia, nadany termin i datę, od której pozycja przestała być widoczna w kolejnych udanych skanach. To ostatnie nie jest jeszcze potwierdzeniem naprawy: status "naprawione" jest decyzją operatora i wymaga osobnego dowodu zmiany.
Jeżeli polityka dopuszcza wyjątki, dowodem jest decyzja uprawnionej osoby z uzasadnieniem, środkami kompensacyjnymi i datą wygaśnięcia.
Nadzór kierownictwa nad ryzykiem potwierdzają datowane raporty, protokoły przeglądów i zapisane decyzje. Tabela odpowiedzialności pokazuje, komu przypisano rolę, ale nie to, że nadzór się odbył.
Jeżeli polityka mówi, że korzystasz z zewnętrznego źródła wiedzy, katalogu podatności wykorzystywanych w atakach albo bazy dostawcy, dowodem nie jest sam fakt integracji. Dowodem jest to, ile pozycji tego źródła faktycznie znasz i kiedy ostatnio się zaktualizowało.
Nie produkuj dowodów dla samych dowodów
Najtańszy model to taki, w którym ślad powstaje przy wykonywaniu pracy. Kolejny udany skan zapisuje datę, od której pozycja przestała być wykrywana. Akceptacja ryzyka wymaga właściciela i terminu przeglądu. Import skanu zapisuje maszynę, czas i wynik. Raport jest widokiem tych danych, a nie osobnym ręcznym dokumentem.
Dwie rzeczy, których taki ślad sam z siebie nie da, i warto o nich wiedzieć od razu. Pierwsza to pokrycie: sam skaner nie wie o maszynach, których mu nie wskazano, więc listę maszyn trzeba porównać z inwentarzem prowadzonym gdzie indziej. Druga to potwierdzenie naprawy: zniknięcie pozycji ze skanu znaczy tylko tyle, że skaner jej już nie widzi, a to nie to samo co naprawa, bo pakiet mógł zostać odinstalowany albo skaner zmienił sposób rozpoznawania.
Secvalis wspiera ten model w zakresie technicznego zarządzania podatnościami. Nie obejmuje całego SZBI, nie potwierdza kompletności inwentarza i nie zamienia zapisów w dowód zgodności.
Jeśli chcesz zobaczyć, jak wygląda eksport za wybrany okres, otwórz demo Secvalis.
Źródła
Cotygodniowy digest CVE
Jeden mail w tygodniu z nowo opublikowanymi podatnościami, o których warto wiedzieć. Bez zakładania konta.
Digest dotyczy ogólnie nowych podatności, nie Twoich serwerów. Jeśli chcesz wiedzieć, które z nich faktycznie działają w Twojej infrastrukturze, tym zajmuje się Secvalis : skanuje Twoje maszyny i zgłasza wyłącznie to, co ich dotyczy.