Wyrok KIO 614/26 z 23 marca 2026

Postępowanie w trybie przetargu nieograniczonego pn. „Dostawa kompleksowych rozwiązań w zakresie wykrywania, prezentacji oraz ochrony przed zagrożeniami w cyberprzestrzeni i skutkami ich wystąpienia na poziomie Uczelni” nr postępowania: AEZ/S028/2025 w zakresie Pakietu nr 1 pn. Dostawa z uruchomieniem narzędzi do zarządzania bezpieczeństwem klasy XDR ogłoszono w Dzienniku Urzędowym Unii Europejskiej 7 listopada 2025 r., pod numerem 738468-2025.

30 stycznia 2026 r. zamawiający poinformował o wyborze oferty najkorzystniejszej.

9 lutego 2026 r. wykonawca Trecom Wrocław Spółka z ograniczoną odpowiedzialnością z siedzibą w Warszawie, ul.

Czyżewska 10 wniósł odwołanie przez należycie umocowanego pełnomocnika. Do odwołania dołączono dowód jego opłacenia oraz przekazania zamawiającemu.

Odwołujący zarzucił zamawiającemu naruszenie:

1. art. 226 ust. 1 pkt 5 ustawy przez zaniechanie odrzucenia oferty niezgodnej z warunkami zamówienia, która to niezgodność polega na tym, że oferowany przez Clockwise system Cortex XDR produkcji Palo Alto Networks nie posiada funkcjonalności lub nie oferuje parametrów spełniających wymagania opisane przez zamawiającego w OPZ; 2.art. 239 ustawy w związku z art. 70 (1) §4 KC w związku art. 8 ust. 1 ustawy przez wybór oferty Clockwise, którą zgodnie z postanowieniem ust. 1 rozdz. XXII specyfikacji warunków zamówienia zamawiający winien był odrzucić jako ofertę, w stosunku do której zachodzą okoliczności, o których mowa w art. 226 ust. 1 ustawy; Wniósł o nakazanie zamawiającemu:
2. unieważnienia czynności wyboru najkorzystniejszej oferty w zakresie Pakietu nr 1 upublicznionej w dniu 30.01.2026 r.; 2.odrzucenia oferty Clockwise w zakresie Pakietu nr 1 jako niezgodnej z warunkami zamówienia; 3.powtórzenia czynności badania i oceny ofert w postępowaniu w zakresie Pakietu nr 1; 3.4.zasądzenie od zamawiającego na rzecz odwołującego kosztów postępowania, w tym kosztów reprezentacji wg przedstawionych na rozprawie rachunków; Odwołujący wskazał, że posiada interes we wniesieniu niniejszego odwołania w rozumieniu art. 505 ust. 1 ustawy.

Zamawiający w postępowaniu uzyskał 2 oferty w zakresie Pakietu nr 1 ofertę Clockwise na kwotę 495.562,92 zł oraz ofertą odwołującego opiewającą na kwotę 498.787,44 zł.

Oferta Clockwise jest niezgodna z warunkami zamówienia i powinna zostać odrzucona z postępowania, czego zaniechał zamawiający. W tej sytuacji odwołujący ma interes we wniesieniu odwołania i doprowadzania rozstrzygnięcia postępowania do stanu zgodnego z prawem, czyli odrzucenia oferty Clockwise.

Odrzucanie oferty Clockwise umożliwi wybór oferty odwołującego, a w konsekwencji uzyskanie przychodu i zysku z realizacji zamówienia. Zatem niewniesienie odwołania doprowadzi do szkody u odwołującego na skutek nieuzyskania przechodu i zysku z tego zamówienia [zarzut naruszenia art. art. 226 ust. 1 pkt 5 ustawy - system Cortex XDR nie spełnia wymogu opasanego ust. 8 OPZ] Zgodnie z postanowieniem ust. 8 załącznika nr 2.1. pt. Opis Przedmiotu Zamówienia Dostawa kompleksowych rozwiązań w zakresie wykrywania, prezentacji oraz ochrony przed zagrożeniami w cyberprzestrzeni i skutkami ich wystąpienia na poziomie Uczelni dla Pakietu 1 pn. Dostawa z uruchomieniem narzędzi do zarządzania bezpieczeństwem klasy XDR (dalej „OPZ”) Zamawiający wymagał, aby oferowany System musi przechowywać przez 180 dni i umożliwiać przeszukiwanie z konsoli i via API co najmniej następujące typy indykatorów (ang. Indicators of Compromise): hashe SHA256 i MD5, adresy IPv4 i IPv6 oraz nazwy domenowe domena. Odwołujący wskazał, że oferowany przez Clockwise system Cortex XDR nie oferuje takiej możliwości.

W toku postępowania zamawiający wystąpił do Clockwise o wyjaśnienie treści tej oferty w tym zakresie. Clockwise w ramach wyjaśnień wskazał, że wymagania postanowieniem ust. 8 funkcja jest realizowane w sposób równoważny, zgodny z dokumentacją producenta. Clockwise wyjaśnia, że dostęp do wyników wyszukiwania możliwy jest nie przez API, a w modelu pobrania wyników i przeszukiwania ich lokalnie.

Zamawiający wu ust. 8 OPZ jasno określił, że wymaga, aby to System umożliwiał przeszukiwanie z konsoli i via API co najmniej następujące typy indykatorów (ang. Indicators of Compromise): hashe SHA256 i MD5, adresy IPv4 i IPv6 oraz nazwy domenowe domena. We własnych wyjaśnieniach Clockwise oświadczył, że przeszukiwanie nie jest realizowane za pomocą API. API służy tutaj tylko i wyłącznie do pobrania wszystkich danych, a przeszukiwanie jest realizowane w inny sposób. Zatem sam system Cortex XDR nie pozwala na przeszukiwanie danych przez API, a zaproponowane przez Clockwise przeszukiwanie realizowane jest już poza zaoferowanym systemem.

Zamawiający nie dopuścił, nie określił w zakresie tej funkcji kryteriów równoważności, ale jasny wymóg w OPZ, stąd Clockwise zaoferował rozwiązanie nie spełniające wymagań OPZ. Zatem zupełnie oczywiste jest niespełnienie wymagań postawionych przez zamawiającego w Opisie Przedmiotu Zamówienia przez oferowany przez Clockwise system Cortex XDR. [system Cortex XDR nie spełnia wymogu opasanego ust. 10 pkt 10) 1 lit. b) OPZ] Zgodnie z postanowieniem ust. 10 pkt 1) lit. b załącznika nr 2.1. pt. OPZ zamawiający wymagał, aby oferowany system posiadał możliwość instalacji agenta m.in. dla systemu operacyjnego Microsoft Windows 10 dla architektury procesorów x86-64 i arm64.

Zamawiający uznał to za wymóg nieodzowny, ponieważ brzmienie postanowienia ust. 10 OPZ wskazuje, że oferowany System musi posiadać możliwość instalacji agenta na co najmniej systemach operacyjnych wymienionych dalej w tym ustępie, w tym na systemie wskazanym w ust. 10 pkt 1) lit. b OPZ, tj. na Microsoft Windows 10 dla architektury procesorów x86-64 oraz arm64 właśnie.

Odwołujący wskazał, że ofertowany przez Clockwise system Cortex XDR nie ma możliwości instalacji agenta na systemie Windows 10 dedykowanym dla architektury procesora ARM64.

W toku postępowania zamawiający zwrócił się do Clockwise o wyjaśnienie tej kwestii wskazując, że zgodnie z dokumentacją Cortex XDR firmy Palo Alto ze strony https://docs-cortexpaloaltonetworks.com/r/Cortex-XDRCompatibilityMatrix agent Cotrex XDR nie jest dostępny dla Windows 10 dla architektury ARM. Natomiast architektura ARM jest wspierana przez Cortex XDR tylko systemu operacyjnego Windows 11, co wynika z instrukcji ujawnionej na ww. stronie Palo Alto.

W ramach wyjaśnień Clockwise oświadczył, powołując się na aktualizację oprogramowania Cortex XDR Agent w wersji 9.0, że aktualne wsparcie dla systemów operacyjnych Windows opartych na procesorach RAM w oferowanym rozwiązaniu XDR jest dostępne.

Odwołujący wskazał, że przesłane przez Clockwise wyjaśnienie w żaden sposób nie wskazuje na to, że producent zapewnia wsparcie dla Windows 10 z architekturą ARM64. Uwidoczniona w dokumencie informacja wskazuje jedynie, że Cortex XDR jest dostępny dla bliżej nieokreślonego systemu Windows działającego na architekturze ARM 64.

Powyższe potwierdza fakt, że w styczniu 2026 roku producent Palo Alto wprowadził do oferty nową wersję Cortex XDR oraz nową wersję agenta numerowaną jako 9.1. Odnosząc się do tej najnowszej wersji systemu Cotrex XDR odwołujący podkreślił, że nawet w przypadku tej wersji oprogramowania producent nie wskazuje, aby był dostępny agent w wymaganej przez zamawiającego wersji dla Windows 10 dedykowanej dla architektury ARM64. Na stronie zawierającej

informacje producenta Palo Alto dla systemu Cotrex XDR producent wskazuje m.in.: że To ensure maximum protection of your endpoints, Palo Alto Networks recommends that you always deploy the latest maintenance version for each agent release, Czyli producent zaleca(tłumaczenie): Aby zagwarantować maksymalną ochronę punktów końcowych, firma Palo Alto Networks zaleca, aby zawsze wdrażać najnowszą wersję konserwacyjną dla każdej wersji agenta.

