Załącznik nr 1 do Części II SIWZ Koncepcja Rozbudowy Systemu Ochrony Informacji (SOI) eksploatowanego. I. Opis Koncepcji Rozbudowy (Koncepcji) SOI, obejmującej swoim zakresem dostawę sprzętu, licencji oraz implementację nowych funkcjonalności. Stan obecny. Obecnie w PSE S.A. system ochrony informacji działa w następujących lokalizacjach: 1. Podstawowe Centrum Przetwarzania Danych (PCPD), ul. Warszawska 165, Konstancin- Jeziorna. 2. Rezerwowe Centrum Przetwarzania Danych (RCPD), ul. Mysia 2, Warszawa, 3. Stacje robocze i serwery z zainstalowanymi dedykowanymi dla nich komponentami systemu ochrony informacji, w lokalizacjach PCPD, RCPD i Oddziałów PSE S.A., zarządzane z PCPD i RCPD. PSE S.A. posiada obecnie następujące produkty firmy Intel Security (dawniej McAfee): Konsola zarządzająca: McAfee epolicy Orchestrator centralne zarządzanie SOI w zakresie rozwiązań firmy Intel Security (dawniej McAfee). Rozwiązania na stacjach roboczych i serwerach: VirusScan Enterprise realizacja ochrony antywirusowej. McAfee Drive Encryption realizacja szyfrowania danych na dyskach stacji roboczych. McAfee Data Loss Prevention Endpoint funkcje ochrony przed wyciekiem danych. McAfee MOVE o realizacja ochrony antywirusowej dedykowana dla środowisk wirtualnych. McAfee EMM zarządzanie sprzętem mobilnymi oraz system antywirusowy dla urządzeń z systemem Android. McAfee Email Gateway realizacja ochrony poczty elektronicznej przed SPAMem i innymi zagrożeniami. McAfee Web Gateway realizacja ochrony ruchu web przed zagrożeniami i niepoprawnym użyciem. McAfee Network Security Platform rozwiązanie realizujące ochronę IPS na brzegu sieci. McAfee Network Data Loss Prevention rozwiązanie ochrony przed wyciekiem danych na brzegu sieci. 1
Istniejący SOI zasila informacjami o zdarzeniach bezpieczeństwa eksploatowany u Zamawiającego system monitorowania bezpieczeństwa teleinformatycznego SIEM HP ArcSight. Stan docelowy. Docelowo Rozbudowany System Ochrony Informacji (RSOI) ma działać w następujących lokalizacjach: 1. Podstawowe Centrum Przetwarzania Danych (PCPD), ul. Warszawska 165, Konstancin- Jeziorna. 2. Rezerwowe Centrum Przetwarzania Danych (RCPD), ul. Mysia 2, Warszawa. 3. Stacje robocze i serwery z zainstalowanymi dedykowanymi dla nich komponentami systemu ochrony informacji, w lokalizacjach PCPD, RCPD i Oddziałów PSE S.A., zarządzane z PCPD i RCPD. 4. Stacje robocze i serwery z zainstalowanymi dedykowanymi dla nich komponentami systemu ochrony informacji, funkcjonujące w wyizolowanej sieci specjalnego przeznaczenia, przyłączonej do PCPD i RCPD. W ramach proponowanej rozbudowy należy zaprojektować i uruchomić do współpracy z istniejącym SOI następujące nowe Funkcje (moduły): A. moduł lokalnej bazy reputacji (LBR), gromadzący informacje o wszystkich plikach w sieci teleinformatycznej Zamawiającego objętej ochroną RSOI, nadający im kategoryzację względem poziomu bezpieczeństwa, na podstawie wyników ich skanowania w Sandbox, a także na podstawie globalnej bazy reputacji producenta i ręcznie przez administratora oraz szyna danych bezpieczeństwa (SDB), służąca do wymiany informacji o wykrytych zagrożeniach pomiędzy wszystkimi komponentami RSOI (np. w przypadku wykrycia niebezpiecznych akcji wykonywanych przez plik na Sandbox lub na IPS, informacja ta trafi do wszystkich składników RSOI, by podjęły automatyczne działania: oprogramowania antywirusowe na stacjach komputerowych usuną te pliki lub wskażą zainfekowane zasoby), B. moduł zaawansowanej analizy kodu wykonywalnego (Sandbox), odpowiedzialny za uruchamianie, na żądanie otrzymane od pozostałych składników RSOI za pośrednictwem 2
szyny danych bezpieczeństwa, podejrzanych plików w symulującym rzeczywisty komputer wyizolowanym środowisku wirtualnym, w celu wykrycia prób niebezpiecznych działań, przekazujący informację o wynikach skanowania do pozostałych składników RSOI za pośrednictwem szyny danych bezpieczeństwa, C. moduł wykrywania i analizy podatności (SWP), identyfikujący zainstalowane na komputerach w sieci teleinformatycznej PSE S.A. oprogramowanie i automatycznie powiadamiający o pojawiających się w nim zagrożeniach bezpieczeństwa, Rozbudowany SOI ma zostać skonfigurowany do współpracy ze środowiskami AD Microsoft Zamawiającego. Rozbudowany SOI ma zostać skonfigurowany do współpracy z istniejącym systemem SIEM HP ArcSight Zamawiającego. Elementy Rozbudowanego SOI dostarczają do SIEM informacje o wszystkich zarejestrowanych przez nie zdarzeniach bezpieczeństwa teleinformatycznego. Zamawiający wymaga, by format danych przekazywanych do SIEM był automatyczne rozpoznawany. Wszystkie elementy Rozbudowanego SOI mają zostać wdrożone i skonfigurowane w najnowszych wersjach produkcyjnych. Rozwiązania na stacjach roboczych i serwerach funkcjonujących w wyizolowanej sieci specjalnego przeznaczenia, zaplanowane do uruchomienia i skonfigurowania w ramach SOI (nie będące przedmiotem dostawy): Antywirus, antymalware moduły programowe realizujące ochronę antywirusową, zarządzane z dedykowanego serwera zarządzającego i wykorzystujące wszystkie funkcje rozbudowanego SOI dostępne za pośrednictwem szyny wymiany danych bezpieczeństwa, Whitelisting moduł programowy realizujący na stacjach roboczych i serwerach funkcję blokowania uruchamiania aplikacji nie zdefiniowanych jawnie jako dozwolone, zarządzany z dedykowanego serwera zarządzającego i wykorzystujące wszystkie funkcje RSOI dostępne za pośrednictwem szyny wymiany danych bezpieczeństwa. Dla zachowania separacji stacji roboczych i serwerów, funkcjonujących w wyizolowanej sieci specjalnego przeznaczenia od pozostałej infrastruktury PSE S.A. wymagane jest zaprojektowanie, instalacja i konfiguracja dodatkowych serwerów zarządzających i modułów RSOI w udostępnionym przez PSE S.A. środowisku wirtualnym, funkcjonującym w wyizolowanej sieci oraz dostarczenie dedykowanych serwerów (jeśli jest to wymagane technologicznie), przy założeniu minimalizacji wymaganej komunikacji pomiędzy segmentami. Komunikacja pomiędzy elementami RSOI w PCPD i RCPD a dodatkowymi serwerami i agentami w wyizolowanej sieci musi być szczegółowo opisana, by było możliwe jej precyzyjne filtrowanie na urządzeniach Zamawiającego pośredniczących w tej komunikacji. 3
II. Realizacja opisanej w Koncepcji rozbudowy podzielona została na trzy etapy: Etap I (do czterech tygodni od daty zawarcia umowy z Wykonawcą) W ramach realizacji Etapu I wymagane jest wykonanie następujących zadań: 1. Opracowanie Projektu Technicznego w oparciu o Koncepcję rozbudowy SOI. 2. Opracowanie harmonogramów wdrożenia, scenariuszy testowych, instrukcji instalacji, konfiguracji dostarczonych w ramach rozbudowy SOI. Zakres dokumentacji oraz instrukcji w uzgodnieniu z Zamawiającym. 3. Opracowanie planu testów, zakres testów powinien obejmować wszystkie aspekty wdrożenia. Wszystkie zadania określone w Etapie I zostaną odebrane po zakończeniu realizacji tego Etapu, zgodnie z zapisami w projekcie Umowy. Brak pozytywnego odbioru produktów Etapu I będzie skutkował rozwiązaniem Umowy. Etap II (do czterech tygodni od daty pozytywnego odbioru Etapu I) W ramach realizacji Etapu I wymagane jest wykonanie następujących zadań: 1. Dostarczenie sprzętu, licencji oprogramowania i usług wsparcia technicznego producenta. Specyfikację sprzętu, licencji oprogramowania oraz opis warunków świadczenia usług wsparcia technicznego producenta zawiera Załącznik nr 1 do Koncepcji. Etap III (do 12 tygodni od daty zakończenia Etapu II) W ramach realizacji Etapu III wymagane jest wykonanie następujących zadań: 1. Instalacja, konfiguracja i uruchomienie dostarczonych Sprzętu oraz Oprogramowania (licencje) we wskazanych przez Zamawiającego lokalizacjach, zgodnie z projektem technicznym opracowanym przez Wykonawcę w Etapie I oraz integracja z obecnie używanymi przez PSE rozwiązaniami Intel Security (dawniej McAfee) (m.in. Intrusion Prevention System, Web Gateway, Email Gateway, stacje końcowe). 2. Przeprowadzenie wymaganych testów akceptacyjnych dostarczonych w ramach rozbudowy SOI Sprzętu i Oprogramowania oraz testów akceptacyjnych funkcjonowania RSOI. Testy wykonuje Wykonawca we współpracy z Zamawiającym wg. scenariuszy testowych dostarczonych przez Wykonawcę. Wymaganie dotyczy wszystkich testów. 3. Opracowanie dokumentacji powykonawczej Rozbudowanego SOI. 4. Przeprowadzenie instruktażu w zakresie przeprowadzonej implementacji co najmniej 40 godzin dla 15 osób. III. Zasady świadczenia usługi wsparcia technicznego na Sprzęt i Oprogramowanie dostarczone na potrzeby rozbudowy SOI: 1. Sprzęt i Oprogramowanie musi być objęte usługą wsparcia technicznego, świadczoną w trybie 24 godziny, 7 dni w tygodniu. Przyjmowanie/obsługa zgłoszeń oraz naprawa w dni robocze. Naprawa w dni robocze w godzinach 7:00-18:00 - przystąpienie do naprawy sprzętu w miejscu instalacji u Zamawiającego, najpóźniej w następny dzień roboczy od momentu otrzymania zgłoszenia. Uszkodzone dyski twarde nie podlegają zwrotowi. 2. Wykonawca będzie pełnił Pierwszą Linię Wsparcia dla dostarczonych w ramach Rozbudowy SOI Sprzętu i Oprogramowania, objętych usługą wsparcia technicznego. 3. W okresie świadczenia usługi wsparcia wymagane jest zapewnienie dostępu dla Zamawiającego do wszystkich najnowszych wersji Oprogramowania. 4. Wykonawca na dostarczony Sprzęt i Oprogramowania zapewni usługę wsparcia technicznego producenta do 10 października 2018 r., a na usługę wdrożenia i wykonane prace udziela 36 miesięcznej gwarancji. Gwarancja na wykonane usługi liczona jest daty Odbioru bez zastrzeżeń Etapu III (końcowego). 4
IV. Instruktaż dla administratorów. 1. Instruktaż w zakresie dostarczonego Sprzętu i Oprogramowania dla administratorów (do 15 osób) obejmujący: instalację, administrację, konfigurację i rozwiązywanie problemów w ramach elementów stanowiących rozbudowę SOI, instalację, administrację, konfigurację i rozwiązywanie problemów w ramach istniejącego systemu ochrony informacji, w zakresie jego dostosowania do pracy w Rozbudowanym SOI. Wymagane jest, aby instruktaż był prowadzony na terenie Warszawy, w języku polskim. 5
Załącznik nr 1. Lista modułów (systemów) stanowiących przedmiot rozbudowy systemu ochrony informacji. L.p. Nazwa modułu Jednostka miary Minimalna wymagania ilościowe 1 Moduł zaawansowanej analizy kodu appliance/serwer wykonalnego (Sandbox) wirtualny 1 2 Moduł lokalnej bazy danych reputacji obsługiwane (LBR) stacje robocze 2100 3 Moduł wykrywania i analizy centralny podatności (SWP) appliance 2 4 Moduł wykrywania i analizy lokalny agent - podatności (SWP) appliance 9 5 Moduł wykrywania i analizy obsługiwane IP podatności (SWP) 10000 6 Szyna danych bezpieczeństwa (SDB) appliance/serwer wirtualny 2 Dla dostarczanych modułów i licencji oprogramowania wymagane jest zapewnienie podstawowego wsparcia producenta na poziomie opisanym w pkt D. poniżej. A. Moduły (systemy) wymiany informacji o zagrożeniach Szyna Danych Bezpieczeństwa (zwana dalej SDB) oraz Lokalna Baza Reputacji (LBR). Oba systemy maja na celu zapewnienie wymiany informacji o zagrożeniach pomiędzy różnymi komponentami bezpieczeństwa w infrastrukturze Zamawiającego, co najmniej pomiędzy systemem typu Sandbox i systemami końcowymi. Wymagania techniczne: 1. System SDB powinien umożliwiać przekazywanie informacji o zagrożeniach, co najmniej pomiędzy systemem Sandbox a obecnie funkcjonującym na stacjach roboczych Zamawiającego oprogramowaniem antywirusowym. 2. System SDB powinien być zbudowany o infrastrukturę tzw. brokerów, które pośredniczą w komunikacji różnych komponentów. 3. Każdy system biorący udział w komunikacji SDB powinien utrzymywać stałe, permanentne połączenie TCP z brokerem by można go było użyć w dowolnym momencie do przekazania komunikatu. 4. Komunikacja SDB powinna być zorganizowana w oparciu o tzw. tematy, które grupują komunikaty o podobnej tematyce. 5. System LBR powinien gromadzić informacje, co najmniej o plikach i certyfikatach, które są obecne w infrastrukturze Zamawiającego. 6. W ramach informacji zbieranych przez LBR powinny być co najmniej: a. W przypadku plików wykonywalnych: i. Reputacja pliku w systemie reputacyjnym producenta ii. Reputacja pliku w systemie Sandbox producenta iii. Ręcznie ustawiona reputacja iv. Informacje o systemach, gdzie plik był wykonywany v. Informacja o wieku pliku w infrastrukturze rozumianej jako odstęp czasu pomiędzy chwilą obecną a pierwszym wykonaniem pliku. b. W przypadku certyfikatów: i. Reputacja pliku w systemie reputacyjnym producenta ii. Ręczne ustawiona reputacja 6
7. Informacje w systemie LBR powinny być gromadzone i udostępniane w czasie rzeczywistym przez system SDB tego samego producenta. 8. Do każdego pliku powinna być na bieżąco wyliczana wynikowa reputacja bazująca na wielu danych wejściowych gromadzonych w okresie pracy systemu. 9. Każda istniejąca stacja robocza z zainstalowanym oprogramowaniem antywirusowym Zamawiającego powinna mieć możliwość aktualizacji informacji w LBR oraz używania tychże informacji w celu dokonania oceny własnej plików. 10. Pliki zidentyfikowane na stacjach roboczych Zamawiającego i oznaczone w LBR jako posiadające złą reputacje powinny być możliwe do skasowania ze stacji roboczych, a wszystkie procesy z nimi powiązane automatycznie zabite. Czynność ta powinna zostać zrealizowana przez zainstalowane u Zamawiającego oprogramowania McAfee VirusScan Entrerprise i odbywać się w czasie bliskim do rzeczywistego. Zabicie procesów nie powinno trwać dłużej niż 5 sekund od momentu naniesienia stosownej reputacji w LBR. 11. Produkt powinien integrować się z oprogramowaniem obecnie zainstalowanym na stacjach roboczych i serwerach Zamawiającego. 12. Zarządzanie LBR i SDB powinno być możliwe do realizacji z użyciem konsoli zarządzającej SOI zainstalowanej u Zamawiającego. 13. LBR powinna mieć możliwość integracji z systemem IPS McAfee zainstalowanym u Zamawiającego poprzez SDB w celu bieżącego konsumowania informacji reputacyjnej z LBR. 14. Powinna istnieć możliwość budowy hierarchii brokerów SDB w celu lepszego wpasowania się w infrastrukturę Zamawiającego. 15. Jeśli na stacjach roboczych wymagany jest dodatkowy komponent jego instalacja i konfiguracja powinna być również wykonywana z tej samej konsoli, co innymi systemami ochrony dla stacji roboczych tego samego producenta. 16. W ramach stacji klienckich powinny być wspierane co najmniej następujące systemy operacyjne: a. Windows XP b. Windows Vista c. Windows 7 d. Windows 8 e. Windows 8.1 f. Windows Server 2003 g. Windows Server 2008 R2 h. Windows Server 2012 i. Windows Server 2012 R2 17. System powinien dostarczać podstawowych raportów na temat stanu infrastruktury SDB oraz statystyk dotyczących LBR. 18. Powinna istnieć wyszukiwarka plików z możliwością podglądu ich reputacji. 19. W ramach wyszukiwania plików powinna istnieć możliwość zakładania filtrów, by lepiej dopasować wyniki do oczekiwań Zamawiającego. 20. System powinien być licencjonowany per ilość stacji roboczych z nim się komunikujących, którym udostępnia on swoje funkcje. 21. Dla dodatkowych elementów infrastruktury jak brokerzy czy serwery zarządzające nie powinny być wymagane żadne dodatkowe licencje. 22. Poza bazą danych dla środowiska zarządzającego dla brokerów SDB oraz serwerów LBR nie powinny być wymagane żadne dodatkowe licencje bazodanowe. 23. Oprogramowanie powinno być dostarczone w postaci maszyn wirtualnych VMware (format OVA/OVF) bezpośrednio przez producenta. B. Moduł (system) zaawansowanej analizy kodu wykonywalnego (dalej zwany Sandbox), który będzie realizował analizę rzeczywistą próbek kodu. Analiza powinna odbywać się z wykorzystaniem testowego środowiska złożonego z maszyn wirtualnych oraz integrować się z obecnie posiadaną infrastrukturą. Zakup rozwiązania ma zwiększyć 7
skuteczność wykrywania złośliwego oprogramowania typu 0-day w ramach zaawansowanych ataków z użyciem kodu złośliwego. Wymagania: System powinien spełniać następujące wymagania: 1. System Sandbox powinien dysponować możliwościami rzeczywistej analizy plików. Poprzez rzeczywistą analizę rozumie się uruchomienie pliku w środowisku testowym i wykonanie jego zawartości. Nie jest akceptowane rozwiązanie polegające tylko na sygnaturach lub innych mechanizmach bez faktycznego uruchomienia kodu. 2. Środowisko Sandbox powinno umożliwiać wgranie własnych, wcześniej przygotowanych obrazów systemów operacyjnych z wybranym przez zamawiającego oprogramowaniem towarzyszącym. 3. System Sandbox powinien akceptować przygotowane przez Zamawiającego systemy w postaci plików dysków VMware (pliki VMDK). 4. W ramach środowiska zaawansowanej analizy kodu wykonywalnego powinna istnieć możliwość instalacji następujących systemów operacyjnych: a. Windows XP b. Windows 7 c. Windows 8 d. Windows Server 2003 e. Windows Server 2008 R2 f. Android 5. System powinien umożliwić jednoczesne uruchomienie do 60 instancji powyższych systemów operacyjnych. 6. Wydajność Sandbox pozwalająca na analizę co najmniej 200 000 obiektów statycznych na dobę. 7. Licencje do systemów operacyjnych zostaną dostarczone przez Zamawiającego. 8. System powinien umożliwiać emulowanie łączności z Internetem dla badanych próbek. W razie wysłania żądania do zewnętrznego serwera WWW ten serwer powinien być emulowany i zwracać odpowiedź. W przypadku żądania ściągnięcia pliku powinien zostać dostarczony plik. 9. Powinna istnieć możliwość uruchomienia dostępu do Internetu dla analizowanego kodu oraz ustanowienie osobnego interfejsu fizycznego dla tego dostępu w celu separacji takiego ruch od sieci produkcyjnej. 10. W ramach analizy plików (obiektów statycznych) powinny być wspierane następujące formaty plików: a. Pliki wykonywalne Windows b. Pliki programów Microsoft Office Word, Excell, Power Point c. Pliki PDF, SWF, JAR d. Pliki wygaszaczy ekranu e. Pliki archiwów (ZIP, RAR, CAB, 7Z etc.) f. Pliki APK (aplikacje uruchamiane w środowisku Android) 11. Oprócz analizy dynamicznej (uruchomienia kodu) system powinien realizować analizę statyczną (analiza kodu bez jego uruchamiania). System powinien podjąć próby dezasemblacji kodu i analizy jego przebiegu. 12. W ramach analizy statycznej system Sandbox powinien realizować analizę porównawczą z posiadaną bazą bibliotek i innych zagrożeń. W razie stwierdzenia podobieństwa analizowanego kodu z biblioteką system wykryje kod jako złośliwy i umieści w raporcie stopień podobieństwa oraz rodzinę zagrożeń, do których to podobieństwo wystąpiło. 13. Przed właściwą analizą system Sandbox powinien podjąć próby oceny kodu z wykorzystaniem innych technik w postaci globalnej reputacji pliku oraz co najmniej dwóch 14. Możliwość bezpośredniej integracji z systemem do ochrony antywirusowej zainstalowanym na stacjach roboczych i serwerach Zamawiającego. W ramach integracji powinna być możliwość przesyłania informacji o zagrożeniach w czasie krótszym niż 5 sekund do wszystkich 8
uruchomionych stacji oraz zamykanie procesów uznanych, jako złośliwe przez system Sandbox. 15. Dodatkowo, system powinien dawać możliwość integracji bezpośredniej z innymi składnikami systemu ochrony informacji u Zamawiającego, jak Web Proxy, Email Proxy czy IPS. Bezpośrednia integracja powinna polegać na możliwości automatycznego przesyłania próbek do analizy i w razie wykrycia zagrożenia natychmiastowego blokowania go na w/w urządzeniach. 16. Powinna istnieć możliwość ręcznego wgrywania próbek do analizy. Ręczne wgrywanie próbek powinno być realizowane przez interfejs WWW rozwiązania. 17. Powinna istnieć możliwość wyboru odpowiedniej wersji systemu operacyjnego (32 lub 64 bitowego) w zależności od systemu zgłaszającego próbkę, z wykorzystaniem integracji z systemem zarządzania stacjami roboczymi zainstalowanym u Zamawiającego. 18. System Sandbox powinien umożliwiać tworzenie klastrów balansujących obciążenie pomiędzy większą ilość sprzętu Sandbox niż jedno. W ramach tworzenia klastra nie powinny być wymagane żadne dodatkowe licencje. 19. Po analizie i wykryciu kodu, jako zagrożenia powinny być dostępne następujące wyniki analizy: a. Oceny punktowej w skali pięciostopniowej (lub większej) b. Szczegółowego raportu prezentującego przebieg analizy. W ramach raportu powinny być dostępne: i. Wykonane operacje we/wy dyskowych ii. Operacje wykonane na rejestrach iii. Operacje sieciowe iv. Zrzuty ekranu, jeśli dostępne. c. Informacji możliwej do automatycznej analizy w postaci STIX/TAXII, d. Grafu obrazującego strukturę kodu wykonywalnego, e. Oryginalne próbki. 20. Powinny być dostępne panele (dashboardy), które prezentują podstawowe informacje dotyczące stanu rozwiązania i ilości obecnie analizowanych próbek. Dodatkowe powinny być prezentowane podstawowe dane historyczne. 21. Powinna istnieć możliwość logowania z użyciem syslog do zewnętrznych systemów typu SIEM. 22. Powinna istnieć możliwość ustanowienia wielu kont użytkowników z różnymi uprawnieniami. Dla przykładu powinna istnieć możliwość skonfigurowania użytkownika posiadającego dostęp jedynie do raportów bez próbek i możliwości rekonfiguracji sprzętu. 23. Zarządzanie powinno odbywać się jedynie z użyciem konsoli WEB za pomocą protokołu TLS. 24. Powinna istnieć możliwość wysyłania próbek z użyciem ogólnych zapytań REST. Powinna tez istnieć możliwość odpytania o wynik analizy z użyciem zapytań REST. 25. System powinien być licencjonowanie jedynie per sprzęt. Nie powinno być dodatkowych licencji per maszyna wirtualna czy ilość analizowanych próbek. 26. Rozwiązanie powinno być oferowane, jako appliance (max 2U). Niedopuszczalne jest wysyłanie próbki do chmury. C. Moduł (System Wykrywania Podatności) wykrywania i analizy podatności systemowych: Wymagania: System powinien spełniać następujące wymagania: 1. Oprogramowanie Systemu Wykrywania Podatności powinno obsłużyć do 10 000 adresów IP, 2. System Wykrywania Podatności powinien składać się z minimum 9 modułów skanujących wraz z dedykowanymi dla różnych lokalizacji geograficznych lub sieciowych platformami sprzętowymi oraz redundantna platforma zarządzająca sprzętowe zarządzająca, dostarczana i serwisowana przez producenta oprogramowania systemu skanowania. 3. Wszelkie informacje dotyczące wykrytych podatności i niezgodności z polityką bezpieczeństwa Zamawiającego czy ze standardami muszą być przetwarzane i przechowywane lokalnie w systemie SWP zainstalowanym w lokalizacjach Zamawiającego. 9
4. Całe niezbędne do działania SWP oprogramowanie (np. system operacyjny instalowany na appliance, baza danych, itp.) wraz z odpowiednimi licencjami muszą być zawarte w oferowanym rozwiązaniu. 5. Aktualizacje do oprogramowania zarządzającego i skanującego, ale także dla systemu operacyjnego i bazy danych muszą pochodzić ze stron producenta systemu SWP i być przez niego zaakceptowanymi do wdrożenia. 6. System musi wykorzystywać standardową bazę danych MS SQL o otwartej architekturze oraz opisanym schemacie. 7. System musi wykrywać podatności systemów operacyjnych i aplikacji w zakresie braku poprawek i błędów konfiguracji zgodnie z bazą wzorców dostarczaną przez producenta systemu SWP. 8. System musi być licencjonowany na zdefiniowaną liczbę adresów IP (węzłów) bez określania rodzaju węzła (stacja, serwer, urządzenia sieciowe, drukarka sieciowa, itp.). Wymagane jest dostarczenie licencji na co najmniej 10 000 adresów IP. 9. System musi sprawdzać zgodności skanowanych zasobów pod kątem przynajmniej następujących norm PCI, SOX, HIPAA, ISO 17799 i FISMA. 10. System musi sprawdzać zgodność podstawowych parametrów systemu z zadaną polityką (np. konto administratora lokalnego bez hasła, itp.). 11. System musi zapewniać weryfikację uprawnień dostępu do zasobów systemowych. 12. System musi zapewniać możliwość sprawdzania podatności systemu od strony sieci, do której jest podłączony skanowany węzeł, ale także od środka systemu operacyjnego działającego na skanowanych komputerach z systemami operacyjnymi MS Windows, Linux/Unix oraz na urządzeniach sieciowych. Skanowanie z perspektywy wnętrza systemu operacyjnego nie może wymagać instalacji jakiegokolwiek agenta. 13. Dla umożliwienia skanowania węzła z perspektywy jego systemu operacyjnego system SWP musi umożliwiać zalogowanie się do systemu węzła korzystając z natywnych metod MS Windows oraz poprzez SSH do innych węzłów. 14. System SWP musi umożliwiać zdefiniowanie indywidualnych danych (parametrów konta logowania) dla poszczególnych węzłów poddanych skanowaniu jak i dla grup tych węzłów. 15. W przypadku logowania poprzez SSH musi być możliwość automatycznego akceptowania certyfikatów użytych do autentykacji sesji SSH oraz możliwość użycia określonego konta użytkownika z hasłem. 16. System SWP musi zapewniać centralne zarządzanie jego wszystkimi funkcjami i elementami oraz centralne raportowanie wyników skanowania. 17. System SWP musi umożliwiać rozbudowę o dodatkowe sprzęty dedykowane pełniące funkcje lokalnych skanerów w sieciach wydzielonych, komunikujące się z centralnym serwerem i zarządzanych przez niego, zawierającym centralne repozytorium (bazę danych) oraz moduły raportujący i administrujący. 18. Całość komunikacji pomiędzy komponentami systemu musi być zaszyfrowana. 19. System musi wspierać co najmniej 3 metody (ICMP, TCP, UDP) wykrywania aktywnych węzłów (komputerów, urządzeń aktywnych, itd.) podłączonych do sieci. 20. System musi wspierać środowisko DHCP i korelować automatycznie dane dotyczące skanowanego węzła. 21. System musi przedstawiać dane o wynikach skanowania w formie raportów, musi również alarmować w przypadku wykrycia podatności krytycznych. 22. System musi umożliwiać sprawdzenie zgodności konfiguracji skanowanych węzłów z założonym poziomem (opisem polityki bezpieczeństwa). 23. Dla zdefiniowania skanów musi być możliwość skorzystania przez administratora z aktualizowanej okresowo przez producenta SWP listy podatności i luk dla różnych rodzajów węzłów, systemów operacyjnych, aplikacji. 24. Wymagane jest wyraźne określenie w systemie SWP czy wykonanie skanowania danej podatności może powodować sytuacje zatrzymania procesów, restart, itp. skanowanego węzła. 10
25. System musi umożliwiać tworzenie własnych opisów ( template'ów") podatności i parametrów konfiguracji wykorzystywanych podczas skanowania. 26. Musi istnieć możliwość tworzenia własnych sprawdzeń parametrów skanowanych systemów oraz własnych opisów oczekiwanej konfiguracji tych systemów w formacie OVAL/XCCDF. 27. System musi umożliwiać tworzenie domen administracyjnych wraz z definicją zakresu adresacji sieciowej dostępnej w tej domenie. 28. System musi umożliwiać elastyczne tworzenie użytkowników dla całej organizacji jak i poszczególnych domen wraz z nadawaniem im ról (np. operator, administrator, itp.). 29. System musi umożliwiać elastyczne grupowanie węzłów wykrytych w sieci i poddawanych skanowaniu - np. wg adresacji sieciowej, wg rodzaju systemu operacyjnego, itp. oraz pozwalać na definiowanie właściciela węzła (osoby odpowiedzialnej za jego konfiguracje i bezpieczeństwo). 30. System musi w sposób automatyczny tworzyć zgłoszenia serwisowe (tzw. Ticket) o wykrytych podatnościach i niezgodnościach z polityką oraz powiadamiać o tym właścicieli węzłów. 31. System musi w automatyczny sposób zamykać otwarte wcześniej zgłoszenia serwisowe, jeżeli podatność/niezgodność została usunięta i fakt ten został potwierdzony przez SWP podczas kolejnego skanowania. 32. System musi umożliwiać tworzenie wyjątków w skanowanych węzłach (np., w przypadku jeśli niedopuszczalne jest instalowanie poprawek na danym węźle lub grupie węzłów). 33. System musi pozwalać na automatyczne generowanie raportów i powiadamianie, kiedy są one dostępne. 34. System musi umożliwiać eksport raportów do formatów: HTML, XML, PDF, CSV. 35. System musi umożliwiać tworzenie własnych zapytań do bazy danych z poziomu aplikacji SWP. Forma tych zapytań powinna umożliwiać tworzenie zagnieżdżonych warunków: np. pokaż wszystkie wykryte urządzenia znajdujące się w sieci oddziału X, a następnie wśród nich te, na których działa system Linux. 36. System musi umożliwiać skanowanie lokalnych zasobów (po podaniu uprawnionego użytkownika) w rozumieniu systemu plików, czy też rejestru (bez potrzeby instalacji lokalnego agenta). 37. System musi umożliwiać skanowanie i wykrywanie co najmniej następujących rodzajów aktywnych węzłów w sieci oraz aplikacji: o Systemy operacyjne: Microsoft Windows Server 2003 i wyższe, Win9x i wyższe, Linux, Solaris, OpenBSD, FreeBSD, HP-UX, AIX, SCO, QNX, MacOS, o Aplikacje: Microsoft: Office, Exchange, SQL Server, Terminal Server, DNS, Apache, Sendmail, BIND, Oracle, MySQL, Web Sphere, SSH, WUFTP, o Urządzenia sieciowe: włączając routery, przełączniki, oraz load balancery firm Cisco, 3com, Linksys, o Zapory sieciowe (firewall): Cisco o Drukarki sieciowe: Ricoh, HP, Lexmark, Xerox, IBM, o Urządzenia sieci bezprzewodowej WLAN. 38. System musi umożliwiać wykrywanie podatności na wymienionych w poprzednim punkcie rodzajach węzłów. 39. System musi umożliwiać wykrycie węzłów podłączonych do skanowanego segmentu sieci wraz z rozpoznaniem systemu operacyjnego, jaki działa na danym węźle. 40. System musi umożliwiać przydzielenie priorytetu (czyli ważności) poszczególnym węzłom wykrytym w sieci. 41. W celu identyfikacji skanowanego systemu operacyjnego (OS fingerprinting) system nie może wysyłać pakietów niezgodnych z regułami RFC. 42. System musi umożliwiać elastyczne definiowanie zadań skanowania, ich intensywności, zajętości pasma w sieci w taki sposób, aby zminimalizować wpływ na normalną pracę sieci lub przyśpieszyć wykonanie skanu. 11
43. System musi wykrywać obecność usług (serwisów) udostępnionych na skanowanych węzłach działających na niestandardowych portach oraz jednoznacznie je identyfikować. 44. System musi umożliwiać przeprowadzenie skanowania w poszukiwaniu podatności tylko dla architektury skanowanego systemu np. na platformie Windows tylko podatności dotyczące tej platformy. 45. System musi być w automatyczny sposób aktualizowany informacjami o nowych podatnościach z zasobów producenta przez Internet. 46. System musi umożliwiać automatyczne szacowanie i wyliczanie wartości procentowej ryzyka w organizacji wg algorytmów dostarczonych przez producenta lub modyfikowanych przez administratora tak, aby dostosować je do potrzeb organizacji. 47. Algorytmy wyliczania poziomu ryzyka powinny uwzględniać minimum następujące parametry: o istotność wykrytej podatności wg producenta systemu SWP lub wg producenta systemu operacyjnego/aplikacji, w której wykryto lukę, o priorytet skanowanego węzła określany przez administratora systemu SWP. 47. Informacja o wartości ryzyka powinna być przechowywana w bazie danych systemu SWP, w taki sposób, aby możliwe było śledzenie zmian tej wartości w czasie. 48. System musi umożliwiać szybką identyfikację komputerów, które potencjalnie są narażone na nowe zagrożenie bez wykonywania kolejnego skanowania. Wymagania dotyczące integracji z innymi systemami: 48. System musi współpracować z serwerem zarządzającym McAfee epo, który jest aktualnie używany przez Zamawiającego, w celu: o odzwierciedlania struktury drzewa epo na strukturę węzłów objętych skanowaniem, o pobierania z epo informacji o wersji systemu operacyjnego skanowanego węzła, a następnie weryfikowania i eliminowania niepoprawnych informacji o rodzaju i wersji systemu operacyjnego w bazie SWP, o korelacji informacji o wykrytych podatnościach z danymi o zainstalowanych na skanowanych węzłach produktach McAfee VirusScan z włączoną funkcją ochrony przed atakami Buffer Overflow Protection, o prezentacji wyników skanowania poszczególnych węzłów bezpośrednio we właściwościach węzła zarządzanego przez epo z poziomu konsoli epo. 49. Dedykowana platforma sprzętowa systemu SWP musi posiadać wymiary i komponenty montażowe umożliwiające zainstalowanie jej w szafie stelażowej 19". 50. System musi posiadać moduł skanujący umożliwiający automatyczne skanowanie aplikacji webowych pod względem istniejących tam podatności. 51. Skanowanie aplikacji powinno być zgodne z OWASP oraz CWE. 52. Moduł skanowania aplikacji webowych powinien być w pełni zintegrowany z głównym skanerem podatności. D. Wymagania dla podstawowego wsparcia technicznego producenta oraz dla rozszerzonego wsparcie technicznego producenta dla dostarczanych rozwiązań.: 1. Wraz z zakupem sprzętu i oprogramowania ma być zapewniony dla Zamawiającego dostęp (subskrypcja) baz podatności, gwarancja na sprzęt i dostęp do wsparcia technicznego producenta w okresie do 10 października 2018r. 2. Podstawowe wsparcie techniczne producenta powinno zapewniać co najmniej: a. Codzienne updaty dostępne dla produktów, b. Upgrade y produktów, c. Alerty dotyczące malware u. d. Usługi analizy malware u, e. Wsparcie telefoniczne, za pomocą chat lub web włącznie z możliwością zdalnej sesji, 12
f. Wsparcie telefoniczne 24/7, g. Dostęp do bazy wiedzy oraz przewodników produktowych, h. Gwarancję na dostarczone sprzęty i oprogramowanie, oznaczająca wysyłkę urządzenia zastępczego w następnym dniu roboczym od momentu zdiagnozowania uszkodzenia sprzętowego urządzenia. 3. Wymagane jest aby rozszerzony zakres usług wsparcia producenta zapewniał: a. Bezpośredni dostęp do specjalistów produktowych z pominięciem niższych szczebli wsparcia technicznego producenta. 13