Ogłoszenie nr 328036 - 2016 z dnia 2016-10-21 r.

Wrocław: "Dostawa urządzenia zabezpieczającego aplikacje WWW(Firewall Aplikacyjny) wraz z usługą wdrożenia"
OGŁOSZENIE O UDZIELENIU ZAMÓWIENIA -

Zamieszczanie ogłoszenia: obowiązkowe.

Ogłoszenie dotyczy: zamówienia publicznego

Zamówienie dotyczy projektu lub programu współfinansowanego ze środków Unii Europejskiej

nie

Zamówienie było przedmiotem ogłoszenia w Biuletynie Zamówień Publicznych: tak
Numer ogłoszenia: 309538 z dnia 16.09.2016

Ogłoszenie o zmianie ogłoszenia zostało zamieszczone w Biuletynie Zamówień Publicznych: nie

SEKCJA I: ZAMAWIAJĄCY

Postępowanie zostało przeprowadzone przez centralnego zamawiającego

nie

nie

nie

nie

I. 1) NAZWA I ADRES: Centrum Usług Informatycznych we Wrocławiu, krajowy numer identyfikacyjny 2228736100000, ul. ul. Namysłowska  8, 50304   Wrocław, państwo Polska, woj. dolnośląskie, tel. 71 777 90 23, faks , e-mail piotr.schmidt@cui.wroclaw.pl
Adres strony internetowej (URL): http://bip.cui.wroclaw.pl

I. 2) RODZAJ ZAMAWIAJĄCEGO:

Administracja samorządowa

I.3) WSPÓLNE UDZIELANIE ZAMÓWIENIA (jeżeli dotyczy):

Podział obowiązków między zamawiającymi w przypadku wspólnego udzielania zamówienia, w tym w przypadku wspólnego przeprowadzania postępowania z zamawiającymi z innych państw członkowskich Unii Europejskiej (jeżeli zamówienie zostało udzielone przez każdego z zamawiających indywidualnie informacja w sekcji I jest podawana przez każdego z zamawiających, jeżeli zamówienie zostało udzielone w imieniu i na rzecz pozostałych zamawiających w sekcji I należy wskazać który z zamawiających zawarł umowę):

SEKCJA II: PRZEDMIOT ZAMÓWIENIA

II.1) Nazwa nadana zamówieniu przez zamawiającego:

"Dostawa urządzenia zabezpieczającego aplikacje WWW(Firewall Aplikacyjny) wraz z usługą wdrożenia"

CUI/ZP/PN/18/2016

Dostawy