Dalej na tej stronie producent Palo Alto przedstawia tabele zawierające wskazanie systemów operacyjnych dla urządzeń końcowych, dla których Cortex XDR oferuje wsparcie.Producent wskazuje tamże: The following tables show the endpoint operating systems on which you can install each release of the Cortex XDR agent. These operating systems are also supported with supported Citrix and VMware virtual applications. Tłumaczenie: Poniższe tabele przedstawiają systemy operacyjne punktów końcowych, na których można zainstalować poszczególne wersje agenta Cortex XDR. Te systemy operacyjne są również obsługiwane przez aplikacje wirtualne Citrix i VMware.

Wg producenta Palo Alto Networks jego System Cortex XDR dla systemów Windows 10 i Windows 11 oferuje wsparcie dla następujących wersji, wg tabel: tu odwołujący wkleił tabele ze strony producenta dotyczące Windows 10 i Widows 11 oraz wskazania czy system i w jakich wersjach oferuje wsparcie.

Z tych tabel dla odwołującego jasno wynika, że zgodnie z oświadczeniem producenta Palo Alto jego system Cortex XDR nie dalej możliwości instalowania agenta dla architektury ARM64 dla Windows 10, ale daje możliwość instalowania agenta dla architektury ARM64 dla Windows 11. Wynika z tego, że Palo Alto nie uwzględnił architektury ARM64 dla Windows 10, ale uwzględnił architekturę ARM64 dla Windows 11 w ww. zestawieniach.

Jako że wspomniany dokument został opublikowany już w styczniu 2026, czyli po dacie złożenia ofert, absolutnie nie można przyjąć interpretacji, że zaoferowane przez Clockwise rozwiązanie Palo Alto Cortex XDR spełnia wymogi OPZ w zakresie wymogu określonego ust. 10 pkt 1) lit. b) OPZ. [system Cortex XDR nie spełnia wymogu opasanego ust. 34 OPZ] W ust. 34 OPZ zamawiający określił wymóg dotyczący izolacji skompromitowanego urządzenia końcowego (tzw. endpointa) precyzując, że: System musi umożliwiać zdalną izolację sieciową endpointa. W trakcie trwania izolacji sieciowej cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany.

Odwołujący wskazał, że ofertowany przez Clockwise system Cortex XDR w trakcie trwania izolacji skompromitowanego endponita na serwerach Linux, poza połączeniami do systemu oraz protokołu DHCP, dopuszcza ruch DNS i HTTPS z siecią, co oczywiście wykracza poza dopuszczony warunkiem ruch do konsoli XDR.

W toku postępowania zamawiający wezwał Clockwise do wyjaśnień w tym zakresie i powołując się na treść dokumentacji producenta Palo Alto dla systemu Cotrex XDR dostępnej na stronie https://docscirtex.palpaltoworks.com/r/Cortex-XDR-4.x-Documentation/Initiate-a-LiveTerminal-sessions, z którego wynika, że po izolacji punkt końcowy pozwala na: ruch wychodzący DHCP i HTTPS dla użytkownika root i ruch DNS, a co stoi w sprzeczności z wymogiem ust. 34 OPZ.

W ramach wyjaśnień treści oferty Clockwise oświadczył, że: Według naszej wiedzy, dobrych praktyk i naszego doświadczenia związanego z wdrażaniem rozwiązań Cortex XDR, wymóg „w trakcie izolacji cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany” jest spełniony, ponieważ rozwiązanie w trybie izolacji blokuje ruch sieciowy endpointa z wyjątkiem kanału komunikacji z systemem zarządzającym oraz DHCP.

W dokumentacji znajduje się zapis "When you isolate an endpoint, you halt all network access on the endpoint except for traffic to Cortex XDR."(tłum. „Izolując punkt końcowy, zatrzymujesz cały dostęp do sieci na tym punkcie, z wyjątkiem ruchu do Cortex XDR.”). Jednocześnie wskazujemy, że w praktyce technicznej „połączenie do systemu” wymaga utrzymania niezbędnych zależności tego kanału DNS i HTTPS są warstwami technicznymi niezbędnymi do utrzymania połączenia z systemem zarządzającym. Wymóg OPZ dopuszcza ruch „do systemu”, a więc obejmuje również mechanizmy potrzebne do jego zestawienia i utrzymania takie jak DNS/FQDN oraz HTTPS/TLS.

Odwołujący wskazał, że wyżej przytoczone twierdzenie Clockwise o tym, jakoby wskazywane w instrukcji połączenia wychodzące izolowanego urządzenia końcowego przy użyciu kanałów DNS i HTTPS stanowi połączenie z systemem zarządzającym za pośrednictwem DNS i HTTPS jako warstwami technicznymi niezbędnymi do utrzymania połączenia z systemem zarządzającym, jest sprzeczne z ww. jasnym opisem technicznym zawartym w dokumentacji technicznej producenta Cortex XDR.

Clockwise opiera w tym zakresie swoje twierdzenie, wprost sprzeczne z oświadczeniami producenta Cortex XDR, o swoje przekonanie wynikające jakoby z wiedzy, dobrych praktyk i naszego doświadczenia związanego z wdrażanie rozwiązań Cortex XDR Clockwise. Natomiast opis przedmiotu zamówienia na dostawę oprogramowania bazuje na porównaniu dostępnych funkcjonalności oprogramowania, a nie dobrych praktykach wykonawcy.

Nieprawdą jest, że połączenia DNS oraz HTTPS są niezbędne dla zestawienia połączenia do konsoli zarządzania Cortex XDR, jak twierdzi Clockwise w wyjaśnienia treści swojej oferty. Połączenie do DNS jest niezbędne tylko w celu wskazania agentowi adresu IP, z którym powinien się skomunikować celem nawiązania połączenia do konsoli

administracyjnej. Połączenie to odbywa się do lokalnego lub globalnego serwera DNS i nie jest połączeniem do samej konsoli administracyjnej. Zatem wyjaśnienia Wykonawcy są niewiarygodne.

Odwołujący wskazał, że po uzyskaniu adresu IP połączenie do DNS jest połączeniem niezwiązanym z komunikacją z konsolą administracyjną i stanowi potencjalnie niebezpieczny kanał, który może zostać wykorzystany do infiltracji/eksfiltracji danych z izolowanego komputera co uwidacznia, że może to stanowić realne zagrożenie bezpieczeństwa. Dodatkowo agent może uzyskać połączenie do konsoli przez wpisanie w konfiguracji adresu IP do połączenia z konsolą administracyjną – wówczas sam agent nie potrzebuje połączenia z DNS dla realizacji połączenia z konsolą, a mimo to utrzymuje otwarte połączenie DNS. Stanowi to wprost brak spełnienia wymagania postawionego przez zamawiającego w ust. 34 OPZ.

Dodatkowo połączenie HTTPS jest połączeniem używanym powszechnie przy dostępie do stron internetowych – tym samym dopuszczenie tego ruchu powoduje, że zainfekowany komputer może łączyć się z dowolnymi zasobami w Internecie. Nie można zatem przyjąć interpretacji Clockwise, że jest to połączenie niezbędne by zrealizować łączność z konsolą administracyjna systemy Cortex XDR.

Podkreślił, że w ww. dokumentacji systemu Cortex XDR producent Palo Alto Networks zawarł się konkretny opis dotyczący izolacji:

Tu odwołujący wkleił fragment dokumentacji systemu w języku angielskim.

Co w przekładzie oznacza:

„Wyizolowanie punktu końcowego Gdy izolujesz punkt końcowy, dochodzi do zablokowania dostępu do sieci z tego urządzenia końcowego z wyjątkiem ruchu do Cortex XDR. Służy to temu, aby skompromitowane urządzenie końcowe nie miało możliwości komunikacji z innymi punktami końcowymi, ograniczając mobilność atakującego w Twojej sieci. Po otrzymaniu przez agenta instrukcji by izolować urządzenie końcowe i wykonaniu tej akcji, Cortex XDR wskazuje status Izolowany. Aby zapewnić, że urządzenie końcowe pozostanie w izolacji, w czasie jej trwania dla izolowanych urządzeń nie są dostępne aktualizacje oprogramowania agenta.

Po izolacji punkt końcowy nadal pozwala na: •Ruch wychodzący DHCP i HTTPS dla użytkownika root •Ruch DNS” Co oznacza, że uzyskanie/wskazanie statusu „isolated” w Cortex XDR determinuje już komunikację z konsolą zarządzającą w zakresie niezbędnym do zrealizowania cechy izolacji. Pomimo to producent Palo Alto wskazuje, że w tym stanie agent ma nadal możliwość podłączenia się do innych usług tj. DNS i HTTPS. Stoi to w jawnej sprzeczności z tym co zamawiający określił w wymaganiach OPZ. [system Cortex XDR nie spełnia wymogu opasanego ust. 65 OPZ] W ust. 65 OPZ zamawiający postawił wymóg dotyczący funkcjonalności zamawianego systemu polegający na tym, że Agent musi posiadać możliwość usuwania złośliwych makr wykrytych w plikach Microsoft Word i Microsoft Excel.

Rozwiązanie Cortex XDR firmy Palo Alto Networks zaoferowane przez Clockwise nie posiada zdolności do usuwania złośliwych makr wykrytych w plikach Microsoft Word i Microsoft Excel i pod tym względem oferta Clockwise jest wprost niezgodna wymogiem określonym przez zamawiającego w ust. 65 OPZ.

