SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

1 Załącznik nr 1 do SIWZ.../09 SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I. Zamawiający oczekuje, Ŝe: 1. wykonawca posiada status certyfikowanego partnera producenta sprzętu i oprogramowania, 2. dostarczany sprzęt będzie fabrycznie nowym, nie uŝywanym wcześniej w innych projektach, wyprodukowany nie wcześniej niŝ pół roku przed datą dostawy, 3. dostarczony sprzęt będzie posiadał świadczenia gwarancyjne oparte na oficjalnej gwarancji świadczonej przez producenta sprzętu i posiadającym stosowny pakiet usług gwarancyjnych kierowanych równieŝ do uŝytkowników z obszaru Rzeczpospolitej Polskiej, 4. wraz z dostawą sprzętu naleŝy dostarczyć dokument wydany przez producenta, poświadczający datę produkcji sprzętu II. Na dostarczany sprzęt ma być udzielona gwarancja i rękojmia: 1) Gwarancja dla urządzeń: a) okres: 12 m-cy pełnej gwarancji producenta, b) miejsce realizacji: w siedzibie Zamawiającego, c) przyjmowanie zgłoszeń serwisowych przez centrum pomocy technicznej Producenta/Wykonawcy w trybie 24/7, d) wymiana uszkodzonego sprzętu na sprawny do końca następnego dnia roboczego, e) wsparcie techniczne świadczone telefonicznie i pocztą elektroniczną przez producenta oraz polskiego dystrybutora, f) w okresie wsparcia technicznego dostęp do nowych wersji oprogramowania, a takŝe dostęp do baz wiedzy, przewodników konfiguracyjnych i narzędzi diagnostycznych. 2) W przypadku stwierdzenia róŝnic funkcjonalnych pomiędzy zaakceptowaną koncepcją a faktyczną realizacją przedmiotu umowy, Zamawiający ma prawo zarządzać wykonania odpowiednich poprawek w konfiguracji systemu. Poprawki będą wykonane w ustalonym z Zamawiającym terminie, nie dłuŝszym jednak niŝ 10 dni od chwili przekazania zgłoszenia. Z tytułu wykonania poprawek Wykonawcy nie przysługuje dodatkowe wynagrodzenie. III. Wykaz sprzętu, oprogramowania i usług: 1. WdroŜenie: WdroŜenie będzie polegało na: 1) Przygotowaniu wstępnej koncepcji wdroŝenia dla kaŝdego z systemów przy uwzględnieniu specyfiki sieci i wymagań Zamawiającego. Koncepcja musi zawierać co najmniej elementy takie jak: a) dla bramki SSL-VPN: dostęp z sieci publicznej do serwerów RDP, NX znajdujących się w obszarze chronionym przygotowanie konfiguracja dla 3 serwerów, dostęp z sieci publicznej do serwerów WWW znajdujących się w obszarze chronionym przygotowanie konfiguracja dla 1 serwera,, autentykacja uŝytkowników z wykorzystaniem usługi katalogowej z uwzględnieniem działającej obecnie infrastruktury zamawiającego (2 domeny), w tym ewentualne propozycje modernizacji istniejącego rozwiązania, b) dla system zarządzania bezpieczeństwem sieci lokalnej SIEM i NBAD: 111_zal 1 1/5

