Інтеграція системи моніторингу інформаційної безпеки Wazuh у діяльність Департаменту фінансів Черкаської обласної державної адміністрації

Яковлев, Богдан Вікторович

Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6509

Title:	Інтеграція системи моніторингу інформаційної безпеки Wazuh у діяльність Департаменту фінансів Черкаської обласної державної адміністрації
Authors:	Палагін, Володимир Васильович Яковлев, Богдан Вікторович
Keywords:	моніторинг інформаційної безпеки;інфраструктура департаменту;SIEM-рішення
Issue Date:	2025
Abstract:	Метою дослідження є розробка та обґрунтування проєкту інтеграції системи моніторингу інформаційної безпеки Wazuh для підвищення рівня захищеності інформаційних ресурсів Департаменту фінансів Черкаської ОДА Об’єкт дослідження: Процеси забезпечення інформаційної безпеки в Департаменті фінансів Черкаської ОДА. Предмет дослідження: Методи та засоби інтеграції системи моніторингу безпеки Wazuh в інформаційну інфраструктуру Департаменту.
URI:	https://er.chdtu.edu.ua/handle/ChSTU/6509
Appears in Collections:	125 Кібербезпека та захист інформації (Безпека інформаційних і комунікаційних систем)

Files in This Item:

File	Description	Size	Format
М_125__Яковлєв_Палагін+.pdf Restricted Access		2.64 MB	Adobe PDF	View/Open Request a copy

Show full item record

Extracted text

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ЕЛЕКТРОННИХ ТЕХНОЛОГІЙ,
АВТОТРАНСПОРТУ ТА МАШИНОБУДУВАННЯ
КАФЕДРА РОБОТОТЕХНІЧНИХ І ТЕЛЕКОМУНІКАЦІЙНИХ СИСТЕМ
ТА КІБЕРБЕЗПЕКИ

До захисту допущено
завідувач кафедри РТСК
д.т.н., професор
В.В. Палагін
" " 2025 року

Пояснювальна записка
до дипломного роботи
магістра
(освітньо-кваліфікаційний рівень)

на тему Інтеграція системи моніторингу інформаційної безпеки Wazuh у
діяльність Департаменту фінансів Черкаської обласної державної
адміністрації

Виконав: студент 2 курсу, групи мБІ-041
Спеціальності 125 – «Кібербезпека та захист
інформації» ,
(шифр і назва спеціальності)

освітньої програми «Безпека інформаційних і
комунікаційних систем»
(назва освітньої програми)
Яковлєв Б.В.
(прізвище та ініціали)
Керівник Палагін В.В.
(прізвище та ініціали)
Рецензент Лавданський А.О.
(прізвище та ініціали)

Черкаси – 2025 року

Форма № Н-9.01

ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
(повне найменування вищого навчального закладу)
Факультет електронних технологій, автотранспорту та машинобудування
(повна назва)
Кафедра робототехнічних і телекомунікаційних систем та кібербезпеки
(повна назва)
Освітньо-кваліфікаційний рівень магістр

Спеціальність 125 – «Кібербезпека та захист інформації»

Освітня програма Безпека інформаційних і комунікаційних систем

ЗАТВЕРДЖУЮ
Завідувач кафедри д.т.н., проф.
____________ Палагін В.В.
“___” _____________ 2025 року

З А В Д А Н Н Я
НА КВАЛІФІКАЦІЙНУ РОБОТУ МАГІСТРА СТУДЕНТУ
Яковлєву Богдану Вікторовичу
(прізвище, ім’я, по батькові)

1. Тема роботи «Інтеграція системи моніторингу інформаційної безпеки Wazuh у діяльність Департаменту
фінансів Черкаської обласної державної адміністрації»
керівник роботи _ Палагін Володимир Васильович_____
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом Черкаського державного технологічного університету від
«15» __Вересня_ 202_ року №_261/03-03__.
2. Строк подання студентом роботи «_5_» Грудня 2025 р.
3. Вихідні дані до роботи Нормативно-правова база України у сфері кібербезпеки (Закони України, вимоги
ДССЗЗІ); офіційна технічна документація системи Wazuh; модель ІТ-інфраструктури Департаменту
фінансів; модель загроз, актуальних для державних установ
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити)
Вступ, Розділ 1 Теоретичні та організаційні основи забезпечення інформаційної безпеки в органах
державної влади, Розділ 2 Аналіз іт-інфраструктури та підготовка департаменту фінансів ЧОДА
до інтеграції Wazuh, Розділ 3 Практична реалізація інтеграції Wazuh у діяльність департаменту
фінансів ЧОДА, Загальні висновки, Список використаних джерел.
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
мультимедійна презентація “ Інтеграція системи моніторингу інформаційної безпеки Wazuh у
діяльність Департаменту фінансів Черкаської обласної державної адміністрації ” – 16 слайдів
(додається до роботи).

6. Консультанти розділів роботи
Підпис, дата
Прізвище, ініціали та посада
Розділ
консультанта завдання видав завдання прийняв

7. Дата видачі завдання __________________

КАЛЕНДАРНИЙ ПЛАН

№ Строк виконання
Назва етапів кваліфікаційної роботи магістра Примітка
з/п етапів роботи
1. Пошук і аналіз інформації по заданій темі 15.09.2025-
30.09.2025
2. Написан ня І розділу “ Теоретичні та організаційні 01.10.2025-
основи забезпечення інформаційної безпеки в 19.10.2025
органах державної влади”
3. Написан ня ІІ розділу роботи “ Аналіз ІТ- 20.10.2025-
інфраструктури та підготовка Департаменту 07.11.2025
фінансів ЧОДА до інтеграції Wazuh”
4. Написан ня ІІI розділу роботи “Практична реалізація 08.11.2025-
інтеграції Wazuh у діяльність Департаменту 24.11.2025
фінансів ЧОДА”
5. Написан ня вступу і висновків, складання списку 25.11.2025
літератури
6. Оформл ення кваліфікаційної роботи магістра 05.12.2025
7. Подання роботи в ЕК 08.12.2025
8. Захист р оботи в ЕК

Студент _____________________Яковлєв Б.В.
(підпис) (прізвище та ініціали)
Керівник роботи ________________Палагін В.В.
(підпис) (прізвище та ініціали)

Зміст

ВСТУП 6
РОЗДІЛ 1. ТЕОРЕТИЧНІ ТА ОРГАНІЗАЦІЙНІ ОСНОВИ ЗАБЕЗПЕЧЕННЯ
ІНФОРМАЦІЙНОЇ БЕЗПЕКИ В ОРГАНАХ ДЕРЖАВНОЇ ВЛАДИ 9
1.1. Концепція інформаційної безпеки та її складові. 9
1.2. Організаційні аспекти захисту інформації в держустановах 10
1.3. Стандарти та нормативно-правові вимоги щодо інформаційної безпеки 12
1.4. Системи моніторингу інформаційної безпеки (SIEM): принципи та
можливості 13
1.5. Огляд та функціональні можливості Wazuh 15
1.6. Аналіз поточного стану інформаційної безпеки Департаменту фінансів
ЧОДА 17
1.7. Виявлення проблем, вразливостей та загроз 18
1.8. Оцінка ризиків та потенційних наслідків для інформаційних активів 19
1.9. Ролі та обов’язки персоналу в контексті впровадження системи
моніторингу 22
1.10. Організаційна структура підрозділу ІТ та кібербезпеки ДФ ЧОДА 23
1.11. Необхідність впровадження системи моніторингу безпеки на базі Wazuh 25
1.12 Висновок до розділу 26
РОЗДІЛ 2. АНАЛІЗ ІТ-ІНФРАСТРУКТУРИ ТА ПІДГОТОВКА
ДЕПАРТАМЕНТУ ФІНАНСІВ ЧОДА ДО ІНТЕГРАЦІЇ WAZUH 28
2.1. Опис інформаційно-телекомунікаційної системи Департаменту та її активів
28
2.2. Аналіз використовуваних засобів захисту та журналювання подій 30
2.3. Оцінка наявного рівня виявлення та реагування на інциденти 32
2.4. Визначення вимог до інтеграції системи Wazuh 34
2.5. Планування архітектури рішення на основі Wazuh 36
2.6. Визначення зон моніторингу та категорій подій 38
2.7. Модель процесів моніторингу та інцидент-менеджменту в структурі ДФ
ЧОДА 41
2.8. Підготовка персоналу та розробка внутрішніх регламентів роботи з Wazuh
43
2.9. Розробка політик безпеки, адаптованих під використання SIEM Wazuh 46
2.10. Визначення критеріїв ефективності впровадження системи моніторингу 48
2.11 Висновки до розділу 50

мБІ041.025.24358.248.ПЗ
Змн. Арк. № докум. Підпис Дата
Розроб. Інтеграція системи моніторингу Літ. Арк. Аркушів
Перевір. Палагін В.В. інформаційної безпеки Wazuh у 4
Реценз. Лавданський А.О діяльність Департаменту
фінансів Черкаської обласної
Н. Контр. Палагін В.В.
державної адміністрації ЧДТУ, мБІ-041
Затверд. Палагін В .В.

РОЗДІЛ 3. ПРАКТИЧНА РЕАЛІЗАЦІЯ ІНТЕГРАЦІЇ WAZUH У
ДІЯЛЬНІСТЬ ДЕПАРТАМЕНТУ ФІНАНСІВ ЧОДА 52
3.1. Проєктування та розгортання інфраструктури Wazuh 52
3.2. Розгортання агентів Wazuh на робочих станціях та серверах 53
3.3. Налаштування модулів безпеки Wazuh 56
3.4. Інтеграція з Active Directory та іншими службами ДФ ЧОДА 59
3.5. Розробка правил кореляції та алертів для державної установи 60
3.6. Побудова дашбордів і звітності щодо інцидентів у Wazuh 63
3.7. Розробка та проведення сценаріїв тестування працездатності системи
(імітація атак) 67
3.8. Аналіз результатів тестування та оцінка ефективності впровадження 71
3.9. Пропозиції щодо покращення системи моніторингу ІБ у ДФ ЧОДА 74
3.10. Напрямки подальшого розвитку системи 76
3.11 Висновки до розділу 77
ЗАГАЛЬНІ ВИСНОВКИ 78
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 80

Арк.
мБІ041.025.24358.248.ПЗ 5
Змн. Арк. № докум. Підпис Дата

ВСТУП

Сучасний світ надзвичайно залежить від інформаційних технологій, що
створює одночасно нові можливості та суттєві виклики для державного сектору.
Органи влади, які забезпечують функціонування ключових адміністративних та
фінансових процесів, усе частіше стають об’єктами кібератак. Зростаючий рівень
кіберзагроз і недостатній рівень централізованого контролю безпеки
інформаційних систем формують критичні ризики для стабільної роботи
державних установ. Кібератаки можуть призвести до викрадення або
компрометації персональних і фінансових даних, порушення функціонування
інформаційних сервісів, зупинки ІТ-інфраструктури чи втрати доступу до
важливих ресурсів.
Особливо гостро ця проблема проявляється в діяльності Департаменту
фінансів Черкаської ОДА, який опрацьовує критичні бюджетні дані та іншу
фінансову інформацію. В умовах сучасних загроз ухвалення ефективних рішень
щодо моніторингу безпеки вимагає впровадження інтегрованих систем, здатних
забезпечити оперативне виявлення атак та аналіз змін у конфігурації систем.
Незважаючи на наявність окремих механізмів захисту, відсутність
централізованого журналювання, кореляції подій, автоматизованого контролю
цілісності (FIM) та конфігурацій (SCA) збільшує середній час виявлення
інцидентів (MTTD), що негативно впливає на рівень безпеки.
Впровадження системи моніторингу безпеки Wazuh дозволяє державним
установам суттєво підвищити зрілість кіберзахисту без додаткових ліцензійних
витрат. Wazuh об’єднує функції HIDS, аналізу вразливостей, FIM, SCA, кореляції
подій та інтеграції з MITRE ATT&CK, забезпечуючи комплексне виявлення та
аналіз підозрілої активності. Використання цього рішення створює технічну
основу для побудови ефективних процесів моніторингу, реагування на інциденти,
ведення журналів безпеки та аудиту змін у системах Департаменту.
Арк.
мБІ041.025.24358.248.ПЗ 6
Змн. Арк. № докум. Підпис Дата

Проблематика даного дослідження полягає у відсутності комплексної
моделі впровадження відкритого XDR/SIEM-рішення Wazuh у державній
фінансовій установі. Зростання масштабів кібератак, спрямованих на органи
влади, актуалізує необхідність розробки таких моделей. Недостатня автоматизація
контролю безпеки, фрагментований моніторинг, обмежена кількість фахівців, а
також високі вимоги до оперативності реагування створюють додаткові труднощі
у забезпеченні належного рівня захищеності.
У межах такої інтеграції у Департаменті фінансів можуть працювати
спеціалісти з інформаційних та мережевих технологій, аналітики безпеки,
адміністратори Wazuh та фахівці з реагування на інциденти, які
забезпечуватимуть безперервний контроль подій безпеки. Такі фахівці
відповідатимуть за розробку та впровадження політик і процедур безпеки,
налаштування правил моніторингу в Wazuh, виявлення та реагування на
потенційні загрози, а також за проведення навчання персоналу.
Метою дослідження є розробка та обґрунтування проєкту інтеграції системи
моніторингу інформаційної безпеки Wazuh для підвищення рівня захищеності
інформаційних ресурсів Департаменту фінансів Черкаської ОДА.
Для досягнення поставленої мети були визначені наступні завдання:
Проаналізувати нормативну базу, сучасні SIEM/XDR-рішення та
обґрунтувати вибір Wazuh.
Провести аудит інфраструктури Департаменту, змоделювати загрози та
розробити архітектуру й оновлену модель процесів моніторингу.
Виконати практичну реалізацію інтеграції, налаштувати ключові модулі
Wazuh та оцінити ефективність впровадження на основі розроблених метрик.
Об’єкт дослідження: Процеси забезпечення інформаційної безпеки в
Департаменті фінансів Черкаської ОДА.
Предмет дослідження: Методи та засоби інтеграції системи моніторингу
безпеки Wazuh в інформаційну інфраструктуру Департаменту.
Арк.
мБІ041.025.24358.248.ПЗ 7
Змн. Арк. № докум. Підпис Дата

Методи дослідження: У роботі використано методи системного аналізу та
синтезу (для огляду нормативної бази та формування архітектури), порівняльного
аналізу (для вибору SIEM-рішення), моделювання (для побудови моделі загроз та
архітектури Wazuh) та експериментальні методи (для тестування ефективності
системи).
Наукова новизна отриманих результатів полягає в адаптації та верифікації
моделі технічної інтеграції системи Wazuh до вимог захисту інформації в
державній установі фінансового профілю.
Практичне значення роботи полягає у створенні готового проєкту
впровадження, що забезпечує зниження MTTD та підвищує загальну зрілість
кіберзахисту Департаменту без додаткових ліцензійних витрат. У сучасних
умовах постійного зростання кіберзагроз впровадження системи централізованого
моніторингу безпеки є ключовим етапом підвищення кіберстійкості державних
органів. Інтеграція Wazuh у діяльність Департаменту фінансів Черкаської ОДА є
важливим кроком у напрямку створення надійної системи кіберзахисту, здатної
оперативно виявляти інциденти, мінімізувати ризики та забезпечувати
безперервність роботи критично важливих процесів.

Арк.
мБІ041.025.24358.248.ПЗ 8
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 1. ТЕОРЕТИЧНІ ТА ОРГАНІЗАЦІЙНІ ОСНОВИ
ЗАБЕЗПЕЧЕННЯ ІНФОРМАЦІЙНОЇ БЕЗПЕКИ В ОРГАНАХ ДЕРЖАВНОЇ
ВЛАДИ

1.1. Концепція інформаційної безпеки та її складові.

