Wyrok KIO 5818/26

Odwołanie zostało wniesione do Prezesa Krajowej Izby Odwoławczej w dniu 22 grudnia 2​ 025 r. przez wykonawcę InfoSoftware Polska Sp. z o.o. z/s w Szczepańcowej (Odwołujący) w postępowaniu prowadzonym na podstawie ustawy z dnia 11 września 2019 r. - Prawo zamówień publicznych (Dz. U. z 2024 r. poz.

1320 ze zm.), [ustawa Pzp lub Pzp lub Ustawa PZP] w trybie konkursu nieograniczonego, jednoetapowego, realizacyjnego na: „Opracowanie koncepcji architektonicznej szkoły ponadpodstawowej wraz z poradnią psychologicznopedagogiczną w Tarczynie” (Konkurs SARP nr 1082) przez Zamawiającego: Powiat Żyrardowski ul. Limanowskiego 45 96300 Żyrardów. Przedmiotem zamówienia jest: „Dostawa i wdrożenie systemu bezpieczeństwa SIEM/SOAR w ramach projektu grantowego „Cyberbezpieczny Samorząd” – Znak sprawy: ZP.272.5.29.2025.). Ogłoszenie nr 2025/BZP 00509036/01).

Wykonawca podał: (…) wnoszę odwołanie od niezgodnych z przepisami PZP czynności i zaniechania dokonania czynności przez Zamawiającego w postaci:

1. odrzucenia oferty Odwołującego jako niezgodnej z warunkami zamówienia w sytuacji, gdy oferta ta jest zgodna z tymi warunkami, a oferowany system spełnia wszystkie wymagania Zamawiającego, a sama ocena intuicyjności rozwiązań jest ocena subiektywną, sprzeczną z ustawą; 2.odrzucenia oferty Odwołującego jako zawierającej rażąco niska cenę w sytuacji, gdy Wykonawca przedstawił wyczerpujące wyjaśnienia potwierdzające, że oferowana cena nie jest rażąco niska;
2. wyboru jako najkorzystniejszej oferty podlegającej odrzuceniu,
3. zaniechania odrzucenia oferty TK-MED. Sp. z o.o. jako niezgodnej z warunkami zamówienia w zakresie zgodności oferowanego systemu z wymaganiami Zamawiającego. ewentualnie
4. zaniechania unieważnienia postępowania jako obarczonego niemożliwą do usunięcia wadą, która powoduje niemożność zawarcia niepodlegającej unieważnieniu umowy, tj. z uwagi na wewnętrznie sprzeczny i niejednoznaczny opis przedmiotu zamówienia, który nie pozwala na prawidłową ocenę ofert, jak również dający Zamawiającemu prawo subiektywnej oceny niezgodności systemu z jego oczekiwaniami.

Zamawiającemu zarzucam naruszenie:

1. art. 226 ust. 1 pkt 5) w zw. z art. 16 pkt 1) - 3) ustawy Pzp, poprzez bezzasadne odrzucenie oferty Odwołującego jako niezgodnej z warunkami zamówienia, gdy w rzeczywistości oferowany system spełnia wszystkie wymagania określone przez Zamawiającego w OPZ, a ocena intuicyjności rozwiązań jest sprzeczna z ustawą i nieproporcjonalna do zaspokojenia uzasadnionych potrzeb Zamawiającego, 2)art. 226 ust. 1 pkt 8) w zw. z art. 224 ust. 6 ustawy Pzp, poprzez błędne uznanie, że cena oferty Odwołującego jest rażąco niska i niezaakceptowanie wyjaśnień złożonych przez Odwołującego, gdy wyjaśnienia te potwierdzają, że cena nie jest rażąco niska, 3)art. 226 ust. 1 pkt 5) w zw. z art. 16 pkt 1) i 2) ustawy Pzp, poprzez zaniechanie odrzucenia oferty TK-MED Sp. z o.o., gdy zaoferowany przez tego wykonawcę system nie posiada wymaganych opisem przedmiotu zamówienia funkcjonalności, 4)art. 239 ust. 1 i 2 ustawy Pzp, poprzez wybór oferty, która najkorzystniejsza nie jest, ewentualnie, w przypadku nieuwzględnienia zarzutów 1 lub 2:
2. art. 239 ust. 1 i 2 ustawy Pzp, poprzez wybór oferty sytuacji, w której postępowanie podlega unieważnieniu, 6)art. 255 pkt 6) w zw. z art. 457 ust. 1 pkt 1) w zw. z art. 99 ust. 1 i 4 i w zw. z art. 16 pkt 1) i 2) ustawy Pzp ustawy Pzp, poprzez zaniechanie unieważnienia postepowania w sytuacji, gdy postępowanie to obarczone jest niemożliwą do usunięcia wadą, która powoduje niemożność zawarcia niepodlegającej unieważnieniu umowy, wynikającą z wewnętrznie sprzecznego i niejednoznacznego opisu przedmiotu zamówienia, który nie pozwala na prawidłową ocenę ofert, jak również daje Zamawiającemu prawo subiektywnej oceny niezgodności systemu z jego oczekiwaniami przez pryzmat niezdefiniowanej intuicyjności.

Wskazując na powyższe zarzuty, wnoszę̨ o:

I.uwzględnienie odwołania, II.nakazanie Zamawiającemu: a)unieważnienie czynności wyboru oferty najkorzystniejszej, b)unieważnienie czynności odrzucenia oferty Odwołującego, c)ponowienie procedury badania i oceny ofert, w tym odrzucenie oferty TK- MED. Sp. z o.o.,a w przypadku uwzględnienia zarzutów ewentualnych d)unieważnienie postępowania.

Nadto, wnoszę̨ o:

I.(…), II.dopuszczenie i przeprowadzenie dowodów z dokumentów załączonych do odwołania na okoliczności wskazane w uzasadnieniu odwołania, III.zobowiązanie Zamawiającego do załączenia dokumentacji postępowania o udzielenie zamówienia, którego dotyczy odwołanie, IV.zobowiązanie Zamawiającego do wniesienia pisemnej odpowiedzi na odwołanie.

W uzasadnieniu stanowiska wskazał na następujące okoliczności:

I.Interes we wniesieniu odwołania Zgodnie z art. 505 ust. 1 Pzp środki ochrony prawnej przewidziane w ustawie przysługują̨ podmiotowi, który ma lub miał interes w uzyskaniu danego zamówienia oraz poniósł lub może ponieś́ ć szkodę̨ w wyniku naruszenia przez zamawiającego przepisów Pzp. Odwołujący się złożył ofertę w postępowaniu, która zgodnie z informacją z dnia 17 grudnia br. została odrzucona. Oferta Odwołującego była jedyną ofertą złożona poza ofertą, której wyboru dokonał Zamawiający. W ocenie Odwołującego, prawidłowa ocena ofert, nie powinna skutkować odrzuceniem oferty Odwołującego, a powinna prowadzić do odrzucenia oferty TK-MED. Sp. z o.o. Przesłanką legitymacji do wniesienia odwołania jest także możliwość poniesienia szkody w wyniku naruszenia przez Zamawiającego przepisów Pzp.

Odwołujący prowadzi działalność gospodarczą, która koncentruje się m.in. wokół dostaw oprogramowania dla jednostek sektora finansów publicznych. Znaczna część zobowiązań Odwołującego, dotyczy kontraktów pozyskanych w wyniku udzielenia zamówienia publicznego. Zainteresowanie Odwołującego uzyskaniem zamówienia będącego przedmiotem postępowania prowadzonego przez Zamawiającego jest zatem związane bezpośrednio z profilem jego działalności.

Jakiekolwiek naruszenia po stronie Zamawiającego, które mogą mieć wpływ na końcowy wynik postepowania, w przedmiotowym stanie faktycznym wprost narażają Odwołującego na szkodę i utratę jednego ze źródeł dochodu. W rezultacie, utrzymanie w mocy decyzji Zamawiającego będzie skutkowało uniemożliwieniem Odwołującemu uzyskania

przedmiotowego zamówienia i osiągnięcia oczekiwanego zysku w sytuacji, gdy wybór oferty najkorzystniejszej dokonany został wbrew ustawie. Jednocześnie, nawet w sytuacji oddalenia zarzutów co do bezzasadnego odrzucenia oferty Odwołującego, posiada on interes w żądaniu unieważnienia postępowania. Działania Zamawiającego musza pozostawać transparentne i obiektywne, a pozycja wykonawców równa z perspektywy dostępu do zamówienia i zasad oceny ich świadczeń. Utrzymanie w mocy decyzji o wyborze oferty najkorzystniejszej w świetle zaniechań dotyczących opisu przedmiotu zamówienia będzie prowadziło do uznania, że zamawiający mają prawo do bezrefleksyjnego tworzenia dokumentów zamówienia, a następnie do subiektywnej, niepoddanej żadnej kontroli oceny ofert. W związku z powyższym uznać należy, że Odwołującemu się̨ przysługuje interes do wniesienia niniejszego odwołania.

II.Opis stanu faktycznego Przedmiotem zamówienia jest dostawa i wdrożenie systemu bezpieczeństwa SIEM/SOAR opisanego w Załączniku nr 8 do SWZ – Opis przedmiotu zamówienia. Zgodnie ze wspomnianym opisem: (str. 1 Załącznika nr 8 do SWZ) (str. 2 Załącznika nr 8 do SWZ) Zgodnie z treścią Opisu przedmiotu zamówienia system musi spełniać powyższe wymagania. A contrario, literalne znaczenie słowa „musi” oznacza, że oferowany system nie może nie posiadać którejkolwiek z wymaganych funkcjonalności. Jednocześnie w dalszej części Opisu przedmiotu zamówienia, Zamawiający zawarł następujący opis: (str. 21 i 22 Załącznika nr 8 do SWZ) Zamawiający nie zdefiniował w żaden sposób co i w jaki sposób (w oparciu o jakie kryteria) będzie oceniał pod kątem „intuicyjności”. Dodatkowo, Zamawiający w sposób niejasny i sprzeczny z pozostałą treścią Opisu przedmiotu zamówienia opisał zasady oceny „Zgodności”. Zgodnie z tym opisem, system może nie posiadać funkcjonalności, co do których Zamawiający napisał wcześniej, że posiadać je musi.

W postępowaniu oferty złożyło dwóch Wykonawców:

Wykonawca TK-MED Sp. z o.o. zaoferował system, którego nie jest producentem. Odwołujący zaoferował własny system IS Sec Scan.

Zamawiający dokonując oceny zaoferowanych systemów, oceniał w zakresie oferty TK-MED Sp. z o.o. m.in. wymagania dotyczące spełniania przez system pkt 11) OPZ (wspomnianego na str. 6 odwołania).

Zgodnie z formularzem oceny, system nie wspiera składni URI, co do której OPZ wskazywał, że funkcjonalność taką musi posiadać.

W pozostałym zakresie Zamawiający nie znalazł brakujących funkcjonalności, a oceniając „Intuicyjność” przyznał niemal w każdym aspekcie maksymalną ocenę.

Dokonując oceny systemu Odwołującego, Zamawiający stwierdził rzekomy brak wielu funkcjonalności oraz negatywnie ocenił „Intuicyjność” większości ocenianych wymagań, opisując m.in.: − „Wszystkie nazwy po angielsku, brakuje opisów i wyjaśnienia co dana funkcja robi. Istnieje możliwość wyszukiwania po nazwie” − „Mapa znajduje się w podmenu, posiada wymiary 966x800 na ekranie FullHD, co stanowi 37,3% powierzchni ekranu, a schowanie paska bocznego nie powiększa obrazu. Wykorzystanie monitora o większej rozdzielczości nie zwiększa obszaru roboczego mapy. Tym samym cała mapa jest mała i nieczytelna”; lub podnosząc, że pewnych funkcjonalności nie odnalazł.

Korzystając z uprawnienia wskazanego w pkt 145 lit. g) OPZ, Odwołujący zaproponował spotkanie w formie zdalnej za pomocą platformy Teams, podczas którego odniesie się do wyników ocen zgodności i intuicyjności systemu opracowanych przez Zamawiającego.

W pkt 145 lit. g) nie określono żadnych szczególnych obowiązków związanych ze sposobem odniesienia się do oceny Zamawiającego.

Na spotkaniu 2 grudnia 2025 r. Zamawiający podniósł, że oczekuje prezentacji systemu „na żywo” nie informując o takich planach wcześniej, do czego Odwołujący nie był przygotowany. Mimo to Odwołujący wyjaśnił, że jako producent oprogramowania posiada wiedzę co do tego, że zarzuty stawiane przez Zamawiającego są niezasadne, a system posiada wszelkie wymagane funkcjonalności.

Jednocześnie, z uwagi na wyrażoną przez Zamawiającego potrzebę odbycia prezentacji każdego z wątpliwych wymagań, Odwołujący zaproponował niezwłoczne zorganizowanie dodatkowego spotkania, na którym taka prezentację przeprowadzi zgodnie z życzeniem Zamawiającego. Nagranie było nagrywane.

Mimo wysuniętej propozycji, Zamawiający nie wyraził woli uczestnictwa w takim spotkaniu.

Pismem z 4 grudnia 2025 r. Zamawiający wezwał Wykonawcę do wyjaśnienia, na podstawie art. 224 ust. 1 ustawy pzp, do złożenia wyjaśnień w zakresie ceny „w celu weryfikacji możliwości wykonania przedmiotu zamówienia zgodnie z wymaganiami określonymi w dokumentach zamówienia lub wynikającymi z odrębnych przepisów.”

Wyjaśnienia te Odwołujący złożył w terminie wskazanym przez Zamawiającego w sposób wyczerpujący, odnosząc się do wszystkich istotnych dla wykonania zamówienia kosztów, w tym kosztów wdrożenia, kosztów prac konfiguracyjnych i programistycznych, kosztów licencji, wsparcia technicznego na okres 12 miesięcy. Jednocześnie Odwołujący przedstawił informacje o założonej rezerwie finansowej i spodziewanym zysku. W wyjaśnieniach przedstawiono także szczegółową metodologię i harmonogram prac, wyjaśnienie w zakresie braku kosztów ukrytych oraz stosowanych rozwiązań technicznych.

Złożone wyjaśnienia były w pełni wystarczające do uznania, że Odwołujący jako producent oferowanego systemu, nie oferuje go po cenie rażąco niskiej.

Mimo podjętych przez Odwołującego działań, Zamawiający w dniu 17 grudnia poinformował o odrzuceniu oferty Odwołującego i wyborze oferty TK-MED Sp. z o.o. jako najkorzystniejszej.

Z decyzją Zamawiającego nie sposób się zgodzić.

III.Analiza prawna - Zarzut nr 1 Zgodnie z art. 226 ust. 1 pkt 5) ustawy Pzp, Zamawiający odrzuca ofertę Wykonawcy, jeżeli jej treść jest niezgodna z warunkami zamówienia. Warunki zamówienia należy rozumieć zgodnie z definicją wyrażoną w art. 7 pkt 29 Pzp, która stanowi, że poprzez warunki zamówienia należy rozumieć warunki, które dotyczą zamówienia lub postępowania o udzielenie zamówienia, wynikające w szczególności z opisu przedmiotu zamówienia, wymagań związanych z realizacją zamówienia, kryteriów oceny ofert, wymagań proceduralnych lub projektowanych postanowień umowy w sprawie zamówienia publicznego.

Zamawiający zarzucił Odwołującemu, że oferowany system IS SEC nie spełnia wymagań i posiada określone błędy powodujące niespełnienie następujących punktów OPZ: 1), 11), 23) – wyłącznie w zakresie „intuicyjności”, 51) – wyłącznie w zakresie „intuicyjności”, 75) – wyłącznie w zakresie „intuicyjności”, 87), 122), 125) oraz części wymagań stawianych funkcjonalności dodatkowej.

W tym miejscu należy zauważyć, że niezgodność z warunkami zamówienia może dotyczyć różnych aspektów – np. opisu przedmiotu zamówienia lub wymagań proceduralnych. Każda niezgodność wymaga innego dowodzenia ze strony Zamawiającego. Niezgodność systemu z opisem przedmiotu zamówienia musi być dowiedziona przez Zamawiającego, a nie jedynie domniemana. Zgodnie z wyrokiem KIO 199/24 - Niezgodność oferty z warunkami zamówienia musi być oczywista i niewątpliwa, czyli zamawiający musi mieć pewność co do niezgodności oferty z jego oczekiwaniami, przy czym postanowienia SW Z powinny być jasne i klarowne. (...) Aby możliwe było odrzucenie oferty na podstawie art. 226 ust. 1 pkt 5 p.z.p. niezgodność treści oferty z warunkami zamówienia musi być pewna i oczywista, tym samym nie może to być niezgodność wyinterpretowana z treści niestanowiących pełnych danych o planowanym rozwiązaniu projektowym.