Zgodnie z dokumentacją producenta Cortex XDR dostępną na stronie https://docs-cortex.paloaltonetworks.com/r/CortexXDR/Cortex-XDR-5.xDocumentation/Set-up-malware-prevention-profiles agent Cortex XDR umożliwia wykrycie złośliwych makr w plikach WORD i EXCEL, a następnie jego działanie ogranicza się do blokowania wykonania złośliwych makr zagnieżdżonych w dokumentach Microsoft Office (W ORD, EXCEK) na endpointach z systemem Windows, co jest opisane w sekcji dotyczącej funkcji Office Files with Macros Examination (tłumaczenie: Pliki Office z weryfikacją makr) w dokumentacji dotyczącej konfiguracji profili zapobiegania złośliwemu oprogramowaniu. Instrukcja systemu Cortex XDR w odniesieniu do makr w plikach Mocrosoft Office wskazuje:

Tu odwołujący wkleił fragment dokumentacji producenta w języku angielskim.

Tłumaczenie:

1. Skonfiguruj opcje plików pakietu Office z funkcją badania makr. Agent Cortex XDR może analizować i zapobiegać uruchamianiu złośliwych makr osadzonych w plikach pakietu Microsoft Office (Word, Excel) na punktach końcowych systemu Windows.

PrzedmiotOpcje Tryb akcjiBlokowanie Raportowanie WyłączanieGdy agent Cortex XDR wykryje próby uruchomienia złośliwego oprogramowania, wykonuje skonfigurowaną akcję Jak jednoznacznie widać możliwa jest akcja zablokowania (ang. Block), akcja powiadomienia o wykryciu złośliwego makra, ale bez blokowania (Report) oraz opcja wyłączenia tej funkcji (ang. Disabled).

Jako uzupełnienie, rozwiązanie to pozwala na usuwanie lub umieszczanie w kwarantannie całych plików uznanych za złośliwe, co jest opisane w części poświęconej funkcji Search and Destroy w oficjalnej dokumentacji administratora:https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/CortexXDR-3.x-Documentation/Search-anddestroy-malicious-files Z dokumentacji producenta systemu Cortex XDR wynika, że system nie dysponuje wymaganą przez zamawiającego funkcjonalnością usunięcia wyłącznie złośliwego kodu makra z dokumentu z pozostawieniem niezmienionej resztę zawartości pliku Word/Excel, tak jak zostało to opisane w ust. 65 OPZ.

Działania reakcyjne agenta systemu Cortex XDR są zatem ograniczone do blokowania wykonania makra oraz usuwania lub kwarantanny całego pliku, a nie „oczyszczania” dokumentu z złośliwych makr. Nie można zatem ustanowić równoważności pomiędzy dostępnymi akcjami w rozwiązaniu Cortex XDR a ustanowionym w tym zakresie jasnym wymogiem zamawiającego. [system Cortex XDR nie spełnia wymogu opasanego ust. 70 OPZ] W ust. 70 OPZ zamawiający określił wymóg automatycznego skanowania pamięci masowej po jej przyłączeniu wskazując: Agent musi automatycznie wykonywać skanowanie pamięci masowej natychmiast po jej podłączeniu do portu USB.

Oferowany przez Clockwise system Cortex XDR produkcji Palo Alto Networks nie realizuje funkcji automatycznego, natychmiastowego skanowania pamięci masowej w momencie podłączenia nośnika do portu USB.

Funkcja takiego skanu „on connect” nie jest dostępna w produkcie jako natywna możliwość wyzwalania malware-scanu bezpośrednio po wykryciu urządzenia USB.

Cortex XDR umożliwia jedynie skanowanie przyłączonych nośników wymiennych (removable media drives) w ramach okresowego skanowania malware (Periodic Scan, który jest konfigurowany w profilu Malware Security Profile → Endpoint Scanning → Periodic Scan, przez włączenie opcji „Scan Removable Media Drives”). W tym trybie nośniki USB są objęte cyklicznym skanem (np. tygodniowym lub miesięcznym), podczas gdy zamawiający jednoznacznie w wymaganiu wskazał, że nośnik USB musi być skanowany „natychmiast”, co explicite wskazuje, że wymaga skanu uruchamianego automatycznie w chwili podłączenia urządzenia, a nie po określonym czasie.

System Cortex XDR oferuje funkcję Device Control, pozwalającą na kontrolowanie dostępu do urządzeń USB (m.in. blokowanie odczytu/zapisu, ograniczanie typów urządzeń oraz generowanie alertów i logów zdarzeń związanych z podłączaniem nośników) jednak funkcja ta służy do ograniczania ryzyka związanego z nośnikami wymiennymi, ale nie obejmuje automatycznego wyzwalania skanu wirusowego w momencie ich podłączenia. [art. 239 ustawy w związku z art. 70 (1) §4 KC w związku art. 8 ust. 1 ustawy] W postanowieniu ust. 1 rozdz. XXII SW Z zamawiający wskazał: Zamawiający odrzuci ofertę, w przypadku zaistnienia okoliczności, o których mowa w art. 226 ust. 1 ustawy.

Z uwagi na wyżej wykazane niezgodności treści oferty Clockwise z warunkami zamówienia, zamawiający winien był odrzucić ofertę tego wykonawcy na podstawie art. 226 ust. 1 pkt 5) ustawy.

Zgodnie z art. 70 (1) §4 KC Organizator od chwili udostępnienia warunków, a oferent od chwili złożenia oferty zgodnie z ogłoszeniem aukcji albo przetargu są obowiązani postępować zgodnie z postanowieniami ogłoszenia, a także warunków aukcji albo przetargu. Zatem zamawiający jako organizator przetargu od chwili ogłoszenia dokumentów zamówienia obowiązany jest do treści własnych dokumentów zamówienia w zakresie, w jakim związał się nimi.

Zatem zaniechanie odrzucenia oferty niezgodnej z warunkami zamówienia w świetle ust. 1 rozdz. XXII SW Z i dopuszczenie do wyboru w przetargu – postępowaniu takiej oferty stanowi naruszenie art. 70 (1) §4 KC w związku z art.

239 ustawy w taki zakresie, w jakim wadliwa oferta w ogóle brana jest pod uwagę przy wyborze najkorzystniejsze oferty i oceniania w ramach kryteriów oceny ofert wraz z innymi, niewadliwymi ofertami. [konkluzja] Zamawiający korzystając z uprawnienia określonego w art. 246 ust.2 ustawy ustalił cenę jedynym kryterium oceny ofert wskazując w uzasadnieniu zawartym w ust. 4 rozdz. XII SW Z, że w Postępowaniu kryteria oceny ofert zrezygnował z OPZ określa szczegółowe wymagania techniczne i funkcjonalne, będące wyznacznikiem jakości właściwej dla określonego segmentu systemów, odnoszące się do głównych cech funkcjonalnych pozostających w ofercie spośród kręgu wykonawców oferujących tego typu rozwiązania. Zatem postanowienia OPZ zawierają główne wymagania jakościowe odnoszące się do zamawianego systemu i przedmiot oferty powinien bezwzględnie im odpowiadać.

Oferowany przez Clockwise system Cortex XDR nie oferuje przynajmniej 5 opisanych odwołaniem funkcjonalności wymaganych bezwzględnie OPZ, tj. system Cortex XDR nie zapewnia wsparcia dla systemu Windows 10 dedykowanego dla procesora o architekturze ARM64; w trakcie izolacji skompromitowanego urządzenia końcowego na systemach Linux, poza jedynie dopuszczonymi połączeniami do systemu oraz protokołu DHCP, dopuszcza ruch DNS i HTTPS z siecią; agent Cortex XDR nie dysponuje możliwością usuwania złośliwych makr z plików Word i Excell, a jego zdolność reakcji ogranicza się do blokowania, raportowania, ewentualnie usunięcia całego pliku Word/Excell; wreszcie

agent Cortex XDR nie oferuje funkcjonalności automatycznego skanowania pamięci masowej po jej podłączeniu.

W kontekście wymogów określonych dla zamawianego systemu XDR system Cortex XDR nie wypełnia przynajmniej 5 wymogów OPZ i oferta Clockwise powinna być odrzucona z uwag na jej niezgodność z warunkami zamówienia, czego zamawiający zaniechał.

10 lutego 2026 r. zamawiający poinformował o wniesieniu odwołania.

12 lutego 2026 r. wykonawca Clockwise Spółka z ograniczoną odpowiedzialnością Spółka Komandy ul. Puławska 405A, 02-801 Warszaw zgłosił swój udział w postępowaniu odwoławczym po stronie zamawiającego wnosząc o oddalenie odwołania. Przystępujący działał przez należycie umocowanego pełnomocnika. Do zgłoszenia dołączono dowody jego przekazania stronom. Przystępujący wskazał, że zgodnie z podjętą przez Zamawiającego decyzją, jego oferta została uznana za najkorzystniejszą w części zamówienia objętej pakietem nr 1. Uwzględniając zarzuty wniesionego odwołania oraz sformułowane w nim żądania (odrzucenie oferty Przystępującego) jego uwzględnienie spowodowałoby pozbawienie przystępującego możliwości uzyskania zamówienia. W konsekwencji stwierdził, że posiada interes w rozstrzygnięciu wniesionego odwołania na korzyść zamawiającego tj. przez utrzymanie w mocy zaskarżonej przez odwołującego decyzji o wyborze oferty przystępującego jako najkorzystniejszej.

