Załącznik nr 1 do SIWZ nr ref.: DOA-ZP-I.271.2.5.2013 Opis przedmiotu zamówienia Przedmiotem niniejszego zamówienia jest dostawa licencji oprogramowania ochrony antywirusowej i antyspamowej dla systemu teleinformatycznego Urzędu Miasta Łodzi wraz z asystą techniczną na 12 miesięcy. Licencja musi umoŝliwiać wykorzystanie oprogramowania na 2300 stacjach roboczych lub serwerach oraz dla 3000 uŝytkowników serwera poczty elektronicznej (bramki smtp). Nazwa i kod dotyczący przedmiotu zamówienia określony we Wspólnym Słowniku Zamówień Publicznych (CPV): 48.76.10.00-0 Pakiety oprogramowania antywirusowego Oferowane rozwiązanie musi spełniać wymagania opisane w niniejszym opisie przedmiotu zamówienia w pkt. I. Wymagania minimalne dotyczące rozwiązania oraz Wymagania minimalne dotyczące wdroŝenia pkt. II. Zamawiający uŝywa obecnie oprogramowanie Symantec Protection Suite Enterprise Edition 4.0. I. Wymagania minimalne dotyczące rozwiązania 1. Wymagania ogólne. 1) Rozwiązanie musi zapewnić ochronę w dwóch obszarach tj. ochronę stacji końcowej uŝytkownika oraz serwerów plikowych jak równieŝ w zakresie ochrony poczty smtp instalowane osobno ( nie na działającym serwerze pocztowym). 2) Wszystkie moduły oprogramowania w kaŝdym z obszarów opisanych w pkt 1), muszą posiadać konsolę zarządzającą. Jedna konsola musi obejmować co najmniej funkcjonalność ochrony stacji końcowej uŝytkownika oraz serwerów plikowych. Zarządzanie system ochrony poczty smtp moŝe być realizowane z wykorzystaniem konsoli dedykowanej lub poprzez konsolę do zarządzania ochroną stacji końcowej uŝytkownika oraz serwerów plikowych. 3) Zamawiający nie dopuszcza rozwiązań typu Unified Threat Managment (UTM). 4) W obszarze ochrony stacji końcowej uŝytkownika oraz serwerów plikowych oprogramowanie musi realizować co najmniej następujące funkcjonalności: ochrona antywirusowa, firewall, ids/ips na interfejsie sieciowym, kontrola aplikacji na stacjach roboczych oraz kontrola zgodności z polityką bezpieczeństwa stacji roboczych. Szczegółowy opis funkcjonalności jest opisany w pkt 2. Szczegółowe wymagania techniczne. 5) W obszarze ochrony poczty smtp oprogramowanie musi realizować, co najmniej następujące funkcjonalności: ochronę antywirusową, antyspamową. Szczegółowy opis funkcjonalności jest opisany w pkt 2. Szczegółowe wymagania techniczne. 6) Pełna funkcjonalność klienta dla stacji roboczej musi być zawarta w jednym pliku instalacyjnym *msi, zgodnym z Windows Installer.
7) Oprogramowanie musi działać na systemach Windows XP 32/64-bit, Windows Vista 32/64-bit, Windows 7 32/64-bit, Windows 8 32/64 bit, Windows 2003 32/64-bit, Windows 2008 32/64-bit, Windows 2008 R2, Windows 2012. 8) Oferowane rozwiązanie musi poprawnie funkcjonować w zakresie serwerów zarządzających (konsola zarządzająca) oraz ochrony serwerów smtp w środowisku VMWare ESXi. 9) Komponenty rozwiązania, które realizują funkcjonalności takie jak: firewall, zapobieganie włamaniom i kontrola aplikacji na stacjach roboczych, muszą działać na wszystkich powyŝszych platformach 32/64-bitowych. 10) Serwer zarządzający musi działać na systemach Windows 2003 32/64-bit, Windows 2008 32/64-bit, Windows 2008 R2, Windows 2012. 11) Zarządzanie systemem ma być zapewnione poprzez graficzną konsolę administratora. 12) Rozwiązanie ma zapewniać wysoką skalowalność(obsługa do 10 000 stacji). 13) Komunikacja pomiędzy agentami i serwerem ma być szyfrowana i kompresowana. 14) Numery portów uŝywane do komunikacji mają mieć moŝliwość konfiguracji. 15) Agent ma się przełączać do innego serwera zarządzającego w przypadku niedostępności przypisanego serwera. 16) Musi istnieć moŝliwość zdefiniowania dowolnego klienta, jako lokalnego źródła aktualizacji z moŝliwością konfiguracji określenia prędkości ich pobierania z serwera zarządzającego. 17) JeŜeli rozwiązanie wykorzystuje oprogramowanie firm trzecich, muszą zostać dostarczone licencje na ich uŝywanie. 18) Asysta techniczna świadczona przez producenta w swoim zakresie musi obejmować upgrade oprogramowania i jego składników, update definicji antywirusowych i antyspamowych oraz pomoc techniczną przy rozwiązywaniu problemów z zaoferowanym oprogramowaniem. Czas naprawy nie dłuŝszy niŝ 14 dni. 2. Szczegółowe wymagania techniczne. 1) Ochrona antywirusowa stacji roboczej oraz serwerów plikowych. a. Usuwanie wirusów, makro wirusów, robaków internetowych oraz koni trojańskich (oraz wirusów i robaków z plików skompresowanych oraz samorozpakowujących się) lub kasowanie zainfekowanych plików. Ochrona przed oprogramowaniem typu spyware i adware, włącznie z usuwaniem zmian wprowadzonych do systemu przez to oprogramowanie tego typu. b. Wykrywanie wirusów, makro-wirusów, robaków internetowych, koni trojańskich, spyware, adware i dialerów ma być realizowane w pojedynczym systemie skanującym. c. Określanie obciąŝenia CPU dla zadań skanowania zaplanowanego oraz skanowania na Ŝądanie. d. Skanowanie zaplanowane musi umoŝliwiać automatyczne pomijanie plików uznanych przez producenta za zaufane. e. Skanowanie plików pobranych z Internetu wraz ze skryptami umieszczonymi w sieci Internet oraz plików skompresowanych.
f. Zapewnienie stałej ochrony wszystkich zapisywanych, odczytywanych, a takŝe uruchamianych plików przez mechanizm skanujący pracujący w tle wraz z metodą heurystyczną wyszukiwania wirusów (na Ŝyczenie); pliki te mogą być skanowane: na dyskach twardych, w boot sektorach, na dyskietkach, na płytach CD/DVD, na zewnętrznych dyskach twardych (np. podłączonych przez port USB). g. MoŜliwość samodzielnego pobierania aktualizacji z Internetu do stacji roboczej h. MoŜliwość zablokowania funkcji zmiany konfiguracji klienta lub ukrycie interfejsu uŝytkownika klienta. i. Scentralizowaną obsługę wirusów polegającą na przekazywaniu nieodwracalnie zainfekowanych plików do bezpiecznego miejsca w postaci centralnej kwarantanny na centralnym serwerze, w celu przeprowadzenia dalszych badań. j. Wbudowana w oprogramowanie funkcja do wysyłania podejrzanych lub zainfekowanych nowymi wirusami plików do producenta w celu uzyskania szczepionek. k. Wyszukiwanie i usuwanie wirusów w plikach skompresowanych (takŝe zagnieŝdŝonych wewnątrz innych plików skompresowanych) w szczególności z plikach typu ZIP, GNU, LZH/LHA, BinHex, ARJ, RAR, MIME/UU, TAR, kontenery CAB,UUE, Rich Text Format. l. Aktualizacja definicji wirusów nie wymaga zatrzymania procesu skanowania na jakimkolwiek systemie serwerze czy stacji roboczej. m. Mikrodefinicje wirusów - przyrostowe, scentralizowane aktualizowanie klientów jedynie o nowe definicje wirusów i mechanizmy skanujące. n. MoŜliwość cofnięcia procesu aktualizacji definicji wirusów i mechanizmów skanujących powrót do poprzedniego zastawu definicji wirusów bez konieczności deinstalacji oprogramowania czy teŝ restartu komputerów. o. MoŜliwość natychmiastowego wypchnięcia definicji wirusów do stacji klienckich p. Aktualizacja bazy definicji wirusów oraz mechanizmów skanujących, co najmniej 2 raz dziennie. q. Aktualizacja baz definicji musi być aplikowana tylko w czasie nieaktywności uŝytkownika na komputerze jeŝeli uŝytkownik komputera na nim pracuje, aplikacja automatycznie zostaje opóźniona. r. MoŜliwość aktualizacji bazy definicji wirusów średnio, co 1 godzinę. s. Heurystyczna technologia do wykrywania nowych, nieznanych wirusów. t. Moduł analizy w czasie rzeczywistym zachowań aplikacji do wykrywania nowych, nieznanych zagroŝeń typu robak internetowy, koń trojański, keylogger. u. Automatyczna rejestracja w dzienniku zdarzeń wszelkich nieautoryzowanych prób zmian rejestru dokonywanych przez uŝytkownika. v. Automatyczne ponowne uruchomianie skanowania w czasie rzeczywistym, jeśli zostało wyłączone przez uŝytkownika mającego odpowiednie uprawnienia na z góry określony czas. w. Automatyczne wymuszanie na kliencie programu pobrania zaktualizowanych definicji wirusów, jeśli aktualnie przechowywane pliki są przestarzałe. x. Aktualizacje definicji wirusów posiadają podpis cyfrowy, którego sprawdzenie gwarantuje, Ŝe pliki te nie zostały zmienione. y. Skanowanie poczty klienckiej (na komputerze klienckim). z. Opóźnienie skanowania zaplanowanego w wypadku działania komputera (laptopa) na bateriach.
aa. Ściągnięcie dowolnego pliku na komputer musi spowodować sprawdzenie reputacji takiego pliku jako reputacja rozumie się odpowiedź, co do ilość uŝytkowników w Internecie korzystających z danej aplikacji/pliku, czasu, kiedy aplikacja/plik pojawiła się w Internecie po raz pierwszy, oraz czy aplikacja/plik jest dobra czy teŝ nie. bb. W wypadku systemu Windows 8, wsparcie dla funkcji ELAM (Early Launch Anti- Malware). 2) Firewall dla stacji roboczej oraz serwerów plikowych a. Pełne zabezpieczenie stacji klienckich przed nieautoryzowanymi próbami dostępu do komputerów i skanowaniem jego portów. b. Moduł firewall ma mieć moŝliwość monitorowania i kontroli, jakie aplikacje łączą się poprzez interfejsy sieciowe. c. Administrator moŝe definiować połączenia, które stacja robocza moŝe inicjowaći odbierać. d. Administrator moŝe konfigurować dostęp stacji do protokołów rozszerzonych innych niŝ ICMP,UDP czy TCP np.: IGMP, L2TP. e. Program ma pozwalać na zdefiniowanie indywidualnych komputerów lub całych zakresów adresów IP, które są traktowane, jako: całkowicie bezpieczne lub niebezpieczne. f. Program musi wykrywać próby wyszukiwania luk w zabezpieczeniach systemu w celu przejęcia nad nim kontroli. g. Konfiguracja zezwalanego i zabronionego ruchu ma się odbywać w oparciu o takie informacje jak: interfejs sieciowy, protokół, stacja docelowa, aplikacja, godzina komunikacji. h. Konfiguracja stacji ma się odbywać poprzez określenie: Adresu MAC, numeru IP, zakresu numerów IP, wskazanie podsieci, nazwy stacji DNS (FQDN) lub domeny DNS. i. Firewall powinien umoŝliwiać nagrywanie komunikacji spełniającej wskazane wymagania. j. Firewall ma mieć konfigurowalną funkcjonalność powiadamiania uŝytkownika o zablokowanych aplikacjach. Ma istnieć moŝliwość dodania własnego komunikatu. k. W przypadku wykrycia zdefiniowanego ruchu, firewall ma wysłać wiadomość do administratora. l. UniemoŜliwianie określenia systemu operacyjnego i rodzaju przeglądarki internetowej przez serwery www. m. UniemoŜliwienie określenia systemu operacyjnego poprzez analizę pakietów sieciowych wysyłanych przez stację. n. UniemoŜliwienie przejęcia sesji poprzez losowo generowane numery sekwencji TCP. o. Domyślne reguły zezwalające na ruch DHCP, DNS, WINS. p. Wsparcie dla protokołu IPv6. 3) IDS/IPS na interfejsie sieciowym dla stacji roboczych i serwerów plikowych a. Producent ma dostarczyć bibliotekę ataków i podatności (sygnatur) stosowanych przez produkt. Administrator ma mieć moŝliwość uaktualniania tej biblioteki poprzez konsolę zarządzającą. b. Biblioteka ataków i podatności musi zawierać przynajmniej 3000 sygnatur. c. Biblioteka sygnatur musi zawierać równieŝ sygnatury dotyczące działalności programów P2P. d. Wykrywanie skanowania portów.
e. Ochrona przed atakami typu odmowa usług (Denial of Service). f. Blokowanie komunikacji ze stacjami z podmienionymi MAC adresami (spoofed MAC). g. Wykrywanie trojanów i generowanego przez nie ruchu. h. Wykrywanie prób nawiązania komunikacji za pośrednictwem zaufanych aplikacji, przez inne oprogramowanie. i. Blokowanie komunikacji ze stacjami uznanymi za wrogie na zdefiniowany przez administratora czas. Ma istnieć moŝliwość definiowania wyjątków. j. System ochrony przed włamaniami musi automatycznie integrować się z przeglądarką internetową (przynajmniej z Internet Explorer oraz Firefox) uniemoŝliwiając wykonanie w nich (nawet, jeŝeli są podatne) szkodliwego dla nich kodu. 4) Kontrola aplikacji na stacjach końcowych oraz serwerach plikowych a. Produkt ma umoŝliwiać uruchamianie i blokowanie wskazanych aplikacji. b. Produkt ma umoŝliwiać ładownie modułów lub bibliotek DLL. c. Produkt ma umoŝliwiać kontrolę odczytywania i zapisywania na systemie plików przez wskazane aplikacje. d. Aplikacje powinny być rozróŝniane poprzez nazwę i sygnaturę cyfrową. e. Produkt ma umoŝliwiać blokowanie wskazanego typu urządzeń przed dostępem uŝytkownika urządzenia muszą być identyfikowane po ich numerze seryjnym. f. Produkt ma kontrolować dostęp do rejestru systemowego. g. Produkt ma umoŝliwiać logowanie plików wgrywanych na urządzenia zewnętrzne. h. Produkt musi automatycznie umoŝliwić zablokowanie pliku autorun.inf na urządzeniach zewnętrznych i na udziałach sieciowych. i. Polityki ochrony mają mieć moŝliwość pracy w dwóch trybach, testowym i produkcyjnym. W trybie testowym aplikacje i urządzenia nie są blokowane, ale jest tworzony wpis w logu. j. MoŜliwość wykluczenia dowolnej aplikacji z trybu ochrony systemu operacyjnego. k. MoŜliwość utworzenie listy zaufanych aplikacji (tzw. białej listy) i konfiguracji produktu w taki sposób, by Ŝadna inna aplikacja/biblioteka z poza listy nie mogła uruchomić się na komputerze. l. MoŜliwość utworzenia listy blokowanych aplikacji (tzw. czarnej listy) i konfiguracji produktu w taki sposób, by tylko aplikacja znajdujące się na liście nie mogły uruchomić się na komputerze. m. MoŜliwość automatycznego importu list zarówno białej, jaki i czarnej, co zdefiniowany interwał czasu. 5) Kontrola zgodności z polityką bezpieczeństwa stacji roboczych i serwerach plikowych a. Oprogramowanie musi umoŝliwiać wykonywanie szerokiego zakresu testów integralności komputera pod kątem zgodności z polityką bezpieczeństwa urządzeń końcowych, w tym: programów antywirusowych, poprawki firmy Microsoft, dodatki Service Pack firmy Microsoft, osobistych zapór ogniowych. b. Testy integralności ma być przeprowadzany cyklicznie, co zdefiniowany okres czasu. c. PowyŜsze szablony muszą być automatycznie aktualizowane ze strony producenta
d. Oprogramowanie musi umoŝliwiać wykonanie niestandardowego (dowolnie zdefiniowanego) testu integralności komputera, posiadać zaawansowaną składnie If Then Else. e. W przypadku niestandardowego testu integralności musi istnieć dostępność następujących testów: wpisy rejestru systemu operacyjnego - istnienie, określona wartość, inne; pliki - istnienie, data, rozmiar, suma kontrolna; wiek, data, rozmiar pliku sygnatury oprogramowania antywirusowego; zainstalowane poprawki; uruchomiony proces, wersja systemu operacyjnego; własna aplikacja. f. W przypadku niezgodności stacji z testem integralności, musi być moŝliwość ustawienia akcji naprawczej na poziomie pojedynczego testu. Jako moŝliwe operacje do wykonania, musi istnieć moŝliwość: uruchamianie dowolnego/własnego skryptu lub programu, logowanie zdarzenia, ukazanie okienka z wiadomością, pobieranie oraz uruchamianie instalacji. g. Ma istnieć moŝliwość wskazania czasu oczekiwania na wykonanie akcji naprawczych. h. MoŜliwość wymuszenia instalacji dowolnej aplikacji. i. W wypadku niezgodności własnego systemu, oprogramowanie musi umoŝliwić zaaplikowanie dowolnego innego zestawu konfiguracji, w szczególności polityki firewallowej (zdefiniowanej bardzo restrykcyjnie), polityki antywirusowej, polityki pobierania aktualizacji, polityki kontroli uruchamianych aplikacji i polityki kontroli urządzeń. j. Musi być moŝliwe, nieuwzględnianie wyniku poszczególnego testu na wynik końcowy integralności komputera. k. Musi istnieć moŝliwość stwierdzenia, Ŝe na komputerze znaleziono zagroŝenie i nie moŝna było takiego zagroŝenia usunąć na ten czas komputer powinien znaleźć się w kwarantannie. l. Musi istnieć test integralności komputera, który sprawdzi czy komputer nie jest podłączony do Internetu poprzez dwie róŝne drogi, np. poprzez kabel sieciowy i poprzez dostęp mobilny. 6) Centralna konsola zarządzająca dla stacji roboczych i serwerów plikowych a. Centralna instalacja, konfiguracja w czasie rzeczywistym, zarządzanie, raportowanie i administrowanie oprogramowaniem z pojedynczej konsoli. b. Centralna aktualizacja ochrony antywirusowej, zapory ogniowej i systemu wykrywania włamań przez administratora sieci. c. Produkt ma wykrywać i raportować nieautoryzowane zmiany w konfiguracji produktu na stacji roboczej. Ma istnieć moŝliwość blokowania takich zmian. d. Produkt ma zapewniać zarządzanie poprzez konsolę. Dostęp do konsoli ma być moŝliwy po wcześniejszej weryfikacji uŝytkownika. Produkt ma mieć moŝliwość definiowania wielu kont administracyjnych i niezaleŝną konfigurację uprawnień. e. MoŜliwość definiowania wielu niezaleŝnych organizacji na jednym serwerze zarządzającym informacje dostarczone do serwera zarządzającego nie będą dostępne pomiędzy organizacjami. f. Integracja z Microsoft Active Directory w celu importu uŝytkowników, listy maszyn, struktury jednostek organizacyjnych. g. Konta administracyjne mają być tworzone na poziomie serwerów zarządzających i na poziomie organizacji definiowanych na serwerze. h. Uprawnienia administratorów mają być ustawiane niezaleŝnie dla kaŝdego kontenera wewnątrz organizacji. i. MoŜliwość utworzenia administratorów z uprawnieniami tylko do odczytu.
j. Uwierzytelnianie administratorów ma się odbywać w oparciu o wewnętrzną bazę danych lub z uŝyciem Microsoft Active Directory. Produkt ma mieć moŝliwość wykorzystania wielo-elementowego uwierzytelniania (np. z wykorzystaniem tokenów, certyfikatów itp.) k. Dostęp do interfejsu produktu i listy funkcji dostępnych dla uŝytkownika ma być konfigurowany z poziomu centralnej konsoli zarządzającej. l. Konfiguracja aktywna na stacji ma rozróŝniać lokalizację agenta i według tego kryterium określać stosowany zestaw reguł/polityk dla agenta. m. Lokalizacja ma być określana według istnienia lub nieistnienia: typu interfejsu sieciowego, numeru MAC domyślnej bramki, adresu IP, zakresu podsieci, komunikacji z serwerem zarządzającym, nazwy domeny, adresów serwerów WINS, DNS, DHCP, wyniku zapytania do serwera DNS. n. Paczki instalacyjne produktu mają pozwalać na dodanie własnej konfiguracji. o. W paczce instalacyjnej musi być zawarta funkcjonalność deinstalacji innych produktów bezpieczeństwa, która uruchomi się automatycznie przed instalacją produktu. p. Pełna funkcjonalność ma być zawarta w jednym pliku instalacyjnym. q. Nowe wersje oprogramowania mają być automatycznie dystrybuowane na stacje robocze w postaci róŝnicy między aktualnie zainstalowaną wersją na kliencie a nową wersją oprogramowania. r. Produkt ma automatycznie wykrywać wszystkie urządzenia przyłączone do sieci komputerowej. s. MoŜliwość zdefiniowania alertów administracyjnych zawierających zdarzenia: błędnej autoryzacji do systemu zarządzania, dostępności nowego oprogramowania, pojawienia się nowego komputera, zdarzeń powiązanych z infekcjami wirusów, stanu serwerów zarządzających. t. Pełna polska wersja językowa oprogramowania dla systemu zarządzania i stacji klienckich wraz z dokumentacją. 7) Ochrona antywirusowa, antyspamowa oraz filtrowanie treści dla serwerów poczty smtp a. licencja pozwalająca uruchomić w środowisku wirtualnym VMware. b. Integracja z LDAP: Active Directory, OpenLDAP 2.x. c. Zintegrowane rozwiązanie antywirusowe, antyspamowe i filtrowania treści. d. Praca, jako bramka pocztowa. e. Blokowanie spamu w oparciu o lokalne polityki, silnik skanujący i bazy. Poczta nie jest przekierowana na serwer usługodawcy. f. Rozwiązanie antyspamowe ma mieć skuteczność nie mniejszą niŝ 98%. Równocześnie rozwiązanie ma charakteryzować się współczynnikiem fałszywych alarmów na poziomie 1 na milion, potwierdzonym przez niezaleŝne testy. g. Do wykrywania spamu, system ma wykorzystywać bazy o numerach IP lub nazwach domen wykorzystywanych przez spamerów. h. System ma zapewnić routing wiadomości pocztowych w oparciu o domenę i adres odbiorcy. i. System ma mieć moŝliwość zmiany domeny i nazwy uŝytkownika w wiadomości przychodzącej i wychodzącej dla odbiorcy i nadawcy odpowiednio dla ruchu przychodzącego i wychodzącego. j. System ma umoŝliwiać tworzenie aliasów dla grup uŝytkowników. k. System ma zapewnić dopisywanie domyślnej nazwy domeny dla nadawcy wiadomości.
l. System ma zapewnić ochronę przed skanowaniem serwera pocztowego w poszukiwaniu istniejących (prawidłowych) adresów pocztowych. m. Usuwanie nagłówków Received z wysyłanych wiadomości. n. Wiadomości z systemów próbujących atakować spamem serwer pocztowy, mają być automatycznie odrzucane przez określony czas, jeśli zostanie przekroczona wartość graniczna (ilość wiadomości zaklasyfikowanych, jako spam z jednego IP w danym przedziale czasu). o. Wiadomości z systemów próbujących atakować wirusami serwer pocztowy, mają być automatycznie odrzucane przez określony czas, jeśli zostanie przekroczona wartość graniczna (ilość wiadomości zaklasyfikowanych, jako wirusy z jednego IP w danym przedziale czasu). p. Połączenia z systemów próbujących atakować spamem serwer pocztowy, mają być automatycznie odrzucane przez określony czas, jeśli zostanie przekroczona wartość graniczna (ilość wiadomości zaklasyfikowanych, jako spam z jednego IP w danym przedziale czasu). q. Administrator ma mieć moŝliwość definiowania domen i adresów pocztowych, z którymi wymiana wiadomości będzie się zawsze odbywać. r. Administrator ma mieć moŝliwość definiowania domen i adresów pocztowych, z którymi wymiana wiadomości będzie zawsze blokowana. s. NiezaleŜnie konfigurowane polityki dla wiadomości przychodzących i wychodzących. t. Funkcja ograniczająca dostępne pasmo dla maszyn/domen przesyłających spam, ale nieblokująca w całości komunikacji z tymi maszynami/domenami. u. Aktualizacje sygnatur spamu nie rzadziej, niŝ co 10 min. v. Aktualizacje sygnatur antywirusowych nie rzadziej, niŝ co 2 godziny. w. Skaner antywirusowy ma skanować skompresowane załączniki do 10 poziomów zagnieŝdŝeń w głąb i ma być odporna na złośliwie spreparowane załączniki ( załączniki bomby ). x. Wiadomości z wirusami typu mass-mailer mają być w całości odrzucane, bez podejmowania dodatkowych akcji takich jak np. powiadomienie. y. Wykrywanie fałszywych URL-i w wiadomościach. z. Wykorzystanie technologii znakowania załączników dla odróŝnienia ich treści. aa. Wykorzystanie technologii analizy html mających na celu przeciwdziałanie metodom utrudniającym analizę treści wiadomości (np.: losowo generowane ciągi, nieprawidłowe kody formatujące). bb. Detekcja języka, w którym została napisana wiadomość i moŝliwość uŝycia tej informacji, jako kryterium przy przetwarzaniu wiadomości. cc. Kontrola treści w oparciu o słowa kluczowe lub słowniki definiowana przez administratora, w tym sprawdzanie zawartości skompresowanych archiwów. dd. Zaawansowane mechanizmy tworzenia reguł kontroli treści, wiązanie wymagań przy pomocy logicznych I i LUB, moŝliwość budowanie reguł w postaci negatywnej NIE. ee. MoŜliwość dodawania do wysyłanych wiadomości zdefiniowanego tekstu. ff. Nakładanie polityk na załączniki w oparciu o ich rozmiar, typ MIME, nazwa pliku lub jego rozszerzenie w tym identyfikację prawdziwego rozszerzenia pliku. gg. Wiadomości sklasyfikowane, jako spam moŝna: usunąć, dodać nagłówek wiadomości, zmodyfikować dodać informację dla odbiorcy, zarchiwizować, wyczyścić - jeśli wiadomość zawierała wirusa, dostarczyć bez modyfikacji, przekierować na inny adres pocztowy, zmodyfikować temat wiadomości, wrzucić wiadomość do centralnej kwarantanny, usunąć załącznik z wiadomości.
hh. Wsparcie dla Transport Layer Security (TLS) definiowane per domena lub polityka, Sender Policy Framework (SPF), Sender ID. ii. Import bazy uŝytkowników poprzez LDAP. jj. Administrator ma mieć moŝliwość ingerencji w czułości rozwiązania. kk. Rozwiązanie ma posiadać serwer kwarantanny. Serwer ma być dostępny dla poszczególnych uŝytkowników końcowych. Serwer ma przesyłać okresowe powiadomienia o zawartości kwarantanny. Powiadomienia mają mieć wbudowane mechanizmy do zarządzania zawartością kwarantanny (przesłanie dalej, podgląd, zalogowanie do kwarantanny). ll. Na serwer kwarantanny moŝna nałoŝyć ograniczenia dla poszczególnych uŝytkowników jak i całego serwera wg ilości przechowywanych wiadomości, ilości zajętego miejsca. mm. Komunikacja pobierania uaktualnień ma być szyfrowana. nn. Komunikacja w celu zarządzania systemem ma być szyfrowana. oo. Rozwiązanie ma być centralnie zarządzane z wbudowanymi mechanizmami raportowania. pp. System ma umoŝliwiać tworzenie wielu kont administracyjnych z róŝnymi poziomami uprawnień, w tym moŝliwość zdefiniowania uŝytkowników mających dostęp do róŝnych kwarantann. qq. System ma powiadamiać wybranych administratorów o nieprawidłowej pracy komponentów. rr. System ma umoŝliwiać wykonywanie zaplanowanych kopii bezpieczeństwa konfiguracji i baz kwarantanny oraz moŝliwość odtworzenia konfiguracji z tak wykonanej kopii. ss. System ma umoŝliwiać graficzne śledzenie wiadomości, w tym informacje, co stało się z wiadomością, tt. System ma posiadać wewnętrzną bazę reputacji, śledzącą adresy IP serwerów pocztowych. uu. System ma umoŝliwiać zapytanie o adres IP do wewnętrznej i globalnej bazy reputacji. vv. System ma mieć moŝliwość zdefiniowania osobnej kwarantanny dla poczty naruszającej reguły zgodności z polityką określającą rodzaj przesyłanych treści. ww. System musi umoŝliwiać skorzystania z predefiniowanych polityk i wzorców. xx. System ma posiadać ochronę przed atakami wirusów typu Day Zero, oraz zdefiniowaną kwarantannę dla złapanych w ten sposób wirusów z moŝliwością ustawienia czasu, przez który zatrzymane maile mają w niej pozostawać. yy. System musi umoŝliwiać wysyłkę źle sklasyfikowanych wiadomości typu spam do producenta, gdzie automatycznie zostaną przygotowane sygnatury antyspamowe i natychmiast dostarczone do rozwiązania. zz. System musi wspierać autentykację SMTP. II. Wymagania minimalne dotyczące wdroŝenia. 1) Czas wdroŝenia nowego systemu musi zakończyć się najpóźniej w 10 dniu roboczym od daty podpisania umowy i objąć wszystkie niŝej wymienione zadania. 2) Wszystkie prace, które będą wykonywane u Zamawiającego muszą być realizowane w godzinach pracy Zamawiającego. 3) Wykonawca dokona analizy wykorzystywanego przez Zamawiającego systemu Symantec Protection Suite Enterprise Edition 4.0. Analiza musi
obejmować minimum: architekturę funkcjonalną wdroŝonego systemu, lokalizację wszystkich klientów oraz ich liczbę, systemy operacyjne na których funkcjonują agenci. Analiza ta zostanie wykorzystana do odtworzenia wszystkich obecnie wdroŝonych funkcjonalności i polityk bezpieczeństwa w zaoferowanym rozwiązaniu. 4) Wykonawca dokona deinstalacji obecnie wykorzystywanego systemu ochrony na wszystkich serwerach i wszystkich stacjach roboczych o ile jest wymagana. W przypadku wystąpienia problemów podczas deinstalacji, ich rozwiązanie będzie naleŝeć do Wykonawcy. Jednocześnie musi zostać zachowana pełna i prawidłowa funkcjonalność zainstalowanych innych aplikacji i systemów na danej stacji roboczej lub serwerze. 5) Wykonawca dokona instalacji agentów systemu na wszystkich stacjach roboczych i serwerach objętych ochroną. W przypadku wystąpienia problemów podczas instalacji, ich rozwiązanie będzie naleŝeć do Wykonawcy. Jednocześnie musi zostać zachowana pełna i prawidłowa funkcjonalność zainstalowanych innych aplikacji i systemów na danej stacji roboczej lub serwerze. 6) W urzędzie Miasta Łodzi funkcjonuje około 2300 stacji roboczych w ponad 24 lokalizacjach na terenie miasta Łodzi. 7) Obecnie wykorzystywane rozwiązanie musi funkcjonować do czasu pełnego wdroŝenia zaoferowanego rozwiązania. W związku z tym, nie będzie moŝliwe wykorzystanie obecnie dedykowanych serwerów zarządzających dla nowego rozwiązania. 8) Zamawiający posiada infrastrukturę serwerową, która umoŝliwia uruchomienie w środowisku wirtualnym, 4 serwerów. 2 serwery na platformie VMware ESXi oraz 2 serwery na platformie Microsoft Hyper-v 2012 o następujących parametrach: a. Maksymalna wielkość pamięci RAM dla kaŝdego serwera - 4 GB. b. Maksymalna wielkość przestrzeni dyskowej - 50 GB. c. Maksymalna ilość VCPU 2 szt. 9) Wykonawca przeprowadzi szkolenie dla min 6 osób w zakresie zarządzania systemem. Szkolenie musi zostać przeprowadzone zgodnie z zaleceniami dotyczącymi szkoleń, w zakresie czasu i tematyki zalecanej przez producenta zaoferowanego rozwiązania. Szkolenie musi być przeprowadzone nieodpłatnie na terenie miasta Łodzi. 10) Wykonawca przygotuje dokumentację powdroŝeniową, która będzie obejmować co najmniej: a. Architekturę wdroŝonego systemu. b. WdroŜone polityki bezpieczeństwa. 11) W przypadku wypowiedzenia lub zerwania umowy w trakcie realizacji procesu wdroŝenia, Wykonawca zobowiązany jest wykonać wszystkie czynności na własny koszt, które przywrócą środowisko informatyczne Zamawiającego do stanu przed rozpoczęciem procesu wdroŝenia. W przypadku, gdy Wykonawca nie wykona tych czynności, Zamawiający wykona niezbędne prace z wykorzystaniem firm trzecich a kosztami tych prac obciąŝy Wykonawcę.