Również w wyroki KIO 202/24 Izba uznała, że „odrzucenie oferty wykonawcy na podstawie art. 226 ust. 1 pkt 5 p.z.p. musi nastąpić w razie stwierdzenia niebudzącej wątpliwości sprzeczności oferty wykonawcy z jednoznacznymi postanowieniami, wynikającymi z dokumentów zamówienia.”

Tymczasem Zamawiający nie udowodnił, że oferowany system jest niezgodny z opisem przedmiotem zamówienia.

Zamawiający jedynie przyjął taką tezę w wyniku wadliwie przeprowadzonej procedury badania próbki, w tym w zakresie uniemożliwienia prezentacji systemu po pierwszym nieudanym spotkaniu, na którym Zamawiający przedstawił oczekiwania wcześniej nie sygnalizowane. Odnosząc się do poszczególnych uwag Zamawiającego należy wyjaśnić jak poniżej:

WADA Zamawiający w pkt. 1 opisu przedmiotu zamówienia sformułował zakaz stosowania rozwiązań typu open source, w tym expressis verbis wymienił Elastic Security jako niedopuszczalne. Weryfikacja próbki systemu wykazała, że „iS SEC SIEM” realizuje podstawowe mechanizmy właśnie poprzez Elastic Security. Oznacza to, że zaoferowany system stoi w sprzeczności z zakazem zawartym w opisie przedmiotu zamówienia, wymienionym jako przykładowy (por. pkt. 1 opisu przedmiotu zamówienia).” Treść Punktu 1.:

„1) Zamawiający nie dopuszcza rozwiązań z otwartym kodem źródłowym ani rozwiązań darmowych, w tym rozwiązań posiadających płatne opcje wsparcia z darmowym oprogramowaniem jak np. Elastic Security, AlienVault, Wazuh, OSSIM, Snort itp."

WYJAŚNIENIE Zgłoszona przez Zamawiającego powyższa „wada” systemu jest całkowicie nieuzasadniona. Po pierwsze Zamawiający podczas weryfikacji próbki systemu nie miał możliwości stwierdzić, że System iS Sec realizuje podstawowe mechanizmy przez Elastic Security. W przedstawionej Wykonawcy próbce nie było informacji na temat technologii i silników, z których korzysta System. Aby to sprawdzić Zamawiający musiałby mieć dostęp do kodu źródłowego Systemu iS Sec, lub mieć dostęp do konsoli zarządzającej silnikiem Elastic Search (indeksowa baza danych typu noSQL).

Wykonawca nie udostępnił Zamawiającemu kodu źródłowego oraz nie dał dostępów do Elastic Search. Wykonawca w opisie do omawianego punktu przesłanym do Zamawiającego również nie wskazał tej technologii (Elastic Security) tylko

dokładnie wymienił Elastic Search. Wykonawca nie wie na jakiej podstawie zamawiający stwierdził, że system ISSec realizuje podstawowe mechanizmy poprzez Elastic Security. Wykonawca stwierdza, że tego typu zgłoszona „wada” wynika z nieznajomości rozwiązań stosowanych w Systemie iS Sec, oraz rozwiązań i technologii Elastic. Elastic Search i Elastic Security są to różne rozwiązania, stosowane w różnych celach. Elastic Search to indeksowa baza danych, która służy w systemie iS Sec jako kolektor logów, jest to technologia bardzo rozpowszechniona i stosowana nawet przez takich gigantów jak Amazon. Odrzucanie tej technologii jest tożsame z odrzucaniem takich baz danych jak MS SQL Express, czy MySQL stosowanych najczęściej przez różnych producentów. Elastic Security natomiast jest to platforma/system od firmy Elastic bazująca na Elastic Search tak samo jak oferowany przez Wykonawcę System iS Sec.

Wykonawca nie zgadza się również z tym, że omawiany i przedstawiony powyżej punkt 1) z OPZ wyklucza z postępowania system iSSec.

1. Zamawiający nie dopuszcza rozwiązań z otwartym kodem źródłowym Oferowany system iS Sec nie jest systemem z otwartym kodem źródłowym, nie można nigdzie pobrać jego źródła, a klientom dostarczane są tylko skompilowane rozwiązanie (w sloganie informatycznym tzw. binarki).
2. ani rozwiązań darmowych, Oferowany system iS Sec nie jest system darmowym i nigdzie nie można go pobrać za darmo. System IS sec posiada własny serwer licencyjny, który pilnuje ilości instalowanych urządzeń końcowych, czy licencji okresowych.
3. w tym rozwiązań posiadających płatne opcje wsparcia z darmowym oprogramowaniem jak np. Elastic Security, AlienVault, Wazuh, OSSIM, Snort itp.

Oferowany system iS Sec nie jest rozwiązaniem posiadającym płatne opcje wspracia z darmowym oprogramowaniem jak np. Elastic Security, AlienVault, Wazuh, OSSIM, Snort itp. Wykonawca nie oferuje Zamawiającemu wdrażania żadnego ze wskazanych tutaj systemów. Wykonawca w ramach realizacji takiego zamówienia, wdraża własny system z jego wszystkimi komponentami. Jest to komercyjny system posiadający autorskie rozwiązania umożliwiające centralne zarządzanie infrastrukturą pod kątem cyberbezpieczeństwa takie jak np. analiza behawioralna UEBA, analiza danych AI (wsparcie w analizie logów, problemów, zagrożeń, anomalii) czy tworzenie scenariuszy automatyzujących reakcje na raportowane incydenty bezpieczeństwa. System wyposażony jest we własne mechanizmy SIEM/SOAR.

Ponadto zapis OPZ odnosi się do rozwiązań jako całości, nie do technologii użytej wewnętrznie. –„rozwiązania open-source” - chodzi o system oferowany zamawiającemu, nie o frameworki, bazy danych czy silniki. –„rozwiązania darmowe” - chodzi o system oferowany zamawiającemu, nie o komponenty wewnętrzne. –„rozwiązania free + paid (jak Elastic Security)” - chodzi o produkty dostępne dla klienta w darmowej wersji podstawowej.

WADA Zgodnie z pkt. 11 opisu przedmiotu zamówienia, Zamawiający określił sposób realizacji funkcjonalności tworzenia parserów, wymagając, aby odbywało się to poprzez graficzny interfejs. W wyniku weryfikacji próbki systemu Zamawiający stwierdził brak funkcjonalności parsowania logów dla następujących typów składni z poziomu interfejsu użytkownika: a) CEF, b)LEEF, c) URI, d) XML, e) JSON, f) SYSLOG, g) REGEX.

Opis dostarczony przez Wykonawcę wskazywał na konieczność ich wykonania poza środowiskiem graficznym. Ponadto Zamawiający Ponadto w udostępnionej próbce systemu nie odnaleziono możliwości dalszej normalizacji, zaś opis Wykonawcy nie wskazywał miejsca dostępności tej funkcji.

WYJAŚNIENIE W odniesieniu do tej „wady” systemu iS Sec wykonawca również całkowicie się nie zgadza ze stwierdzeniami Zamawiającego. Nie prawdą jest, że Wykonawca wskazywał w przesłanym zamawiającemu opisie na konieczność ich wykonania poza środowiskiem graficznym.

Zamawiający otrzymał opis:

„OPD. System wyposażony jest w Moduł analizy logów spełniający powyższe wymagania, module tym możliwe jest wyświetlanie i wyszukiwanie wstępnie sprasowanych/niesparowanych logów z różnych źródeł. W zakładce indeksy użytkownik może utworzyć własny indeks oraz w szczegółach indeksu skopiować/podglądnąć dostęp do niego przez udostępnione API. Ponadto w zakładce „Niestandradowe logi”, użytkownik może wskazać lokalizację źródła logów poprzez podanie ścieżki do pliku/plików na wybranym hoście oraz przypisanie ich do utworzonego wcześniej indeksu.

Możliwość tworzenia parserów znajduję się w zakładce Parsery i jest dość rozbudowana, a przy użyciu składni GROK umożliwia tworzenie praktycznie dowolnych parserów. System umożliwia dowolne parsowanie wstępne i końcowe. Oraz automatycznie rozpoznaje wymienione formaty.

Scenariusz testowania:

1. Zaloguj się do Systemu ISSec z przeglądarki internetowej.
2. Wybierz Moduł analizy logów
3. Przeglądnij zakładkę „Niestandardowe logi” 4.Przeglądnij zakładkę „Parsery” 5.Przeglądnij zakładkę „indexy” 6.Przeglądnij zakładkę „Zaawansowane wyszukiwanie” Nigdzie w tym zapisie nie jest napisane, że jest konieczne ich wykonanie poza środowiskiem graficznym. Wykonawca domyśla się, że Zamawiającemu chodziło o stwierdzenie „a przy użyciu składni GROK umożliwia tworzenie praktycznie dowolnych parserów”, tylko że system iS Sec umożliwia tworzenie dowolnych parserów przy użyciu składni GROK (nie całego skryptu) z poziomu GUI. Poniżej zrzuty ekranu z GUI Systemu iS Sec: (…) Gdyby Zamawiający znał GUI systemu na pewno odnalazłby te funkcjonalności. Scenariusz testowania mówił o przeglądnięciu tych zakładek, i gdyby testujący nacisnął przycisk „Dodaj parser”, to znalazłby tam wszystkie wymagane w tym punkcie funkcjonalności: (…) f) SYSLOG g) REGEX. Wyrażenia regularne Grok (…) Ponadto aby stworzyć np. parser SYSLOG należy dodać źródło danych. Aby to zrobić trzeba mieć dostęp do urządzenia SYSLOG i przekierować logi tego urządzenia po konkretny adres. Gdyby Zamawiający dobrze sprecyzował w jaki sposób będzie wykonywana weryfikacja systemu, to można by jakoś to przygotować. Zamawiający nie posiadający wiedzy o architekturze systemu iS Sec, wiedzy o podstawowych zasadach jego funkcjonowania nie miał możliwości zweryfikowania, czy np. SYSLOG jest parsowany. Bo nie mógł dodać w systemie źródła logów, ponieważ testowanie było wykonywane na infrastrukturze sieciowej udostępnionej przez Wykonawcę, o której Zamawiający nie miał żadnych informacji. Poniżej przykłady sparsowania LEEF i SYSLOG.

Ostatnią „wadą” systemu wskazaną przez Zamawiającego w tym zakresie jest: „Ponadto Zamawiający Ponadto w udostępnionej próbce systemu nie odnaleziono możliwości dalszej normalizacji, zaś opis Wykonawcy nie wskazywał miejsca dostępności tej funkcji.”

Wykonawca w scenariuszu wskazał na przeglądnięcie zakładki Indeksy, w której powyższa funkcjonalność się znajduje.

Nieznajomość tego rozwiązania (systemu iS Sec) uniemożliwiła Zamawiającemu naciśnięcie przycisku „Dodaj indeks” lub „Edytuj”, gdzie z powodzeniem odnalazłby opcję dalszej normalizacji/parsownia. Poniżej przykład parsowania w systemie logów przychodzących w formacie LEEF. Na poniższym rysunku widzimy, że „leefindeks”, który zawiera logi wstępnie sparsowane przez system, będzie dalej parsowany przez „Parser logów”, a następnie przez „parserprezentacj”. W systemie iS Sec istnieje możliwość praktycznie dowolnego zagnieżdżania parserów. (…)

WADA Wizualizacja w formie interaktywnej sieci została uznana za spełnioną (wymóg określony w pkt. 23 opisu przedmiotu zamówienia), natomiast w zakresie intuicyjności Zamawiający uznał spełnienie wymogu w wymiarze 15%, uzasadniając to w ten sposób, że mapa znajdująca się w podmenu posiada niezmienne wymiary 966x800 pikseli. Oznacza to tyle, że zaoferowane narzędzie, przy rozdzielczości ekranu FullHD, zajmuje zaledwie 37,3% dostępnej powierzchni ekran.

Modyfikacje polegające na schowaniu paska bocznego nie powiększyło obrazu. Zamawiający potwierdził powyższe poprzez wykorzystanie monitora o większej rozdzielczości – czynność nie zwiększyła obszaru roboczego mapy. Tym samym cała mapa pozostała niewielkiego rozmiaru, a przez to nieczytelna.

WYJAŚNIENIE Wykonawca również nie zgadza się z tą uwagą i uznaję ją za nieuzasadnioną. Po pierwsze w żadnym miejscu w dokumentach dotyczących opisu przedmiotu zamówienia nie było wzmianki na temat wizualizacji mapy, czy formy prezentacji różnych danych. Po drugie rozdzielczość mapy, o której jest mowa może być zmieniona wg. wytycznych zamawiającego w procesie konfiguracji systemu w ramach wdrożenia. Jest to rzecz na tyle prosta, że wykonawca jest wstanie w stosunkowo krótkim czasie skonfigurować system tak, żeby np. ta mapa była wyświetlana w osobnym oknie na całości ekranu. Po trzecie wykonawca nie uważa wcale, że zaimplementowana rozdzielczość omawianej mapy sprawia, że jest ona nieczytelna. Mapa jest interaktywna i pozwala użytkownikowi dobrowolnie przybliżać i oddalać jej elementy, dla przykładu przedstawiono poniżej zrzuty z ekranu. Pierwszy dotyczy wizualizacji mapy bez powiększenia/przybliżania na typowym monitorze 27”, drugi przedstawią tą samą mapę z przybliżeniem i trzeci z jeszcze większym przybliżeniem. Przybliżenie dowolnych elementów na mapie jest bardzo intuicyjne wystarczy „najechać” kursorem myszki na dowolny obszar/element mapy i użyć „scrolla” na mszyce. Tak jak to się robi w większości okien różnych systemów. Chwytając myszką dowolny obszar na mapie można też w dowolny sposób tę

mapę przesuwać i nawet wyrzucić ją całkowicie poza obszar roboczy. (…)

WADA W ramach wymogu określonego w pkt. 51 opisu przedmiotu zamówienia: a) Możliwość stosowania sparsowanych pól oraz ich wartości została uznana za spełnioną, natomiast w zakresie intuicyjności Zamawiający uznał spełnienie wymogu w wymiarze 12,50%, uzasadniając to w ten sposób, że względem wszystkich nazw pól użyto języka angielskiego, w systemie brak było opisów i wyjaśnienia działania poszczególnych funkcji, niemniej istniała możliwość wyszukiwania po nazwie. b) Możliwość stosowania atrybutów użytkowników z Active Directory została uznana za niespełnioną, bowiem Zamawiający nie odnalazł możliwości wyboru atrybutu użytkownika z AD, a instrukcja nie opisywała takiego przypadku. c) Możliwość stosowania atrybutów komputerów z Active Directory została uznana za niespełnioną, bowiem Zamawiający nie odnalazł możliwości wyboru atrybutu komputera z AD, a instrukcja nie opisywała takiego przypadku. d) Możliwość stosowania bazy wskaźników kompromitacji (IOC) została uznana za niespełnioną, bowiem Zamawiający nie odnalazł możliwości wyboru IoC, a instrukcja nie opisywała takiego przypadku. e) Możliwość stosowania informacji z elektronicznej dokumentacji została uznana za niespełnioną, bowiem Zamawiający nie odnalazł możliwości wybory informacji z elektronicznej dokumentacji, a instrukcja nie opisywała takiego przypadku. f) Możliwość stosowania anomalii w zachowaniu użytkowników (UBA) została uznana za niespełnioną, bowiem Zamawiający nie odnalazł możliwości wyboru anomalii w zachowaniu użytkowników, a instrukcja nie opisywała takiego przypadku. g) Możliwość stosowania mali w zachowaniu zasobów (EBA) została uznana za niespełnioną, bowiem Zamawiający nie odnalazł możliwości wyboru anomalii w zachowaniu zasobów, a instrukcja nie opisywała takiego przypadku. h) Możliwość stosowania podatności na zasobach została uznana za niespełnioną, bowiem Zamawiający nie odnalazł możliwości wyboru podatności na zasobach, a instrukcja nie opisywała takiego przypadku. i) Możliwość stosowania wyników analizy konfiguracji została uznana za niespełnioną, bowiem Zamawiający nie odnalazł możliwości wyboru wyników analizy konfiguracji, a instrukcja nie opisywała takiego przypadku.