19 marca 2026 r. zamawiający złożył odpowiedź na odwołanie wnosząc o oddalenie odwołania w całości jako bezzasadnego.

Zamawiający nie zgodził się z zarzutami przedstawionymi w odwołaniu, jednocześnie odnosząc się merytorycznie do przedmiotowych zarzutów.

Zarzut nr 1: Ust. 8 OPZ – Przeszukiwanie IOC via API (180 dni) Wymóg: "System musi przechowywać przez 180 dni i umożliwiać przeszukiwanie z konsoli i via API co najmniej następujące typy indykatorów (ang. Indicators of Compromise): hashe SHA256 i MD5, adresy IPv4 i IPv6 oraz nazwy domenowe (domena). Zarzut: Cortex XDR nie umożliwia przeszukiwania IOC poprzez API. API służy tylko do pobrania wszystkich danych, a przeszukiwanie realizowane jest lokalnie poza systemem. Zamawiający wymagał, aby SAM SYSTEM przeszukiwał via API, czego Cortex XDR nie oferuje.

Wyjaśnienie Clockwise (z 14.01.2026): Funkcja realizowana w sposób równoważny zgodnie z dokumentacją producenta.

Dostęp do wyników wyszukiwania możliwy przez model pobrania wyników i przeszukiwania ich lokalnie.

Ocena: 1.OPZ nie definiuje architektury technicznej – wymóg "via API" oznacza możliwość programowego dostępu do funkcji przeszukiwania, niekonkretną implementację query processing

1. Równoważność funkcjonalna – Cortex XDR Platform API oferuje endpoint /public_api/v1/indicators/get z parametrami filtrowania: - field: indicator, type (hash/ip/domain_name) - operator: EQ, IN, GTE, LTE - search_from/to: paginacja wyników - Zwraca obiekty IOC z atrybutami zgodnie z wymogami OPZ
2. Standard rynkowy REST API – model "pobierz z filtrami + przetwarzaj lokalnie" stosowany powszechnie (Elasticsearch, Splunk, Microsoft Defender).

Zamawiający dodatkowo wskazał, że Krajowa Izba Odwoławcza w swoim orzecznictwie – wielokrotnie uznawała, że OPZ nie może narzucać konkretnych rozwiązań technicznych, jeśli cel zostaje osiągnięty, co potwierdza orzeczenie KIO 1234/19 oraz KIO 2456/20.

Zarzut nr 2: Ust. 10 pkt 1 lit. b OPZ – Windows 10 ARM64 Wymóg: "Oferowany System musi posiadać możliwość instalacji agenta na co najmniej systemach operacyjnych: [...] Microsoft Windows 10 dla architektury procesorów x86-64 i arm64" Zarzut Trecom: Cortex XDR nie ma agenta dla Windows 10 ARM64. Dokumentacja producenta (Cortex XDR Compatibility Matrix, styczeń 2026, wersja 9.1) wyraźnie rozróżnia: - Windows 10: x86-64 (wsparte) - Windows 11: x8664, ARM64 (wsparte) Brak Windows 10 ARM64 w tabelach zgodności. Clockwise powołał się na wersję 9.0, ale nawet najnowsza wersja 9.1 nie potwierdza wsparcia dla W10 ARM64. Wyjaśnienie: Aktualizacja oprogramowania Cortex XDR Agent w wersji 9.0+ zapewnia wsparcie dla systemów operacyjnych Windows opartych na procesorach ARM, w tym Windows 10.

Ocena:

1. Deklaracja producenta vs. dokumentacja – jeśli Palo Alto Networks oficjalnie potwierdzi wsparcie W10 ARM64 (np. przez Technical Support ticket), dokumentacja publiczna może być nieaktualna.
2. Zalecenie producenta – "Always deploy the latest maintenance version" sugeruje ciągłe rozszerzanie wsparcia.
3. Faktyczne potrzeby zamawiającego – W UM nie posiada urządzeń z Windows 10 ARM64 (inwentaryzacja IT: 0 sztuk), wymóg może być teoretyczny
4. Zasada proporcjonalności – odrzucenie oferty za brak wsparcia dla nieistniejącej w infrastrukturze architektury byłoby nieproporcjonalne.
5. Jednoznaczność tabeli zgodności – Palo Alto wyraźnie rozróżnia W10 i W11 w kontekście ARM64.

Zarzut nr 3: Ust. 34 OPZ – Izolacja sieciowa endpoint Wymóg OPZ: "System musi umożliwiać zdalną izolację sieciową endpointa. W trakcie trwania izolacji sieciowej cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany."

Zarzut: Cortex XDR w trakcie izolacji endpointów na serwerach Linux dopuszcza: - Ruch wychodzący DHCP (zgodnie z wymogiem) - Ruch wychodzący HTTPS dla użytkownika root - Ruch DNS Dokumentacja Palo Alto wyraźnie to potwierdza. DNS i HTTPS wykraczają poza dopuszczony ruch "do systemu + DHCP", co stanowi niezgodność z OPZ.

Wyjaśnienie: Według dokumentacji i dobrych praktyk, wymóg jest spełniony, ponieważ: - Rozwiązanie w trybie izolacji blokuje ruch sieciowy endpointa z wyjątkiem kanału komunikacji z systemem zarządzającym oraz DHCP - W praktyce technicznej połączenie do systemu wymaga utrzymania niezbędnych zależności tego kanału - DNS i HTTPS są warstwami technicznymi niezbędnymi do utrzymania połączenia z systemem zarządzającym - Wymóg OPZ "ruch do systemu" obejmuje mechanizmy potrzebne do jego zestawienia i utrzymania (DNS/FQDN, HTTPS/TLS) Ocena:

1. Interpretacja celowościowa – OPZ wymaga blokady ruchu w celu ograniczenia mobilności atakującego w sieci.

DNS/HTTPS do konsoli XDR nie umożliwiają komunikacji z innymi endpointami = cel spełniony

1. Dokumentacja producenta – Palo Alto explicite wskazuje: "halt all network access except for traffic to Cortex XDR".

DNS/HTTPS są częścią "traffic to Cortex XDR"

1. Praktyczna konieczność – agent musi rozwiązać nazwę domenową konsoli (DNS) i ustanowić bezpieczne połączenie (TLS/HTTPS). Bez tego izolacja uniemożliwiłaby zarządzanie endpointem
2. Precedens techniczny – większość rozwiązań XDR/EDR dopuszcza warstwy protokołów niezbędne do komunikacji z konsolą Zarzut nr 4: Ust. 65 OPZ – Usuwanie złośliwych makr Office Wymóg: "Agent musi posiadać możliwość usuwania złośliwych makr wykrytych w plikach Microsoft Word i Microsoft Excel." Zarzut: Cortex XDR nie posiada funkcji usuwania złośliwych makr z dokumentów Word/Excel. System oferuje: - Blokowanie wykonania makr (Block) - Raportowanie wykrycia makr (Report) - Usuwanie/kwarantannę całego pliku (Search and Destroy) Brak funkcji selektywnego czyszczenia kodu VBA z dokumentu z pozostawieniem treści pliku. Dokumentacja producenta potwierdza, że działania reakcyjne są ograniczone do blokowania wykonania makra oraz usuwania całego pliku, nieoczyszczania dokumentu z makr.

Wyjaśnienie: Malware Prevention Profile blokuje wykonanie złośliwych makr w plikach Office (funkcja "Office Files with Macros Examination"). Dodatkowo Search and Destroy usuwa lub umieszcza w kwarantannie pliki uznane za złośliwe.

Równoważna ochrona.

Ocena

1. Interpretacja funkcjonalna vs. literalna – celem wymogu jest eliminacja zagrożenia, nie - konkretna metoda. Blokada wykonania makr + usunięcie pliku = cel osiągnięty
2. Standard rynkowy – większość rozwiązań XDR/EDR (CrowdStrike, Microsoft Defender, SentinelOne) również nie oferuje selektywnego czyszczenia makr VBA, tylko blokadę lub usunięcie pliku
3. Przewaga bezpieczeństwa – usunięcie całego zainfekowanego pliku jest bezpieczniejsze niż próba czyszczenia VBA (ryzyko residuum złośliwego kodu)
4. Brak precyzji OPZ – wymóg nie wskazuje "z zachowaniem treści pliku" ani "bez usuwania dokumentu" Zarzut nr 5: Ust. 70 OPZ – Automatyczne skanowanie USB Wymóg OPZ: "Agent musi automatycznie wykonywać skanowanie pamięci masowej natychmiast po jej podłączeniu do portu USB."

Zarzut: Cortex XDR nie oferuje automatycznego, natychmiastowego skanowania pamięci masowej w momencie podłączenia nośnika do portu USB. System oferuje: - Device Control – blokowanie dostępu do USB, generowanie alertów - Periodic Scan – cykliczne skanowanie z opcją "Scan Removable Media Drives" (np. tygodniowo) Brak natywnej funkcji "scan on connect". Wymóg OPZ explicite wskazuje "natychmiast", co oznacza event-driven scan, nie scheduled scan.

Wyjaśnienie: Clockwise: Device Control pozwala kontrolować dostęp do urządzeń USB (blokowanie odczytu/zapisu, ograniczanie typów urządzeń, alerty). Periodic Scan z opcją Removable Media zapewnia równoważną ochronę.

Prewencja (blokada) lepsza niż detekcja (scan).

Ocena:

1. Przewaga prewencji nad detekcją – Device Control blokujący USB default + allowlist to wyższy poziom

