Акціонерне товариство "Державний експортно-імпортний банк України" оприлюднило оголошення в системі Прозоро про закупівлю програмної продукції в електронному вигляді для захисту веб-ресурсів Банку від DDoS атак та захисту за допомогою WAF терміном на 12 місяців з дати активації. Аукціон буде запланований після 04.10.2024. Перелік вендорів ПП: Cloudflare, Imperva, Radware, Akamai.
ТЕХНІЧНЕ ЗАВДАННЯ
на закупівлю
48730000-4 пакети програмного забезпечення для забезпечення безпеки (програмна продукція хмарного захисту веб-додатків від DDoS атак)
Найменування програмної продукції: Програмна продукція в електронному вигляді (далі ПП) для захисту веб-ресурсів Банку від DDoS атак та захисту за допомогою WAF, 12 місяців з дати активації.
Перелік вендорів ПП: Cloudflare, Imperva, Radware, Akamai.
|
№ |
Кількісні параметри ПП/системи |
Кількість |
|
1 |
Кількість мережевих об’єктів Банку (IP-адрес), що мають бути захищені засобами ПП |
40 |
Опис ПП (СИСТЕМИ)
1. Розгортання та функціонування ПП
1.1 ПП поставляється у вигляді:
«Хмарного» сервісу (консолі) управління ПП/системою, розміщеного на веб-ресурсах вендора;
1.2 Робота рішення в якості Reverse Proxy.
2. Централізоване управління
2.1 Система має забезпечувати централізоване управління, як за допомогою веб-інтерфейсу, так і RestAPI із метою збору інформації, управління всіма її компонентами, налаштуванням комплексних кореляційних правил задля забезпечення інформаційної безпеки.
2.2 Система має зберігати мережевий трафік з функцією візуалізації в реальному часі для можливості аналізування та побудови звітів і відслідковування мережевих аномалій за останні 30 днів із можливістю експорту різних звітів щодо інцидентів інформаційної безпеки.
2.3 Система має надавати можливість грануляції доступу до облікового запису на основі ролей.
3. Користувачі системи
3.1 Система має забезпечити доступ до неї користувачів на основі персоніфікованих облікових записів та відповідно до ролей - із застосуванням розмежування прав доступу.
3.2 Система має надавати можливість Адміністратору налаштовувати базові параметри безпеки і доступу до платформи, такі як:
мультифакторна аутентифікація для всіх користувачів (застосування внутрішніх (що є частиною самого ПП), або зовнішніх (що є частиною загальнодоступних безкоштовних сервісів Microsoft, Google тощо) засобів додаткової аутентифікацїі користувачів через одноразові паролі, Push-повідомлення та ін.);
3.3 Система повинна мати можливість логування аудиту та змін налаштувань її компонентів.
4. Захист інформації
4.1 Вендор ПП має забезпечити захист від несанкціонованого доступу з боку сторонніх осіб інформації, що зберігається всередині компонентів Системи, розміщених на ресурсах вендора («хмарна» консоль управління тощо) - внутрішніми засобами Системи.
4.2 Система має забезпечити шифрування мережевих комунікацій між її компонентами/модулями, а також, між користувачами та засобами Системи із застосуванням стійких криптоалгоритмів, що відповідають регуляторним вимогам Національного банку України (TLS 1.2 та вище, IPsec у режимі ESP тощо).
4.3 Система повинна забезпечити можливість використання власних сертифікатів для шифрування даних.
4.4 Система повинна забезпечити можливість шифрування обох сесій (зі сторони клієнта та сервера).
5. Вимоги до функціоналу захисту
5.1 Система повинна мати механізми захисту: Блокування, Captcha Challenge, JS Challenge.
5.2 Система повинна мати можливість визначення реакції на кожну подію безпеки.
5.3 Система повинна мати можливість визначення правил доступу на основі User-agent.
5.4 Система повинна мати можливість визначення правил доступу для певних зон сайту.
5.5 Система повинна мати можливість визначення параметрів для окремих сторінок.
5.6 Система повинна мати можливість включення режиму захисту для всього ресурсу.
5.7 Система має відповідати стандартам PCI DSS.
6. Захист від DDoS
6.1 Система повинна мати наявність функціоналу захисту від DDoS на рівні додатків L7 та одночасно захисту на основі WAF.
6.2 Захист від обсягових атак незалежно від розміру та тривалості.
6.3 Рішення має можливість захисту від атак на перебір паролів (Brute Force).
6.4 Рішення має можливість визначення кількості запитів з одного IP для окремих сторінок веб-ресурсу (Rate Limiting).
6.5 Рішення має можливість створення власних правил обробки запитів.
6.6 В системі наявний механізм вивчення поведінки трафіку при побудові політик DDoS.
6.7 Гарантований об'єм легітимного (очищеного) трафіку на рівні L7 не менше ніж 100 мб/с або кількість HTTP/S запитів на рівні L7 на місяць не менше ніж 150 000 000 (4 TB).
7. Захист веб-додатків
7.1 Захист від атак на вразливості.
7.2 Захист від OWASP TOP-10 вразливостей.
7.3 Наявність попередньо встановлених шаблонів захисту в залежності від платформи.
7.4 Можливість налаштування правил реакції на загрозу для кожної сигнатури.
7.5 Автоматичне оновлення сигнатур захисту.
7.6 Можливість додавання параметрів до веб-запиту.
7.7 Можливість створення користувацьких правил WAF.
7.8 Захист від атак Brute Force.
7.9 Захист веб-додатків розміщених на “Нестандартних” портах інструментами WAF та Anti-DDoS.
7.10 Обов’язковий захист на портах: 443, 2011, 2012, 8443, 8444, 3333, 3334, 22022, 8083, 3443, 6444, 9744, 6454, 9754, 7002, 4333, 4334, 1201-1204, 9032, 9033, 7003, 9003, 10003, 1200, 1210, 9023, 5003, 6003, 1207-1209, 9022.
8. Захист від ботів
8.1 Функціонал блокування шкідливих ботів і дозвіл доступу для ботів дозволених пошукових систем.
8.2 Використання механізмів машинного навчання, поведінкового аналізу та white-lists для визначення доступу ботів до ресурсів.
8.3 Можливість використання детальних параметрів запиту для визначення доступу.
8.4 Застосування rate-limiting правил для пригнічення бот-атаки.
8.5 Можливість відправки логів про події на сторонні системи SIEM.
9. Вимоги до DNS
9.1 Можливість використання CNAME.
9.2 Використання протоколу DNSSEC.
10. Вимоги до шифрування
10.1 Підтримка протоколу шифрування TLS 1.3.
10.2 Можливість визначення мінімальної версії протоколу шифрування даних для доступу до ресурсу.
10.3 Можливість шифрування обох сесій (зі сторони клієнта та сервера).
10.4 Можливість використання власних сертифікатів для шифрування даних.
11. Вимоги до організації доступу
11.1 Можливість логування аудиту та змін.
11.2 Можливість задавати правила доступу для користувачів.
11.3 Можливість задавати правила доступу для груп.
12. Вимоги до аналітики
12.1 Виведення інформації про трафік в реальному часі.
12.2 Виведення інформації статистики за країнами.
12.3 Можливість логування в реальному часі.
12.4 Можливість використання деталізованої фільтрації при відображенні звітів.
12.5 Можливість отримання сирих логів з використанням REST API.
12.6 Можливість передачі реального IP користувача на захищені сервери додатків.
12.7 Дані на інформаційних панелях повинні відображатися не менше ніж за останні 30 днів.
13. Вимоги до підтримки
13.1 Підтримка 24/7/365.
13.2 Гарантований uptime 99%.