WYJAŚNIENIE Wykonawca nie zgadza się ze wskazaną przez Zamawiającą wadą/usterką. W odniesieniu do powyższych podpunktów, również należy stwierdzić, że Zamawiający dokonał niesprawiedliwej oceny na podstawie braku wiedzy na temat systemu, technologii oraz ogólnej zasady działania tego typu systemów. Ponadto uwaga na temat języka angielskiego jest wręcz absurdalna. System iS Sec jest to system stworzony przez Polskiego producenta, który dbając o intuicyjność systemu używa głównie języka polskiego. Dodanie reguł korelacyjnych w systemie odbywa się poprzez wejście w Moduł wykrywania zagrożeń i wybranie zakładki reguły korelacyjne i naciśnięcie przycisku dodaj regułę. Poniżej przedstawiono formularz dodawanie reguły i jest on całkowicie stworzony w języku polskim. Jeśli chodzi o używanie sparsowanych pól w tych regułach, to zależy od użytkownika czy dane pole jest w języku angielskim, czy polskim. Ponadto w dziedzinie IT powszechnie stosuje się język angielski, i każdy wykształcony informatyk wie, czego dotyczy słowo „hostname”, „eventlog”, czy „winlog”. Generalnie zarówno logi jak i informacje dotyczące różnych pól pochodzących z systemów powszechnie stosowanych sprasowane są w systemie w taki sposób aby można było się domyślić z jakich systemów pochodzą. Dla przykładu z MS Office 365 (nie używamy MS Biuro 365) umieszczone w systemie są w indeksie „logso365”, a pola sparsowane posiadają przedrostek o365. W systemie istnieje możliwość ponownego parsowania dowolnych indeksów, gdzie użytkownik może zmienić nazwy tych pól na dowolne, ale informatyk/administrator, który nie wie co znajduje się np. pod polem, „winlog.process.pid”, nie powinien pracować przy tak trudnych zagadnieniach jak cyberbezpieczeństwo. (…) Podobna jest sytuacja dla Matrycy Mitre ATT&CK powszechnie stosowanej w systemach klasy SIEM. Jest ona pobierana i oficjalnych źródeł, z których wszyscy producenci na całym świecie korzystają. Taktyki i techniki działania cyberprzestępców są dodawane do tej właśnie matrycy i odpowiednio kategoryzowane. Sprawa jest prosta jest to po Angielsku ponieważ jest to język międzynarodowy, a w IT język ten jest powszechne stosowany i używany we wszelkich dokumentacjach technicznych. Dla przykładu na poniższym zrzucie z systemu przedstawiono wybrany z matrycy rodzaj ataku: „Brute Force” – każdy wykształcony informatyk słyszał o taki zagrożeniu. Następnie mamy listę zaimplementowanych reguł korelacyjny i tak dla przykładu: w tych regułach od razu widać czego dotyczą np. AW S to wiemy że to ten typ chmury, Azure inny itd. itp. jeśli mamy np. Multiple Logon Failure – to znaczy że reguła dotyczy wielokrotnie błędnego wpisania hasła. Informatyk/administrator musi znać te pojęcia, ponieważ większość systemów zagranicznych dostawców, logi wypisuje w języku angielskim, jeśli ktoś nie zna tych podstawowych pojęć nie będzie mógł skutecznie analizować logów z własnej infrastruktury sieciowej i własnych systemów. Większość naszych klientów miałoby wręcz problem z tym, że takie informacje spolszczyliśmy i oni teraz nie mogą się odnaleźć. (…) Ponadto system wyposażony jest w odrębny moduł UEBA, moduł wskaźników kompromitacji IoC, itd. i posiada wszystkie

funkcjonalności opisane w powyższych podpunktach, lecz niechęć sprawdzenia (przeklikania systemu) oraz brak wiedzy na jego temat oraz tego typu technologii i systemów uniemożliwił Zamawiającemu odnalezienie tych funkcjonalności. Tak samo jest z opisami reguł, które można znaleźć w listach referencyjnych pod linkiem umieszonym przy każdym zagrożeniu uwzględnionym w Matrycy Mitre ATT&CK.

WADA Wymóg określony w punkcie 72 opisu przedmiotu zamówienia został uznany za niespełniony, bowiem system nie umożliwiał automatycznego przypisywania zdarzeń do operatora.

WYJAŚNIENIE Wykonawca nie zgadza się z tą uwagą/usterką, System iS Sec posiada funkcjonalność automatycznego przypisywania zdarzeń do operatorów. Wykonawca opisał ten mechanizm Zamawiającemu i wskazał miejsca konfiguracji.

Nieznajomość systemu, technologii oraz działania tego typów systemów uniemożliwiła Zamawiającemu sprawdzenie jak działa ta funkcjonalność. Po pierwsze Zamawiający na próbce systemu otrzymał dostęp do jednego konta (operatora), do którego automatycznie system przypisał wszystkie zdarzenia/incydenty w celu przedstawienia funkcjonalności.

Ograniczenie w tym przypadku zdarzeń do innego operatora skutkowałoby brakiem dostępu do tych zdarzeń dla tego operatora (czyli konta które otrzymał Zamawiający). Skutkowałoby to stwierdzeniem przez Zamawiającego, że na przykład w systemie nie ma incydentów dotyczących podatności, co nie jest zgodne z prawdą. Automatyczne przypisanie to znaczy, że coś zostało zrobione bez ingerencji użytkownika. W jaki sposób Zamawiający sprawdził, że tej funkcji niema w systemie, skoro wykonała się ona automatycznie, to jest nadal zagadką. Właśnie sam fakt zalogowania się do systemu jako operator wskazywał Zamawiającemu, że jeśli ma dostęp to automatycznie zostały do niego przypisane wszystkie incydenty. W systemie iS Sec znajduje się kilka możliwości przypisujących konkretne zdarzenia do konkretnych osób/opertorów. Można to robić na kilka sposobów, a jeden z nich przedstawiono Zamawiającemu. Poprzez np. uprawnienia, operatorowi można przyznać dostęp zarówno do sekcji/funkcjonalności jak i grup zasobów. Jeśli podzielimy dostępy zarówno do sekcji systemu jak i zasobów na poszczególnych operatorów, to możemy zapewnić automatyczne przypisanie wszystkich zdarzeń dotyczących podatności CVE na grupie urządzeń SERW ERY do konkretnej osoby, która dostaje takie uprawnienia. Mało tego można te uprawnienia w systemie mieszać i użytkownicy o tych samych uprawnieniach dostaną przypisane do siebie te same zdarzenia. W tym momencie użytkownik może ręcznie przypisać operatora i wskazać tą osobę lub przypisać siebie, żeby np. drugi użytkownik wiedział, ze ktoś już zajmuje się tym zdarzeniem. Kolejna opcja to przypisywanie powiadomień do konkretnych operatorów poprzez konfigurację SLA. System wyposażony jest w rozbudowany moduł powiadomień o incydentach i pozwala na tworzenie własnych reguł, w których można ustawić np. zgłoś powiadomienie OPERATOROW I A jeśli jest Incydent jest krytyczny.

A jeśli incydent ma priorytet niski to zgłoś OPERATOROWI B. Poniżej przedstawiono zrzuty ekranu z systemu.

Ponadto istnieje jeszcze możliwość z skorzystania z Modułu SOAR, w którym wykrycie konkretnego np. typu zagrożenia można przypisać do konkretnych osób/operatorów i ich powiadomić o tym incydencie.

WADA Możliwość manualnego grupowania zdarzeń została uznana za spełnioną (wymóg określony w pkt. 75 opisu przedmiotu zamówienia), natomiast Zamawiający uznał rozwiązanie jako nieintuicyjne (0%), uzasadniając to w ten sposób, że wymogiem było przepisanie numeru zdarzenia, który ma łącznie 32 cyfry w formacie heksadecymalnym połączone w pięć grup. System nie posiada możliwości wyszukania po części numeru. Ponadto sama nazwa funkcji nie wskazuje w żaden sposób, że służy do grupowania zdarzeń.

WYJAŚNIENIE Wykonawca nie zgadza się z tą usterką oraz opinią na temat intuicyjności. Sprawę intuicyjności omówiliśmy już powyżej i nasze stanowisko jest takie, że została ona wykonana nie rzetelnie. Ponadto w punkcie 75 OPZ nie ma opisu w jaki sposób ma się to odbywać. W naszej ocenie aby zgrupować np. dwa zdarzenia należy do jednego zdarzenia przypisać drugie zdarzenie. Dlatego w systemie umieszczono przycisk o nazwie „przypisz zdarzenie”. Po przypisaniu zdarzenia w systemie widzimy zgrupowane zdarzenia. Omawianą sytuacje przedstawiają poniższe zrzuty ekranu. (…) Jeśli Zamawiającemu nie przypadła do gustu nazwa tej funkcji to na etapie wdrożenia Wykonawca może skonfigurować system tak aby była inna, choć w naszej ocenia przypisanie zdarzenia jest bardziej intuicyjne.

WADA W ramach wymogu określonego w pkt. 87 opisu przedmiotu zamówienia: a) Możliwość filtrowania po wyliczonym priorytecie podatności została uznana za niespełnioną, bowiem nie została przewidziana w systemie ani przekazanej instrukcji. b) Możliwość filtrowania po ważności zasobu na którym została wykryta została uznana za niespełnioną, bowiem nie została przewidziana w systemie ani przekazanej instrukcji. c) Możliwość filtrowania po adresie IP tego systemu została uznana za niespełnioną, bowiem nie została przewidziana w systemie ani przekazanej instrukcji. d) Możliwość filtrowania po parametrach SLA związanych z tym statusem została uznana za niespełnioną, bowiem nie

została przewidziana w systemie ani przekazanej instrukcji. e) Możliwość filtrowania po przetwarzanych na zasobach informacji, np.: lista podatności dotycząca tylko systemów przetwarzających dane osobowe została uznana za niespełnioną, bowiem nie została przewidziana w systemie ani przekazanej instrukcji. f) Możliwość filtrowania po parametrach CVSS, np.: lista podatności których „Access Complexity (AC)” = „low” oraz „Access Vector (AV) = „Network”, została uznana za niespełnioną, bowiem nie została przewidziana w systemie ani przekazanej instrukcji.

WYJAŚNIENIE Wykonawca nie zgadza się z tą uwagą/wadą systemu. Zamawiający dostał do dyspozycji próbkę systemu oraz podstawowy scenariusz testowania. Niestety nie do końca wykonał te proste polecenia albo z jakiś niewyjaśnionych przyczyn nie widział zaawansowanej wyszukiwarki podatności CVE.

„ODP. W systemie ISSec – każda obsługiwana podatność może być wyszukiwana wg. parametrów wypisanych powyżej. System wyposażony jest w zaawansowaną wyszukiwarkę umożliwiającą również wyszukiwanie po kategorii oraz podanej frazy.

Scenariusz testowania:

1. Zaloguj się do Systemu ISSec z przeglądarki internetowej.
2. Wybierz i przeglądnij Moduł SLA 3.Wybierz zakładkę „Podatności” 4.Wybierz incydent i naciśnij przycis „…” (akcje) i wybierz wyświetl CVE 5.Sprawdź możliwości filtrowania wyników” Konsekwentne wykonanie tego scenariusza i zaznajomienie się z tak prostym opisem, powinno doświadczonego użytkownika tego typu systemów doprowadzić do zupełnie innych wniosków. System wyposażony jest w intuicyjną wyszukiwarkę znajdującą się po prawej stronie podpisaną „wyszukaj”, która wyszukuje po podanej frazie, czyli również po IP. Ponadto z lewej strony moduł analizy podatności wyposażony jest w różne filtry wymagane w tym punkcie.

Zamawiający nie wykonał piątego punktu z tego scenariusza. System wyposażony jest również w interaktywne wykresy umożliwiające filtrowanie po priorytetach. Kliknięcie w dany „kolor” priorytetu powoduje odfiltrowanie podatności.

Poniżej przedstawiono z rzuty ekranu z systemu. (…)

WADA W ramach wymogu określonego w pkt. 122 opisu przedmiotu zamówienia: a) Aplikacja typu agent została uznana za spełnioną, natomiast Zamawiający uznał rozwiązanie jako nieintuicyjne (0%), uzasadniając to w ten sposób, że opis agentów przedstawiony przez Wykonawcę okazał niezrozumiały: w playbookach SOAR nie brak było możliwości zarządzania, instalacji czy zbierania logów z agentów. Ponadto w systemie testowym nie stwierdzono śladów wykorzystania aplikacji typu agent. b) Brak możliwość centralnego zarządzania, a dostarczona instrukcja milczy na temat dostępności. c) Brak możliwość aktualizacji z głównej konsoli zarządzającej, a dostarczona instrukcja milczy na temat dostępności. d) Brak możliwość zbierania logów z plików tekstowych na urządzeniach z zainstalowanym systemem z rodziny Windows, a dostarczona instrukcja milczy na temat dostępności. e) Brak możliwość zbierania logów dotyczących zdarzeń rodzajów innych niż: Security, System, Application, a dostarczona instrukcja milczy na temat dostępności. f) Brak możliwość monitorowania integralności plików, a dostarczona instrukcja milczy na temat dostępności. g) Brak możliwość monitorowania rejestru systemowego, a dostarczona instrukcja milczy na temat dostępności. h) Brak możliwość monitorowania urządzeń zewnętrznych (removable devices), a dostarczona instrukcja milczy na temat dostępności. i) Odnośnie wymogu komunikowania się agenta w sposób zaszyfrowany z wykorzystaniem protokołu HTTPS Wykonawca oświadczył, że dane są szyfrowane, niemniej nie przedstawił żadnych dowodów. W systemie nie stwierdzono żadnych dedykowanych ustawień, brak był również przechwycenia pakietów sieciowych w celu analizy. j) Brak możliwość monitorowania stanu agentów w konsoli zarządzającej systemu, a dostarczona instrukcja milczy na temat dostępności. k) Brak możliwość przygotowania różnych zestawów konfiguracji agenta, a dostarczona instrukcja milczy na temat dostępności.

WYJAŚNIENIE Wykonawca nie zgadza się z tą opinią i temat oceny intuicyjności był już poruszany wcześniej. Zamawiający otrzymał od Wykonawcy wyczerpującą odpowiedź i tylko nieznajomość tego typu systemów może doprowadzić do tak skrajnie niesprawiedliwej oceny.

Przekazana odpowiedź:

„ODP. System ISSec może gromadzić logi agentowo i bezagnetowo. System posiada agentów zarówno na Windows jak i na systemy Linux, połączenia agentowe są szyfrowane. Agenci automatycznie zbierają informacje na temat oprogramowania oraz zasobów. Centralne zarządzanie agentami jest możliwe w formie uproszczonej tj. poprzez sprawdzenie ich statusów bądź możliwość ich usuwania. Agenci mają możliwość wykonywania dowolnych skryptów czy reakcji na zgłaszane incydenty takie jak blokada procesu stworzenie dump blokowanie ruchu sieciowego i wiele innych.

Instalowanie agentów może odbywać się ręcznie bądź na systemach Windows przy wykorzystaniu GPO. Wykonawca zapewnia dostęp do plików konfiguracyjnych agentów instrukcji instalacji oraz instrukcji zmiany wybranych parametrów.

Wykonawca dostarcza również różne zestawy agentów na Systemy Windows w postaci paczek instalacyjnych MSI.

Scenariusz testowania:

1. Zaloguj się do Systemu ISSec z przeglądarki internetowej.
2. Wybierz moduł SOAR 3.Wybierz zakładkę „Playbooki” 4.Wybierz dodaj playbook 5.Rozwiń zakładkę Skrypty „ W pierwszej kolejności trzeba rozumieć czym jest agent i gdzie on jest instalowany. Agentów nie instaluje się w konsoli Systemu iS Sec, tylko na tkzw. końcówka, czyli urządzeniach końcowych takich jak serwery fizyczne, serwery virtualne desktopy pracowników, laptopy itp. , i podczas ich instalacji agencji rejestrowani są w systemie iS Sec. Wykonawca założył, że sprawdzający tę funkcjonalność jest osoba związaną z środowiskiem IT i wie jak działają systemy agentowe i również wie, że bez agenta zainstalowanego na końcówce nie da się wykonać zdalnie skryptu bez wcześniejszego nawiązania z tym komputerem połączenia np. ssh, rdp itp. Co do szyfrowania , to już sama próbka systemu była udostępniona Zamawiającemu po HTTPS (czyli z użyciem certyfikatu SSL), co może sugerować, że całe rozwiązanie jest szyfrowane. Stan agentów również jest dostępny w zakładce Agneci w Module inwentaryzacji i gdyby wykonawca bez uprzedzeń zapoznał się z próbką nie mógł by tej opcji nie zauważyć. (…) Co do dowodów na temat szyfrowania połączeń pomiędzy agentami, a kolektorami logów to Wykonawca bez problemu mógłby je przedstawić, gdyby znał formę oceny intuicyjności na etapie ogłoszenia przetargu.

