Test podatności ≠ test penetracyjny
Dość częstym zjawiskiem jest mylenie dwóch pojęć (test podatności oraz test penetracyjny) przez jednostki zamawiające usługi. W szczególności odzwierciedla to audyt Krajowych Ram Interoperacyjności, co wiąże się ze sporymi różnicami kosztów po stronie zamawiającego jak i wykonawcy.
Test podatności jest skanowaniem / wykrywaniem luk. Natomiast test penetracyjny jest przeprowadzaniem kontrolowanego ataku na system IT jednostki jako „przedłużenie” testu podatności. Jest to zasadnicza różnica pomiędzy oba testami, przy czym test podatności jest najtrafniejszą interpretacją zapisów rozporządzenia Krajowych Ram Interoperacyjności.
W rozporządzeniu Krajowych Ram Interoperacyjności (link do tekstu jednolitego) w § 20 ust. 2 pkt 12 lit. f oraz g mowa jest o opublikowanych podatnościach technicznych:
Rozporządzenie Krajowych Ram Interoperacyjności z dnia 12 kwietnia 2012r. (Dz.U. 2017.2247)
§ 20 ust. 2 | Zarządzanie bezpieczeństwem informacji realizowane jest w szczególności przez zapewnienie przez kierownictwo podmiotu publicznego warunków umożliwiających realizację i egzekwowanie następujących działań:
[…]
pkt 12 | zapewnienia odpowiedniego poziomu bezpieczeństwa w systemach teleinformatycznych, polegającego w szczególności na:
[…]
lit. f | redukcji ryzyk wynikających z wykorzystania opublikowanych podatności technicznych systemów teleinformatycznych,
lit. g | niezwłocznym podejmowaniu działań po dostrzeżeniu nieujawnionych podatności systemów teleinformatycznych na możliwość naruszenia bezpieczeństwa,
Opublikowane podatności
Frazę „opublikowanych podatności” najprościej utożsamić ze zjawiskiem ogólnodostępnych baz danych podatności (np. CVE). Takowe bazy są aktualizowane od wielu lat i są podstawą dla każdego informatyka/pentestera. Oczywiście ręczne przeglądanie jest wykonalne, jednakowoż w praktyce wykorzystuje się m.in zautomatyzowane oprogramowania oraz indywidualne rozwiązania IT. Pierwszym etapem jest test podatności (wyszukiwanie luk) co niejednokrotnie może być wystarczające, ale nie jest to regułą. Takowe testy powinny dotyczyć wewnętrznej i zewnętrznej infrastruktury jednostki. Przykładem są np. serwery wewnętrzne / chmurowe / kolokowane, punkty styku WAN/LAN, urządzenia brzegowe, komputery, drukarki, oprogramowanie itd… Natomiast drugim etapem jest wskazanie sposobu zniwelowania podatności (wyszukanych luk) co w naszej organizacji jest standardem. Oczywiście jest to bardzo ogólne zestawienie wymagające większej szczegółowości.
Techniki testów
Obligatoryjnym jest ustalenie techniki wykonywanych testów (Black Box, Grey Box, White Box). Jest to ustalenie sposobu pozyskiwania danych. Przykładowo techniką jest brak jakichkolwiek wewnętrznych informacji o jednostce, „pół na pół” czy też pełna wiedza o infrastrukturze.
Test penetracyjny
Uzupełnieniem całego procesu może być test penetracyjny w zależności od uwarunkowania oraz zapotrzebowania. Warto jednak pamiętać, iż w sektorze realizującym zadania publiczne wykonywanie testów penetracyjnych nie jest takie oczywiste z punktu formalno-prawnego. Ale to już inna, dłuższa historia.
Testy socjotechniczne
Warto też pamiętać, iż testy socjotechniczne (zjawisko inżynierii społecznej) są ciekawym dopełnieniem całego procesu testowania. Ich sposób oraz rodzaj przeprowadzenia jest dość indywidualny wobec każdej sytuacji.
Więcej szczegółów można się dowiedzieć na naszych szkoleniach oraz na stronie www.audytkri.pl