Opis przedmiotu zamówienia CZĘŚĆ 1

Transkrypt

1 Opis przedmiotu zamówienia CZĘŚĆ 1 Poz. Szczegółowa specyfikacja technicznych, funkcjonalnych i użytkowych wymagań Zamawiającego Oferowane przez Wykonawców produkty muszą posiadać parametry nie gorsze niż wskazane poniżej przez Zamawiającego A. Serwer: I. Wymagania ogólne: 1. Zamawiający oczekuje dostawy rozwiązania ochrony poczty elektronicznej, które docelowo po rozbudowie o dodatkowe elementy w przyszłości będzie realizować następujące funkcje: 1) ochronę przed szkodliwą treścią (m.in. malware, wirusy etc.), 2) ochronę przed spamem, 3) filtrowanie treści przesyłanej w poczcie elektronicznej (w tym załączniki), 4) ochronę przed utratą informacji wrażliwych (wbudowany system DLP). 2. Rozwiązanie musi umożliwiać kontrolę protokołu SMTP w tym szyfrowane wersje tego protokołu: SSL i TLS. 3. System musi zapewniać filtrowanie poczty przychodzącej i wychodzącej, przy czym musi istnieć możliwość przypisana odrębnych polityk dla każdego z kierunków przesyłania poczty elektronicznej. 4. System musi zapewniać ochronę dla komunikacji z wykorzystaniem protokołu IPv4 i IPv6. 5. Rozwiązanie musi pracować jako gateway dla poczty elektronicznej (jako MTA - Mail Transfer Agent). Ilość Stawka VAT II. Architektura rozwiązania 1. Rozwiązanie musi być dedykowanym MTA (Mail Transfer Agent) pracującym w trybie bramy dla ruchu przychodzącego z możliwością rozbudowy o opcję bramy dla ruchu wychodzącego. 2. System musi umożliwiać tworzenie klastrów w trybie active-active z rozkładem obciążenia. 3. System musi składać się z co najmniej dwóch redundantnych urządzeń potrafiących pracować zarówno w trybie aktywny-zapasowy jak i aktywny-aktywny bez dodatkowych licencji wymaganych do uruchomienia tych funkcjonalności. 4. Rozwiązanie musi wspierać protokoły SMTP, ESMTP, Secure SMTP over TLS, jako protokoły Mail Injection i Mail Delivery 5. System operacyjny musi posiadać specjalnie zaprojektowany mechanizm do obsługi I/O, zoptymalizowany do obsługi poczty elektronicznej. 6. Konfiguracja urządzenia musi być możliwa przez: 1) Interfejs Web: HTTP i HTTPS 2) CLI: SSH i telnet 3) API umożliwiające odczytanie z systemu co najmniej następujących informacji: a) Bieżące parametry określające status systemu. 1 szt. 0 % Strona 1 z 7