WADA W ramach wymogu określonego w pkt. 125 opisu przedmiotu zamówienia: a) Brak możliwość integracji z Threat Inteligence Feed: Zamawiający nie odnalazł opcji umożliwiającej włączenie integracji. Funkcja określona przez Zamawiającego zawierała wyłącznie listę 10 plików zablokowanych. System nie posiadał możliwości integracji z jakimkolwiek systemem Threat Intelligence. b) System nie spełniał wymogi dotyczącego zintegrowanej bazy zagrożeń.

Udostępniona baza danych zawierała tylko 10 plików, spośród których 5 w nazwie miało słowo test lub testowy. Dwa pliki to litery leżące bezpośrednio w swoim towarzystwie na klawiaturze, a pozostałe trzy pliki mają tylko liczbę heksadecymalną zamiast nazwy. Hash trzech ostatnich jest identyczny. Udostępniona baza nie zasługiwała na miano bazy danych, lecz były to przykładowe wpisy do bazy danych. W zakresie zadeklarowanej funkcjonalności opcjonalnej nr 2,

WYJAŚNIENIE Zamawiający całkowicie nie zgadza się z opinia w tym punkcie. Zamawiający chyba w ogóle nie sprawdził co znajduje się w „Module Threat Intelligence”. W tym przypadku dla Wykonawcy sprawa była tak oczywista, że Zamawiający otrzymał taką odpowiedź w raz ze scenariuszem do próbki:

„ODP. System jest zintegrowany z zewnętrznymi bazami danych Threat Inteligence.

Scenariusz testowania:

1. Zaloguj się do Systemu ISSec z przeglądarki internetowej.
2. Wybierz z menu Moduł Threat Inteliligence 3.Przeglądnij baze wiedzy z różnych kategorii danych 4.Sprawdź listę blokowanych plików” Ciężko jest się odnieść do tego zarzutu, Zamawiający w ocenie Wykonawcy nie wykonał scenariusza punkt 2 i 3 wskazuje dokładnie na zintegrowane bazy wiedzy na temat wskaźników kompromitacji. Ponownie Wykonawca uważa, że Zamawiający z przyczyn braku wiedzy na temat tego typu rozwiązań oraz ogólnej niechęci, nieprawidłowo ocenił funkcjonalności systemu iS Sec. (…) Co do punktów 10, 11, 12 , 13, 14, 15 dotyczących zadeklarowanej funkcjonalności opcjonalnej, również Wykonawca nie zgadza się z ustaleniami Zamawiającego. Wykonawca przedstawił zamawiającemu scenariusz, którego rzetelne przejście wskazywałoby na zupełnie inną, sprawiedliwą ocenę. System iS Sec jest rozbudowanym system posiadającym te wszystkie funkcjonalności. Wykonawca nie wie dlaczego tak został oceniony, ale podejrzewa albo znaczną niewiedzę oceniającego, albo celowe działanie. Poniżej przedstawiamy kilka zrzutów ekranu z systemu: (…) W odniesieniu jeszcze do punktu 40 OPZ:
3. System musi zawierać mechanizm integracji ze skanerami podatności co najmniej trzech producentów. W ramach integracji system musi mieć możliwość uruchamiania skanowania podatności, importowania jego wyników

zawierających listę podatności i ich atrybuty oraz możliwość kasowania ze skanera zaimportowanych wcześniej skanów.

Wszystkie powyższe operacje muszą być konfigurowalne z poziomu graficznego interfejsu systemu.

Wykonawca przesłał Zamawiającemu taką odp:.

„System ISSec wyposażony jest we własny Moduł analizy podatności automatycznie sprawdzający wszystkie urządzenia oraz ich oprogramowanie zinwentaryzowane w systemie. Synchronizacje z bazami CVE odbywają się cyklicznie bez ingerencji użytkownika. Ponadto użytkownik z poziomu systemu może oznaczyć podatność jako rozwiązaną (zaakceptowaną). Po aktualizacji lub usunięciu oprogramowania wykryta wcześniej w systemie podatność zostanie automatycznie usunięta. Ponadto system ISSec umożliwia integracje z innymi skanerami podatności udostępniającymi API takimi jak np. Nessus 7 w powyżej przedstawionym zakresie. „ Zostało to również źle ocenione przez Zamawiającego, ponieważ nie znalazł „możliwości konfiguracji integracji przez API”. Wykonawca oświadcza, że system iS Sec, którego jest producentem ma na tyle otwartą strukturę, że integruje się z każdym dostępnym na rynku skanerem podatności, który na taką integracje pozwala. W ramach wdrożenia systemu Wykonawca konfiguruje system tak, żeby był w pełni zintegrowany ze skanerem podatności, który posiada.

Przedstawienie np. takiej integracji z trzema komercyjnymi skanerami podatności (innych producentów), wiązałoby się z zakupem tych licencji przez wykonawcę. Licencja dla wspomnianego w OPZ oprogramowania Nessus jest kosztem rzędu 100 tyś zł. rocznie. Wykonawca podejrzewa, że konkurencyjne firmy, specjalnie dla tego postępowania, nie zakupiły tej licencji i również nie przedstawiły wyników tej integracji. Wykonawca widział wyniki oceny wg. tej samej ankiety dla firmy, która została wyłoniona. Zamawiający w tej ankiecie dopuścił integrację (konfigurację integracji) z tymi skanerami pomimo tego, że trzeba było je wykonać z poziomu „powershell”, czyli poza system Zamawianym. Czyli Zamawiający dla tej drugiej firmy dokonał oceny pozytywnej dla zewnętrznego mechanizmu konfigurującego omawiane integrację, a dla Odwołującego nie. Integracja poprzez API jest również zewnętrznym mechanizmem integrującym systemy, z tą różnicą, że jest to element systemu iS Sec, natomiast „powershell” jest elementem systemu Windows, który nie był przedmiotem zamówienia. Jak widać, system oferowany przez Odwołującego nie jest niezgodny z warunkami zamówienia w zakresie opisu przedmiotu zamówienia, To Zamawiający dokonał błędnej oceny dostarczonej próbki. Nie jest dla Zamawiającego żadnym usprawiedliwieniem to, że na spotkaniu w dniu 2 grudnia 2025 r. Odwołujący nie był w stanie zaprezentować powyższych wymagań, gdyż to Zamawiający nie informował o takiej potrzebie. Należy podkreślić, że Odwołujący jest producentem oferowanego systemu. Wyjaśnienia składane przez samego Odwołującego są oświadczeniami podmiotu najbardziej zaznajomionego z produktem, zarówno co do rozwiązań znanych, jak i tych utajnionych dla osób trzecich. Gdyby Zamawiający wyraził zgodę na dodatkowe spotkanie (co nie było zabronione), uzyskałby wszelkie niezbędne informacje pozwalające na uznanie, że oferowany system spełnia jego wymagania. Jak już wskazano, niezgodność systemu z opisem przedmiotu zamówienia zachodzi, gdy system nie posiada wymaganych funkcjonalności. Sytuacja taka nie zachodzi w niniejszym postępowaniu.

Zarzut nr 2

Zgodnie z art. 226 ust. 1 pkt 8) ustawy Pzp, Zamawiający odrzuca ofertę, jeżeli zawiera rażąco niską cenę lub koszt w stosunku do przedmiotu zamówienia.

Ustawa Prawo zamówień publicznych nie zawiera definicji rażąco niskiej ceny. Nie została ona również wskazana w Dyrektywach ani wypracowana przez Trybunał Sprawiedliwości Unii Europejskiej, jednak przez lata funkcjonowania regulacji badanie takiej ceny w kontekście weryfikacji ofert wykonawców, ukształtowane zostały kluczowe elementy tego pojęcia: − o cenie rażąco niskiej można mówić wówczas, gdy oczywiste jest, że przy zachowaniu reguł rynkowych wykonanie umowy przez wykonawcę byłoby dla niego nieopłacalne (wyrok KIO z dnia 28 marca 2013 r., KIO 592/13), − za ofertę z rażąco niską ceną można uznać ofertę z ceną niewiarygodną, nierealistyczną w porównaniu do cen rynkowych podobnych zamówień. Oznacza to cenę znacząco odbiegającą od cen przyjętych, wskazującą na fakt realizacji zamówienia poniżej kosztów wytworzenia usługi, dostawy, roboty budowlanej – cena dumpingowa (opinia prawna Urzędu Zamówień Publicznych), − cena rażąco niska jest ceną nierealną, niepozwalającą na realizację zamówienia z należytą starannością, wskazującą na zamiar realizacji zamówienia poniżej kosztów własnych wykonawcy, nie pozwalającą na wygenerowanie przez niego zysku (wyrok KIO z dnia 17 czerwca 2019 r., KIO 992/19), − cena rażąco niska jest to taka cena, która ewidentnie, w sposób obiektywnie i powszechnie widoczny jest nierealna (wyrok KIO z dnia 17 kwietnia 2023 r., KIO 835/23).

Odrzucając ofertę Odwołującego Zamawiający posłużył się argumentami domniemanymi, nie wskazując przy tym faktycznych wad złożonych wyjaśnień. Zamawiający kwestionuje wyjaśnienia dotyczące braku kosztów ukrytych, w tym związanych z zakupem akceleratora podnosząc, że „wedle jego wiedzy” takie koszty Odwołujący powinien ponieść.

Odwołujący jest mocno zdziwiony, że Zamawiający wyciąga takie wnioski, nie znając architektury, systemu iS Sec. Sam zresztą w wezwaniu wskazał, że są to koszty „ewentualne”. Nie znając technologii oraz nie znając zasad działania

metod uczenia maszynowego ML oraz sztucznej inteligencji AI. Wszystkie te wyliczenia i sugestie, są całkowicie bezpodstawne. Modele uczenia maszynowego stosowane w systemie ISSec to modele dotyczące wykrywania anomalii UEBA, które, uczą się na danych historycznych i douczają w trakcie, brak znajomości tych metod oraz zasady działania tych algorytmów skłania Zamawiającego do wyciągania tak absurdalnych wniosków. Oczywiście każda metoda ML obciąża CPU może obciążać GPU oraz nawet NPU. Ale metody ML stosowane w systemie iS Sec są tak dobrane, że technicznego punktu widzenia implementuje się je na Virtualnych maszynach które nie posiadają GPU i działają sprawnie. Model w trakcie uczenia się, douczania wymaga większej ilości zasobów natomiast sprawdzanie anomalii wykonywane jest paczkami, do maszyny z ML trafiają już tylko dan po preprocessingu i tylko wybrane cechy biorące udział w analizie. Zamawiający nie zna tych metod, nie zapytał jak działają, ale wyciągną wnioski że się nie da.

Wykonawca natomiast wdrożył już kilkadziesiąt razy system iS Sec i nigdy klienci nie kupowali „akceleratorów” . Co do LLM, to również Zamawiający wykazał się całkowitym brakiem wiedzy na temat architektury realizacji itd. itp. Zazwyczaj modeli LLM nie implementuje się u odbiorców, tylko albo stawia się je na własnych zasobach, albo korzysta z rozwiązań chmurowych, albo po prostu korzysta się z API dostępnych modeli LLM. Takich jak Czat GPT, czy GEMINI, gdzie opłaty to pewnej ilości zapytań są zerowe bądź minimalne. Ciekawym argumentem Zamawiającego jest zakwestionowanie wyceny wsparcia technicznego w okresie dodatkowych 12 miesięcy. Wedle oceny Zamawiającego jest to niemożliwe do zrealizowania w cenie 10 000 zł. Jednocześnie Zamawiający nie znajduje podstaw do kwestionowania wyceny przyjętej przez TK-MED Sp. z o.o., która wynosi 1 000,00 zł (…).Odnosząc to do argumentacji Zamawiającego, który uważa, że 40 godzin w skali roku to zbyt mała ilość dla obsługi zamówienia, to nawet taka ilość godzin w odniesieniu do oferty TKMED. Sp. z o.o. sugeruje godzinę pracy specjalisty na poziomie 25 zł, a więc poniżej płacy minimalnej. Ale tu już Zamawiający wątpliwości nie ma, co tylko potwierdza, że ocena Zamawiającego toczy się wedle podwójnych standardów faworyzujących jedną stronę. Odnosząc się jednak do argumentacji Zamawiającego, przenoszenie wynagrodzenia specjalisty, obliczonego w odniesieniu do prac konfiguracyjnych indywidualnie go angażujących, do wsparcia technicznego, które realizowane jest na zupełnie innych zasadach, w ramach ogólnego wsparcia klientów Odwołującego jest całkowicie chybione i ponownie jest działaniem pod z góry założoną tezę. Całość argumentacji Zamawiającego w przedmiocie rzekomo rażąco niskiej ceny w ogóle nie podważa realności wyceny systemu Odwołującego, a stanowi jedynie pustą polemikę. Odwołujący złożył obszerne wyjaśnienia ze wskazaniem wszystkich istotnych kosztów, które w pełni potwierdzają, że zaoferowana cena pozwala na wykonanie zamówienia zgodnie z wymaganiami Zamawiającego.

Zarzut nr 3

Zgodnie z art. 226 ust. 1 pkt 5) ustawy Pzp, Zamawiający odrzuca ofertę Wykonawcy, jeżeli jej treść jest niezgodna z warunkami zamówienia. Warunki zamówienia należy rozumieć zgodnie z definicją wyrażoną w art. 7 pkt 29 Pzp, która stanowi, że poprzez warunki zamówienia należy rozumieć warunki, które dotyczą zamówienia lub postępowania o udzielenie zamówienia, wynikające w szczególności z opisu przedmiotu zamówienia, wymagań związanych z realizacją zamówienia, kryteriów oceny ofert, wymagań proceduralnych lub projektowanych postanowień umowy w sprawie zamówienia publicznego. Jak już wskazano we wcześniejszej części odwołania, Opis przedmiotu zamówienia jednoznacznie wskazuje, że System musi spełniać następujące wymagania: − Proces normalizacji musi wspierać następujące typy składni: CEF, LEEF, URI, SYSLOG (zgodny z RFC 3164) i automatycznie tworzyć na ich podstawie pola i ich wartości zgodne z zasadami określonymi przez te składnie.

Parsowanie powyższych składni nie może być realizowane za pomocą wyrażeń regularnych. − System musi być wyposażony w graficzny interfejs do tworzenia dodatkowych reguł normalizacji (parserów) dla zdarzeń z niestandardowych źródeł danych, w oparciu o następujące składnie: CEF, LEEF, URI, XML, JSON, SYSLOG, REGEX. System musi umożliwiać zastosowanie wszystkich typów składni dla pojedynczego zdarzenia, przykładowo pole „msg” znormalizowane automatycznie według standardu CEF powinno mieć możliwość dalszej normalizacji np.: zgodnej z URI lub REGEX.

Jak wykazał Odwołujący, system oferowany przez TK-MED Sp. z o.o. nie posiada powyższych funkcjonalności w zakresie składni URI, co sam stwierdził Zamawiający podczas dokonanej oceny próbki. Jednoznacznie potwierdza to, że oferta TK-MED Sp. z o.o. jest niezgodna z warunkami zamówienia w zakresie, w jakim warunki te wynikają z opisu przedmiotu zamówienia. Tym samym, oferta ta powinna zostać odrzucona, a nie wybrana jako najkorzystniejsza jak uczynił to Zamawiający. Działanie Zamawiającego narusza również art. 16 pkt 1 i 2 ustawy Pzp, zgodnie z którymi postępowanie przeprowadza się z zachowaniem uczciwej konkurencji i równego traktowania wykonawców jak również w sposób przejrzysty.

Zarzut nr 4

Zgodnie z art. 239 ust. 1 i 2 ustawy Pzp, Zamawiający wybiera najkorzystniejszą ofertę na podstawie kryteriów oceny ofert określonych w dokumentach zamówienia. Najkorzystniejsza oferta to oferta przedstawiająca najkorzystniejszy stosunek jakości do ceny lub kosztu lub oferta z najniższą ceną lub kosztem. Potwierdzenie zarzutu 3 prowadzi wprost to uznania, że wybór oferty obarczony jest wadą. Oferta podlegająca odrzuceniu nie może być ofertą wybraną.

Zarzut nr 5 i 6 (zarzut ewentualny):

Zgodnie z art. 255 pkt 6) Pzp Zamawiający unieważnia postępowanie o udzielenie zamówienia publicznego, jeżeli postępowanie obarczone jest niemożliwą do usunięcia wadą uniemożliwiającą zawarcie niepodlegającej unieważnieniu umowy w sprawie zamówienia publicznego. Zamawiający ma obowiązek unieważnienia postępowania o udzielenie zamówienia ze względu na jego wadę, o ile spełnia ona dwa kryteria. Musi to być wada niemożliwa do usunięcia po jej stwierdzeniu ze względu na stan zaawansowania postępowania. Ponadto chodzi o nieprawidłowości rzutujące bezpośrednio na zawarcie niepodlegającej unieważnieniu umowy w sprawie zamówienia publicznego. Celem postępowania jest bowiem zawarcie wyłącznie w pełni skutecznej umowy w sprawie zamówienia publicznego. Na przeszkodzie stają zatem wyłącznie nieusuwalne wady proceduralne (nie podlegające konwalidacji), obciążające postępowanie w sposób nieodwracalny. Mogą to być zarówno nieprawidłowe działania, jak i zaniechania zamawiającego.