2 analiza struktury sieci Zamawiającego celem wytypowania obszarów newralgicznych, które w pierwszej kolejności naleŝy podłączyć do systemu zarządzającego, analiza konfiguracji pracujących w wytypowanym obszarze urządzeń, przygotowanie koniecznych zmian konfiguracji istniejących urządzeń i ewentualnej rekonfiguracji połączeń sieciowych, szczegółowe załoŝenia do konfiguracji systemu zarządzania z analizą spodziewanych efektów. 2) Uzyskaniu akceptacji komórki właściwej ds. informatyki Zamawiającego dla przygotowanych koncepcji. 3) Dostawie urządzeń, oprogramowania, licencji i dokumentacji. 4) Konfiguracji wszystkich elementów systemów, w tym niezbędna rekonfiguracja elementów infrastruktury sieciowej posiadanej przez Zamawiającego, które zostaną włączone do systemu. 5) Przygotowaniu dokumentacji powykonawczej obejmującej aktualną konfigurację, metody obsługi w zakresie analizy zdarzeń w analizowanych obszarach sieci oraz archiwizacji i odtwarzania konfiguracji. 6) Szkoleniu administratorów Zamawiającego (3 osób) zakończone wystawieniem certyfikatu w ilości: a) minimum 1 dzień (8h) dla bramki SSL-VPN, b) minimum 2 dni (16h) dla systemu zarządzania bezpieczeństwem sieci lokalnej. 2. Bramka SSL-VPN: - 1 szt. 1) Urządzenie musi być oparte o dedykowaną platformę sprzętową oraz zapewniać obsługę co najmniej 50 jednoczesnych sesji SSL VPN z moŝliwością rozbudowy do 1000 jednoczesnych sesji. 2) Urządzenie musi oferować zróŝnicowane metody dostępu do zasobów: a) dostęp podstawowy (min. aplikacje Web; standardowe protokoły pocztowe IMAP, POP3,SMTP; współdzielenie plików NETBIOS, NFS; usługi terminalowe telnet, SSH), b) dostęp do aplikacji klient-serwer (enkapsulacja dowolnej aplikacji TCP w protokół HTTPS) bez konieczności zastosowania dodatkowych licencji, c) pełen dostęp sieciowy bez konieczności zastosowania dodatkowych licencji - praca w trybie wysokiej dostępności (SSL) oraz wysokiej wydajności (ESP wraz z kompresją treści). MoŜliwość automatycznego przełączania z trybu wysokiej wydajności do trybu wysokiej dostępności. 3) Rozwiązanie musi umoŝliwiać autentykację uŝytkowników w oparciu o: a) serwery RADIUS, b) usługi katalogowe LDAP, Microsoft Active Directory, Novell NDS/eDirectory, c) lokalna baza danych uŝytkowników, d) system RSA SecurID, e) certyfikaty X.509, f) serwery NIS 4) Urządzenie musi umoŝliwiać uwierzytelnienie dwuskładnikowe (hasło statyczne plus certyfikat, hasło dynamiczne plus certyfikat). Musi istnieć moŝliwość rozdzielenia serwera autentykacji uŝytkowników od serwera autoryzacji dostępu do zasobów. 5) Urządzenie musi umoŝliwiać obsługę CRL poprzez http. 111_zal 1 2/5

3 6) Urządzenie musi umoŝliwiać dynamiczne przyznawanie praw dostępu do zasobów w zaleŝności od: spełnienia określonych warunków przez uŝytkownika zdalnego, węzeł zdalny, parametry sieci oraz parametry czasowe. 7) Urządzenie musi umoŝliwiać szczegółową weryfikację stanu bezpieczeństwa węzła zdalnego. Musi istnieć moŝliwość: a) sprawdzenia obecności konkretnego procesu, pliku, wpisu w rejestrze Windows b) sprawdzenia czy włączono odpowiednie usługi zabezpieczeń zarówno w momencie logowania jak w trakcie trwania sesji, c) sprawdzenia czy wszystkie pobierane pliki pośrednie i pliki tymczasowe instalowane w czasie logowania są usuwane w momencie wylogowania, d) sprawdzenia przed zalogowaniem takich atrybutów jak adres IP, typ przeglądarki, certyfikaty cyfrowe, e) integracji z systemami weryfikacji stanu bezpieczeństwa firm trzecich, 8) Urządzenie musi umoŝliwiać budowanie konfiguracji odpornych na awarię w trybie Aktywny/Aktywny oraz Aktywny/Pasywny. Musi istnieć moŝliwość tworzenia konfiguracji nadmiarowej, w której węzły klastra zlokalizowane są w LAN bądź w odległych graficznie sieciach i komunikują się poprzez sieć WAN. 9) System musi umoŝliwiać spójne zarządzanie z jednej konsoli administracyjnej wieloma urządzeniami w przypadku budowania konfiguracji nadmiarowych. 10) Urządzenie musi umoŝliwiać instalację dodatkowego sprzętowego modułu akceleracji SSL. 11) Urządzenie musi być zarządzane poprzez przeglądarkę Web 12) Urządzenie musi umoŝliwiać wykonywanie lokalnych kopii zapasowych konfiguracji lub na zewnętrznym serwerze FTP oraz SCP. 13) Urządzenie musi umoŝliwiać integrację z zewnętrznymi serwerami SNMP v.2 oraz SYSLOG 14) Urządzenie musi przechowywać dwie wersje oprogramowania oraz umoŝliwiać reset do wersji fabrycznej. 15) Urządzenie musi zapewniać moŝliwość współpracy z rozwiązaniem klasy NAC tego samego producenta w zakresie jednokrotnego uwierzytelnienia uŝytkowników, tj. status uwierzytelnienia uŝytkownika na urządzeniu dostępowym SSL jest automatycznie i w sposób przezroczysty dla uŝytkownika przekazywany do urządzenia kontrolującego infrastrukturę NAC. 3. System zarządzania bezpieczeństwem sieci lokalnej SIEM i NBAD: - 1 szt. 1) System zarządzania bezpieczeństwem musi utrzymywać centralne repozytorium logów pobieranych z innych urządzeń i systemów oraz realizować funkcje Security Information and Event Management (SIEM) i Network Behavior Anomalny Detection (NBAD). 2) Moduł SIEM musi pobierać logi z wielu róŝnych elementów systemu informatycznego, poddawać je korelacji i na tej podstawie przedstawiać administratorom wiarygodne informacje na temat stanu bezpieczeństwa i wykrytych incydentów. 3) Moduł NBAD na podstawie statystyk i opisu ruchu (NetFlow, itp.) pobieranych bezpośrednio z urządzeń sieciowych (ruterów, przełączników) musi dokonywać analizy stanu i efektywności pracy sieci, w tym wykrywania sytuacji nieprawidłowych (anomalii). 4) Moduł NBAD musi dokonywać wykrywania anomalii w systemie informatycznym za pomocą analizy behawioralnej. W tym celu muszą być na bieŝąco budowane profile normalnego stanu i zachowania sieci oraz identyfikowane odchylenia (m.in. zmiany stanu, nagłe zwiększenia lub zmniejszenia natęŝenia ruchu i przekroczenie wartości progowych). 111_zal 1 3/5