2 b) Zbiorowe zestawienia z określonego okresu co najmniej o przychodzących wiadomościach (również wychodzących, jeżeli system zostanie rozbudowany) oraz o zdarzeniach bezpieczeństwa. c) Raporty typu Top-N z zestawieniem określonych zdarzeń z określonego okresu 7. Urządzenie musi wspierać następujące mechanizmy kryptograficzne: 1) TLS: 56-bit DES, 168-bit 3DES, 128-bit RC4, 128-bit AES i 256-bit-AES 2) DomainKeys Signing: 512-, 768-, 1024-, i 2048-bit RSA III. IV. Definiowanie polityk 1. System zarządzania politykami musi umożliwiać wielokrotne wykorzystywanie w regułach predefiniowanych elementów takich jak filtry i akcje 2. System musi umożliwiać definiowanie co najmniej następujących akcji (w ramach polityki): 1) dostarczenie wiadomości z wykonaniem dodatkowych akcji: a) zmodyfikowanie tematu przesyłki b) usunięcie i/lub dodanie nagłówka X-header c) wysłanie kopii wiadomości pod wskazany adres lub adresy 2) zablokowanie wiadomości 3) zapisanie wiadomości do wskazanej kolejki 4) wysłanie powiadomienia, 3. System musi umożliwiać budowanie polityk i wyjątków od polityk, obejmujących wszystkie funkcjonalności produktu, niezależnie dla ruchu wychodzącego i przychodzącego z zastosowaniem co najmniej: 1) domen 2) obiektów z Microsoft AD 3) adresów pojedynczych użytkowników 4. System musi umożliwiać tworzenie odrębnych polityk i wyjątków dla różnych użytkowników 5. System musi umożliwiać tworzenie dedykowanych polityk dla tzw. greymail (wiadomości, które nie są kwalifikowane jako spam); dla takich wiadomości musi istnieć możliwość ich jednoznacznego znakowania. System powinien umożliwiać bezpieczne wypisanie z subskrypcji bezpośrednio przez użytkownika. System ochrony antyspamowej 1. System powinien posiadać rozbudowane narzędzia zapobiegania przesyłaniu wiadomości klasyfikowanych jako SPAM do serwera pocztowego. W tym celu system musi zapewniać mechanizmy ochrony oparte co najmniej o: 1) Sygnatury 2) Słowniki 3) Heurystykę, dla której musi być możliwa regulacja czułości (kontrola ilości False-Positives) 2. System musi posiadać wbudowane mechanizmy metody wykrywania wiadomości komercyjnych typu Newsletters i umożliwiać traktowanie tych wiadomości w zależności od ustalonej polityki organizacji jako SPAM lub jako wiadomość dopuszczona Strona 2 z 7

3 3. System musi zapewnić opcję definiowania wyjątków od stosowanych polityk 4. Mechanizm antyspamowy musi być realizowany dwufazowo. 1) Pierwsza faza musi opierać się na sprawdzeniu reputacji adresu IP nadawcy w ogólnoświatowej bazie reputacji, która musi posiadać następujące parametry: a) Musi otrzymywać dane z co najmniej źródeł danych z całego świata b) Musi analizować co najmniej 150 parametrów dotyczących ruchu poczty elektronicznej i protokołu WWW (w tym co najmniej 90 dla poczty) c) Musi zwracać wynik reputacji dla adresu IP w skali co najmniej 20-stopniowej czyli np. od -10 do 10 d) System zwraca rezultat reputacji jedynie na podstawie zbieranych danych, nie dopuszczając jednorazowych interwencji ze strony wysyłających pocztę mających na celu manualne podwyższenie ich reputacji. e) System musi umożliwiać wykorzystanie, co najmniej dwóch systemów badania reputacji nadawców dla poczty przychodzącej. Jeden z nich oparty o publiczne serwisy Real-Time Blackhole List (RBL), drugi musi być systemem własnym producenta zaimplementowanym w rozwiązaniu. 2) Druga faza ma następować jeżeli wiadomość przejdzie pomyślnie fazę pierwszą i musi opierać się silniku antyspamowym, korzystającym z reguł wysyłanych od producenta. 3) Reguły muszą być tworzone dynamicznie na podstawie informacji z co najmniej trzech źródeł: a) ogólnoświatowej bazy danych reputacji o parametrach jak w fazie pierwszej, b) informacji zwrotnych od użytkowników proponowanego rozwiązania c) informacji od dedykowanych analityków bezpieczeństwa pracujących 24h na dobę, 7 dni w tygodniu, 365 dni w roku dla producenta proponowanego rozwiązania. 4) Reguły muszą weryfikować, informację na temat adresów IP pojawiających się w mailach jako linki do stron, strukturę wiadomości, sposób w jaki została wysłana, treść wiadomości i reputację nadawcy. 5) Reguły powinny być uaktualniane, automatycznie, nie rzadziej niż co 5 minut przez internet. 5. System musi posiadać możliwość skorzystania z funkcji reverse DNS lookup do określenia nazwy domeny dla adresu IP nadawcy wiadomości przychodzącej, wykonanie weryfikacji, oraz odrzucenie połączenia w przypadku: 1) braku rekordu PTR w DNS 2) niezgodności nazwy domeny przesłanej w komunikacie SMTP HELO/EHLO z nazwą domeny w rekordzie DNS, 3) niezgodności rekordu reverse DNS (PTR) z rekordem forward DNS (A) 6. System musi umożliwiać weryfikację nadawcy wiadomości w oparciu o mechanizm SPF (Sender Policy Framework) oraz umożliwiać co najmniej: 1) odrzucenie lub przyjęcie wiadomości jeżeli rekord SPF nie istnieje 2) odrzucenie wiadomości jeżeli rekord SPF nie pasuje do domeny nadawcy 7. System musi umożliwiać: 1) monitorowanie i ograniczanie ilości połączeń z jednego adresu IP w określonym przedziale czasu. a) Musi zapewniać opcję definicji przedziału czasowego b) Musi zapewniać opcję ograniczenia maksymalnej ilości połączeń i wiadomości. 2) ograniczanie maksymalnej liczby wiadomości przekazywanych za pomocą pojedynczego połączenia SMTP Strona 3 z 7