W ocenie Odwołującego w postępowaniu Zamawiający dokonał tak dalece nieprawidłowego opisu przedmiotu zamówienia w zakresie procedury oceny próbki systemu, że niemożliwe jest na obecnym etapie postepowania: − zagwarantowanierównego traktowania wykonawców i uczciwej konkurencji, − dokonanie obiektywnej oceny oferowanych systemów.

Powyższe narusza art. 99 ust. 1 i 4 ustawy Pzp.

Zgodnie z art. 457 ust. 1 pkt 1) ustawy Pzp, Umowa podlega unieważnieniu, jeżeli zamawiający z naruszeniem ustawy udzielił zamówienia, zawarł umowę ramową lub ustanowił dynamiczny system zakupów bez uprzedniego zamieszczenia w Biuletynie Zamówień Publicznych albo przekazania Urzędowi Publikacji Unii Europejskiej ogłoszenia wszczynającego postępowanie lub bez wymaganego ogłoszenia zmieniającego ogłoszenie wszczynające postępowanie, jeżeli zmiany miały znaczenie dla sporządzenia wniosków o dopuszczenie do udziału w postępowaniu albo ofert. Zgodnie z wyrokiem KIO 310/23, nie można przyjąć, że „z art. 457 ust. 1 pkt 1 Prawa zamówień publicznych wynika wyłącznie przesłanka unieważnienia umowy, związana z nieprawidłowościami w obowiązkowych ogłoszeniach w publikatorach. Każde naruszenie związane z ogłoszeniami jest równocześnie "naruszeniem ustawy". Trzeba zatem przyjąć, że ustawodawca przewidział dwie podstawy unieważnienia, do których odwołuje się w art. 457 ust. 1 pkt Prawa zamówień publicznych, tj: "do zawarcia umowy z naruszeniem Pzp oraz do zaniechania obowiązków ogłoszeniowych" (tak: Prawo zamówień komentarz, red. Hubert Nowak i Marek Winiarz, Urząd Zamówień Publicznych, Warszawa 2021). Rzeczywiście przepis sformułowany jest mało przejrzyście, ale trudno byłoby zaakceptować, dlaczego ustawodawca, jako prowadzącą do nieważności umowy, miałby przyjąć jedynie przesłankę związaną z ogłoszeniami, mającymi znaczenie dla sporządzenia ofert, a pominął inne naruszenia przepisów, które takie znaczenia również mają. Dlatego zasadnym jest przyjęcie, że intencją ustawodawcy było wprowadzenie przesłanki nieważności umowy zawartej z naruszeniem przepisów Prawa zamówień publicznych, jednak nie każdym, tylko kwalifikowanym - takim, które miało znaczenie dla przygotowania ofert, a więc wpłynęło na wynik postępowania. Generalnie rzecz biorąc przesłanki unieważnienia postępowania mają charakter wysoce sankcyjny i powinny być interpretowane możliwie wąsko, jednak jakakolwiek interpretacja musi uwzględniać sens i cel przepisu. Dlatego ostatecznie, biorąc pod uwagę powyższe rozważania, Izba doszła do wniosku, że udzielenie zamówienia z naruszeniem przepisów ustawy, tego rodzaju, że miało wpływ na sporządzenie ofert i wynik postępowania, mieści się w normie opisanej w art. 457 ust. 1 pkt 1 Prawa zamówień publicznych.” Również w wyroku KIO 169/22 Izba uznała, że „konstrukcja przepisu odsyła wprost do art. 457 ust. 1 ustawy Pzp, w którym wymienione są wszystkie przypadki naruszenia Pzp powodujące konieczność unieważnienia umowy. Odesłania nie można jednak ograniczać wyłącznie do przywołanego przepisu, który zawiera zamknięty i bardzo ograniczony katalog sytuacji powodujących unieważnienie umowy. Taka interpretacja skutkowałaby tym, iż wystąpienie innych wad w postępowaniu nie mogłoby być powodem jego unieważnienia. Taka wykładnia prowadziłaby do błędnego zdaniem Izby wniosku, że nawet wystąpienie wady w sposób oczywisty wypaczającej wynik postępowania nie daje zamawiającemu prawa do unieważnienia postępowania, podczas gdy zawarcie umowy będzie rodzić skutki w postaci dochodzenia jej nieważności lub unieważnienia przez innych wykonawców na podstawie odrębnych przepisów, czego w przypadku wad innych niż określone art. 457 ust. 1 pkt 1 Pzp nie zabrania. Izba zwraca uwagę, że w przepisach ustawy Pzp istnieje możliwość uznania umowy za nieważną na podstawie art. 457 ust. 5 ustawy Pzp który stanowi, że przepis ust. 1 nie wyłącza możliwości żądania unieważnienia umowy na podstawie art. 705 ustawy z dnia 23 kwietnia 1964 r. - Kodeks cywilny.

Dyspozycja art. 705 k.c. znajdzie zastosowanie do umów w sprawie zamówień publicznych zawartych w wyniku jakiegokolwiek postępowania otwartego (poprzedzonego ogłoszeniem) prowadzonego w oparciu o przepisy Pzp.

Możliwość żądania unieważnienia umowy w sprawie zamówienia publicznego w oparciu o art. 705 k.c. jest niezależna od podstaw i ograniczeń unieważnienia na podstawie przepisów Pzp.”

Powyższe poglądy Izby zasługują w pełni na uwzględnienie. Inny wniosek prowadziłby do uznania, że po terminie składania ofert Zamawiający nie ma prawa unieważnić postępowania w związku z wadami proceduralnymi, a więc musi udzielić zamówienia Wykonawcy wybranemu w takim wadliwym postępowaniu, chyba że zajdą inne przesłanki unieważnienia.

Nie budzi wątpliwości, że za wadę postępowania uzasadniającą jego unieważnienie może być uznana wada wynikająca z opisu przedmiotu zamówienia. W orzecznictwie Izby wykształcił się pogląd, że niejasność lub nieprecyzyjność opisu przedmiotu zamówienia może stanowić podstawę unieważnienia postępowania. Pogląd ten został wyrażony m.in. w wyrokach KIO: z 25 września 2017 r. (KIO 1869/17), z 4 sierpnia 2017 r. (KIO 1507/17), z 11 czerwca 2021 r. (KIO 1343/21) oraz z 18 lipca 2022 r. (KIO 1623/22). Przy czym niejednoznaczność opisu musi być na tyle znacząca, że porównanie złożonych ofert nie jest możliwe (zob. wyroki Izby z 24 września 2019 r., KIO 1747/19, oraz z 12 listopada 2019 r., KIO 2176/19). O braku jednoznaczności opisu przedmiotu zamówienia nie można natomiast mówić w sytuacji, gdy zamawiający konstruuje opis, który nie odzwierciedla jego rzeczywistych potrzeb (zob. wyrok KIO z 12 sierpnia 2021 r., KIO 2309/21). Jak wykazano już w odwołaniu, Zamawiający dokonał takiego opisu przedmiotu zamówienia, który:

1. jednocześnie wymusza istnienie określnych funkcjonalności systemu („system musi posiadać”) i dopuszcza sytuację, w której jedna lub więcej tych funkcjonalności jednak nie jest spełniona nie powodując negatywnej oceny oferowanego produktu, a ocena w tym zakresie ma charakter następczy – po złożeniu ofert; 2)przyznaje Zamawiającemu prawo oceny w oparciu o subiektywne odczucia w zakresie, którego nie opisał, a który mógł określić przed terminem składania ofert.

Należy zauważyć, że „Intuicyjność” ma w ocenie próbki wagę 25 %. Uwzględniając przy tym zapis, że każdy punkt musi osiągnąć minimum 90 %, jest to prosty sposób eliminowania oprogramowania bez logicznego uzasadnienia i w sposób nieproporcjonalny, co zresztą potwierdza badanie Zamawiającego.

Zamawiający jako rozwiązanie nieintuicyjne wskazuje m.in.: − Wymagane jest przepisanie numeru zdarzenia który ma łącznie 32 cyfry w formacie heksadecymalnym połączone w pięć grup. Nie ma możliwości wyszukania po części numeru. Sama nazwa funkcji nie wskazuje na to że służy do grupowania zdarzeń; − Opis zawiera tylko i wyłącznie ręczne przypisywanie zdarzeń, funkcja automatycznego przypisywania zdarzeń nie została odnaleziona; − Wszystkie nazwy po angielsku, brakuje opisów i wyjaśnienia co dana funkcja robi.

Istnieje możliwość wyszukiwania po nazwie.

Każdy z tych elementów mógł być opisany jako oczekiwany w ramach funkcjonalności, ale Zamawiający tego zaniechał, a teraz dokonuje w oparciu o te elementy oceny warunkujące to czy oferta podlega lub nie podlega odrzuceniu.

Praktyka taka przeczy podstawowym zasadom zamówień publicznych wyrażonym w art. 16 ustawy Pzp.

Mając na uwadze powyższe, wnoszę jak na wstępie. (…) V.Wpływ na wynik postępowania Zgodnie z art. 554 ust. 1 Pzp Izba uwzględnia odwołanie, jeżeli stwierdzi naruszenie przepisów ustawy, które miało wpływ lub może miéć istotny wpływ na wynik postępowania o udzielenie zamówienia. Przedstawiony w odwołaniu stan faktyczny jak i dokonana analiza prawna potwierdzają, że w postępowaniu Zamawiający naruszył przepisy w taki sposób, że zaburzył wynik postępowania. Udzielenie zamówienia w takich okolicznościach, będzie działaniem sprzecznym z ustawą.

Do postępowania odwoławczego po stronie Zamawiającego przystąpienie w piśmie z dnia 30.12.2025 r. zgłosił wykonawca TK-MED Sp. z o.o. z/s w Chorzowie (Uczestnik po stronie Zamawiającego) wnoszą o oddalenie odwołania.

W uzasadnieniu stanowiska podał: (…) I.Interes przystępującego Przystępujący po stronie Zamawiającego – spółka TK-MED Sp. z o.o. złożyła ofertę w postępowaniu o udzieleniu zamówienia publicznego prowadzonego pn.: „Dostawa i wdrożenie systemu bezpieczeństwa SIEM/SOAR w ramach projektu grantowego >>Cyberbezpieczny Samorząd<<” przez Powiat Żyrardowski. Zgodnie z informacją o wyborze najkorzystniejszej oferty z dnia 17 grudnia 2025 roku, oferta złożona przez Przystępującego była jedyną ofertą niepodlegającą odrzuceniu. Co więcej, w toku postępowania ofertę złożyły zaledwie dwa podmioty, a drugim wykonawcą jest Odwołujący - spółka InfoSoftware Polska Sp. z o.o. Oferta złożona przez Odwołującego została odrzucona przez Zamawiającego na zasadzie art. 226 ust. 1 pkt 5 pzp oraz art. 226 ust. 1 pkt 8 pzp. Za najkorzystniejszą ofertę złożoną w postępowaniu została wybrana ta, złożona przez Przystępującego.

Przystępujący posiada zatem oczywisty interes prawny w uzyskaniu rozstrzygnięcia na korzyść Zamawiającego i jest zainteresowany utrzymaniem w mocy wyżej wymienionych czynności. Ewentualne uwzględnienie odwołania przez KIO miałoby bezpośredni i negatywny wpływ na sytuację Przystępującego, albowiem uniemożliwiałoby mu to realizację przedmiotu zamówienia publicznego, a tym samym uzyskanie z tego tytułu wynagrodzenia.

II.Stanowisko Przystępującego W ocenie Przystępującego zarzuty sformułowane przez Odwołującego pozostają nietrafione, albowiem wszystkie

czynności podjęte przez Zamawiającego odpowiadają wymogom stawianym przez przepisy pzp. Przytaczana przez Odwołującego argumentacja stanowi w istocie jedynie polemikę z prawidłowymi ustaleniami Zamawiającego podjętymi wskutek weryfikacji obu oferowanych systemów informatycznych. W konsekwencji, odwołanie jako niezasadne nie zasługuje na uwzględnienie i winno zostać oddalone.

Odnosząc się pokrótce do kolejnych zarzutów podnoszonych przez Odwołującego wskazać w pierwszej kolejności należy, iż oferta Odwołującego została zasadnie odrzucona przez Zamawiającego w oparciu o art. 226 ust. 1 pkt 5 pzp, albowiem jej treść nie była zgodna z warunkami zamówienia. Odwołujący w piśmie procesowym szeroko odnosi się do poszczególnych wad stwierdzonych przez Zamawiającego podczas dokonywania oceny dostarczonej próbki oprogramowania wywodząc, iż ocena dokonana przez Zamawiającego była błędna. Odnosząc się do nich tych uwag zbiorczo, zaakcentowania wymaga przede wszystkim pkt 144 zd. 3 Załącznika nr 8 do SW Z „W przypadku, gdy Zamawiający uzna niezgodność próbki i dokumentacji z wymaganiami OPZ, lub gdy Zamawiający nie odnajdzie określonego wymagania w próbce systemu i dokumentacji, oferta Wykonawcy zostanie odrzucona.” Oznacza to, że Zamawiający jasno sformułował w SW Z postanowienia, iż nieodnalezienie określonej funkcjonalności będzie skutkowało odrzuceniem oferty. Aby przeciwdziałać przypadkowemu przeoczeniu danej funkcjonalności Zamawiający przewidział specjalną procedurą opisaną szczegółowo w pkt 145 lit. g Załącznika nr 8 do SW Z, zgodnie z którym „Wykonawca w okresie 3 dni od otrzymania oceny strony Zamawiającego (ppkt. f) ma możliwość wyznaczenia spotkania w formie zdalnej (np. za pomocą platformy: Teams, Zoom lub Webex), podczas którego odniesie się on do wyników oceny zgodności i intuicyjności systemu, opracowanych przez Zamawiającego. Jeśli w wyznaczonym terminie Wykonawca nie zorganizuje spotkania i/lub nie przedstawi odpowiedzi na ocenę Zamawiającego zostanie uznane, że oferowane rozwiązanie nie spełnia wymagań OPZ”.

Oznacza to z jednej strony, iż Odwołujący miał prawo do zajęcia stanowiska i odniesienia się do uwag Zamawiającego jeszcze na etapie oceny próbek przedmiotu zamówienia. Z drugiej strony oznacza to jednak, iż ciężar dowodowy w takim przypadku (pkt 145 lit. g) został de facto przerzucony na Odwołującego, albowiem to on był zobowiązany do wykazania, iż zaoferowany przez niego system IT spełniał wymagania wbrew pierwotnej ocenie Zamawiającego. Procedurę tę należy zatem uznać za swoiste wezwanie do udzielenia wyjaśnień. Z przytoczonego przez Odwołującego stanu faktycznego wynika, iż do organizacji spotkania w trybie zdalnym de facto doszło, jednak złożone przez Odwołującego wyjaśnienia okazały się niewystarczające. Nie może dziwić, że Zamawiający oczekiwał prezentacji każdego z kwestionowanych wymagań, wobec niepopartych twierdzeń oferenta. Zgodnie z przytoczonym pkt 145 lit. g Załącznika nr 8 do SW Z, to właśnie to spotkanie w formie zdalnej miało służyć rozwianiu jakichkolwiek wątpliwości Zamawiającego. Z wniesionego odwołania wynika, że Odwołujący nie był jednak przygotowany na taką okoliczność i nie przeprowadził takiej prezentacji, a więc de facto nie przedstawił odpowiedzi na ocenę Zamawiającego. Dość wskazać, że procedura opisana w Załączniku nr 8 do SW Z nie przewidywała możliwości organizacji ponownego spotkania w jakimkolwiek trybie, toteż wyrażenie zgody na takowe przez Zamawiającego stanowiłoby naruszenie zasad postępowania i faworyzację jednego z wykonawców. Tym samym, Zamawiający słusznie (w oparciu o pkt 144 zd. 3 oraz pkt 145 lit. g. Załącznika nr 8 do SW Z) uznał, że oferowane rozwiązanie nie spełnia wymagań OPZ.

