Załącznik nr 1 do SIWZ Opis przedmiotu zamówienia (zwany dalej OPZ ) 1 Przedmiotem zamówienia jest wdrożenie rozwiązania do zarządzania podatnościami Vulnerability Management - VM (zwanego dalej Rozwiązaniem lub Systemem ) realizowanego poprzez dostawę niezbędnych licencji, oprogramowania, pakietów suportowych oraz świadczenie serwisu dla wdrożonego Rozwiązania. W szczególności przedmiot zamówienia obejmuje: 1.1 Dostawę Rozwiązania wraz z licencjami oraz aktualizacjami, w tym: 1.1.1 Dożywotniej licencji Rozwiązania w formie SOFTWARE APPLIANCE, do zarządzania podatnościami min. 5000 systemów/aplikacji/baz danych (5000 adresów IP). 1.1.2 Najnowszej dostępnej wersji Oprogramowania oferowanego Rozwiązania. 1.1.3 Niezbędnych pakietów suportowych producenta Rozwiązania na okres 12 miesięcy od daty podpisania protokołu odbioru końcowego. 1.2 Zaprojektowanie i wdrożenie Rozwiązania, w tym: 1.2.1 Przeprowadzenie analizy technicznej oraz opracowanie projektu technicznego wdrożenia Rozwiązania. 1.2.2 Instalację, konfigurację oraz uruchomienie Rozwiązania zgodnie z projektem technicznym wdrożenia Rozwiązania. 1.2.3 Przeprowadzenie warsztatowego przekazania wiedzy dla użytkowników wdrożonego Rozwiązania. 1.2.4 Wykonanie dokumentacji powdrożeniowej, dostarczonej i opracowanej przez Wykonawcę. 1.3 Świadczenie serwisu i wsparcia technicznego dla wdrożonego Rozwiązania w okresie 12 miesięcy od daty podpisania Protokołu odbioru końcowego. 1
2 Specyfikacja Rozwiązania 2.1 Architektura Rozwiązania 2.1.1 Zarządzanie przy pomocy przeglądarki. 2.1.2 Architektura Klient (silniki skanujące) / Serwer zarządzania (magazyn danych, serwer raportowania). 2.1.3 Skanowanie może być wykonywane z poziomu serwera oraz dowolnego silnika skanującego. 2.1.4 Wspierane systemy operacyjne: Windows 7, 8, 10. Microsoft Windows Server 2008/2008 R2. Microsoft Windows Server 2012/2012 R2. Microsoft Windows Server 2016. Red Hat Enterprise Linux 6.x, 7.x. Maszyny wirtualne na VMware ESXi 5.x, VMware ESXi 6.x VMware vcenter Server 5.x, 6.x Maszyny wirtualne na Hyper-V 2012/2012R2/2016. 2.1.5 Serwer zarządzania powinien dawać możliwość: Przechowywania wszystkich danych pochodzących z dowolnego silnika skanującego. Opierać się na bazie danych PostgreSQL lub MySQL. Baza danych nie powinna wymagać żadnych działań konfiguracyjnych ze strony administratora. Wszystkie dane zebrane przez zewnętrzne silniki skanujące powinny być niezwłocznie przesyłane do centralnej bazy i nie powinny być nigdy przechowywane po stronie silników skanujących. 2.1.6 Rozwiązanie (zarówno silnik jak i konsola) powinno dawać możliwość wdrożenia, jako: Aplikacja. Urządzenie. Maszyna wirtualna. Wszystkie wyżej wymienione sposoby wdrożenia powinny mieć możliwość jednoczesnego uruchomienia w całym środowisku. 2.1.7 Zwiększenie wydajności aplikacji powinno być możliwe dzięki rozbudowaniu platformy sprzętowej poprzez: 2
Zmianę procesora. Zwiększenie pamięci RAM. Zwiększenie pojemności pamięci masowej. 2.2 Administracja 2.2.1 Przekazywanie danych z silników skanujących do serwera zarządzania powinno odbywać się bezpiecznym kanałem szyfrowanym. 2.2.2 Serwer zarządzania powinien udostępniać możliwość logowania wielu użytkownikom o różnych poziomach dostępu. 2.2.3 Różne poziomy dostępu dla użytkowników Rozwiązania powinny dawać możliwość definiowania: Widoczności poszczególnych grup kontrolowanych przez skaner hostów. Zmiany zakresu uprawnień do modyfikacji widocznych dla użytkownika hostów. Poziomów dostępu do raportów. Możliwości tworzenia raportów. Obsługi wbudowanego systemu ticketowania 2.2.4 Narzędzie powinno umożliwić ograniczenie możliwości skanowania do określonych site ów/systemów dla danych użytkowników. 2.2.5 Możliwość wprowadzenia jak największej automatyzacji procesów, powinna obejmować, co najmniej: Skanowanie o zaplanowanym według ustalonego harmonogramu. Powiadamianie i alarmowanie administratora o zdefiniowanych zdarzeniach (SNMP, SYSLOG, SMTP). Funkcjonalność raportowania powinna mieć możliwość rozszerzenia przy pomocy API producenta Rozwiązania. 2.3 Wykrywanie podatności 2.3.1 Skanowanie podatności powinno odbywać się na dwa sposoby: Skanowanie uwierzytelnione. Skanowanie bez uwierzytelnienia. 2.3.2 Wszystkie testy, które mogą wpłynąć na stabilność działania sprawdzanego hosta, powinny być oznaczone w jasny sposób dla administratora. 2.3.3 Skanowanie uwierzytelnione powinno odbywać się, co najmniej przy użyciu: Concurrent Versioning System (CVS). 3
File Transfer Protocol (FTP). Microsoft SQL Server. Sybase SQL Server. Microsoft Windows/Samba (SMB/CIFS). Microsoft Windows/Samba LM/NTLM Hash (SMB/CIFS). MySQL Server. Oracle. PostgreSQL. Remote Execution. Simple Network Management Protocol (SNMP). Secure Shell (SSH). Secure Shell (SSH) Public Key. Telnet. Web Site Form Authentication. Web Site HTTP Authentication. Web Site Session Authentication. 2.3.4 System powinien wykrywać obecność komunikacji ipv6 nawet podczas skanowania przy pomocy ipv4. 2.3.5 Wykryte podatności powinny w formie pozwalającej na szybkie odniesienie do otwartych baz podatności, takich jak: NVD, Bugtraq, CERT, SANS. 2.3.6 Używane podczas skanowania podatności testy powinny być zależne od przeprowadzonego wcześniej przez silnik skanowania rozpoznania. Takie rozpoznanie powinno zapewnić inteligentne skanowanie testami podatności dopasowanymi do wykrytego wcześniej systemu operacyjnego oraz aplikacji. 2.3.7 Możliwość śledzenia zmian ryzyka związanego z konkretnym hostem. Powiązanie ryzyka z hostem powinno odbywać się, co najmniej na podstawie: Adresu IP. Adresu MAC. Nazwy hosta (hostname). 2.3.8 Silnik skanujący powinien dostosowywać się do zaistniałej sytuacji i automatycznie wykorzystywać wykryte podatności, na przykład po wykryciu standardowych danych logowania do rutera, powinny one zostać automatycznie wykorzystane do dalszych testów. 4
2.4 Kontrola aplikacji 2.4.1 Kontrola aplikacji powinna być standardową częścią Rozwiązania. 2.4.2 Skanowanie powinno zawierać testy sprawdzające OWASP Top 10. 2.4.3 Jeśli aplikacja daje dostęp do systemów back endowych, skaner powinien wykorzystać te informacje do dalszego skanowania. 2.5 Kontrola baz danych 2.5.1 Kontrola baz danych powinna być standardową częścią Rozwiązania. 2.5.2 Wspierane bazy danych to, co najmniej: Informix, MSSQL, Oracle, Sybase, DB2, PostgreSQL, MySQL. 2.6 Kontrola polityk bezpieczeństwa (zalecenia konfiguracyjne) 2.6.1 Predefiniowane ustawienia skanowania dla określonych systemów. 2.6.2 Skaner konfiguracji powinien być standardową częścią systemu. 2.6.3 Powinien zawierać ponad 150 zestawów kontrolnych konfiguracji systemów. 2.6.4 Kontrola konfiguracji powinna się odbywać wg zaleceń: USGCB, FDCC, DISA STIG, CIS. 2.7 Raportowanie 2.7.1 Raportowanie musi być niezależne od wykonującego skanowanie silnika (raporty muszą umożliwiać konsolidację wszystkich wyników). 2.7.2 Raporty powinny mieć możliwość generowania przy użyciu: Przygotowanych przez producenta wzorców. Modyfikowanych przez użytkownika standardowych wzorców. Dodatkowych wzorców raportów pobranych ze stron producenta. 2.7.3 Użytkownik powinien mieć możliwość wykonania dowolnego zapytania SQL do bazy danych serwera zarządzania. Wynik takiego zapytania powinien być prezentowany, jako raport w formacie CSV. 2.7.4 Raporty powinny mieć możliwość automatycznego generowania według harmonogramu. 2.7.5 Moduł raportujący powinien mieć możliwość automatycznego przesyłania raportów do dedykowanych użytkowników. 2.7.6 Raporty powinno dać się generować do następujących formatów (formaty wyjściowe mogą się różnić w zależności od typu raportu): PDF, HTML, RTF, XML, CSV. 2.8 Zarządzanie bezpieczeństwem 2.8.1 Ocena ryzyka powinna być możliwa w oparciu o: 5
CVSS. Dedykowany, dynamiczny Risk Score. 2.8.2 Użytkownik może wpływać na dedykowany Risk Score poprzez wprowadzenie rankingu ważności skanowanych hostów. 2.8.3 System musi generować dane/raport, pozwalający na przyjęcie strategii podnoszenia bezpieczeństwa firmy. Taki raport powinien zawierać: Sekwencję kroków do podjęcia przez administratorów. Szacowany czas potrzebny do wykonania operacji. Instrukcje wykonania operacji. Ew. linki do pobrania aktualizacji. 2.8.4 System musi dawać możliwość dodawania wyjątków z listy podatności. 2.9 Integracja 2.9.1 Rozwiązanie powinno się integrować, z co najmniej wymienionymi poniżej zewnętrznymi dostawcami rozwiązań bezpieczeństwa: Imperva. VMware Splunk 2.9.2 Możliwość integracji z VMware, poprzez wbudowany konektor, dająca możliwość: Automatycznej aktualizacja danych o wirtualnych maszynach. Skanowanie bezpośrednio przez Hypervisora Vmware. 2.9.3 Możliwości skryptowania / API Skaner powinien udostępniać dwukierunkowy interfejs API, oparty na XML. Powinny być dostępne publicznie biblioteki ułatwiające oprogramowanie interfejsu API. 3 Wymagania odnośnie harmonogramu realizacji wdrożenia Rozwiązania. Wykonawca zobowiązany jest przedstawić harmonogram realizacji wdrożenia Rozwiązania uwzględniający: 3.1 Wykonanie analizy technicznej i przygotowanie projektu technicznego wdrożenia. 3.2 Prace implementacyjno-wdrożeniowe: 3.2.1 Przygotowanie propozycji konfiguracji. 3.2.2 Instalacja i konfiguracja Rozwiązania. 3.2.3 Konfiguracja i integracja z Active Directory, serwerem DHCP, VMware vcenter. 6
3.2.4 Zdefiniowanie użytkowników systemu. 3.2.5 Przygotowanie min. pięciu skanów podatności oraz uruchomienie ich. 3.2.6 Przygotowanie przykładowych raportów. 3.2.7 Implementacja zaprojektowanych polityk, raportów i skanów. 3.2.8 Przeprowadzenie strojenia samego systemu oraz doboru odpowiednich parametrów celem otrzymania najwydajniejszej i najbardziej bezpiecznej konfiguracji systemu. 3.2.9 Przeprowadzenie prac optymalizacji systemu pod kątem minimalizacji liczby fałszywych alertów. 3.3 Przeprowadzenie warsztatowego przekazania wiedzy z użytkowania i administracji wdrożonego Rozwiązania dla 2 osób. Warsztaty powinny trwać minimum 5 dni, powinny być prowadzone przez certyfikowanego z oferowanej technologii inżyniera i obejmować następujący zakres tematyczny: 3.3.1 Administracja Rozwiązania; 3.3.2 Instalacja i konfiguracja; 3.3.3 Definiowanie nowych polityk skanowania; 3.3.4 Budowa raportów; 3.4 Zamawiający wymaga przeprowadzenia warsztatów wdrożeniowych w siedzibie Wykonawcy. Koszty ewentualnego zakwaterowania i przejazdu pokrywa Wykonawca. Osoba prowadząca warsztaty musi posiadać następujące kwalifikacje: 3.4.1 Certyfikat z oferowanego Rozwiązania. 3.4.2 Certyfikat CISA lub CISSP lub inny równoważny. 3.4.3 Doświadczenie we wdrażaniu Rozwiązań klasy Vulnerability Manager. 3.4.4 Biegłe posługiwanie się językiem polskim. 3.5 Wykonanie dokumentacji powdrożeniowej. 4 Zakres wsparcia technicznego i serwisu Rozwiązania oraz zakupu pakietów suportowych: 4.1 Pakiety suportowe oferta powinna zawierać oprócz kosztów zakupu samego Rozwiązania, koszty zakupu pakietów suportowych na okres minimum 12 miesięcy. Zakres suportu producenta: 4.1.1 Dostęp do pomocy technicznej producenta Rozwiązania. 4.1.2 Dostęp do poprawek i nowych wersji wdrożonego Rozwiązania. 4.1.3 Dostęp do dokumentacji technicznej wdrożonego Rozwiązania. 4.1.4 Dostęp dla BGK do konta suportowego producenta Rozwiązania, zawierającego dostęp do bazy wiedzy. 7
4.2 Zakres wsparcia technicznego i serwisu: 4.2.1 Zapewnienie Hot-Line, dostępnego dla upoważnionych pracowników Zamawiającego, w dni robocze od 8: 00 do 16: 00 z wyjątkiem dni świątecznych i ustawowo wolnych od pracy, spełniającego poniższe wymagania: Hot-Line musi obejmować następujące kanały zgłoszeń: serwis WWW, poczta elektroniczna, telefon. W ramach Hot-Line zapewnienie kanału WWW do śledzenia i aktualizacji zarejestrowanych zgłoszeń. W ramach Hot-Line zapewnienie możliwości automatycznego powiadamiania o zbliżającym się czasie przeznaczonym na naprawę lub przekroczeniu SLA; W ramach Hot-Line zapewnienie automatycznego powiadamiania o zbliżającym się końcu suportu lub wygaśnięciu umowy; 4.2.2 Usuwanie usterek i błędów z zachowaniem poniższych zasad: Usunięcie błędu krytycznego lub wykonanie obejścia błędu krytycznego (umożliwiającego korzystanie z systemu) nastąpi w czasie 24h od przyjęcia zgłoszenia. Jeżeli jednak bezpośrednią przyczyną powstania błędu krytycznego systemu jest wada w oprogramowaniu, usunięcie błędu krytycznego nastąpi poprzez współpracę Wykonawcy z Producentem w terminie możliwie najszybszym z punktu widzenia Producenta, nie dłuższym niż 10 Dni roboczych od przyjęcia zgłoszenia. Usunięcie innych błędów nastąpi w ciągu 5 dni roboczych od przyjęcia zgłoszenia. Usunięcie usterek nastąpi w ciągu 10 dni roboczych od przyjęcia zgłoszenia. W przypadku braku możliwości usunięcia błędów w podanych wyżej terminach Wykonawca dostarczy równoważne Rozwiązanie zastępcze (workaround). Rozwiązanie zastępcze może funkcjonować nie dłużej niż 30 dni od dat jego dostarczenia. 4.3 Utrzymanie i aktualizacje zaimplementowanych polityk skanowania, raportów i alertów stworzonych na potrzeby Zamawiającego w wymiarze 3 dni roboczych w danym kwartale świadczenia usługi serwisu. 4.4 Wykonawca zapewni wsparcie powdrożeniowe w okresie 12 miesiące od daty podpisania Protokołu odbioru końcowego. Objęcie suportem oraz usługami wsparcia technicznego i serwisu Systemu musi zapewnić Zamawiającemu pełną gotowość Wykonawcy do świadczenia opisanych w niniejszej specyfikacji usług od pierwszego dnia obowiązywania Umowy. Ponadto, świadczone usługi nie mogą negatywnie wpływać na zintegrowane z Systemem aplikacje biznesowe i inne systemy bezpieczeństwa informacji. 8
4.5 Wsparcie techniczne musi być świadczone, przez co najmniej jednego inżyniera Wykonawcy, posiadającego stosowne kompetencje, potwierdzone certyfikatem z oferowanej technologii. 4.6 Wszelkie nośniki danych (w szczególności dyski twarde, karty pamięci), w przypadku awarii lub usterki (po jej usunięciu) pozostają w siedzibie Banku. Koszt pozostawionych nośników danych wliczony jest w opłatę Serwisową. 9