TEDCPV 32000000 · Sprzęt radiowy i telekomunikacyjnyCPV 48000000 · Pakiety oprogramowania Warmińsko-Mazurskie Termin: 1 października 2026
Dostawa i instalacja platformy NDR dla sieci szpitalnej – Elbląg
Pełna nazwa postępowania: „Zabezpieczenie sieci wewnętrznej szpitala, w tym bezprzewodowej - dostawa, instalacja, konfiguracja i uruchomienie kompletnego rozwiązania klasy Network Detection and Response (NDR), obejmującego dwa fizyczne węzły platformy sprzętowo-programowej, dwa przełączniki sieciowe, wymagane licencje i aktualizacje na okres minimum 60 miesięcy, moduły optyczne, komplet okablowania oraz wszystkie pozostałe
Wojewódzki Szpital Zespolony w Elblągu·NIP 5782517492·Elbląg
Wartość szac.
1 121 154 zł
wg ogłoszenia
Termin składania
01.10.2026
za 1 dni
Otwarcie ofert
—
nie podano
Opublikowano
17 września 2026
źródło: TED
Streszczenie SWZ
Streszczenie AI · Janusz
Widzisz połowę każdej z 10 sekcjiDruga połowa — łącznie 13 zdań z warunkami, dokumentami i analizą ryzyka — odsłania się po założeniu darmowego konta.
Doświadczenie: co najmniej 2 dostawy z wdrożeniem rozwiązań bezpieczeństwa sieci o wartości łącznej ≥ 1 000 000 zł brutto w ciągu ostatnich 3 lat (z podaniem wartości, przedmiotu, daty, miejsca i podmiotu + referencje lub oświadczenie).
7
Kryteria oceny ofert
Pełna treść
Cena oferty brutto: waga 60% – punktacja 0–100, najniższa cena = 100 pkt, wzór Px=Cn×100/Cb - Termin gwarancji: waga 40% – 84 mies. ≥20 pkt, 72 mies. =10 pkt, 60 mies. =0 pkt
8
Kary i sankcje
Pełna treść
Wadium:11 200,00 zł (poręczenie/gwarancja lub pieniądz).
9
Inne zapisy
Widoczne 50%
Podwykonawstwo: dopuszczone; wskazać w ofercie części i nazwy podwykonawców; nie zwalnia z odpowiedzialności.
Zmiana umowy: dopuszczana w zakresie wzoru; wymaga formy pisemnej; naruszenie art. 454/455 Pzp → unieważnienie.
Z każdej z 10 sekcji pokazujemy połowę. Załóż darmowe konto, żeby odsłonić pozostałe 13 zdań — pełne warunki udziału, dokumenty i analizę ryzyka Janusza. Bez karty, 14 dni za darmo.
Wyjaśnienia treści SWZ udzielone przez zamawiającego. Odpowiedzi wiążą wszystkich wykonawców — także tych, którzy nie zadali pytania.
Punkt 99 - Czy Zamawiający dopuszcza, aby system zachowywał informację o przynależności ruchu do sieci VLAN na poziomie metadanych sesji (np. VLAN ID widoczny w kontekście detekcji lub ruchu hosta), a nie jako parsowany nagłówek enkapsulacji wewnątrz silnika analitycznego?
Zamawiający w treści OPZ nie narzuca sposobu wewnętrznego przetwarzania ani reprezentacji nagłówków VLAN przez silnik analityczny rozwiązania i uzna powyższy sposób realizacji wymagania za spełnienie wymagań.
Punkt 144 - Czy Zamawiający dopuszcza, aby wykrywanie podejrzanych transferów dużej ilości danych było realizowane jako element modelu behawioralnego eksfiltracji, w którym anomalia wolumenu jest wyznaczana relatywnie do wyuczonego profilu danego hosta i korelowana z innymi sygnałami (pkt 145–147 OPZ), a nie jako samodzielny detektor oparty na sztywnym, globalnym progu wolumenu?
Zamawiający w treści OPZ nie narzuca stosowania odrębnego detektora opartego na jednym, sztywnym i globalnym progu wolumenu danych i uzna powyższy sposób realizacji wymagania za spełnienie wymagań.
Punkt 151 - Czy Zamawiający dopuszcza, aby wykrywanie aktywności botnetowej związanej ze skanowaniem było realizowane przez korelację dwóch niezależnych modeli detekcyjnych – wykrywania aktywności botnetowej (w tym beaconing, C2) oraz wykrywania skanowania sieci (szybkiego i wolnego, w tym skanów RPC, SMB, LDAP – pkt 138–143 OPZ) – jako jednego scenariusza zagrożenia, a nie jako osobnego, dedykowanego detektora „botnet scanning"?
Zamawiający w treści OPZ nie narzuca istnienia pojedynczego, odrębnego detektora noszącego nazwę „botnet scanning”, pod warunkiem że zastosowane mechanizmy pozwalają na identyfikację takiego scenariusza zagrożenia i powiązanie występujących zachowań z konkretnym hostem. Zamawiający uzna powyższy sposób realizacji wymagania za spełnienie wymagań.
Punkt 152 - Czy Zamawiający dopuszcza, aby wykrywanie aktywności botnetowej związanej z atakami DDoS było realizowane przez identyfikację cech charakterystycznych dla infrastruktury botnetowej stanowiącej podłoże ataku DDoS (np. wzorce beaconing, C2, koordynowany ruch masowy z wielu hostów), a nie jako wykrywanie samego wolumenu ataku DDoS na warstwie L3/L4?
Zamawiający w treści OPZ nie narzuca wykrywania samego wolumenu ataku DDoS na warstwie L3/L4. Zamawiający uzna powyższy sposób realizacji wymagania za spełnienie wymagań.
Punkt 202 - Czy Zamawiający dopuszcza, aby polityka retencji była realizowana przez pojemność platformy dostarczonej w ramach zamówienia oraz przez automatyczne usuwanie najstarszych danych po osiągnięciu dostępnej pojemności, a nie przez osobne, konfigurowalne w interfejsie systemu ustawienie okresu i algorytmu retencji?
Zamawiający w treści OPZ nie narzuca sposobu realizacji polityki retencji jako osobne, konfigurowalne w interfejsie systemu ustawienie okresu i algorytmu retencji. Zamawiający uzna powyższy sposób realizacji wymagania za spełnienie wymagań.
Punkty 263, 267, 269–271 - Czy Zamawiający dopuszcza realizację integracji z ESET Inspect (pkt 263) – systemem opartym na konsoli chmurowej – wyłącznie przez interfejs API (pkt 267), bez konfiguracji w GUI systemu NDR, przy czym wzbogacanie hostów i kontekstu zagrożeń (pkt 269–270) realizowane jest przez własne mechanizmy identyfikacji NDR (pkt 245–262, 280–283 OPZ), a powiązanie urządzenia w NDR z urządzeniem w ESET Inspect (pkt 271) – przez wspólne identyfikatory (IP, nazwa hosta) w procesie reakcji?
Zamawiający nie narzuca w OPZ bezpośredniej dwukierunkowej synchronizacji wszystkich informacji opisujących host pomiędzy systemem NDR i ESET Inspect, o ile zastosowany sposób integracji umożliwia jednoznaczne lub wystarczające do wykonania reakcji powiązanie hosta wykrytego przez NDR z hostem obsługiwanym przez ESET Inspect. Zamawiający uzna powyższy sposób realizacji wymagania za spełnienie wymagań.
Punkty 272–277 - Czy Zamawiający dopuszcza realizację ręcznej (pkt 272) i automatycznej (pkt 273) izolacji hosta przez zautomatyzowany proces (SIEM/SOAR), w którym detekcja/decyzja z NDR wywołuje izolację przez API konsoli ESET Inspect, z konfigurowalnością warunków i możliwością wyłączenia (pkt 274–276) po stronie NDR oraz z wykorzystaniem czasowej izolacji (pkt 277) o ile funkcjonalność ESET Inspect ją umożliwia?
Zamawiający w treści OPZ nie narzuca, aby wszystkie elementy logiki reakcji były implementowane bezpośrednio wewnątrz systemu NDR. Zamawiający dopuszcza wskazane sposoby realizacji wymagania. Funkcja ręcznej lub automatycznej izolacji hosta może być realizowana poprzez zautomatyzowany proces reakcji wykorzystujący interfejsy API systemu NDR oraz ESET Inspect, w tym z wykorzystaniem systemu SIEM, SOAR, skryptu lub innego komponentu automatyzującego.
Punkty 272–277 - Czy Zamawiający dopuszcza realizację ręcznej (pkt 272) i automatycznej (pkt 273) izolacji hosta przez zautomatyzowany proces (SIEM/SOAR/skrypt), w którym: - system NDR wystawia interfejs API udostępniający dane detekcji i stanu hostów, - proces reakcji (SIEM/SOAR/skrypt) odczytuje dane z NDR i wywołuje izolację przez API konsoli chmurowej ESET Inspect, - warunki uruchamiania izolacji, jej wyłączenie oraz czas trwania (pkt 274–277) są konfigurowane po stronie procesu reakcji, a nie wewnątrz systemu NDR?
Zamawiający w treści OPZ nie narzuca, aby wszystkie elementy logiki reakcji były implementowane bezpośrednio wewnątrz systemu NDR. Zamawiający dopuszcza wskazane sposoby realizacji wymagania. Funkcja ręcznej lub automatycznej izolacji hosta może być realizowana poprzez zautomatyzowany proces reakcji wykorzystujący interfejsy API systemu NDR oraz ESET Inspect, w tym z wykorzystaniem systemu SIEM, SOAR, skryptu lub innego komponentu automatyzującego.
Punkty 278–279 - Czy Zamawiający dopuszcza realizację pkt 278 przez integrację z infrastrukturą sieciową (blokada ruchu na warstwie sieciowej poprzez publikację listy IoC) w alternatywie do integracji z konsolą chmurową ESET Inspect?
Zamawiający w treści OPZ dopuszcza proponowane rozwiązanie i nie ogranicza sposobu realizacji tej funkcjonalności, a proponowana blokada ruchu na warstwie sieciowej jest jednym z oczekiwanych sposobów realizacji.
Punkty 308-311 - Czy Zamawiający dopuszcza realizację pkt 308–311 w następujący sposób: eksport dzienników audytowych (pkt 311) – przez przesyłanie do zewnętrznego zbieracza (SIEM) za pomocą protokołu syslog?
Zamawiający w treści OPZ dopuszcza proponowane rozwiązanie i nie ogranicza sposobu realizacji tej funkcjonalności, a proponowane przesyłanie do zewnętrznego kolektora logów jest jednym z oczekiwanych sposobów realizacji powyższej funkcjonalności.
Dotyczy Rozdziału VI ust. 2 SWZ (Termin wykonania zamówienia). Zamawiający określił w SWZ termin wykonania zamówienia jako: „VI. TERMIN WYKONANIA ZAMÓWIENIA 2. Termin realizacji zamówienia: od dnia zawarcia umowy maksymalnie do dnia 10.11.2026 r.
Zamawiający zmienia termin realizacji na 27.11.2026.
VII. WARUNKI UDZIAŁU W POSTĘPOWANIU 2. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy spełniają warunki dotyczące: ……… 4) zdolności technicznej lub zawodowej: Wykonawca spełni warunek, jeżeli wykaże, że w okresie ostatnich trzech lat przed upływem terminu składania ofert, a jeśli okres prowadzenia działalności jest krótszy – w tym okresie, wykonał: co najmniej 2 dostawy z wdrożeniem rozwiązań bezpieczeństwa sieci o wartości łącznej co najmniej 1 000 000 zł brutto. Pytanie: Zwracamy się do Zamawiającego o wyjaśnienie, czy przez wdrożenie rozwiązań bezpieczeństwa sieci rozumie również wdrożenie urządzeń sieciowych, jak ma to miejsce w niniejszym postępowaniu obejmującym również dostawę i wdrożenie przełączników sieciowych? Infrastruktura aktywna sieci jest nieodzownym elementem systemów bezpieczeństwa sieci i umożliwia integrację różnych rozwiązań w obrębie bezpieczeństwa.
Zamawiający nie akceptuje dostawy i wdrożenia samych przełączników sieciowych jako spełnienia warunków zdolności technicznej lub zawodowej. Zamawiający wyjaśnia, że przez „dostawę z wdrożeniem rozwiązań bezpieczeństwa sieci
Pytanie dotyczące węzła sprzętowego NDR. W wymaganiach dotyczących dysków systemowych w serwerze, Zamawiający wskazał: 342. Każdy węzeł musi posiadać co najmniej dwa nośniki SSD NVMe o pojemności minimum 960 GB każdy. Pytanie: Ze względu na bardzo ograniczoną dostępność dysków NVMe na rynku, czy Zamawiający dopuści dyski SATA SSD jako dyski systemowe? Według najlepszej wiedzy Oferenta, różnica wydajności dysków SSD NVMe względem SSD SATA w zastosowaniach pod instalację systemów operacyjnych lub silników hypervisor'ów nie ma istotnego znaczenia, a zatem oferowane rozwiązanie nie będzie miało negatywnego wpływu na parametry funkcjonalne.
Zamawiający akceptuje dyski SSD w dowolnej technologii i zmienia treść Opisu Przedmiotu Zamówienia.
Pytania dotyczące przełączników sieciowych.
Pytanie 4.1: Dot. „510. Przełącznik musi posiadać możliwość obsługi IS-IS.
Zamawiający dopuszcza proponowane rozwiązanie i zmienia treść Opisu Przedmiotu Zamówienia.
Pytanie 4.2: Dot. „524. Jeżeli PIM-DM lub PIM-SSM wymaga dodatkowej licencji, licencja musi zostać dostarczona w ramach zamówienia.
Zamawiający dopuszcza proponowane rozwiązanie i zmienia treść Opisu Przedmiotu Zamówienia.