Gdyby Odwołujący równie szeroko, co w odwołaniu odniósł się do poszczególnych wad stwierdzonych przez Zamawiającego we właściwym czasie tj. podczas spotkania w trybie 5 zdalnym, Zamawiający mógłby dokonać weryfikacji własnych ustaleń. Wobec niewykorzystania przedmiotowej szansy, czynione obecnie wyjaśnienia uznać należy za co najmniej spóźnione. Rolą KIO w tego typu sprawach nie jest ponowna ocena całego systemu IT oferowanego przez Odwołującego, a to czy Zamawiający dokonując odrzucenia jego oferty naruszył przepisy ustawy lub postanowienia SW Z. Tymczasem, z przedstawionego stanu faktycznego jasno wynika, iż działania Zamawiającego znajdowały pełne oparcie w precyzyjnie opisanej w SWZ procedurze.

Mając na uwadze powyższe, stawiany przez Odwołującego zarzut naruszenia przez Zamawiającego art. 226 ust. 1 pkt 5 pzp jawi się jako zupełnie bezzasadny.

Po drugie, należy przyznać rację Zamawiającemu, który uznał, iż oferta Odwołującego zawiera rażąco niską cenę w stosunku do przedmiotu zamówienia. Odwołujący stawiając zarzut naruszenia art. 226 ust. 1 pkt 8 pzp podniósł, iż Zamawiający nie zaakceptował wyjaśnień udzielonych przez Odwołującego. Rzecz jednak w tym, że uzasadniając przedmiotowy zarzut, Odwołujący ograniczył się jedynie do skierowania wobec Zamawiającego słów krytyki imputując mu brak znajomości technologii czy zasad działania metod uczenia maszynowego. Tymczasem, w przypadku rozpoznania zarzutu rażąco niskiej ceny, na etapie postępowania odwoławczego ciężar dowodu rozkłada się analogicznie do tego w postępowaniu o udzielenie zamówienia. Oznacza to, że stosownie do art. 537 pzp ciężar dowodu, że oferta nie zawiera rażąco niskiej ceny, bądź też że cena nie budzi wątpliwości, spoczywa na wykonawcy który ją złożył. Zgodnie z utrwalonym orzecznictwem Krajowej Izby Odwoławczej, treść art. 537 pzp nie uprawnia Odwołującego do poprzestania na samych twierdzeniach i przerzucenia na uczestnika postępowania lub Zamawiającego ciężar dowodu (por. wyrok KIO z dnia 26

kwietnia 2022 r. o sygn. akt KIO 719/22 oraz wyrok KIO z dnia 21 stycznia 2019 r. o sygn. akt KIO 2617/18).

Mając na uwadze powyższe wskazać należy, iż w ocenie Przystępującego, Odwołujący nie sprostał ciężarowi dowodowemu i nie wykazał, że oferta nie zawiera rażąco niskiej ceny. W toku postępowania, Zamawiający słusznie powziął wątpliwości co do rynkowego charakteru ceny zawartej w ofercie Odwołującego i wezwał go do złożenia stosownych wyjaśnień. Dość wskazać w tym miejscu, że cena zaoferowana przez Odwołującego była ponad dwukrotnie niższa od tej przedstawionej przez Przystępującego, jak i ponad dwukrotnie niższa od kwoty jaką Zamawiający zamierzał przeznaczyć na sfinansowanie zamówienia. Zamawiający słusznie zakwestionował wyjaśnienia Odwołującego i uznał zaoferowaną cenę za rażąco niską. Przedstawiona przez Odwołującego argumentacja w złożonym odwołaniu nie może doprowadzić do zmiany dokonanej przez Zamawiającego ceny.

Mając na uwadze powyższe, stawiany przez Odwołującego zarzut naruszenia przez Zamawiającego art. 226 ust. 1 pkt 8 pzp jawi się jako zupełnie bezzasadny.

Po trzecie, nie sposób zgodzić się z zarzutem nr 3 sformułowanym przez Odwołującego, a dotyczącym rzekomej niezgodności z warunkami zamówienia oferty Przystępującego. Zamawiający precyzyjnie określił w jakich sytuacjach wymagania wskazane w Załączniku nr 8 do SW Z zostaną uznane za spełnione. Jedynie na marginesie wskazać należy, że Odwołujący sam dokonał ich przytoczenia na stronie siódmej odwołania. Zgodnie z pkt 145 lit f. „Wymaganie uznaje się za niespełnione, gdy jego ocena zostanie określona przez Zamawiającego poniżej poziomu 75%.” Z kolei, zgodnie z pkt 145 lit. e, ocena każdego z wymagań miała nastąpić z uwzględnieniem kryterium intuicyjności (25%) oraz zgodności (75%). Wskazać należy, iż w formularzu oceny systemu oferowanego przez Przystępującego, kwestionowane przez Oferującego wymaganie zostało ocenione przez Zamawiającego w wierszu (l.p.) nr 2 odnoszącym się do pkt 11 w OPZ.

Z powodu braku wspierania składni URI Zamawiający ocenił zgodność na poziomie 67% (na 75% możliwych), jednak ocenę intuicyjności na poziomie 25%, co sumarycznie oznaczało ocenę 92%. Zważywszy zatem, że w myśl przytoczonego pkt 145 lit. f. Załącznika nr 8 do SW Z, wymaganie uznaje się za spełnione w przypadku oceny na poziomie co najmniej 75%, nie może ulegać wątpliwości, iż oferta Przystępującego jest zgodna z warunkami zamówienia. W konsekwencji, stawiany przez Odwołującego zarzut naruszenia przez Zamawiającego art. 226 ust. 1 pkt 5 pzp pozostaje niezasadny.

Odnosząc się do zarzutu czwartego sformułowanego przez Odwołującego godzi się zauważyć, że ma on charakter wtórny, a ocena jego zasadności wynika wprost z oceny uprzednio omówionych zarzutów. Biorąc z kolei pod uwagę, iż te pozostają nietrafione, również i zarzut nr 4 nie zasługuje na uwzględnienie.

Przechodząc do sformułowanych przez Odwołującego zarzutów ewentualnych – wynika z nich, iż Odwołujący upatruje wadliwości postępowania uzasadniającej jego unieważnienie w dwóch argumentach tj. niejasności opisu zamówienia oraz przyznania oceny w oparciu o subiektywne odczucia. Pierwszy z powyższych stanowi w istocie powielenie zarzutu nr 3 dotyczącego sposobu oceny wymagań stawianych w OPZ. W ocenie Przystępującego, zasady oceny zostały precyzyjnie określone w Załączniku nr 8 do SW Z, a Przystępujący odniósł się do nich już we wcześniejszym fragmencie niniejszego pisma. Z powyższych względów powielanie przedmiotowej argumentacji w tym miejscu jawi się jako bezcelowe.

Drugi argument podnoszony przez Odwołującego odnosi się w istocie do zakwestionowania przesłanki „intuicyjności” do oceny oferowanego systemu IT. Tymczasem „intuicyjność” jako kryterium jakościowe jest powszechnie wykorzystywane w praktyce i aprobowane w orzecznictwie, zwłaszcza gdy przedmiotem zamówienia są właśnie systemy IT. Nie sposób zgodzić się ze stanowiskiem Odwołującego, iż kryterium to dawało Zamawiającemu pełną swobodę „w eliminowaniu oprogramowania bez logicznego uzasadnienia i w sposób 8 nieproporcjonalny”. Przeciwnie, należy zauważyć, że Zamawiający przyznał kryterium intuicyjności 25% wagi oceny.

Jednocześnie, jak przytoczono już wcześniej, wymaganie uznawało się za spełnione w przypadku oceny na poziomie co najmniej 75%. Oznacza to, że jeżeli dana funkcjonalność systemu była w pełni zgodna z oczekiwaniami Zamawiającego, to nawet w przypadku całkowitego braku intuicyjności i dokonania jej oceny na poziomie 0%, wymaganie należy uznać za spełnione. Tym samym, kryterium intuicyjności nie może samodzielnie prowadzić do subiektywnego eliminowania ofert wykonawców.

Co więcej, zgodnie z pkt 145 lit. g wykonawca miał prawo w terminie trzech dni od dnia otrzymania wyników oceny do wyznaczenia spotkania w formie zdalnej, celem odniesienia się do wyników oceny zgodności i intuicyjności systemu.

Oznacza to, że Zamawiający przyznał wykonawcom prawo de facto złożenia wyjaśnień już po przeprowadzeniu oceny oferowanych przez nich systemów informatycznych. Choć Przystępujący nie ma wiedzy o przebiegu przedmiotowego spotkania, nie sposób podzielić argumentacji Odwołującego zawartej na 48 stronie in fine odwołania. W ocenie Przystępującego, wszystkie przytoczone przez Odwołującego rozwiązania zostały zasadnie uznane przez Zamawiającego za nieintuicyjne. (…) Zamawiający w odpowiedzi na odwołanie (pismo z dnia 6.02.2026 r.) wniósł o oddalenie odwołania w całości.

W uzasadnieniu stanowiska wskazał: (…)

I. Zarzut dotyczący naruszenia art. 226 ust. 1 pkt 5) w zw. z art. 16 pkt 1) - 3) ustawy (…) – (…).

Każde zamówienie publiczne ma zamierzony cel, którego osiągnięcie jest możliwe w wyniku postępowania. Cel ten stoi ponad interesem wykonawców ubiegających się o zamówienie. Celem tym jest zaspokojenie konkretnych, obiektywnie uzasadnionych potrzeb zamawiającego poprzez efektywne wydatkowanie środków.

Prawo zamawiającego do określania parametrów technicznych, funkcjonalnych i jakościowych nie jest nieograniczone, ale granice te wyznaczają uzasadnione potrzeby. Jak wskazuje doktryna, zamawiający ma prawo opisać przedmiot zamówienia w sposób, który może ograniczać krąg potencjalnych wykonawców, pod warunkiem, że wymagania te są proporcjonalne do celu zamówienia i wynikają z obiektywnych potrzeb.

Zamawiający nie ma obowiązku obniżania swoich wymagań do poziomu „przeciętnej oferty rynkowej” ani dostosowywania opisu przedmiotu zamówienia do możliwości „przeciętnego wykonawcy”. Jeśli zamawiający wymaga specyficznej funkcjonalności, to fakt, że dany system realizuje to w inny sposób, nie czyni oferty zgodną.

Zakup systemu bezpieczeństwa (SIEM/SOAR) jest działaniem na rzecz ochrony interesu publicznego. W tym kontekście specyficzne, precyzyjne wymagania techniczne są uzasadnione koniecznością zapewnienia poziomu bezpieczeństwa i ergonomii pracy osób, które nabywany system będą obsługiwać w celu zapewnienia zbiorowej ochrony cyfrowej.

Opis przedmiotu zamówienia prezentujący konkretne wymagania funkcjonalne jest oczekiwaniem Zamawiającego co do konkretnego rezultatu działania systemu. Argumentacja opierająca się na twierdzeniu, że produkt (tu: system bezpieczeństwa) jest wystarczająco dobry lub realizuje cel w inny sposób podlega odrzuceniu a limine.

Postępowanie o udzielenie zamówienia nie jest też polem do wzajemnych ustępstw (poza trybami negocjacyjnymi), lecz procedurą sformalizowaną, w której oferta musi stanowić lustrzane odbicie wymagań zamawiającego. Jeśli jest inaczej, mamy do czynienia z niezgodnością treści oferty z warunkami zamówienia.

Zanim Zamawiający odniesie się do poszczególnych punktów składających się na ww. zarzut, należy we wstępie przybliżyć również rolę próbki. Otóż w niniejszym Postępowaniu próbka w formie dostępu demonstracyjnego pełniła funkcję przede wszystkim dowodową. Zgodnie z systematyką Ustawy, próbka jest przedmiotowym środkiem dowodowym. Służy potwierdzeniu, że oferowany system spełnia wymagania określone przez zamawiającego. Zatem próbka ma udowodnić, że system działa tak, jak opisano w opisie przedmiotu zamówienia. Nie jest to jedynie ilustracja możliwości wykonawcy i jego wizji systemu, lecz dowód. Ponadto obok funkcji dowodowej, próbka stanowi również element oferty. Pokazuje ona konkretne rozwiązania, które wykonawca oferuje i wykazuje spełnienie wymagań. Jeśli próbka nie zawiera pewnych funkcji wymaganych względem niej i później całego systemu, przyjmuje się, że oferowany system ich nie posiada. Próbkę należy zatem traktować jako wycinek możliwości produktu wykonawcy w momencie składania ofert. Zamawiający bada ten wycinek systemu, aby ocenić całość. Samo badanie odbywa się z kolei o przygotowane scenariusze testowe. Wykonawca, chcąc uzyskać zamówienie, musi przygotować próbkę w taki sposób, aby Zamawiający mógł bez trudu zweryfikować wymagane cechy. Próbka powinna być przyjąć takie parametry, aby umożliwić weryfikację bez konieczności posiadania wiedzy eksperckiej o wewnętrznej architekturze specyficznego produktu wykonawcy. Z kolei na Zamawiającym ciąży zakaz domniemania posiadania funkcji przez oferowany system: jeśli funkcja nie została zademonstrowana albo obligatoryjna instrukcja nie wykazuje jej istnienia, uznaje się ją za nieistniejącą w momencie jej badania.

W dalszej części Zamawiający odniesie się do każdego punktu składającego się na ww. zarzut, zgodnie z systematyką odwołania i przy zachowaniu przyjętej kolejności.

Punkt 1 opisu przedmiotu zamówienia Wbrew twierdzeniom Odwołującego (str. 11 odwołania), jakoby system wykorzystywał jedynie silnik bazy danych Elasticsearch, materiał dowodowy ujawnia wykorzystanie parametru o nazwie Elastic_Agent (nagranie „Reguły korelacyjne IS Sec.mkv”, czas 04:30).

1. Powyższy zrzut ekranu z interfejsu właściwego dla nowej reguły korelacyjnej prezentuje widoczną na liście filtrów/warunków „elastic_agent.id.keyword”. Obecność tego konkretnego parametru dowodzi, że system posiada zainstalowanego agenta Elastic Agent, będącego integralną częścią platformy Elastic Security.
2. Zgodnie z dokumentacją producenta1, Elastic Agent nie jest bazą danych. Jest to dedykowane oprogramowanie służące m.in. do aktywnej ochrony stacji końcowych (Security) i stanowi integralny element rozwiązania Elastic Security, wymienionego w pkt. 1 opisu przedmiotu zamówienia jako niedozwolony. Parametr Elastic Agent stanowi element oprogramowania systemu bezpieczeństwa Elastic Security. Elastic A w graficzny interfejs (GUI) do tworzenia reguł

normalizacji (parserów) dla zdarzeń z niestandardowych źródeł danych, w oparciu o konkretne składnie: CEF, LEEF, URI, XML, JSON, SYSLOG, REGEX. Zamawiający nie wymagał jedynie "możliwości obsługi" tych formatów, ale wymagał konkretnego narzędzia w interfejsie graficznym dedykowanego tym formatom.

1. W toku badania oferty Odwołującego (testu próbki), Zamawiający stwierdził brak funkcjonalności parsowania dla formatów CEF, LEEF, URI, XML, JSON, SYSLOG, REGEX z poziomu graficznego interfejsu. Odwołujący w piśmie przedstawił zrzuty ekranu jako materiał dowodowy, z których nie wynika wniosek przeciwny. Otóż na załączonych zrzutach ekranu widnieje funkcja „Dodaj procesor”, a niżej widoczna jest lista rozwijana „Typ”. Zawiera ona opcje takie jak: Konwersja na bajty, Konwersja okręgu, Identyfikator społeczności, Konwersja typu danych, CSV, Data, Nazwa indeksu z datą, Rozszerzanie notacji kropkowej, Usuwanie dokumentu, Komunikat o błędzie, Skrót zawartości dokumentu, Geosiatka, Dodawanie danych geograficznych, Wyrażenie regularne [Grok], Wyrażenie regularne [Gsub], Usuwanie znaczników HTML, Łączenie ciągów. Na kolejnym zrzucie widoczne są dodatkowe opcje: Konwersja URI, Tworzenie obiektu JSON. Na żadnym z dostarczonych zrzutów ekranu oferowanego systemu nie widnieją dedykowane opcje: CEF, LEEF, XML czy SYSLOG, abstrahując od ewentualnego sposobu ich działania, którego w oparciu o zrzuty ekranu nie sposób zweryfikować. Zamiast tego Odwołujący oferuje ogólny procesor "Wyrażenie regularne [Grok]", co w ocenie Zamawiającego stanowi próbę zmiany sposobu obsługi systemu w stosunku do wymagań.
2. Dodatkowo Zamawiający podnosi, że Odwołujący w przesłanych dokumentach nie definiuje jednoznacznie, czym w istocie jest oferowana przez niego składnia „GROK”. Brak tej definicji w materiałach Odwołującego narusza wymóg dostarczenia odpowiedniej dokumentacji – por. pkt 144 opisu przedmiotu zamówienia. To właśnie weryfikacja oferowanego systemu w postaci jego próbki i dostarczonej dokumentacji była podstawą kontroli spełnienia wymogów.

