Jak nie zamawiać testów penetracyjnych

Dobrze, że urzędy zamawiają testy penetracyjne swoich serwisów. Źle, że nie potrafią poprawnie opisać przedmiotu zamówienia.

Dobrze, że urzędy zamawiają testy penetracyjne swoich serwisów. Źle, że nie potrafią poprawnie opisać przedmiotu zamówienia. Spójrzmy na niedawne ogłoszenie UM Krakowa. Przedmiot zamówienia:

"... przeprowadzenie audytu w obszarze bezpieczeństwa teleinformatycznego na zgodność z normą ISO 27001 tj. wykonanie testów penetracyjnych polegających na przeprowadzeniu kontrolowanego ataku na system informatyczny..."

To całkowite pomieszanie pojęć. Audyt to audyt. Test penetracyjny to test penetracyjny. Jedno z drugim ma mało wspólnego. Choć norma ISO 27001 jako jedno z zabezpieczeń wymienia testy penetracyjne to wymienia je między kopiami zapasowymi, kontrolą dostępu czy zarządzaniem licencjami na oprogramowanie. Zakres audytu jest więc o wiele szerszy niż testu penetracyjnego. Co za tym idzie, zamawiający musi być znacznie lepiej przygotowany do audytu na zgodność z normą ISO 27001 bo ocenie nie będzie podlegać sam serwer (jak przy teście penetracyjnym), ale cała instytucja - od strony organizacyjnej, technicznej i każdej innej, która składa się na "zintegrowany system zarządzania bezpieczeństwem" (ISMS). Czy zamawiający jest na to przygotowany? Prawdopodobnie nie. Czy o to mu chodziło? Z pewnością nie. Nieco precyzyjniej opisuje zamiary zamawiającego załącznik nr 3 (umowa) ale wynika z niej, że zakres ten jest z kolei o wiele szerszy niż sam test penetracyjny (np. analiza konfiguracji) ale nadal koncentruje się na kwestiach bezpieczeństwa sieciowego.

Że trudno jest to poprawnie opisać? Zapewne tak. Testy penetracyjne z definicji trudno usystematyzować i opisać pod kątem poprawnego zamówienia. Co nie znaczy, że jest to niemożliwe - można wykorzystać którąś z istniejących metodyk testów penetracyjnych, zalecenia dotyczące testowania aplikacji (OWASP) czy wręcz katalogi dziur (WASC, OWASP). Tyle, że trzeba dokładnie rozumieć co chce się osiągnąć.

Nieco bardziej rozbudowanym przykładem jest sierpniowy SIWZ MSWiA na testy ePUAP. W SIWZ zamawiający oczekuje przeprowadzenia audytu systemu zarządzania bezpieczeństwem informacji w systemie ePUAP na zgodność z wymaganiami normy PN-ISO/IEC 27001, po czym następuje lista zadań (np. walidacja danych wejściowych), które pasują jak najbardziej do testu penetracyjnego ale nijak do audytu! Co gorsze, dalej następuje koncert życzeń zawierający kurioza takie jak bliżej niesprecyzowane testy wydajnościowe (zapewnia wymaganą wydajność - wymaganą do czego? przy jakich założeniach?) czy poziom rozwiązania Planu awaryjnego...

Podsumowując: szanowni koledzy i koleżanki z sektora publicznego - gdy zamawiacie tego typu usługi to pamiętajcie, że słowo "audyt" ma określone znaczenie i nie jest to "coś z testowaniem bezpieczeństwa". Problem nazywania "audytem" wszystkich testów jak leci jest znany od dawna (patrz artykuł Krzysztofa Lidermana). Problem polega także na tym, że na tak sformułowane zamówienie można otrzymać równie ogólnikową wykonaną i nieweryfikowalną pod względem poprawności usługę. Równocześnie przy takim określeniu przedmiotu zamówienia możecie otrzymać oferty za kilkaset tysięcy złotych za usługę, która przy poprawnym sformułowaniu warta byłaby kilkanaście-kilkadziesiąt tysięcy!

Jak ten problem rozwiązać? Któryś z urzędów centralnych powinien zamówić wzorcową, poprawną umowę testu penetracyjnego i udostępniać ją wszystkim zainteresowanym urzędom. Do pomocy można zaangażować aktywne w Polsce stowarzyszenia branżowe takie jak OWASP czy ISSA. A w pierwszej kolejności należy przeczytać zgłaszane przez oferentów pytania do SIWZów, bo jasno z nich wynika co budziło największe wątpliwości.