Директива (ЄС) 2022/2555, відома як NIS2, замінила первісну директиву NIS 2016 року; термін її перенесення в національне право сплив 17 жовтня 2024 року. Вона суттєво розширює коло організацій, що підпадають під законодавство ЄС про кібербезпеку, і підвищує вимоги до управління ризиками, корпоративного врядування та звітування про інциденти. Якщо ви володієте вебзастосунками, API чи онлайн-сервісами в ЄС, ця стаття пояснює — практично й неюридично — де ви можете опинитися та як тестування безпеки підтримує ваші обов’язки.
Хто підпадає під дію
NIS2 поширюється на середні та великі організації (як правило, 50+ працівників або оборот від 10 млн €) у перелічених секторах. Їх поділяють на дві категорії:
- Суттєві суб’єкти (Додаток I): енергетика, транспорт, банківська справа, інфраструктура фінансового ринку, охорона здоров’я, питна вода та стічні води, цифрова інфраструктура (DNS, реєстри TLD, хмара, ЦОД, CDN), управління ІКТ-послугами, державне управління та космос.
- Важливі суб’єкти (Додаток II): поштові послуги, поводження з відходами, хімія, харчові продукти, виробництво, цифрові провайдери (онлайн-маркетплейси, пошуковики, соцмережі) і дослідження.
Пороги розміру — не єдиний критерій: деякі суб’єкти підпадають під дію незалежно від розміру (наприклад, реєстри DNS і TLD чи кваліфіковані надавачі довірчих послуг). Важливо, що NIS2 сягає вашого ланцюга постачання: навіть якщо ви не підпадаєте напряму, підпадаючий клієнт передасть ці вимоги вам договором.
Обов’язки з управління ризиками (стаття 21)
Стаття 21 вимагає належних і пропорційних технічних, операційних та організаційних заходів на основі підходу «усі загрози». Директива називає мінімальний набір, який добре лягає на визнані фреймворки, як-от ISO/IEC 27001 і NIST Cybersecurity Framework:
- Аналіз ризиків і політики безпеки інформаційних систем
- Обробка інцидентів (виявлення, реагування, відновлення)
- Безперервність діяльності, управління резервними копіями та кризове управління
- Безпека ланцюга постачання, включно з відносинами з прямими постачальниками
- Безпека при придбанні, розробці та супроводі — включно з обробкою та розкриттям вразливостей
- Політики оцінки ефективності заходів (тобто тестування та аудит)
- Базова кібергігієна та навчання
- Політики криптографії та шифрування
- Контроль доступу, управління активами та багатофакторна автентифікація
Два моменти варто підкреслити. По-перше, органи управління зобов’язані затверджувати та контролювати ці заходи й можуть нести відповідальність (стаття 20) — кібербезпека тепер обов’язок рівня ради директорів, а не лише питання ІТ. По-друге, вимога оцінювати ефективність робить тестування практично обов’язковим.
Звітування про інциденти: годинник 24/72 (стаття 23)
NIS2 встановлює суворий багатоетапний графік для значних інцидентів (що спричиняють серйозні операційні збої, фінансові втрати чи істотну шкоду іншим):
- Протягом 24 годин — раннє попередження до CSIRT або компетентного органу із зазначенням, чи підозрюється протиправний/зловмисний характер і чи можливий транскордонний вплив.
- Протягом 72 годин — повідомлення про інцидент із первинною оцінкою, серйозністю, впливом та індикаторами компрометації (IoC).
- На запит — проміжне оновлення статусу.
- Протягом одного місяця — підсумковий звіт із кореневою причиною, заходами усунення та транскордонним впливом.
Терміни стислі. Їх дотримання вимагає логування, виявлення та заздалегідь відпрацьованого плану реагування на інциденти, а не імпровізації під час атаки.
Як пентест і аудити безпеки підтримують відповідність
NIS2 не приписує конкретної методики тестування, але пентест — це найпряміший доказ того, що ви оцінили ефективність заходів і що ваш процес обробки вразливостей працює. Конкретно тестування підтримує одразу кілька пунктів статті 21:
- Обробка вразливостей — тест на основі OWASP Top 10 та OWASP Web Security Testing Guide (WSTG) виявляє проблеми на кшталт порушеного контролю доступу (A01), ін’єкцій (A03) і SSRF (A10) раніше за атакувальників.
- Пріоритизація з CVSS — вразливості, оцінені за CVSS v3.1/v4.0, дозволяють робити тріаж і демонструвати ризик-орієнтований підхід, а зіставлення з CWE і MITRE ATT&CK показує аналітичну строгість.
- Оцінка ефективності — повторне тестування після усунення дає документований доказ, що виправлення справді закрили пролом.
- Гарантії для ланцюга постачання — звіт, яким можна поділитися, дає вашим підпадаючим клієнтам докази, потрібні для їхніх власних обов’язків за NIS2.
- Готовність до інцидентів — вправи red team / purple team перевіряють, чи справді спрацьовує ваш ланцюг виявлення та звітування 24/72 год.
Обґрунтована періодичність — щонайменше щорічне тестування плюс повторний тест після будь-якої значної зміни систем, доступних з інтернету, доповнене безперервним скануванням вразливостей між роботами.
Практичні наступні кроки
- Визначте свою сферу: сектор (Додаток I/II), пороги розміру та будь-які критерії, незалежні від розміру.
- Зіставте наявні заходи контролю з мінімальним набором статті 21; візьміть ISO/IEC 27001 або NIST CSF за основу.
- Побудуйте та відрепетируйте план реагування на інциденти відповідно до графіку 24/72 год / один місяць.
- Замовте пентест на основі OWASP/WSTG з вразливостями, оціненими за CVSS, і повторним тестом після усунення.
- Передайте аналогічні вимоги власним постачальникам.
Ця стаття — практичні рекомендації, а не юридична консультація. Точні обов’язки залежать від закону про перенесення у вашій державі-члені та класифікації суб’єкта — уточніть деталі у кваліфікованого юриста та в національному CSIRT.