Testy bezpieczeństwa systemów urzędu
Sprawdzamy, czy do serwisu, e-usługi lub systemu urzędu da się włamać albo wydostać z nich dane mieszkańców, zanim zrobi to ktoś niepowołany. Urząd otrzymuje listę znalezionych luk z opisem, jak je naprawić, a po naprawie sprawdzamy system ponownie.
Kiedy warto zlecić testy
Przed uruchomieniem
Nowy serwis, e-usługa lub aplikacja dla mieszkańców powinna zostać sprawdzona, zanim trafią do niej prawdziwe dane.
Po dużej zmianie
Nowy moduł, logowanie przez Profil Zaufany czy połączenie z innym systemem to nowe miejsca, w których może pojawić się luka.
Raz w roku
Regularne testy pokazują, czy system nadal jest bezpieczny, i pomagają udokumentować coroczny audyt bezpieczeństwa informacji.
Po incydencie
Gdy coś niepokojącego wydarzyło się w systemie, testy pomagają ustalić, którędy mogło dojść do ataku i co zabezpieczyć.
Co sprawdzamy
Szukamy luk w miejscach, przez które najczęściej dochodzi do wycieku danych lub przejęcia systemu.
Logowanie i hasła
Czy hasła są dobrze chronione, czy da się je odgadnąć metodą prób i błędów i czy wylogowanie naprawdę kończy sesję.
Uprawnienia
Czy mieszkaniec nie zobaczy cudzego wniosku, a pracownik danych spoza swojego wydziału, na przykład po zmianie numeru w adresie strony.
Formularze i pliki
Czy przez formularz albo załącznik nie da się wprowadzić do systemu szkodliwego kodu ani pliku.
Wymiana danych z innymi systemami
Połączenia z innymi systemami (API), na przykład z systemem dziedzinowym, płatnościami czy Węzłem Krajowym.
Serwer i szyfrowanie
Konfiguracja serwera, szyfrowane połączenia, kopie zapasowe dostępne z internetu i niepotrzebnie otwarte usługi.
Aktualność oprogramowania
Czy system i użyte w nim biblioteki nie mają znanych, opisanych publicznie luk, które łatwo wykorzystać.
Testujemy bezpiecznie dla urzędu
Test bezpieczeństwa to kontrolowana próba włamania, dlatego prowadzimy go według jasnych zasad:
- Testujemy wyłącznie za pisemną zgodą urzędu i w uzgodnionym zakresie.
- Ustalamy termin i godziny testów, a najlepiej testujemy na kopii systemu.
- Nie zmieniamy ani nie usuwamy danych i nie przeciążamy systemu, chyba że uzgodnimy to na piśmie.
- Poważną lukę zgłaszamy od razu, nie czekając na raport.
- Wyniki i dane, z którymi zetkniemy się podczas testów, traktujemy jako poufne.
Słowniczek
Luka (podatność)
Błąd w systemie, który pozwala zrobić coś, czego nie powinno się dać, na przykład zobaczyć cudze dane.
Test penetracyjny
Kontrolowana próba włamania do systemu, przeprowadzana za zgodą właściciela, żeby znaleźć luki przed atakującym.
Skan podatności
Automatyczne sprawdzenie systemu programem. Jest szybkie, ale wykrywa tylko typowe, znane problemy.
OWASP
Międzynarodowa organizacja, która publikuje uznane metodyki testowania bezpieczeństwa aplikacji internetowych.
Ponowny test
Sprawdzenie po naprawie, czy luka została usunięta skutecznie.
Jak przebiegają testy
- 01. Ustalamy zakres i zasady. Określamy, które systemy, adresy i role użytkowników sprawdzamy, w jakich godzinach i kto po stronie urzędu jest osobą kontaktową. Urząd potwierdza zakres na piśmie, a często uprzedza też firmę hostingową.
- 02. Testujemy. Sprawdzamy system według uznanych metodyk OWASP: najpierw narzędziami, a potem ręcznie, tak jak działałby atakujący. Poważne luki zgłaszamy od razu.
- 03. Przekazujemy raport. Raport omawiamy z urzędem i z zespołem, który utrzymuje system, ustalając, co naprawić najpierw.
- 04. Naprawa. Luki usuwa dostawca systemu, a w systemach, które utrzymujemy, robimy to sami.
- 05. Testujemy ponownie. Sprawdzamy, czy luki zostały usunięte skutecznie, i przekazujemy raport końcowy.
Co urząd otrzymuje
Raport ma dwie części: zrozumiałą dla kierownictwa i szczegółową dla dostawcy systemu.
Podsumowanie dla kierownictwa
Krótko i bez żargonu: jak bezpieczny jest system, jakie jest najważniejsze ryzyko i co zrobić najpierw.
Opis każdej luki
Na czym polega, jakie dane lub funkcje są zagrożone, jak bardzo jest groźna (od krytycznej do niskiej) i jak ją naprawić. Ta część jest przeznaczona dla dostawcy systemu.
Raport końcowy
Po ponownym teście: które luki usunięto, a które pozostały i dlaczego. Raport można dołączyć do dokumentacji audytu bezpieczeństwa informacji.
Pytania o testy bezpieczeństwa
Czym test penetracyjny różni się od skanu?
Skan to automatyczne sprawdzenie, które wykrywa typowe problemy. W teście penetracyjnym człowiek szuka luk tak, jak zrobiłby to atakujący, na przykład sprawdza, czy po zmianie numeru w adresie strony nie zobaczy cudzego wniosku. Takich błędów skaner zwykle nie znajdzie.
Czy testy mogą zakłócić pracę urzędu?
Testujemy na kopii systemu albo w uzgodnionych godzinach. Nie przeciążamy systemu i nie zmieniamy danych, chyba że uzgodnimy to na piśmie.
Czy zobaczycie dane mieszkańców?
Staramy się testować na danych przykładowych. Jeśli w trakcie testów zetkniemy się z prawdziwymi danymi, traktujemy je jako poufne i nie kopiujemy ich. Zasady zapisujemy w umowie, w razie potrzeby także w umowie powierzenia przetwarzania danych.
Czy testujecie systemy innych dostawców?
Tak. Potrzebna jest pisemna zgoda urzędu, a często także uprzedzenie dostawcy i firmy hostingowej. Raport przygotowujemy tak, żeby dostawca mógł od razu usunąć luki.
Jakie przepisy dotyczą bezpieczeństwa systemów urzędu?
Rozporządzenie w sprawie Krajowych Ram Interoperacyjności (Dz.U. 2024 poz. 773) wymaga od urzędów między innymi usuwania znanych podatności i przeprowadzania co najmniej raz w roku audytu wewnętrznego bezpieczeństwa informacji. Raport z testów pomaga to udokumentować, ale nie zastępuje całego audytu.
Ile trwają testy i ile kosztują?
To zależy od liczby systemów, ról użytkowników i połączeń z innymi systemami. Termin i cenę podajemy w ofercie, którą można wykorzystać do oszacowania wartości zamówienia.
Zacznijmy od rozmowy o zakresie
Przygotujemy propozycję zakresu i terminu testów dopasowaną do systemów urzędu.
- Zadzwoń +48 730 955 565
- Napisz biuro@netcorelabs.pl