Opis przedmiotu zamówienia

Stronaǀ 1z5
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.
Stronaǀ 2z5
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
Stronaǀ 3z5
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,
Stronaǀ 4z5
2.
3.
4.
5.
6.
7.
8.
VII.
- Testing for Denial of Service,
- Web Service Testing,
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”);
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.
Testy wydajnościowe systemu w celu identyfikacji tzw. „wąskich gardeł” i błędów w
implementacji na poziomie architektury sieciowej oraz samej aplikacji;
Testy wydajnościowe modułów raportujących;
Testy wydajnościowe krytycznych formularzy;
Testy wydajnościowe określające maksymalną liczbę użytkowników obsługiwanych
równolegle;
Strategia usunięcia podatności;
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),
Stronaǀ 5z5
i)
j)
k)
l)
m)
n)
fuzzing wszystkich pól formularzy,
fuzzing wszystkich pól ciasteczek,
fuzzing wszystkich pól protokołu aplikacyjnego,
fuzzing wiadomości zapisywanych do dziennika zdarzeń (A7),
ocena zgodności z ustawą o ochronie danych osobowych,
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.