4 3) wskazanie limitu czasu (timeout) dla niewykorzystywanego połączenia 8. Rozwiązanie musi pozwalać na blokowanie na określony czas przyjmowania poczty z adresów IP, dla których odnotowano wiadomości zawierające zdefiniowaną liczbę niewłaściwych adresatów z chronionej domeny. V. System ochrony antywirusowej 1. System musi zapewniać blokowanie złośliwej treści z wykorzystaniem tradycyjnego skanowania antywirusowego opartego o komercyjny silnik antywirusowy oraz bazie sygnatur kodów złośliwych 2. Silnik antywirusowy musi korzystać z następujących metod skanowania wiadomości: 1) Dopasowanie wzorców binarnych do sygnatur antywirusowych 2) Analiza heurystyczna 3) Emulacja uruchomienia kodu (w celu zapobiegania infekcji wirusami polimorficznymi) 3. Mechanizm musi mieć do dyspozycji oddzielną od dedykowanej dla spamu, kwarantannę, do której dostęp ma tylko administrator. 4. System musi zapewniać mechanizmy dynamicznej ochrony przed epidemią złośliwego kodu (ang. Outbreak) 1) Mechanizm antywirusowy musi posiadać technologię umożliwiającą automatyczną kwarantannę wiadomości, które pomimo, że nie są wskazane przez powyższe metody skanowania (z powodu np. braku odpowiednich sygnatur antywirusowych), mogą jednak zawierać złośliwy kod. 2) Informacje o takim podejrzeniu powinny być wysyłane przed globalną bazę reputacji, o parametrach opisanych w wymogach modułu antyspamowego. 3) Podejrzane wiadomości powinny pozostać w kwarantannie, aż do wypuszczenia przez producentów silników antywirusowych odpowiednich sygnatur i automatycznie wypuszczane i skanowane ponownie po ściągnięciu odpowiednich sygnatur. VI. Moduł raportujący i zarządzający: 1. System musi posiadać wbudowany moduł zarządzający i raportujący. 2. Dla potrzeb przyszłej rozbudowy musi istnieć możliwość zastosowania osobnego modułu zarządzającego i raportującego, przy czym jego funkcjonalność będzie musiała zostać zachowana co najmniej na poziomie modułu wbudowanego. 3. Rozwiązanie musi być wyposażone w system raportujący, umożliwiający: 1) Generowanie predefiniowanych oraz własnych raportów na żądanie oraz zgodnie z harmonogramem. 2) Harmonogram powinien umożliwiać generowanie raportów codziennie, co tydzień lub co miesiąc. 3) Powinno być możliwe dostarczanie raportów w postaci plików pdf i csv. 4) Powinno być możliwe dostosowanie tematu i treści automatycznie wysyłanego maila zawierającego generowane raporty. 4. Zarządzanie, przeglądanie aktywności użytkowników oraz raportowanie powinny być dostępne przez zintegrowaną webową konsolę administracyjną 5. Dostęp do webowej konsoli zarządzającej powinien odbywać się w bezpiecznym połączeniu HTTPS. Strona 4 z 7

