Przejdź do treści
← Wróć do listy
RozstrzygniętyPrzetarg nieograniczony · PN588351-2026

Dostawa i uruchomienie systemu NDR do zabezpieczenia sieci szpitala – Elbląg

Składanie ofert: 1 października 2026 · Wartość szacunkowa: 1 121 154 zł · Wadium: 11 200 zł

Rozstrzygnięcie

Kto wygrał, za ile i ilu było chętnych.

NIP zwycięzcy5921474043
Kwota oferty1 213 308,73 zł
Złożonych ofert1

Przedmiot zamówienia

AI

Zamówienie jednoczęściowe — dostawa, instalacja, konfiguracja i uruchomienie kompletnego rozwiązania klasy NDR (Network Detection and Response) do zabezpieczenia sieci wewnętrznej szpitala (w tym bezprzewodowej). W zakres:

  • 2 fizyczne węzły platformy sprzętowo-programowej NDR (1U, serwerowe, do montażu w szafie Rack 19", po jednym w serwerowni A i B);
  • 2 przełączniki sieciowe (1U, 48 portów 1G/10G Base-T + porty optyczne/wieloprędkościowe, do połączenia w stos);
  • 136 modułów SFP+ 10 Gb/s (jednomodowe, LC);
  • komplet okablowania światłowodowego i miedzianego oraz przewodów zasilających;
  • wszystkie wymagane licencje (rozwiązanie, aktualizacje, mechanizmy detekcyjne, AI/ML, modele analityczne, warstwa wirtualizacyjna, integracje) na okres minimum 60 miesięcy;
  • licencje integracyjne (m.in. z Active Directory, ESET Inspect, EDR, SIEM/Syslog);
  • elementy montażowe, akcesoria, szyny Rack, organizacja kabli;
  • pełna instalacja, konfiguracja, integracja z istniejącą infrastrukturą (Active Directory, ESET Inspect, przełączniki rdzeniowe i dystrybucyjne Zamawiającego, sieć bezprzewodowa), testy odbiorowe;
  • dokumentacja powykonawcza (diagram logiczny i fizyczny, wykaz połączeń, protokoły testów, opis zachowania przy awarii węzłów);
  • szkolenie warsztatowe administratorów Zamawiającego.

Rozwiązanie ma monitorować co najmniej 1400 adresów IP, analizować ruch wschód–zachód oraz północ–południe, pokrywać ≥90% technik MITRE ATT&CK i integrować się z posiadanym systemem zarządzania siecią Extreme Networks XIQ-SE v24.1 oraz środowiskiem ESET Inspect.

Trudność: wysoka

Złożone wdrożenie klasy enterprise NDR obejmujące dedykowaną platformę sprzętowo-programową w dwóch serwerowniach, rozbudowaną topologię mirroringu ruchu, integracje z AD, EDR i systemem zarządzania siecią, dużą liczbę modułów optycznych i wymagania dotyczące pokrycia MITRE ATT&CK, co wymaga doświadczonego zespołu i precyzyjnej koordynacji.

Terminy realizacji

Termin realizacji zamówienia
od dnia zawarcia umowy maksymalnie do 10.11.2026 r.
Okres licencji / aktualizacji / wsparcia NDR
min. 60 miesięcy od dnia podpisania końcowego protokołu odbioru bez zastrzeżeń
Wymagany okres gwarancji
min. 60 miesięcy (kryterium oceny: 72 mies. = 10 pkt, ≥ 84 mies. = 20 pkt; 60 mies. = 0 pkt)

Warunki udziału

AI
1Doświadczenie — min. 2 dostawy z wdrożeniem rozwiązań bezpieczeństwa sieci o łącznej wartości ≥ 1 000 000 zł brutto, z ostatnich 3 lat (Załącznik nr 4)

Kryteria wyboru oferty

AI

Wagi punktowe, według których zamawiający oceni oferty.

Cena oferty bruttonajniższa cena 100 pkt, wzór Cn/Cb × 100
60%
Termin gwarancji84+ mies.=20 pkt, 72 mies.=10 pkt, 60 mies.=0 pkt
40%

Czerwone flagi

AI

Sygnały, na które warto zwrócić uwagę przed startem.

Brak istotnych sygnałów ostrzegawczych.

Kary i sankcje

AI
  • Wadium: 11 200,00 zł (przelew na PKO BP S.A. Oddział w Elblągu nr 33 1020 1752 0000 0102 0006 3727, z dopiskiem „Wadium – nr postępowania 28/2026").
  • Formy wadium: pieniądz, gwarancja bankowa, gwarancja ubezpieczeniowa, poręczenie z art. 6b ust. 5 pkt 2 ustawy o PARP.
  • Kary umowne: w projekcie umowy sprzedaży (zał. nr 10 do SWZ).

Pytania i odpowiedzi

15

Wyodrębnione z wyjaśnień treści SWZ.

1Punkt 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ń.
2Punkt 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ń.
3Punkt 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ń.
4Punkt 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ń.
5Punkt 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ń.
6Punkty 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ń.
7Punkty 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.
8Punkty 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.
9Punkty 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.
10Punkty 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.
11Dotyczy 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.
12VII. 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
13Pytanie 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.
14Pytania 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.
15Pytanie 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.

Historia zmian

26.08.2026 — ogłoszenie o zamówieniu
17.09.2026 — sprostowanie
01.10.2026 — upływ terminu składania ofert
21.10.2026 — rozstrzygnięcie