KIO 3098/24 WYROK Warszawa, dnia 20 września 2024 r.

Stan prawny na dzień: 20.11.2024

Sygn. akt: KIO 3098/24 
 

WYROK 

Warszawa, dnia 20 

września 2024 r. 

Krajowa Izba Odwoławcza  -   w składzie: 

Przewodnicząca: 

Izabela Niedziałek-Bujak 

 Protokolant:   

Rafał Komoń 

po  rozpoznaniu  na  rozprawie  w  dniu  16 

września  2024  r.  w  Warszawie  odwołania 

wniesionego 

do  Prezesa  Krajowej  Izby  Odwoławczej  w  dniu  26  sierpnia  2024  r.  przez 

Odwołującego – Wykonawcę Prosystem Spółka Akcyjna, ul. Zygmunta Wróblewskiego 12, 

627  Wrocław,  w  postępowaniu  prowadzonym  przez  Zamawiającego  –  Centrum 

Informatyki Resortu Fi

nansów, ul. Samorządowa 1, 26-601 Radom  

przy  udziale  przystępującego  po  stronie  Zamawiającego  –  Wykonawcy  IT  Solution  Factor 

Spółka z ograniczoną odpowiedzialnością, al. Jerozolimskie 98, 00-807 Warszawa 

orzeka: 

Oddala odwołanie. 

Kosztami postępowania odwoławczego obciąża Odwołującego – Prosystem S.A. z/s we 

Wrocławiu i zalicza w poczet kosztów postępowania odwoławczego kwotę  15.000 zł 00 

gr. 

(słownie:  piętnaście  tysięcy  złotych,  zero  groszy)  uiszczoną  przez  Odwołującego 

tytułem wpisu od odwołania.  

Na  orzeczenie  - 

w  terminie  14  dni  od  dnia  jego  doręczenia  -  przysługuje  skarga  za 

pośrednictwem  Prezesa  Krajowej  Izby  Odwoławczej  do  Sądu  Okręgowego  w  Warszawie  - 

Sądu Zamówień Publicznych. 

Przewodnicząca: 

……………………………… 


Sygn. akt: KIO 3098/24 
 

U z a s a d n i e n i e 

W  postępowaniu  prowadzonym  przez  Zamawiającego  –  Centrum  Informatyki  Resortu 

Finansów  z  siedzibą  w  Radomiu,  w  trybie  podstawowym  na  dostawę  oprogramowania 

antywirusowego  dla  DataCenter 

(nr  postępowania:  PN/4/24/HYDB),  ogłoszonym  w 

Dzienniku  Urzędowym  Unii  Europejskiej  w  dniu  08.04.2024  r.,  S  69/2024  204407,  wobec 

czynności oceny ofert, wyboru oferty najkorzystniejszej, wniesione zostało w dniu 26.08.2024 

r. do Prezesa Krajowej Izby Odwoławczej odwołanie Wykonawcy Prosystem S.A. z siedzibą 

we Wrocławiu (sygn. akt KIO 3098/24). 

Odwołujący zarzucał Zamawiającemu naruszenie  

1)  naruszenie  art.  art.  91  ust.  1  w  zw.  z    oraz  art.  226  ust.  1  pkt  5  oraz  art.  223  ust.  1 

ustawy Pzp 

– poprzez:  

•  zaniechanie  wezwania  do  wyjaśnień  treści  oferty  złożonej  przez  Wykonawcę  IT 

Solution Factor sp. z o.o. 

z siedzibą w Warszawie (dalej „IT Solution”), mimo iż oferta 

nie spełnia wymagań stawianych przez Zamawiającego;  

•  zaniechanie  odrzucenia  oferty  złożonej  przez  IT  Solution,  mimo  iż  nie  jest  ofertą, 

która  spełniałaby  wszystkie  wymagania  określone  w  SWZ  i  dokumentacji 

postępowania;  

•  wybór  i  uznanie  za  najkorzystniejszą  ofertę  złożoną  przez  IT  Solution,  mimo  iż 

powinna ona zostać odrzucona jako oferta, która nie spełnia wymagań określonych w 

SWZ i dokumentacji postępowania;  

2)  naruszenie art. art. 91 ust. 1 ustawy w zw. z  oraz art. 226 ust. 1 pkt 5 oraz art. 223 ust. 

1 ustawy Pzp 

– poprzez:  

•  zaniechanie wezwania do złożenia wyjaśnień treści oferty złożonej przez Wykonawcę 

Trafford  IT  sp.  z  o.  o.,  sp.  k. 

z  siedzibą  w  Warszawie  (dalej  „Trafford  IT”),  mimo  iż, 

oferta nie spełnia wymagań stawianych przez Zamawiającego;  

•  zaniechanie odrzucenia oferty złożonej przez Trafford IT, mimo iż nie jest ofertą, która 

spełniałaby wszystkie wymagania określone w SWZ i dokumentacji postępowania;  

•  przyznanie punktów ofercie złożonej przez Trafford IT, mimo iż powinna ona zostać 

odrzucona  jako  oferta,  która  nie spełnia  wszystkich  wymagań  określonych  w  SWZ  i 

dokumentacji postępowania;  

3)  naruszenie  art.  16  ustawy  Pzp 

–  poprzez  prowadzenie  postępowania  w  sposób 

sprzeczny z zasadami uczciwej konkurencji i równego traktowania wykonawców.  


Odwołujący wnosił o  uwzględnienie  odwołania  w  całości,  nakazanie  unieważnienia 

czynności wyboru oferty najkorzystniejszej oraz nakazanie odrzucenia ofert złożonych przez 

IT  Solution  oraz  Trafford  IT

,  a  także  nakazanie  dokonania  ponownego  wyboru  oferty 

najkorzystniejszej, 

tj. oferty Odwołującego.  

W  przypadku  natomiast  gdyby  Izba  stwierdziła  konieczność  uprzedniego  wezwania 

wykonawców  Trafford  IT  oraz  IT  Solution  do  wyjaśnień  treści  złożonych  ofert  Odwołujący 

wnosi

ł  o  nakazanie  dokonania  unieważnienia  czynności  wyboru  oferty  najkorzystniejszej 

oraz o nakazanie wezwania wykonawców IT Solution oraz Trafford IT do złożenia wyjaśnień 

w  zakresie  złożonych  ofert,  a  następnie  nakazanie  uznania,  że  ich  oferty  podlegają 

odrzuceniu, gdyż nie spełniają wymogów stawianych przez Zamawiającego w dokumentach 

postępowania.   

I. 

Zarzuty dotyczące oferty złożonej przez IT Solution  

Zdaniem Odwołującego zaoferowane oprogramowanie Trend Vision One - Endpoint Security 

(Essentials  )  producent  Trend  Micro

,  nie  spełnia  wymagań  określonych  przez 

Zamawiającego w OPZ. 

Produkt  „Trend  Vision  One  -  Endpoint  Security  (Essentials  )“  to  pakiet  zawierający  dwa 

produkty  do  ochrony  endpoint:  Standard  Endpoint  Protection 

–  ochrona  desktopów: 

Windows,  macOS  oraz  Server  and  Workload  Protection 

–  ochrona  serwerów:  Windows, 

Linux. 

Oba  produkty  posiadają  osobne  agenty,  konsole  zarządzające,  polityki  i 

funkcjonalności.  

Część  wymagań  OPZ  jest  spełniona  tylko  przez  jeden  z  tych  produktów,  np.  wsparcie  dla 

systemów  Linux  jest  jedynie  w  produkcie  Server  and  Workload  Protection,  a  wymaganie  z 

Funkcjonalność  F1  będący  kryterium  oceny  („możliwość  przywracania  zaszyfrowanych 

plików  po  ataku  Ransomware  dla  systemów  Windows”)  spełniany  jest  tylko  przez  produkt 

Standard Endpoint Protection. W takim wypadku rozwiązanie nie powinno zostać uznane za 

spełniające wymagania SWZ, ponieważ są to dwa osobne produkty, z osobnymi politykami i 

zarządzaniem.  Jedynie  produkt  XDR  (w  OPZ  jak  EDR)  czyli  wykrywania  zagrożeń  na 

podstawie zgromadzonych logów i telemetrii, obejmuje wszystkie stacje.  

Wymagania w OPZ odnośnie EDR to tylko 9 punktów, tj. Rozdział II, punkty od 3.1 do 

Pozostałe punkty dotyczą ochrony antymalware i zarządzania stacjami końcowymi i nie 

jest  możliwe  obsłużenie  pojedynczej  stacji  końcowej  przez  oba  produkty,  ponieważ  musi 

zostać wybrany jeden z nich.   

Dodatkowo  Zamawiający  w  OPZ,  Rozdział  II,  punkt  5.1  wymaga  pojedynczego 

agenta.  


Natomiast 

panel  Trend  Vision  One  przedstawia  osobne  konsole  zarządzania  „Standard 

Endpoint  Protection”  i  „Server  and  Workload  Protection”  umieszczone  w  sekcji  „Endpoint 

Security”.  

Dodatkowo wymaganie Zamawiającego wyraźnie określa w OPZ, Rozdział II, punkt 7 

pkt  12 

„Wymagania  w  zakresie  konsoli  Centralne  Zarządzanie“,  że  centralne  zarządzanie 

dotyczy  m.in.  „dodawania  własnych  wpisów  w  ramach  modułów  kontroli  sieci  oraz  kontroli 

urządzeń  (punkt  7.10)  czy  „filtrowania  stacji  końcowych  na  których  został  zainstalowanych 

agent“  Posiadając  agenty  w  dwóch  różnych  rozwiązaniach  nie  jest  możliwe  spełnienie 

wymaganych przez Zamawiającego zapisów.  

Oferowane rozwiązania Trend Micro nie spełniają opisu dodatkowych funkcjonalności 

zapisanych 

„Tom_I_SWZ_Instrukcja_dla_Wykonawcy_08-04-2024_10.16.29”, 

zaznaczonych przez Oferenta jako spełnione:  

a) w zakresie „Funkcjonalność F1”  

„Funkcjonalność F1  

Oprogramowanie  zapewnia  możliwość  przywracania  zaszyfrowanych  plików  po  ataku 

Ransomware dla systemów Windows“  

Trend  Micro  łączy  funkcjonalności  dwóch  różnych  produktów  „Standard  Endpoint 

Protection”  i  „Server  and  Workload  Protection”  w  paczce  Trend  Vision  One  Essentials. 

Przywracanie  zaszyfrowanych  plików  jest  możliwe  w  produkcie  Standard  Endpoint 

Protection, który m.in. nie obsługuje systemów Linux i ma zupełnie inne funkcjonalności niż 

produkt Server and Workload Protection, który obsługuje systemy Linux.  

Do obu tych produktów jest osobny agent i oddzielne zarządzanie. W konsoli TM jest 

wyraźne  rozróżnienie  na  „Standard  Endpoint  Protection  Manager”  i  „Server  and  Workload 

Protection  Manager”.  W  celu  zapewnienia  odzyskiwania  plików  trzeba  umieścić  stacje  w 

osobnym, dedykowanym dla desktopów produkcie „Standard Endpoint Protection Manager” i 

zarządzać nimi z tego miejsca. Polityki, grupy, ustawienia, notyfikacje itd. są zupełnie inne i 

nie synchronizują się pomiędzy produktami.  

Możliwość przywracania zaszyfrowanych plików po ataku Ransomware jest dostępna 

tylko w produkcie „Standard Endpoint Protection Manager”. Zgodnie z OPZ rozwiązanie ma 

wspierać  systemy  Windows  i  Linux,  np.  Rozdział  II,  punkt  5.6.  „możliwość  automatycznej 

aktualizacji  agentów  zainstalowanych  na  stacjach  końcowych  z  systemem  operacyjnym: 

Microsoft  Windows  oraz  Linux;”.  Oferta  zawierająca  rozwiązanie  Trend  Micro  nie  spełnia 

jednocześnie wszystkich punktów OPZ.  

W  OPZ  jest  położony  duży  nacisk  na  Centralną  Konsolę  Zarządzania  i  jej 

funkcjonalności  (OPZ,  Rozdział  II,  punkt  „7.  Wymagania  w  zakresie  konsoli  Centralne 

Zarządzanie:”).  A  zatem  nie  jest  możliwe  dopuszczenie  rozwiązania,  które  część 

funkcjonalności  spełnia  w  jednej  konsoli  zarządzającej  a  część  w  drugiej.  Zarządzając 


systemami  Windows  w  konsoli  „Standard  Endpoint  Protection  Manager”,  żeby  spełnić 

Funkcjonalność  F1,  oraz  systemami  Linux  w  konsoli  „Server  and  Workload  Protection 

Manager”  (bo  tylko  ta  konsola  może  zarządzać  Linuxami)  nie  spełnione  są  punkty 

centralnego  zarządzania  zawarte  w  OPZ  takie  jak  7.8,  7.10,  7.14,  7.15,  7.16,  7.17,  7.19. 

Samo słowo „manager”, tj. menadżer w nazwach „Standard Endpoint Protection Manager” i 

„Server and Workload Protection Manager” wskazuje na oddzielne zarządzanie. Posiadanie 

części stacji w jednej a części w drugiej konsoli zarządzającej powoduje, że nie są spełnione 

punkty  OPZ  „6.  Zarządzanie  Politykami  Bezpieczeństwa  musi  uwzględnić:”.  Opisują  one 

tworzenie  polityk  czy  list  kontroli  sieci. 

Nie  można  stworzyć  polityki  czy  listy  kontroli  sieci 