1. 1.Celem zamówienia jest zakup systemu Web Aplication Firewall, wdrożenie go w infrastrukturze zamawiającego oraz szkolenia z administracji systemem. Zadaniem systemu " Web Aplication Firewall" ma być monitorowanie całej aktywności użytkowników względem aplikacji internetowych będących w posiadaniu Urzędu Miasta Wrocław. System ma za zadanie chronić te aplikację i dane przed cyberatakami. 2.Zamówienie obejmuje: 1) Wdrożenie rozwiązania w infrastrukturze zamawiającego uwzględniając wszystkie aplikacje będące w posiadaniu Zamawiającego (jest to około 40 adresów URL), dostarczenie dokumentacji technicznej z wdrożenia zawierającej schematy połączeń oraz konfiguracji zabezpieczeń aplikacji. 2) Zapewnienie ciągłości poprawnego działania "Web Aplication firewall". 3) Zapewnienie Wsparcia technicznego producenta sprzętu/ maszyny wirtualnej dla systemu "Web Aplication firewall" w okresie trwania umowy. 4) Zapewnienie opieki serwisowej w zakresie rozwiązywania problemów, aktualizacji oraz konfiguracji systemu. 5) Zapewnienie Wsparcia Wykonawcy oraz producenta oprogramowania dla wdrożonego systemu. 6) Wymagane jest potwierdzenie przez producenta bądź dostawce oprogramowania poniżej opisanych "kluczowych elementów systemu". 3. Kluczowe elementy które musi posiadac system: 1) Wszystkie elementy systemu zabezpieczeń muszą być dostarczone przez jednego producenta w formie gotowych maszyn virtualnych działających w środowisku ESX/ESXi 2) System musi działać w następujących trybach pracy: Transparent Bridge (inline warstwa 2 ISO/OSI), Transparent Reverse Proxy - tj praca w trybie proxy nie wymagająca korzystania z nowych adresów IP, Reverse Proxy oraz Sniffing przy czym musi istnieć możliwość działania w trybie Transparent Bridge oraz Transparent Reverse Proxy w obrębie tych samych chronionych aplikacji. 3) Moduły wykonawcze muszą mieć możliwość pracy w trybie High Availability (HA), powinny zawierać mechanizm ochrony typu Stateful Firewall oraz weryfikować zgodność komunikacji sieciowej ze standardem protokołu tcp/ip, opisanym w RFC. 4) System musi mieć wydajność analizy protokołu http/https na poziomie 500Mbps. 5) Uwierzytelnianie użytkowników oferowanego rozwiązania musi być możliwe za pomocą integracji z Active Directory, LDAP w celu uzyskania dodatkowych informacji w logach na temat użytkownika. Obsługiwane muszą być nie mniej niż następujące metody uwierzytelnienia: formularze html, certyfikat cyfrowy, kerberos, NTLM. 6) Całość konfiguracji oraz repozytorium logów musi być przechowywane na centralnym serwerze zarządzania. 7) System powinien na podstawie analizy obserwowanego ruchu zbudować odzwierciedlenie całej struktury aplikacji, składającej się z katalogów, URLi, metod dostępu, parametrów, typów wartości oraz długości ciągów znaków wprowadzanych przez użytkowników w poszczególnych formatkach a w szczególności powinien umożliwiać naukę formularzy, służących do logowania się użytkowników do aplikacji Web. 8) System powinien zagwarantować wysoki poziom ochrony serwerów Web oraz serwerów aplikacyjnych ( uwzględniając elementy XML oraz akcje SOAP) przed różnego typu atakami, a także powinien monitorować poprawne zachowanie chronionej aplikacji, a wszelkie próby wyjścia poza to poprawne zachowanie powinien blokować. Wymagane są sygnatury dla nie mniej niż : sieci, aplikacji Web, zapytań Web. 9) Monitorowanie i kontrolowanie w czasie rzeczywistym wszystkich operacji wykonywanych przez użytkowników. Rozwiązanie musi posiadać możliwość rejestrowania naruszeń bezpieczeństwa oraz udostępniać administratorom co najmniej następujące informacje o zdarzeniach: nazwa użytkownika aplikacyjnego (jeżeli klient zalogował się w systemie przez aplikację Web) , dodatkowe atrybuty użytkownika z zewnętrznych repozytoriów jak baza danych czy LDAP oraz zapytanie HTTP przesłane do serwera aplikacji Web. 10) Musi istnieć możliwość rejestrowania kodu źródłowego strony zwracanej klientowi przez aplikację Web, dostępnego bezpośrednio z interfejsu GUI serwera zarządzającego. 11) System powinien posiadać GUI dostępne przez przeglądarkę internetową w celu zoptymalizowania pracy, eliminacji konieczności instalacji dodatkowego oprogramowania na stacji administratora a także scentralizować zarządzanie całością rozwiązania. 12) Samoczynne uczenie się "normalnych" zachowań aplikacji umożliwiając przegląd zestawienia zachowań użytkowników z informacją o zagrożeniach. 13) Kontrolowanie dostępu do danych wrażliwych występujących w aplikacjach , które system ma chronić. 14) Przyśpieszenie procesów reagowania na incydenty naruszenia bezpieczeństwa oraz procesów śledczych dzięki zastosowaniu technik analitycznych. 15) Automatyczne uczenie się struktury danej aplikacji webowej oraz zachowań użytkowników, profil aplikacji Web musi być budowany w sposób automatyczny poprzez analizę ruchu sieciowego. Musi istnieć możliwość automatycznej aktualizacji profilu w przypadku wystąpienia zmiany w strukturze aplikacji. 16) System musi posiadać możliwość sprawdzenia, które z wykorzystywanych pól aplikacji są typu "read-only" i nie mogą być zmieniane przez klientów. 17) Wykrywanie ruchu sieciowego pochodzącego z potencjalnie niebezpiecznych źródeł w tym sieci TOR- ukrywania źródła ataku, szkodliwe adresy IP z których wielokrotnie zaatakowano inne strony Internetowe. 18) Tworzenie wirtualnych poprawek dla aplikacji poprzez integrację ze skanerem podatności. 19) Musi istnieć możliwość tworzenia własnych raportów, zarówno w formie tekstowej jak i reprezentacji graficznej bezpośrednio z centralnego serwera zarządzającego oraz możliwość cyklicznego wysyłania raportów wiadomością e-mail. Rozwiązanie musi posiadać funkcję wysyłania informacji o zdarzeniach: poprzez protokół SNMP. System musi posiadać możliwość wygenerowania gotowych raporty dotyczących: alarmów bezpieczeństwa, zdarzeń systemowych, zmian w profilach aplikacji, ostrzeżeń, ataków, prób włamań. 20) Tworzenie tzw. "białej listy" akceptowanych zachowań użytkownika (profilowanie chronionych aplikacji), nie może dodawać do profilu informacji pochodzących z przeprowadzanych ataków. 21) Automatyczne wykrywanie niepożądanych atrybutów, niezgodnych z protokołem HTTP. 22) System powinien analizować słabe punkty zgłaszane przynajmniej przez Bugtraq, CVE, Snort. 23) Powienien posiadać ochronę przed botami. 24) Umożliwiać zaimplementowanie CAPTCHA oraz posiadać możliwość wirtualnego "patchowania" aplikacji. 25) Powinien posiadać możliwość geolokalizacji adresów IP - położenie geograficzne będące źródłem ataków i blokady dostępu. 26) System w przypadku ataku powinien umożliwić: blokowanie pakietu oraz źródła ataku w postaci adresu IP, nazwy użytkownika lub sesji (jeżeli użytkownik uwierzytelnił się w systemie). 27) Musi istnieć możliwość uruchomienia skryptu shell w przypadku wykrycia incydentu. 28) Wykrywanie phishingowych adresów URL - fałszywe strony internetowe (adresy URL) używane podczas ataków phishingowych. 29) Wykrywanie adresów IP znanych, aktywnych spamerów, adresów atakujących (serwis reputacyjny, udostępniający listy niebezpiecznych adresów IP. 30) Wykryć adresy z których wykonywane są krytyczne incydenty SQL Injection oraz Remote File Inclusion, anonimowe proxy maskujące tożsamość użytkowników oraz adresy IP znane ze spamowania na forach internetowych. Baza adresów IP musi być pogrupowana według zagrożeń a także automatycznie aktualizowana. 31) Rozwiązanie musi posiadać reguły dotyczące identyfikacji incydentów typu web scraping poprzez zliczanie ilości odwołań do serwisu, oraz identyfikację ataków z sieci Bot dzięki wykorzystaniu skryptów java wykonywanych w przeglądarce klienta. 32) Ochrona przed atakami CSRF bez modyfikacji ruchu HTTP. 33) Aktualizacja systemu musi być dostępna zarówno poprzez ręczne pobranie zawartości ze strony producenta jak i automatycznie, poprzez zdefiniowanie terminów wykonania procedury aktualizacji. 34) Powinien posiadać możliwość integracji z systemem SIEM (syslog) - ManageEngine Eventlog Analyzer. 35) Powinien posiadać możliwość zarządzania prawami użytkowników dla plików przechowywanych na serwerach oraz sieciowych pamięciach masowych nie ograniczając przy tym wydajności i dostępności serwera plików, sygnalizować lub blokować żądania dostępu naruszające politykę korporacyjną dotyczącą bezpieczeństwa plików. 36) System powinien posiadać możliwość rozwoju funkcjonalności o ochronę bazy danych. 37) Tworzenie wirtualnych poprawek dla aplikacji poprzez integrację ze skanerami podatności. 38) System powinien klasyfikować wagę, typ zagrożenia i oznaczać go np. kolorem (system powinien korzystać z bazy podatności, prób ataków producenta). W przypadku znanych ataków system powinien automatycznie blokować zagrożenie.

Nie

II.5) Główny Kod CPV: 32420000-3
Dodatkowe kody CPV: 72265000-0

SEKCJA III: PROCEDURA

III.1) TRYB UDZIELENIA ZAMÓWIENIA

Przetarg nieograniczony

III.2) Ogłoszenie dotyczy zakończenia dynamicznego systemu zakupów

III.3) Informacje dodatkowe:

SEKCJA IV: UDZIELENIE ZAMÓWIENIA

IV.9) UZASADNIENIE UDZIELENIA ZAMÓWIENIA W TRYBIE NEGOCJACJI BEZ OGŁOSZENIA, ZAMÓWIENIA Z WOLNEJ RĘKI ALBO ZAPYTANIA O CENĘ

IV.9.1) Podstawa prawna
Postępowanie prowadzone jest w trybie   na podstawie art.  ustawy Pzp.

IV.9.2) Uzasadnienia wyboru trybu
Należy podać uzasadnienie faktyczne i prawne wyboru trybu oraz wyjaśnić, dlaczego udzielenie zamówienia jest zgodne z przepisami.