Podkreślenia wymaga, że nie tylko niezgodność systemu z wymaganiami, ale też niezgodność dokumentacji z opisem przedmiotu zamówienia lub sam brak dokumentacji, stanowiły podstawę odrzucenia oferty. Dokumentacja dostarczona przez Odwołującego była na tyle niekompletna i pozbawiona warstwy merytorycznej, że Zamawiający zmuszony był wyszukiwać informacji w zewnętrznych, ogólnie dostępnych źródłach, co z pewnością stanowi argument obalający twierdzenie Odwołującego o braku dobrej woli Zamawiającego do zapoznania się z systemem. Dokumentacja tej treści skutecznie utrudniała zapoznanie się z funkcjami systemu.

1. W tym miejscu Zamawiający uznaje za zasadne przedstawienie różnicy pomiędzy składnią GROK a wymienionymi formatami ustrukturyzowanymi. Składnia GROK narzędziem do obsługi danych nieustrukturyzowanych i służy do analizy tekstu linijka po linijce (liniowo). Potwierdza to dokumentacja firmy Elastic (twórcy standardu GROK) - Logstash Grok Filter Plugin . W przeciwieństwie do dedykowanych parserów XML/JSON, GROK nie interpretuje hierarchicznej struktury danych (drzewa), co sprawia, że jego użycie do tych formatów jest niezgodne z przeznaczeniem. Format XML to również format hierarchiczny, drzewiasty: „XML documents form a tree structure that starts at "the root" and branches to "the leaves" (tłumaczenie: Dokumenty XML tworzą strukturę drzewa, która zaczyna się od „korzenia” i rozgałęzia się do „liści”.) . Oznacza to tyle, że organizacja danych to relacja nadrzędny – podrzędny. Dostęp do konkretnej informacji wymaga przejścia ścieżki od „korzenia” przez „gałęzie” do „liścia”. W praktyce oznacza to konieczność nawigowania w dół struktury. Tym samym dane nie są dostępne z dowolnego poziomu, lecz są zawsze osadzone w kontekście nadrzędnym.
2. Jeszcze inaczej sprawa wygląda w przypadku formatu JSON, który definiuje się jako zbiór par nazw i wartości, gdzie wartością może być kolejny obiekt lub tablica. Taka definicja (obiekt w obiekcie) jest definicją struktury hierarchicznej (drzewiastej).
3. Mając na uwadze, że GROK nakłada wzorzec na pole tekstowe, tj. skanuje tekst od lewej do prawej (liniowo), próbując dopasować znaki, nie będzie właściwy dla struktury danych w postaci tzw. drzewa, co jest niezbędne do poprawnego, nieliniowego parsowania XML czy JSON.
4. Odwołujący w środku odwoławczym podnosi, że:
5. dostarczony przez niego opisu nie stanowi, iż parsowanie musi odbywać się poza środowiskiem graficznym, 2)składnia GROK umożliwia tworzenie "praktycznie dowolnych parserów", 3)gdyby Zamawiający znał GUI, odnalazłby wymagane funkcje pod przyciskiem "Dodaj parser", gent posiada wbudowane funkcje antywirusowe i detekcyjne. Jego obecność w systemie dowodzi, że Odwołujący oferuje rozwiązanie oparte nie tylko o bazę danych, lecz implementuje gotowy produkt pudełkowy (Elastic Security).

Punkt 11 opisu przedmiotu zamówienia

1. Punktem wyjścia dla oceny zgodności oferty jest wykładnia wymagań postawionych przez Zamawiającego. Zgodnie z dokumentami zamówienia, system musiał być wyposażony
2. wymagana jest wiedza o architekturze i dodanie źródła danych (np. urządzenia Syslog), czego Zamawiający nie zrobił, a ponadto źle sprecyzował w jaki sposób będzie weryfikował system – wówczas „można by jakoś to przygotować”.
3. Powyższa argumentacja stanowi próbę redefinicji wymagań na etapie postępowania odwoławczego. Odwołujący próbuje zastąpić wymóg posiadania dedykowanych, wcześniej opracowanych narzędzi wymogiem posiadania narzędzia

uniwersalnego (GROK), które przy odpowiednim nakładzie pracy może zrealizować ten sam cel. Jeżeli jednak Zamawiający wymagał obsługi konkretnych formatów poprzez interfejs graficzny, to intencją było pozyskanie systemu, który wykona polecenia względem tych formatów. Formaty te są standardami o ściśle określonej strukturze. Wymaganie ich obsługi w GUI oznacza oczekiwanie, że w operator wybierze z listy wymagany format, a system automatycznie rozpozna strukturę. System Odwołującego, opierający się na mechanizmie GROK, zmusiłby Zamawiającego do ręcznego definiowania struktury za pomocą wzorców tekstowych do tego niededykowanych. Nie jest to gotowy parser w GUI, lecz edytor kodu w GUI.

1. Zamawiający oczekiwał próbki systemu w celu potwierdzenia jego zgodności z wymaganiami. Zatem w Postępowaniu próbka jest materializacją oświadczenia woli Odwołującego. Ma ona pokazywać stan systemu w momencie składania ofert. Jeżeli w trakcie weryfikacji próbki Zamawiający nie znalazł funkcjonalności wymaganych, a Odwołujący nie był w stanie ich wskazać podczas prezentacji, to zgodnie z pkt 144 opisu przedmiotu zamówienia stanowi to dowód tego, że oferta pozostaje niezgodna z wymaganiami Zamawiającego.
2. Argumentację Odwołującego, że funkcje te można „jakoś przygotować” gdyby Zamawiający sprecyzował sposób weryfikacji, należy uznać za nieskuteczną. Po pierwsze próbka nie może być półproduktem, zapowiedzią dopiero wytworzenia funkcjonalności na etapie wdrożenia. System w wersji testowej powinien posiadać gotowe rozwiązania dla określonych wymogów, przykładowo widoczne w interfejsie jako opcje wyboru. Brak tych opcji jest dowodem, którego nie można zastąpić ogólnikowymi zapewnieniami o potencjale konfiguracyjnym systemu w przyszłości.
3. Ponadto Zamawiający nie doprowadził do sytuacji, w której ujawniłby lub uzgodnił sposób weryfikacji, żeby Odwołujący mógł przygotować system pod konkretne, wcześniej wyspecyfikowane czynności. To rolą Odwołującego było zaoferowane systemu spełniającego wymagania, w tym przygotowanie i opisanie scenariuszy, które umożliwią Zamawiającemu ich samodzielną weryfikację, niepoprzedzoną konsultacjami. Odwołujący natomiast próbuje przerzucić odpowiedzialność na Zamawiającego, zarzucając mu brak wiedzy o architekturze. Jest to próba obrony niezasługująca na uwzględnienie. To Odwołujący jako profesjonalista, zobowiązany jest przygotować ofertę, próbkę i scenariusze testowe w sposób, który umożliwi Zamawiającemu jednoznaczną weryfikację spełnienia wymagań.
4. Jeżeli obsługa formatu SYSLOG wymagała dodania źródła logów, Odwołujący powinien był przygotować próbkę systemu w taki sposób, aby weryfikacja była w ogóle możliwa. Obrona swojego produktu polegająca na zarzucaniu Zamawiającemu braku możliwości dodania źródła logów, wzmacniając to stwierdzeniem o braku wiedzy nt. architektury systemu iS Sec, jest argumentacją absurdalną i pozbawioną logiki. Zamawiający ponownie przypomina i podkreśla, że to rolą Odwołującego było wykazanie spełnienia wymagań poprzez udostępnienie systemu i opisanie scenariuszy, które wykażą spełnienie tych wymagań. Odwołujący nie wywiązał się z tej roli ani na etapie składania ofert, ani w toku spotkania zorganizowanego po przekazaniu uwag (por. pkt. 75-78) Punkt 23 opisu przedmiotu zamówienia 23.Wymogiem Zamawiającego względem systemu w zakresie elektronicznej dokumentacji była możliwość wizualizacji w formie interaktywnej mapy sieci, gdzie na pierwszym planie będą widoczne urządzenia zabezpieczeń, strefy bezpieczeństwa oraz połączenia sieciowe wskazujące jakie mechanizmy zabezpieczeń chronią poszczególne strefy bezpieczeństwa. Zamawiający oczekiwał, że „kliknięcie” na dowolny z obiektów na pierwszym planie pozwoli na podgląd oraz edycję parametrów tego obiektu. Przykładowo po kliknięciu na strefę bezpieczeństwa musi istnieć możliwość definiowania komputerów należących do tej strefy, ich adresacji oraz innych z nimi związanych parametrów.
5. Tymczasem Odwołujący zarzuca, że opis przedmiotu zamówienia nie precyzował wymogów co do rozdzielczości mapy. Twierdzi, że „rozdzielczość mapy (...) może być zmieniona wg wytycznych zamawiającego w procesie konfiguracji” (podkreślenie Zamawiającego) oraz że Odwołujący jest w stanie „skonfigurować system tak, żeby np. ta mapa była wyświetlana w osobnym oknie na całości ekranu” (podkreślenie Zamawiającego). Ostatecznie Odwołujący argumentuje również, że mapa jest czytelna dzięki funkcji „zoom” (przybliżanie scrollem).
6. Analiza dostarczonej próbki wykazała stan zgoła odmienny od deklaracji Odwołującego. Po pierwsze, prezentowana w próbce mapa sieci została zaimplementowana w sztywnych wymiarach 966x800 pikseli. Okno nie skalowało się (nie było responsywne) względem rozdzielczości monitora, zajmując jedynie ok. 27% powierzchni ekranu roboczego (na monitorze o rozdzielczości 2560x1440). Po drugie, w interfejsie próbki systemu brak było widocznej i dostępnej dla użytkownika opcji „wyświetlenia w osobnym oknie na całości ekranu”, o której Odwołujący opisuje w czasie przyszłym w odwołaniu. Zamawiającemu nie było dane na etapie badania ofert skorzystać z deklarowanej funkcji. Po trzecie, obsługa mapy w tak małym oknie, przy dużej liczbie obiektów wymusza ciągłe, nieergonomiczne przewijanie i skalowanie, co czyni widok nieczytelnym, a przez to nieintuicyjnym.
7. Zgodnie z pkt. 144 opisu przedmiotu zamówienia, Zamawiający oceniał dostarczoną próbkę systemu, a nie hipotetyczne funkcjonalności, które Odwołujący „może skonfigurować” po wdrożeniu. Próbka w dniu badania posiadała wadę w postaci sztywnego, małego okna wizualizacji, co obniżało jej użyteczność i uzasadniało dokonaną ocenę.

Deklaracje Odwołującego o możliwości przyszłej konfiguracji są bezprzedmiotowe w świetle oceny stanu zastanego

próbki.

Punkt 51 opisu przedmiotu zamówienia 27.Na wstępie Zamawiający, referując do stwierdzenia Odwołującego dot. braku wiedzy Zamawiającego na temat systemu, technologii oraz ogólnej zasady działania tego typu systemów, za zasadne uważa przywołanie stanowiska wyrażonego w pkt. 6 i 19-21 również w tym miejscu odpowiedzi.

1. Odnosząc się do uwag Odwołującego dot. języka angielskiego oraz wiedzy co do pól zaimplementowanych w systemie, Zamawiający wskazuje, co następuje. W pierwszej kolejności należy zwrócić uwagę na listę pól dostępnych do budowy reguł, która nie jest posortowana ani alfabetycznie, ani według logicznych grup systemowych. Wymaga to od użytkownika żmudnego przeszukiwania listy „linijka po linijce”. Po drugie, system wyświetla jedynie nazwy techniczne pól, bez żadnych podpowiedzi. Widoczne są pola takie jak elastic_agent.id.keyword czy ds-logs-filestream (gdzie pojęcie „wzorzec” raz występuje po polsku, a raz jako „pattern”), których znaczenie nie jest wyjaśnione w interfejsie ani w dostarczonej dokumentacji. Po trzecie, na liście wyboru znajdują się pola o nazwach wieloznacznych, np. related.ip.

Interfejs nie informuje, czy pole to dotyczy adresu IPv4 czy IPv6. Zmusza to użytkownika do domyślania się lub zewnętrznej weryfikacji w dokumentacji silnika Elastic (co potwierdza oparcie systemu o rozwiązania osób trzecich, a nie autorską, spójną logikę).

1. Odwołujący w odwołaniu wprost przyznaje, że „można było się domyślić z jakich systemów pochodzą”. Taka konstrukcja interfejsu stoi w sprzeczności z definicją intuicyjności, która zakłada łatwość obsługi bez konieczności domyślania się ukrytych znaczeń.
2. Podsumowując, obniżona ocena intuicyjności nie wynikała z samego użycia języka angielskiego, lecz z chaosu organizacyjnego w interfejsie, braku kategoryzacji pól oraz braku opisów funkcjonalnych, co czyni proces tworzenia reguł podatnym na błędy i czasochłonnym. Na dowód powyższego Zamawiającego przedstawia nagranie z badania próbki systemu, który potwierdza, że interfejs wymaga od operatora posiadania wiedzy tajemnej, bo niedostępnej w systemie ani instrukcji, a nie wiedzy inżynierskiej (plik „Reguły korelacyjne IS Sec,mkv”, czas: od 1:43 do 2:22, od 4:06 do 7:28).
3. Na marginesie, nawiązując do niemerytorycznych uwag Odwołującego podważających kompetencje personelu IT Zamawiającego, należy wskazać, że stanowią one niedopuszczalną w profesjonalnym obrocie próbę odwrócenia uwagi od wad oferowanego systemu. Fakt, że Odwołujący uzależnia obsługę systemu od „domyślania się” (co wprost przyznaje w odwołaniu) oraz posiadania przez operatora systemu niemalże wiedzy tajemnej, nieopisanej w dokumentacji ani instrukcji, dowodzi nieintuicyjności oferowanego narzędzia, a nie braku wiedzy Zamawiającego. Pozbawiona taktu narracja ad personam nie zastąpi brakującej funkcjonalności systemu, nie wchodzi zakres ochrony prawnej, stanowi dowód braku kultury i przez to zasługuje na pogardę.
4. Przechodząc do możliwości stosowania atrybutów użytkowników i komputerów z Active Directory, Zamawiający podtrzymuje dokonaną ocenę i stoi na stanowisku, że system nie spełniał ww. wymogu. Na prezentowanym przez Odwołującego zrzucie ekranu (s. 24) widnieją takie pozycje jak:
5. o365.audit.Parameters.WorkDays, 2)o365.audit.ModifiedPropertiesDevice, 3)o365.audit.CorrelationId, 4)winlog.event_data.Schema.keyword, 5)winlog.proces.pid, 6)winlog.event_data.ReturnCode.key.
6. Wymienione pozycje pochodzą z dzienników zdarzeń systemowych i zawierają informacje dostępne w momencie i miejscu zdarzenia. Są one statyczne względem zdarzenia – nie zmieniają się wraz ze zmianami stanu Active Directory.

Filtry oparte na winlog.event_data i o365.audit zawierają wyłącznie dane dostępne w samych logach.

1. W tym miejscu należy wyjaśnić, że Active Directory to centralna baza danych, która nadaje tożsamość logom.

Obrazując to przykładem, o ile log informuje, że „użytkownik X zalogował się na komputerze Y”, o tyle atrybuty Active Directory precyzują, że „użytkownik X jest Dyrektorem Finansowym, a komputer Y to serwer przechowujący dane wrażliwe”. Zamawiający wymagał, aby te konkretne informacje były bezpośrednio dostępne jako gotowe pola.

1. System Odwołującego dostarcza jedynie technicznych parametrów technologii Windows (np. numer procesu, kod błędu). Są to dane techniczne, oparte na zdarzeniach, ale nie zawierają w sobie informacji o tym, kim jest dany użytkownik w badanej strukturze. Zamawiający natomiast wymagał, żeby system posiadał dostęp do szczegółowych danych, takich jak: przynależność do grupy (np. „Administratorzy”), dział (np. „Kadry”), czy lokalizacja komputera.
2. Odwołujący w dostarczonej próbce systemu nie zaimplementował Active Directory, co było wymagane w punktach 51c i 51d opisu przedmiotu zamówienia. Zaoferowanie dostępu do logów systemowych jest jedynie warunkiem koniecznym do działania systemu, ale niewystarczającym do spełnienia wymogu wykorzystania atrybutów AD w procesie korelacji odpowiedzialnych za wykrywanie określonych zdarzeń pojawiających się w systemie.
3. Odnosząc się do twierdzenia Odwołującego odnośnie modułów UEBA oraz wskaźnika kompromitacji IoC i „niechęci

