S t r o n a ǀ 1 z 5 Załącznik nr 1 do zapytania ofertowego Opis Przedmiotu Zamówienia na przeprowadzenie testów bezpieczeństwa systemu wspomagania nadzoru archiwalnego e-nadzór I. Definicje. 1. Dostawca wykonawca systemu wspomagania nadzoru archiwalnego e-nadzór. 2. System system wspomagania nadzoru archiwalnego e-nadzór (aplikacja Web). 3. Wykonawca wyłoniony w ramach postępowania o udzielenie zamówienia publicznego poniżej 30000 euro wykonawca zamówienia przedmiotem którego jest przeprowadzenie testów bezpieczeństwa Systemu e-nadzór. 4. Zamawiający Naczelna Dyrekcja Archiwów Państwowych. 5. Fuzz testing (fuzzing) automatyczna lub półautomatyczna metoda testowania oprogramowania lub znajdowania w nim błędów. II. Kontekst zamówienia. 1. Ogólne informacje o zakładanej funkcjonalności Systemu. System wspomagania nadzoru archiwalnego ma umożliwiać wprowadzanie, przechowywanie, edytowanie oraz analizę danych dotyczących stanu przechowywania materiałów archiwalnych w jednostkach organizacyjnych ustalonych jako wytwarzających materiały archiwalne. 2. Ogólne informacje o systemie. System będzie zbudowany z wykorzystaniem oprogramowania bazującego na otwartych standardach i bezpłatnych licencjach (technologia WAMP/LAMP). System w swym ogólnym założeniu będzie aplikacją web opartą na języku PHP i bazie danych MySQL. Oprogramowanie powinno pozwolić na jednoczesną pracę 50 użytkowników. Szacowany maksymalny rozmiar pamięci dyskowej zajmowanej przez dane nie powinien przekroczyć 2 GB, a w początkowym okresie eksploatacji nie powinien być większy niż 300 MB. III. Przedmiot zamówienia. 1. Przedmiotem zamówienia jest przeprowadzenie przez Wykonawcę na rzecz Zamawiającego testów bezpieczeństwa opracowywanego systemu wspomagania nadzoru archiwalnego e-nadzór. 2. Wykonawcą testów bezpieczeństwa nie powinien być Dostawca Systemu lub podmiot zależny od Dostawcy Systemu.
S t r o n a ǀ 2 z 5 3. Testy bezpieczeństwa wykonane zostaną w ramach sprawdzenia działania Systemu w zakresie zgodności z postawionymi Dostawcy wymaganiami i przeprowadzone zostaną w dwu etapach: a. Etap pierwszy testy przeprowadzone przed odbiorem oprogramowania Systemu (w ramach testowania funkcjonalności systemu testów działania), które stanowić mają praktyczną ocenę stanu bezpieczeństwa wykonanego Systemu. Oprogramowanie zostanie przetestowane na serwerze Dostawcy. b. Etap drugi testy zostaną przeprowadzone w ramach testów powdrożeniowych przed odbiorem wdrożonego Systemu, zainstalowanego na serwerze Zamawiającego i traktowane będą jako ostatnie sprawdzenie stanu bezpieczeństwa i poprawności funkcjonowania Systemu. IV. Założenia realizacyjne. 1. Wykonawca dostarczy Zamawiającemu kompletny model zagrożeń uwzględniający wszystkie role w testowanym Systemie oraz technologie, na których oparto testowany System (w terminie określonym w ppkt. V 1a). Model będzie wykonany według ogólnie przyjętej metodyki. 2. Na podstawie modelu Wykonawca opracuje i przekaże Zamawiającemu do akceptacji szczegółowy plan testów penetracyjnych opisanych w pkt. IV i VI (w terminie określonym w ppkt. V 1b). 3. Po zakończeniu testów przeprowadzonych w ramach wykonania pierwszej części przedmiotu umowy, w przypadku wykrycia nieprawidłowości Wykonawca nawiąże kontakt z przedstawicielami Dostawcy systemu, w celu wypracowania właściwych metod usunięcia wykrytych podatności. Po wprowadzeniu przez Dostawcę poprawek rekomendowanych przez Wykonawcę, Wykonawca przeprowadzi retest Systemu. Retest należy wykonać niezależnie od stopnia ryzyka wykrytych podatności (klasyfikacji ryzyka - krytyczne, średnie, niskie). W ramach retestu Wykonawca powinien min.: a) zweryfikować, czy wykryte podczas testów podatności i problemy z bezpieczeństwem zostały poprawnie rozwiązane, b) powtórzyć test penetracyjny typu white-box interfejsów dostępnych z Internetu, c) powtórzyć wewnętrzny test penetracyjny typu white-box interfejsów dostępnych w poszczególnych strefach DMZ, d) powtórzyć wewnętrzny test penetracyjny typu white-box styku interfejsów systemu i księgi głównej, 4. Na podstawie przeprowadzonych testów opisanych powyżej Wykonawca opracuje i przekaże Zamawiającemu (w terminie określonym w ppkt. V 1c), raport z przeprowadzonych testów. Raport powinien obejmować min.: a) streszczenie dla Kierownictwa Zamawiającego, b) opis wszystkich wykrytych podatności wraz z informacją o zastosowanej metodzie ich usunięcia, c) opinię o stanie bezpieczeństwa systemu, d) pozostałe rekomendacje. 5. Po zakończeniu testów przeprowadzonych w ramach wykonania drugiej części przedmiotu umowy, w przypadku wykrycia nieprawidłowości Wykonawca nawiąże kontakt z przedstawicielami Dostawcy systemu, w celu wypracowania właściwych
S t r o n a ǀ 3 z 5 metod usunięcia wykrytych podatności. Po wprowadzeniu przez Dostawcę poprawek rekomendowanych przez Wykonawcę, Wykonawca przeprowadzi retest Systemu. 6. Po zakończeniu testów opisanych powyżej, Wykonawca opracuje i przekaże Zamawiającemu (w terminie określonym w ppkt. V 1f), raport końcowy, opisujący aktualny poziom bezpieczeństwa i zawierający streszczenie dla Kierownictwa oraz opinię o stanie bezpieczeństwa Systemu i finalne rekomendacje zmierzające do dalszego podnoszenia poziomu jego bezpieczeństwa. Raport końcowy powinien również zawierać: a) definicje fuzzerów użytych do testowania aplikacji - materiał ten będzie stanowił część raportu końcowego jako załącznik, b) wynik automatycznego skanu kodu źródłowego jako załącznik do raportu końcowego. V. Harmonogram realizacji zamówienia. 1. Wykonawca zobowiązuje się w szczególności do wykonania wszystkich prac opisanych w opisie przedmiotu zamówienia, zgodnie z następującym harmonogramem prac: a) Wykonanie i dostarczenie (na informatycznym nośniku danych i w wersji papierowej) Zamawiającemu kompletnego modelu zagrożeń (opisanego w pkt. IV 1) w terminie do 29 września 2015 r. b) Wykonanie i dostarczenie (na informatycznym nośniku danych i w wersji papierowej) Zamawiającemu planu testów penetracyjnych (opisanych w pkt. IV, VI i VII) w terminie do 29 września 2015 r. c) przeprowadzenie testów penetracyjnych Systemu (opisanych w pkt. IV, VI i VII OPZ), w ramach testów działania w terminie do 29 września 2015 r., d) Wykonanie i dostarczenie (na informatycznym nośniku danych i w wersji papierowej) Zamawiającemu raportu z przeprowadzonych testów (opisanego w pkt. IV 4), w terminie do 29 września 2015 r. e) przeprowadzenie testów penetracyjnych Systemu (opisanych w pkt. IV, VI i VII OPZ),w ramach testów powdrożeniowych, w terminie do 12 listopada 2015 r. f) Wykonanie i dostarczenie (na informatycznym nośniku danych i w wersji papierowej) Zamawiającemu raportu końcowego z przeprowadzonych testów (opisanego w pkt. IV 6), w terminie do 12 listopada 2015 r. VI. Rodzaje przeprowadzonych testów penetracyjnych. 1. Testy penetracyjne przy założeniu zerowej wiedzy na temat badanego Systemu prowadzone z Internetu - typu black-box, (adres strony www na której będzie dostępny system zostanie podany Wykonawcy po podpisaniu umowy); a) analiza podatności Systemu pod kątem występowania błędów bezpieczeństwa, obejmująca co najmniej: - Configuration Management Testing, - Authorization and Authentication Testing, - Session Management Testing, - Data Validation Testing,
S t r o n a ǀ 4 z 5 - Testing for Denial of Service, - Web Service Testing, 2. Testy penetracyjne przy założeniu dysponowania standardowymi kontami w badanym systemie, mające na celu analizę podatności aplikacji na nieautoryzowane działania uprawnionych użytkowników (typu grey-box ); 3. Testy penetracyjne z dostępem testującego do kodu źródłowego i konfiguracji testowanej aplikacji oraz jej środowiska wykonania (typu white-box ). Wykonawca otrzyma także dokumentację projektową aplikacji przed rozpoczęciem testu; a) testy penetracyjne typu white-box interfejsów dostępnych z Internetu, b) testy penetracyjne wewnętrzne typu white-box interfejsów dostępnych w poszczególnych strefach DMZ, c) testy penetracyjne wewnętrzne typu white-box styku interfejsów systemu i księgi głównej, d) przegląd krytycznych fragmentów kodu (autoryzacja, uwierzytelnienie, filtrowanie danych, dostęp do bazy danych), e) raportowanie wykrytych podatności w trybie on-line, uznanych przez Wykonawcę jako krytyczne, natychmiast po ich wykryciu, do Zamawiającego, f) każda wykryta podatność musi zawierać opis oraz sugerowaną metodę jej wykorzystania, a także analizę skutków dla Zamawiającego możliwości jej wykorzystania. Na przykład w przypadku podatności typu przepełnienie bufora lub sterty należy podać adres powrotu oraz sugerowany sposób uruchomienia sheilcode u z uwzględnieniem wykorzystanych w docelowym systemie zabezpieczeń. W przypadku podatności w aplikacji webowej należy zademonstrować działający adres URL lub gotowy skrypt pozwalający na wykorzystanie podatności. 4. Testy wydajnościowe systemu w celu identyfikacji tzw. wąskich gardeł i błędów w implementacji na poziomie architektury sieciowej oraz samej aplikacji; 5. Testy wydajnościowe modułów raportujących; 6. Testy wydajnościowe krytycznych formularzy; 7. Testy wydajnościowe określające maksymalną liczbę użytkowników obsługiwanych równolegle; 8. Strategia usunięcia podatności; VII. Minimalne wymagania wobec testów penetracyjnych. 1. Test penetracyjny typu white-box interfejsu webowego: a) test wszystkich klas podatności z aktualnej listy OWASP Top 10, a w szczególności Injection (Al) i XSS (A2), b) testy bezpieczeństwa implementacji i konfiguracji protokołu SSL (A3, A6, A9), c) analiza bezpieczeństwa modelu i procesu uwierzytelnienia i autoryzacji, zgodnie z założeniami projektowymi oraz pod kątem bezpieczeństwa (A3), d) analiza bezpieczeństwa mechanizmu zarządzania sesją włącznie z jej kończeniem (A3), e) analiza walidacji danych wejściowych, f) analiza walidacji danych wyjściowych, g) zarządzanie plikami tymczasowymi, h) zarządzanie prawami dostępu do struktur katalogów na serwerach www (A8),
S t r o n a ǀ 5 z 5 i) fuzzing wszystkich pól formularzy, j) fuzzing wszystkich pól ciasteczek, k) fuzzing wszystkich pól protokołu aplikacyjnego, l) fuzzing wiadomości zapisywanych do dziennika zdarzeń (A7), m) ocena zgodności z ustawą o ochronie danych osobowych, n) przegląd wybranych przez Wykonawcę fragmentów kodu aplikacji: - przegląd za pomocą automatycznego skanera, - manualny przegląd kodu. 2. Testy penetracyjne typu white-box pozostałych interfejsów: a) skanowanie w poszukiwaniu podatności, b) fuzzing dostępnych protokołów sieciowych, c) test słabych haseł i domyślnych kont, d) testy procedur składowych baz danych. 3. Testy penetracyjne typu white-box komponentów Systemu: a) skanowanie pełnego zakresu portów TCP, b) skanowanie pełnego zakresu portów UDP; 4. Zakres zadań przeprowadzonych w ramach w/w testów obejmuje również min: a) próby enumeracji i wykorzystania znanych podatności w celu uzyskania nieautoryzowanego dostępu, b) próby podszywania się pod użytkownika/administratora i uzyskania nieautoryzowanego dostępu do systemu, c) próby zablokowania/umożliwienia dostępu do Systemu wszystkim lub wybranym jej użytkownikom, d) próby uzyskania nieautoryzowanego dostępu do danych przetwarzanych w systemie, e) próby uzyskania nieautoryzowanego dostępu do klientów zewnętrznych (np. poprzez podsłuch ruchu). f) próby dokonania nieautoryzowanych modyfikacji/usunięcia informacji w systemie, g) testy bezpieczeństwa aplikacji pod kątem typowych zagrożeń: - ataki semantyczne na adres URL, - ataki związane z ładowaniem plików, - ataki typu Cross-Site Scripting, - ataki typu CSRF, - podrabianie zarządzania formularza, - sfałszowanie żądania http, - ujawnienie uwierzytelnień dostępu, - wstrzykiwanie kodu SQL lub innych języków programowania, - ujawnienie danych przechowywanych w bazie, - kradzież cookies, - przechwytywanie sesji, - trawersowanie katalogów, - wstrzykiwanie poleceń systemowych.