bezpieczeństwa niż skanowanie after-the-fact

1. Zero-trust model – blokada wszystkich USB z wyjątkiem zatwierdzonych urządzeń eliminuje zagrożenie u źródła
2. Interpretacja celu OPZ – celem jest ochrona przed malware z USB, co osiąga się skuteczniej przez blokadę niż scan
3. Brak zakazu alternatyw – OPZ nie stanowi "wyłącznie przez scan on-connect" Zamawiający stoi na stanowisku, tak jak podkreślała wielokrotnie KIO w swoich wyrokach, że „In dubio pro performerem”, czyli wszelkie niejednoznaczności w OPZ należy interpretować na korzyść wykonawcy składającego ofertę. Jeśli zamawiający chciał wykluczyć równoważne rozwiązania, powinien to jednoznacznie określić w OPZ, co potwierdzają orzeczenia wydane w sprawach KIO 1456/18, KIO 2234/19, KIO 987/21.

Oferta jest niezgodna z warunkami zamówienia tylko wtedy, gdy cel określony w OPZ nie może zostać osiągnięty. Jeśli Clockwise oferuje alternatywne metody realizacji tych samych celów (ochrona przed malware, izolacja zagrożeń, kontrola USB), niezgodność nie zachodzi, co potwierdza nietrafność zarzutu odwołującego, tj. art. 226 ust. 1 pkt 5 PZP.

Zamawiający zastosował art. 131 ustawy, wezwał Clockwise do wyjaśnień, otrzymał szczegółowe odpowiedzi potwierdzone dokumentacją producenta, dokonał weryfikacji merytorycznej. Trecom nie kwestionuje procedury, tylko ocenę merytoryczną.

Odrzucenie oferty tańszej o 3.224,52 zł z powodu niejasności interpretacyjnych byłoby nieproporcjonalne wobec celu postępowania (wybór najkorzystniejszej oferty). Szczególnie gdy druga oferta (Trecom) również była dostępna. Wybór oferty Trecom (nie narusza interesu publicznego, ale przedłuża postępowanie i opóźnia realizację krytycznego projektu bezpieczeństwa IT w sektorze medycznym (WUM).

Zamawiający, biorąc pod uwagę powyższe, a także uwzględniając następujące fakty, min. dotyczące zgodności z dokumentacją producenta (Palo Alto Networks), tj. brak sprzeczności, a także udzielenie wyczerpującej odpowiedzi na wezwanie zamawiającego przez wykonawcę, która kompleksowo wykazała spełnienie warunków opisanych w OPZ, powinno skutkować oddaleniem odwołania odwołującego w całości jako bezzasadnego.

20 marca 2026 r. przystępujący przedstawił pisemne stanowisko i wniósł o przeprowadzenie dowodów z przedłożonych dokumentów.

Zarzut 1

Zarzut jest oczywiście bezzasadny. Oparty on został na nierzetelnej ocenie wyjaśnień złożonych przez przystępującego, nieznajomości rozwiązania zaoferowanego przez przystępującego oraz przedstawieniu błędnego rozumienia wymogu SWZ.

Jak wynika z wyjaśnień złożonych przystępującego, w żadnym ich miejscu nie wskazał on, wbrew twierdzeniom odwołującego, że w systemie Cortex XDR przeszukiwanie nie jest realizowane za pomocą API.

W odpowiedzi na punkt 3 zapytania zamawiającego, powołując się na konkretne postanowienia dokumentacji producenta, przystępujący wskazał w treści swoich wyjaśnień: • „Rozwiązanie umożliwia przeszukiwanie danych telemetrycznych pod kątem IoC zarówno z poziomu konsoli (XQL), jak i z poziomu API [……]”.

Dalej przystępujący wskazał w swoich wyjaśnieniach w jaki sposób realizowane jest przeszukanie ww. danych z poziomu tj. za pomocą API: • „[…..] poprzez XQL Query APIs (Start XQL Query + pobranie wyników Get XQL Query Results / Stream).”

Powyższe wprost zatem zaprzecza twierdzeniom odwołującego.

Przystępujący równocześnie wskazał, że zastosowany w systemie Cortex XDR sposób realizacji ww. wymagania SW Z tj. przez XQL Query APIs (Start XQL Query + pobranie wyników Get XQL Query Results / Stream)” w żaden sposób nie oznacza braku jego spełnienia. Twierdzenia odwołującego w tym zakresie nie tylko nie zostały udowodnione, ale są również całkowicie bezzasadne.

W odniesieniu do stwierdzenia odwołującego, że w przypadku rozwiązania przystępującego:

„API służy tutaj tylko i wyłącznie do pobrania wszystkich danych, a przeszukiwanie jest realizowane w inny sposób”; wymaga zauważenia, że wymóg SW Z nie brzmi, jak chciałby tego odwołujący tj., aby API służyło do przeszukiwania danych, ale aby przeszukiwanie danych było możliwe z poziomu API. W przypadku rozwiązania przystępującego taka możliwość istnieje. Przeszukiwanie danych jest możliwe z poziomu API, a przyjęty w rozwiązania Cortex XDR sposób tego przeszukiwania jest zgodny z SW Z. Zamawiający zresztą nie określił w SW Z szczegółowego sposobu przeszukiwania identyfikatorów via API.

Przystępujący równocześnie wskazał, że użyte prze niego w złożonych wyjaśnieniach stwierdzenie: „tym samym przeszukiwanie „via API” jest realizowane w sposób równoważny, zgodny z dokumentacją producenta” nie oznaczało, że przystępujący oferuje inny sposób realizacji wymagania niż opisał to zamawiający. Zgodnie ze słownikiem języka polskiego słowo „równoważny” oznacza m.in. zgodny, taki sam, mający tę samą wartość i w tym znaczeniu przystępujący użył tego określenia tj., że przeszukiwanie via API odbywa się w sposób zgodny z wymogiem SWZ.

Przystępujący wniósł o przeprowadzenie dowodu z:

a) Wyjaśnień treści oferty (pismo z dnia 16.01.2026 r.) złożonych przez przystępującego (odpowiedź do punktu 3) – znajduje się w aktach postępowania; b) dokumentacji producenta zawartej na stronie https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR-REST-API/XQLQuery - w załączeniu: wydruk zrzutu ekranu dot. kluczowego stwierdzenia producenta („zarzut 1”); na fakt, że zaoferowany przez przystępującego system Cortex XDR Cortex XDR umożliwia przeszukiwanie danych telemetrycznych pod kątem identyfikatorów IoC z poziomu API przez użycie funkcji: XQL Query APIs (Start XQL Query + pobranie wyników Get XQL Query Results / Stream), co realizuje wymóg z ust. 8 załącznika nr 2.1 do SWZ (OPZ) tj.:

„System musi przechowywać przez 180 dni i umożliwiać przeszukiwanie z konsoli i via API co najmniej następujące typy indykatorów (ang. Indicators of Compromise): hashe SHA256 i MD5, adresy IPv4 i IPv6 oraz nazwy domenowe domena."

Ad. zarzut nr 2 Istotą zarzutu opisanego w pkt III.b uzasadnienia odwołania jest twierdzenie odwołującego, że zaoferowany przez przystępującego system Cortex XDR nie spełnia poniższego wymagania określonego w ust. 10 pkt 1) lit. b załącznika nr 2.1 do SWZ (OPZ): • system musi posiadać możliwość instalacji agenta m.in. dla systemu operacyjnego Microsoft Windows 10 dla architektury procesorów x86-64 i arm64.

Przystępujący stwierdził, że poniższe twierdzenie odwołującego: • „ofertowany przez Clockwise system Cortex XDR nie ma możliwości instalacji agenta na systemie Windows 10 dedykowanym dla architektury procesora ARM64” jest bezpodstawne, nierzetelne i jest wynikiem wybiórczej z jego strony interpretacji dokumentacji dotyczącej systemu Cortex XDR. Odwołujący nie przeanalizował całości dokumentacji producenta i oparł swój zarzut jedynie na swoich domysłach.

Przystępujący równocześnie w pełni podtrzymał złożone w treści wyjaśnień oferty oświadczenie, że wsparcie dla systemów operacyjnych Windows, w tym Windows 10 opartych na procesorach ARM, w tym ARM64 w oferowanym rozwiązaniu XDR jest dostępne.

Uznając za zbyteczne odnoszenie się do poszczególnych stwierdzeń odwołującego zawartych w treści odwołania, a rzekomo uzasadniających ten zarzut przystępujący wniósł o przeprowadzenie dowodu z: c) dokumentacji producenta zawartej na stronie https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/9.0/Cortex-XDRAgent-Release-Notes/Feature-Enhancements - w załączeniu: wydruk zrzutu ekranu dot. kluczowego stwierdzenia producenta („zarzut 2”) oraz d) dokumentacji producenta zawartej na stronie https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDRCompatibility-Matrix/Windows - w załączeniu: wydruk zrzutu ekranu dot. kluczowego stwierdzenia producenta „zarzut 2”) na fakt, że dla wersji Cortex XDR Agent 9.0 istnieje wsparcie dla systemów operacyjnych Windows opartych na architekturze procesorów ARM64 oraz że środowisko Windows 10 znajduje się w zakresie kompatybilności Agenta Cortex XDR, zarówno w wersji 9.0 jak również dla wersji 9.1. oraz kolejnych wersjach.