obejmującej  system  Windows  i  Linux  oraz  spełniającej  Funkcjonalność  F1.  Z  kolei 

wymagane  są  wszystkie  z  tych  trzech  zapisów  (Funkcjonalność  F1  jest  wymagana, 

ponieważ Oferent wskazał ją jako spełnioną).  

b) w zakresie Tomu III SWZ  

O

ferowane 

rozwiązanie 

TM 

nie 

spełnia 

wymagań 

„Tom_III_SWZ_-

_Opis_przedmiotu_zamowienia_wersja_ujednolicona_13-

052024_09.31.29.pdf”   

Rozdział II OPZ, punkt 4.3  

„Automatyczna  Reakcja  i  Izolacja  Zagrożeń  musi  posiadać:  „zestaw  silników  które  można 

włączać lub wyłączać;”  

W rozwiązaniu nie można wyłączyć silników jako automatyczna reakcja ani podczas 

izolacji zagrożeń. Wszystkie możliwe czynności dla automatycznej reakcji i izolacji zagrożeń 

Odwołujący przedstawił na zrzucie ekranu z oferowanych rozwiązań Tren Micro. Nie ma tu 

możliwości wyłączania lub włączania zestawu silników czego wymaga Zamawiający.  

Rozdział II OPZ, punkt 4.5  

„możliwość  przeniesienia  do  kwarantanny  złośliwych  plików  należących  do  tego  samego 

incydentu.  Funkcja  kwarantanny  musi  zatrzymać  procesy,  szyfrować  plik  wykonywalny  i 

przenieść go na ograniczoną ścieżkę;”  

Oferowane  rozwiązania  Trend  Micro  nie  zawierają  opcji  przeniesienia  wszystkich 

plików z incydentu do kwarantanny. Pliki w incydencie można dodać do listy blokowania, co 

nie  jest  jednoznaczne  z  kwarantanną,  dodawać  pliki  można  tylko  pojedynczo.  Odwołujący 

przedstawił  zrzut  z  ekranu  z  konsoli  Trend  Micro,  gdzie  widoczna  jest  możliwość  dodania 

pliku do listy blokowania. 

W dostępnych opcjach oferowane rozwiązanie nie posiada możliwości przeniesienia 

do  kwarantanny  złośliwych  plików  należących  do  tego  samego  incydentu  czego  wymaga 

Zamawiający.  

Rozdział II OPZ, punkt 5.1  


„Jedno  plikowy  agent  AV,  który  musi  być  w  pełni  autonomiczny,  co  oznacza,  że  jego 

działanie  i  funkcjonalność  nie  może  być  zależna  od  serwera  zarządzania,  chmury  ani 

ŻADNYCH zasobów zewnętrznych od agenta;”  

Brak  Internetu  uniemożliwia  oferowanym  rozwiązaniom  Trend  Micro  działanie 

funkcjonalności:  behavior  monitoring  (tłumaczenie  z  ang.:  monitorowanie/analiza 

behawioralna),  predictive  machine  learning  (tłumaczenie  z  ang.:  predyktywne  uczenie 

maszynowe),  i  process  memory  scanning  (tłumaczenie  z  ang.:  skanowanie  procesów  w 

pamięci).  

„If  your  agents  or  relays  don't  have  access  to  the  internet  (also  called  "air-gapped 

agents"), then they won't be able to access several of the security services provided by the 

Trend Micro Smart Protection Network. These security services are necessary for the full and 

successful operation of the Server & Workload Protection Anti-Malware and Web Reputation 

features. The Trend Micro Smart Protection Network security services are:   

Jeśli agenci lub przekaźniki nie mają dostępu do Internetu (zwani również „agentami 

ze  szczeliną  powietrzną”),  nie  będą  mogli  uzyskać  dostępu  do  kilku  usług  zabezpieczeń 

świadczonych  przez  Trend  Micro  Smart  Protection  Network.  Te  usługi  bezpieczeństwa  są 

niezbędne  do  pełnego  i  pomyślnego  działania  funkcji  Server  &  Workload  Protection  Anti-

Malware i Web Reputation. 

Usługi bezpieczeństwa Trend Micro Smart Protection Network to:  

Smart Scan Service   Smart Scan  

Web Reputation Service  

Web Reputation  

Global Census Service  

Behavior monitoring, predictive machine learning  

Good File Reputation Service  

Behavior  monitoring,  predictive  machine  learning, 

process memory scans  

Predictive Machine Learning Service  

Predictive machine learning  

„Źródło: 

https://docs.trendmicro.com/en-us/documentation/article/trend-vision-one-

agent-airgapped

Z  oficjalnej  dokumentacji  producenta  Trend  Micro  wynika,  że  najważniejsze 

funkcjonalności, takie jak monitorowanie behawiorystyczne i uczenie maszynowe nie działają 

przy  braku  dostępu  do  zasobu  zewnętrznego  jakim  jest  chmura,  tj.  Internet  a  takiej  pracy 

produktu wymaga Zamawiający.  

Rozdział II OPZ, punkt 5.9.2  

„funkcjonalność automatycznej aktualizacji, która musi pozwalać na wybór stacji końcowych 

które  powinny  zostać  zaktualizowane  posiadając  możliwość  wyboru  co  najmniej:  jedynie 

stacji końcowych z wybranym tag-iem;” 

Oferowane rozwiązania Trend Micro nie spełniają tego zapisu.  

Standard  Endpoint  Protection  Manager  posiada  tagowanie  endpointów,  ale  nie  ma 

możliwości  definiowania  aktualizacji  na  podstawie  tagów.  Server  and  Workload  Protection 


Manager  ma  tagi  tylko  dla  zdarzeń/logów,  nie  ma  dla  endpointów.  Odowłujący  załączył 

zrzuty 

ekranu z interfejsu oferowanych rozwiązań Trend Micro. Widać na nich, że w opcjach 

automatycznej aktualizacji nie można wybrać stacji końcowych podlegających aktualizacji na 

podstawie tagu czego wymaga Zamawiający.  

Rozdział II OPZ, punkt 5.12  

„możliwość zdefiniowania maksymalnej liczby stacji końcowych pobierających jednocześnie 

paczkę aktualizacyjną;”  

Oferowane  rozwiązania  Trend  Micro  nie  spełniają  tego  zapisu,  nie  ma  takiej  opcji. 

Brak  tej  opcji  jest  widoczny  na  zrzutach  ekranu  z  oferowanych  rozwiązań  Trend  Micro. 

Pośród  wszystkich  dostępnych  opcji  nie  ma  opcji  definiowania  maksymalnej  liczby  stacji 

końcowych pobierających jednocześnie paczkę aktualizacyjną.  

Rozdział II OPZ, punkt 5.18  

„informacje  dla  każdego  pakietu  instalacyjnego,  które  muszą  zawierać  co  najmniej 

następujące dane:  

5.18.1 wersja główna,  

5.18.2 numer buildu,  

5.18.3 rozszerzenie pliku,  

5.18.4 nazwa pliku,  

5.18.5 data opublikowania,  

5.18.6 platforma”  

Informacje  zawarte  w  punktach  od  5.18.1  do  5.18.6  nie  są  wyświetlane  w  Standard 

Endpoint  Protection  Manager  a  w  Server  and  Workload  P

rotection  Manager  nie  ma  „daty 

opublikowania”. 

W  kolumnach  tabeli  zawierającej  pakiety  instalacyjne  są  kolumny  „Nazwa”, 

„Platforma”,  „Wersja”,  „Typ  publikacji”  i  „Data  importu”.  Nie  istnieje  kolumna  „Data 

opublikowania” czego wymaga Zamawiający. Data importu jest myląca dla administratorów, 

ponieważ  może  być  różna  dla  tego  samego  pakietu  (np.  przy  ponownym  pobraniu)  i 

niezgodna  chronologicznie  w  porównaniu  z  datą  opublikowania,  np.  starszy  pakiet 

instalacyjny  może  być  zaimportowany  później  niż  nowszy.  Data  opublikowania  jest 

niezmienna i niezależna od momentu pobrania pakietu instalacyjnego.  

Rozdział II OPZ, punkt 6.10  

„możliwość  stopniowania  poziomu  wyjątków  dla  wyjątków  typu  "Ścieżka"  w  systemie 

Windows , co najmniej w następującym zakresie:  

6.10.1 w

ygaszenie alarmów,  

6.10.2 zredukowanie monitorowania konkretnego procesu,  

6.10.3 zredukowanie monitorowania konkretnego procesu i jego procesów potomnych,  

6.10.4 wyłączenie monitorowania konkretnego procesu,  


6.10.5 wyłączenie monitorowania konkretnego procesu i jego procesów potomnych;”  

Oferowane rozwiązania Trend Micro nie spełniają tego zapisu opcji 6.10.1 do 6.10.5 

dla  ścieżki/path  systemu  Windows,  co  przedstawiono  na  zrzutach  ekranu.  Na  zrzutach 

ekranu  widoczne  są  opcje  konfiguracji  wyjątków  typu  „ścieżka”  w  systemie,  nie  ma  jednak 

opcji  przedstawionych  w  podpunktach  6.10.1  do  6.10.5  czyli  możliwości  określenia  stopnia 

poziomu wyjątku tego typu.  

Z

rzuty ekranów pochodzą z konfiguracji polityki w produktach ochrony antymalware. 

Funkcjonalność  XDR  jest  osobna  i  niezależna  od  produktów  Standard  Endpoint  Protection 

Manager  i  Server  and  Workload  Protection  Manager. 

W  konsoli  oferowanych  rozwiązań 

Trend  Micro,  w  opcjach  wykrywania  zagrożeń  za  pomocą  XDR  są  opcje  6.10.1,  6.10.4, 

6.10.5.  Podpunkt  6.10  należy  do  punktu  „6.  Zarządzanie  Politykami  Bezpieczeństwa  musi 

uwzględnić:”  czyli  do  ustawień  polityk.  Jeżeli  w  wykrywaniu  zagrożeń  za  pomocą  telemetrii 

XDR zostaną wprowadzone wyjątki, to nie będą one działać podczas wykrywania zagrożeń 

bezpośrednio  w  produktach  Standard  Endpoint  Protection  Manager  i  Server  and  Workload 

Protection  Manager  czyli  w  rzeczywistym  oprogramowaniu  antywirusowym.  Dlatego  wyjątki 

możliwe  do  wprowadzenia  w  produkcie  XDR  nie  powinny  być  brane  pod  uwagę.  Jednak 

nawet,  uwzględniając  opcje  wyjątków  w  produkcie  XDR,  nie  są  spełnione  punkty  6.10.2, 

Rozdział II OPZ, punkt 6.11  

„rozwiązanie,  dla  wyjątków  typu  "Ścieżka"  w  systemie  Linux  musi  mieć  możliwość 

stopniowania poziomu wyjątków, co najmniej w następującym zakresie:  

6.11.1 wyga

szenie alarmów,  

6.11.2 wyłączenie monitorowania konkretnego procesu”  

Oferowane rozwiązania Trend Micro nie spełniają tego zapisu. Nie ma opcji 6.11.1 i 

6.11.2 dla ścieżki/path systemu Linux co przedstawiono na zrzutach ekranu  

Z

rzuty ekranów pochodzą z konfiguracji polityki w produktach ochrony antymalware. 

Funkcjonalność  XDR  jest  osobna  i  niezależna  od  produktów  Standard  Endpoint  Protection 

Manager  i  Server  and  Workload  Protection  Manager.  Opcje  opisane  w  punktach  6.11.1  i 

6.11.2  są  tylko  dostępne  w  wyjątkach  wykrywania  zagrożeń  za  pomocą  XDR,  nie  dla 

antywirusa/polityki  agenta.  Podpunkt  6.10  należy  do  punktu  „6.  Zarządzanie  Politykami 

Bezpieczeństwa musi uwzględnić:” czyli do ustawień polityk a w ustawieniach polityki nie ma 

opisanych  opcji.  Jeżeli  w  wykrywaniu  zagrożeń  za  pomocą  telemetrii  XDR  zostaną 

wprowadzone wyjątki, to nie będą one działać podczas wykrywania zagrożeń bezpośrednio 

w  produktach  Standard  Endpoint  Protection  Manager  i  Server  and  Workload  Protection 

Manager czyli w rzeczywistym oprogramowaniu antywirusowym. Dlatego wyjątki możliwe do 

wprowadzenia w produkcie XDR nie powinny być brane pod uwagę.  

Rozdział II OPZ, punkt 6.18  


„moduł  kontroli  sieci,  który  musi  być  zintegrowany  z  funkcjonalnością  tagowania  hostów  w 

oferowanym rozwiązaniu” 

Oferowane  rozwiązania  Trend  Micro  nie  spełniają  tego  wymagania.  Standard 

Endpoint Protection Manager posiada tagowanie endpointów ale nie można ich wykorzystać 

w  module  kontroli  sieci.  Server  and  Workload  Protection  Manager  posiada  tagi  tylko  dla 

zdarzeń/logów,  nie  ma tagowania dla endpointów.  Nie ma  integracji  modułu kontroli  sieci  z 

tagowaniem  hostów.  Możliwość  tagowania  ograniczająca  się  tylko  do  zdarzeń/logów  w 

produkcie Server and Workload Protection Manager przedstawiono na h zrzutach ekranu.  

Tylko dla zdarzeń, które na zrzucie są widoczne jako kolejne rzędy, można dodać tag 

(„Add Tag(s)”).  

