Dostawa subskrypcji Infoblox Threat Defense
Przedmiot zamówienia
AI| Dostawa subskrypcji systemu Infoblox Threat Defense albo dostawy, wdrożenia i konfiguracji rozwiązania równoważnego, obejmującego zarządzanie usługami DNS, DHCP i IPAM, wykrywanie urządzeń sieciowych, raportowanie, ochronę DNS oraz bezpieczne rozwiązywanie nazw DNS z dostępem do danych o zagrożeniach dla 1800 użytkowników. - Dostawa/usługa: subskrypcje, licencje i dostęp do usług dla systemu składającego się z 6 maszyn wirtualnych i 1 usługi SaaS na 36 miesięcy albo wdrożenie rozwiązania równoważnego obejmujące migrację danych i konfiguracji, testy, dokumentację powdrożeniową oraz szkolenie dla 12 administratorów (16 godzin). - Usługa: pakiet 144 godzin wsparcia technicznego dla systemu przez 36 miesięcy.
Trudność: średnia
Zamówienie obejmuje odnowienie lub wdrożenie zintegrowanego systemu DNS/DHCP/IPAM i bezpieczeństwa DNS dla 1800 użytkowników wraz z wieloletnim wsparciem, co wymaga doświadczenia i koordynacji.
Terminy realizacji
Termin realizacji umowy
37 miesięcy (dostawa/wdrożenie do 14 dni od zawarcia umowy; wsparcie 36 mies.)
37 miesięcy (dostawa/wdrożenie do 14 dni od zawarcia umowy; wsparcie 36 mies.)
Warunki udziału
AI1Zdolność techniczna/zawodowa — Certyfikat ISO/IEC 27001 lub równoważny z niezależnej jednostki certyfikującej; albo udokumentowany, wdrożony i stosowany system zarządzania bezpieczeństwem informacji obejmujący co najmniej politykę bezpieczeństwa, analizę ryzyka, zarządzanie dostępem, procedury incydentów, zarządzanie podatnościami/aktualizacjami oraz bezpieczeństwo usług teleinformatycznych; w konsorcjum warunek spełnia wykonawca realizujący dostawę, konfigurację, wdrożenie, utrzymanie lub wsparcie techniczne.
Kryteria wyboru oferty
AIWagi punktowe, według których zamawiający oceni oferty.
Cena brutto za całość zamówienia
100%
Czerwone flagi
AISygnały, na które warto zwrócić uwagę przed startem.
Brak istotnych sygnałów ostrzegawczych.
Kary i sankcje
AI- Wadium: 50 000,00 zł — pieniądz, gwarancje bankowe/ubezpieczeniowe, poręczenia; rachunek PKO BP 34 1020 3147 0000 8602 0090 2411 (dopisek „Wadium – OZP.26.1.71.2026.KBA").
- Gwarancja wadium: termin obowiązywania ≥ termin związania ofertą.
- Kary umowne: w projekcie umowy (Załącznik nr 3).
Pytania i odpowiedzi
13Wyodrębnione z wyjaśnień treści SWZ.
1pkt II.A.2.40, II.D.4 ppkt 3.40 i II.E.6.1 OPZ: wykrywanie tunelowania DNS z zamkniętym katalogiem cech
DNS Guardian wykrywa tunelowanie i wyciek danych behawioralnie, w czasie rzeczywistym; rezultat podlega weryfikacji testem akceptacyjnym z OPZ.
1A5. Uwaga: Wybór i waga cech stanowią część metody wykrywania stosowanej przez dostawcę. Ich narzucenie wyklucza model, który wykrywa te same ataki innymi cechami lub analizą kontekstową. Zamawiający przewidział miarodajny test akceptacyjny (ok. 1000 zapytań zakodowanych heksadecymalnie co ok. 2 sekundy) – to on powinien rozstrzygać o zgodności. Dowód: DNS Guardian zapewnia kontrolę transakcji w czasie rzeczywistym i behawioralne wykrywanie tunelowania DNS i wycieku danych. Dowody nr 2 i 14.
Zastąpić wskazane punkty tekstem (pozostawiając test akceptacyjny): „System musi wykrywać i blokować tunelowanie DNS oraz wyciek danych przez DNS, w tym wcześniej nieznane wzorce, przy użyciu analizy behawioralnej, uczenia maszynowego, heurystyki lub innej skutecznej metody analitycznej, niezależnie od kategorii treści domeny. System nie może opierać się wyłącznie na sygnaturach znanych narzędzi. Zgodność zostanie zweryfikowana testem akceptacyjnym opisanym w OPZ, obejmującym skuteczność wykrycia, czas reakcji i zastosowane środki zaradcze. Wewnętrzny zestaw cech wykorzystywanych przez algorytm nie jest narzucony.”
2pkt II.C OPZ: katalog raportów i wydzielona maszyna wirtualna raportowa
DNS Guardian udostępnia statystyki trafień w pamięć podręczną, kodów odpowiedzi, opóźnień, typów zapytań i listy najaktywniejszych klientów i domen bez osobnej maszyny wirtualnej.
2A6. Uwaga: Odwołanie do konkretnej rodziny złośliwego oprogramowania pochodzi z materiałów produktu referencyjnego. Potrzebą jest wykrywanie i blokowanie przesyłu danych w odpowiedziach DNS (w szczególności TXT), niezależnie od nazwy kampanii. Wymóg powinien być weryfikowalny scenariuszem testowym, a nie deklaracją marketingową. Dowód: DNS Guardian analizuje transakcje DNS w czasie rzeczywistym, wykrywa anomalie w zapytaniach i odpowiedziach i blokuje domeny złośliwe na podstawie danych o zagrożeniach. Dowód nr 2.
Zastąpić wskazane punkty tekstem: „System musi wykrywać i blokować próby przesyłania danych do sieci Zamawiającego zakodowanych w odpowiedziach DNS, w szczególności w rekordach TXT, z wykorzystaniem analizy behawioralnej, danych o zagrożeniach lub innej skutecznej metody. Zgodność może zostać zweryfikowana scenariuszem testowym uzgodnionym w ramach odbioru.”
3pkt II.E.1.1 – 1.2.1 OPZ: usługa SaaS z publicznym adresem IP
DNS Guardian realizuje rekurencję i egzekwowanie polityk lokalnie; dla użytkowników poza siecią integruje się z Cisco Umbrella.
3A7. Uwaga: Wymóg odpowiada funkcji File Distribution w Infoblox NIOS (TFTP, FTP, HTTP). Dystrybucja plików nie jest funkcją DNS, DHCP ani IPAM i nie wynika z opisu przedmiotu zamówienia. Zamawiający nie wskazuje, do czego jej używa (np. PXE, konfiguracje telefonów IP). Udostępnianie plików przez nieszyfrowane FTP i HTTP z urządzeń DNS jest ponadto sprzeczne z zasadą minimalizacji usług na urządzeniach infrastruktury krytycznej (§ 6a IPU, NIS2). Dowód: Dowód nr 10.
Zastąpić pkt II.A.3.5 i II.D.5.6 tekstem: „System musi oferować usługi synchronizacji czasu za pomocą protokołu NTP. Jeżeli Zamawiający wykorzystuje dystrybucję plików (np. TFTP dla PXE), Wykonawca zapewni ją w ramach oferowanego rozwiązania lub odrębnej usługi, przy zastosowaniu bezpiecznych protokołów tam, gdzie jest to możliwe.”
4Wymaganie wszystkich trzech protokołów jest wymaganiem katalogowym. TFTP nie zapewnia uwierzytelnienia ani szyfrowania, a FTP przesyła dane jawnie, choć kopie systemu DDI zawierają pełną konfigurację DNS, DHCP i IPAM oraz dane uwierzytelniające. Wymóg jest sprzeczny z § 6a ust. 4 IPU (ochrona kryptograficzna danych przesyłanych poza infrastrukturę Zamawiającego) i z wymaganiami NIS2. SOLIDserver DDI umożliwia planowane kopie zapasowe na serwer zewnętrzny z użyciem protokołów bezpiecznych.
Dowód nr 1
§ 6a ust. 4 IPU
Zastąpić pkt II.A.3.14 i II.D.5.15 tekstem:
„System musi umożliwiać wykonywanie planowanych kopii bezpieczeństwa do zewnętrznego serwera z wykorzystaniem protokołu zapewniającego uwierzytelnienie i szyfrowanie transmisji (np. SCP, SFTP, HTTPS) oraz odtwarzanie konfiguracji z kopii.”
5pkt II.B.2.7 – 2.8 – rezerwacja interfejsu sieciowego oraz „uruchomienie nowej sieci IP łącznie z definicją domyślnej bramy, VLAN – przynajmniej na przełącznikach Cisco”
Sformułowanie odpowiada funkcji port control i provisioning sieci w Infoblox Network Insight, realizowanej jako jedna operacja. Potrzebą jest skoordynowane uruchomienie nowej sieci: rezerwacja adresacji w IPAM, utworzenie VLAN, konfiguracja portów i bramy z kontrolą uprawnień i audytem. Wymóg realizacji wszystkich kroków jednym mechanizmem nie jest konieczny do osiągnięcia tego rezultatu. NetChange wykrywa przełączniki i routery (CDP, LLDP, SNMP), prezentuje porty, VLAN, adresy MAC i IP oraz VRF i automatyzuje konfigurację przełączników szablonami (VLAN, trunk, access, 802.1x, opis i stan portu), z delegowaniem uprawnień, kopiami i wersjonowaniem konfiguracji.
Dowody nr 8 i 11
Zmienić pkt II.B.2.8 w następujący sposób:
„System musi umożliwiać uruchomienie nowej sieci IP, obejmujące co najmniej rezerwację adresacji w IPAM, utworzenie i przypisanie VLAN oraz konfigurację portów na przełącznikach Cisco, z kontrolą uprawnień i rejestrowaniem zmian. Konfiguracja bramy domyślnej może być realizowana szablonem konfiguracji, skryptem lub integracją z narzędziami Zamawiającego za pośrednictwem API.”
6pkt II.C.1.1, 2.1 i 2.3 – podsystem raportowania w formie 1 maszyny wirtualnej, przetwarzający min. 500 MB danych dziennie, z zamkniętym katalogiem raportów (m.in. „DHCP Top Lease Clients”, „DHCP Message Rate Trend”, „Trend trafień w bufor DNS (Cache Hit Ratio)”)
Katalog raportów jest tłumaczeniem raportów Infoblox Reporting & Analytics (część nazw pozostawiono w języku angielskim). Wydzielona maszyna wirtualna i wolumen 500 MB dziennie, z zamkniętym katalogiem raportów (m.in. „DHCP Top Lease Clients”, „DHCP Message Rate Trend”, „Trend trafień w bufor DNS (Cache Hit Ratio)”) odpowiadają architekturze i licencjonowaniu tego produktu. Potrzebą jest dostęp do określonych informacji (bezpieczeństwo, wydajność DNS i DHCP, wykorzystanie adresacji, obciążenie systemu). Nazwy raportów i miejsce ich generowania są cechą produktu, a pkt II.C.2.4 (raporty definiowane przez użytkownika) pozwala uzyskać te same dane w inny sposób. DNS Guardian zapewnia statystyki współczynnika trafień w pamięć podręczną, kodów odpowiedzi, opóźnień, typów zapytań oraz listy najaktywniejszych klientów i domen.
Dowody nr 2 i 12
Zastąpić pkt II.C.1.1 i wprowadzenie do pkt II.C.2.3 tekstem:
„Funkcje raportowania mogą być realizowane w dedykowanej maszynie wirtualnej, w systemie zarządzającym lub w zintegrowanym systemie SIEM. Rozwiązanie musi zapewniać informacje odpowiadające co do zakresu danych raportom wymienionym w pkt 2.3, przy czym dopuszcza się inne nazwy, układ i sposób prezentacji raportów oraz ich realizację za pomocą raportów definiowanych przez użytkownika. Wykonawca wskaże w ofercie mapowanie raportów wymaganych na raporty oferowane.”
7B1. pkt II.E.1.1 – 1.2.1 (Fragment Kryteriów Równoważności): implementacyjnym. Wymaganymi rezultatami są: bezpieczne rozwiązywanie nazw, egzekwowanie polityk, dostępność, kontrola danych i raportowanie. Wymóg modelu SaaS z publicznym resolwerem wyklucza lokalne i hybrydowe rozwiązania bezpiecznego DNS, nie wskazując rezultatu, który mogłoby zapewnić wyłącznie przetwarzanie zewnętrzne. Lokalny resolwer ogranicza ponadto przekazywanie danych o zapytaniach pracowników poza infrastrukturę Zamawiającego (§ 6a ust. 4 IPU). Dowody nr 1 i 2
Rozwiązanie powinno zapewniać rekursywne rozwiązywanie nazw DNS dla domen internetowych wraz z kontrolą bezpieczeństwa. Funkcje te mogą być realizowane w infrastrukturze dostawcy (SaaS), w infrastrukturze kontrolowanej przez Zamawiającego lub w architekturze hybrydowej, pod warunkiem że Wykonawca wykaże wymagane wyniki w zakresie bezpieczeństwa, dostępności, wydajności, lokalizacji danych, rejestrowania zdarzeń oraz wsparcia technicznego. W przypadku resolwera dostępnego publicznie musi istnieć możliwość ograniczenia akceptowanych adresów źródłowych.
8B2. pkt II.E.1.2.2 lit. a – b: „wirtualny serwer DNS forwarding proxy zaimplementowany w sieci wew. Zamawiającego jako maszyna Vmware”, dodający do zapytań prywatny adres IP i adres MAC komputera i przesyłający je przez DoT lub DoH. Sformułowanie odpowiada modelowi DNS Forwarding Proxy (DFP) Infoblox: lokalne proxy, zachowanie kontekstu klienta i szyfrowane przekazanie zapytań do platformy chmurowej Infoblox. Inni producenci stosują Relay (DNSFilter), urządzenie wirtualne (Cisco Umbrella VA) lub punkt usługowy (BlueCat Edge Service Point), z różnymi kombinacjami platform, atrybucji klientów i transportu. Lokalny resolwer egzekwuje politykę bez etapu proxy do chmury – widzi prywatny adres IP klienta natywnie, a adres MAC może pochodzić z korelacji z DHCP/IPAM. Alternatywny projekt wykorzystuje lokalny resolwer DNS Guardian oraz, w razie potrzeby, frontend DoH z identyfikacją klienta w EDNS. Dowody nr 7, 17, 25, 26, 30 i 31
Ruch DNS z sieci wewnętrznej może być obsługiwany przez serwer proxy, serwer przekazujący, lokalny resolwer lub zintegrowaną bramę bezpieczeństwa DNS działającą na platformie VMware Zamawiającego. Komponent ten powinien zachowywać atrybucję źródła (prywatny adres IP, a w razie potrzeby adres MAC) poprzez adres źródłowy, EDNS, korelację z DHCP/IPAM lub inną niezawodną metodę. Ruch DNS przechodzący przez sieć publiczną lub niezaufaną powinien wykorzystywać DoT, DoH lub inny zaakceptowany bezpieczny protokół. Oferta powinna określać liczbę instancji aktywnych i rezerwowych oraz ich pojemność.
9B4. pkt II.E.2.2 – blokowanie: wymóg „przy pomocy odpowiedzi NXDomain”; „Każda z tych trzech akcji musi mieć możliwość odnotowania jej podjęcia w logach lub nieodnotowywania”; strona przekierowania „udostępniona przez dostawcę”. NXDOMAIN, konkretny rekord przekierowania oraz selektywne wyłączanie rejestrowania to wybory wdrożeniowe odpowiadające akcjom reguł Infoblox Threat Defense. Efektem bezpieczeństwa jest skuteczne egzekwowanie, czytelna informacja dla użytkownika i dowody podlegające audytowi. Obowiązkowa możliwość rezygnacji z rejestrowania zdarzeń bezpieczeństwa może być sprzeczna z celami audytowymi i obowiązkami wynikającymi z KSC i NIS2. Client Query Filtering obsługuje zezwalanie, blokowanie i środki zaradcze przez centralnie zarządzane reguły, listy i tagi, aktualizowane przez GUI, API i standardowe mechanizmy DNS. Dowody nr 3 i 19.
Zastąpić pkt II.E.2.2 tekstem: „Polityka bezpieczeństwa powinna obsługiwać zezwalanie, blokowanie i przekierowanie (adres IP lub CNAME), sinkhole lub inne działania o równoważnej funkcjonalności. Blokowanie może wykorzystywać NXDOMAIN, NODATA, odpowiedź sinkhole lub inny obsługiwany mechanizm DNS. Rozwiązanie może rejestrować wszystkie zdarzenia związane z polityką, pod warunkiem że administratorzy mogą je filtrować, raportować, eksportować i stosować reguły retencji. Konfigurowalna strona blokady może być hostowana przez producenta, Wykonawcę, Zamawiającego lub inną upoważnioną usługę.”
Historia zmian
27.10.2026 — publikacja ogłoszenia