Wymagania w zakresie bezpieczeństwa. Numer wymagania Opis wymagania
Wymagania w zakresie bezpieczeństwa. System musi być wyposażony w środki ochrony spełniające wymagania klasy C2 (zgodnie z dokumentem Trusted Computer System Evaluation Criteria), praca przez Internet musi wykorzystywać bezpieczny protokół transmisji danych/szyfrowanie połączeń, system musi zapewnić bezpieczeństwo przetwarzania danych osobowych zgodnie z ustawą z dnia 10 maja 2018 r. o ochronie danych osobowych oraz Rozporządzeniem Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych, system musi wymuszać by hasło składało się z co najmniej 8 znaków, zawierało małe i wielkie litery oraz cyfry lub znaki specjalne, system powinien zablokować czasowo dostęp do konta po 5 nieudanych próbach zalogowania. system powinien wyświetlić odpowiedni komunikat odnośnie zablokowania konta, system wyświetli ekran umożliwiający zresetowanie hasła powodujący wysłanie wiadomości na adres e-mail przypisany do konta, podczas rejestracji nowego użytkownika system wymusi podanie loginu i hasła użytkownika, przy czym login (nazwa wymyślona przez wnioskodawcę lub adres e-mail) musi być unikatowy w ramach całego systemu, logowanie możliwe jest poprzez podanie loginu oraz wprowadzenie hasła, system uniemożliwi dostęp bez uwierzytelnienia. Zamawiającemu przysługuje prawo przeprowadzenia audytu bezpieczeństwa systemu, a w przypadku stwierdzenia ewentualnych nieprawidłowości Wykonawca zobowiązany jest do ich nieodpłatnego usunięcia w terminie wskazanym przez Zamawiającego.
Wymagania w zakresie bezpieczeństwa. 1. Obowiązkiem Banku jest stosowanie odpowiednich narzędzi kontroli bezpieczeństwa, chroniących systemy i dane w tych systemach przed nieuprawnionym dostępem i wykorzystaniem. Bank ponosi wyłączną odpowiedzialność za odpowiednią ochronę poufności, integralności i dostępności jego systemów.
Wymagania w zakresie bezpieczeństwa. 1.4.1. Radiotelefon musi zapewniać szyfrowanie zgodnie z algorytmem TEA1 i w tym zakresie musi mieć uaktywnione wymagane licencje. Radiotelefon musi być przystosowany do wprowadzenia algorytmu TEA2 poprzez doposażenie w przyszłości w dodatkowy, wewnętrzny moduł i/lub upgrade oprogramowania i/lub zakup licencji (przy czym modyfikacja do szyfrowania zgodnego z algorytmem TEA2 nie jest objęta niniejszym zamówieniem).
Wymagania w zakresie bezpieczeństwa. System EZD musi posiadać zabezpieczenia co najmniej przed następującymi zagrożeniami: Utrata danych w przypadku awarii stacji roboczej. Zabezpieczenie musi zapobiegać utracie danych zgromadzonych i już przekazanych do serwera aplikacji lub bazy danych. Przykładowo, w przypadku uszkodzenia klienckiej stacji roboczej, dopuszcza się jedynie utratę danych/zmian wprowadzanych w momencie awarii tylko na tej stacji. Utrata danych w przypadku awarii serwera aplikacji. Zabezpieczenie musi zapobiegać utracie danych zgromadzonych i już przekazanych do bazy danych poprzez system tworzenia kopii zapasowych. System musi umożliwiać automatyczne tworzenie kopii zapasowych danych na odseparowane od niej pamięci masowe, z częstotliwością zaplanowaną przez administratora (co najmniej raz w tygodniu). Utrata danych lub ich spójności. Zabezpieczenie musi zapobiegać utracie danych lub ich spójności, w tym x.xx. w przypadku jednoczesnej pracy wielu użytkowników z tą samą porcją danych. Utrata globalnego dostępu do aplikacji w przypadku awarii pojedynczej stacji roboczej. Zabezpieczenie musi zapobiegać utracie dostępu do aplikacji wszystkich pozostałych stacji roboczych. Nieuprawniony dostęp do danych i funkcji. Zabezpieczenie musi zapobiegać nieuprawnionemu (a określonemu w konfiguracji uprawnień przez administratora) dostępowi użytkowników do danych i funkcji aplikacji. Wprowadzenie lub uruchomienie złośliwego kodu. Zabezpieczenie musi zapobiegać wprowadzeniu lub uruchomieniu złośliwego kodu w aplikacji. Naruszenie poufności danych. Zabezpieczenie musi zapobiegać utracie poufności danych w odniesieniu do komunikatów przesyłanych między wszystkimi komponentami aplikacji (w szczególności pomiędzy stacjami roboczymi i serwerami) oraz systemami zewnętrznymi. Za wystarczające zabezpieczenie uznaje się wykorzystanie protokołu SSL lub połączenia VPN.
Wymagania w zakresie bezpieczeństwa. Wykonawca musi zagwarantować bezpieczeństwo informacji znajdujących się w portalu. W ofercie przedstawionej przez Wykonawcę musi znajdować się dokładny opis proponowanych rozwiązań w zakresie bezpieczeństwa oraz projekt konfiguracji infrastruktury portalu i sposób zabezpieczenia. System CMS dostarczony przez Wykonawcę musi zapewniać: • poufność – ochrona przed ujawnieniem nieuprawnionemu odbiorcy, • integralność – ochrona przed nieuprawnioną modyfikacją lub zniekształceniem, • dostępność – dostęp do zasobów informacyjnych, • rozliczalność – określenie i weryfikowanie odpowiedzialności za wykorzystanie systemu informacyjnego, • autentyczność – weryfikacja tożsamości podmiotów i prawdziwości zasobów, • niezawodność – gwarancja oczekiwanego zachowania portalu i otrzymywanych wyników. Opracowany przez Wykonawcę portal, przed jego odbiorem końcowym, będzie musiał spełnić wymagania audytu bezpieczeństwa technicznego, według przygotowanych przez Xxxxxxxxxxxxx, scenariuszy testowych. Każda funkcja oprogramowania CMS obsługująca cykl zapytania HTTP musi oczyszczać dane wejściowe przed ich użyciem. Oczyszczanie odbywać się będzie zawsze przez tę samą funkcję, której domyślna konfiguracja oczyszczać będzie dane z wszystkich potencjalnie niebezpiecznych wartości (kod SQL, znaczniki HTML, etc.). W celu pozostawienia np. znaczników HTML w przekazywanym kodzie, funkcja będzie musiała być wywołana explicite z taką opcją. Kod będzie napisany w sposób zabezpieczający przed atakami z sieci, uwzględniając przynajmniej następujące rodzaje ataków: • Code injection [xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxx_xxxxxxxxx], np. SQL injection [xxxx://xx.xxxxxxxxx.xxx/xxxx/XXX_xxxxxxxxx], etc., • XSS ‐ Cross‐site scripting [xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxx‐site_scripting], • CSRF ‐ Cross‐site request forgery [xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxx‐site_request_forgery], • Directory traversal [xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxxxx_xxxxxxxxx], • Session fixation [xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxx_xxxxxxxx], • Session poisoning [xxxx://xx.xxxxxxxxx.xxx/xxxx/Xxxxxxx_xxxxxxxxx].