програмна продукція для перегляду та аналізу даних журналів реєстрації подій операційних систем та прикладного програмного забезпечення

Добрий день! Просимо надати обґрунтовану відповідь та внести відповідні зміни в тендерну документацію щодо потенційно дискримінаційних її вимог та неточностей, а саме: 1. Детально вивчивши вимоги в додатку 2 до тендерної документації, а саме Розділу ІІ. «Вимоги до системи аудиту подій в ІТС» ми дійшли висновку, що в даному пункті відсутній такі ключові вимоги до кількісних характеристик системи аудиту подій в ІТС, такі як кількість подій, що опрацьовуються за секунду та/або об’єм в Гігабайтах даних щодо події, що опрацьовуються за годину/день/місяць або їх еквівалент. Враховуючи те, що згідно правил ліцензування всесвітньо відомих виробників програмного забезпечення, що можуть бути запропоновані учасниками, ці показники є критично важливими для коректного розрахунку необхідної кількості ліцензій. 2. Вимоги пп.1.18, п. 1. «Загальні вимоги», Розділу ІІІ. «Вимоги до системи аудиту дій користувачів» про те що система аудиту повинна мати можливість одночасного моніторингу цільової групи НЕ МЕНШЕ 200 користувачів - має бути конкретизована та деталізована хоча б до кроку в 10-50 користувачів. Виходячи з такого формулювання тисяча та мільйон також більше двохсот. Згідно правил ліцензування всесвітньо відомих виробників програмного забезпечення, що можуть бути запропоновані учасниками, ці показники є критично важливими для коректного розрахунку необхідної кількості ліцензій. 3. Детально вивчивши вимоги в додатку 2 до тендерної документації, а саме пп. 2.3.5, 2.3.6 та 2.3.7, п. 2 «Вимоги до компоненту збору подій», Розділу ІІ. «Вимоги до системи аудиту подій в ІТС» ми дійшли висновку, що дані підпункти мають відношення до характеристик ДЖЕРЕЛ з яких Система має отримувати для опрацювання інформацію про події, а не до Системи аудиту подій в ІТС. Вимагаємо їх виключення з додатку 2 до тендерної документації як такі, що не стосуються предмету закупівлі та не впливають на роботу Системи в цілому 4. Вимоги пп.1.4, п. 1. «Загальні вимоги», Розділу ІІІ. «Вимоги до системи аудиту дій користувачів» про те що Система аудиту повинна ВІДСТЕЖУВАТИ зміни в IT-інфраструктурі і ЗДІЙСНЮВАТИ ЇХ КОНТРОЛЬ - є некоректними тому що такий функціонал не відноситься до функціоналу систем аудиту дій користувачів. 5. Вимоги пп.2.1.1-2.1.13, п. 2. «Вимоги до можливостей налаштування системи аудиту», Розділу ІІІ. «Вимоги до системи аудиту дій користувачів» про те що саме має відображатися в консолі системи аудиту – повність описує інтерфейс рішення конкретного виробника ObserveIT, а не необхідні технічні вимоги. Вимагаємо їх виключення з додатку 2 до тендерної документації як такі, що обмежують конкуренцію. Дякуємо.