4 5) Moduł NBAD musi posiadać moŝliwość wykrywania nowych obiektów w systemie informatycznym (hostów, aplikacji, protokołów, itd.). Moduł NBAD musi takŝe posiadać moŝliwość wykrywania awarii systemów, m.in. zablokowanych lub uszkodzonych serwerów i aplikacji. 6) System zarządzania musi być dostarczony jest jako jedno, gotowe do uŝycia urządzenia Appliance. Nie jest dopuszczalne oprogramowanie instalowane na sprzęcie ogólnego przeznaczenia. 7) Urządzenie Appliance musi posiadać minimum 8 GB pamięci RAM oraz 6 dysków o pojemności co najmniej 250 GB funkcjonujące w konfiguracji RAID 5. 8) Urządzenie Appliance musi posiadać wydajność co najmniej 1250 zdarzeń na sekundę oraz strumieni (Flows) na minutę. 9) Urządzenie Appliance musi działać na bazie dostrojonego przez producenta systemu operacyjnego klasy Linux. Nie jest dopuszczalne zastosowanie do tego celu systemu operacyjnego Microsoft Windows. 10) Urządzenie Appliance musi umoŝliwiać integrację z zewnętrznymi repozytoriami danych, co najmniej iscsi SAN i NAS. 11) Wszystkie funkcje systemu (SIEM, NBAD) muszą być dostępne są w ramach jednego urządzenia Appliance. 12) Moduły SIEM i NBAD muszą być zintegrowane ze sobą tak, aby informacje o naruszeniach bezpieczeństwa były przedstawiane na podstawie analiz obu tych modułów. 13) Obsługa incydentów bezpieczeństwa musi odbywać się na podstawie wielu źródeł informacji, nie mniej niŝ: a) zdarzenia i logi z systemów zabezpieczeń (firewall, VPN, IPS, AV, itd.), systemów operacyjnych (Unix, Microsoft Windows, itd.) oraz aplikacji i baz danych, b) statystyki i opis ruchu sieciowego odbierane z urządzeń za pomocą NetFlow, J-Flow, S-Flow i Packeteer oraz odczytywane bezpośrednio z sieci (span port), c) informacje na temat stanu systemów i ich słabości bezpieczeństwa odczytywane za pomocą Juniper IDP Profiler oraz skanerów Nessus, NMAP, ncircle i Qualys. 14) System zarządzania musi umoŝliwiać pobieranie logów z innych systemów za pomocą wielu metod, nie mniej niŝ Syslog (standardowy format logów, protokoły TCP i UDP), SNMP (wiadomości o zdarzeniach przesyłane poprzez SNMP Trap), a takŝe Security Device Event Exchange (SDEE) i Java Database Connectivity API (JDBC). 15) System zarządzania musi umoŝliwiać odczytywanie logów z systemów operacyjnych Microsoft Windows i Unix, nie mniej niŝ Redhat Linux, IBM AIX i SUN Solaris. 16) System zarządzania w zakresie odczytu logów musi umoŝliwiać integrację z innymi systemami zarządzania zabezpieczeń, nie mniej niŝ Juniper Security Manager, IBM ISS SiteProtector i Check Point SmartCenter. 17) Administratorzy bezpieczeństwa muszą mieć do dyspozycji dedykowane, graficzne narzędzia, uruchamiane z wykorzystaniem standardowej przeglądarki Web. Nie jest dopuszczalne instalowanie do tego celu dodatkowych aplikacji. 18) System zarządzania musi posiadać moŝliwość powiadamiania administratorów o zdarzeniach za pomocą co najmniej , SNMP oraz Syslog. System zarządzania musi posiadać moŝliwość nawiązania połączenia z urządzeniami zabezpieczeń sieci w celu zablokowania niedozwolonej komunikacji. 19) System zarządzania musi umoŝliwiać przypisywanie zidentyfikowanych incydentów bezpieczeństwa do obsługi określonym administratorom. 20) System zarządzania musi umoŝliwiać wdroŝenie w architekturze scentralizowanej (wszystkie funkcje na jednym Appliance) oraz rozproszonej, złoŝonej z wielu urządzeń. Struktura rozproszona budowana jest w celu zwiększenia wydajności systemu. W przypadku rozproszonej struktury zarządzanie całości systemu musi odbywać się z jednej 111_zal 1 4/5