Концепція інформаційної безпеки є комплексною системою заходів,
спрямованих на захист інформації від втручання, несанкціонованого доступу,
руйнування, крадіжки або витоку. Основна мета концепції полягає у запобіганні
завданню шкоди інформаційним системам, збереженні конфіденційності,
цілісності та доступності інформації. Схема представлена на Рис.1.1.

Рис.1.1. Складові системи кібербезпеки.

Ключові аспекти концепції інформаційної безпеки включають:
1. Конфіденційність: забезпечення захищеності інформації від
несанкціонованого доступу або розголошення третім сторонам.
Арк.
мБІ041.025.24358.248.ПЗ 9
Змн. Арк. № докум. Підпис Дата

2. Цілісність: забезпечення недоторканності інформації від
несанкціонованої модифікації, втручання або руйнування.
3. Доступність: забезпечення готовності та доступності інформації в
потрібний момент часу.
4. Аутентифікація: встановлення і підтвердження ідентичності користувачів
та систем.
5. Авторизація: визначення та контроль прав доступу користувачів до
різних функцій та даних системи.
6. Захист від втручання: виявлення, усунення та запобігання відмовам у
роботі системи, всіляким атакам та загрозам безпеці інформації.
7. Резервне копіювання: забезпечення створення резервних копій
інформації, щоб мати можливість відновлення даних у разі втрати або
пошкодження. Концепція інформаційної безпеки вимагає комплексного підходу
до захисту інформації, включаючи технічні, організаційні та правові заходи. Вона
також передбачає постійне оновлення заходів безпеки, спрямованих на
запобігання новим загрозам та методам атак. [15]

1.2. Організаційні аспекти захисту інформації в держустановах

Організаційні заходи з інформаційної безпеки – це комплекс внутрішніх
правил, процедур та управлінських рішень, що захищають конфіденційні дані від
несанкціонованого доступу, витоку, пошкодження або втрати. Вони є
фундаментом системи захисту інформації та включають в себе наступні ключові
елементи:
1. Організаційна структура та розподіл обов'язків: Чітко визначена
структура з розподілом відповідальності за інформаційну безпеку. Від керівника,
який визначає політику, до спеціалістів, які контролюють її виконання. Це може
бути комітет з безпеки або уповноважені фахівці, що координують заходи захисту
інформації.
Арк.
мБІ041.025.24358.248.ПЗ 10
Змн. Арк. № докум. Підпис Дата

2. Політика управління інформацією: Формальні правила, що визначають,
які дані є критичними, хто має доступ до них, як вони зберігаються, передаються
та обробляються, а також вимоги до їх захисту. Політика встановлює загальний
порядок роботи з інформацією для всіх співробітників.
3. Навчання персоналу та підвищення обізнаності: Регулярні тренінги та
інструктажі для співробітників щодо актуальних загроз та процедур безпеки. Це
сприяє формуванню культури безпеки, зменшує ризик інцидентів, спричинених
людським фактором, та вчить співробітників правильно реагувати на підозрілі
ситуації.
4.Системи контролю доступу: Обмеження доступу до конфіденційної
інформації лише для тих, кому це необхідно для виконання службових обов'язків.
Це реалізується за допомогою механізмів ідентифікації та автентифікації, таких як
паролі, багатофакторна перевірка, електронні ключі або біометричні дані.
5. Превентивні заходи та засоби захисту: Використання антивірусів,
міжмережевих екранів, шифрування даних, систем контролю активності та інших
інструментів для запобігання атакам та мінімізації їх наслідків.
6. Моніторинг та аудит безпеки: Постійний контроль за станом
інформаційних систем шляхом аналізу мережевої активності, перевірки журналів
доступу та регулярних аудитів. Це дозволяє своєчасно виявляти порушення та
інциденти безпеки, а також оперативно реагувати на них.
7. Резервне копіювання та відновлення даних: Регулярне створення
резервних копій важливої інформації та забезпечення можливості її відновлення у
випадку втрати або пошкодження. Це забезпечує безперервність роботи
організації навіть у разі критичних збоїв.
Всі ці заходи разом створюють багаторівневу систему організаційного
захисту, яка доповнюється технічними та фізичними засобами, забезпечуючи
цілісність, доступність та конфіденційність важливої інформації. [3, 13]

Арк.
мБІ041.025.24358.248.ПЗ 11
Змн. Арк. № докум. Підпис Дата

1.3. Стандарти та нормативно-правові вимоги щодо інформаційної
безпеки

Інформаційна безпека є важливим аспектом у будь-якій організації або
компанії. Існує багато стандартів та рекомендацій, які регулюють питання
безпеки й допомагають захистити інформацію від вторгнень, втрати та
несанкціонованого доступу . Ось деякі з них:
1. ISO/IEC 27001: Цей стандарт встановлює міжнародні вимоги до системи
управління інформаційною безпекою. [6] Він надає фреймворк для розробки й
впровадження ефективних заходів захисту інформації.
2. NIST Cybersecurity Framework: Розроблений національним інститутом
стандартів і технологій США (NIST), цей фреймворк пропонує методику
керування ризиками та рекомендації щодо забезпечення безпеки інформації. [9]
3. GDPR: Загальний регламент про захист даних є європейським
законодавством, яке регулює збір, обробку і передачу персональних даних.
Дотримання цього законодавства вимагає від організацій забезпечити належний
рівень захисту інформації.
4. OWASP Top 10: Національна асоціація безпеки веб-додатків (OWASP)
публікує щорічний список найпоширеніших вразливостей веб-додатків. Цей
список допомагає розробникам виявляти й усувати потенційні загрози.
5. CIS Controls: Ця незалежна організація надає список 20 базових
контрольних точок безпеки, які допомагають організаціям покращити свою
інформаційну безпеку. [10]
Усі ці стандарти та рекомендації можуть бути використані організаціями,
щоб запровадити ефективні заходи захисту інформації та забезпечити безпеку
даних. Найважливіше - обрати стандарт чи рекомендацію, яка відповідає
потребам і особливостям вашої організації .

Арк.
мБІ041.025.24358.248.ПЗ 12
Змн. Арк. № докум. Підпис Дата

1.4. Системи моніторингу інформаційної безпеки (SIEM): принципи та
можливості

В умовах постійного зростання обсягів інформації, що генерується
мережевими пристроями, серверами та прикладним програмним забезпеченням,
ручний аналіз подій безпеки стає неефективним та неможливим. Відповіддю на
цей виклик стала концепція SIEM (Security Information and Event Management), яка
поєднує в собі управління інформацією про безпеку (SIM) та управління подіями
безпеки (SEM). Сучасні системи такого класу являють собою централізовані
платформи, призначені для автоматизованого збору, нормалізації, зберігання та
аналізу логів із різнорідних джерел у масштабі реального часу. Головна мета
впровадження SIEM полягає у забезпеченні повної видимості інфраструктури,
виявленні прихованих загроз та скороченні часу реагування на інциденти.
Детальніше представлено на схема Рис1.2.

Рис 1.2. Схема SIEM архітектури

Функціонування систем моніторингу базується на кількох ключових
принципах. Першим етапом є агрегація даних (Log Aggregation), яка передбачає
збір журналів подій з гетерогенного середовища: операційних систем, мережевого
обладнання, баз даних та засобів захисту. Оскільки різні джерела генерують логи
у несумісних форматах, критично важливим процесом стає нормалізація та
парсинг, що дозволяє привести різнорідні дані до єдиної стандартизованої
структури для подальшої обробки.
Арк.
мБІ041.025.24358.248.ПЗ 13
Змн. Арк. № докум. Підпис Дата

Центральним елементом інтелекту SIEM-систем є кореляція подій (Event
Correlation). Цей механізм дозволяє виявляти складні атаки шляхом аналізу
послідовностей подій, які окремо можуть виглядати легітимними, але у
сукупності вказують на інцидент. Наприклад, система здатна пов’язати
багаторазові невдалі спроби аутентифікації на одному вузлі з подальшим
успішним входом та запуском підозрілого процесу, ідентифікувавши це як єдиний
інцидент безпеки.

Варто зазначити, що сучасний ринок засобів захисту еволюціонує від
класичних SIEM до рішень класу XDR (Extended Detection and Response). На
відміну від традиційного підходу, який спирається переважно на логи, XDR
використовує розширену телеметрію з кінцевих точок, хмарних середовищ та
мережевого трафіку, що значно підвищує точність виявлення загроз і зменшує
кількість помилкових спрацьовувань.
Щодо функціональних можливостей, то сучасні системи моніторингу
забезпечують не лише збір логів, а й вирішення низки критичних завдань:
1. Управління інцидентами: надання інструментарію для класифікації,
пріоритезації та відстеження життєвого циклу інциденту.
2. Забезпечення відповідності (Compliance): автоматична генерація звітів
для підтвердження відповідності вимогам нормативних документів (зокрема НД
ТЗІ, ISO 27001).
3. Моніторинг цілісності (FIM): контроль несанкціонованих змін у файловій
системі та реєстрах, що є критичним для виявлення дій зловмисників.
4. Криміналістичний аналіз: можливість швидкого пошуку в історичних
даних для розслідування причин та наслідків інцидентів.
Комерційні рішення часто є фінансово обтяжливими для державних установ
через вартість ліцензій. У цьому випадку виправданим є використання рішень з
відкритим кодом (Open Source), які пропонують функціонал рівня Enterprise без
Арк.
мБІ041.025.24358.248.ПЗ 14
Змн. Арк. № докум. Підпис Дата

ліцензійних обмежень, що дозволяє адаптувати систему під специфічні потреби
установи без значних витрат.

1.5. Огляд та функціональні можливості Wazuh

Wazuh – це уніфікована платформа безпеки з відкритим вихідним кодом, що
поєднує можливості XDR (Extended Detection and Response) та SIEM (Security
Information and Event Management). Вона виходить за рамки традиційного
моніторингу логів, надаючи комплексний захист для кінцевих точок, хмарних
сервісів та контейнерних середовищ. Завдяки своїй гнучкій архітектурі та
ліцензуванню за GNU GPLv2, Wazuh є економічно привабливим рішенням, що
активно використовується як у державному, так і в комерційному секторах.
Архітектурно Wazuh реалізована за моделлю клієнт-сервер, що складається
з наступних ключових компонентів. На стороні клієнта функціонує Wazuh Agent –
мінімалістичний програмний модуль, призначений для встановлення на сервери
та робочі станції (Windows, Linux, macOS). Агент виконує первинну обробку
даних, моніторинг цілісності файлової системи та збір різноманітної телеметрії,
після чого передає зашифровані дані на центральний сервер. Wazuh Server
виступає центральним вузлом, відповідальним за декодування, нормалізацію та
кореляцію отриманих подій за допомогою попередньо налаштованих правил. Для
ефективного зберігання та пошуку подій застосовується Wazuh Indexer, що
базується на високопродуктивній пошуковій системі OpenSearch. Візуалізація
даних та управління інцидентами здійснюється через веб-інтерфейс Wazuh
Dashboard.
Функціональні можливості Wazuh покривають повний спектр задач
моніторингу та реагування, необхідних для захисту фінансової установи:
1. Аналіз логів та подій безпеки: Система автоматично збирає та аналізує
журнали операційних систем та додатків, виявляючи помилки, спроби
несанкціонованого доступу та порушення політик. Завдяки потужним декодерам,
Арк.
мБІ041.025.24358.248.ПЗ 15
Змн. Арк. № докум. Підпис Дата

Wazuh здатен розпізнавати події від широкого спектру джерел без складної
попередньої конфігурації.
2. Моніторинг цілісності файлів (FIM - File Integrity Monitoring): Один із
критично важливих модулів для фінансового сектору. Він відстежує зміни у
вибраних файлах та директоріях, фіксуючи час модифікації, користувача, який
вніс зміни, та характер змін (створення, видалення, редагування). Це дозволяє
виявляти дії зловмисників, які намагаються змінити конфігураційні файли або
підмінити системні бібліотеки.
3. Виявлення вразливостей (Vulnerability Detection): Агенти Wazuh збирають
інформацію про встановлене програмне забезпечення та версії ОС, порівнюючи їх
із глобальними базами даних вразливостей (CVE - Common Vulnerabilities and
Exposures). Це дозволяє автоматизувати процес інвентаризації "дірок" у безпеці та
пріоритезувати встановлення оновлень.
4. Оцінка конфігурації безпеки (SCA - Security Configuration Assessment):
Модуль проводить сканування систем на відповідність стандартам безпеки
(наприклад, CIS Benchmarks), виявляючи слабкі налаштування, такі як відсутність
політики паролів, відкриті непотрібні порти або запущені небезпечні служби.
5. Активне реагування (Active Response): Wazuh дозволяє не лише виявляти
загрози, а й автоматично реагувати на них. Наприклад, при виявленні Brute-Force
атаки система може автоматично додати IP-адресу нападника у блок-лист
брандмауера, зупинивши атаку за лічені секунди.
Важливою перевагою платформи є нативна інтеграція з фреймворком
MITRE ATT&CK, що дозволяє класифікувати виявлені загрози відповідно до
тактик і технік зловмисників [8]. Крім того, Wazuh забезпечує відповідність
нормативним вимогам (Regulatory Compliance), надаючи готові шаблони звітів
для стандартів PCI DSS, GDPR, NIST, що значно спрощує проходження аудитів
інформаційної безпеки. Така сукупність функцій робить Wazuh оптимальним
інструментом для побудови центру моніторингу безпеки (SOC) в умовах
обмеженого бюджету та високих вимог до надійності.
Арк.
мБІ041.025.24358.248.ПЗ 16
Змн. Арк. № докум. Підпис Дата

1.6. Аналіз поточного стану інформаційної безпеки Департаменту
фінансів ЧОДА

Процес аналізу поточної ситуації з інформаційною безпекою в державній
адміністрації складається з кількох етапів Рис 1.3. Перш за все, проводиться
оцінка рівня захищеності інформаційних ресурсів та систем. Це означає перевірку
механізмів контролю доступу (аутентифікація та авторизація), надійності
резервного копіювання та відновлення даних, а також ефективності захисту від
випадкового чи навмисного знищення або модифікації інформації. Далі йде етап
виявлення потенційних загроз та вразливостей. Він передбачає дослідження
зовнішнього середовища для ідентифікації можливих каналів проникнення
сторонніх осіб до інформаційних систем. Також аналізуються вже впроваджені
заходи безпеки для виявлення їхніх недоліків.

Рис.1.3. Стан інформаційної безпеки

На основі отриманих даних розробляється стратегія захисту, яка включає
визначення пріоритетів для різних типів інформації, формування чітких правил та
процедур роботи з інформаційними ресурсами, а також вибір відповідних
технологічних рішень. Результати цього аналізу дозволяють виявити проблемні
Арк.
мБІ041.025.24358.248.ПЗ 17
Змн. Арк. № докум. Підпис Дата

зони та вразливі місця, які потребують негайного реагування, і є фундаментом для
покращення загальної системи інформаційної безпеки та захисту державних
ресурсів.

1.7. Виявлення проблем, вразливостей та загроз

Проведений аналіз поточної архітектури безпеки Департаменту фінансів
дозволив ідентифікувати низку критичних вразливостей, які в умовах зростання
кіберзагроз можуть призвести до порушення конфіденційності або доступності
фінансових даних. На відміну від загальних проблем ІТ-безпеки, специфіка
державної установи вимагає врахування як технічних, так і організаційних
векторів атак.
Основними ідентифікованими проблемами є:
1. Фрагментарність моніторингу (Відсутність SIEM). Найголовнішою
технічною проблемою є відсутність єдиної точки збору та аналізу подій безпеки.
Логи генеруються окремо на рівні серверів, мережевих екранів та робочих
станцій, але не корелюються між собою. Це створює «сліпі зони», де складні
багатовекторні атаки залишаються непоміченими до моменту настання критичних
наслідків.
2. Відсутність автоматизованого контролю цілісності (FIM). В
інфраструктурі не реалізовано механізм відстеження змін у критичних системних
файлах та реєстрах. Це означає, що несанкціонована модифікація конфігурації або
підміна системних бібліотек шкідливим ПЗ може залишатися невиявленою
тривалий час.
3. Некеровані вразливості ПЗ (Patch Management). Відсутність інструментів
для автоматизованої інвентаризації програмного забезпечення (SCA) ускладнює
процес виявлення застарілих версій ПЗ, що містять відомі вразливості (CVE).
4. Людський фактор та соціальна інженерія. Специфіка роботи фінансового
департаменту передбачає активну взаємодію із зовнішніми кореспондентами, що
Арк.
мБІ041.025.24358.248.ПЗ 18
Змн. Арк. № докум. Підпис Дата