sprawdzenia (przeklikania systemu) oraz brak wiedzy na jego temat oraz tego typu technologii i systemów uniemożliwił Zamawiającemu odnalezienie tych funkcjonalności”, należy wskazać, że Odwołujący nie pokazał na żadnym zrzucie ekranu (a wcześniej w próbce) modułów zarządzania IoC ani UEBA. Instrukcja obsługi zawierała rozdział „Reguły korelacyjne”, który nie zawierał żadnej treści– poniżej fragment instrukcji dostarczonej przez Odwołującego:

1. Z kolei scenariusz testowy tej funkcji ograniczył się do wskazania okna reguł korelacyjnych i zdania „Przeglądnij dostępne opcje”. Twierdzenie, że system posiada w/w moduły, bez ich zaprezentowania w próbce, jest gołosłowne.

Przenosząc zasadę ciężaru dowodu na grunt niniejszej sprawy, elementy nieujęte w próbce, uznaje się za nieistniejące w ofercie.

Punkt 72 opisu przedmiotu zamówienia 39.Zamawiający zweryfikował każdą ze wskazanych zakładek, wykonując i dokumentując scenariusz testowy przedstawiony przez Odwołującego. Wynik tej weryfikacji, widoczny na całym przebiegu nagrania (por. Przypisywanie automatyczne zdarzeń IS Sec.mkv) nie ujawnił istnienia jakichkolwiek mechanizmów konfiguracji „logiki automatycznego przypisywania” opartej na wymaganiach z opisu przedmiotu zamówienia, tj. dostępności operatora czy jego bieżącego obciążenia.

1. Weryfikacja instrukcji obsługi, na którą powołuje się Odwołujący, wykazała, że na stronach 64-84 opisane są wyłącznie reguły powiadamiania (notyfikacji), a nie przypisywania zgłoszeń do konkretnego operatora w oparciu o obciążenie bądź dostępność (por. pkt 72 zd. 2 opisu przedmiotu zamówienia).
2. Twierdzenie Odwołującego, jakoby automatyczne przypisanie polegało na wyświetleniu zdarzeń zalogowanemu użytkownikowi, jest próbą wprowadzenia w błąd. Opis przedmiotu zamówienia w pkt. 72 definiuje, że system musi posiadać logikę uwzględniającą „dostępność operatora” i „jego obciążenie”. Mechanizm polegający na wyświetleniu wszystkich zdarzeń z racji posiadania jednego konta, a na tym koncie uprawnień administratora, nie jest logiką przypisywania zadań, lecz ich prezentacją.
3. Ponownie, twierdzenie o rzekomej niekompetencji Zamawiającego pozostaje bezzasadne w świetle dowodu z nagrania, na którym widać jak Zamawiający realizuje krok po kroku scenariusz testowania dostarczony przez Odwołującego. Uszło uwadze Odwołującego, że celem instrukcji i scenariusza testowego w procedurze weryfikacji próbki jest wskazanie Zamawiającemu, gdzie znajduje się wymagana funkcjonalność. Jeżeli funkcjonalność ta nie znajduje się w tych miejscach systemu, do których Zamawiający dotarł w sposób opisany w instrukcji i scenariuszu, to odpowiedzialność za ten stan rzeczy spoczywa wyłącznie ich autor. Braki w instrukcji, jej błędna redakcja lub wskazanie błędnych ścieżek dotarcia do pożądanych funkcji obciążają Odwołującego jako podmiot profesjonalny, zobowiązany do udowodnienia spełnienia wymogów. Ocena znajomości technologii przez Zamawiającego jest subiektywną opinią Odwołującego i nie ma znaczenia w procedurze, w której Zamawiający wykonuje polecenia z instrukcji. To Odwołujący swoim zaniedbaniem uniemożliwił weryfikację poprzez dostarczenie błędnej instrukcji, co potwierdza materiał wideo.
4. Nie sposób nie odnieść się również do tej części odwołania, w której Odwołujący argumentuje w oparciu o przyznanie dostępu do jednego konta (operatora), „do którego automatycznie system przypisał wszystkie zdarzenia/incydenty”, co miało na celu przedstawienie funkcjonalności. Otóż, jeśli Odwołujący skonfigurował tylko jedno konto, czym – jak sam przyznaje – technicznie uniemożliwił prezentację mechanizmu podziału zadań, to jest to okoliczność obciążająca wyłącznie Odwołującego. Zamawiający nie może domniemywać działania funkcji, której nie można uruchomić z powodu ograniczeń konfiguracyjnych narzuconych przez dostawcę próbki. Automatyczne przypisanie wszystkich procesów do jedynego użytkownika nie jest realizacją algorytmu badanego obciążenia i dostępności, lecz domyślnym zachowaniem każdego systemu informatycznego przy braku innych użytkowników. Tak skonfigurowana próbka prezentująca możliwości systemu nie może zostać uznana za spełniająca w/w wymóg.

Punkt 75 opisu przedmiotu zamówienia 44.Odwołujący podnosi, że opis przedmiotu zamówienia nie precyzował sposobu realizacji funkcjonalności grupowania.

Zdaniem Odwołującego zastosowanie przycisku „przypisz zdarzenie” jest rozwiązaniem wystarczającym i intuicyjnym, a ocena Zamawiającego w tym zakresie jest nierzetelna. Ponadto Odwołujący deklaruje gotowość zmiany nazwy funkcji na etapie wdrożenia.

1. Jednak z twierdzeniami Odwołującego nie sposób się zgodzić, a wynik oceny Zamawiającego potwierdza materiał dowodowy w postaci nagrania (plik Przypisywanie zdarzeń IS Sec.mkv). Jak prezentuje nagranie, czynność „przypisania” incydentu nie polega na wyborze incydentu z listy bądź zaznaczenie incydentu/incydentów i wykonanie polecenia, lecz wymaga ręcznego przepisania 32-znakowego unikalnego identyfikatora zdarzenia nadrzędnego i przypisanie do zdarzenia podrzędnym (bądź incydentu podrzędnego do nadrzędnego). Zamawiający zwraca uwagę, że w toku badania, w warunkach „laboratoryjnych” (brak presji czasu i stresu towarzyszącego incydentom krytycznym, gdzie czas ich zażegnania może wpłynąć na rozmiar szkody), pracownik Zamawiającego dwukrotnie popełnił błąd podczas przepisywania ciągu znaków, co nie powinno dziwić biorąc pod uwagę, że jest to ciąg znaków składających z liter i cyfr.

Potwierdza to, że zaimplementowana metoda jest nieergonomiczna i stwarza realne zagrożenie dla ciągłości obsługi incydentów.

1. Co więcej, w końcowej fazie nagrania widoczne jest, że system nie posiadał (lub instrukcja nie kierowała do tej czynności) funkcjonalności umożliwiającej zamknięcie incydentu nadrzędnego w sposób, który wymusiłby automatyczne zamknięcie incydentów podrzędnych. Dla przypomnienia, opis przedmiotu zamówienia stanowił, że: „zamknięcie nadrzędnego zdarzenia musi zamykać też wszystkie podrzędne”.
2. W ocenie Zamawiającego powyżej opisany i nagrany sposób obsługi incydentów dobitnie pokazuje jak nieintuicyjny, a nawet niebezpieczny biorąc pod uwagę wykorzystanie systemu w sytuacjach zagrożenia, pozostaje oferowany system Odwołującego. Polemika Odwołującego z gustem Zamawiającego jest tylko odwróceniem uwagi od realnego problemu, jaki mógłby stworzyć oferowany system.

Punkt 87 opisu przedmiotu zamówienia 48.Zamawiający ponownie przypomina, że to na Odwołującym spoczywał obowiązek przygotowania systemu i instrukcji w sposób niebudzący wątpliwości. Zamawiający nie jest zobowiązany do poszukiwania ukrytych funkcjonalności systemu ani do domyślania się sposobu ich działania, jeżeli nie wynika to wprost z dostarczonej instrukcji (scenariusza testowania).

1. Odwołujący zarzuca Zamawiającemu, że ten nie zaznajomił się z jego prostym opisem. Należy jednak zauważyć, że polecenie w instrukcji brzmiało lakonicznie: „5. Sprawdź możliwości filtrowania wyników”. Taka redakcja instrukcji przenosi ciężar eksploracji na Zamawiającego, ale z konsekwencjami dla Odwołującego. Instrukcja powinna wskazywać konkretną ścieżkę kliknięć prowadzącą do uzyskania wymaganego efektu. Brak takiej precyzji obciąża jedynie Odwołującego.
2. Aby wyjaśnić istotę problemu, warto wyjaśnić różnicę pomiędzy funkcją filtrowania (wymaganą przez Zamawiającego) a funkcją wyszukiwania (oferowaną przez Odwołującego). Wykonawca opiera zarzut na tezie, że system posiada wyszukiwarkę oraz moduł analizy podatności, które konsumują wymaganie filtrowania.
3. Otóż wyszukiwanie jako czynność polega na odnalezieniu konkretnego wyniku (lub grupy grupy) na podstawie dopasowania ciągu znaków (słów kluczowych) do treści przechowywanych w bazie danych. Użytkownik wpisując poszukiwany wynik oczekuje, że system przeszuka bazę w poszukiwaniu wystąpień tej frazy. Z kolei filtrowanie polega na zawężeniu widocznego zbioru poprzez parametry co do zdefiniowanych uprzednio właściwości. Filtrowanie opiera się na strukturze i typach danych: rozróżnia daty, liczby, statusy, co pozwala na odnalezienie wyników z pożądanego zakresu, których zwykła wyszukiwarka tekstowa nie wykona.
4. Zamawiający, po wykonaniu czynności wskazanych w dostarczonym scenariuszu testowym, po wejściu we wskazaną zakładkę „Podatności”, spotkał się z listą zawierającą wyłącznie jedną podatność. W oknie nie był widoczny żaden panel boczny, menu kontekstowe ani zestaw filtrów umożliwiających selekcję danych wg kryteriów z pkt. 87.

Widoczny interfejs nie oferował funkcjonalności pozwalających na zawężanie wyników w sposób wymagany.

1. Należy podkreślić, że umieszczenie wyników skanowania podatności w module SLA jest informatycznym absurdem i dowodzi braku logiki w architekturze systemu. Aby uzmysłowić skalę tego absurdu, należy najpierw wyjaśnić czym jest SLA i zarządzanie podatnościami.
2. SLA (Service Level Agreement) to moduł służący do monitorowania jakości świadczenia usług. Dotyczy parametrów opartych na czasie, takich jak dostępność systemu, czas reakcji na zgłoszenie, czas usunięcia awarii. Z kolei zarządzanie podatnościami jest modułem służącym do identyfikacji, oceny i eliminacji luk bezpieczeństwa.
3. W systemie Odwołującego, aby odnaleźć listę podatności, operator musi udać się do modułu służącego do rozliczania umów i czasów reakcji (SLA). Jest to działanie sprzeczne z jakąkolwiek intuicją i logiką, zwłaszcza że w głównym menu jest zakładka „Skaner podatności”. Ulokowanie funkcji z zakresu bezpieczeństwa w module rozliczeniowym sprawia, że dla użytkownika końcowego funkcja ta jest de facto niedostępna. Zamawiający nie ma obowiązku badania całego systemu w poszukiwaniu pożądanych funkcji, które Odwołujący ukrył w nielogicznych lokalizacjach, ale co gorsze - nie opisał w dostarczonych materiałach, pozostawiając Zamawiającego bez wymaganego wsparcia.

Punkt 122 opisu przedmiotu zamówienia 56.Zamawiający wymagał, aby rozwiązanie SIEM wspierało obsługę agentów na systemy Windows, posiadających m.in. centralne zarządzanie i możliwość aktualizacji z głównej konsoli (lit. a); zdolność monitorowania integralności plików, rejestru systemowego oraz urządzeń zewnętrznych (lit. d, e, f); możliwość przygotowania i przypisywania różnych zestawów konfiguracji (lit. i); automatyzację reakcji (blokowanie ruchu/procesu) - lit. j.

1. Odwołujący twierdzi, że system posiada agentów, których zarządzanie jest możliwe w "formie uproszczonej" (sprawdzanie statusów/usuwanie), a aktualizacja i reakcja odbywają się poprzez skrypty w module SOAR ("Playbooki").

Zarzuca Zamawiającemu, że ten pominął instrukcję nakazującą szukanie funkcji agentowych w module automatyzacji (SOAR).

1. Weryfikacja systemu Odwołującego, utrwalona na nagraniu wideo (por. plik Agenty IS Sec.mkv), potwierdza prawidłowość oceny dokonanej na etapie badania próbki.
2. Nawiązując do pkt. 122 lit. a opisu przedmiotu zamówienia, zgodnie z instrukcją Odwołującego, użytkownik jest kierowany do modułu SOAR -> Playbooki. Jest to próba obejścia wymogu. Moduł SOAR służy do orkiestracji incydentów (łączenie rozproszonych systemów bezpieczeństwa takich jak firewalle, systemy SIEM, poczta elektroniczna, w jeden spójny ekosystem, umożliwiając im wymianę informacji), a nie do zarządzania infrastrukturą. Na nagraniu widać listę playbooków (predefiniowane scenariusze, czas 1:49), jednak brak jest tam funkcji służącej do ustalenia: miejsca instalacji agenta, wersji agenta czy mechanizmu dystrybucji aktualizacji na końcówki. System nie posiada narzędzia do zarządzania agentami. Cały scenariusz testowy nie dotyczył agentów system Windows.
3. System był pozbawiony funkcji monitorowania, wymaganych w pkt. 122 lit. d, e, f. W oparciu o próbę nie stwierdzono żadnych opcji konfiguracji monitorowania integralności plików, rejestru systemowego ani urządzeń zewnętrznych (np. nośników danych). W sekcji "Lista urządzeń" widocznej na nagraniu brak jest wglądu w jakiekolwiek parametry, a jedyne informacje to wersja systemu operacyjnego i adres IP (czas 3:00). Świadczy to o tym, że istnieje komunikacja zwrotna z agentem. Fakt ten jednak w żaden sposób nie dowodzi spełnienia w/w wymagań. Sama bowiem obecność agenta raportującego wersję systemu nie jest tożsama z posiadaniem przez niego wymaganych funkcji. Jak prezentuje dostarczone nagranie, nie stwierdzono żadnych danych ani opcji konfiguracyjnych potwierdzających monitorowanie zmian w plikach, rejestrze czy podłączenia nośników zewnętrznych.
4. Pomimo wymogu dot. komunikacji z poszczególnymi komponentami rozwiązania SIEM w sposób zaszyfrowany z wykorzystałem protokołu HTTPS (por. pkt 122 lit. g opisu przedmiotu zamówienia), w systemie nie ma przykładowo sekcji zarządzania certyfikatami szyfrującymi połączenie dla agentów ani podglądu statusu szyfrowania bądź inny dowolny dowód, że połączenie jest szyfrowane. Dostarczony scenariusz testowania w żaden sposób nie umożliwiał ustalenia, że połączenie było zaszyfrowane.
5. Odnośnie możliwości monitorowania stanu agentów w konsoli zarządzającej, sama lista urządzeń nie potwierdza spełnienie wymogu. To, że system widzi komputer w sieci (np. odpowiada na polecenie PING), nie oznacza, że zainstalowany na nim agent działa poprawnie, jest aktywny i przesyła logi. Prezentowana w systemie lista to nic innego jak widoczne zasoby sieciowe, a nie konsola zarządzania agentami. Widoczne statusy i informacje (online/active, adres IP) odnoszą się wyłącznie do dostępności sieciowej. Nagranie we fragmencie prezentującym urządzenia w sieci ujawnia, że system nie rozróżnia sytuacji, w której komputer jest włączony, ale np. proces agenta uległ zatrzymaniu. Widoczność urządzenia w sieci nie jest tożsama z monitorowaniem stanu agenta. Wymóg dotyczył weryfikacji, czy oprogramowanie zabezpieczające działa, a nie czy komputer jest podłączony do zasilania.

Próbka systemu nie wykazała możliwości tworzenia zestawów polityk (np. osobna polityka dla DNS, osobna dla AD) i ich zdalnego przydzielania grupom agentów (por. pkt 122 lit. i opisu przedmiotu zamówienia).

Punkt 125 opisu przedmiotu zamówienia 63.W odpowiedzi na wezwanie Zamawiającego, Odwołujący udostępnił środowisko demonstracyjne systemu iS Sec, opartego na silniku Elastic Search i MS SQL. Odwołujący wprost wskazał w scenariuszu testowym: „System jest zintegrowany z zewnętrznymi bazami danych Threat Inteligence”. Weryfikacja przeprowadzona przez Zamawiającego ujawniła jednak rozbieżność pomiędzy oświadczeniem a stanem faktycznym.