Rozdział II OPZ, punkt 6.20  

„interfejs  graficzny  modułu  kontroli  sieci,  który  musi  oferować  możliwość  importowania 

wybranych wyjątków dla kwarantanny sieciowej rozwiązania z pliku .json.”  

Oferowane  rozwiązania  Trend  Micro  nie  spełniają  tego  wymagania.  Rozwiązania 

Trend  Micro  potrafią  jedynie  zaimportować  plik  z  formatu  XML  co  przedstawiają  zrzuty 

ekranu z konsoli Trend Micro. Pokazują one możliwość eksportu reguł, w tym wyjątków czyli 

reguł  dopuszczających  ruch,  do  formatu  możliwego  do  zaimportowania  w  postaci  XML,  tj. 

„Export  to  XML  (For  Import)”  czyli  „Eksport  do  formatu  XML  (na  potrzeby  importu)”  oraz 

„Export  Selected  to  XML  (For  Import)”  czyli  „Eksport  wybranych reguł  do  formatu  XML (na 

potrzeby importu)”.  

Zrzut  przedstawia 

przykład  importowania  reguł,  w  tym  wyjątków  czyli  reguł 

dopuszczających ruch. Jedyna opcja dostępna do importu to „Import From File” czyli „Import 

z pliku”.   

Po  wyborze  opcji  „Import  z  pliku”  pojawia  się  okno  polecające  wybór  pliku  XML  do 

importu,  tj. 

„Please  select  an  XML  file  of  firewall  rules  to  import”  czyli  „Proszę  wybrać  plik 

XML reguł zapory sieciowej do importu”.  

XML to odmienny format pliku niż JSON. Posiada inną strukturę wewnętrzną. JSON 

(JavaScript  Object  Notation)  to  otwarty  standardowy  format  tekstowy  do  wymiany  danych. 

Podczas przetwarzania informacji JSON wykorzystuje mniej pamięci niż XML co powoduje, 

że JSON jest lepszym formatem do szybkiego przetwarzania dużych ilości danych. Nie jest 

możliwe  zastosowanie  tego  samego  analizatora  składniowego  (parsera)  do  obu  formatów 

jednocześnie co sprawia, że formaty JSON i XML nie są zamienne.  

Rozdział II OPZ, punkt 7.12  

„7.12  rozwiązanie  musi  mieć  możliwość  filtrowania  stacji  końcowych  na  których  został 

zainstalowanych agent, co najmniej z wykorzystaniem następujących parametrów:  

7.12.1 nazwa stacji końcowej,  


7.12.2 tag przypisany do stacji końcowej,  

7.12.3 system operacyjny stacji końcowej,  

7.12.4 wersja zainstalowanego agenta,  

7.12.5 typ stacji końcowej:  

7.12.5.1 desktop,  

7.12.5.2 serwer,  

7.12.6 domena MS Windows,  

7.12.7 czy agent połączony jest do konsoli zarządzania,  

7.12.8 stan zdrowia agenta,  

7.12.9 stan sieci stacji końcowej,  

7.12.10 czy było wykonane pełne skanowanie dysku,  

7.12.11 czy agent oczekuje na aktualizacje,  

7.12.12 architekturę systemu operacyjnego,  

7.12.13 rodzaj użytego instalatora,  

7.12.14 stan operacyjny,  

7.12.15 jakikolwiek ciąg znaków z domeny Microsoft Windows,  

7.12.16 MAC adres.,  

7.12.17 lokalny adres IP.”  

R

ozwiązania  Trend  Micro  nie  spełniają  punktów  7.12.2,  7.12.6,  7.12.9,  7.12.15. 

Z

rzuty  ekranu  pochodzą  z  różnych  konsol  zarządzania,  punkty,  które  nie  są  spełnione 

dotyczą wszystkich konsol.  

W  każdej  z  konsol  jest  tylko  część  wymienionych  parametrów.  Zarządzanie 

produktem w takim stanie jest niedopuszczalne i niezgodne ze zwrotem „konsoli centralnego 

Zarządzania”  użytym  w  OPZ.  Dodatkowo  dwie  konsole  należą  do  produktu  Standard 

Endpoint Protection Manager, który nie obsługuje systemów Linux. Prowadzi to do sytuacji, 

w  której  Zamawiający  będzie  musiał  prowadzić  ewidencję,  które  informacje  są 

przechowywane w której konsoli oraz nie będzie posiadał dostępu do informacji o wszystkich 

stacji końcowych, ponieważ stacje mogą być umieszczone w różnych produktach i w konsoli 

z daną informacją nie będzie części agentów. Przy skali zamawianego oprogramowania, tj. 

8500  szt.  endpointów  spowoduje  to  ogromny  chaos  w  zarządzaniu  i  ograniczenie 

funkcjonalności.  

Zrzuty  przedstaw

iają  wszystkie  możliwe  opcje  filtrowania  stacji  końcowych.  Nie 

istnieje  możliwość  filtrowania  po  wymaganych  parametrach,  tj.  7.12.2  tag  przypisany  do 

stacji  końcowej,  7.12.6  domena  MS  Windows,  7.12.9  stan  sieci  stacji  końcowej,  7.12.15 

jakikolwiek ciąg znaków z domeny Microsoft Windows 

a takich funkcjonalności wymaga Zamawiający.  

Rozdział II OPZ, punkt 7.15, 7.16, 7.19  


„7.15 rozwiązanie musi umożliwiać oznaczanie hostów poprzez etykiety (tagi);  

7.16 każda etykieta (tag) musi być określana poprzez parametr - nazwa etykiety (tagu);  

7.19 rozwiązanie musi umożliwiać dopisanie wielu etykiet (tagów) do jednej stacji końcowej;“ 

Standard  Endpoint  Protection  Manager  posiada  tagowanie  endpointów  ale  nie 

obsługuje serwerów Linux, które są wymagane do obsługi zgodnie z wymaganiami OPZ, np. 

Rozdział  II,  punkt  5.6.  „możliwość  automatycznej  aktualizacji  agentów  zainstalowanych  na 

stacjach końcowych z systemem operacyjnym: Microsoft Windows oraz Linux;”. Server and 

Workload  Protection  Manager  posiada  tagi  tylko  dla  zdarzeń/logów,  nie  posiada  tagów  dla 

hostów/stacji końcowych. Możliwość tagowania ograniczająca się tylko do zdarzeń/logów w 

produkcie  Server  and  Workload  Protection  Manager  przedstawiona 

została  na  zrzutach 

ekranu z konsoli rozwiązań Trend Micro.  

Tylko  dla  zdarzeń,  które  na  powyższym  zrzucie  ekranu  są  widoczne  jako  kolejne 

rzędy, można dodać tag („Add Tag(s)”).  

Rozdział II OPZ, punkt 7.17  

„7.17  etykiety  (tagi)  muszą  umożliwiać  filtrowanie  stacji  końcowych,  tworzenia  grup 

dynamicznych oraz do tworzenie widżetów na pulpicie nawigacyjnym;”  

Oferowane rozwiązania Trend Micro nie spełniają tego wymagania.  

Server  and  Workload  Protection  Manager  posiada  tagi  tylko  dla  zdarzeń/logów,  nie 

posiada  tagów  dla  hostów/stacji  końcowych.  Produkt  nieobsługujący  systemów  Linux, 

Standard Endpoint Protection Manager, nie posiada takiej funkcjonalności.  

Możliwości  produktu  Standard  Endpoint  Protection  Manager  odnośnie  tagów 

ograniczają się do przeszukiwania logów i tworzenia raportów dla endpointów z określonym 

tagiem.  Możliwości  odnośnie  tagowania  zostały  na  wycinku  z  dokumentacji  producenta 

Trend Micro.  

Wycinek z dokumentacji Trend Micro: (tłumaczenie z ang.):  

• 

Widok  danych  zapytania  dziennika  Dostępu  Użytkownika  zawiera  szczegółowe 

informacje  o  wszelkich  modyfikacjach  użytkownika  związanych  z  dowolnymi  dostępnymi 

niestandardowymi  tagami  lub  filtrami.  Aby  uzyskać  więcej  informacji,  zapoznaj  się  z 

następującymi tematami: o Zapytania dotyczące dzienników  

• 

Generowanie  niestandardowych  raportów  dla  oznaczonych  użytkowników  i  punktów 

końcowych,  na  podstawie  skojarzonych  tagów,  filtrów  lub  etykiety  ważności  jako  cele 

raportu. Aby uzyskać więcej informacji, zapoznaj się z następującymi tematami:  

o Tworzenie raportów jednorazowych  

o Dodawanie zaplanowanych raportów  

o Edytowanie zaplanowanyc

h raportów)  

Odnośnik 

do 

dokumentacji 

Trend 

Micro: 

https://docs.trendmicro.com/en-

us/documentation/article/trend-vision-one-custom-tags-filters  


Rozdział II OPZ, punkt 8.9  

„8.9  interfejs  graficzny  modułu  kontroli  sieci,  który  musi  prezentować  reguły  w  formie 

tabularycznej, z możliwością definiowania następujących kolumn:  

8.9.1 nazwa,  

8.9.2 opis,  

8.9.3 aplikacja,  

8.9.4 poziomami struktury rozwiązania, dla których reguły są aplikowane,  

8.9.5 system operacyjny,  

8.9.6 status (włączona / wyłączona),”  

Oferowane rozwiązania Trend Micro nie spełniają punktów 8.9.3 do 8.9.6, co zostało 

zaprezentowane na zrzutach ekranu z konsoli. 

Z

rzuty  ekranu  przedstawiają  wszystkie  możliwe  do  zdefiniowania  kolumny 

prezentowanych  reguł  w  formie  tabelarycznej  interfejsu  graficznego  modułu  kontroli  sieci. 

Oferowany  produkt  nie  posiada  możliwości  definiowania  kolumn  wyszczególnionych  w 

punktach 8.9.3 do 8.9.6.  

Rozdział II OPZ, punkt 9.4  

„zakres czasu raportów, który musi być możliwy do zdefiniowania przez użytkownika konsoli 

zarządzającej;”  

W  oferowanych  rozwiązaniach  Trend  Micro  użytkownik  nie  może  zdefiniować 

zakresu,  może  tylko  wybrać  zakres  z  listy  zdefiniowanej  przez  producenta,  w  przypadku 

raportów z harmonogramu (Scheduled report), jest to lista zdefiniowanej przez producenta z 

opcjami dzień, tydzień, miesiąc, w przypadku jednorazowych raportów (One time report), jest 

to  lista z  opcjami  7  dni, 30  dni. 

Przedstawiono zrzuty, które opisują konfiguracje, w których 

brakuje możliwości zdefiniowania zakresu.  

Podczas prazy  z  innymi  funkcjonalnościami istnieje możliwość definiowania zakresu 

czasu,  np.  dla  wyszukiwania  zdarzeń  w  funkcjonalności  XDR.  Przedstawiono  na  zrzucie 

ekranu możliwość wyboru definiowanego zakresu (Custom period) w wyszukiwaniu zdarzeń 

XDR. Można wybrać dzień i godzinę, od której („From:”) oraz do której („To:”) wyszukiwanie 

będzie  obowiązywać.  Podczas  tworzenia  raportów  rozwiązanie  nie  daje  takiej  możliwości 

więc nie spełnia cytowanego wymagania, którego spełnienia wymaga Zamawiający.  

Rozdział II OPZ, punkt 10.14  

„10.14 moduł  zarządzania aktywnościami, który musi  oferować możliwość filtrowania logów 

w następujących kategoriach:  

10.14.1 odpowiedź na zagrożenia;  

10.14.2 zarządzanie incydentami;  

10.14.3 wykluczenia;  

10.14.4 operacje administratorskie;  


10.14.5 email użytkownika konsoli;  

10.14.6 nazwa hosta.”  

Oferowane rozwiązania Trend Micro nie spełniają tego zapisu.  

R

ozwiązanie  nie  posiada  filtrowania  logów  w  kategoriach  10.14.1,  10.14.2,  10.14.3, 

10.14.5,  co  przedstawiono  na  zrzutach 

ekranu  z  konsoli  oferowanych  rozwiązań  Trend 

Micro.  

P

rzedstawione są wszystkie możliwe do filtrowania kategorie. Oferowane rozwiązania 

nie posiadają filtrowania logów w kategoriach 10.14.1, 10.14.2, 10.14.3, 10.14.5.  

Rozdział II OPZ, punkt 10.15  

„moduł  zarządzania  aktywnościami,  który  musi  oferować  możliwość  eksportowania  wpisów 

100, 1000, 5000 lub 10000 ostatnich aktywności do pliku .csv.”  

Oferowane rozwiązania Trend Micro nie spełniają tego wymagania.  

D

la modułu zarządzania aktywnościami nie ma możliwości eksportu określonej liczby 

wpisów,  czego  wymaga Zamawiający  i  co jest  przedstawione na  zrzutach ekranu z  konsoli 

oferowanych rozwiązań Trend Micro.  

Po wybraniu opcji „Export as .csv file.” czyli „Eksportuj jako plik .csv” eksportowane są 

wszystkie wyświetlone wpisy.  

Rozdział II OPZ, punkt 10.16  

„moduł  zarządzania  aktywnościami,  który  musi  oferować  możliwość  pobierania  logów 

zebranych przez agenta końcowego po wydaniu komendy z poziomu modułu zarządzania;”  

Oferowane rozwiązania Trend Micro nie spełniają tego wymagania.  