підвищує ризик цільового фішингу. Без технічних засобів аналізу поведінки
користувачів важко виявити компрометацію облікового запису на ранніх стадіях.
Необхідність системного підходу до захисту підтверджується і в науковій
літературі. Зокрема, дослідники Д. С. Бірюков та С. І. Кондратов у своїх працях
наголошують, що захист об'єктів критичної інфраструктури не може
обмежуватися лише реактивними заходами. Вони аргументують необхідність
переходу до стратегічного планування, яке включає:
• секторальну ідентифікацію специфічних ризиків, притаманних
конкретній галузі;
• попереджувальну оцінку вразливостей інфраструктури до початку
реальних атак;
• впровадження превентивних механізмів захисту на основі постійного
аналізу загроз. [4]
Застосовуючи цей науковий підхід до реалій Департаменту фінансів, стає
очевидним, що просте встановлення антивірусів є недостатнім. Для реалізації
стратегії попереджувального захисту необхідне впровадження комплексної
платформи моніторингу, такої як Wazuh. Саме вона здатна технічно реалізувати
рекомендації науковців: забезпечити ідентифікацію ризиків у реальному часі,
оцінку вразливостей через модуль Vulnerability Detector та централізоване
управління інцидентами.

1.8. Оцінка ризиків та потенційних наслідків для інформаційних
активів

Оцінка ризиків є фундаментальним етапом у побудові системи захисту
інформації державних установ. Для Департаменту фінансів цей процес полягає у
систематичному виявленні потенційних загроз, аналізі вразливостей
інформаційної системи та прогнозуванні можливих наслідків (Impact Analysis) від
реалізації цих загроз. [9]
Арк.
мБІ041.025.24358.248.ПЗ 19
Змн. Арк. № докум. Підпис Дата

В контексті діяльності фінансової установи, ризики можна класифікувати за
трьома основними напрямками:
1. Технологічні ризики: Пов'язані з вразливостями програмного
забезпечення, відсутністю оновлень, слабкою конфігурацією серверів та
мережевого обладнання. Саме ці вразливості найчастіше стають вектором для
зовнішніх атак.
2. Фізичні ризики: Загрози безпосереднього доступу до серверних
приміщень, крадіжка носіїв інформації, збої в системах електроживлення або
пошкодження комунікацій.
3. Соціальні та кадрові ризики: Включають цільовий фішинг, соціальну
інженерію, інсайдерські загрози (навмисні дії співробітників) або помилки
персоналу через недостатню кваліфікацію.
Наслідки реалізації цих ризиків для Департаменту можуть бути
критичними: від порушення конфіденційності бюджетних даних та персональної
інформації громадян до повної зупинки роботи інформаційно-телекомунікаційної
системи (доступність), що призведе до блокування фінансових операцій регіону.
Ефективна модель управління ризиками повинна бути циклічною та
інтегрованою в загальну стратегію кібербезпеки. Вона базується на постійному
моніторингу індикаторів компрометації (IoC) та аналізі поведінкових аномалій.
Для візуалізації цього процесу та його інтеграції з системою моніторингу
пропонується наступний алгоритм управління ризиками.
Далі представлена схема моделі управління ризиками Рис.1.4.
Арк.
мБІ041.025.24358.248.ПЗ 20
Змн. Арк. № докум. Підпис Дата

Рис.1.4. Циклічна модель управління ризиками інформаційної безпеки.

Як видно зі схеми, ключовим елементом мінімізації ризиків є впровадження
технічних засобів контролю. Інтеграція системи Wazuh дозволяє автоматизувати
етапи ідентифікації (через інвентаризацію та сканування вразливостей) та
моніторингу, перетворюючи управління ризиками з теоретичної процедури на
дієвий технічний процес. Це забезпечує перехід від реактивного усунення
наслідків до проактивного виявлення загроз на ранніх стадіях.

Арк.
мБІ041.025.24358.248.ПЗ 21
Змн. Арк. № докум. Підпис Дата

1.9. Ролі та обов’язки персоналу в контексті впровадження системи
моніторингу

Успішна інтеграція системи моніторингу Wazuh вимагає чіткого
перерозподілу відповідальності серед наявного ІТ-персоналу, оскільки у
Департаменті фінансів, як у більшості державних установ, відсутній окремий
штатний підрозділ SOC (Security Operations Center). Впровадження інструментів
XDR/SIEM кардинально змінює характер роботи, переводячи ІТ-підрозділ від
реактивного усунення наслідків до проактивного виявлення загроз.
Перегляд функціональних обов'язків фокусується на трьох ключових ролях:
1. Керівник ІТ-підрозділу (або особа, відповідальна за ІБ): На цю посадову
особу покладається стратегічна функція прийняття рішень про реагування та
контроль за загальною зрілістю кібербезпеки. Після інтеграції Wazuh, керівник
забезпечує моніторинг дашбордів високого рівня, які відображають ключові
метрики (KPI) та загальну ситуацію з безпекою. Він відповідає за затвердження та
актуалізацію процедур інцидент-менеджменту, забезпечуючи, що всі виявлені
системою Wazuh інциденти отримують належну пріоритезацію та
документування.
2. Системний адміністратор (Оператор системи Wazuh): Системний
адміністратор, який традиційно займається обслуговуванням інфраструктури, стає
ключовим оператором системи моніторингу. Його обов'язки розширюються за
рахунок технічного супроводу сервера Wazuh Manager, розгортання та оновлення
агентів на всіх кінцевих точках Департаменту. Найважливішою функцією стає
оперативне реагування на критичні сповіщення (Alerts): аналіз спрацювань FIM,
виявлення Brute-Force атак та аномальної активності. Адміністратор повинен
регулярно переглядати Wazuh Dashboard для моніторингу вразливостей
(Vulnerability Detector) та контролю конфігурацій (SCA), забезпечуючи тим самим
перехід до проактивної моделі захисту.
Арк.
мБІ041.025.24358.248.ПЗ 22
Змн. Арк. № докум. Підпис Дата

3. Користувачі та Адміністратори кінцевих точок: Незважаючи на
відсутність прямих функцій моніторингу, їхня роль є критичною для успіху
системи. Кожен користувач зобов’язаний суворо дотримуватися нових
регламентів безпеки, особливо щодо використання фінансових систем. Вони
мають бути навчені процедурам негайного інформування ІТ-підрозділу про
підозрілу активність або збої. У разі виявлення інциденту, користувачі зобов'язані
співпрацювати з адміністратором, надаючи доступ для збору криміналістичних
даних, які можуть бути відсутні у логах Wazuh.

1.10. Організаційна структура підрозділу ІТ та кібербезпеки ДФ ЧОДА

Забезпечення кіберстійкості Департаменту фінансів Черкаської ОДА
реалізується в рамках існуючої організаційної структури, де функції захисту
інформації та підтримки ІТ-інфраструктури об'єднані в єдиний структурний
підрозділ - Відділ інформаційних технологій, кібербезпеки та захисту інформації.
Така централізація є характерною для державних установ регіонального рівня та
дозволяє ефективно використовувати наявні кадрові ресурси.
Згідно з положенням про відділ, його організаційна структура побудована за
лінійно-функціональним принципом. Це забезпечує чітку вертикаль
підпорядкування та розмежування зон відповідальності, що є критично важливим
при реагуванні на інциденти безпеки що зображено на Рис.1.5.
В контексті впровадження системи моніторингу Wazuh, штатний розпис
відділу та розподіл функціональних обов'язків виглядає наступним чином:
1. Начальник відділу. Здійснює загальне керівництво, стратегічне
планування розвитку ІТ-інфраструктури та контроль за дотриманням політик
безпеки. У системі моніторингу він виступає отримувачем звітів високого рівня та
приймає рішення щодо блокування критичних процесів або ескалації інцидентів
на рівень керівництва Департаменту.
Арк.
мБІ041.025.24358.248.ПЗ 23
Змн. Арк. № докум. Підпис Дата

2. Головний спеціаліст з кібербезпеки (Адміністратор безпеки). Це ключова
технічна роль у новій моделі захисту. На цього фахівця покладаються обов'язки
оператора системи Wazuh: розгортання сервера, написання правил кореляції,
моніторинг дашбордів у реальному часі та розслідування інцидентів.
3. Головний спеціаліст із супроводження баз даних. Відповідає за цілісність
та доступність фінансових баз даних (ІПК «Місцевий бюджет», ПК «ГРК»). Його
роль у системі моніторингу полягає у контролі логів доступу до БД та реагуванні
на спроби несанкціонованих SQL-запитів або витоку даних.
4. Головний спеціаліст із технічної підтримки. Забезпечує працездатність
робочих станцій та периферійного обладнання. Він відповідає за коректну роботу
агентів Wazuh на комп'ютерах користувачів та первинну діагностику проблем
безпеки на рівні кінцевих точок.
Така структура дозволяє забезпечити повний цикл управління інцидентами
від виявлення (Спеціаліст з кібербезпеки) до локалізації на рівні мережі або
робочої станції (Технічні спеціалісти) під контролем керівника.

Рис.1.5 Адаптована схема організаційної структури підрозділу
Арк.
мБІ041.025.24358.248.ПЗ 24
Змн. Арк. № докум. Підпис Дата

Впровадження системи Wazuh не потребує зміни штатного розпису, але
наповнює роботу існуючих спеціалістів новим змістом, перетворюючи їх з
технічного персоналу на команду реагування на інциденти (CSIRT - Computer
Security Incident Response Team) локального рівня.

1.11. Необхідність впровадження системи моніторингу безпеки на базі
Wazuh

В умовах цифрової трансформації державного сектору, створення надійної
системи кіберзахисту є не просто технічним завданням, а стратегічною
необхідністю. Як зазначається у роботі [1] (посилання на Буркота або подібне
джерело), базова інфраструктура кіберзахисту базується на забезпеченні тріади
інформаційної безпеки: конфіденційності, цілісності та доступності. Досягнення
цього стану в сучасних умовах неможливе без автоматизованих засобів контролю.
Необхідність інтеграції системи моніторингу Wazuh у діяльність
Департаменту фінансів зумовлена наступними факторами:
1. Забезпечення безперервності моніторингу. Людський ресурс обмежений:
системний адміністратор не може аналізувати логи 24/7. Впровадження Wazuh
дозволяє автоматизувати цей процес, забезпечуючи постійне спостереження за
інформаційною системою та миттєве сповіщення про інциденти незалежно від
часу доби.
2. Виконання вимог законодавства. Згідно з нормативними документами у
сфері ТЗІ, державні установи зобов'язані вести облік подій безпеки та
контролювати цілісність критичних даних. Wazuh технічно реалізує ці вимоги
через модулі Security Configuration Assessment (SCA) та File Integrity Monitoring
(FIM), надаючи доказову базу (аудит) у разі перевірок.
3. Мінімізація часу реагування (MTTD/MTTR). Ручний пошук причин збою
чи атаки може займати години або дні. Завдяки механізмам кореляції подій та
інтеграції з базою знань MITRE ATT&CK, Wazuh дозволяє скоротити час
Арк.
мБІ041.025.24358.248.ПЗ 25
Змн. Арк. № докум. Підпис Дата

виявлення та локалізації загрози до хвилин, що критично важливо для збереження
фінансових даних.
4. Економічна ефективність. Створення повноцінного підрозділу
кібербезпеки (SOC) вимагає значних бюджетних витрат на штат та комерційне
ПЗ. Використання Open Source рішення Wazuh дозволяє отримати функціонал
рівня Enterprise без ліцензійних відрахувань, що є оптимальним для бюджетної
установи.
У всиновку впровадження Wazuh є не лише технічним оновленням, а й
організаційно-управлінським рішенням, яке трансформує підхід до безпеки від
фрагментарного захисту до централізованої керованої системи. Це дозволяє
Департаменту перейти на якісно новий рівень зрілості кіберзахисту, забезпечуючи
захищеність критичної інфраструктури від сучасних векторів атак.

1.12 Висновок до розділу

У розділі було виконано теоретичний аналіз кіберзахисту в дуржавному
секторі та обґрунтовано вибір інструментів.
Основні підсумки:
Актуальність та нормативна база: Встановлено, що державні установи
потребують комплексного підходу до захисту інформації, який базується на
забезпеченні конфіденційності, цілісності та доступності даних. Також аналіз
нормативної бази (НД ТЗІ, ISO 27001) підтвердив необхідність впровадження
систем аудиту та моніторингу подій.
Проблема фрагментарності: Аналізом поточного стану Департаменту
фінансів виявивлено відсутність централізованого моніторингу. Існуючі засоби
захисту працюють ізольовано, що унеможливлює кореляцію подій та збільшує час
виявлення інцидентів .
Вибір рішення: Обґрунтовано доцільність використання платформи Wazuh.
Як рішення з відкритим кодом (Open Source) воно дозволяє реалізувати
Арк.
мБІ041.025.24358.248.ПЗ 26
Змн. Арк. № докум. Підпис Дата

функціонал рівня Enterprise (SIEM, XDR, FIM) без витрат на ліцензії, що
критично важливим для бюджетної установи.
Організаційні зміни: Визначено необхідність адаптації організаційної
структури ІТ-підрозділу, де системний адміністратор набуває функцій оператора
безпеки, переходячи від реактивного усунення збоїв до проактивного виявлення
загроз

Арк.
мБІ041.025.24358.248.ПЗ 27
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 2. АНАЛІЗ ІТ-ІНФРАСТРУКТУРИ ТА ПІДГОТОВКА
ДЕПАРТАМЕНТУ ФІНАНСІВ ЧОДА ДО ІНТЕГРАЦІЇ WAZUH

2.1. Опис інформаційно-телекомунікаційної системи Департаменту та її
активів

Інформаційно-телекомунікаційна система (ІТС) Департаменту фінансів
Черкаської ОДА є гетерогенною інфраструктурою, побудованою за принципом
ешелонованого захисту та розподілу навантаження. Архітектура системи
спроєктована з урахуванням вимог до безперервності бюджетного процесу та
захисту критичних даних.
Мережева інфраструктура та сегментація:
Мережа Департаменту має високий рівень відмовостійкості завдяки
використанню двох незалежних каналів зв'язку. Доступ до глобальної мережі
Інтернет забезпечують провайдери Kyivstar та Ukrtelecom, що дозволяє
організувати балансування навантаження та резервування каналів у разі аварії
одного з постачальників послуг.
Ключовою особливістю архітектури є фізичне та логічне розділення мережі
на два контури безпеки, кожен з яких захищається окремим шлюзом:
1. Контур серверної інфраструктури та VoIP. Захист цього критичного
сегмента забезпечує апаратний міжмережевий екран Fortinet. Він контролює
вхідний та вихідний трафік серверів, забезпечує роботу захищених VPN-каналів
для зв'язку з казначейством та обробляє трафік IP-телефонії.
2. Контур користувачів та бездротової мережі. Робочі станції співробітників
та Wi-Fi мережа підключені через програмний маршрутизатор на базі PfSense,
посилений модулем Zenarmor (Next Generation Firewall). Це рішення забезпечує
глибоку інспекцію трафіку (DPI), фільтрацію небажаного контенту та захист від
веб-загроз на рівні додатків.