5 konsoli. W przypadku rozproszonej struktury musi być moŝliwość kryptograficznej ochrony (szyfrowanie) komunikacji sieciowej pomiędzy komponentami systemu. 21) System zarządzania musi umoŝliwiać definiowanie precyzyjnych uprawnień administratorów w zakresie monitorowanego obszaru systemu informatycznego oraz dostępnych operacji w systemie zarządzania. ToŜsamość administratorów musi być weryfikowana poprzez lokalne konto oraz zewnętrzne systemy uwierzytelniania - co najmniej RADIUS, LDAP i Active Directory. 22) System zarządzania do celów obsługi zdarzeń musi utrzymywać centralne repozytorium logów z moŝliwością ich przeglądania w formie rzeczywistej (raw) oraz znormalizowanej. Dla logów system musi utrzymywać wskaźniki czasu (time stamp). Starsze logi muszą być poddawane kompresji. 23) System zarządzania musi składować informacje w bazie danych zaprojektowanej do tego celu przez producenta. Nie jest dopuszczalne uŝycie do tego celu bazy danych ogólnego przeznaczania. 24) Składowane w systemie zarządzania informacje muszą być zabezpieczone kryptograficznie za pomocą sum kontrolnych - dostępne są minimum funkcje MD2, MD5, SHA-1 oraz SHA-2 (NIST FIPS 180-2). 25) System zarządzania musi mieć moŝliwość wykonywania operacji backup i restore, uruchamianych z graficznej konsoli. System zarządzania musi mieć moŝliwość wykonywania archiwizacji informacji do zewnętrznych repozytoriów danych nie mniej niŝ iscsi SAN i NAS. 26) System zarządzania musi posiadać moŝliwość tworzenia wielu typów raportów generowanych zgodnie z kryteriami ustalonymi przez administratorów oraz na podstawie predefiniowanych wzorców (raportów). Raporty muszą być tworzone w wielu formatach - minimum PDF, HTML, CSV, RTF i XML. 27) System zarządzania musi posiadać co najmniej 200 predefiniowanych raportów. W celu sprawnego przeszukiwania predefiniowanych raportów muszą być one pogrupowane - co najmniej według typu urządzeń i zdarzeń bezpieczeństwa. W systemie muszą być dostępne predefiniowane raporty na zgodność ze standardami bezpieczeństwa - minimum dla PCI i SOX. 28) System zarządzania musi utrzymywać szczegółowy log audytowy rejestrujący co najmniej następujące operacje administratorów - login/logoff i zmiany konfiguracji systemu. 29) System zarządzania musi posiadać moŝliwości weryfikacji poprawności swojego działania i powiadamiania administratorów o nieprawidłowościach - co najmniej za pomocą wpisu do logów systemowych oraz SNMP Trap. 111_zal 1 5/5