Powyższe potwierdza, że ofertowany przez Clockwise system Cortex XDR ma możliwość instalacji agenta na systemie Windows 10 dedykowanym dla architektury procesora ARM64, co stanowi spełnienie wymogu SWZ; Ad. zarzut nr 3 Istotą zarzutu opisanego w pkt III.c uzasadnienia odwołania jest twierdzenie Odwołującego, że zaoferowany przez Przystępującego system Cortex XDR nie spełnia poniższego wymagania określonego w ust. 34 załącznika nr 2.1 do SWZ (OPZ): • „System musi umożliwiać zdalną izolację sieciową endpointa. W trakcie trwania izolacji sieciowej cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany.”

Odwołujący stwierdza: • „system Cortex XDR w trakcie trwania izolacji skompromitowanego endponita na serwerach Linux, poza połączeniami do systemu oraz protokołu DHCP, dopuszcza ruch DNS i HTTPS z siecią, co oczywiście wykracza poza dopuszczony warunkiem ruch do konsoli XDR.”

Przystępujący wskazał analogicznie jak w przypadku innych zarzutów odwołania, że powyższy zarzut jest oczywiście bezzasadny. Przystępujący w sposób jednoznaczny potwierdził w wyjaśnieniach treści oferty spełnienie przedmiotowego wymagania, wskazał bowiem: • „[…..] rozwiązanie w trybie izolacji blokuje ruch sieciowy endpointa z wyjątkiem kanału komunikacji z systemem zarządzającym oraz DHCP.”

Powyższe stwierdzenie przystępujący oparł na wskazanym w wyjaśnieniach fragmencie dokumentacji producenta, gdzie czytamy: • "When you isolate an endpoint, you halt all network access on the endpoint except for traffic to Cortex XDR."(tłum.

„Izolując punkt końcowy, zatrzymujesz cały dostęp do sieci na tym punkcie, z wyjątkiem ruchu do Cortex XDR.”).

Należy stwierdzić, że powyższe jest jednoznacznym potwierdzeniem spełnienia wymogu SWZ: • „System musi umożliwiać zdalną izolację sieciową endpointa. W trakcie trwania izolacji sieciowej cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany.”

Wbrew twierdzeniom odwołującego dalsza część wyjaśnień przystępującego tj.: • „Jednocześnie wskazujemy, że w praktyce technicznej „połączenie do systemu” wymaga utrzymania niezbędnych zależności tego kanału DNS i HTTPS są warstwami technicznymi niezbędnymi do utrzymania połączenia z systemem zarządzającym. Wymóg OPZ dopuszcza ruch „do systemu”, a więc obejmuje również mechanizmy potrzebne do jego zestawienia i utrzymania takie jak DNS/FQDN oraz HTTPS/TLS” w żaden sposób nie stoi w sprzeczności z ustaleniem, że w trakcie trwania izolacji sieciowej cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany.

Dopuszczenie przez producenta w trakcie trwania izolacji wybranych typów ruchu tj. m.in. DNS oraz wyjściowy HTTPS w żaden sposób nie oznacza, że dopuszczony jest ruch sieciowy poza połączeniem do systemu oraz protokołem DHCP. Z dokumentacji wprost bowiem wynika, że te typy ruchu tj. DNS oraz HTTPS są niezbędne do utrzymania połączenia z systemem zarządzającym, co zamawiający wprost dopuścił w SW Z („ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany”).

Przystępujący wyjaśnił że sformułowanie SW Z „połączenia do systemu” należy rozumieć szerzej niż samo utrzymanie sesji — obejmuje ono również zależności warstwowe, bez których zestawienie oraz stabilne utrzymanie łączności z usługami chmurowymi nie byłoby możliwe.

Ruch DNS jest wymagany do prawidłowego rozwiązywania nazw FQDN usług po stronie chmury, co stanowi warunek nawiązania komunikacji pomiędzy agentem a konsolą. Z kolei HTTPS/TLS jest podstawowym, szyfrowanym kanałem transmisji wykorzystywanym do bezpiecznej komunikacji z systemem zarządzającym, w tym do przesyłania telemetrii, poleceń oraz potwierdzeń wykonania działań w ramach izolacji.

Przystępujący wniósł o przeprowadzenie dowodu z: a) Wyjaśnień treści oferty (pismo z dnia 16.01.2026 r.) złożonych przez przystępującego (odpowiedź do punktu 2) – znajduje się w aktach postępowania; e) dokumentacji producenta zawartej na stronie https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-5.xDocumentation/Isolate-an-endpoint - w załączeniu: wydruk zrzutu ekranu dot. kluczowego stwierdzenia producenta („zarzut 3”) na fakt, że zaoferowany przez przystępującego system Cortex XDR realizuje wymóg z ust. 34 załącznika nr 2.1 do SW Z (OPZ) tj.:

Ad. zarzut nr 4 Zarzut opisany w pkt III.d uzasadnienia odwołania oparty jest na twierdzeniu odwołującego, że zaoferowany przez przystępującego system Cortex XDR nie spełnia poniższego wymagania określonego w ust. 65 załącznika nr 2.1 do SWZ (OPZ): • „Agent musi posiadać możliwość usuwania złośliwych makr wykrytych w plikach Microsoft Word i Microsoft Excel.”

Istotą ww. zarzutu jest następujące stwierdzenie odwołującego (pkt 43 uzasadnienia odwołania): • system nie dysponuje wymaganą przez zamawiającego funkcjonalnością usunięcia wyłącznie złośliwego kodu makra z dokumentu z pozostawieniem niezmienionej resztę zawartości pliku Word/Excel, tak jak zostało to opisane w ust. 65 OPZ.

Przystępujący wskazał, że powyższy zarzut jest oczywiście bezzasadny.

O bezzasadności ww. zarzutu świadczy już sama okoliczność, w której oparty jest on na interpretacji ww. wymagania pozostającej w sprzeczności z jego faktyczną treścią. Zdaniem odwołującego z cytowanego wyżej wymagania z ust. 65 załącznika nr 2.1 do SW Z wynika jakoby agent musiał mieć możliwość usunięcia wyłącznie złośliwego kodu makra z dokumentu z pozostawieniem niezmienionej reszty zawartości pliku Word/Excel. Przystępujący podkreślił, że w treści przedmiotowego wymagania nie pojawiają się sformułowania użyte przez odwołującego tj. „wyłącznie złośliwego kodu”, „z dokumentu” oraz „z pozostawieniem niezmienionej reszty zawartości pliku”.

Określając wymóg „Agent musi posiadać możliwość usuwania złośliwych makr wykrytych w plikach Microsoft Word i Microsoft Excel” zamawiający nie narzucił sposobu jego realizacji tj. sposobu usunięcia złośliwych makr. Istotą wymagania jest to, aby Agent miał możliwość usunięcia złośliwych makr wykrytych w plikach Word/Excel. Agent w rozwiązaniu zaoferowanym przez Przystępującego ma taką możliwość, tj. wykryte w plikach Word/Excel złośliwe makra mogą być usunięte przez usunięcie całego pliku Word/Excel, w którym wykryto złośliwe makro. Taki sposób realizacji wymagania SWZ nie jest sprzeczny z jego treścią.

Wymóg SW Z nie wskazuje, że jedynym sposobem usunięcia złośliwych makr jest usunięcie samego kodu makra z

dokumentu, a po jego usunięciu dokument musi pozostać w niezmienionej treści.

Przystępujący wniósł o przeprowadzenie dowodu z: f) dokumentacji producenta zawartej na stronie https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-5.xDocumentation/Add-Quick-Actions-commands-and-scripts - w załączeniu: wydruk zrzutu ekranu dot. kluczowego stwierdzenia producenta („zarzut 4”) na fakt, że zaoferowany przez przystępującego system Cortex XDR wspiera analizę i blokowanie złośliwych makr w plikach Microsoft Office w ramach profili prewencji (Office files with macros examination, tryb Block/Report), a także działania reakcyjne/remediacyjne na artefaktach, takie jak kwarantanna lub usunięcie pliku (z wykorzystaniem wbudowanych automatyzacji), co oznacza, że realizuje wymóg z ust. 65 załącznika nr 2.1 do SWZ (OPZ).

Ad. zarzut nr 5 Istotą zarzutu opisanego w pkt III.e uzasadnienia odwołania jest twierdzenie odwołującego, że zaoferowany przez przystępującego system Cortex XDR nie spełnia poniższego wymagania określonego w ust. 70 załącznika nr 2.1 do SWZ (OPZ): • „Agent musi automatycznie wykonywać skanowanie pamięci masowej natychmiast po jej podłączeniu do portu USB.”

O bezzasadności ww. zarzutu świadczy już sama okoliczność, w której oparty jest on na interpretacji ww. wymagania pozostającej w sprzeczności z jego faktyczną treścią. Zdaniem odwołującego bowiem skanowanie, o którym mowa w ww. wymaganiu ma mieć na celu automatyczne wyzwalanie skanu wirusowego, co przecież nie wynika z treści tego wymagania.

Przystępujący zwrócił uwagę, że wymóg z ust. 70 załącznika nr 2.1 do SW Z wskazuje na konieczność automatycznego skanowania pamięci masowej po jej podłączeniu do portu USB natomiast nie określa rodzaju/zakresu/efektu tego skanowania. Nie jest zatem zgodne z treścią SW Z twierdzenie odwołującego, że ww. automatyczne skanowanie ma mieć na celu automatyczne wyzwalanie skanu wirusowego.

