Стежити Регуляторні зобов’язання щодо виявлення є наслідками безпеки, які DORA, NIS2, PCI DSS v4.0.1, та правила розкриття SEC вимагають від організації досягти та підтвердити за допомогою виявлення, моніторингу, логування та розкриття.
Жоден з цих чотирьох режимів не передбачає конкретного інструменту виявлення. Лише DORA називає виявлення як самостійне зобов’язання. Кожна структура вимагає результат: своєчасне виявлення, безперервний моніторинг, структуроване логування або своєчасне розкриття. Можливість виявлення – це те, що мається на увазі під доказами, а не контроль, який регулятор призначає за назвою.
MITRE ATT&CK організовує ці докази у структуру, яку аудитор може запитати за категорією поведінки суперника. ATT&CK не вимагається DORA, NIS2, PCI DSS або правилами SEC.
DORA є спеціальним законом або специфічним законом, який має пріоритет над загальним законом. Стаття 1(2) DORA робить його секторально-специфічним правовим актом Союзу для цілей Статті 4 NIS2. Фінансова установа в межах дії DORA застосовує DORA для управління ІКТ ризиками та звітності про інциденти. NIS2 охоплює нефінансовий ланцюг постачання банку, а не сам банк.
Які докази виявлення підтверджують зобов’язання за PCI DSS 4.0 та DORA?
Обидва PCI DSS v4.0.1 та DORA розглядають виявлення як засіб для доказової мети. Регламент запитує, чи генерують виявлення записи, які вимагає зобов’язання з моніторингу, а не чи існують виявлення.
П’ять класів доказів несуть цей доказ. Обидва режими вимагають їх по суті.
| Клас доказів | PCI DSS v4.0.1 | DORA |
|---|---|---|
| Зібрані джерела логів | Вимога 10: захоплення журналів аудиту, збереження історії | Стаття 9(1): безперервний моніторинг та контроль безпеки та функціонування ІКТ-систем; Стаття 10(3): моніторинг активності користувачів, аномалій ІКТ та інцидентів, пов’язаних з ІКТ |
| Розгорнуті правила, із власником | Вимога 11: виявлення проникнення/запобігання, виявлення змін реалізовано | Стаття 10: кілька рівнів контролю, визначені пороги оповіщення та критерії |
| Доказ спрацювання | Вимога 10: перегляд журналів, виявлення збоїв системи контролю | Стаття 10: оповіщення спрацювали та досягли відповідального персоналу |
| Історія змін | Вимога 11: виявлення змін і підробки | Стаття 17: документований процес управління інцидентами з подальшою обробкою основної причини |
| Звіт про покриття з даними | Вимога 10.5.1: історія журналів аудиту зберігається не менше 12 місяців, найбільш недавні три місяці доступні відразу (Бібліотека документів PCI SSC) | Стаття 10(1): механізми виявлення регулярно тестуються згідно з Статтею 25 |
PCI DSS v4.0 було знято з 31 грудня 2024 року, і PCI DSS v4.0.1 є єдиною активною версією (PCI SSC, червень 2024). 51 вимога з датою набуття чинності стали діючими 31 березня 2025 року (PCI SSC, серпень 2024). Заголовок H2 вище використовує “PCI DSS 4.0”, щоб відповідати запиту шукача.
Правило виявлення, яке розгорнуто, але не генерує жодного запису для перевірки, невидиме для оцінювача.
Які зобов’язання щодо виявлення та моніторингу фактично нав’язують DORA, NIS2, PCI DSS 4.0 і правила розкриття SEC?
Кожен режим нав’язує зобов’язання на рівні результату, а не необхідність у конкретному інструменті. Таблиця нижче відображає кожне зобов’язання на докази виявлення, які воно передбачає.
| Режим | Стаття або вимога | Зобов’язання | Передбачені докази виявлення |
|---|---|---|---|
| DORA | Статті 9(1), 10(3) | Безперервно моніторьте та контролюйте безпеку та функціонування ІКТ-систем (Стаття 9(1)); Моніторьте активність користувачів, аномалії ІКТ та інциденти, пов’язані з ІКТ (Стаття 10(3)) | Інвентаризація джерел журналів, записи безперервного збору |
| DORA | Статті 10(1), (2) | Виявлення аномальних дій; кілька рівнів контролю з порогами оповіщення та критеріями, включаючи автоматичні сповіщення відповідального персоналу; механізми виявлення регулярно тестуються за Статтею 25 | Інвентаризація правил з власниками, обґрунтування порогів, докази, що сповіщення дійшли до реагувальних, тестові записи |
| DORA | Стаття 17 | Виявлення, управління та повідомлення про ІКТ-інциденти з подальшою обробкою основної причини | Документація процесу, записи виявлення та обробки на інцидент |
| DORA | Стаття 19 + Делегований Регламент (ЄС) 2025/301 | Звітування про великі інциденти компетентному органу | Запис з часовою міткою виявлення та класифікації (попереднє повідомлення протягом 4 годин з моменту класифікації інциденту як великого та не пізніше ніж через 24 години після виявлення; проміжний звіт протягом 72 годин після першого повідомлення; остаточний звіт протягом одного місяця після проміжного звіту) |
| NIS2 | Стаття 21(2) | Заходи з управління ризиками, включаючи обробку інцидентів (пункт (б)) та політики для оцінки ефективності заходів (пункт (ф)); обов’язки моніторингу та логування містяться в імплементаційних правилах нижче, а не в самій Статті 21 | Задокументовані заходи, записи виявлення |
| NIS2 | Стаття 23(4) | Повідомлення про значний інцидент | Попереднє повідомлення протягом 24 годин з моменту виявлення, повідомлення про інцидент протягом 72 годин, остаточний звіт не пізніше ніж через місяць після повідомлення про інцидент |
| NIS2 | Імплементаційний Регламент (ЄС) 2024/2690 | Моніторинг і логування (додаток секція 3.2) для одинадцяти типів суб’єктів, зазначених у Статті 1(1), включаючи постачальників послуг з управління безпекою | Явні записи журналів для охоплених суб’єктів |
| PCI DSS v4.0.1 | Вимога 10 | Логування та моніторинг усіх доступів до компонентів системи та даних держателів карток | Журнали аудиту переглядаються щодня (10.4.1), автоматизований перегляд журналів (10.4.1.1), збереження історії журналів (10.5.1), збої в роботі критично важливих систем безпеки виявлені, повідомлені та своєчасно відреагували (10.7, 10.7.2); текст у Бібліотека документів PCI SSC |
| PCI DSS v4.0.1 | Вимога 11 | Регулярно тестуйте безпеку систем та мереж | Записи виявлення проникнення та запобігання (11.5.1), оповіщення про зміни (11.5.2), сповіщення про зміну та підробку сторінки оплати (11.6.1) |
| SEC | 8-K Пункт 1.05 | Розкриття матеріальних інцидентів протягом чотирьох робочих днів з моменту визначення матеріальності, яке саме повинно бути зроблено без необґрунтованої затримки після виявлення (Форма 8-K, Пункт 1.05) | Процес визначення матеріальності, записи виявлення інцидентів |
| SEC | S-K Пункт 106 | Опишіть процеси оцінки, ідентифікації та управління суттєвими кіберзагрозами в річному звіті 10-K (Пункт 1C) | Задокументований процес ідентифікації ризиків, включаючи можливості виявлення |
DORA (Регламент (ЄС) 2022/2554, який застосовується з 17 січня 2025 року) є безпосередньо застосовним. Його часові межі звітності встановлені Делегованим Регламентом (ЄС) 2025/301: початкове повідомлення протягом 4 годин після класифікації інциденту як великого та не пізніше ніж через 24 години після виявлення, проміжний звіт протягом 72 годин після першого повідомлення та остаточний звіт протягом одного місяця після проміжного звіту. Оскільки перший часовий інтервал починається з виявлення та класифікації, сама хронологія інциденту є аудиторським доказом.
NIS2 (Директива (ЄС) 2022/2555) обов’язкова через законодавство кожної держави-члена, яке є її перетворенням, а не безпосередньо. Строк перетворення сплив 17 жовтня 2024 року (Стаття 41). 7 травня 2025 року Європейська комісія направила аргументовані висновки 19 державам-членам за невиконання повного перетворення, а 8 липня 2026 року вона передала Ірландію, Іспанію, Францію та Нідерланди до Суду Справедливості. 20 січня 2026 року Комісія запропонувала зміни до NIS2 (COM(2026) 13), що зачіпляють Статтю 21(5) і додають пункти про вимагання до Статті 23, залишаючи заходи Статті 21(2) та часові рамки звітності Статті 23(4) без змін. Зобов’язання, з яким стикається покупець, залежить від законодавства, яке є перетворенням держави-члена.
Регламент (ЄС) 2024/2690, опублікований 18 жовтня 2024 року і чинний з 7 листопада 2024 року, встановлює чіткі вимоги до моніторингу та логування (додаток секція 3.2) для постачальників послуг DNS, реєстрів імен TLD, хмарного обчислення, центрів обробки даних, мереж доставки контенту, керованих сервісів і постачальників послуг з управління безпекою, платформ електронної комерції, пошукових систем, соціальних мереж і постачальників послуг довіри. Це охоплює MSSP як окремі регульовані суб’єкти, не пов’язані з обов’язками їх клієнтів.
PCI DSS v4.0.1 є єдиною активною версією. Вимоги 10 і 11 містять зобов’язання щодо виявлення та моніторингу.
SEC (остаточне правило Випуск 33-11216, прийняте 26 липня 2023 року) є правилом розкриття та управління, а не зобов’язанням щодо засобів контролю виявлення. Виявлення є похідне: реєстрант не може визначити матеріальність без можливості виявляти і оцінювати інциденти. Дотримання Пункту 1.05 було обов’язковим з 18 грудня 2023 року для більшості реєстрантів і з 15 червня 2024 року для менших компаній.
Які докази зазвичай шукають аудитори, щоб підтвердити, що наші системи виявлення є ефективними?
П’ять класів доказів повторюються у цих режимах. Відсоток покриття сам по собі не є доказом для жодного з них.
| # | Клас доказів | Що це доводить |
|---|---|---|
| 1 | Зібрані джерела логів | Яка телеметрія збирається, з яких систем і що збір є безперервним. Аудитор перевіряє, чи працює моніторинг, а не чи був він одного разу налаштований. |
| 2 | Застосовані правила | Правила виявлення у місці, кожне прив’язане до зобов’язання, яке воно підтримує, та до його ATT&CK техніки, де це доречно, з власником. |
| 3 | Доказ спрацювання | Правила спрацювали на реальних або змодельованих подіях, і оповіщення дійшли до відповідальних. Правило, яке ніколи не спрацьовувало, невипробуване з точки зору аудитора. |
| 4 | Історія змін | Хто змінив правило, коли і чому: управління версіями, слід рецензій та обґрунтування документованих змін. |
| 5 | Звіт про покриття з даними | Звіт у певний момент часу з датою, тому тенденції та актуальність є доведеними. Недатований звіт нічого не доводить про те, коли існувало покриття. |
ATT&CK функціонує як перехідник, який робить ці докази доступними за пошуковими запитами за поведінкою супротивника. Ідентифікатор техніки є метаданими, прикріпленими до вже існуючих доказів (джерела даних, застосовані правила, записи спрацювання), так що докази стають доступними за категоріями поведінки. ATT&CK не вимагається жодним із цих чотирьох режимів. Він організовує докази проти зобов’язань, які вони накладають.
Чи можете ви показати аудитору, хто змінив правило, коли і чому?
Detection-as-Code відповідає на це. Кожне правило виявлення є артефактом з версіями у системі контролю джерел. Історія змін реєструє автора, часову мітку, затвердження огляду і причину зміни.
Цей слід пов’язаний зі специфічними зобов’язаннями:
- Стаття 17 DORA вимагає документованого процесу управління інцидентами з подальшою обробкою основної причини.
- PCI DSS v4.0.1 Вимога 11 включає виявлення змін і підробок.
- Пункт 106 SEC очікує, що реєстрант опише свої процеси ідентифікації ризиків.
Кожна структура запитує, чи організація керує правилами виявлення як контрольованими артефактами, а не просто, чи існують правила.
Операційне тестування: з урахуванням правила, яке спрацювало в останньому кварталі, чи може команда продемонструвати його повну лінію спадковості? Хто написав його, хто переглянув, коли воно було востаннє змінене, чому, яке зобов’язання воно прив’язане, і яку техніку воно адресує. Платформа змісту виявлення, яка керує правилами як кодом з версіями, генерує цей слід як побічний продукт нормальних операцій.
Коли правила редагуються в консолі без управління версіями, аудитор не має походження для поточного стану правила. Управління Detection-as-Code видаляє цю неоднозначність за конструюванням.
Як покриття виявлення стає пунктом у розкладі відповідності?
Можливості виявлення, як правило, знаходяться в межах операційних бюджетів, видимі менеджеру SOC, невидимі фінансовому директору. Три факти роблять покриття обговоренням на засіданні ради директорів.
- Часовий інтервал звітності починається з виявлення. 4-годинний класифікаційний годинник DORA та 4-денний матеріальний годинник SEC обидва починаються, коли організація виявляє або ознайомлюється з інцидентом. Швидше виявлення є початком часової шкали відповідності.
- Докази виявлення підлягають аудиту. П’ять класів доказів, наведених вище, є тим, що переглядає аудитор. Їхнє виготовлення коштує часу та персоналу, незалежно від того, чи команда будує свої власні правила, чи підписується на джерело вмісту виявлення.
- Час до покриття є вимірюваним. Проміжок між тим, коли техніка стає публічною, і спрацюванням перевіреного виявлення в середовищі організації є відстежуваним.
Інженерна команда запитує можливості виявлення в термінах кадрового складу та інструментів. Команда з питань відповідності запитує це в термінах вироблення доказів. Друге формулювання прив’язує витрати на виявлення до регуляторного зобов’язання, за яким рада вже відстежує.
Аудит стійкості SIEM створює карту покриття, яку запитують аудитори: правила, прив’язані до MITRE ATT&CK, джерела журналів, прив’язані до тієї ж матриці, і перераховані прогалини з планом.
Зв’язатись з відділом продажів
Де це не тримається
Декілька обмежень застосовується.
Не кожне зобов’язання прив’язане до виявлення. Пункт 1.05 SEC вимагає розкриття, а не специфічних засобів контролю. Стаття 21 NIS2 і DORA обидві включають безпеку ланцюга постачання, безперервність бізнесу та управління доступом. Ніхто з них не орієнтований на техніки ATT&CK. ATT&CK організовує виявлення та моніторинг підмножини, а не повну площину відповідності.
Транспозиція NIS2 не завершена. Коли законодавство, яке є перетворенням держави-члена, не в силі, Статті 21 і 23 NIS2 не підлягають місцевому виконанню. Пропоновані у січні 2026 року зміни не перенумеровують Статті 21 чи 23.
Правила SEC оспорюються. The петиція про скасування проти Пункту 1.05, подана 22 травня 2025 року п’ятьма банківськими та цінними паперовими торговими асоціаціями (Файл SEC № 4-856), залишається нерешеною: станом на 21 вересня 2026 року SEC не запропонувало жодних змін до Пункту 1.05, хоча петиціонери оновили запит у листі коментаря в квітні 2026 року в рамках огляду Регламенту S-K Комісії. А заява від 21 травня 2024 року Еріка Гердінга, тодішнього директора підрозділу коропоративних фінансів, з’ясувала, що Пункт 1.05 зарезервований для інцидентів, які реєстрант визначив як матеріальні, і порадила розкривати інші інциденти під іншим пунктом, таким як Пункт 8.01; підрозділ продовжив роботу з інтерпретаціями дотримання та розкриття 24 червня 2024 року.
Номера підвимог відповідають v4.0.1. Підвимоги PCI DSS, наведені тут (10.4.1, 10.4.1.1, 10.5.1, 10.7, 10.7.2, 11.5.1, 11.5.2, 11.6.1) використовують нумерацію v4.0.1; сам стандарт знаходиться у Бібліотека документів PCI SSC, а Вимога 10.7.2 застосовується до всіх суб’єктів з 31 березня 2025 року.
ATT&CK є перехідником, а не зобов’язанням за регламентами. Прив’язування виявлень до технік ATT&CK організовує докази. Це не виконує жодне регуляторне зобов’язання, і жодна з розглянутих тут структур цього не вимагає.
DORA є спеціальним законом для фінансових установ. Банк у межах дії DORA не застосовує Статті 21 і 23 NIS2 поверх для власного управління ІКТ ризиками та звітності про інциденти. NIS2 досягає нефінансового ланцюга постачання банку, а не власних операцій з ІКТ банку.
ЧЕКЛІСТ ДОКАЗІВ АУДИТУ: ЗОБОВ'ЯЗАННЯ З ВИЯВЛЕННЯ
1. ЗІБРАНІ ДЖЕРЕЛА ЛОГІВ
[ ] Інвентаризація джерел телеметрії, які поглинаються
[ ] Докази безперервного збору (не на момент часу)
[ ] Кожне джерело прив'язане до систем, активів та
зобов'язання, які воно покриває
2. РОЗГОРНУТІ ПРАВИЛА
[ ] Інвентаризація правил виявлення з названими власниками
[ ] Кожне правило прив'язане до регуляторного зобов'язання, яке воно підтримує
[ ] Кожне правило прив'язане до техніки ATT&CK, де це можливо
(перехідник, не вимагається регламентами)
[ ] Пороги оповіщень задокументовані з обґрунтуванням
3. ДОКАЗИ СПРАЦЮВАННЯ
[ ] Докази, що правила спрацювали на реальних або змодельованих подіях
[ ] Записи, що оповіщення дійшли до визначених відповідальних
[ ] Датовані тести записів для механізмів виявлення
(Стаття 10 DORA)
4. ІСТОРІЯ ЗМІН
[ ] Управління версіями для кожного правила виявлення
(Detection-as-Code)
[ ] Автор, рецензент, часовий штамп і обґрунтування для кожної зміни
[ ] Слід перегляду та затвердження
[ ] Записи виявлення змін і підробок
5. ДАТОВАНИЙ ЗВІТ ПРО ПОКРИТТЯ
[ ] Звіт про покриття у певний момент часу з датою
[ ] Покриття вимірюється проти пріоритетного набору технік,
а не повної матриці ATT&CK
[ ] Дані про тенденції, що показують покриття з часом
[ ] Звітність для кожного середовища (не одне сукупне число)
РЕЖИМО-СПЕЦИФІЧНІ ПУНКТИ
[ ] DORA: пороги оповіщень задокументовані з обґрунтуванням
(Стаття 10)
[ ] DORA: часові мітки інцидентів на часових рамках звітності
(4 год з моменту класифікації / 24 год з моменту усвідомлення,
72 год проміжний, 1 місяць остаточний)
[ ] NIS2: докази прив'язані до національного законодавства, яке є перетворенням,
тільки не тексту директиви
[ ] PCI DSS v4.0.1: збереження журналів відповідно до застосовних
підвимог
[ ] SEC: задокументований процес визначення матеріальності
(Пункт 1.05)
[ ] SEC: роль наглядової та управлінської ради описана
(Пункт 106)
ПРИМІТКИ
- ATT&CK є перехідником, що використовується для організації цих доказів.
Це не вимагається DORA, NIS2, PCI DSS або правилами SEC.
- DORA є спеціальним законом: банк у межах дії DORA застосовує DORA,
а не Статті 21 і 23 NIS2, для управління ІКТ ризиками.
- PCI DSS v4.0.1 є єдиною активною версією
(v4.0 знято з 31 грудня 2024 року).
- Кожна регуляторна специфіка в цьому документі є підтвердженою
від ciso-cto-sme перед публікацією.
FAQ
Які докази виявлення підтверджують зобов’язання за PCI DSS 4.0 та DORA?
Обидва режими вимагають доказів постійного виявлення та моніторингу, а не просто доказів, що інструменти виявлення розгорнуті. П’ять класів доказів: зібрані джерела логів, розгорнуті правила виявлення з власниками, докази, що ці правила спрацьовують, історія змін із управлінням версіями та датований звіт про покриття. MITRE ATT&CK організовує ці докази за категорією поведінки супротивника. ATT&CK не вимагається жодною з рамок.
Які докази шукають аудитори, щоб підтвердити ефективність систем виявлення?
Аудитори шукають п’ять класів доказів: які джерела телеметрії зібрані і що їх збір є безперервним, правила виявлення, прив’язані до зобов’язань та технік ATT&CK із названими власниками, докази, що ці правила спрацьовують на реальних або змодельованих подіях, історія змін із управлінням версіями для кожного правила, та датований звіт про покриття в певний момент часу. Відсоток покриття сам по собі, без підтримуючих записів, не є доказом.
Чи задовольняє прив’язка виявлень до MITRE ATT&CK регулятора?
ATT&CK – це перехідник, що організовує докази виявлення за поведінкою супротивника. Він робить докази доступними для запитів і звітів за технікою. Це не саме собою виконує жодне регуляторне зобов’язання. DORA, NIS2, PCI DSS та правила SEC запитують докази роботи: моніторинг, виявлення, логування та розкриття. ATT&CK організовує ці докази. Жодна з розглянутих тут рамок цього не вимагає.
Які часові рамки звітності про інциденти за DORA та NIS2?
Згідно з DORA, Делегований Регламент (ЄС) 2025/301 встановлює часові рамки для великих інцидентів: початкове повідомлення протягом 4 годин з моменту класифікації інциденту як великого (не пізніше ніж через 24 години після усвідомлення), проміжний звіт протягом 72 годин після першого повідомлення та остаточний звіт протягом одного місяця після проміжного звіту. Згідно з NIS2, значущі інциденти потребують раннього застереження протягом 24 годин з моменту усвідомлення, повідомлення про інцидент протягом 72 годин, та остаточного звіту не пізніше ніж через місяць після повідомлення про інцидент. Обидві часові рамки починаються з виявлення, роблячи мітку на виявленні само^g собою аудиторським записом.
Власна розробка контенту SOC Prime реалізує виявлення у вашому SIEM або EDR та надає високорівневу документацію їхньої мети, функції та використання.
Зв’язатись з відділом продажів
Пов’язані матеріали для читання
- SIEM проти Управління Логами: Спостерігання, Телеметрія та Виявлення (Березень 2026)
- Ланцюги атак: Перегляньте повну історію кожної загрози (Серпень 2026)
- Постійна відповідність як код P1: Sigma (Серпень 2019)
