Zwiększenie cyberodporności i ciągłości działania Miejskiego Zakładu Gospodarki

Zamawiający nie potwierdza zarzutu i nie znajduje podstaw do unieważnienia postępowania w tym zakresie. Opis przedmiotu zamówienia w Zadaniach 9, 11, 12 i 21 określa wymagania funkcjonalne i wydajnościowe, a nie konstrukcję ani architekturę wewnętrzną urządzenia. Konwergencja funkcji ochrony sieci (inspekcja pakietów, IDS/IPS, kontrola aplikacyjna, elementy routingu i przełączania, stanowa inspekcja ruchu) w ramach jednej platformy sprzętowej jest od lat standardem rynkowym klasy NGFW/NDR/UTM, oferowanym przez wielu niezależnych producentów działających na rynku europejskim, w tym w segmencie rozwiązań dedykowanych sieciom przemysłowym/OT jak i IT. Wymóg ten nie wskazuje zatem na jednego, konkretnego dostawcę, lecz opisuje funkcjonalność niezbędną do zapewnienia ciągłości działania infrastruktury wodociągowej – to znaczy zdolność jednoczesnego wykrywania, klasyfikowania i – tam, gdzie to uzasadnione – blokowania zagrożeń bez tworzenia kolejnych, odrębnych punktów awarii w sieci OT. Zamawiający nie jest zobowiązany – ani na gruncie Rozdziału 3 ust. 10 SWZ, ani na gruncie zasad Zasady Konkurencyjności – do wskazywania konkretnych modeli lub producentów spełniających wymagania OPZ. Takie wskazanie prowadziłoby do efektu odwrotnego niż zamierzony przez pytającego, tj. do związania opisu przedmiotu zamówienia ze znakami towarowymi konkretnych produktów. Kryteria równoważności wynikają z parametrów funkcjonalnych i wydajnościowych określonych w OPZ (Rozdział 3 ust. 10 i 14 SWZ), a ciężar wykazania spełnienia tych parametrów – niezależnie od architektury oferowanego rozwiązania – spoczywa na wykonawcy składającym ofertę, zgodnie z Rozdziałem 3 ust. 14 SWZ.

Zamawiający podtrzymuje wymóg i nie znajduje podstaw do jego uchylenia ani do unieważnienia postępowania. Po pierwsze, wymóg dotyczy komponentów pracujących na styku sieci IT/OT lub bezpośrednio zabezpieczających sieć OT/ICS przedsiębiorstwa wodociągowo-kanalizacyjnego, a nie „urządzeń IT” w oderwaniu od ich funkcji. Norma IEC 62443-4-2 opisuje wymagania bezpieczeństwa dla komponentów systemów automatyki i sterowania niezależnie od tego, czy komponent formalnie klasyfikowany jest jako „IT”, czy „OT” – decydujące znaczenie ma rola pełniona w architekturze stref i kanałów komunikacyjnych (zgodnie z koncepcją zoning/conduit opisaną w serii IEC 62443, do której odwołuje się OPZ). Skoro Zadania 9, 11, 12 i 21 dotyczą urządzeń chroniących styk sieci technologicznej i biorą bezpośredni udział w segmentacji i ochronie sieci OT, poziom asekuracji tych komponentów musi odpowiadać profilowi ryzyka środowiska OT, a nie środowiska biurowego. Po drugie, dobór poziomu SL4 nie jest decyzją arbitralną, lecz wynika z oceny profilu zagrożeń właściwego dla infrastruktury krytycznej dostarczającej wodę pitną, potwierdzanego konsekwentnie przez CERT Polska, CSIRT-y sektorowe oraz instytucje unijne jako jeden z priorytetowych celów zorganizowanych i sponsorowanych kampanii ataków na infrastrukturę krytyczną. Od 3 kwietnia 2026 r. obowiązuje ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa, implementująca dyrektywę NIS2, która kwalifikuje przedsiębiorstwa zaopatrujące w wodę pitną jako podmioty kluczowe krajowego systemu cyberbezpieczeństwa i nakłada na kierownika takiego podmiotu – niezależnie od odpowiedzialności samej spółki – bezpośrednią, osobistą odpowiedzialność administracyjną za nadzór nad wdrożeniem adekwatnych środków bezpieczeństwa (art. 8c oraz art. 73a tej ustawy). W tym stanie prawnym przyjęcie poziomu zabezpieczeń niższego niż uzasadniony rzeczywistym ryzykiem nie byłoby wyrazem otwartości na konkurencję, lecz świadomym obniżeniem standardu bezpieczeństwa usługi kluczowej. Po trzecie, zasada proporcjonalności nie oznacza obowiązku dostosowania wymagań do możliwości najsłabiej przygotowanej części rynku, lecz obowiązek adekwatności wymagań do przedmiotu i celu zamówienia. Certyfikacja w standardzie IEC 62443-4-2 jest procesem otwartym i dostępnym dla każdego producenta, a liczba certyfikowanych komponentów systematycznie rośnie wraz z wdrażaniem NIS2 w całej Unii Europejskiej. Ewentualny brak certyfikatu po stronie oferty konkretnego dostawcy jest okolicznością leżącą po stronie podaży rynkowej, a nie wadą opisu przedmiotu zamówienia. Zamawiający wyjaśnia jednocześnie, że dopuszcza – zgodnie z Rozdziałem 3 ust. 10 i 14 SWZ – wykazanie równoważnego poziomu asekuracji bezpieczeństwa również w drodze innych dowodów niż formalny certyfikat SL4 wystawiony przez akredytowaną jednostkę oceny zgodności, o ile wykonawca jednoznacznie wykaże w ofercie, że oferowane komponenty spełniają wymagania techniczne odpowiadające…