W przypadku rozwiązania zaoferowanego przez przystępującego bezpieczeństwo w ww. obszarze realizuje się dwutorowo: (1) przez natychmiastowe rozpoznanie i kontrolę podłączonego urządzenia oraz (2) przez kontrolę i analizę plików w momencie ich użycia lub w ramach skanów planowych / na żądanie.

Cortex XDR zapewnia funkcję Device Control, która pozwala wykrywać i klasyfikować podłączane urządzenia USB (w tym pamięci masowe) oraz egzekwować polityki dopuszczenia bądź blokowania nośników (np. tylko zaufane/zaakceptowane urządzenia), co stanowi automatyczną reakcję „natychmiast po podłączeniu” i pozwala ograniczyć ryzyko jeszcze zanim dojdzie do skopiowania lub uruchomienia plików z nośnika. Te informacje możemy znaleźć w dokumentacji Producenta dostępnej pod linkiem poniżej:

Przystępujący wniósł o przeprowadzenie dowodu z: g) dokumentacji producenta zawartej na stronie https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-5.xDocumentation/Device-control - w załączeniu: wydruk zrzutu ekranu dot. kluczowego stwierdzenia producenta („zarzut 5”) na fakt, że zaoferowany przez przystępującego system Cortex XDR zawiera funkcję agenta Device Control, która polega na automatycznym skanowaniu pamięci masowej natychmiast po jej podłączeniu, gdzie skanowanie to pozwala automatycznie wykrywać i klasyfikować podłączane urządzenia USB (w tym pamięci masowe) oraz egzekwować polityki dopuszczenia bądź blokowania nośników (np. tylko zaufane/zaakceptowane urządzenia), co oznacza, że realizuje wymóg z ust. 70 załącznika nr 2.1 do SWZ (OPZ).

Stan faktyczny:

KIO na podstawie dokumentacji postępowania o udzielenie zamówienia oraz dowodów złożonych przez odwołującego i przystępującego ustaliła, co następuje:

W SWZ zamawiający postanowił:

III. Opis przedmiotu zamówienia

1. W sytuacjach, gdy Zamawiający opisuje przedmiot zamówienia poprzez odniesienie się do norm, ocen technicznych, specyfikacji technicznych i systemów referencji technicznych, Zamawiający dopuszcza rozwiązania równoważne opisywanym w każdej takiej normie, ocenie technicznej, aprobacie, specyfikacji technicznej, systemie referencji technicznych spełniające wymagania określone w opisie przedmiotu zamówienia.
2. W sytuacjach, gdy Zamawiający opisuje przedmiot zamówienia poprzez odniesienie się do wymagań dotyczących wydajności lub funkcjonalności Zamawiający dopuszcza rozwiązania równoważne opisywanym, zgodne z Polską Normą przenoszącą normę europejską, normami innych państw członkowskich Europejskiego Obszaru Gospodarczego przenoszącymi normy europejskie, z europejską ocena techniczną, ze wspólną specyfikacją techniczną, z normą międzynarodową lub z systemem referencji technicznych ustanowionym przez europejski organ normalizacyjny, jeżeli te normy, oceny techniczne, specyfikacje i systemy referencji technicznych spełniają wymagania dotyczące wydajności lub

funkcjonalności określone przez Zamawiającego.

XI. PRZEDMIOTOWE ŚRODKI DOWODOWE W celu potwierdzenia, że oferowane dostawy spełniają określone przez Zamawiającego wymagania oraz cechy, Zamawiający nie żąda złożenia wraz z ofertą przedmiotowych środków dowodowych.

XII. KRYTERIA OCENY OFERT ORAZ ICH ZNACZENIE ORAZ SPOSÓB OCENY OFERT Zamawiający w Pakietach 1 - 5 odstąpił od zastosowania kryterium ceny o wadze nie przekraczającej 60%, zgodnie z zasadą wyrażoną w art. 246 ust. 2 ustawy Pzp, kierując się optymalizacją jakości oferowanych produktów w korelacji z ich wartością.

Zamawiający jednocześnie wyjaśnia, że w Opisie Przedmiotu Zamówienia (Załączniki nr 2.1-2.5 do SW Z) określił szczegółowe wymagania techniczne i funkcjonalne, będące wyznacznikiem jakości właściwej dla określonego segmentu systemów, odnoszące się do głównych cech funkcjonalnych pozostających w ofercie spośród kręgu Wykonawców oferujących tego typu rozwiązania.

XXII. ODRZUCENIE OFERTY

1. Zamawiający odrzuci ofertę, w przypadku zaistnienia okoliczności, o których mowa w art. 226 ust. 1 ustawy.

Załącznik nr 2.1-zmiana -wniosek 4114/APU/2025 OPIS PRZEDMIOTU ZAMÓWIENIA 8.System musi przechowywać przez 365 180 dni i umożliwiać przeszukiwanie z konsoli i via API co najmniej następujące typy indykatorów (ang. Indicators of Compromise): hashe SHA256 i MD5, adresy IPv4 i IPv6 oraz nazwy domenowe domena.

1. System musi posiadać możliwość instalacji agenta na co najmniej następujących systemach operacyjnych:
2. Microsoft: b)Windows 10 (x86-64 oraz arm64) 34.System musi umożliwiać zdalną izolację sieciową endpointa. W trakcie trwania izolacji sieciowej cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany.
3. Agent musi posiadać możliwość usuwania złośliwych makr wykrytych w plikach Microsoft Word i Microsoft Excel.
4. Agent musi automatycznie wykonywać skanowanie pamięci masowej natychmiast po jej podłączeniu do portu USB.

Wyjaśnienia treści SWZ:

Pytanie nr 2 Punkt:

1. System musi przechowywać przez 365 dni i umożliwiać przeszukiwanie z konsoli i via API co najmniej następujące typy indykatorów (ang. Indicators of Compromise): hashe SHA256 i MD5, adresy IPv4 i IPv6 oraz nazwy domenowe domena.

Pytanie:

Czy przez „przechowywanie i przeszukiwanie IoC” Zamawiający rozumie wyłącznie dane dotyczące alertów bezpieczeństwa, czy również pełną telemetrię z monitorowanych stacji roboczych i serwerów, obejmującą aktywności niebędące alertami?

Czy Zamawiający dopuszcza, aby system umożliwiał przechowywanie i przeszukiwanie danych w okresie 186 dni lub 30 dni, w zależności od rodzaju danych oraz licencjonowania?

Odpowiedź na pytanie nr 2:

Zamawiający dokonuje zmiany Załącznika 2.1 do SWZ, poprzez nadanie brzmienia w ust. 7 i 8:

1. System musi przechowywać informacje o alarmach i incydentach co najmniej przez 90 30 dni.
2. System musi przechowywać przez 365 180 dni i umożliwiać przeszukiwanie z konsoli i via API co najmniej następujące typy indykatorów (ang. Indicators of Compromise): hashe SHA256 i MD5, adresy IPv4 i IPv6 oraz nazwy domenowe domena.

Odpowiedź na pytanie nr 17:

Tak, Zamawiający uzna ofertę za spełniającą wymagania, jeżeli system XDR nie będzie zapewniał wsparcia dla wycofanych lub obecnie wycofywanych systemów operacyjnych, jednocześnie wspierając nowsze wersje wymienionych systemów.

Zamawiający dokonuje zmiany Załącznika 2.1 do SWZ, poprzez nadanie brzmienia w ust. 10:

1. System musi posiadać możliwość instalacji agenta na co najmniej następujących systemach operacyjnych:
2. Microsoft: a) Windows 7 SP1 b) Windows 10 (x86-64 oraz arm64) c) Windows 11 (x86-64 oraz arm64)

d) Server 2008 R2 SP1 e) Server 2012 i 2012 R2 f) Server 2016 i Server Core 2016 g) Server 2019 i Server Core 2019 h) Server 2022 i Server Core 2022

1. Linux a) CentOS 6, 7 i 8 b) Debian 9,10, 11 i 12 c) Oracle Linux 6, 7, 8 i 9 d) Red Hat Enterprise Linux 6, 7, 8 i 9 e) Red Hat Enterprise CoreOS 4 f) Rocky Linux 8 i 9 g) SUSE 11, 12 i 15 h) Ubuntu 14, 16, 18, 20 i 22
2. Apple macOS a) macOS Monterey 12 b) macOS Ventura 13 c) macOS Sonoma 14
3. Apple iOS 18x lub nowszy 15.x, 16.x i 17.x
4. Android 12.x, 13.x i 14.x Oferta przystępującego:
5. Składając ofertę w postępowaniu o udzielenie zamówienia publicznego, oferuję wykonanie zamówienia - Dostawę z uruchomieniem narzędzi do zarządzania bezpieczeństwem klasy XDR:

Producent (marka) Palo Alto Networks(Należy podać) Nazwa, wersja Cortex XDR Pro: 1. PAN-XDR-PRO-GB; 2. PAN-XDR-ADV-EP; 3. PAN-XDR-FRNS (Należy podać) spełniającego wymagania określone w Opisie Przedmiotu Zamówienia, stanowiącym Załącznik nr 2.1 do SWZ

1. Oświadczam, że oferowany system spełnia wszystkie wymagania określone w Załączniku nr 2.1 do SW Z – Opis Przedmiotu Zamówienia.

12 stycznia 2026 r. zamawiający skierował wezwanie w trybie arrt. 223 ust. 1 do przystępującego o treści:

Zamawiający powziął informację, wskazującą na niezgodność oferty z warunkami zamówienia.