Арк.
мБІ041.025.24358.248.ПЗ 28
Змн. Арк. № докум. Підпис Дата

Інвентаризація активів (Asset Inventory):
Для подальшого розгортання системи моніторингу Wazuh проведено
класифікацію активів ІТС.
1. Мережеве обладнання (Точки збору мережевих подій):
• Fortinet: Основне джерело подій про атаки на сервери, спроби
несанкціонованого доступу ззовні та статус VPN-тунелів.
• PfSense + Zenarmor: Джерело даних про активність користувачів,
відвідані веб-ресурси, блокування шкідливого ПЗ та спроби
вторгнення через Wi-Fi.
2. Серверне забезпечення: Серверний парк працює під управлінням ОС
Windows Server (версії 2019/2022) та Linux. До критичних активів належать:
• Сервер баз даних (MS SQL): Забезпечує роботу ІПК «Місцевий
бюджет».
• Контролер домену (Active Directory): Відповідає за централізовану
автентифікацію користувачів та групові політики.
• Файловий сервер: Використовується для обміну службовою
документацією.
3. Клієнтські робочі місця: Парк налічує близько 50 робочих станцій під
управлінням ОС Windows 10/11 Pro. Вони знаходяться в зоні відповідальності
шлюзу Zenarmor, проте потребують додаткового моніторингу на рівні хоста
(HIDS) для контролю запуску процесів та цілісності реєстру.
4. Прикладне програмне забезпечення: Окрім стандартного офісного пакету,
в системі функціонує спеціалізоване ПЗ: ІПК «Місцевий бюджет»;
Структурна схема мережі
Графічне відображення топології мережі з розподілом на зони
відповідальності шлюзів безпеки наведено на Рис.2.1.
Арк.
мБІ041.025.24358.248.ПЗ 29
Змн. Арк. № докум. Підпис Дата

Рис.2.1. Структурна схема інформаційно-телекомунікаційної системи
Департаменту фінансів.
Така архітектура забезпечує високий рівень ізоляції критичних ресурсів.
Сервери фінансових баз даних відокремлені від прямого доступу з користувацької
мережі та Інтернету за допомогою Fortinet, тоді як робочі станції, що мають
вищий ризик зараження через веб-серфінг, захищені окремим контуром на базі
Zenarmor. Інтеграція Wazuh дозволить об'єднати події з обох контурів у єдину
картину безпеки.

2.2. Аналіз використовуваних засобів захисту та журналювання подій

Оцінка поточного стану інформаційної безпеки Департаменту фінансів
базується на аналізі реалізованих механізмів захисту на трьох ключових рівнях:
мережевий периметр, кінцеві точки та моніторинг подій.
Захист зовнішнього периметра мережі організовано за принципом глибокої
інспекції трафіку. Основним бар'єром для серверного сегмента виступає
апаратний шлюз Fortinet FortiGate, який забезпечує фільтрацію вхідних та
Арк.
мБІ041.025.24358.248.ПЗ 30
Змн. Арк. № докум. Підпис Дата

вихідних з'єднань, функціонування системи запобігання вторгненням (IPS) та
підтримку захищених VPN-каналів. Для захисту користувацького сегмента
застосовується програмний маршрутизатор PfSense з інтегрованим модулем
Zenarmor (NGFW). Це дозволяє здійснювати контроль на рівні додатків (L7),
блокувати доступ до потенційно небезпечних веб-ресурсів та аналізувати трафік
на наявність шкідливого коду.
На рівні кінцевих точок (робочих станцій та серверів під управлінням ОС
Windows) основним засобом захисту від шкідливого програмного забезпечення
виступає вбудоване рішення Microsoft Defender Antivirus. У поточній конфігурації
воно забезпечує базовий сигнатурний аналіз та захист у реальному часі.
Управління налаштуваннями антивірусу частково централізоване через групові
політики (GPO) служби каталогу Active Directory, що дозволяє запобігти
несанкціонованому відключенню захисту користувачами. Стратегією розвитку ІТ-
інфраструктури передбачено перехід на Microsoft Defender for Business, який
надасть розширені можливості EDR (Endpoint Detection and Response), проте на
даному етапі відсутність єдиної консолі управління ускладнює оперативне
виявлення інцидентів на окремих хостах.
Критичним недоліком існуючої системи захисту є децентралізований підхід
до журналювання подій (Log Management). На момент проведення аудиту в
Департаменті відсутня єдина система збору та зберігання логів. Журнали подій
операційних систем Windows (Security, System, Application), служби Active
Directory та СУБД MS SQL Server зберігаються локально на кожному пристрої.
Це створює ризик втрати доказової бази у разі виходу обладнання з ладу або
навмисного очищення журналів зловмисником. Аналогічна ситуація
спостерігається і з мережевим обладнанням (Fortinet, PfSense), де термін
зберігання логів обмежений обсягом локальних накопичувачів.
Така фрагментарність даних унеможливлює кореляцію подій між різними
сегментами мережі. Наприклад, спроба підбору пароля до облікового запису
користувача (зафіксована контролером домену) та подальша підозріла мережева
Арк.
мБІ041.025.24358.248.ПЗ 31
Змн. Арк. № докум. Підпис Дата

активність цього ж користувача (зафіксована Zenarmor) розглядаються як дві
непов'язані події. Впровадження системи моніторингу Wazuh дозволить вирішити
цю проблему шляхом агрегації різнорідних логів у єдиному сховищі, що
забезпечить цілісну картину стану інформаційної безпеки та компенсує
відсутність спеціалізованих EDR-рішень на поточному етапі розвитку
інфраструктури.

2.3. Оцінка наявного рівня виявлення та реагування на інциденти

Ефективність системи захисту інформації визначається не лише наявністю
технічних засобів, але й здатністю персоналу оперативно виявляти загрози та
локалізувати їх наслідки. Для об’єктивної оцінки поточного стану кібербезпеки
Департаменту фінансів було проведено аналіз процесів інцидент-менеджменту з
використанням ключових часових метрик: середнього часу виявлення (MTTD -
Mean Time To Detect) та середнього часу реагування (MTTR - Mean Time To
Respond).
Оцінка базувалася на моделюванні типових сценаріїв атак, характерних для
фінансових установ, з урахуванням архітектурних особливостей, описаних у
попередніх підрозділах. Результати моделювання (Таблиця.2.1) демонструють
залежність швидкості реакції від наявних інструментів моніторингу.

Таблиця.2.1 Оцінка часових метрик обробки інцидентів (стан «As-Is»)
Сценарій інциденту Механізм виявлення Оцінка MTTD Оцінка MTTR
Brute-force атака на Скарги користувачів на блоку- Високий (4–24 го- Середній (1–2
RDP/VPN вання облікового запису або дини) години)
випадковий перегляд логів.
Зараження шкідли- Спрацювання локального ан- Середній (зале- Високий (від 24
вим ПЗ тивірусу на робочій станції. жить від оновлен- годин)
(Ransomware) ня баз)
Несанкціонована Виявлення лише після збою в Критичний (тиж- Високий (відно-
зміна конфігурацій роботі сервісу або системи. ні/місяці) влення з бекапу)

Арк.
мБІ041.025.24358.248.ПЗ 32
Змн. Арк. № докум. Підпис Дата

Аналіз наведених даних свідчить про те, що поточний рівень зрілості
процесів реагування можна класифікувати як «Початковий» (Initial). Основною
проблемою є реактивний характер дій персоналу: адміністратор дізнається про
інцидент вже після того, як він завдав шкоди або вплинув на працездатність
систем. Це зумовлено відсутністю автоматизованої кореляції подій, коли
розрізнені сигнали тривоги від Fortinet, Defender та Active Directory не
об’єднуються в єдиний ланцюжок атаки.
Особливе занепокоєння викликає показник MTTD для інцидентів,
пов'язаних із внутрішніми загрозами та зміною цілісності файлів. Через
відсутність спеціалізованих засобів контролю (FIM), такі зміни залишаються
непоміченими протягом тривалого часу, що створює вікно можливостей для
зловмисників. Скорочення цього розриву між моментом проникнення та
моментом виявлення є ключовим завданням інтеграції системи Wazuh, яка
дозволить трансформувати процес моніторингу з ручного режиму в
автоматизований, забезпечуючи сповіщення в режимі реального часу. Наглядно
зображено на Рис.2.2.

Рис.2.2 Порівняння життєвого циклу виявлення інциденту до та після
впровадження системи моніторингу.
Арк.
мБІ041.025.24358.248.ПЗ 33
Змн. Арк. № докум. Підпис Дата

2.4. Визначення вимог до інтеграції системи Wazuh

Визначення вимог до інтеграції системи моніторингу Wazuh здійснюється
на основі аудиту інформаційної безпеки (п. 2.2, 2.3) та нормативно-правових актів
у сфері захисту інформації в органах державної влади. Інтеграція має забезпечити
не лише збір даних, а й перетворення розрізнених подій на єдиний, дієвий
механізм виявлення та реагування.
Вимоги до проєкту розділяються на функціональні (що система повинна
робити), нефункціональні (як система повинна працювати) та вимоги до інтеграції
(як система взаємодіятиме з існуючою ІТС).
Функціональні вимоги до Wazuh спрямовані на усунення критичних
прогалин, виявлених у процесі оцінки MTTD:
• Централізований збір логів та кореляція подій (Log Data Collection and
Correlation): Система повинна забезпечувати збір, нормалізацію та
зберігання логів у режимі реального часу від усіх критичних джерел:
• Операційні системи: Журнали подій Windows (Security, System, Application)
з усіх робочих станцій та серверів.
• Active Directory: Аудит входу/виходу, зміни в облікових записах та
групових політиках (GPO).
• Мережеве обладнання: Логи Fortinet та PfSense/Zenarmor для виявлення
мережевих вторгнень та підозрілої активності.
• Критичне ПЗ: Аудит доступу та транзакцій у СУБД MS SQL Server та
спеціалізованих ІПК («Місцевий бюджет»).
• Моніторинг цілісності файлів (File Integrity Monitoring, FIM): Реалізація
FIM-модуля для контролю цілісності файлових ресурсів з високим рівнем
конфіденційності. Основними об’єктами моніторингу є:
o Системні папки серверів (для виявлення руткітів та зловмисних змін).
o Папки з ключовими файлами ІПК «Місцевий бюджет».
Арк.
мБІ041.025.24358.248.ПЗ 34
Змн. Арк. № докум. Підпис Дата

o Папки з налаштуваннями критичних сервісів.
• Оцінка конфігурації та виявлення вразливостей (SCA/Vulnerability
Detection): Wazuh повинен регулярно сканувати кінцеві точки для:
• Виявлення програмних вразливостей (CVE) на робочих станціях та
серверах.
• Оцінки відповідності конфігурацій (SCA) вимогам безпеки (наприклад,
політикам CIS Benchmarks для Windows/Linux).
• Активне реагування (Active Response): Система повинна підтримувати
механізми автоматичного реагування на критичні інциденти, наприклад:
• Блокування IP-адреси-джерела атаки на мережевому екрані (через API
Fortinet/PfSense) після виявлення Brute-force.
• Ізоляція скомпрометованої робочої станції (видалення мережевих
маршрутів) у випадку виявлення Ransomware.
Нефункціональні вимоги. Ці вимоги стосуються ефективності та надійності
самої платформи Wazuh:
• Продуктивність та масштабованість: Система повинна забезпечувати
обробку не менше 500 подій на секунду (EPS) із запасом на майбутнє
зростання інфраструктури (до 20%).
• Надійність: Wazuh Server та інфраструктура зберігання логів повинні
мати механізми відмовостійкості (наприклад, кластеризація або
резервування).
Відповідність нормативній базі: Функціонал системи має відповідати
вимогам нормативно-правових актів України щодо технічного захисту інформації,
зокрема, у частині аудиту та контролю доступу.
Вимоги до інтеграції:
• Успішна інтеграція Wazuh безпосередньо залежить від його взаємодії
з існуючими компонентами ІТС:
Арк.
мБІ041.025.24358.248.ПЗ 35
Змн. Арк. № докум. Підпис Дата

• Інтеграція з Active Directory: Використання GPO для масового
розгортання та оновлення агентів Wazuh на клієнтських машинах.
• Підтримка LDAP/S для аутентифікації користувачів у веб-інтерфейсі
Wazuh, що забезпечує централізоване управління доступом.
• Інтеграція з мережевим обладнанням:
• Підтримка протоколу Syslog для збору логів з Fortinet та
PfSense/Zenarmor.
• Можливість взаємодії через API для реалізації функцій активного
реагування (наприклад, додавання правил до чорного списку IP-адрес
на Fortinet).
Інтеграція зі СУБД MS SQL: Налаштування агентів Wazuh для моніторингу
журналів аудиту SQL Server, що фіксують спроби несанкціонованого доступу до
фінансових баз даних.
Визначені вимоги стануть основою для розробки архітектури рішення та
детального плану розгортання системи Wazuh у наступних підрозділах.

2.5. Планування архітектури рішення на основі Wazuh

Розробка логічної та фізичної архітектури системи моніторингу Wazuh є
критичним етапом, який конвертує функціональні вимоги (п. 2.4) у конкретну
інженерну схему. Враховуючи особливості ІТС Департаменту фінансів - наявність
високозахищеного серверного сегмента та обмеженість апаратних ресурсів - було
обрано розподілену модель розгортання (Distributed Deployment Model) на базі
єдиної віртуальної машини (ВМ) для центральних компонентів.
Основні логічні компоненти системи - Wazuh Manager (ядро кореляції та
управління), Wazuh Indexer (база даних для індексації та зберігання логів) та
Wazuh Dashboard (інтерфейс візуалізації) - будуть встановлені на цій ВМ.
Розміщення всіх критичних елементів здійснюється виключно у Серверному
Арк.
мБІ041.025.24358.248.ПЗ 36
Змн. Арк. № докум. Підпис Дата

сегменті, що знаходиться за апаратним міжмережевим екраном Fortinet. Це
забезпечує максимальну ізоляцію системи моніторингу від потенційних загроз із
користувацької мережі та інтернету.
Проведено розрахунок ресурсів, з урахуванням 50 робочих станцій, 5
критичних серверів та очікуваного пікового обсягу логів (близько 500-1000 подій
на секунду), визначив мінімальні вимоги до ВМ: 4-6 vCPUs та мінімум 16 GB
оперативної пам'яті (з резервуванням 10 GB під Indexer для ефективної обробки
пошукових запитів). Для забезпечення необхідної глибини зберігання логів
(рекомендовано 60 днів) виділяється близько 500 GB дискового простору,
причому обов'язково на SSD-накопичувачах для високої швидкості індексації.
Розроблена логічна архітектура зображена на Рис2.3 визначає двосторонній
потік даних. З одного боку, Wazuh Agents, розгорнуті на всіх робочих станціях (за
PfSense) та серверах, передають дані (телеметрію, FIM-звіти, журнали подій) на
Wazuh Manager по зашифрованому каналу TCP/1514. З іншого боку, мережеве
обладнання - Fortinet та PfSense/Zenarmor - налаштовується на відправку копій
своїх системних логів через протокол Syslog (UDP/514) безпосередньо на Wazuh
Manager. Таким чином, менеджер виконує функцію централізованого хабу, який
збирає інформацію як із рівня хоста, так і з мережевого периметра, забезпечуючи
повноцінну картину безпеки. Доступ до Wazuh Dashboard надається оператору
(спеціалісту з кібербезпеки) через внутрішню мережу по захищеному HTTPS-
з'єднанню.
Арк.
мБІ041.025.24358.248.ПЗ 37
Змн. Арк. № докум. Підпис Дата

Рис.2.3 Логічна архітектура інтеграції системи моніторингу Wazuh у
Департаменті фінансів.

Така архітектура дозволяє задовольнити функціональні вимоги до
централізованої кореляції та забезпечує основу для впровадження модулів
активного реагування, які будуть взаємодіяти з Fortinet та PfSense для
автоматичного блокування виявлених загроз.