Zamawiający nie potwierdza sprzeczności. Zapisy OPZ dla Zadań 9, 11 i 12 (oraz analogicznych pozycji OPZ) opisują dwa odrębne, uzupełniające się elementy licencyjne, typowe dla współczesnych platform bezpieczeństwa sieciowego: ● licencję (lub komplet licencji) na oprogramowanie/funkcjonalność podstawową urządzenia – wymaganą w trybie wieczystym (bezterminowym), bez obowiązku jej okresowego odnawiania w celu zachowania podstawowej funkcjonalności urządzenia; ● subskrypcje na usługi z natury swej okresowe (m.in. aktualizacje sygnatur zagrożeń, IoC dla threat intelligence, wsparcie chmurowe, bazy reputacyjne) – które w całej branży bezpieczeństwa sieciowego są dostarczane w modelu subskrypcyjnym, niezależnie od modelu licencjonowania samego oprogramowania bazowego; dla tych elementów Zamawiający określił jedynie minimalny wymagany okres ważności, tj. do daty zakończenia programu dofinansowania. Nie jest to zatem alternatywa („licencja wieczysta albo subskrypcja”), lecz koniunkcja – licencja wieczysta obejmuje funkcjonalność podstawową urządzenia, a subskrypcja obejmuje elementy usługowe, które ze swej natury nie występują w obrocie w modelu bezterminowym. Taki model jest jednoznacznie opisany w OPZ i nie pozostawia wykonawcy wątpliwości co do zakresu wyceny: wykonawca wycenia komplet licencji wieczystych funkcjonalności podstawowej oraz subskrypcje ważne minimum do końca okresu kwalifikowalności wydatków w programie. Zamawiający nie znajduje w powyższym podstaw do unieważnienia postępowania. Jeżeli jednak w toku postępowania okaże się, że konkretny zapis OPZ rodzi wątpliwość interpretacyjną, Zamawiający rozważy doprecyzowanie tego zapisu w trybie Rozdziału 6 ust. 8 SWZ, co nie stanowi wady nieusuwalnej.