5 6. Konsola zarządzająca powinna zawierać ekran przedstawiający wykres sumarycznej aktywności z ostatnich 24 godzin oraz podstawowe statystki. 7. System powinien udostępniać mechanizm pozwalający na przeglądanie przez chronionych użytkowników wiadomości umieszczonych w kwarantannie, umożliwiając im również zwolnienie wybranych wiadomości z kwarantanny VII. Wymagania sprzętowe 1. Rozwiązanie musi być dedykowanym MTA (Mail Transfer Agent) pracującym w trybie bramy dla ruchu przychodzącego z możliwością rozbudowy o opcję bramy dla ruchu wychodzącego. 2. Rozwiązanie powinno być zrealizowane w postaci dedykowanych urządzeń. 3. Rozwiązanie powinno zapewnić możliwość docelowej obsługi 10 tysięcy skrzynek pocztowych. 4. Proponowane rozwiązanie powinno być posadowione na redundantnych urządzeniach potrafiących pracować zarówno w trybie aktywny-zapasowy jak i aktywny-aktywny bez dodatkowych licencji wymaganych do uruchomienia tych funkcjonalności. 5. System operacyjny musi posiadać specjalnie zaprojektowany mechanizm do obsługi I/O, zoptymalizowany do obsługi poczty elektronicznej. 6. Urządzenia powinny być montowane w szafach rackowych, a wysokość pojedynczego urządzenia nie powinna być większa niż 1U. 7. Urządzenia powinny posiadać co najmniej dwa dyski twarde o pojemności co najmniej 600GB każdy i obsługiwać RAID1 (mirror). 8. Dyski twarde powinny być Hot-swappable 9. Urządzenia powinny być wyposażone w co najmniej 16GB pamięci RAM 10. Urządzenia powinny posiadać redundantne zasilacze. 11. Każde z urządzeń powinno posiadać co najmniej sześć interfejsów 1000Base-T. 12. Proponowane rozwiązanie musi zostać dostarczone z wbudowaną konsolą zarządzającą. VIII. Możliwości rozbudowy systemu o zaawansowaną ochronę antymalware 1. System musi mieć możliwość rozbudowy o mechanizmy zaawansowanej ochrony antymalware 1) Mechanizmy zaawansowanej ochrony antymalware muszą obejmować: a) Sprawdzenie reputacyjne dla plików przesyłanych przez urządzenie b) Kontrolę przesyłanych plików przez mechanizm sandboxingu w chmurze c) Monitorowanie wsteczne dla plików już przesłanych 2) Kontrola reputacji dla plików musi odbywać się w ogólnoświatowej bazie reputacji 3) Kontrola reputacji musi odbywać się na podstawie unikalnych metadanych własnościowych pliku, nie jest dopuszczalne, aby sprawdzenie reputacyjne wymuszało przesłanie pliku na zewnątrz systemu kontroli poczty. 4) Funkcja sandboxingu dla plików przesyłanych pocztą elektroniczną musi być wbudowana w system ochrony poczty, nie jest dopuszczalne stosowanie zewnętrznych systemów firm trzecich. Strona 5 z 7