Шановний Організатор! Ми уважно вивчили відповіді Організатора на загальні питання по закупівлі з ідентифікатором UA-2020-04-17-003366-c. Просимо Організатора відповідно прокоментувати/надати уточнення/спростувати свої ствердження щодо: --1.-- Відповіді, наданої 30 квітня 2020 10:40, а саме: ««Згідно інформації з відкритих джерел, вимозі, щодо наявності у Системі аудиту функціоналу розпізнавання тексту у відеозображенні (модуль OCR), та пошуку по розпізнаному тексту, викладеній у п.п. 1.12. п. 1 Розділу ІІІ Додатку 2 до тендерної документації, крім програмної продукції виробництва ObserveIT, відповідає програмна продукція ще щонайменше двох виробників, а саме One Identy та BalaBit IT Security. Таким чином, вимога щодо наявності у Системі аудиту функціоналу розпізнавання тексту у відеозображенні (модуль OCR), та пошуку по розпізнаному тексту, не є дискримінаційною та відповідає вимогам законодавства у сфері публічних закупівель. Отже, тендерна документація не потребує внесення змін у цій частині.»» - ВІДПОВІДЬ НЕ Є ПОВНІСЮ ДОСТОВІРНОЮ. Просимо ще раз уточнити, які саме виробники маються на увазі у Вашій відповіді. Справа в тому, що компанія BalaBit IT Security була повністю викуплено компанією OneIdentity на початку 2018 року. Тому у відповіді мова йде про ОДНОГО Й ТОГО Ж САМОГО ВИРОБНИКА. Продукт OneIdentity Safeguard for Privileged Sessions, який мається на увазі у відповіді, дійсно підтримує розпізнавання тексту у відеозображені, але не відноситься до категорії «аудит дій користувачів». Натомість він призначений для аудиту дій виключно системних адміністраторів і не підходить для вирішення задач замовника згідно технічних вимог.»; --2.-- Відповіді, наданої 05 травня 2020 о17:44, а саме: «« Вимога, викладена у пп.1.8 п. 1. Розділу ІІ Додатку 2 до тендерної документації щодо архітектури зберігання вхідних та вихідних (збагачених) даних у двох різних базах обумовлена необхідністю розмежування доступу певних адміністраторів до цієї інформації за їх ролями з метою запобігання спотворенню або знищенню даних»» - ВІДПОВІДЬ НЕ ПОЯСНЮЄ ТЕ, ЩО ВИМОГА ОПИСУЄ КОНКРЕТНЕ РІШЕННЯ SPLUNK, ЧИМ ОБМЕЖУЮТЬ КОНКУРЕНЦІЮ. Якщо Організатору потрібне розмежування, чому в ТЗ так і не написати. В такому разі просимо викласти вимогу у такій редакції «Система повинна дозволяти розмежувати доступ адміністраторів за їх ролями окремо для вхідних даних та вихідних даних з внесеними змінами та доповненнями (збагачені дані) з метою запобігання спотворенню або знищенню» для визначення функціональних властивостей і не вимагати конкретної архітектурної реалізації.»; --3.-- Відповіді, наданої 05 травня 2020 17:45, а саме: «« Підпункти 2.3.5, 2.3.6 та 2.3.7 пункту 2 Розділу ІІ Додатку 2 до тендерної документації визначають вимоги до функціональних можливостей агентів компоненту збору подій, необхідних для вирішення задач контролю та моніторингу інформаційної системи замовника. Виключення цих підпунктів з технічних вимог суттєво обмежить можливості»» - ВІДПОВІДЬ НЕ ПОЯСНЮЄ ТЕ, ЩО ВИМОГА НЕ ВПЛИВАЄ НА РОБОТУ СИСТЕМИ В ЦІЛОМУ, А ТІЛЬКИ ОБМЕЖУЮТЬ КОНКУРЕНЦІЮ. В такому випадку просимо чітко викласти у вимозі, що вона стосується програмних агентів, наприклад в такій редакції: «2.3.5 внесення за допомогою встановленого на джерело подій програмного агента необхідних змін в конфігураційні файли, обладнання і систем, що обслуговуються Системою; 2.3.6 збору подій агентом з використанням мінімальних привілеїв на джерелі подій, якщо компоненту збору подій необхідний доступ до джерела подій; 2.3.7 здійснювати передачу подій з агента сбору подій, встановленого на джерело, на компонент обробки подій по захищеному протоколу SSL з можливістю завантаження користувацького сертифікату;». Ми наполягаємо на внесенні зазначених змін в тендерну документацію даної закупівлі з метою усунення дискримінаційних вимог. Згадані Організатором виробники Ekran System, One Identy, Netwrix, IBM, Elasticsearch (що наводилися як такі що мають аналогічний Splunk/ ObserveIT функціонал) – по одинці можуть лише частково покривати відповідні вимоги розділів додатку 2 до тендерної документації, але в сукупності вимог- їх не задовольняють. Тобто щоб скласти конкуренцію описаним замовникам продуктам Splunk/ObserveIT учасникам потрібно запропонувати рішення ще додатково двох-трьох інших виробників, що не завжди можливо згідно принципів ліцензування та технічних особливостей програмного забезпечення, а суттєво перевищує оголошену вартість цієї закупівлі чим обмежує конкуренцію. Дякуємо!

Доброго дня! Просимо Вас роз'яснити, яким чином можуть бути виконані вимоги п. 2.2.1 та п.2.2.2 додатку 2 до тендерної документації, а саме яким чином компонент збору подій повинен здійснювати нормалізацію і агрегування подій з використанням наданих виробником конфігураційних файлів (правил нормалізації подій) для пропрієтарних та самописних систем за умови відсутності у виробника будь-якої інформації про ці системи, зокрема, про коректність реалізації протоколів передачі даних, зазначених в п. 2.1. Чи буде можливість виконання вимог п. 2.3.1 задовольняти вимоги п. 2.2.1 та 2.2.2?