Moduł  zarządzania  aktywnościami  (Audit  Log)  nie  ma  takiej  opcji,  co  potwierdza 

poniższy  zrzut  ekranu  z  konsoli  oferowanych  rozwiązań  Trend  Micro  a  czego  wymaga 

Zamawiający.  

Na  zrzucie  ekranu  z  modułu  zarządzania  aktywnościami  (Audit  Log)  jedynymi 

dostępnymi opcjami jest filtrowanie wpisów i eksportowania ich jako pliku CSV.  

Rozdział II OPZ, punkt 10.23  

„zarządzanie  notyfikacjami,  które  musi  umożliwiać  wyszukiwanie  pojedynczego  rodzaju 

zdarzenia poprzez wyszukiwarkę tekstową;”  

Oferowane  rozwiązania  Trend  Micro  nie  spełniają  tego  wygania,  nie  posiada 

wyszukiwania  powiadomień,  co  zaprezentowano  na  zrzuci  ekranu  z  konsoli  oferowanych 

rozwiązań Trend Micro.  

Na  zrzucie  ekranu  nie  ma  okna  lub  sekcji,  w  której  można  przeprowadzić 

wyszukiwanie  powiadomień.  Jest  dostępna  lista  powiadomień  ale  nie  można  ich  wyszukać 

poprzez wyszukiwarkę tekstową.  

Rozdział II OPZ, punkt 10.24  

6.„10.24 zarządzanie notyfikacjami, które musi wyróżniać następujące typy powiadomień:  


10.24.1 administracyjne;  

10.24.2 kontrola urządzeń;  

10.24.3 tagi urządzeń;  

10.24.4 kontrola firewall;  

10.24.5 malware;  

10.24.6 łagodzenie incydentów;  

10.24.7 operacje;  

10.24.8 Remote Shell;”  

Oferowane rozwiązania Trend Micro nie spełniają podpunktów 10.24.3, 10.24.6 oraz 

10.24.8,  co  przedstawiono  na  zrzucie 

ekranów  z  konsoli  oferowanych  rozwiązań  Trend 

Micro.  

Zrzuty  ekranów  przedstawiają  miejsca,  w  których  można  konfigurować  notyfikacje. 

Ponieważ  oferta  składa  się  z  wielu  produktów,  konfiguracja  notyfikacji  nie  jest  możliwa  w 

pojedynczym  panelu.  Na  zrzutach  ekranów  przedstawiono  wszystkie  możliwe  do 

skonfigurowania  notyfikacje.  Oferowane  rozwiązania  Trend  Micro  nie  wyróżniają  typów 

powiadomień  opisanych  w  podpunktach  10.24.3,  10.24.6  oraz  10.24.8  czego  wymaga 

Zamawiający.  

II.  Zarzuty dot

yczące oferty złożonej przez Trafford IT  

Zgodnie  ze  złożoną  ofertą,  Trafford  IT,  zaoferowało  oprogramowanie  Cortex  XDR 

producent Palo Alto Networks.  

W  ocenie  Odwołującego  zaoferowane  oprogramowanie  nie  spełnia  wymagań 

określonych  przez  Zamawiającego  w  opisie  przedmiotu  zamówienia.  W  ofercie  nie  podano 

rodzaju licencji, 

co uniemożliwia wskazanie konkretnego rozwiązania. W ofercie wymieniony 

jest  produkt  „Cortex  XDR”  ale  ten  produkt  nie  jest  sprzedawany  w  takiej  formie,  jest 

sprzedawany  jako  Cortex  XDR  Prevent  lub  Cortex  XDR  Pro.  W  formularzu  ofertowym 

wyraźnie napisano: „należy podać oznaczenie pozwalające na identyfikację oprogramowania 

oraz rodzaju licencji” Wpisanie „Cortex XDR” nie spełnia tego wymagania.  

W opisie produktu na stronie Palo Alto - https://www.paloaltonetworks.com/cortex/cortex-xdr 

Producent wskazuje: „Two powerful offerings.” (tłumaczenie z ang.: „Dwie potężne oferty.”)  

„CORTEX XDR PREVENT - CORTEX XDR PRO” Tylko powyższe opcje są właściwe. Są to 

różne produkty, do każdego z tych dwóch rodzajów licencji jest osobna instrukcja, tzw. admin 

guide. 

Licencje  te  różnią  się  znacznie  funkcjonalnością.  Cortex  Pro  pozwala  na  szerszy 

zakres  ochrony  i  funkcjonalności.  Ze  złożonej  oferty  Zamawiający  nie  jest  w  stanie 

zidentyfikować jaki produkt otrzyma.  


Jeżeli nawet by przyjąć (mimo iż nie wynika to z treści złożonej oferty), że zaoferowano 

produkt  „Cortex  XDR  Pro“,  to  Odowłujący  wskazał  funkcjonalności,  których  ten  produkt  nie 

posiada 

odniesieniu 

do 

dokumentu: 

„Tom_III_SWZ_ 

_Opis_przedmiotu_zamowienia_wersja_ujednolicona_13-05-

2024_09.31.29.pdf”.  

Rozdział II OPZ , punkt 5.18  

„informacje  dla  każdego  pakietu  instalacyjnego,  które  muszą  zawierać  co  najmniej 

następujące dane:  

5.18.1 wersja główna,  

5.18.2 numer buildu,  

5.18.3 rozszerzenie pliku,  

5.18.4 nazwa pliku,  

5.18.5 data opublikowania,  

5.18.6 platforma”  

Oferowane  rozwiązanie  nie  posiada  5.18.3,  5.18.4,  co  zaprezentowano  na  zrzucie 

ekranu z konsoli oferowanego produktu Palo Alto.  

Rozdział II OPZ, punkt 6.8.1  

„6.8  możliwość  tworzenia  wyjątków  dla  systemu  Microsoft  Windows  z  wykorzystaniem 

następujących elementów:  

6.8.1 HASH SHA1,  

6.8.2 ścieżka do pliku,  

6.8.3 ścieżka do katalogu wraz z katalogami podrzędnymi,  

6.8.4 certyfikat,  

6.8.5 rodzaj pliku”  

Oferowane  rozwiązanie  nie  spełnia  punktu  6.8.1.  Wspierany  jest  tylko  SHA256. 

Odwołujący  przedstawił  wycinek  z  dokumentacji  producenta  Palo  Alto  oraz  odnośnik  do 

strony dokumentacji potwierdzający ten fakt.  

Wycinek dokumentacji: (tłumaczenie z ang.): 

Przejdź do Incident Response → Response → Action Center → + New Action.  

Wybierz opcję Add to Block List lub Add to Allow List.  

Wprowadź skrót SHA-256 pliku i kliknij    

Możesz  dodać  maksymalnie  100  skrótów  plików  na  raz.  Możesz  dodać  komentarz,  który 

zostanie do

dany do wszystkich skrótów dodanych w tej akcji.)  

Strona do dokumentacji technicznej oferowanego produktu Palo Alto:  

https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Pro-

AdministratorGuide/Manage-File-Execution  

Rozdział  II OPZ,  punkt 6.12 „gotowy  katalog  wyjątków  przygotowany  dla  wybranych 

aplikacji i aktualizowany przez producenta;”  


Nie ma przygotowanego katalogu wyjątków dla wybranych aplikacji. Jest tylko przygotowana 

lista  aplikacji  do  blokowania,  co  w  tym  wypadku  jest  odwrotną  funkcjonalnością.  Według 

odnośnika 

do 

strony 

dokumentacji 

technicznej 

https://docs-

cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Pro-AdministratorGuide/Add-a-New-