2.6. Визначення зон моніторингу та категорій подій

Ефективність системи SIEM залежить від чіткого визначення об'єктів
спостереження та критеріїв, за якими ідентифікуються інциденти. На основі
проведеного аудиту інфраструктури та аналізу загроз, для Департаменту фінансів
було розроблено модель зонування моніторингу, яка передбачає поділ
інформаційного простору на логічні сегменти з різним рівнем критичності.
Зонування моніторингу базується на принципі пріоритетності активів.
Виділено три ключові зони контролю:
Арк.
мБІ041.025.24358.248.ПЗ 38
Змн. Арк. № докум. Підпис Дата

1. Зона підвищеного контролю (Critical Zone): Сюди входять сервери баз
даних, контролери домену та шлюз Fortinet. У цій зоні здійснюється тотальний
моніторинг: фіксуються всі спроби входу (успішні та неуспішні), зміни
конфігураційних файлів, запуск нових процесів та мережеві з'єднання. Для
файлових серверів активується режим моніторингу цілісності (FIM) у реальному
часі ("whodata"), що дозволяє ідентифікувати не лише факт зміни файлу, а й
конкретного користувача, який це зробив.
2. Зона стандартного моніторингу (Standard Zone): Охоплює робочі станції
співробітників. Тут фокус зміщується на виявлення типових загроз кінцевих
точок: спрацювання антивірусу Defender, встановлення несанкціонованого ПЗ,
підключення зовнішніх носіїв (USB) та спроби запуску скриптів (PowerShell).
3. Зона зовнішнього периметра (Perimeter Zone): Включає зовнішні
інтерфейси шлюзів та VPN-концентратори. Моніторинг цієї зони спрямований на
виявлення розвідки (сканування портів), DDoS-атак та спроб підбору паролів до
віддаленого доступу.
Паралельно із зонуванням розроблено класифікатор подій безпеки, який
дозволяє системі Wazuh автоматично визначати пріоритет інциденту. Всі події
поділяються на категорії відповідно до їхнього потенційного впливу на
конфіденційність, цілісність або доступність даних:
• Категорія "Автентифікація" (Authentication): Включає події входу в
систему. Критичними вважаються багаторазові помилки входу (Brute-
force), вхід у неробочий час або використання облікових записів
адміністраторів із нетипових IP-адрес.
• Категорія "Цілісність" (Integrity): Охоплює події, зафіксовані модулем
FIM. Зміни у системних директоріях (/etc, System32) або файлах
конфігурації фінансового ПЗ класифікуються як інциденти високого
рівня.
• Категорія "Шкідливе ПЗ" (Malware/Exploit): Об'єднує сповіщення від
Windows Defender та систем виявлення вторгнень (IPS/IDS). Сюди
Арк.
мБІ041.025.24358.248.ПЗ 39
Змн. Арк. № докум. Підпис Дата

також відносяться спроби експлуатації вразливостей, виявлені
модулем Vulnerability Detector.
• Категорія "Політики" (Policy Violation): Фіксує порушення внутрішніх
регламентів, таких як використання P2P-клієнтів, ігор, або
відключення оновлень ОС.
Такий підхід дозволяє налаштувати правила фільтрації на рівні Wazuh
Manager, відсіюючи інформаційний шум та фокусуючи увагу адміністратора лише
на подіях, що потребують реагування що детальніше розглянуто на схемі Рис.2.4.
Це є необхідною умовою для зниження навантаження на персонал та підвищення
швидкості реакції на реальні загрози.

Рис.2.4 Схема класифікації та обробки подій безпеки в системі Wazuh

Арк.
мБІ041.025.24358.248.ПЗ 40
Змн. Арк. № докум. Підпис Дата

2.7. Модель процесів моніторингу та інцидент-менеджменту в структурі
ДФ ЧОДА