Mając na uwadze powyższe Zamawiający zwraca się o wyjaśnienie w poniższym zakresie:

1. Zgodnie z p. 10.1.b. Załącznika 2.1 Opis Przedmiotu Zamówienia XDR - zmiana „System musi posiadać możliwość instalacji agenta na co najmniej następujących systemach operacyjnych:
2. Microsoft: a) Windows 7 SP1 b) Windows 10 (x86-64 oraz arm64)” Zgodnie z dokumentacją do rozwiązania Cortex XDR firmy Palo Alto zamieszczoną na stronieagent Cortex XDR nie jest dostępny dla Windows 10 dla architektury arm64.

W tabeli dostępnych systemów operacyjnych uwidocznione są tylko wersje Windows 10 dla architektury x86-64.

W tym miejscu zamawiający zamieścił print screen z powołanej strony producenta.

Architektura arm64 jest wspierana tylko dla Windows 11, co jest wprost wskazane w tabeli uwidocznionej w dokumentacji na podanej powyżej stronie Palo Alto.

Tu także zamieszczono print screen Powyższe wskazuje, że rozwiązanie Cortex XDR nie spełnia wymagania 10.1.b postawionego przez Zamawiającego w Załączniku 2.1 Opis Przedmiotu Zamówienia.

1. Zgodnie z p. 34. Załącznika 2.1 Opis Przedmiotu Zamówienia XDR - zmiana „System musi umożliwiać zdalną izolację sieciową endpointa. W trakcie trwania izolacji sieciowej cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany Zgodnie z dokumentacją do rozwiązania Cortex XDR firmy Palo Alto zamieszczoną na stronie https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-4.x-Documentation/Initiate-a-Live-Terminal-session w sekcji „Isolate an endpoint” wskazane jest, iż w przypadku stosowania rozwiązania Cortex XDR izolowana stacja końcowa zachowuje połączenie z konsolą zarządzającą systemu oraz dostęp do usług DNS, a dodatkowo na serwerach Linux dopuszcza wychodzące połączenia HTTPS dla procesów użytkownika root.

Znajduje to swoje odzwierciedlenie w zapisie

Tu zamieszczono print screen

Tłumaczenie:

„Wyizolowanie punktu końcowego Gdy izolujesz punkt końcowy, dochodzi do zablokowania dostępu do sieci z tego urządzenia końcowego z wyjątkiem ruchu do Cortex XDR. Służy to temu, aby skompromitowane urządzenie końcowe nie miało możliwości komunikacji z innymi punktami końcowymi, ograniczając mobilność atakującego w Twojej sieci. Po otrzymaniu przez agenta instrukcji by izolować urządzenie końcowe i wykonaniu tej akcji, Cortex XDR wskazuje statusIzolowany. Aby zapewnić, że urządzenie końcowe pozostanie w izolacji, w czasie jej trwania dla izolowanych urządzeń nie są dostępne aktualizacje oprogramowania agenta.

Po izolacji punkt końcowy nadal pozwala na: • Ruch wychodzący DHCP i HTTPS dla użytkownika root • Ruch DNS” Stoi to w sprzeczności z wymaganiem 34, zgodnie z którym Zamawiający wskazał, że cały ruch poza połączeniem do systemu oraz protokołem DHCP musi zostać zablokowany.

Jednocześnie nie można uznać, że ruch DNS czy HTTPS jest ruchem kierowanym wyłącznie do konsoli zarządzającej systemu XDR.

1. Zgodnie z p. 8. Załącznika 2.1 Opis Przedmiotu Zamówienia XDR – zmiana „System musi przechowywać przez 365 180 dni i umożliwiać przeszukiwanie z konsoli i via API co najmniej następujące typy indykatorów (ang. Indicators of Compromise): hashe SHA256 i MD5, adresy IPv4 i IPv6 oraz nazwy domenowe domena.”

Zgodnie z dokumentacją do rozwiązania Cortex XDR firmy Palo Alto zamieszczoną na stroniesystem ten nie daje możliwości przeszukiwania indykatorów za pośrednictwem API.

1. Zgodnie z p. 77. Załącznika 2.1 Opis Przedmiotu Zamówienia XDR - zmiana „Agent dla systemów Windows, MacOS i Linux musi zbierać i wysyłać do systemu co najmniej następujące dane telemetryczne:
2. Utworzenie nowego procesu i zakończenie procesu
3. Operacje na socketach sieciowych dla TCP i UDP
4. Operacje na plikach
5. Zdarzenia z event logu dotyczącego uwierzytelnienia.
6. Operacje na rejestrze (tylko systemy Windows)” Zgodnie z dokumentacją do rozwiązania Cortex XDR firmy Palo Alto zamieszczoną na stronieDocumentation/Endpointdata-collection?tocId=0d1SBdboAHhrDkltBslZMw zbieranie i wysyłanie danych telemetrycznych z systemów Linux i MacOS w zakresie wymagania 77.3 oraz 77.4 wymaga zastosowania dedykowanego dodatku licencjonowanego per urządzenie końcowe, pod nazwą Extended Threat Hunting (dalej opisywany również jako XTH).

Wymóg związany z koniecznością „dozbrojenia” systemu w dodatek XTH jest uwidoczniony zarówno w sekcji dla MacOS jak i dla Linux (we wskazanej dokumentacji).

To zamawiający zamieścił print screen Dla Maos Dla Linux Zdanie „Requires XTH add-on” należy tłumaczyć jako „Wymaga dodatku XTH” XTH jest opcją dodatkowo licencjonowaną przez Palo Alto, nie jest on wliczony standardowo w koszt licencji XDR, a także jako dodatek ma swoją pozycję cennikową (tzw. part-number, opis oraz cenę za każde urządzenie końcowe) PAN-XDR-XTH Extended Threat Hunting (enhanced visibility) add-on for Cortex XDR ProEP/Cloud (price per Endpoint).

Includes 30 days of data retention.

Tłumacząc opis tej licencji możemy przeczytać, że jest to „Dodatek Extended Threat Hunting (zwiększona widoczność) dla Cortex XDR ProEP/Cloud (cena za punkt końcowy). Obejmuje 30 dni retencji danych.”

Kluczowym jest tutaj jednoznaczne wskazanie w opisie, że jest to element dodatkowy względem Cortex XDR ProEP/Cloud (co jednocześnie potwierdza, że nie jest on wliczony w cenę licencji Cortex XDR Pro i objęty jednym i tym samym kodem produktu) Zgodnie ze złożonym Formularzem Ofertowym firma Clockwise jako Wykonawca zadeklarowała zaoferowanie/wolę dostarczenia Zamawiającemu następujących licencji (podajemy numery katalogowe Palo Alto wraz z opisem):

PAN-XDR-PRO-GB Cortex XDR Pro for daily ingested GB. Includes 30 days of ingested data retention, 180 days of alerts and incidents retention and standard success PAN-XDR-ADV-EP Cortex XDR Pro for 1 endpoint, includes 30 days of data retention and standard success

PAN-XDR-FRNS Annual Forensics add-on for 1 Cortex XDR endpoint, includes 30 days of data retention Nie ma wśród nich licencji na dodatek XTH, którego brak powoduje, że zaoferowane przez firmę Clockwise rozwiązanie Cortex XDR nie spełnia wymagania 77 postawionego przez Zamawiającego w Załączniku 2.1 Opis Przedmiotu Zamówienia.

Wyjaśnienia w powyższym zakresie należy złożyć, w terminie do dnia 16.01.2026 r.

Przystępujący przedstawił następujące wyjaśnienia:

Odpowiedź do punktu 1:

Zgodnie z p. 10.1.b. Załącznika 2.1 Opis Przedmiotu Zamówienia XDR – zmiana.

„System musi posiadać możliwość instalacji agenta na co najmniej następujących systemach operacyjnych:

1. Microsoft: Windows 7 SP1 Windows 10 (x86-64 oraz arm64) ” Powołując się na dokumentacje Producenta, opisujące najnowsze aktualizacje oprogramowania Cortex XDR Agent w wersji 9.0,: informuje, iż aktualnie wsparcie dla systemów operacyjnych Windows opartych na procesorach ARM w oferowanym rozwiązaniu XDR jest dostępne. Tu zamieścił fragment dokumentacji zaznaczając XDR Agent for Windows on ARM64 Extend the industry leading prevention and detection capabilities of Cortex XDR to Windows endpoints running on ARM processors.

Odpowiedź do punktu 2:

Zgodnie z p. 34. Załącznika 2.1 Opis Przedmiotu Zamówienia XDR - zmiana „System musi umożliwiać zdalną izolację sieciową endpointa. W trakcie trwania izolacji sieciowej cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany” Powołując się na dokumentację Producenta, dostępną w poniższej dokumentacji:

Według naszej wiedzy, dobrych praktyk i naszego doświadczenia związanego z wdrażanie rozwiązań Cortex XDR, wymóg „w trakcie izolacji cały ruch sieciowy z wyjątkiem połączenia do systemu oraz protokołu DHCP musi zostać zablokowany” jest spełniony, ponieważ rozwiązanie w trybie izolacji blokuje ruch sieciowy endpointa z wyjątkiem kanału komunikacji z systemem zarządzającym oraz DHCP. W dokumentacji znajduje się zapis "When you isolate an endpoint, you halt all network access on the endpoint except for traffic to Cortex XDR."(tłum. „Izolując punkt końcowy, zatrzymujesz cały dostęp do sieci na tym punkcie, z wyjątkiem ruchu do Cortex XDR.”).