Malware-Security-Profile producenta Palo Alto (

tłumaczenie z ang.:  

Predefiniowane zablokowane aplikacje 

Lista aplikacji  Lista 

powszechnie 

znanych 

aplikacji, które Twoja organizacja może chcieć zablokować na nadzorowanych urządzeniach, 

znajduje  się  tutaj.  Agent  Cortex  XDR  zablokuje  korzystanie  z  wybranych  aplikacji.  Możesz 

wybrać jedną lub więcej aplikacji.  

Odwołujący  przedstawił  także  zrzuty  ekranu  z  oferowanego  rozwiązania  Palo  Alto 

potwierdzające brak gotowego katalogu wyjątków dla wybranych aplikacji.  

Rozdział  II  OPZ,  punkt  6.15  „możliwość  konfigurowania  list  blokujących  na  różnych 

poziomach  hierarchii  z  zachowaniem  zasad  dziedziczenia  z  wyższych  poziomów  do 

niższych;”  

Oferowane rozwiązanie producenta  Palo Alto nie posiada dziedziczenia z  wyższych 

poziomów  hierarchii  do  niższych,  nie  ma  więc  możliwości  dziedziczenia  list  blokujących  w 

takiej hierarchii.  

Rozdział II OPZ, punkt 8.9.4  

„8.9  interfejs  graficzny  modułu  kontroli  sieci,  który  musi  prezentować  reguły  w  formie 

tabularycznej, z możliwością definiowania następujących kolumn:  

8.9.1 nazwa,  

8.9.2 opis,  

8.9.3 aplikacja,  

8.9.4 poziomami struktury rozwiązania, dla których reguły są aplikowane,  

8.9.5 system operacyjny,  

8.9.6 status (włączona / wyłączona),  

8.9.7 akcja (zezwalaj / blokuj),  

8.9.8 kierunek transmisji,  

8.9.9 lokalny host,  

8.9.10 lokalny port,  

8.9.11 zdalny host,  

8.9.12 zdalny port,”  

Rozwiązanie nie spełnia punktu  8.9.4.  Listę  dostępnych kolumn  zaprezentowano  na 

zrzucie ekranu z konsoli oferowanego rozwiązania Palo Alto.  

Rozdział II OPZ, punkt 8.14 „8.14  moduł kontroli sieci z włączonym firewall nie może 

być  zarejestrowany  jako  firewall  w  systemie  Linux.  Firewall  rozwiązania  musi  działać 

równolegle  do  firewalla  systemowego  systemu  Linux.  W  przypadku  konfliktu  między 


firewallami systemowym a rozwiązania, zasady firewalla rozwiązania muszą traktowane być 

prior

ytetowo;”  

Oferowane rozwiązanie nie posiada firewall dla systemu Linux, co potwierdza wyciąg  

z  dokumentacji  technicznej  oraz  odnośnik  do  strony  dokumentacji  technicznej  producenta 

Palo Alto  

Wycinek z dokumentacji technicznej Palo Alto 

(tłumaczenie z ang.):  

Zapora hosta  

Zapora  hosta  Cortex  XDR  umożliwia  kontrolowanie  komunikacji  na  punktach  końcowych. 

Aby użyć zapory hosta, należy ustawić reguły, które zezwalają na ruch na urządzeniach lub 

go  blokują,  i  zastosować  je  do  punktów  końcowych  za  pomocą  reguł  zasad  zapory  hosta. 

Ponadto można skonfigurować różne zestawy reguł w oparciu o bieżącą lokalizację punktów 

końcowych  —  w  obrębie  lub  poza  siecią  organizacji.  Reguły  zapory  hosta  Cortex  XDR 

wykorzystują interfejsy API zapory systemu operacyjnego i wymuszają te reguły na punktach 

końcowych, ale nie na ustawieniach zapory systemu Windows lub Mac.  

Odwołujący wymienił reguły dotyczące zasad zapory hosta Cortex XDR na punktach 

końcowych dla platform Windows i Mac, Linux – nieobsługiwana. 

Strona  do  dokumentacji  technicznej  oferowanego  produktu  Palo  Alto:  https://docs-

cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Prevent-AdministratorGuide/Host-

Firewall. 

W ocenie Odwołującego obie złożone oferty są niezgodne z SWZ i załącznikami do 

niej  (stanowiącymi  dokumentację  postępowania).  Oferty  obu  tych  Wykonawców  powinny 

zostać odrzucone, jako niezgodne z SWZ.  

Zamawiający złożył odpowiedź na odwołanie wnosząc o jego oddalenie w całości (pismo z 

12.09.2024 r.) 

Przystępujący  po  stronie  Zamawiającego  –  IT  Solution  Factor  Sp.  z  o.o.  złożył  pismo 

procesowe,  w  którym  odniósł  się  do  zarzutów  skierowanych  wobec  jego  oferty  (pismo  z 

12.09.2024 r.). 

Odwołujący  na  posiedzeniu  przed  otwarciem  rozprawy  wycofał  zarzut  dotyczący  oferty  IT 

Solution Factor Sp. z o.o. i jej niezgodności z opisanym w lit a wymaganiem „Funkcjonalność 

F1”.  Jednocześnie  Odwołujący  podtrzymał  zarzut,  iż  zaoferowany  produkt:  „Trend  Vision 

One  - 

Endpoint  Security  (Essentials  )“,  to  pakiet  zawierający  dwa  produkty  do  ochrony 

endpoint: Standard Endpoint Protection 

– ochrona desktopów: Windows, macOS oraz Server 

and  Workload  Protection 

–  ochrona  serwerów:  Windows,  Linux.  Oba  produkty  posiadają 


osobne agent

y, konsole zarządzające, polityki i funkcjonalności, co ma naruszać wymagania 

z rozdziału II OPZ.  

W  pozostałym  zakresie  Odwołujący  podtrzymał  odwołanie,  kwestionując  prawidłowość 

dwóch ofert, tj. wykonawców IT Solution Factor Sp. z o.o. oraz Trafford IT. 

Izba  oddaliła  odwołanie  w  całości  uznając,  iż  okoliczności  wskazane  w  podstawie 

zarzutów  nie  uzasadniały  uznania,  iż  obie  kwestionowane  oferty  podlegać  winny 

odrzuceniu,  jako  niezgodne  z  warunkami  zamówienia,  jak  również  nie  uzasadniały 

twierdzenia o potrzebie wyjaśnienia treści ofert.  

Odwołanie w zasadniczym zakresie sprowadzało się do wykazania niezgodności obu ofert z 

swz, mającej uzasadniać ich odrzucenie na podstawie art. 226 ust. 1 pkt 5 Ustawy. Kwestia 

wyjaśnienia treści ofert, poza jej wskazaniem w zarzutach naruszenia Ustawy nie została w 

żaden  sposób  rozwinięta  w  uzasadnieniu  i  sprowadzała  się  do  ogólnego  stwierdzenia 

zaniechania przez Zamawiającego wezwania obu wykonawców do wyjaśnienia treści oferty 

pomimo  niespełniania  wymagań  Zamawiającego.  W  tych  okolicznościach  zarzut  dotyczący 

zaniechania  wezwania  do  złożenia  wyjaśnień  nie  mógł  być  uwzględniony  i  przy  braku 

jakiejkolwiek  rozwinięcia  w  uzasadnieniu,  jego  oddalenie  również  można  sprowadzić  do 

stwierdzenia o lakoniczności odwołania, lub wręcz braku prawidłowo podniesionego zarzutu. 

Odwołujący w żadnym miejscu obszernego uzasadnienia nie wskazał w jakim zakresie treść 

oferty  mogła  podlegać  wyjaśnieniu  przy  jednoczesnym  żądaniu  odrzucenia  obu  ofert,  jako 

niezgodnych  z  warunkami  zamówienia.  Powyższe  czyniło  niejasnym  ustalenie,  czego 

miałyby dotyczyć wyjaśnienia, a tym samym uniemożliwiało to merytoryczną ocenę zarzutu. 

Odnosząc  się  natomiast  do  pozostałych  zarzutów  odwołania,  należy  tytułem  wstępu 

poczynić  ogólna  uwagę,  iż  konstrukcja  zarzutów  ograniczała  ich  rozpoznanie  wyłącznie  do 

zakresu 

okoliczności  wskazanych  w  uzasadnieniu  zarzutów.  Izba  pominęła  argumentację 

podnoszoną  przez  Odwołującego  w  odpowiedzi  na  stanowiska  pisemne  Zamawiającego  i 

Przystępującego  po  jego  stronie,  która  wykraczała  poza  kwestie  faktyczne  wskazane  w 

odwołaniu.  Odwołujący  formułował  zarzuty  niezgodności  treści  oferty  z  swz,  wskazując  i 

cytując  konkretne  postanowienie  opisujące  warunek  techniczny,  a  następnie  prezentował 

uzasadnienie ze wskazaniem podstawy, na jakiej opiera wniosek o braku spełnienia danego 

wymagania.  Tylko  te  kwestie,  które  zostały  w  uzasadnieniu  poruszone,  wyznaczały  zakres 

rozpoznania. 

Należy odnotować, iż złożenie odpowiedzi na odwołanie nie otwierało drogi do 

formułowania  zarzutów  szerzej,  niż  miało  to  miejsce  w  odwołaniu.  Odpowiedź 

Zamawiającego,  jak  i  stanowisko  Przystępującego  były  reakcją  na  argumenty  i  kwestie 

techniczne 

wskazane  w  odwołaniu,  które  w  ocenie  Odwołującego  miały  uzasadniać 


twierdzenie  o  braku  zgodności  z  wymaganiami  zamówienia.  Jeżeli  odpowiedzi  te 

prowokowały  dalszą  dyskusję  wykraczającą  poza  podstawę  faktyczną  zarzutu,  nowe 

okoliczności  nie  były  brane  pod  uwagę  przy  rozpoznaniu  odwołania,  nawet  jeżeli  miały 

odniesienie  do  konkretnego,  wskazanego  w  odwołaniu  warunku  (co  zostanie  odpowiednio 

odnotowane  w  dalszej  części  uzasadnienia).  Należy  również  zauważyć,  iż  przedmiot 

zamówienia  i  wymagania  opisane  przez  Zamawiającego  uwzględniały  oczekiwania  wobec 

działania  i  funkcjonalności  systemu.  Zatem  dla  ustalenia  na  jakiej  podstawie  Odwołujący 

wnioskuje  o  braku  spełnienia  wymagań  decydowało  uzasadnienie  i  wskazanie  na  te 

elementy oferowanego rozwiązania, które miały prowadzić do stwierdzenia, w jakim zakresie 

funkcjonalność  nie  może  być  osiągnięta.  Nie  wystarczyło  zatem  samo  zacytowanie  opisu 

przedmiotu zamówienia, bez odniesienia do konkretnej okoliczności pozwalającej ocenić, czy 

produkt spełnia wymagania Zamawiającego.      

Przechodząc  zatem  do  kwestii  szczegółowych  objętych  zarzutami,  stanowisko  Izby 

podzielone zostanie na dwie części, odnosząc się do dwóch ofert. 

I. 

Zarzuty  dotyczące  oferty  wybranej  –  IT  Solution    Factor  Sp.  z  o.o.  (dalej  jako  IT 

Solution) Izba w całości oddaliła. 

W pierwszej kolejności Izba uznała, iż ocena produktu zaoferowanego w ofercie IT Solution, 

tj.  Trend  Vision  One 

–  Endpoint  Security  (Essentials)  producenta  Trend  Micro,  w  części  w 

jakiej Odwołujący opierał na twierdzeniu, iż zawiera ono dwa produkty do ochrony Endpoint, 

tj. 

„Standard Endpoint Protection – ochrona desktopów: Windows, macOS” oraz „Serwer and 

Workload  Protection 

–  ochrona  serwerów:  Windows,  Linux”,  posiadające  osobne  agenty, 

k

onsole  zarządzające,  polityki  i  funkcjonalności,  oparta  była  na  błędnym  przekonaniu 

własnym  Odwołującego  o  produkcie.  Odwołujący  w  żaden  sposób  nie  skomentował 

oficjalnych  informacji  o  produkcie,  który  objęty  jest  jedną  licencją  oprogramowania  Trend 

Vision  One

.  Jako  rozwiązanie  chmurowe  obejmuje  dwie  funkcjonalności  (wskazane  przez 

Odwołującego  w  sposób  nieuprawniony  jako  „dwa  produkty”),  tworzące  jedno  rozwiązanie 

licencyjne  i  umożliwiające  uruchomienie  ochrony  w  ramach  jednej  centralnej  konsoli  Trend 

Vision  One.  Zamawiający  powołał  się  na  oficjalne  informacje  producenta,  których 

Odwołujący  nie  podważył,  a  tym  samym  odwołanie  w  zakresie  argumentów  opartych  na 

wykazaniu  rozdzielnych  funkcjonalności  „Standard  Endpoint  Protection”  oraz  „Serwer  and 

Workload  Protection”,  które  miały  być  dostępne  z  poziomu  oddzielnych  konsol,  nie  miały 

oparcia  w  rzeczywistości.  Tym  samym  wnioski  o  niezgodności  produktu  z  wymaganiami 

oparte  na  tej  okoliczności  Izba  uznała  za  bezzasadne  (zarzut  nr  1  i  kolejne  odpowiednio 

wskazane poniżej).  


Przechodząc  do  poszczególnych  parametrów  Izba  odniesie  się  oddzielnie  do  każdego  z 

zarzutów w kolejności odpowiadającej treści odwołania. 

rozdział  II  OPZ,  pkt  4.3  –  wymóg:  „Automatyczna  Reakcja  i  Izolacja  Zagrożeń  musi 

posiadać: „zestaw silników które można włączać lub wyłączać;”  

W  rozwiązaniu,  zdaniem  Odwołującego,  nie  można  wyłączyć  silników  jako  automatyczna 

reakcja  ani  podczas  izolacji  zagrożeń.  Wszystkie  możliwe  czynności  dla  automatycznej 

reakcji  i  izolacji  zagrożeń  Odwołujący  przedstawił  na  zrzucie  ekranu  z  oferowanych 

rozwiązań  Tren  Micro.  Nie  ma  tu  możliwości  wyłączania  lub  włączania  zestawu  silników 

czego wymaga Zamawiający.  

Zamawiający  Przystępujący  wskazali  na  możliwość  użycia  funkcjonalności  programu  tzw. 

playbook,  pozwalającej  na  wykorzystanie  skryptu  do  wyłączenia/włączenia  dowolnego 

zestawu silników. 

Izba  oddaliła  zarzut  uznając,  iż  zrzut  z  ekranu  przedstawiony  w  odwołaniu  nie  prezentuje 

innych  dostępnych  funkcjonalności  systemu,  pozwalających  na  włączanie/wyłączanie 

silników  (playbook,  skrypty).  Jednocześnie  słusznym  jest  argument  Przystępującego,  iż  w 

OPZ nie zostały  wskazane  zestawy  silników,  dla których konkretnie wymóg  ten  się  odnosi, 

jak również z jakiego poziomu funkcjonalność ta ma być zagwarantowana.  

rozdział  II  OPZ,  pkt  4.5  –  wymóg:  „możliwość  przeniesienia  do  kwarantanny  złośliwych 

plików  należących  do  tego  samego  incydentu.  Funkcja  kwarantanny  musi  zatrzymać 

procesy, szyfrować plik wykonywalny i przenieść go na ograniczoną ścieżkę;”  

Zdaniem  Odwołującego,  oferowane  rozwiązania  Trend  Micro  nie  zawierają  opcji 

przeniesienia  wszystkich  plików  z  incydentu  do  kwarantanny.  Pliki  w  incydencie  można 

dodać  do  listy  blokowania  (zrzut  z  ekranu),  co  nie  jest  jednoznaczne  z  kwarantanną, 

dodawać  pliki  można  tylko  pojedynczo.  W  dostępnych  opcjach  oferowane  rozwiązanie  nie 

posiada  możliwości  przeniesienia  do  kwarantanny  złośliwych  plików  należących  do  tego 

samego incydentu czego wymaga Zamawiający.  

Izba  oddaliła  zarzut,  jako  niezasadny.  Nie  budziło  sporu,  iż  funkcja  dodawania  do  listy 

blokowania  nie  oznacza  jeszcze  przeniesienia  do  kwarantanny  złośliwych  plików. 

Jednocześnie  odwołujący  sam  przyznał  na  rozprawie,  iż  system  ma  funkcję  kwarantanny, 

kwestionując przy tym prezentowane przez przeciwników sporu zrzuty z ekranu prezentujące 

tą funkcjonalność, którą poprzedza akcja dodawania do listy blokowanych. Należy wskazać, 

iż Zamawiający nie narzucił konkretnego schematu w jakim dany system ma dodawać pliki z 

incydentu  do  kwarantanny,  a  tym  samym  rozwiązanie  zaoferowane  nie  jest  niezgodne  z 

wymaganiem,  gdyż  posiada  możliwość  przeniesienia  do  kwarantanny  złośliwych  plików 

należących  do  tego  samego  incydentu.  Z  wyjaśnień  Przystępującego  i  Zamawiającego 


wynika,  że prezentowane przez  nich zrzuty  obrazują sposób  przeniesienia do  kwarantanny 

plików  w  sposób  automatyczny  lub  pojedynczo  przez  dodanie  do  listy  blokowania. 

Odpowiedź  Odwołującego  udzielona  na  pytanie  o  przedstawione  mechanizmy  nie 

przekonała,  gdyż  w  ogóle  nie  kwestionuje  możliwości  przeniesienia  do  kwarantanny.  Na 

rozprawie  Odwołujący  próbował  rozszerzyć  zarzut  na  ocenę  samego  incydentu,  a  nie 

funkcjonalności dodawania do kwarantanny, co Izba pominęła.  

rozdział  II  OPZ,  pkt  5.1  –  wymóg:  „Jedno  plikowy  agent  AV,  który  musi  być  w  pełni 

autonomiczny,  co  oznacza,  że  jego  działanie  i  funkcjonalność  nie  może  być  zależna  od 

serwera zarządzania, chmury ani ŻADNYCH zasobów zewnętrznych od agenta;”  

W  ocenie  Odwołującego,  brak  Internetu  uniemożliwia  działanie  funkcjonalności:  behavior 

monitoring  (tłumaczenie  z  ang.:  monitorowanie/analiza  behawioralna),  predictive  machine 

learning (tłumaczenie z ang.: predyktywne uczenie maszynowe), i process memory scanning 

(tłumaczenie z ang.: skanowanie procesów w pamięci).  

Izba  na  podstawie  wskazanych  w  pismach  mechanizmów  działania  uznała,  iż  stanowisko 

Odwołującego  wynika  z  wybiórczej  oceny  działania  automatycznego  agenta  AV,  które  nie 

uwzględnia  mechanizmów  pozwalających  na  niezależne  od  serwera  jego  działanie. 

Zamawiający  wskazał  na  możliwości  jakie  stwarza  wykorzystanie  paczki  „web  instaler”  lub 

skryptu. Ponadto, Odwołujący wybiórczo zacytował treść dokumentacji, tj. z pominięciem tej 

części,  w  której  podane  są  dostępne  rozwiązania  w  sytuacji  gdyż  agent  nie  działa  (str.  7 

pisma Przystępującego).  Tym  samym  twierdzenia o braku  możliwości  działania niezależnie 

od  zasobów  zewnętrznych,  nie  zostało  przez  Odwołującego  wykazane.  Wybiórcza  analiza 

rozwiązania  nie  może  stanowić  uzasadnienia  dla  uznania,  iż  rozwiązanie  nie  spełnia 

warunku. Ponadto, s

ame funkcje systemu wybiórczo wskazane w tym miejscu odwołania są 

dostępne,  co  potwierdzają  zrzuty  z  ekranu  w  odpowiedzi  na  odwołanie,  a  Zamawiający 

opisując  warunek  nie  odnosił  się  do  konkretnych  funkcjonalności,  ale  działania  samego 

agenta AV, w pełni autonomicznego. 

rozdział  II  OPZ,  pkt  5.9.2,  wymóg:  „funkcjonalność  automatycznej  aktualizacji,  która  musi 

pozwalać  na  wybór  stacji  końcowych  które  powinny  zostać  zaktualizowane  posiadając 

możliwość wyboru co najmniej: jedynie stacji końcowych z wybranym tag-iem;” 

Odwołujący  wskazał,  iż  Standard  Endpoint  Protection  Manager  posiada  tagowanie 

endpointów, ale nie ma możliwości definiowania aktualizacji na podstawie tagów. Server and 

Workload Protection Manager ma tagi tylko dla zdarzeń/logów, nie ma dla endpointów.  

Zarzut  podlegał  oddaleniu,  gdyż  wynikał  z  błędnego  przedstawienia  produktu,  jako 

składającego  się  z  dwóch  oddzielnych,  wymagających  dwóch  konsoli  obsługujących  ich 

funkcjonalności.  Aktualne  w  tym  zakresie  pozostaje  stanowisko  wyrażone  na  wstępie 


uzasadnienia  o  braku  podstaw  dla  uznania  zarzutów  wywodzonych  z  takiej  analizy 

zaoferowanego  rozwiązania.  Przedstawione  w  kontrze  zrzuty  z  ekranu  prezentują  funkcje 

tagowania 

dla  stacji  końcowej.  Przystępujący  wyjaśniał  działanie  mechanizmu 

wykorzystującego etykiety przypisane stacji końcowej, które pozwalają na aktualizację tylko 

dla określonych etykietami stacji (otagowane). Obrazują to również przedstawione w piśmie 

procesowym  Przystępującego  kroki  (str.  od  8  do  11).  Argumenty  Odwołującego  dotyczące 

tagowania, jako obrazującego „wpisanie z palca”, a nie efekt nadania etykiety, były w ocenie 

składu  orzekającego  oderwane  od  rzeczywistości  i  stanowiły  autorską  ocenę 

prezentowanych działań zakończonych nadaniem etykiety.  

rozdział  II,  pkt  5.12,  wymóg:  „możliwość  zdefiniowania  maksymalnej  liczby  stacji 

końcowych pobierających jednocześnie paczkę aktualizacyjną;”  

W ocenie Odwołującego, oferowane rozwiązanie nie ma takiej opcji.  

Izba  oddaliła  zarzut  jako  gołosłowny,  oderwany  od  faktycznych  mechanizmów  działania 

systemu,  w  którym  administrator  może  określić  zarówno  wszystkie  stacje  końcowe  jak  i 

stacje końcowe należące do konkretnej grupy, co jest powiązane z funkcją tagowania stacji 

końcowych,  dla  których  nastąpi  pobranie  aktualizacji.  Ograniczenie  liczby  stacji  nie  musi 

odbywać  się  wyłącznie  przez  wskazanie  ich  liczby,  ale  zapewnione  jest  również  przez 

wskazanie grupy zawierającej wszystkie stacje o ustalonej etykiecie (tagu). Nie jest to jedyny 

sposób  zdefiniowania  maksymalnej  liczby  stacji  końcowych,  do  czego  odnosi  się 

Przystępujący  w  piśmie  procesowym  (str.  11-17).  Należy  również  podkreślić,  iż  zarzut  w 

zasadzie  sprowadzał  się  do  zaprzeczenia  działania  tej  możliwości  i  wskazania  wybranego 

przez  Odwołującego  screenu.  Argumentacja  nie  została  w  żaden  sposób  rozwinięta  i  nie 

odnosi  się  do  innych  możliwych  działań  administratora,  pozwalających  na  zdefiniowanie 

maksymalnej  liczby  stacji

,  co  zostało  przedstawione  merytorycznie  dopiero  przez 

Przystępującego  i  Zamawiającego.  Odwołujący  dopiero  w  piśmie  procesowym  rozszerzał 

argumentację  o  znaczenie  pojęcia  „zdefiniowanie  maksymalnej  liczby”  nadając  mu 

znaczenie  jako  możliwość  podania/ustawienia  maksymalnej  liczby,  dla  której  aktualizacja 

będzie  miała  zastosowanie.  Skład  orzekający  taki  sposób  rozumienia traktuje  jako  możliwy 

ale  nie  jedyny,  w  świetle  specyfiki  przedmiotu  zamówienia  i  różnych  metod  pozwalających 

ograniczyć  liczbę  stacji  końcowych  bez  narzucania  na  sztywno  ich  liczby.  Ograniczenie 

zbioru  stacji  końcowych  np.  wskazaną  etykietą  (tagiem)  będzie  formą  zdefiniowania 

maksymalnej  liczby  stacji  mieszczących  się  w  zbiorze,  co  spełnia  warunek  swz.  Za  takim 

rozumieniem  przemawia  fakt,  iż  Zamawiający  nie  narzucił  z  góry  na  sztywno  konkretnej 

maksymalnej  liczby  stacji  końcowych,  dla  których  jednocześnie  pobrana  miałaby  być 

aktualizacja.  Taki  opis  wymagania  nie  ingeruje 

w  różne  rozwiązania  stosowane  przez 

producentów,  co  mogłoby  istotnie  ograniczać  konkurencję.  Możliwość  zdefiniowania 


maksymalnej  liczby  stacji  nie  może  być  ograniczana  w  taki  sposób  jak  rozumie  to 

Odwołujący, gdyż prowadzi do zawężenia znaczenia funkcjonalności, która kładzie nacisk na 

samo  zdefiniowanie,  a  więc  sposób  określenia  maksymalnej  liczby,  co  nie  może  być 

zrównywane wyłącznie z wprowadzeniem liczby maksymalnej. 

rozdział  II  OPZ,  pkt  5.18,  wymóg:  „informacje  dla  każdego  pakietu  instalacyjnego,  które 

muszą zawierać co najmniej następujące dane:  

5.18.1 wersja główna,  

5.18.2 numer buildu,  

5.18.3 rozszerzenie pliku,  

5.18.4 nazwa pliku,  

5.18.5 data opublikowania,  

5.18.6 platforma”  

W  ocenie  Odwołującego  powyższe  informacje  nie  są  wyświetlane  w  Standard  Endpoint 

Protection  Manager, 

a  w  Server  and  Workload  Protection  Manager  nie  ma  „daty 

opublikowania”.  W kolumnach  tabeli  zawierającej  pakiety  instalacyjne  są kolumny  „Nazwa”, 

„Platforma”,  „Wersja”,  „Typ  publikacji”  i  „Data  importu”.  Nie  istnieje  kolumna  „Data 

opublikowania” czego wymaga Zamawiający. Data importu jest myląca dla administratorów, 

ponieważ  może  być  różna  dla  tego  samego  pakietu  (np.  przy  ponownym  pobraniu)  i 

niezgodna  chronologicznie  w  porównaniu  z  datą  opublikowania,  np.  starszy  pakiet 

instalacyjny  może  być  zaimportowany  później  niż  nowszy.  Data  opublikowania  jest 

niezmienna i niezależna od momentu pobrania pakietu instalacyjnego.  

Izba oddaliła zarzut, gdyż wynikał z błędnego przedstawienia produktu, jako składającego się 

z  dwóch  oddzielnych,  wymagających  dwóch  konsoli  obsługujących  ich  funkcjonalności. 

Aktualne  w  tym  zakresie  pozostaje stanowisko  wyrażone  na  wstępie  uzasadnienia  o  braku 

podstaw  dla  uznania  zarzutów  wywodzonych  z  takiej  analizy  zaoferowanego  rozwiązania. 

Ponadto,  Zamawiający  i  Przystępujący  wykazali,  iż  wskazane  informacje  zawierają 

wymagane dane. Szczególną uwagę Odwołujący skupiał na „dacie publikacji” przedstawiając 

jako dowód informacje o produkcie Deep Security. 

Izba  oddaliła  zarzut  uznając  wyjaśnienia  Zamawiającego  i  Przystępującego  za  spójne  i 

przekonujące.  Odwołujący  faktycznie  odwołał  się  do  daty  publikacji  agenta  dla  produktu, 

który nie jest oferowany i wymaga pobrania ze strony, co wiąże się z tym, że data importu 

nie  jest  datą  publikacji.  W  przypadku  zaoferowanego  produktu,  który  jest  chmurą 

jednocześnie z publikacją przez producenta agent jest dostępny (importowany), gdyż jest to 

jedno  zdarzenie.  Nie  ma  zatem  podstaw  do  podważania  informacji  przedstawionych  na 

screenach dotyczących zaoferowanego produktu. 


rozdział II OPZ, pkt 6.10, wymóg: „możliwość stopniowania poziomu wyjątków dla wyjątków 

typu "Ścieżka" w systemie Windows , co najmniej w następującym zakresie:  

6.10.1 wygaszenie alarmów,  

6.10.2 zredukowanie monitorowania konkretnego procesu,  

6.10.3 zredukowanie monitorowania konkretnego procesu i jego procesów potomnych,  

6.10.4 wyłączenie monitorowania konkretnego procesu,  

6.10.5 wyłączenie monitorowania konkretnego procesu i jego procesów potomnych;”  

W ocenie Odwołującego, oferowane rozwiązania Trend Micro nie spełniają tego zapisu opcji 

6.10.1  do  6.10.5  dla ścieżki/path  systemu  Windows, co przedstawiono na  zrzutach  ekranu. 

Na zrzutach ekranu widoczne są opcje konfiguracji wyjątków typu „ścieżka” w systemie, nie 

ma  jednak  opcji  przedstawionych  w  podpunktach  6.10.1  do  6.10.5  czyli  możliwości 

określenia  stopnia  poziomu  wyjątku  tego  typu.  Zrzuty  ekranów  pochodzą  z  konfiguracji 

polityki  w  produktach  ochrony  antymalware.  Funkcjonalność  XDR  jest  osobna  i  niezależna 

od  produktów  Standard  Endpoint  Protection  Manager  i  Server  and  Workload  Protection 

Manager. 

W  konsoli  oferowanych  rozwiązań  Trend  Micro,  w  opcjach  wykrywania  zagrożeń 

za  pomocą  XDR  są  opcje  6.10.1,  6.10.4,  6.10.5.  Podpunkt  6.10  należy  do  punktu  „6. 

Zarządzanie Politykami Bezpieczeństwa musi uwzględnić:” czyli do ustawień polityk. Jeżeli w 

wykrywaniu zagrożeń za pomocą telemetrii XDR zostaną wprowadzone wyjątki, to nie będą 

one  działać  podczas  wykrywania  zagrożeń  bezpośrednio  w  produktach  Standard  Endpoint 

Protection  Manager  i  Server  and  Workload  Protection  Manager  czyli  w  rzeczywistym 

oprogramowaniu  antywirusowym.  Dlatego  wyjątki  możliwe  do  wprowadzenia  w  produkcie 

XDR  nie  powinny  być  brane  pod  uwagę.  Jednak  nawet,  uwzględniając  opcje  wyjątków  w 

produkcie XDR, nie są spełnione punkty 6.10.2, 6.10.3. 

Zamawiający w odpowiedzi na zarzut wskazał trzy poziomy, na jakich stopniowanie wyjątków 

i  ich  tworzenie  może  odbywać  się  w  oprogramowaniu  Trend  Vision  One.  Również 

Przystępujący w piśmie procesowym przedstawił przykład ścieżki prezentujący konfigurację 

zredukowania  monitorowania  konkretnego  procesu  i  jego  procesów  potomnych 

(notepad.exe), polegający na dodaniu dodatkowego warunku (st. 21-25). 

Izba oddaliła zarzut, jako bezpodstawny. Twierdzenia Odwołującego nie mają odniesienia do 

funkcjonalności oprogramowania Trend Vision One, wskazanych w pismach Zamawiającego 

i  Przystępującego.  Pomimo  wykazania  możliwości  wprowadzenia  dodatkowych  warunków 

pozwalających na zidentyfikowanie konkretnego procesu, Odwołujący stał na stanowisku, iż 

takiej  możliwości  nie  ma.  Nie  zostało  ono  w  żaden  sposób  wykazane,  co  prowadziło  do 

oddalenia zarzutu. Ocena funkcjonalności opisanej w pkt 6.10 nie może być sprowadzona do 

wybiórczego  przedstawiania  elementów  procesów,  które  nie  dają  całościowego  obrazu 

działania  zaoferowanego  systemu.  Stanowisko  Odwołującego  ponownie  sprowadzone 


zostało  do  wydzielenia,  jako  elementów  systemu  produktów  Standard  Endpoint  Protection 

Manager i Server and Workload Protection Manager i nie uwzględnia funkcjonalności całego 

produktu i jego działania.   

rozdział  II  OPZ,  pkt  6.11,  wymóg:  „rozwiązanie,  dla  wyjątków  typu  "Ścieżka"  w  systemie 

Linux  musi  mieć  możliwość  stopniowania  poziomu  wyjątków,  co  najmniej  w  następującym 

zakresie:  

6.11.1 wygaszenie alarmów,  

6.11.2 wyłączenie monitorowania konkretnego procesu”  

W ocenie Odwołującego oferowane rozwiązania Trend Micro nie spełniają tego zapisu. Nie 

ma opcji 6.11.1 i 6.11.2 dla ścieżki/path systemu Linux co przedstawiono na zrzutach ekranu  

Z

rzuty  ekranów  pochodzą  z  konfiguracji  polityki  w  produktach  ochrony  antymalware. 

Funkcjonalność  XDR  jest  osobna  i  niezależna  od  produktów  Standard  Endpoint  Protection 

Manager  i  Server  and  Workload  Protection  Manager.  Opcje  opisane  w  punktach  6.11.1  i 

6.11.2  są  tylko  dostępne  w  wyjątkach  wykrywania  zagrożeń  za  pomocą  XDR,  nie  dla 

antywirusa/polityki  agenta.  Podpunkt  6.10  należy  do  punktu  „6.  Zarządzanie  Politykami 

Bezpieczeństwa musi uwzględnić:” czyli do ustawień polityk a w ustawieniach polityki nie ma 

opisanych  opcji.  Jeżeli  w  wykrywaniu  zagrożeń  za  pomocą  telemetrii  XDR  zostaną 

wprowadzone wyjątki, to nie będą one działać podczas wykrywania zagrożeń bezpośrednio 

w  produktach  Standard  Endpoint  Protection  Manager  i  Server  and  Workload  Protection 

Manager czyli w rzeczywistym oprogramowaniu antywirusowym. Dlatego wyjątki możliwe do 

wprowadzenia w produkcie XDR nie powinny być brane pod uwagę.  

Z  uwagi  na  tożsamość  z  zarzutem  dotyczącym  spełnienia  wymagań  z  pkt  6.10,  rozdział  II 

OPZ,  Izba  podtrzymuje  stanowisko  przedstawione  powyżej  i  oddala  w  tym  zakresie 

odwołanie.  

rozdział  II  OPZ,  pkt  6.18,  wymóg:  „moduł  kontroli  sieci,  który  musi  być  zintegrowany  z 

funkcjonalnością tagowania hostów w oferowanym rozwiązaniu” 

Oferowane  rozwiązania  Trend  Micro  nie  spełniają  tego  wymagania.  Standard  Endpoint 

Protection Manager posiada tagowanie endpointów ale nie można ich wykorzystać w module 

kontroli sieci. Server and Workload Protection Manager posiada tagi tylko dla zdarzeń/logów, 

nie  ma  tagowania  dla  endpointów.  Nie  ma  integracji  modułu  kontroli  sieci  z  tagowaniem 

hostów. Możliwość tagowania ograniczająca się tylko do zdarzeń/logów w produkcie Server 

and Workload Protection Manager przedstawiono na zrzutach ekranu.  

Tylko dla zdarzeń, które na zrzucie są widoczne jako kolejne rzędy, można dodać tag („Add 

Tag(s)”).  


Odwołujący  formułując  tezę  o  braku  spełnienia  parametru  ponownie  odrębnie  traktuje 

produkty Standard Endpoint Protection Manager i Server and Workload Protection Manager, 

co nie przedstawia pełnej funkcjonalności zintegrowanego rozwiązania zaoferowanego i nie 

mogło  przesądzać  o  niezgodności  oferty  z  swz.  Ponownie  Odwołujący  w  sposób  dowolny 

przedstawia  tagowanie,  jako,  co  w  ocenie  składu  orzekającego  nie  może  być  wykazane 

przez wybiórczą analizę elementów systemu. 

rozdział  II  OPZ,  pkt  6.20,  wymóg:  „interfejs  graficzny  modułu  kontroli  sieci,  który  musi 

oferować  możliwość  importowania  wybranych  wyjątków  dla  kwarantanny  sieciowej 

rozwiązania z pliku .json.”  

W  ocenie  Odwołującego  rozwiązania  Trend  Micro  potrafią  jedynie  zaimportować  plik  z 

formatu XML co przedstawiają zrzuty ekranu z konsoli Trend Micro. Pokazują one możliwość 

eksportu reguł, w tym wyjątków czyli reguł dopuszczających ruch, do formatu możliwego do 

zaimportowania  w  postaci  XML,  tj.  „Export  to  XML  (For  Import)”  czyli  „Eksport  do  formatu 

XML  (na  potrzeby  importu)”  oraz  „Export  Selected  to  XML  (For  Import)”  czyli  „Eksport 

wybranych reguł do formatu XML (na potrzeby importu)”. XML to odmienny format pliku niż 

JSON.  Posiada  inną  strukturę  wewnętrzną.  JSON  (JavaScript  Object  Notation)  to  otwarty 

standardowy format tekstowy do wymiany danych.  Podczas przetwarzania informacji JSON 

wykorzystuje  mniej  pamięci  niż  XML  co  powoduje,  że  JSON  jest  lepszym  formatem  do 

szybkiego przetwarzania dużych ilości danych. Nie jest możliwe zastosowanie tego samego 

analizatora  składniowego  (parsera)  do  obu  formatów  jednocześnie  co  sprawia,  że  formaty 

JSON i XML nie są zamienne.  

Zamawiający w odpowiedzi wskazał na możliwość wykorzystania playbooka korzystającego 

z dostępnych funkcji API, który pozwala przekonwertować każdy format, w tym format XML 

do  pliku  .json.  Sposób  konfiguracji  playbooka  z  interfejsu  graficznego  przedstawił 

Przystępujący w piśmie procesowym na str. od 29 do 31. 

Izba  oddaliła  zarzut  przyjmując,  że  opisany  wymóg  nie  dyskwalifikuje  rozwiązania 

wykorzystującego  skrypt,  jako  elementu  funkcjonalności  całego  rozwiązania.  Nie  można  w 

ocenie  Izby  w  sposób  wybiórczy  badać  funkcjonalności.  Zamawiający  nie  wyłączył 

możliwości  wykorzystania  skryptów  (PowerShell,  Bash),  w  celu  importowania  wyjątków  dla 

kwarantanny sieciowej z pliku .json. 

rozdział  II  OPZ,  pkt  7.12,  wymóg:  rozwiązanie  musi  mieć  możliwość  filtrowania  stacji 

końcowych  na  których  został  zainstalowanych  agent,  co  najmniej  z  wykorzystaniem 

następujących parametrów: (...) – wskazane w pkt 7.12.1-7.12.17.  

W  ocenie  Odwołującego  rozwiązania  Trend  Micro  nie  spełniają  punktów  7.12.2  (tag 

przypisany  do  stacji  końcowej),  7.12.6  (domena  MS  Windows),  7.12.9  (stan  sieci  stacji 


końcowej),  7.12.15  (jakikolwiek  ciąg  znaków  z  domeny  Microsoft  Windows).  Zrzuty  ekranu 

pochodzą z różnych konsol zarządzania, punkty, które nie są spełnione dotyczą wszystkich 

konsol. W każdej z konsol jest tylko część wymienionych parametrów.  

Izba  oddaliła  zarzut,  który  opierał  się  na  błędnym  wydzieleniu  jako  odrębnych  produktów 

elementów  systemu  oferowanego.  Odwołujący  ponownie  w  tym  miejscu  traktuje  oddzielnie 

konsole  wyróżniając  ich  parametry,  co  nie  uwzględnia  faktu,  iż  zaoferowanym  system 

stanowi  zintegrowane  rozwiązanie  zarządzane  z  poziomu  jednej  wspólnej  konsoli 

zarządzania.  

rozdział  II  OPZ,  pkt  7.15,  7.16,  7.19  –  wymagania:  „7.15  rozwiązanie  musi  umożliwiać 

oznaczanie  hostów  poprzez  etykiety  (tagi);  7.16  każda  etykieta  (tag)  musi  być  określana 

poprzez parametr - 

nazwa etykiety (tagu); 7.19 rozwiązanie musi umożliwiać dopisanie wielu 

etykiet (tagów) do jednej stacji końcowej;“    

Odwołujący  wskazał,  iż  Standard  Endpoint  Protection  Manager  posiada  tagowanie 

endpointów  ale  nie  obsługuje  serwerów  Linux,  które  są  wymagane  do  obsługi  zgodnie  z 

wymaganiami  OPZ,  np.  Rozdział  II,  punkt  5.6.  „możliwość  automatycznej  aktualizacji 

agentów  zainstalowanych  na  stacjach  końcowych  z  systemem  operacyjnym:  Microsoft 

Windows  oraz  Linux;”.  Server  and  Workload  Protection  Manager  posiada  tagi  tylko  dla 

zdarzeń/logów,  nie  posiada  tagów  dla  hostów/stacji  końcowych.  Możliwość  tagowania 

ograniczająca  się  tylko  do  zdarzeń/logów  w  produkcie  Server  and  Workload  Protection 

Manager przedstawiona 

została na zrzutach ekranu z konsoli rozwiązań Trend Micro.  

Izba  oddaliła  zarzut,  który  opierał  się  na  błędnym  wydzieleniu  jako  odrębnych  produktów 

elementów  systemu  oferowanego.  Odwołujący  ponownie  w  tym  miejscu  traktuje  oddzielnie 

konsole  wyróżniając  ich  parametry,  co  nie  uwzględnia  faktu,  iż  zaoferowanym  system 

stanowi  zintegrowane  rozwiązanie  zarządzane  z  poziomu  jednej  wspólnej  konsoli 

zarządzania. Ponadto, Odwołujący w sposób dowolny nadaje znaczenia pojęciu „tagowanie”, 

jako opisywanie, wskazując również na brak precyzyjnego określenia w dokumentacji Trend 

Vision One czym są tagi i w jaki sposób można je dodać do hostów. W ocenie składu pojęcie 

to  jako  przypisane  i  zrozumiane  w  branży  nie  wymaga  szczegółowego  omawiania  i  samo 

wskazanie na TGA na zrzutach ekranów pozwala uznać, iż system oznacza hosty poprzez 

etykiety (tagi). 

rozdział  II  OPZ,  pkt  8.9,  wymóg:    „interfejs  graficzny  modułu  kontroli  sieci,  który  musi 

prezentować  reguły  w  formie  tabularycznej,  z  możliwością  definiowania  następujących 

kolumn:  

8.9.1 nazwa,  

8.9.2 opis,  


8.9.3 aplikacja,  

8.9.4 poziomami struktury rozwiązania, dla których reguły są aplikowane,  

8.9.5 system operacyjny,  

8.9.6 status (włączona / wyłączona),”  

Oferowane rozwiązania Trend Micro, w ocenie Odwołującego nie spełniają punktów 8.9.3 do 

8.9.6, co 

zostało zaprezentowane na zrzutach ekranu z konsoli. Zrzuty ekranu przedstawiają 

wszystkie  możliwe  do  zdefiniowania  kolumny  prezentowanych  reguł  w  formie  tabelarycznej 

interfejsu  graficznego  modułu  kontroli  sieci.  Oferowany  produkt  nie  posiada  możliwości 

definiowania kolumn wyszczególnionych w punktach 8.9.3 do 8.9.6. 

Zamawiający i Przystępujący w odpowiedzi na ten zarzut przedstawili zrzut z systemu Trend 

Micro  One  moduł  kontroli  sieci,  prezentujący  w  formie  tabelarycznej  kolumny  z  danymi. 

Odwołujący podważając informacje prezentowane przez oponentów sugerował, iż określenia 

FTP  nie  musi  identyfikować  aplikacji,  ale  porty  na  jakich  działa  i  w  zależności  od  ustawień 

serwera świadczącego usługę FTP będzie odzwierciedlać ustawienia domyślne.  

Tłumaczenie Odwołującego nie przekonało do uznania, iż rozwiązanie nie spełnia wymagań 

dotyczących  możliwości  definiowania  kolumn.  Przedstawione  w  piśmie  procesowym 

Przystępującego  zrzuty z  systemu Trend  Micro Vision  One  przekonały  skład,  iż  są  to  dane 

przedstawiane przez producenta, odpowiadające wymaganiom. Odwołujący podjął w piśmie 

procesowym  polemikę,  która  istotnie  wykraczała  poza  zarzut,  w  którym  kwestionował  sam 

brak  możliwości  definiowania  kolumn  w  zakresie  wyszczególnionym  w  pkt  8.9.3  do  8.9.6. 

Odwołujący odnosił się do wybranej reguły DNS Server, w której poziomy struktury nie jest 

prezentowane  w  formie  tabularycznej. 

W  ocenie  Izby  nie  podważało  to  informacji 

prezentowanych  w  pismach  Zamawiającego  i  Przystępującego  określających  poziom 

struktury rozwiązania, jak i system operacyjny (Windows, Linux). 

rozdział  II  OPZ,  pkt  9.4,  wymóg:  „zakres  czasu  raportów,  który  musi  być  możliwy  do 

zdefiniowania przez użytkownika konsoli zarządzającej;”  

W  opinii  Odwołującego,  w  oferowanych  rozwiązaniach  Trend  Micro  użytkownik  nie  może 

zdefiniować  zakresu,  może  tylko  wybrać  zakres  z  listy  zdefiniowanej  przez  producenta,  w 

przypadku  raportów  z  harmonogramu  (Scheduled  report),  jest  to  lista  zdefiniowanej  przez 

producenta  z  opcjami  dzień,  tydzień,  miesiąc,  w  przypadku  jednorazowych  raportów  (One 

time  report),  jest  to  lista  z  opcjami  7  dni,  30  dni. 

Przedstawiono  zrzuty,  które  opisują 

konfiguracje,  w  których  brakuje  możliwości  zdefiniowania  zakresu.  Podczas  prazy  z  innymi 

funkcjonalnościami  istnieje  możliwość  definiowania  zakresu  czasu,  np.  dla  wyszukiwania 

zdarzeń  w  funkcjonalności  XDR.  Przedstawiono  na  zrzucie  ekranu  możliwość  wyboru 

definiowanego zakresu (Custom period) w wyszukiwaniu zdarzeń XDR. Można wybrać dzień 


i  godzinę,  od  której  („From:”)  oraz  do  której  („To:”)  wyszukiwanie  będzie  obowiązywać. 

Podczas  tworzenia  raportów  rozwiązanie  nie  daje  takiej  możliwości  więc  nie  spełnia 

cytowanego wymagania, którego spełnienia wymaga Zamawiający.  

Przystępujący  w  piśmie  procesowym  wskazał  na  funkcję  Custom  Range,  w  której  istnieje 

możliwość wybrania dowolnego okresu za jaki ma być wygenerowany raport (w przykładzie – 

ostatnie 7 dni

, jak również możliwość wskazania przedziałem czasowym).  

Powyższe  zdaniem  składu  orzekającego  wskazuje  na  bezzasadność  zarzutu.  Dalsza 

argumentacja  Odwołującego,  w  tym  dotycząca  miejsca  w  którym  wygenerowane  raporty 

muszą  być  dostępne,  wykraczała  poza  podstawę  zarzutu.  Ponadto,  sam  Zamawiający  nie 

określał miejsca, w jakim raport ma być generowany. 

rozdział II OPZ, pkt 10.14, wymóg: „moduł zarządzania aktywnościami, który musi oferować 

możliwość filtrowania logów w następujących kategoriach:  

10.14.1 odpowiedź na zagrożenia;  

10.14.2 zarządzanie incydentami;  

10.14.3 wykluczenia;  

10.14.4 operacje administratorskie;  

10.14.5 email użytkownika konsoli;  

10.14.6 nazwa hosta.”  

W  ocenie  Odwołującego  rozwiązanie  nie  posiada  filtrowania  logów  w  kategoriach  10.14.1, 

10.14.2,  10.14.3,  10.14.5,  co  przedstawiono  na  zrzutach  ekranu  z  konsoli  oferowanych 

rozwiązań Trend Micro.  

Odwołujący  kwestionował  argumenty  Zamawiającego  podnosząc,  iż  prezentowane  w 

odpowiedzi  na  odwołanie  powiadomienia  generowane  w  systemie  nie  pochodziły  z  modułu 

zarządzania  aktywnościami.  Jednocześnie  Odwołujący  w  żaden  sposób  nie  skomentował 

twierdzenia  i  przykładu  przedstawionego  w  piśmie  Przystępującego  (str.  44  do  48),  który 

wprost  odnosi  się  do  akcji  będących  odpowiedzią  na  zagrożenia,  pochodzących  wprost 

modułu zarządzania, na co wskazuje dziennik logowania administratora z poziomu konsoli.  

W  ocenie  składu  orzekającego  zarzut  nie  miał  podstaw  i  wynikał  z  autorskiego 

przedstawienia działania systemu wybiórczo prezentowanego w odwołaniu. Należy również 

odnotować,  iż  w  uzasadnieniu  tego  i  wielu  innych  punktów  w  odwołaniu  stanowisko 

Odwołującego  sprowadzało  się  wyłącznie  do  zakwestionowania  danej  funkcjonalności  i 

przedstawienia wybranego na potrzeby konkretnego parametru obrazu. Dopiero w replice na 

stanowiska  procesowe  Odwołujący  szeroko  komentował  inne  wskazane  drogi  i  narzędzia 

pozwalające  ocenić  pozytywnie  rozwiązania  przyjęte  w  systemie  Trend  Micro  Vision.  W 

ocenie  składu  orzekającego  taka  taktyka  prowadzenia  sporu  prowadzi  często  do 


wykroczenia poza  zakres  okoliczności  wskazanych w  odwołaniu i  nie może  być skutecznie 

prowadzić  do  rozszerzenia  podstawy  faktycznej.  Jak  Izba  wskazywała  na  wstępie,  w 

przypadku  kwestionowania  danej  funkcjonalności  i  odniesienia  się  do  wybranego  jej 

elementu,  nie  można  na  etapie  rozprawy  skutecznie  twierdzić,  iż  zarzut  obejmuje  pełen 

zakres  funkcjonalności  wynikający  z  cytowanych  zapisów  OPZ.  Tylko  w  takim  zakresie  w 

jakim  Odwołujący  odniesie  się  w  odwołaniu  do  konkretnego  rozwiązania,  jest  możliwość 

prowadzenia  sporu  i  prezentowania  stanowisk.  Słusznie  zatem  Zamawiający  wskazał,  iż 

przygotowując odpowiedź  na  odwołanie kierował  się kwestiami  podniesionymi  w  podstawie 

faktycznej, wskazując na takie elementy systemu, które odpierały zarzut. Dalsza polemika o 

tych  elementach  nie  mogła  zatem  prowadzić  do  podnoszenia  nowych  kwestii,  nie 

poruszonych w samym zarzucie i jego uzasadnieniu faktycznym.  

rozdział II OPZ, pkt 10.15, wymóg: „moduł zarządzania aktywnościami, który musi oferować 

możliwość eksportowania wpisów 100, 1000, 5000 lub 10000 ostatnich aktywności do pliku 

.csv.”  

Odwołujący wskazał, iż dla modułu zarządzania aktywnościami nie ma możliwości eksportu 

określonej  liczby  wpisów, czego  wymaga  Zamawiający i  co jest  przedstawione na  zrzutach 

ekranu z konsoli oferowanych rozwiązań Trend Micro. Po wybraniu opcji „Export as .csv file.” 

czyli „Eksportuj jako plik .csv” eksportowane są wszystkie wyświetlone wpisy.  

W  odpowiedzi  na  tak  postawiony  zarzut  Zamawiający  i  Przystępujący  przedstawili  zrzuty 

prezentujące możliwości pobierania logów przez agenta końcowego dla przykładowych ilości 

wpisów 50, 100 lub 200. 

W  ocenie  Izby  wykazana  ilość  wpisów  100  potwierdza  wymóg  Zamawiającego.  Ilość  ta 

wprost referuje do wymagania z pkt 10.15.  

rozdział II OPZ, pkt 10.16, wymóg: „moduł zarządzania aktywnościami, który musi oferować 

możliwość  pobierania  logów  zebranych  przez  agenta  końcowego  po  wydaniu  komendy  z 

poziomu modułu zarządzania;”  

W  ocenie Odwołującego  moduł  zarządzania  aktywnościami  (Audit  Log)  nie  ma takiej  opcji, 

co  potwierdza

ć  ma  zrzut  ekranu z  konsoli  oferowanych rozwiązań Trend Micro.  Na zrzucie 

ekranu  z  modułu  zarządzania aktywnościami  (Audit  Log) jedynymi  dostępnymi  opcjami jest 

filtrowanie wpisów i eksportowania ich jako pliku CSV.  

Przystępujący i Zamawiający przedstawili możliwości modułu zarządzania z wykorzystaniem 

funkcji  get  events

,  służącej  zbieraniu  logów  przez  agenta  końcowego  (oprogramowanie 

zainstalowane na stacji administratora). 


Samo  zaprzeczenie  przez  Odwołującego  możliwości  systemu  nie  jest  wystarczające  dla 

podważenia  funkcjonalności  oprogramowania.  Izba  oddaliła  na  tej  podstawie  zarzut  jako 

bezpodstawny. 

rozdział  II  OPZ,  pkt  10.23,  wymóg:  „zarządzanie  notyfikacjami,  które  musi  umożliwiać 

wyszukiwanie pojedynczego rodzaju zdarzenia poprzez wyszukiwarkę tekstową;”  

Odwołujący  przedstawił  zrzut  z  ekranu,  na  którym  nie  ma  okna  lub  sekcji,  w  której  można 

przeprowadzić wyszukiwanie powiadomień. Jest dostępna lista powiadomień ale nie można 

ich wyszukać poprzez wyszukiwarkę tekstową.  

Zamawiający i Przystępujący przedstawili możliwości, jakie daje wyszukiwarka tekstowa dla 

wyszukiwania pojedynczego zdarzenia. 

Izba  oddaliła  odwołanie,  jako  mające  uzasadnienie  wyłącznie  w  wybiórczej  analizie 

rozwiązania,  posiadającego  możliwość  wyszukiwania  pojedynczego  zdarzenia  poprzez 

wyszukiwarkę  tekstową.  Argumenty  Odwołującego  nie  podważają  przykładów  działania 

systemu wykazane w pismach procesowych Zamawiającego i Przystępującego.  

rozdział II OPZ, pkt 10.24, wymóg: „10.24 zarządzanie notyfikacjami, które musi wyróżniać 

następujące typy powiadomień:  

10.24.1 administracyjne;  

10.24.2 kontrola urządzeń;  

10.24.3 tagi urządzeń;  

10.24.4 kontrola firewall;  

10.24.5 malware;  

10.24.6 łagodzenie incydentów;  

10.24.7 operacje;  

10.24.8 Remote Shell;”  

Odwołujący kwestionuje spełnienie wymagań w zakresie podpunktów 10.24.3, 10.24.6 oraz 

10.24.8,  co  przedstawiono  na  zrzucie 

ekranów  z  konsoli  oferowanych  rozwiązań  Trend 

Micro.  Zrzuty  ekranów  przedstawiają  miejsca,  w  których  można  konfigurować  notyfikacje. 

Ponieważ  oferta  składa  się  z  wielu  produktów,  konfiguracja  notyfikacji  nie  jest  możliwa  w 

pojedynczym  panelu.  Na  zrzutach  ekranów  przedstawiono  wszystkie  możliwe  do 

skonfigurowania notyfikacje.  

Izba oddaliła zarzut oparty na rozróżnieniu, jako dwóch niezależnych produktów, jak również 

odmiennego  rozumienia  tagowania,  które  Odwołujący  nadaje  w  odwołaniu.  Argumenty 

Odwołującego nie były wystarczające dla podważenia możliwości, jakie zostały wykazane w 

pismach procesowych Zamawiającego (str. 39, 40) i Przystępującego (str. 53-55). 


II.  Zarzuty dot

yczące oferty złożonej przez Trafford IT  

Zgodnie ze złożoną ofertą, Trafford IT, zaoferowało oprogramowanie Cortex XDR producent 

Palo Alto Networks.  

W  ocenie  Odwołującego  zaoferowane  oprogramowanie  nie  spełnia  wymagań  określonych 

przez  Zamawiającego  w  opisie  przedmiotu  zamówienia.  W  ofercie  nie  podano  rodzaju 

licencji, 

co  uniemożliwia  wskazanie  konkretnego  rozwiązania.  W  ofercie  wymieniony  jest 

produkt „Cortex XDR” ale ten produkt nie jest sprzedawany w takiej formie, jest sprzedawany 

jako Cortex XDR Prevent lub Cortex XDR Pro. 

Na  podstawie  wyróżnienia  tych  produktów  Odwołujący  kwestionował  spełnienie 

szczegółowych parametrów stanowiących wymagania dotyczące przedmiotu zamówienia. 

Izba oddaliła zarzuty wobec tej oferty przyjmując, jako istotną z punktu widzenia argumentów 

okoliczność  wskazaną  w  odpowiedzi  na  odwołanie,  o  nieaktualności  dokumentów 

dotyczących  produktów  Cortex  XDR  Pro  o  Prevent.  Pomimo  oczywistej  niespójności 

argumentacji  z  obecnym  stanem,  Odwołujący  próbował  wykazać  niezgodność,  której 

podstawa  opiera  się  na  wyróżnieniu  dwóch  produktów,  które  Wykonawca  miał 

zidentyfikować  w  ofercie.  Zamawiający  wskazując  na  aktualną  dokumentację  wykazał,  iż 

oprogramowanie  Cortex  XDR  to  rozszerzona  chmurowa  platforma  wykrywania  zagrożeń 

posiadająca  funkcjonalności  całego  rozwiązania  XDR.  Odnoszenie  się  do  szczegółowych 

parametrów  w  tych  okolicznościach  nie  miało  znaczenia,  gdyż  w  każdym  z  parametrów 

należałoby  wskazać,  iż  zarzut  opiera  się  na  błędnym  założeniu  co  do  istoty  rozwiązania 

XDR. 

W świetle powyższego odwołanie w całości podlegało oddaleniu. 

Orzekając  o  kosztach  postępowania  odwoławczego  orzeczono  stosownie  do  wyniku  na 

podstawie art. 575 Ustawy 

Prawa zamówień publicznych oraz w oparciu o przepisy § 5 ust. 2 

w zw. z 

§ 8 ust. 2 pkt 1 rozporządzenia Prezesa Rady Ministrów z dnia 31 grudnia 2020 r. w 

sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz 

wysokości i sposobu pobierania wpisu od odwołania (Dz. U. poz. 2437).  

I

zba  zaliczyła  do  kosztów  postępowania  wpis  w  wysokości  15.000  zł  i  obciążyła  nimi  w 

całości Odwołującego.  

Przewodnicząca: 

……………………..….