Zamawiający podtrzymuje wymóg struktury modularnej dla urządzeń aktywnych sieci montowanych w szafach rack 19”, wskazanych w OPZ i nie znajduje podstaw do unieważnienia postępowania. Potrzeba funkcjonalna jest następująca: producent zobowiązany jest zapewnić dostępność wsparcia i cyklu życia produktu do 2032 r. (OPZ, wymagania ogólne dla sprzętu), a urządzenie ma pełnić funkcję platformy bezpieczeństwa obsługującej rosnące w czasie obciążenie ruchem sieciowym oraz liczbę chronionych segmentów sieci IT/OT. Konstrukcja umożliwiająca rozbudowę interfejsów (np. dodanie kart portów, modułów redundancji zasilania) bez wymiany całego urządzenia pozwala: (i) uniknąć przerwy w ochronie sieci OT przy rozbudowie infrastruktury w toku wieloletniej eksploatacji, (ii) racjonalnie gospodarować środkami z dofinansowania, unikając konieczności zakupu nowego urządzenia w całości przy każdej zmianie skali sieci, oraz (iii) zachować redundancję zasilania wymaganą dla urządzeń o znaczeniu krytycznym dla ciągłości monitoringu bezpieczeństwa. Modularna budowa sprzętu montowanego w szafach rack (możliwość wymiany/rozbudowy kart interfejsów, zasilaczy redundantnych) jest rozwiązaniem oferowanym przez wielu producentów urządzeń sieciowych klasy enterprise, nie jest więc cechą właściwą wąskiej grupie linii produktowych jednego dostawcy. Zamawiający opisuje w tym zakresie potrzebę funkcjonalną (rozszerzalność i redundancja w horyzoncie eksploatacji do 2032 r.), a nie konkretne rozwiązanie konstrukcyjne jednego producenta, w związku z czym nie znajduje podstaw do rezygnacji z tego wymogu.

Zamawiający nie potwierdza, że opis przedmiotu zamówienia w Zadaniach 33 i 34 wskazuje na jedno, konkretne rozwiązanie producenckie, i nie znajduje podstaw do unieważnienia postępowania w tym zakresie. Nazwy funkcjonalności wymienione w OPZ (m.in. IPS/IDS, OT Anomaly Detection, Threat Detection, Data Traceability Control, SDN, Anti-DDoS, Anti-APT, SIEM, SOAR, XDR, Central FW Management) opisują kategorie funkcjonalne powszechnie występujące w rozwiązaniach klasy przemysłowy IDS/UTM/UTM/SIEM dostępnych na rynku, nie zaś zastrzeżone nazwy handlowe jednego produktu. Zamawiający nie posługuje się w opisie tych zadań nazwami handlowymi ani znakami towarowymi konkretnego producenta. Zgodnie z Rozdziałem 3 ust. 10 SWZ Zamawiający dopuszcza rozwiązania równoważne opisywanym, a kryterium równoważności stanowi realizacja wskazanych funkcjonalności w zakresie i na poziomie jakościowym nie gorszym niż opisany w OPZ – niezależnie od nazewnictwa handlowego stosowanego przez poszczególnych producentów dla analogicznych mechanizmów ochronnych. Zamawiający nie ma obowiązku wskazywania konkretnych modeli lub producentów spełniających łącznie wymagania Zadań 33 i 34, gdyż takie wskazanie byłoby sprzeczne z zasadą neutralności technologicznej opisu przedmiotu zamówienia. Ciężar wykazania równoważności – w tym poprzez dokumentację techniczną, karty katalogowe lub deklaracje producenta potwierdzające realizację danej funkcjonalności – spoczywa na wykonawcy, zgodnie z Rozdziałem 3 ust. 14 SWZ. Jeżeli wykonawca wskaże konkretny zapis OPZ, którego brzmienie w jego ocenie nie pozwala na jednoznaczne powiązanie z funkcą (a nie z nazwą handlową), Zamawiający rozważy doprecyzowanie opisu w trybie Rozdziału 6 ust. 8 SWZ. Sama obszerność listy wymaganych funkcjonalności nie stanowi jednak wady nieusuwalnej postępowania.