Інтеграція технічних засобів моніторингу вимагає розробки відповідної
процесної моделі, яка регламентує дії персоналу на кожному етапі обробки подій
безпеки. Для Департаменту фінансів було розроблено адаптовану модель
інцидент-менеджменту, що базується на рекомендаціях NIST SP 800-61 та
враховує обмежені кадрові ресурси установи.
Основою моделі є циклічний процес реагування, який складається з
чотирьох фаз: підготовка, виявлення та аналіз, стримування та відновлення, пост-
інцидентний аналіз.
Фаза 1. Підготовка та безперервний моніторинг (Preparation) Ця фаза є
постійно діючою. Вона включає автоматизований збір логів системою Wazuh з
усіх підключених джерел (Windows, Fortinet, PfSense).
• Дії системи: Wazuh Manager у режимі реального часу порівнює вхідні
події з правилами кореляції та базою сигнатур загроз.
• Дії персоналу: Системний адміністратор перевіряє статус агентів та
доступність сервісів, забезпечуючи працездатність системи
моніторингу.
Фаза 2. Виявлення та аналіз (Detection & Analysis). Це критичний етап, на
якому подія перекваліфікується в інцидент.
• Автоматичне виявлення: При спрацюванні правила (наприклад, "High
severity alert: RDP brute-force") Wazuh генерує сповіщення (Alert) з
рівнем критичності 10 і вище. Сповіщення надсилається
адміністратору через налаштовані канали зв'язку (E-mail/Telegram).
• Тріаж (Triage): Оператор Wazuh (Спеціаліст з кібербезпеки) аналізує
сповіщення через Wazuh Dashboard. Його завдання - відфільтрувати
хибні спрацювання (False Positives) та підтвердити факт атаки.
Арк.
мБІ041.025.24358.248.ПЗ 41
Змн. Арк. № докум. Підпис Дата

• Класифікація: Підтверджений інцидент класифікується за типом
(наприклад, шкідливе ПЗ, несанкціонований доступ) та пріоритетом.
Фаза 3. Стримування, викорінення та відновлення (Containment, Eradication,
Recovery). Метою цієї фази є обмеження масштабів інциденту та мінімізація
збитків.
• Стримування: Залежно від типу загрози, застосовуються заходи
ізоляції. Це може бути автоматичне блокування IP-адреси на шлюзі
Fortinet (через Active Response) або відключення скомпрометованої
робочої станції від мережі VLAN.
• Викорінення: Видалення шкідливого ПЗ, скидання скомпрометованих
паролів, усунення вразливості, через яку стався злам.
• Відновлення: Відновлення пошкоджених файлів із резервних копій,
перевірка цілісності системи та повернення сервісу в штатний режим
роботи.
Фаза 4. Пост-інцидентний аналіз (Post-Incident Activity) Після закриття
інциденту проводиться аналіз "вивчених уроків".
• Документування: Спеціаліст формує звіт у системі, фіксуючи
хронологію подій та вжиті заходи.
• Оптимізація: На основі інциденту вносяться зміни до правил кореляції
Wazuh (Tuning) для покращення детекції подібних загроз у
майбутньому.
Для наочності взаємодії персоналу та системи на кожному етапі розроблено
схему процесу інцидент-менеджменту Рис.2.5.
Арк.
мБІ041.025.24358.248.ПЗ 42
Змн. Арк. № докум. Підпис Дата

Рис.2.5. Процес інцидент менеджменту

2.8. Підготовка персоналу та розробка внутрішніх регламентів роботи з
Wazuh
Ефективність впровадження будь-якої складної технічної системи, такої як
SIEM/XDR, безпосередньо залежить від готовності персоналу до її експлуатації.
Навіть найкраще налаштована система моніторингу буде неефективною, якщо
відповідальні особи не володіють навичками інтерпретації подій або не мають
чітких інструкцій щодо реагування. Тому етап підготовки Департаменту фінансів
Арк.
мБІ041.025.24358.248.ПЗ 43
Змн. Арк. № докум. Підпис Дата

до інтеграції Wazuh включає два паралельні процеси: розробку нормативно-
технічної документації та навчання співробітників.
Розробка внутрішніх регламентів:
Впровадження Wazuh вимагає створення пакету операційної документації,
яка формалізує роботу з системою. На відміну від політик безпеки (які
визначають що захищати), регламенти визначають як здійснювати моніторинг.
На основі моделі інцидент-менеджменту розроблено структуру необхідної
документації Рис.2.6.:

Рис.2.6. Ієрархія документації

1. Регламент моніторингу та аудиту подій. Цей документ визначає
періодичність перегляду дашбордів Wazuh (наприклад, щоденний ранковий огляд
критичних Alerts), порядок зберігання та ротації логів (Retention Policy), а також
перелік подій, що підлягають обов'язковому архівуванню для можливих
розслідувань.
2. Інструкція адміністратора системи Wazuh. Технічний документ, що
описує процедури розгортання агентів на нових робочих станціях, оновлення
Арк.
мБІ041.025.24358.248.ПЗ 44
Змн. Арк. № докум. Підпис Дата

правил кореляції (Ruleset update), створення резервних копій конфігурації сервера
та дії у разі збою компонентів системи моніторингу.
3. Операційна процедура реагування (SOP - Standard Operating Procedure).
Документ типу "Playbook", який містить покрокові алгоритми дій чергового
спеціаліста при виявленні типових загроз (вірусна атака, спроба підбору пароля,
несанкціоноване підключення пристрою). Це дозволяє мінімізувати вплив
"людського фактора" у стресових ситуаціях.
Підготовка та навчання персоналу. Враховуючи організаційну структуру ІТ-
підрозділу Департаменту (п. 1.10), план навчання диференціюється залежно від
ролі співробітника.
Для спеціалістів з кібербезпеки (Операторів Wazuh): Навчання фокусується
на глибокому вивченні архітектури системи. Ключові компетенції, які необхідно
сформувати:
• Робота з синтаксисом пошукових запитів (Query Language) для
фільтрації подій у Kibana/OpenSearch Dashboards.
• Написання кастомних декодерів та правил (XML) для специфічного
фінансового ПЗ.
• Інтерпретація логів FIM (File Integrity Monitoring) та відрізнення
легітимних змін системних файлів від зловмисних.
• Використання API Wazuh для автоматизації рутинних задач.
Для технічних спеціалістів та адміністраторів БД: Проводиться інструктаж
щодо взаємодії з агентами Wazuh. Вони повинні розуміти, як перевірити статус
служби агента на сервері, як інтерпретувати повідомлення про блокування (Active
Response) та як правильно подавати запити на виключення (Whitelisting) у разі
хибних спрацювань, щоб не зупинити критичні бізнес-процеси.
Для звичайних користувачів: Проводиться ознайомчий семінар щодо
присутності агентів моніторингу на їхніх робочих станціях.
Арк.
мБІ041.025.24358.248.ПЗ 45
Змн. Арк. № докум. Підпис Дата

Мета - підвищення дисципліни та пояснення, що система фіксує не зміст
їхньої роботи, а безпекові параметри (підключення флеш-носіїв, встановлення
програм). Це базується на принципах "культури кібербезпеки", описаних у роботі.
Комплексний підхід до регламентації та навчання дозволяє інтегрувати
Wazuh у щоденну діяльність Департаменту не як "чужорідний елемент", а як
зрозумілий та керований інструмент.

2.9. Розробка політик безпеки, адаптованих під використання SIEM
Wazuh
Інтеграція системи SIEM вимагає перегляду підходів до формування
політик інформаційної безпеки Департаменту. Традиційні організаційно-
розпорядчі документи часто носять декларативний характер, встановлюючи
заборони без дієвих механізмів контролю їх виконання. Впровадження Wazuh
дозволяє реалізувати концепцію «Policy as Code» (Політика як код), коли вимоги
безпеки автоматично перевіряються та забезпечуються технічними засобами. У
зв'язку з цим було розроблено та адаптовано три ключові групи політик, які
безпосередньо корелюються з функціональними можливостями системи
моніторингу.
Першим критичним напрямком є політика управління доступом та
автентифікації. У чинних регламентах Департаменту зафіксовано заборону на
використання облікових записів адміністраторів для віддаленого доступу з
неконтрольованих мереж. Технічна реалізація цієї вимоги в середовищі Wazuh
здійснюється шляхом налаштування правил кореляції для подій входу Windows
(Event ID 4624) та Linux PAM. Створено спеціалізоване правило, яке генерує
сповіщення критичного рівня у випадку, якщо IP-адреса джерела з'єднання не
належить до діапазону захищеної VPN-підмережі, а обліковий запис користувача
входить до групи адміністраторів домену. Це дозволяє миттєво виявляти спроби
обходу периметрального захисту.
Арк.
мБІ041.025.24358.248.ПЗ 46
Змн. Арк. № докум. Підпис Дата

Друга група адаптованих вимог стосується політики цілісності критичних
даних (Data Integrity Policy). Специфіка фінансової установи вимагає гарантій
незмінності баз даних та конфігурацій серверів. Для забезпечення цієї вимоги
налаштовано модуль FIM (File Integrity Monitoring), який переведено в режим
«whodata». Це дозволяє не лише фіксувати факт зміни системних файлів або
конфігурацій ІПК «Місцевий бюджет», але й ідентифікувати конкретного
користувача та процес, що ініціював ці зміни. Особливу увагу приділено
моніторингу ключів реєстру Windows, відповідальних за автозавантаження, що є
ефективним методом виявлення закріплення шкідливого програмного
забезпечення в системі.
Третій напрямок охоплює політику управління вразливостями. Замість
періодичних ручних перевірок, впроваджено безперервний автоматизований
контроль за допомогою модуля Vulnerability Detector. Система щоденно звіряє
інвентарний список встановленого програмного забезпечення з базами даних
відомих вразливостей (NVD), автоматично формуючи звіти про наявність
критичних помилок (CVSS > 9.0). Це дозволяє системному адміністратору
оперативно отримувати інформацію про необхідність встановлення оновлень
безпеки, мінімізуючи час існування вразливого середовища.
Процес технічної імплементації політик завершується створенням
відповідних наборів правил (Rulesets) у форматі XML. Наприклад,
адміністративна заборона на підключення особистих USB-накопичувачів
трансформується в конкретне технічне правило Wazuh, яке відстежує події
підключення змінних носіїв та класифікує їх як порушення внутрішніх
регламентів. Таким чином, розробка адаптованих політик створює не лише
юридичну, але й технічну основу для функціонування системи захисту,
перетворюючи кожне правило на інструмент активного контролю Рис.2.7.
Арк.
мБІ041.025.24358.248.ПЗ 47
Змн. Арк. № докум. Підпис Дата

Рис.2.7. Візуалізація трансформації політик

2.10. Визначення критеріїв ефективності впровадження системи моніторингу

Завершальним етапом проєктування системи є встановлення чітких,
вимірюваних показників, які дозволять об'єктивно оцінити успішність інтеграції
Wazuh у інфраструктуру Департаменту фінансів. Відхід від абстрактних понять
"надійності" до конкретних метрик (KPI - Key Performance Indicators) є
необхідною умовою для перевірки гіпотези про те, що впровадження SIEM/XDR
підвищує рівень захищеності установи.
Ключовим критерієм ефективності нової системи визначено часові
параметри реагування на інциденти. У той час як поточна модель захисту
характеризується високою латентністю виявлення загроз, впроваджена система
повинна забезпечити кардинальне скорочення середнього часу виявлення
Арк.
мБІ041.025.24358.248.ПЗ 48
Змн. Арк. № докум. Підпис Дата

(MTTD). Цльовим показником для критичних інцидентів, таких як атаки типу
Brute-force або спроби зміни системних файлів, встановлено інтервал, що не
перевищує кількох хвилин з моменту виникнення події. Аналогічні вимоги
висуваються і до середнього часу реагування (MTTR), який має зменшитися за
рахунок автоматизації блокування загроз на мережевих шлюзах.
Не менш важливим показником якості впровадження є повнота охоплення
інфраструктури моніторингом (Log Coverage). Ефективна система повинна
агрегувати події не менше ніж з 95% активних хостів мережі, включаючи всі
критичні сервери та активне мережеве обладнання. Будь-яка "сліпа зона" в
моніторингу автоматично знижує загальну оцінку ефективності проєкту, оскільки
залишає потенційний вектор для непоміченої атаки.
Якісний аспект роботи системи оцінюється через співвідношення корисних
сповіщень до хибних спрацювань (False Positive Rate). Висока чутливість системи
не повинна призводити до "втоми від тривог" (Alert Fatigue), коли адміністратор
ігнорує повідомлення через їх надмірну кількість. Тому критерієм успішного
налаштування Wazuh є досягнення балансу, при якому кількість хибних
сповіщень про інциденти високого пріоритету зведена до мінімуму завдяки точно
налаштованим правилам кореляції та виключенням.
Специфіка фінансової установи також вимагає включення до системи
оцінки критеріїв відповідності (Compliance). Успішною вважатиметься така
інтеграція, яка забезпечить автоматизований контроль цілісності критичних
файлових ресурсів (FIM) та регулярне проходження перевірок на відповідність
стандартам безпеки (SCA) з формуванням доказової бази для аудиторів.
Таким чином, сукупність цих показників - швидкість реакції, повнота
охоплення, точність детекції та відповідність стандартам - формує комплексну
методику оцінки, яка буде застосована у третьому розділі для аналізу результатів
практичного впровадження системи що вказано на Таблиці 2.2 та Рис.2.8.

Арк.
мБІ041.025.24358.248.ПЗ 49
Змн. Арк. № докум. Підпис Дата

Таблиця.2.2. Прогноз зміни ключових показників ефективності (KPI)
Критерій ефективності Поточний стан (As-Is) Цільовий стан (To-Be) Очікуваний результат
Швидкість виявлення
Години / Дні Хвилини (< 5 хв) Прискорення реакції
(MTTD)
Зниження навантаження на
Автоматизація реакції Відсутня (0%) Висока (85%)
персонал
Охоплення хостів Часткове (~30%) Повне (> 95%) Ліквідація "сліпих зон"
Зменшення хибних
Точність детекції Низька Висока
спрацювань
Аудит відповідності Ручний / Епізодичний Автоматичний / Щоденний Готовність до перевірок

Рис.2.8. Діаграма показників ефективності

2.11 Висновки до розділу

У розділі здійснено проєктування та підготовка інфраструктури до
провадження системи Wazuh.
Архітектура рішення. Сформовано розподілену архітектуру системи Wazuh,
яка враховує наявну сегментацію мережі Департаменту (серверний сегмент,
сегмент користувацьких робочих станцій). Центральний сервер розгорнуто в
захищеній частині мережі, де він приймає журнали безпеки від агентів на робочих
станціях та отримує дані через Syslog від мережевих пристроїв (Fortinet, PfSense).
Модель загроз та політики. Визначено ключові можливі вектори атак —
brute-force, несанкціоновані зміни конфігурацій та шкідливе ПЗ. На їх основі були
Арк.
мБІ041.025.24358.248.ПЗ 50
Змн. Арк. № докум. Підпис Дата

розроблені оновлені політики безпеки, у тому числі автоматизований контроль
цілісності файлів (FIM) для фінансових баз даних та політики щодо виявлення
вразливостей.
Процеси реагування. Сформовано модель управління інцидентами, яка
охоплює етапи підготовки, виявлення, стримування та відновлення. Це забезпечує
стандартизований підхід персоналу до реагування на загрози.
Критерії ефективності. Для оцінки результатів впровадження визначено
низку KPI. Головним серед них є скорочення середнього часу виявлення
інцидентів (MTTD) із годин або днів до кількох хвилин, а також досягнення
повного покриття інфраструктури засобами моніторингу.

Арк.
мБІ041.025.24358.248.ПЗ 51
Змн. Арк. № докум. Підпис Дата

РОЗДІЛ 3. ПРАКТИЧНА РЕАЛІЗАЦІЯ ІНТЕГРАЦІЇ WAZUH У
ДІЯЛЬНІСТЬ ДЕПАРТАМЕНТУ ФІНАНСІВ ЧОДА

3.1. Проєктування та розгортання інфраструктури Wazuh

У цьому розділі буде розглянуто процес практичного розгортання системи
Wazuh в мережі Департаменту. Для того, щоб не витрачати багато часу на
налаштування кожного компонента окремо (Indexer, Server, Dashboard) і уникнути
помилок сумісності, було вирішено використати готовий віртуальний образ
(OVA), який надають розробники. Це значно спрощує старт роботи.
Для розгортання системи ми використали наявний гіпервізор на сервері.
Спочатку з офіційного сайту Wazuh скачали файл образу wazuh-7.2.4.ova.
Процес встановлення виглядав наступним чином:
1. Відкрили консоль гіпервізора і вибрали функцію імпорту ("Import
Appliance"), вказавши шлях до скачаного файлу.
2. В налаштуваннях віртуальної машини виділили ресурси: 4 ядра
процесора (vCPU) та 8 ГБ оперативної пам'яті. Згідно з документацією, цього має
вистачити для нашої кількості агентів.
3. Мережевий адаптер перевели в режим "Bridge", надали йому статичну
адресу з нашої локальної мережі щоб він був видимий для інших комп'ютерів.
Після завершення імпорту ми запустили віртуальну машину. Завантаження
зайняло кілька хвилин. Коли з'явилося вікно входу в консоль, використали
стандартний логін wazuh-user і пароль wazuh. Система відразу попросила змінити
пароль на більш надійний, що ми і зробили.
Ми відкрили браузер і ввели адресу https://10.23.100.37. Браузер видав
попередження про небезпечне з'єднання, бо сертифікат самопідписаний, але ми
його пропустили. Після цього відкрилася сторінка входу.
Арк.
мБІ041.025.24358.248.ПЗ 52
Змн. Арк. № докум. Підпис Дата

Ввели логін admin і пароль, який був згенерований при першому запуску
системи. Після входу відкрилася головна панель Wazuh overview. Поки що там
пусто, агентів немає, але інтерфейс працює що видно на Рис.3.1.

Рис.3.1. Головна панель Wazuh overview

Також варто додати, що для нормальної роботи серверу треба прописати
статичну IP-адресу, щоб вона не змінювалася після перезавантаження. Це
робиться в налаштуваннях мережі самої операційної системи. Ще перевірили
через netstat, чи відкриті порти 1514 і 55000 – все було нормально.
Загалом, використання OVA-образу дозволило дуже швидко підняти сервер
і підготувати його до роботи. Тепер можна переходити до підключення агентів.

3.2. Розгортання агентів Wazuh на робочих станціях та серверах

Після успішного розгортання та налаштування серверної частини системи
(описаного в п. 3.1), наступним етапом стало підключення джерел подій.
Архітектура Wazuh базується на використанні агентів - легковагових програмних
модулів, що встановлюються на кінцеві точки для збору телеметрії, логів та
Арк.
мБІ041.025.24358.248.ПЗ 53
Змн. Арк. № докум. Підпис Дата

моніторингу стану системи. Без коректно встановлених агентів функціонування
SIEM-системи неможливе.
Інфраструктура Департаменту включає сервери під управлінням Windows
Server та клієнтські робочі станції на базі Windows 10/11. Загальна кількість
хостів, що підлягають моніторингу, становить близько 50 одиниць. Зважаючи на
відносно невеликий розмір парку техніки, а також необхідність перевірки
коректності роботи на кожному окремому вузлі, було прийнято рішення
здійснювати встановлення агентів у ручному режимі. Такий підхід дозволяє
уникнути помилок масового розгортання та гарантувати стабільне з'єднання з
сервером.
Процес інсталяції агентів. Для встановлення програмного забезпечення
використовувався метод розгортання через інтерфейс командного рядка
(PowerShell). Цей спосіб є найбільш ефективним, оскільки дозволяє передати
необхідні параметри конфігурації (зокрема, IP-адресу сервера управління)
безпосередньо під час інсталяції, уникаючи необхідності подальшого редагування
конфігураційних файлів.
Алгоритм дій на кожній робочій станції виглядав наступним чином:
1. Здійснювався вхід у систему з правами адміністратора.
2. Запускалася консоль PowerShell.
3. Виконати команду яка завантажує актуальну версію MSI-пакету з
офіційного репозиторію та ініціює процес встановлення з вказанням
адреси Wazuh Manager.
Використана команда : Invoke-WebRequest -Uri
https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.0-1.msi -OutFile wazuh-
agent.msi; msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER='10.23.100.37'
WAZUH_REGISTRATION_SERVER='10.23.100.37'
У даному випадку 10.23.100.37 - це внутрішня IP-адреса розгорнутого
сервера Wazuh. Після завершення роботи інсталятора, запуск служби агента
виконувався командою: NET START Wazuh
Арк.
мБІ041.025.24358.248.ПЗ 54
Змн. Арк. № докум. Підпис Дата

Технічні проблеми та їх вирішення: У процесі впровадження виникли певні
технічні складнощі, пов'язані з налаштуваннями мережевої безпеки та
специфікою роботи окремих серверів.
По-перше, на частині робочих станцій не вдалося встановити з'єднання з
сервером управління. Діагностика мережі показала, що причиною були застарілі
правила локального брандмауера (Windows Defender Firewall), які блокували
вихідний трафік на нестандартні порти. Оскільки агент Wazuh використовує порт
1514 для передачі даних, проблему було вирішено шляхом створення
відповідного дозволяючого правила на проблемних хостах.
По-друге, під час налаштування моніторингу на сервері баз даних (MS SQL)
було зафіксовано підвищене навантаження на центральний процесор. Аналіз
процесів показав, що причиною стала робота модуля моніторингу цілісності
файлів (FIM), який сканував файли баз даних великого обсягу. Для забезпечення
стабільної роботи фінансового ПЗ, директорії з базами даних були додані до
списку виключень модуля FIM, що стабілізувало роботу сервера.
Варто зазначити, що відсутність в інфраструктурі застарілих операційних
систем (Windows 7) значно спростила процес, оскільки не виникало проблем із
сумісністю версій агента.
За результатами проведених робіт, всі критичні вузли мережі були успішно
підключені до системи моніторингу. У консолі управління Wazuh Dashboard
відображається активний статус агентів, що свідчить про коректний збір та
передачу даних подій безпеки.

Арк.
мБІ041.025.24358.248.ПЗ 55
Змн. Арк. № докум. Підпис Дата

3.3. Налаштування модулів безпеки Wazuh

Після того, як агенти були успішно розгорнуті та з'єднані з сервером
(див. п. 3.2), система почала отримувати базові події. Однак для забезпечення
повноцінного моніторингу "з коробки" функціоналу недостатньо. Тому
наступним етапом роботи стало налаштування ключових модулів безпеки Wazuh:
моніторингу цілісності файлів (File Integrity Monitoring - FIM), оцінки
конфігурацій (Security Configuration Assessment - SCA) та виявлення вразливостей
(Vulnerability Detection).
Налаштування здійснювалося шляхом редагування конфігураційного файлу
ossec.conf на стороні сервера (для глобальних налаштувань) та, в окремих
випадках, на стороні агентів.
Налаштування моніторингу цілісності файлів (FIM):
Модуль FIM є критично важливим для фінансової установи, оскільки
дозволяє виявити несанкціоновані зміни у системних файлах та конфігураціях
програмного забезпечення. [7] За замовчуванням Wazuh перевіряє лише
стандартні системні директорії (наприклад, /etc у Linux або C:\Windows\System32
у Windows) з інтервалом у 12 годин. Для наших потреб цього було недостатньо.
Внесено зміни у конфігурацію для забезпечення моніторингу в режимі
реального часу (realtime="yes"). Це дозволяє отримувати сповіщення про зміни
миттєво, а не під час наступного сканування. Особливу увагу було приділено
каталогам, де зберігаються файли ІПК «Місцевий бюджет» та налаштування
серверів баз даних. Ці конфігурації було застосовано лише на тих ПК які
використовують цей програмний продукт
Приклад конфігурації блоку <syscheck>:
<syscheck>
<directories check_all="yes" realtime="yes" report_changes="yes">
C:\abfin_ipkmb
</directories>
Арк.
мБІ041.025.24358.248.ПЗ 56
Змн. Арк. № докум. Підпис Дата

<directories check_all="yes" realtime="yes">
C:\Windows\System32\drivers\etc </directories>
<ignore>C:\Windows\System32\LogFiles</ignore>
</syscheck>

Параметр report_changes="yes" дозволяє бачити не лише факт зміни
файлу, але й що саме змінилося (diff), що дуже зручно для аналізу.
Під час тестування виникла проблема з хибними спрацюваннями (False
Positives). Тимчасові файли, які створювала система під час роботи, генерували
потік непотрібних подій. Щоб вирішити це, ми додали відповідні шляхи до блоку
<ignore>, що суттєво зменшило "шум". Додано загальний вигляд конфіку Рис.3.2.

Рис.3.2 Загильний вигляд серверної конфігурації блоку <syscheck>
Арк.
мБІ041.025.24358.248.ПЗ 57
Змн. Арк. № докум. Підпис Дата

Виявлення вразливостей (Vulnerability Detection):
Для автоматизації пошуку застарілого ПЗ було активовано модуль
Vulnerability Detector. Цей модуль порівнює список встановлених програм, який
збирає агент, із глобальними базами даних вразливостей (CVE) від Microsoft,
Canonical та інших вендорів.
Для активації модуля на сервері Wazuh необхідно було змінити
налаштування в ossec.conf, увімкнувши завантаження баз даних для відповідних
операційних систем Рис .3.3.

Рис.3.3. Конфігурація модуля Vulnerability Detection

Оцінка конфігурації безпеки (SCA):
Модуль SCA дозволяє перевірити налаштування системи на відповідність
стандартам безпеки (наприклад, CIS Benchmark). Wazuh вже має вбудовані
політики для Windows 10 та Windows Server 2019, тому додаткового написання
правил не знадобилося. Ми лише переконалися, що модуль увімкнений
(<sca><enabled>yes</enabled></sca>).
Результати сканування показали, що на багатьох комп'ютерах дозволений
автозапуск зі змінних носіїв і деякі інші вразливості, що було виправлено
системним адміністратором через групові політики Active Directory.
Таким чином, налаштування цих трьох модулів дозволило перетворити
Wazuh з простого збирача логів на повноцінний інструмент контролю стану
захищеності інфраструктури.

Арк.
мБІ041.025.24358.248.ПЗ 58
Змн. Арк. № докум. Підпис Дата

3.4. Інтеграція з Active Directory та іншими службами ДФ ЧОДА

Наступним етапом після базового налаштування системи (п. 3.3) стала
інтеграція Wazuh з критично важливими сервісами Департаменту. Метою цього
етапу було не лише налаштувати збір логів, але й забезпечити кореляцію подій
безпеки на рівні інфраструктури. Основними об'єктами інтеграції стали служба
каталогів Active Directory (AD) та сервер баз даних MS SQL, який обслуговує
фінансове ПЗ.
Інтеграція з Active Directory:
Active Directory є серцем інфраструктури, оскільки керує автентифікацією
всіх користувачів. Для Wazuh важливо отримувати події з контролера домену
(DC), щоб виявляти спроби несанкціонованого доступу, створення підозрілих
облікових записів або зміни в групових політиках.
Процес інтеграції складався з двох частин::
1. Встановлення агента на контролер домену: Це було виконано за
процедурою, описаною в п. 3.2. Агент успішно підключився до
менеджера.
2. Налаштування політик аудиту Windows: Це був найважливіший крок.
За замовчуванням Windows не пише в журнал детальні події безпеки
(наприклад, успішні входи або доступ до об'єктів), щоб не засмічувати
диск. Нам довелося змінити групову політику "Default Domain
Controllers Policy", увімкнувши розширений аудит:
• Audit Logon Events - Success/Failure
• Audit Account Management - Success/Failure
• Audit Object Access - Failure
Після застосування політики (gpupdate /force) у консолі Wazuh почнуть
з'являтися події з ID 4624 (успішний вхід) та 4625 (помилка входу).
Окремим завданням може бути налаштування автентифікації
адміністраторів Wazuh через AD. Щоб не створювати окремі облікові записи в
Арк.
мБІ041.025.24358.248.ПЗ 59
Змн. Арк. № докум. Підпис Дата

самому Wazuh, можна налаштували модуль security в config.yml індексатора,
прописавши параметри підключення до LDAP. Це дозволило заходити в дашборд,
використовуючи доменні логіни та паролі, що значно спростило управління
доступом.
Збір логів з мережевого обладнання:
Також було налаштовано отримання логів з шлюзів безпеки (Fortinet та
PfSense). Оскільки на ці пристрої неможливо поставити агента, використовувався
протокол Syslog. На сервері Wazuh ми дозволили прийом даних по UDP/514,
додавши відповідний блок у ossec.conf:
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>10.23.100.39</allowed-ips>
<allowed-ips>10.23.100.38</allowed-ips>
</remote>
На стороні Fortinet налаштували пересилку логів на IP-адресу сервера
Wazuh. Це дозволило бачити в одній консолі і події з Windows-серверів, і
мережеві атаки, заблоковані фаєрволом.
В результаті проведених робіт було створено єдиний інформаційний
простір, де події з різних джерел (AD, Network) не просто зберігаються, а й
корелюються між собою, дозволяючи бачити повну картину інциденту.

3.5. Розробка правил кореляції та алертів для державної установи

Ефективність SIEM-системи визначається здатністю адаптуватися до бізнес-
процесів організації. Стандартний набір правил Wazuh (Default Ruleset) є
універсальним, проте він не завжди враховує специфіку роботи державної
установи та рівень критичності окремих подій. Це часто призводить до того, що
Арк.
мБІ041.025.24358.248.ПЗ 60
Змн. Арк. № докум. Підпис Дата

дійсно важливі інциденти мають низький пріоритет за замовчуванням і губляться
в загальному потоці логів.
Для підвищення точності виявлення інцидентів було розроблено набір
адаптованих правил у файлі local_rules.xml.
1. Виявлення аномалій доступу в неробочий час
Специфіка роботи Департаменту фінансів передбачає чітко визначений
робочий графік. Будь-яка успішна авторизація в системі у нічний час, вихідні або
святкові дні може свідчити про компрометацію облікового запису або
несанкціоновані дії співробітників (інсайдерська загроза). Стандартні правила не
враховують часовий контекст подій.
Для вирішення цієї проблеми було створено правило, яке відстежує подію
успішного входу в систему (Windows Event ID 4624 / Wazuh ID 60106) у період з
22:00 до 06:00.
Приклад реалізації правила:
<group name="policy_violation,">
<rule id="100050" level="10">
<if_sid>60106</if_sid> <!-- Базується на стандартному успішному вході --
>
<time>22:00-06:00</time>
<description>Увага: Успішний вхід в систему у нічний час</description>
<group>policy_violation,pci_dss_10.2.5,</group>
</rule>
</group>
Впровадження цього правила дозволило автоматично підвищувати
пріоритет таких подій до рівня 10 (High), що гарантує привернення уваги
адміністратора до нічної активності.
2. Ескалація подій очищення журналів (Anti-Forensics)
Однією з характерних ознак дій зловмисника після проникнення в систему є
спроба видалити сліди своєї діяльності, зокрема очистити журнали подій Windows
Арк.
мБІ041.025.24358.248.ПЗ 61
Змн. Арк. № докум. Підпис Дата

(Security Event Log). Це критичний інцидент, який вимагає негайного
розслідування.
У стандартному наборі правил Wazuh ця подія детектується правилом ID
60109, проте воно має низький рівень важливості (Level 3), що недостатньо для
ініціації негайного реагування.
Для виправлення цього недоліку було створено правило-нащадок, яке
підвищує рівень даної події до критичного (Level 12).
<rule id="100060" level="12">
<if_sid>60109</if_sid> 
<description>КРИТИЧНО: Журнал аудиту безпеки Windows був
очищений!</description>
<group>system_error,pci_dss_10.5.2,</group>
</rule>
Завдяки цьому налаштуванню, спроба "замести сліди" тепер генерує
миттєве сповіщення адміністратору, а не просто записується в архів.
3. Налаштування системи сповіщень (Alerting)
Ключовим етапом налаштування стало забезпечення оперативного
інформування відповідальних осіб. Оскільки в установі використовується
хмарний поштовий сервіс Microsoft 365 (домен ck.gov.ua), який вимагає сучасної
автентифікації (OAuth2) і не підтримує застарілі методи SMTP-авторизації, пряма
відправка листів засобами Wazuh Manager була неможливою.
Для вирішення цієї технічної задачі було розгорнуто локальний поштовий
релей (Mail Relay) на базі Postfix. Сервіс налаштовано на прийом повідомлень від
Wazuh на локальному інтерфейсі та їх подальшу маршрутизацію через захищений
шлюз Microsoft 365.
В конфігураційному файлі ossec.conf налаштовано фільтрацію сповіщень,
щоб на корпоративну пошту надходили лише інциденти з рівнем критичності 12 і
вище.

Арк.
мБІ041.025.24358.248.ПЗ 62
Змн. Арк. № докум. Підпис Дата

<ossec_config>
<global>
<jsonout_output>yes</jsonout_output>
<alerts_log>yes</alerts_log>
<logall>no</logall>
<logall_json>no</logall_json>
<email_notification>yes</email_notification>
<smtp_server>XXX.XXX.XXX.</smtp_server>
<email_from>[email protected]</email_from>
<email_to>[email protected]</email_to>
<email_maxperhour>12</email_maxperhour>
<email_log_source>alerts.log</email_log_source>
<agents_disconnection_time>15m</agents_disconnection_time>
<agents_disconnection_alert_time>0</agents_disconnection_alert_time>
<update_check>yes</update_check>
</global>
Така архітектура системи сповіщень забезпечує гарантовану доставку
критичних повідомлень адміністратору протягом кількох секунд після
виникнення інциденту, мінімізуючи час реакції (MTTD).

3.6. Побудова дашбордів і звітності щодо інцидентів у Wazuh

Завершальним етапом технічного налаштування системи стала візуалізація
даних. Wazuh Dashboard надає потужні можливості "з коробки", але стандартні
панелі є надто загальними і відображають статистику по всіх підключених
модулях. Для потреб Департаменту фінансів необхідно було створити
спеціалізовані вікна моніторингу, які б дозволяли миттєво оцінювати стан безпеки
критичних сервісів без необхідності ручного пошуку в масиві логів.
Кастомізація головного дашборду:
Арк.
мБІ041.025.24358.248.ПЗ 63
Змн. Арк. № докум. Підпис Дата

Першочерговим завданням було налаштування головного екрану
(Overview), який бачить адміністратор після входу. Стандартний дашборд містив
багато зайвої інформації про модулі, які ми не використовуємо (наприклад, Cloud
Security).
Було створено нову вкладку "FinDept Security Overview", куди вивели
ключові метрики (KPI) безпеки:
• Top 5 Alert Level 10+: Віджет, що показує останні критичні інциденти.
• FIM Changes (Last 24h): Графік змін у файловій системі серверів.
• Failed Logons Trend: Гістограма невдалих спроб входу, яка дозволяє
візуально помітити початок Brute-force атаки (різкий сплеск на
графіку) Рис.3.4.

Рис.3.4 Створений дашборд

Для реалізації цього використовувався вбудований редактор візуалізацій
OpenSearch Dashboards. Ми створили кілька фільтрів (data.srcip, rule.level), щоб
відсіяти шум і залишити тільки релевантні дані.
Створення звітності для керівництва:
Окрім оперативного моніторингу, система має забезпечувати регулярну
звітність. Керівництву Департаменту не цікаві технічні деталі (IP-адреси, порти),
їм потрібна загальна картина: "Чи нас атакували?", "Чи всі системи захищені?".
Арк.
мБІ041.025.24358.248.ПЗ 64
Змн. Арк. № докум. Підпис Дата

Для цього ми налаштували модуль Wazuh Reporting. Було створено шаблон
щотижневого звіту, який автоматично генерується у форматі PDF і надсилається
на пошту начальника відділу ІТ, приклад видно на Рис.3.5. та Рис.3.6.
Звіт включає:
• Загальну кількість зафіксованих атак.
• Список хостів з найбільшою кількістю вразливостей (щоб розуміти,
де треба оновити ПЗ).
• Статус відповідності стандартам (Compliance score).

Рис.3.5. Налаштування щотижневого звіту

Арк.
мБІ041.025.24358.248.ПЗ 65
Змн. Арк. № докум. Підпис Дата

Рис.3.6 Вміст звіту
Також з відкритого доступу було завантажено дашборд «wazuh-
vulnerabilities-v1.0» рис.3.7. Що дозволяє дуже зручно слідкувати за наявними
вразливостями.
Арк.
мБІ041.025.24358.248.ПЗ 66
Змн. Арк. № докум. Підпис Дата

Рис.3.7. «wazuh-vulnerabilities-v1.0».

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

3.7. Розробка та проведення сценаріїв тестування працездатності
системи (імітація атак)

Для верифікації ефективності впровадженої системи та перевірки
коректності роботи налаштованих правил кореляції було проведено етап
практичного тестування. Випробування здійснювалися в контрольованому
середовищі на тестовому сегменті мережі, щоб уникнути впливу на реальні робочі
процеси Департаменту.
Було реалізовано три сценарії, що імітують типові дії зловмисника або
недобросовісного інсайдера.
Сценарій №1: Перевірка детекції спроб підбору паролів (RDP Brute-force)
Мета: Перевірити здатність системи фіксувати багаторазові невдалі спроби
авторизації через протокол віддаленого робочого столу (RDP).
Арк.
мБІ041.025.24358.248.ПЗ 67
Змн. Арк. № докум. Підпис Дата

Хід експерименту: Тестування проводилося в ручному режимі, без
використання автоматизованих сканерів. З робочої станції було ініційовано
підключення до тестового сервера з адреси 10.23.100.38 (спроби виконувались
через VPN тунель до робочої мережі) за допомогою стандартного клієнта
«Підключення до віддаленого робочого столу» (mstsc.exe). Протягом двох хвилин
було здійснено 6 спроб входу з використанням некоректного пароля.
Результат:
1. Агент Wazuh зафіксував серію подій Windows Event ID 60204 ("An
account failed to log on").
2. Після досягнення порогового значення (5 спроб), спрацювало правило
кореляції.
3. В Wazuh Dashboard було згенеровано сповіщення критичного рівня:
«Multiple Windows Logon Failures» Рис.3.8.
4. На електронну пошту прийшов лист сповіщення рис 3.9

Рис.3.8. Спрацювання правила «Multiple Windows Logon Failures»
Арк.
мБІ041.025.24358.248.ПЗ 68
Змн. Арк. № докум. Підпис Дата

Рис.3.9. Лист через спрацювання правила «Multiple Windows Logon Failures»

Варто зазначити, що механізм автоматичного розриву з'єднання або
блокування IP-адреси (Active Response) у даному сценарії не застосовувався.
Згідно з вимогами керівництва Департаменту, на етапі впровадження системи
автоматичне блокування визнано ризикованим через можливість помилкового
обмеження доступу легітимним користувачам. Тому система працює виключно в
режимі інформування (Alerting).
Сценарій №2: Виявлення спроб очищення журналів (Anti-Forensics)
Мета: Перевірити реакцію на подію очищення журналу безпеки Windows
(Event ID 1102).
Арк.
мБІ041.025.24358.248.ПЗ 69
Змн. Арк. № докум. Підпис Дата

Хід експерименту: На етапі виконання тесту було прийнято рішення
відмовитися від фактичного очищення журналів на діючих серверах задля
збереження аудиторського сліду. Проте було використано інструмент «wazuh
logtest» в який було передано імітації інциденту :
{"win":{"system":{"providerName":"Microsoft-Windows-Security-
Auditing","eventID":"1102"},"eventdata":{"SubjectUserSid":"S-1-5-
18","SubjectUserName":"SYSTEM","SubjectDomainName":"NT
AUTHORITY","SubjectLogonId":"0x3e7"}}}.
Результат: Верифікація правила проводилася за допомогою вбудованої
утиліти симуляції wazuh-logtest. У систему було передано тестовий рядок логу,
що відповідає події очищення. Система коректно розпізнала подію і підтвердила,
що у разі реального інциденту буде згенеровано тривогу критичного рівня (Level-
12) Рис.3.10.

Рис.3.10. Перевірка правила за допомогою «wazuh-logtest»

Сценарій №3: Емуляція запуску шкідливого скрипту (PowerShell)
Мета: Перевірити, чи зафіксує система спробу завантаження файлу із
зовнішнього джерела через командний рядок PowerShell.
Хід експерименту: На тестовій робочій станції було спробувано виконати
команду: powershell -nop -c "IEX (New-Object
Net.WebClient).DownloadString('http://bit.ly/test_file')"
Арк.
мБІ041.025.24358.248.ПЗ 70
Змн. Арк. № докум. Підпис Дата

Результат: Очікуваний запис у журналі PowerShell не з'явився, оскільки
Windows Defender заблокував виконання процесу на етапі запуску. Проте Wazuh
отримав сповіщення від модуля Defender про блокування загрози, що підтверджує
ефективність ешелонованого захисту.
Сценарій №4: Виявлення входу в неробочий час
Мета: Перевірити спрацювання правила, яке контролює доступ до системи в
нічний період (правило ID 100050, налаштоване в п. 3.5).
Хід експерименту: Тестування проводилося о 22:15. З робочої станції
користувача було здійснено успішний вхід у доменний обліковий запис.
Результат: Система зафіксувала подію успішного входу (Event ID 4624).
Завдяки налаштованому часовому фільтру, Wazuh автоматично підвищив рівень
цієї події до 10 і згенерував попередження: "Увага: Успішний вхід в систему у
нічний час" Рис.3.11. Це підтверджує, що система здатна виявляти потенційні
інсайдерські загрози або компрометацію облікових записів, яка відбувається поза
робочим графіком.

Рис.3.11 Спрацювання правила виявлення входу в неробочий час

Висновки до етапу тестування
Практична перевірка показала, що система здатна виявляти основні типи
загроз. Час виявлення інцидентів є мінімальним. Наявність сповіщень про події,
заблоковані антивірусом, та детекція організаційних порушень (вхід вночі)
свідчить про комплексний підхід до моніторингу.

3.8. Аналіз результатів тестування та оцінка ефективності
впровадження

Арк.
мБІ041.025.24358.248.ПЗ 71
Змн. Арк. № докум. Підпис Дата

На основі даних, отриманих у ході практичного тестування (п. 3.7), було
проведено комплексний аналіз ефективності впровадженої системи моніторингу
Wazuh. Оцінка здійснювалася шляхом порівняння ключових показників інцидент-
менеджменту до впровадження системи (статус «As-Is», визначений у п. 2.3) та
після інтеграції (статус «To-Be»).
Кількісна оцінка ефективності (Метрики MTTD/MTTR):
Головним критерієм ефективності SIEM-системи є часові показники реакції
на загрози. Результати випробувань продемонстрували кардинальне скорочення
часу виявлення інцидентів Таблиця.3.1.

Таблиця.3.1. Порівняльний аналіз ефективності реагування
Тип інциденту MTTD (До MTTD (З Wazuh) Динаміка
впровадження)
RDP Brute-force 4–24 години (скарги < 1 хвилини Покращення в
користувачів) (автоматичний алерт) 240+ разів
Вхід у неробочий Не детектується Миттєво (Real-time) Якісний стрибок
час (випадковий аудит)
Очищення логів Не детектується Миттєво Якісний стрибок
Зміна конфігурацій Тижні (до моменту збою) < 5 хвилин (інтервал Забезпечення
(FIM) сканування) цілісності

Як видно з таблиці, впровадження Wazuh дозволило перевести процес
виявлення загроз з категорії "годин та днів" у категорію "хвилин". Це критично
важливо для фінансової установи, де кожна хвилина присутності зловмисника в
мережі підвищує ризик витоку даних.
Якісна оцінка та рівень зрілості:
Окрім часових показників, впровадження системи вплинуло на якісний
рівень кібербезпеки Департаменту:
• Підвищення спостережуваності (Observability): До впровадження
Wazuh інфраструктура мала численні "сліпі зони" (локальні логи
робочих станцій, події Active Directory). Тепер адміністратор має
єдину консоль, що консолідує події з усіх рівнів.
Арк.
мБІ041.025.24358.248.ПЗ 72
Змн. Арк. № докум. Підпис Дата

• Забезпечення відповідності (Compliance): Налаштування модулів FIM
та збереження логів дозволяє Департаменту виконувати вимоги НД
ТЗІ щодо аудиту подій безпеки, що раніше виконувалося формально.
• Зміна моделі безпеки: Відбувся перехід від реактивної моделі (гасіння
пожеж) до проактивної. Завдяки правилам виявлення вразливостей
(Vulnerability Detector), ІТ-відділ тепер бачить потенційні діри в
безпеці до того, як вони будуть використані.
Згідно з моделлю зрілості CMMI, рівень процесів кібербезпеки в
Департаменті підвищився з Level 1 (Initial) до Level 3 (Defined), оскільки процеси
моніторингу тепер стандартизовані, задокументовані та автоматизовані.
Економічна ефективність
Важливим аспектом проєкту є його економічна складова. Для досягнення
аналогічного функціоналу за допомогою комерційних рішень (наприклад, Splunk
або SolarWinds) Департаменту довелося б витратити значні бюджетні кошти на
придбання ліцензій та щорічну підтримку.
Використання Open Source платформи Wazuh дозволило реалізувати проєкт
без капітальних витрат на програмне забезпечення. Витрати обмежилися лише
використанням наявних апаратних ресурсів (виділення віртуальної машини) та
робочим часом штатних спеціалістів на налаштування.
Підсумок:
Результати тестування підтвердили, що інтегрована система повністю
відповідає функціональним вимогам, визначеним у п. 2.4. Вона забезпечує
надійний контроль периметра та внутрішньої мережі, значно знижує ризики
успішних кібератак і створює фундамент для подальшого розвитку процесів
інформаційної безпеки в Департаменті фінансів.

Арк.
мБІ041.025.24358.248.ПЗ 73
Змн. Арк. № докум. Підпис Дата

3.9. Пропозиції щодо покращення системи моніторингу ІБ у ДФ ЧОДА

За результатами впровадження та тестування системи Wazuh було виявлено
ряд напрямків, які потребують подальшого розвитку для досягнення
максимальної ефективності захисту. Поточна реалізація забезпечує надійний
базовий рівень моніторингу, проте для протидії складним цільовим атакам (APT)
необхідне розширення функціоналу.
На основі аналізу результатів тестування (п. 3.7) та оцінки ефективності (п.
3.8), сформовано наступні пропозиції щодо покращення системи:
1. Активація механізмів активного реагування (Active Response)
Під час тестування (сценарій №1) було виявлено, що відсутність
автоматичного блокування IP-адрес при Brute-force атаках створює зайве
навантаження на адміністратора, який змушений реагувати вручну.
Пропозиція: Після завершення періоду дослідної експлуатації (1-2 місяці) та
налаштування "білих списків" легітимних адрес, рекомендовано поетапно
активувати модулі Active Response:
• Автоматичне блокування зовнішніх IP-адрес на шлюзі Fortinet при
виявленні сканування портів або підбору паролів.
• Ізоляція хоста (Host Isolation) шляхом блокування мережевого
інтерфейсу при виявленні активності програм-вимагачів.
2. Поглиблення інтеграції з Microsoft Defender
Тестування показало, що антивірус Windows Defender ефективно блокує
загрози, але деталізація подій, які надходять до Wazuh, є недостатньою для
глибокого аналізу.
Пропозиція: Налаштувати збір розширеної телеметрії з Defender for
Endpoint (у разі переходу на платну підписку, як планувалося в п. 2.2) або
використовувати Sysmon (System Monitor) від Microsoft. Інтеграція Wazuh +
Sysmon дозволить бачити повне дерево процесів (Process Tree), мережеві
Арк.
мБІ041.025.24358.248.ПЗ 74
Змн. Арк. № докум. Підпис Дата

з'єднання кожного процесу та хеш-суми запущених файлів, що значно покращить
можливості розслідування інцидентів.
3. Впровадження контролю виконання PowerShell-скриптів
Інцидент зі сценарієм №3 виявив, що блокування скриптів працює, але
логування самого тексту команд може бути ускладнене.
Пропозиція: Увімкнути на рівні групових політик (GPO) розширений аудит
PowerShell (Script Block Logging) та налаштувати агент Wazuh на збір подій з
журналу Microsoft-Windows-PowerShell/Operational. Це дозволить фіксувати не лише факт
запуску скрипту, але й його деобфускований код, навіть якщо зловмисник
намагався його приховати.
4. Розширення моніторингу на рівень додатків (Application Layer)
Наразі система фокусується на інфраструктурі (ОС, мережа). Проте значна
частина загроз спрямована на веб-додатки та бази даних.
Пропозиція: Налаштувати збір логів веб-сервера IIS (якщо
використовується для внутрішніх порталів) та поглибити аудит транзакцій у MS
SQL Server. Зокрема, доцільно налаштувати правила для виявлення спроб SQL-
ін'єкцій та вивантаження великих масивів даних (DLP-функціонал).
5. Організаційні заходи та навчання
Технічні засоби не можуть компенсувати людський фактор.
Пропозиція:
• Розробити та затвердити регламент реагування на інциденти (Incident
Response Plan), де чітко прописати алгоритм дій чергового
адміністратора при отриманні алерту критичного рівня.
• Проводити регулярні навчання персоналу (Security Awareness) з
імітацією фішингових розсилок, щоб зменшити ризик компрометації
облікових записів.
Реалізація цих пропозицій дозволить трансформувати систему моніторингу
з інструменту фіксації подій у повноцінну платформу активного кіберзахисту.

Арк.
мБІ041.025.24358.248.ПЗ 75
Змн. Арк. № докум. Підпис Дата

3.10. Напрямки подальшого розвитку системи

Впровадження системи моніторингу Wazuh є лише першим етапом у
побудові комплексної системи кіберзахисту Департаменту фінансів. На основі
проведеного аналізу результатів тестування та сформованих пропозицій
визначено наступні стратегічні напрямки подальшого розвитку:
1. Масштабування на підвідомчі структури. Після стабілізації роботи
системи в центральному апараті Департаменту доцільно розширити зону
моніторингу на районні фінансові управління. Архітектура Wazuh (підтримка
кластеризації) дозволяє підключати тисячі агентів, що забезпечить єдиний центр
контролю безпеки для всієї фінансової вертикалі області.
2. Інтеграція з зовнішніми сервісами Threat Intelligence. Підключення Wazuh
до платформ обміну індикаторами компрометації (наприклад, MISP або VirusTotal
API) дозволить автоматично перевіряти хеш-суми файлів та IP-адреси на
наявність у глобальних базах загроз, значно підвищуючи ефективність детекції
нових видів шкідливого ПЗ.
3. Автоматизація реагування (SOAR). Перехід від ручного реагування до
автоматизованих сценаріїв (Playbooks) з використанням можливостей Wazuh
Active Response або інтеграції з платформами SOAR (Security Orchestration,
Automation and Response). Це дозволить миттєво ізолювати скомпрометовані
хости без участі адміністратора.
4. Впровадження поведінкового аналізу (UEBA). Налаштування правил
аналізу поведінки користувачів для виявлення аномалій, які не підпадають під
стандартні сигнатури (наприклад, масове вивантаження документів у нетиповий
час), що є критичним для захисту від інсайдерських загроз.
Реалізація цих напрямків дозволить трансформувати впроваджену систему з
інструменту моніторингу в повноцінний Центр оперативного реагування на
інциденти безпеки (SOC), здатний протистояти сучасним викликам кібербезпеки.

Арк.
мБІ041.025.24358.248.ПЗ 76
Змн. Арк. № докум. Підпис Дата

3.11 Висновки до розділу

У розділі подано опис технічної реалізації та результати тестування
впровадженої системи. Основні висновки такі:
Успішне розгортання. Виконано повне розгортання інфраструктури Wazuh:
підключено агенти до серверів і робочих станцій, налаштовано збір журналів з
Active Directory та мережевих шлюзів. Завдяки цьому було усунуто раніше наявні
«сліпі зони» в інфраструктурі.
Налаштування модулів. Активовано та ретельно налаштовано ключові
модулі: FIM (контроль цілісності файлів), Vulnerability Detector (виявлення
вразливостей ПЗ) та SCA (аудит конфігурацій). Додатково створено кастомні
правила кореляції для фіксації специфічних сценаріїв загроз — зокрема, спроб
входу в неробочий час або очищення журналів подій.
Результати тестування. Проведені сценарії імітованих атак (зокрема RDP
brute-force та запуск шкідливих скриптів) підтвердили стабільну роботу системи.
Час виявлення критичних інцидентів скоротився до менш ніж однієї хвилини, що
демонструє значний прогрес порівняно з попереднім рівнем захисту.
Візуалізація та звітність. Налаштовано інформаційні дашборди для
оперативного моніторингу, а також автоматизовано формування звітів для
керівництва. Це забезпечує високий рівень прозорості стану кібербезпеки.
Підвищення рівня зрілості. Впровадження системи дало змогу
Департаменту перейти від переважно реактивної моделі реагування до
проактивного підходу. У результаті рівень зрілості процесів кібербезпеки досяг
рівня Defined («Визначений») без потреби у додаткових капітальних витратах на
програмне забезпечення.

Арк.
мБІ041.025.24358.248.ПЗ 77
Змн. Арк. № докум. Підпис Дата

ЗАГАЛЬНІ ВИСНОВКИ
Створення та впровадження системи централізованого моніторингу
інформаційної безпеки в державних органах влади є критично важливою
відповіддю на зростання рівня кіберзагроз, з якими стикається державний сектор
України. Це стратегічний крок у напрямку забезпечення кіберстійкості критично
важливих процесів та захисту фінансових даних регіону. Враховуючи специфіку
роботи Департаменту фінансів Черкаської ОДА, інтеграція платформи Wazuh
відіграє ключову роль у забезпеченні конфіденційності, цілісності та доступності
бюджетної інформації.
У даній дипломній роботі було розроблено та обґрунтовано проєкт
інтеграції системи моніторингу інформаційної безпеки Wazuh, в рамках якого
виконано наступні завдання:
• Здійснено системний аналіз сучасних векторів кіберзагроз та
нормативно-правової бази захисту інформації. На основі
порівняльного аналізу SIEM/XDR рішень обґрунтовано вибір
платформи Wazuh як оптимального інструменту, що поєднує
функціональність Enterprise-рівня з відсутністю ліцензійних витрат,
що є критичним для бюджетної установи.
• Проведено аудит ІТ-інфраструктури та оцінку поточної моделі
безпеки Департаменту. Виявлено критичні вразливості, пов’язані з
фрагментарністю журналювання подій та відсутністю
автоматизованого контролю цілісності, що призводило до високого
часу виявлення інцидентів (MTTD).
• Розроблено та реалізовано архітектуру інтеграції системи Wazuh,
яка враховує особливості мережевої топології з двома провайдерами
та розділеними зонами безпеки. Здійснено розгортання серверних
компонентів та підключення агентів на робочих станціях і серверах
без переривання бізнес-процесів.
Арк.
мБІ041.025.24358.248.ПЗ 78
Змн. Арк. № докум. Підпис Дата

• Налаштовано ключові модулі безпеки (SCA, Vulnerability Detector)
та розроблено кастомні правила кореляції подій, адаптовані до
регламенту роботи державної установи. Зокрема, реалізовано сценарії
виявлення аномальної активності в неробочий час та спроб
приховування слідів присутності в системі.
• Експериментально підтверджено ефективність впровадженого
рішення. Результати тестування продемонстрували скорочення
середнього часу виявлення критичних інцидентів (таких як Brute-force
атаки та несанкціоновані зміни конфігурацій) з декількох годин до
лічених хвилин, що значно підвищує загальний рівень захищеності
інформаційно-телекомунікаційної системи Департаменту.
Таким чином, мета дослідження досягнута: впроваджена система Wazuh
трансформувала підхід до кібербезпеки в Департаменті від реактивного усунення
наслідків до проактивного виявлення загроз, створивши надійний фундамент для
подальшого розвитку центру оперативного реагування на інциденти.

Арк.
мБІ041.025.24358.248.ПЗ 79
Змн. Арк. № докум. Підпис Дата

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Закон України «Про основні засади забезпечення кібербезпеки
України» від 05.10.2017 № 2163-VIII (зі змінами та доповненнями) //
Відомості Верховної Ради України. – 2017. – № 45. – Ст. 403.
2. Закон України «Про захист інформації в інформаційно-
комунікаційних системах» від 05.07.1994 № 80/94-ВР // Відомості
Верховної Ради України. – 1994. – № 31. – Ст. 286.
3. Постанова Кабінету Міністрів України «Про затвердження Правил
забезпечення захисту інформації в інформаційних,
телекомунікаційних та інформаційно-телекомунікаційних системах»
від 29.03.2006 № 373.
4. Бірюков Д. С., Кондратов С. І. Захист критичної інфраструктури:
пріоритети та перспективи впровадження в Україні: монографія. – К.:
НІСД, 2019. – 184 с.
5. Гнатюк С. О., Корченко О. Г. Сучасні системи виявлення вторгнень
та моніторингу подій інформаційної безпеки: навч. посіб. – К.: НАУ,
2018. – 240 с.
6. ISO/IEC 27001:2022. Information security, cybersecurity and privacy
protection - Information security management systems - Requirements. –
Geneva: ISO, 2022.
7. Wazuh Documentation. The Open Source Security Platform
[Електронний ресурс]. – Режим доступу:
https://documentation.wazuh.com/current/index.html.
8. MITRE ATT&CK Framework. Knowledge base of adversary tactics and
techniques based on real-world observations [Електронний ресурс]. –
Режим доступу: https://attack.mitre.org/.
9. NIST SP 800-61 Rev. 2. Computer Security Incident Handling Guide. –
Gaithersburg: National Institute of Standards and Technology, 2012. – 79
p.
Арк.
мБІ041.025.24358.248.ПЗ 80
Змн. Арк. № докум. Підпис Дата

10. CIS Controls. Critical Security Controls for Effective Cyber Defense.
Center for Internet Security [Електронний ресурс]. – Режим доступу:
https://www.cisecurity.org/controls.
11. НД ТЗІ 2.5-004-99. Критерії оцінки захищеності інформації в
комп’ютерних системах від несанкціонованого доступу. – К.: ДСТСЗІ
СБ України, 1999.
12. Лапоніна О. Р. Основи мережевої безпеки: криптографічні алгоритми
і протоколи взаємодії. – М.: Інтернет-університет інформаційних
технологій, 2005. – 608 с.
13. Аверченков В. І., Ритов М. Ю. Організація захисту інформації:
підручник. – Брянськ: БДТУ, 2010. – 184 с. (Адаптовано).
14. ДСТУ 3396.2-97. Захист інформації. Технічний захист інформації.
Терміни та визначення. – К.: Держстандарт України, 1997.
15. OWASP Top 10. The Ten Most Critical Web Application Security Risks
[Електронний ресурс]. – Режим доступу: https://owasp.org/www-
project-top-ten/.

Арк.
мБІ041.025.24358.248.ПЗ 81
Змн. Арк. № докум. Підпис Дата

ChSTU repository

ChSTU repository preserves and enables easy and open access to all types of digital content including text, images, moving images, mpegs and data sets