Nr sprawy: SM-WZP-2131-19/16 Załącznik nr 1.1 do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA ZADANIE I. Świadczenie usługi w zakresie dostępu do Internetu SŁOWNIK 1. Centrala lokalizacja Zamawiającego ul. Młynarska 43/45 2. Zapasowe Centrum Danych - lokalizacja Zamawiającego ul. Klimczaka 4 3. SM Straż Miejska m. st. Warszawa. 4. SLA Service Level Agreement część umowy pomiędzy Zamawiającym a Wykonawcą gwarantująca utrzymanie ustalonego poziomu jakości usług będących przedmiotem niniejszego Zamówienia (dostępność i sposób reakcji na awarię). 5. IP - Internet Protocol wersja 4 6. Przestrzeń adresowa typu Provider Independent (PI) blok adresów IP przyznany przez RIRa (Regional Internet Registry) bezpośrednio użytkownikowi końcowemu. Zamawiający w niniejszym postępowaniu wymaga od Wykonawców realizacji usług w określonym standardzie, na świadczenie usług dostępu do Internetu dla SM. 1. Dostarczenie, instalację i konfigurację, utrzymanie przez okres 3 lat usługi operatorskiej sieci teleinformatycznej w zakresie usługi dostępu do sieci Internet w lokalizacjach Centrala i Zapasowe Centrum Danych. 2. Poprzez świadczenie usługi rozumie się: a. uruchomienie dostępu, utrzymanie w ruchu i przekazanie do stałego (24 godziny na dobę) użytkowania, b. udostępnienie podstawowego i zapasowego łącza transmisyjnego z medium kablowym o określonych parametrach, c. automatyczne przełączanie ruchu na łącze zapasowe w chwili awarii łącza podstawowego d. nadanie i zapewnienie routingu do przestrzeni adresowej PI (Provider Independent) /28 e. zakończenie łączy stykiem Ethernet RJ-45 w lokalizacjach wskazanych przez Zamawiającego
3. Udostępnienie 1 pary ciemnych włókien pomiędzy lokalizacjami Młynarska43/45- Klimczaka 4 oraz zakończenie ich złączami RJ-45 o przepustowości minimum 250 Mb/s w każdej lokalizacji, do połączenia w klaster geograficzny 2 urządzeń Fortigate 300B, które są własnością Zamawiającego. WYMAGANIA DLA ŁĄCZY 1. Zamawiający wymaga, aby w ramach realizacji przedmiotu zamówienia, Wykonawca udostępnił w lokalizacjach Zamawiającego, łącza o następującej przepustowości gwarantowanej nie mniejszej niż poddane w tabeli LP Nazwa 1 2 Centrala Łącze podstawowe Zapasowe Centrum Danych łącze zapasowe Lokalizacja Warszawa, ul. Młynarska 43/45 Warszawa, ul. Klimczaka 4 Prędkość transmisji Łącza Podstawowe 150Mb/s Prędkość transmisji Łącza Zapasowe 100Mb/s 2. Nie dopuszcza się realizacji w oparciu o łącza radiowe, 3. Łącza internetowe mają być symetryczne 4. Od Wykonawcy jest wymagane, by był stroną umowy o Usługach Standardowych (Standard Service Agreement) zawartej z RIPE NCC i występował w niej jako LIR. Wykonawca będzie reprezentował Zamawiającego jako Użytkownika Końcowego przed RIPE NCC w celu przydzielenia dla Użytkownika Końcowego i utrzymania na jego rzecz przestrzeni adresowej IP. 5. Zamawiający wymaga, aby w przypadku awarii łącza podstawowego Wykonawca realizował przełączanie na łącze zapasowe we własnej infrastrukturze. 6. Wykonawca zbuduje klaster geograficzny zbudowany z dwóch urządzeń Fortigate FG300B (FW-1 i FW-2 będące własnością Zamawiającego), po jednym w każdym z dwóch ośrodków, pracujący w trybie active-standby i połączone dostarczonym przez Wykonawcę światłowodem. Przykładowe połączenia urządzeń przedstawia poniższy rysunek:
7. Przełączenie ruchu powinno być zrealizowane w sposób zapewniający możliwość komunikacji bez konieczności zmiany używanych w danym momencie adresów IP Zamawiającego. 8. Zamawiający wymaga zapewnienia usługi ochrony przed atakami DDoS realizowanej jako usługi powiązanej z łączami dostępu do Internetu dostarczanymi w ramach zamówienia dla całej udostępnionej przepustowości łączy. Usługa będzie świadczona dla całej adresacji IP Zamawiającego na dostarczanych łączach internetowych 9. W ramach realizacji usługi ochrony przed atakami DDoS, Zamawiający wymaga zapewnienia co najmniej: a. analizy ruchu w celu identyfikacji typu i natury ataku b. powiadamianie Zamawiającego o podejrzeniu wystąpienia ataku c. rozpoczęcie usuwania ataku w porozumieniu z Zamawiającym (możliwe jest automatyczne uruchamianie obrony dla alarmów o wysokim poziomie zagrożenia)
d. modyfikację zestawu użytych mechanizmów przeciwdziałania tak, by uzyskać maksymalny poziom filtracji ruchu niepożądanego przy minimalnym wpływie na ruch prawidłowy e. klasyfikację alarmów typu DDoS jako: 1) zweryfikowany atak 2) fałszywy alarm 3) nagły ruch wzrost ruchu spowodowany inną przyczyną niż atak. Wykrywanie zagrożeń Zamawiający wymaga zapewnienia efektywnej identyfikacji potencjalnych ataków DDoS z wykorzystaniem co najmniej poniższych mechanizmów detekcji: a) Sygnatury b) Missused detection - przekroczenie progów dla określonych typów pakietów i protokołów c) Profiled detection - oparte na analizie profilu ruchu Zamawiającego wykrywanie nieoczekiwanych zmian ruchu w odniesieniu do tego profilu. 1. Usługa monitoruje ruch do i od chronionej podsieci w czasie rzeczywistym 2. Usługa zapewnia wykrywanie anomalii polegających na przekroczeniu wartości uważanych za normalne w ruchu Internetowym w szczególności pakietów TCP SYN, TCP RST, TCP Null, ICMP, IP Null, IP Fragmented, DNS. 3. System realizujący usługę na podstawie danych historycznych wyznacza oczekiwaną wartość ruchu do i od chronionej podsieci o danej porze dnia w danym dniu tygodnia. 4. Usługa zapewnia wykrywanie anomalii polegających na znaczącym przekroczeniu wolumenu ruchu w stosunku do wcześniej wyznaczonych wartości oczekiwanych ruchu. Mitygacja Oczyszczanie ruchu Zamawiający wymaga zapewnienia usługi ochrony przed atakami DDoS polegającej na usuwaniu ataku przy możliwie jak najmniejszym wpływie na ruch uprawniony. Efektywne działanie powinno obejmować trzy procedury: Off-ramping - w przypadku podejrzenia wystąpienia ataku, ruch przekierowany zostanie do dedykowanych do tego celu zasobów wewnętrznych Wykonawcy filtrowanie - oparte o wielowarstwową analizę ruchu i mechanizmy przeciwdziałania On-ramping - kierowanie odfiltrowanego ruchu z powrotem do Klienta. 1. Usługa winna zapewnić ochronę przed atakami o wolumenie do 10Gb/sek i 7Mpps. 2. W trakcie migracji pakiety nie są przekierowane poza teren Polski.
3. Usługa winna zapewnić filtrowanie ruchu z błędnymi nagłówkami IP/TCP/UDP 4. Usługa winna zapewnić odrzucanie lub przepuszczanie na bazie zdefiniowanych filtrów operujących na informacjach nagłówka warstwy 3-ciej i 4-tej modelu OSI. 5. Usługa winna zapewnić filtrowanie ruchu na określonych portach UDP na podstawie zawartości pola danych w oparciu o wyrażenia regularne. 6. Usługa winna zapewnić filtrowanie ruchu na określonych portach TCP na podstawie zawartości pola danych w oparciu o wyrażenia regularne 7. Usługa winna chronić przed atakami ze spoofowanymi (udawanymi) adresami źródłowymi IP poprzez autentykację sesji TCP, zapytań DNS oraz zapytań HTTP. 8. Usługa winna zapewnić filtrowanie nieprawidłowych zapytań DNS 9. Usługa winna umożliwiać ograniczenia zapytań DNS do zadanej wartości zapytań/sek. 10. Usługa winna zapewnić do 5-ciu filtrów opartych o wyrażenia regularne definiujących zakres stosowania autentykacji DNS oraz ograniczania liczby zapytań DNS. 11. Usługa winna zapewnić filtrowanie nieprawidłowych zapytań HTTP. 12. Usługa winna zapewnić blokowanie ruchu od stacji końcowych przekraczających progi dla operacji HTTP na sekundę per serwer lub per URL. 13. Usługa winna zapewnić do 5-ciu filtrów opartych o wyrażenia regularne definiujących zakres stosowania autentykacji HTTP lub ograniczania liczby zapytań HTTP. 14. Usługa winna zapewnić filtrowanie ruchu w oparciu o wyrażenia regularne dotyczące nagłówków HTTP. 15. Usługa winna zapewnić ochronę przez atakami typu slow Lories, poprzez resetowanie połączeń, które pozostają nieaktywne przez zadany okres czasu. 16. Usługa winna zapewnić ochronę przez atakami typu slow Lories, poprzez resetowanie sesji TCP której aktywność jest poniżej zadanej liczby bajtów przesyłanej w zadanym okresie czasu. 17. Usługa winna zapewnić wykrywanie ruchu kierowanego z serwerów proxy i stosuje algorytmy filtrowania na podstawie oryginalnego źródła ruchu. 18. Usługa winna zapewnić wykrywanie i filtrowanie pakietów z nieprawidłowymi nagłówkami SSL/TLS lub nagłówkami SSL/TLS które są poza sekwencją. 19. Usługa winna zapewnić blokowane sesji jeżeli podczas negocjacji SSL/TLS klient zarząda nadmiernej ilości metod kryptograficznych lub rozszerzeń użytkownika. Próg dla tych wartości jest konfigurowalny.
20. Usługa winna zapewnić wykrywanie i rozłączanie sesji jeżeli negocjacja SSL/TLS nie zakończy się w zadanym czasie. 21. Usługa winna zapewnić blokowanie ruchu ze stacji dla których występuje nadmierna liczba nieprawidłowych, nadmiarowych lub niekompletnych sesji SSL. 22. Usługa winna zapewnić monitorowanie negocjacji SSL dla wszystkich portów na których mogą być stosowane aplikacje zabezpieczone protokołem TLS: HTTPS, SMTP, IMAP4, POP, LDAP, IRC, NNTP, TELNET, FTP i SIP. 23. Usługa winna chronić przed atakami pochodzącym od sieci botnetowych (komputerów zainfekowanych w sposób umożliwiające zdalne sterowanie przez hackerów) poprzez filtrowanie na podstawie na bieżąco aktualizowanych sygnatur zawierających listę adresów IP. 24. Usługa winna chronić przed atakami pochodzącymi z sieci botnetowych poprzez wykrywanie źródeł ataku o wolumenie przekraczającym zadane wartości. Wartości progowe są definiowalne zarówno dla całości ruchu jak i do części ruchu zdefiniowanego za pomocą filtru. 25. Usługa winna umożliwiać uruchamianie mitygacji w celu nauczenia się systemu wartości typowych ruchu, które następnie mogą być wykorzystywania do właściwego ustawiania progów dla algorytmów mitygacji. Poziom SLA dotyczący powiadomienia o ataku a. Czas Reakcji na Atak (CRA) Przez CRA rozumie się czas, jaki upłynie od wykrycia Ataku DDoS do rozpoczęcia skutecznego telefonicznego poinformowania Zamawiającego, przez ustalone kanały komunikacji Przez skuteczny kontakt z Zamawiającym rozumie się: rozmowę z Zamawiającym oraz jego poprawną autoryzację. Jeśli w tym czasie nie dojdzie do skutecznego kontaktu z Zamawiającym z przyczyn niezależnych od Wykonawcy, w szczególności Zamawiający nie odbierze telefonu Wykonawca nie zostanie obciążony karą umowną. Czas CRA liczony będzie od momentu zaraportowania na platformie ataku do czasu zarejestrowania w systemie teleinformatycznym Wykonawcy czasu dokonania pierwszej czynności mającej na celu poinformowanie Zamawiającego (czas wykonania rozmowy telefonicznej, wysłania SMS-a). CRA liczone będzie w następujący sposób: kontakt Wykonawcy z Zamawiającym czas mierzony jest od momentu wykrycia ataku przez system Wykonawcy do momentu próby wykonania pierwszego telefonicznego kontaktu z Zamawiającym (zgodnie z listą osób/numerów i priorytetami wskazanym przez Zamawiającego). Każda próba kontaktu będzie wykonywana przez Wykonawcę co dwie minuty w maksymalnym czasie łącznym CRA. Jeśli nie dojdzie do skutecznego kontaktu w pierwszej próbie Wykonawca zobowiązany będzie do wykonania następnej próby do kolejno wskazanych osób/numerów z listy kontaktów. W przypadku niemożności uzyskania połączenia z Zamawiającym w czasie CRA we wszystkich próbach kontaktu, Wykonawca wysyła SMS do grupy
adresowej z informacją o zanotowanym ataku. W przypadku ochrony na żądanie ochrona nie będzie włączona do momentu skutecznego kontaktu z Zamawiającym i potwierdzenia decyzji o włączeniu lub nie ochrony. Wartość parametru CRA dla określonych Poziomów SLA wynosi 15 minut b. Czas Reakcji na Zlecenie oczyszczania ruchu (CRZ) a) Przez CRZ rozumie się czas, jaki upłynie od przyjęcia Zlecenia od Zamawiającego z żądaniem włączenia lub wyłączenia oczyszczania po zarejestrowanym Ataku. b) Wartość parametru CRZ dla określonych Poziomów SLA wynosi 15 minut. Poziom SLA dotyczący parametrów usługi SLA Centrala/Zapasowe centrum Danych LP Parametr Wartość 1 Gwarantowany czas przywrócenia 2h dostępu do sieci Internet w Centrali/Zapasowym Centrum Danych w przypadku całkowitego braku dostępności. 2 Gwarantowany czas naprawy awarii 8h pojedynczego łącza w Centrali/ Zapasowym Centrum Danych 3 Gwarantowane pasmo dla Centrali 150 Mb/s 4 Gwarantowane pasmo dla Zapasowego Ośrodka Danych 100 Mb/s 5 Gotowość serwisowa 24 godziny na dobę przez 7 dni w tygodniu 6 Miesięczne okno serwisowe <2h Raporty miesięczne Zamawiający wymaga sporządzania po każdym zakończonym miesiącu świadczenia usługi indywidualnego raportu zawierającego co najmniej następujące statystyki: poziom ruchu wchodzącego i wychodzącego maksymalne poziomy ruchu lista zarejestrowanych ataków lista usuniętych ataków.
Raport z incydentu Zamawiający wymaga każdorazowo po zakończeniu operacji oczyszczania ruchu po zaistniałym ataku sporządzenia raportu z incydentu. Sposób inicjowania oraz zakończenia procedury zostanie uzgodniony z Zamawiającym. Informacja w raporcie o incydencie musi zawierać co najmniej następujące statystyki: rozmiar ataku, liczniki pakietów, Gb/s oraz procent całości ruchu czas trwania ataku główne źródła ataku typ i natura ataku wdrożone metody eliminacji ataku geograficzna lokalizacja źródeł ataku wielkość oczyszczonego ruchu czasy w szczególności: początek ataku, powiadomienie, wdrożenie procedur obronnych, zakończenie ataku, przywrócenie normalnej pracy sieci. Obszar działania usługi Zamawiający wymaga aby ruch w sieci Zamawiającego przekierowany do oczyszczania był wysyłany wyłącznie na obszar znajdujący się pod bezpośrednim nadzorem służb technicznych Wykonawcy na terenie Polski. Czas świadczenia usługi Zamawiający wymaga świadczenia usługi ochrony przed DDoS w trybie 24/7/365. Procedura przerwania mitygacji Fall-back Procedure Jeśli uruchomiona procedura eliminacji DDoS będzie miała negatywny wpływ na chronione zasoby lub usługi, Zamawiający będzie miał możliwość zlecenia jej przerwania, co nastąpi w ciągu 15 minut. Pomimo przerwania akcji, ruch Klienta będzie cały czas podlegał monitorowaniu i istnieje możliwość przywrócenia procedur obronnych w odpowiednio dostosowanym zakresie i analogicznym czasie wdrożenia. Wymaga się, aby łącze zapasowe uruchomione zostało w jednym czasie, wraz z łączem podstawowym. Implementacja usługi 1. Projekt wykonawczy Po podpisaniu umowy na świadczenie usługi, przy współpracy z Zamawiającym, Wykonawca utworzy Projekt wykonawczy. Dokument zawierać będzie m. in.: a) opis techniczny integracji usługi z siecią Zamawiającego b) opis procedur powiadamiania i eskalacji c) testy akceptacyjne
d) opis procedur obsługi zgłoszeń i raportowania. 2. Implementacja Implementacja obejmuje rekonfigurację urządzeń Zamawiającego oraz Wykonawcy pod kątem monitorowania ruchu oraz uruchomienia usługi przeciwdziałania atakom DDoS. 3. Testy akceptacyjne Po zakończeniu Implementacji Zamawiający wraz z Wykonawcą przeprowadzą Testy akceptacyjne zgodnie z uzgodnionym Projektem wykonawczym i stanowiące test funkcjonalny platformy ochrony przeciwko atakom DDoS. Testy uwzględnią pełną weryfikację poprawności wdrożonej konfiguracji. Przed wdrożeniem usługi Zamawiający wymaga przeprowadzenia Procesu analizy ruchu Abonenta (Learning Mitigation) - proces w którym ruch zdefiniowany w ramach danego obiektu kierowany jest do platformy ochrony przed atakami DDoS Wykonawcy. Ruch podczas learning mitigation nie podlega żadnym filtracjom i w sposób niezmieniony kierowany jest do sieci użytkownika. Platforma podczas learning mitigation zbiera statystyki, na których podstawie jest w stanie określić parametry tzw. countremeasures (algorytmów). Inne uwarunkowania Zamawiający zastrzega sobie prawo, bez uprzedzenia Wykonawcy, do wykonania w okresie raz na 90 dni trwania umowy wykonania testów sprawdzających jakość i poprawność świadczenia usługi.