6 5) Funkcja monitorowania wstecznego musi umożliwiać informowanie administratora o zmianie decyzji dotyczących plików uprzednio przesłanych przez urządzenie. W szczególności dotyczy to sytuacji, gdy we wskazanym pliku wykryto złośliwy kod. 6) Włączenie zaawansowanej ochrony antimalware w przyszłości będzie wiązało się jedynie z wykupieniem odpowiedniej licencji u producenta rozwiązania i jej imporcie w systemie. IX. Możliwość rozbudowy systemu o filtrowanie i kontrolę treści 1. System musi mieć możliwość rozbudowy o filtrowanie i kontrolę treści 1) Kontrola treści wiadomości co najmniej w zakresie: słowa kluczowe, słowniki, wyrażenia regularne, typ załączników 2) Kontrola musi obejmować co najmniej następujące elementy wiadomości: tytuł, treść, nagłówki, adres nadawcy, adres odbiorcy 3) Proponowane rozwiązanie musi posiadać mechanizmy analizy i filtrowania oraz zarządzania treścią wiadomości poczty elektronicznej, zarówno treści samej wiadomości jak i jej załączników. 4) Mechanizm musi mieć możliwość zdefiniowania polityki zarządzania treścią wiadomości w oparciu o wynik reputacji pobrany z bazy reputacji o parametrach opisanych w module antyspamowym. 5) Mechanizm musi mieć możliwość zdefiniowania polityki zarządzania treścią wiadomości w oparciu o wynik uwierzytelnienia DKIM, funkcjonalności opisanej w wymaganiach dotyczących rozbudowy o zastosowanie kryptografii 6) Mechanizm musi mieć możliwość filtrowania treści za pomocą integracji z zewnętrznymi słownikami. 7) System musi umożliwiać zarządzanie kolejkami (folderami) dla blokowanych wiadomości w zakresie zarządzania predefiniowanymi oraz tworzenia nowych. 8) System powinien zawierać moduł DLP umożliwiający identyfikację chronionych informacji z użyciem mechanizmów: słowa kluczowe, słowniki, wyrażenia regularne oraz właściwości przesyłanych plików takie jak prawdziwy typ pliku, jego nazwa lub rozmiar 9) System musi zapewniać kwarantannę dla zablokowanych wiadomości. Dla kolejki kwarantanny musi być możliwe zdefiniowanie jej maksymalnej wielkości oraz czasu, po którym wiadomości będą usuwane 10) Rozbudowa filtrowania i kontroli treści musi się wiązać co najwyżej z wykupieniem odpowiedniej licencji u producenta rozwiązania i jej imporcie w systemie. X. Możliwość rozbudowy systemu o funkcje kryptograficzne i uwierzytelniające 1. System musi mieć możliwość rozbudowy o funkcje kryptograficzne i uwierzytelnienia 1) Rozwiązanie musi posiadać mechanizmy oznaczania poczty wychodzącej (Bounce Address Tag Validation (BATV)) oraz weryfikacji tego oznaczenia w przypadku otrzymania wiadomości odbitej od odbiorcy (tzw. bounce) w celu ochrony przed atakami typu misdirected bounce spam 2) Rozwiązanie musi obsługiwać standard DKIM (Domain Keys Identified Messages) używany w celu uwierzytelnienia poczty, za pomocą szyfrowania asymetrycznego. 3) Rozwiązanie musi umożliwiać opcjonalnie, oddzielnie licencjonowane, szyfrowanie symetryczne poczty dla Strona 6 z 7

7 wybranych wiadomości, wykonywane bez potrzeby jakiejkolwiek ingerencji w klienta pocztowego oraz bez potrzeby implementacji PKI. Rozwiązanie powinno udostępniać szyfrowanie za pomocą algorytmów AES oraz RC4. 4) Rozbudowa o funkcje kryptografii i uwierzytelnienia musi się wiązać co najwyżej z wykupieniem odpowiedniej licencji u producenta rozwiązania i jej imporcie w systemie. XI. Możliwość rozbudowy systemu o dodatkowe funkcjonalności 1. System musi mieć możliwość rozbudowy o drugi komercyjny silnik antywirusowy z własną bazą sygnatur, przy czym silnik ten będzie uruchomiony na tym samym urządzeniu, a uruchomienie będzie wiązało się jedynie z wykupieniem i zaimportowaniem odpowiedniej licencji 2. System musi mieć możliwość rozbudowy o dedykowany scentralizowany moduł do zarządzania politykami i raportowania. B. Licencje do serwera z Poz. A: Licencje dla ochrony 1000 skrzynek pocztowych na 1 rok (z możliwością przedłużenia) na następujące funkcjonalności: 1) Antyspam, 2) Antywirus z wykorzystaniem silnika komercyjnego, 3) Antiwirus z obsługą ochrony przed epidemią złośliwego kodu 1 komplet 23% Strona 7 z 7