Реагування на кіберінциденти в Україні: роль CERT-UA і контролів ISO/IEC 27001 (2026)

Будь-яка компанія рано чи пізно стикається з кіберінцидентом. Фішинговий лист, який відкрив бухгалтер. Шифрувальник, що поклав файловий сервер уночі проти понеділка. Обліковий запис адміністратора, з якого раптом заходять о третій ночі з чужої країни. Питання не в тому, чи це станеться, а в тому, що ваша команда зробить у перші години після того, як це вже сталося.

Кіберінцидент — це подія, що вже порушила конфіденційність, цілісність або доступність ваших даних чи систем: витік, злам, недоступність сервісу, несанкціонований доступ. Кіберзахист будують, щоб таких подій було менше. Але жоден захист не дає стовідсоткової гарантії, тому поряд із превентивними заходами компанії потрібна відпрацьована процедура реагування: хто що робить, коли систему вже зламали, і коли до справи варто залучати CERT-UA.

Реагування на кіберінциденти має логіку від першого сигналу до висновків: помітити атаку, оцінити її, за потреби звернутися до CERT-UA, стримати шкоду і закрити діру, щоб той самий сценарій не повторився. Далі — кожен етап окремо, а поряд із ним контроль стандарту, розібраного в повному посібнику з ISO/IEC 27001, який робить цей етап обов'язковим, а не забутим у паніці.

CERT-UA розшифровується як Computer Emergency Response Team of Ukraine. Це не окреме відомство, а команда у складі Державної служби спеціального зв'язку та захисту інформації, яка діє на виконання Закону України «Про основні засади забезпечення кібербезпеки України». Простими словами, це ті, кому телефонують, коли щось пішло не так на державному чи критичному рівні, і хто допомагає розібратися з атакою.

Функції команди прямо перелічені на офіційному сайті CERT-UA: реагування на кіберінциденти та їх дослідження, моніторинг і виявлення загроз, накопичення й аналіз даних про атаки, допомога та рекомендації, міжнародна співпраця. Команда взаємодіє з підприємствами, установами й організаціями незалежно від форми власності — звернутися може і державний реєстр, і приватна ІТ-компанія.

Для бізнесу цінність CERT-UA не лише в тому, що туди можна поскаржитися після зламу. Команда публікує індикатори компрометації за конкретними хвилями атак, попередження про активні кампанії та рекомендації з кібергігієни — це безкоштовна розвідка, якою гріх не користуватися. Особливо це стосується ІТ- та SaaS-компаній, що стають частою мішенню саме через доступ до даних клієнтів.

Реагування — це не одна дія, а цикл із кількох етапів. Міжнародні методики і практика CERT-UA описують його схоже: підготовка, виявлення, оцінка, стримування, відновлення, висновки. ISO/IEC 27001 не називає ці етапи тими самими словами, але його контролі лягають на цикл майже один в один. Ось як вони збігаються.

Далі пройдемо цими етапами по черзі, з акцентом на два, де найчастіше все ламається: своєчасний детект і рішення про те, повідомляти CERT-UA чи ні.

Найдорожчі інциденти — не найскладніші технічно, а найдовше непомічені. Зловмисник, який тихо сидить у мережі місяцями, встигає значно більше за того, кого виявили за годину. Тому перший практичний етап реагування — це здатність узагалі побачити, що щось не так.

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

Тут спрацьовує контроль A.6.8 — повідомлення про події інформаційної безпеки. Його суть проста: будь-який співробітник має знати, куди за п'ять хвилин повідомити про підозрілий лист чи зниклий ноутбук, і бути впевненим, що за це не покарають. Культура «не скажу, бо влетить» вбиває реагування ще до його початку, і жодна технологія цього не компенсує.

Тут важливо не піддатися двом крайнощам. Ні паніці «нас оштрафують, якщо не доповімо про кожен спам», ні безпечності «ми приватна компанія, нас це взагалі не стосується». Реальність посередині, і залежить вона від того, хто ви за статусом.

Обов'язок інформувати CERT-UA про кібератаки й кіберінциденти прямо встановлений для об'єктів критичної інфраструктури — це енергетика, банки, телеком, транспорт, окремі державні реєстри. Для деяких категорій, як-от надавачі хмарних послуг і центрів обробки даних, порядок повідомлення прописаний окремими актами Держспецзв'язку, аж до затвердженої форми з маркуванням TLP. Якщо ваша компанія належить до критичної інфраструктури, повідомлення — не жест доброї волі, а вимога.

Якщо ж ви звичайний бізнес без такого статусу — умовний інтернет-магазин, агенція чи продуктова ІТ-компанія, — загального обов'язку доповідати про кожен інцидент немає. Це важливо сказати чесно: нормативи не вимагають від будь-якого бізнесу звітувати CERT-UA просто тому, що стався інцидент.

Навіть коли повідомлення добровільне, звернутися часто варто: команда може підказати, чи це частина ширшої кампанії, надати індикатори компрометації і допомогти зорієнтуватися з відновленням. Базовий канал простий — лист на incidents@cert.gov.ua з описом того, що сталося, коли й на яких системах. Коли й у якому обсязі це доречно, команда пояснює у власній інструкції коли і як звертатися до CERT-UA. Що детальніший опис — час виявлення, ознаки, вжиті дії, — то швидша й корисніша відповідь.

Тримайте в голові одну межу. Витік персональних даних — це інша правова площина, ніж технічний кіберінцидент. Повідомлення про нього йде не до CERT-UA, а до Уповноваженого Верховної Ради України з прав людини і регулюється окремим законом про захист персональних даних. Технічний бік атаки може супроводжувати CERT-UA, а відповідальність за дані людей — це вже стосунки з омбудсменом. Один інцидент інколи вимагає обох дій одночасно.

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

Мінімальний порядок дій на етапі стримування виглядає так:

• Ізолюйте, а не вимикайте наосліп. Від'єднати заражену машину від мережі краще, ніж різко знеструмити її: частина доказів живе в оперативній пам'яті й зникає при вимкненні.
• Збережіть логи, поки їх не перезаписала ротація. Це і є контроль A.5.28 — збір доказів: логи, образи дисків, копії підозрілих листів, зібрані так, щоб витримати і внутрішнє розслідування, і за потреби поліцію.
• Змініть скомпрометовані доступи. Паролі, ключі й токени, які могли потрапити до зловмисника, стають безпечними лише після заміни.
• Фіксуйте час і дії. Хто що зробив і коли — проста таблиця подій рятує на етапі висновків, коли деталі вже стерлися з пам'яті.

Відновлення — це повернення систем із чистих резервних копій, а не поспішне «підняли як було». Контроль A.5.26, реагування на інциденти, вимагає керованих дій за наперед визначеною процедурою, а не героїчної імпровізації одного адміністратора, який єдиний знає, де що лежить. І якщо цей адміністратор у відпустці — а він завжди у відпустці саме в такі моменти, — процедура має спрацювати без нього. Резервна копія, яку жодного разу не пробували відновити, це не резервна копія, а надія.

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

Контроль A.5.27, навчання на основі інцидентів, вимагає перетворити кожен серйозний випадок на конкретні зміни. Не звіт для галочки, а відповіді на прості питання: як зловмисник зайшов, чому ми помітили це не одразу, що в наших процесах це дозволило і що саме ми міняємо. Результат — оновлені правила, нові сповіщення, іноді донавчання людей, які клікнули на те, на що не варто було.

У системі управління інформаційною безпекою цей етап замикає цикл: висновки з інциденту повертаються в оцінку ризиків, а звідти — у перегляд контролів. Так реагування перестає бути хаотичною реакцією й стає частиною постійного кіберзахисту. Це і є різниця між «у нас є антивірус» і «у нас є система».

Тему управління інцидентами інформаційної безпеки в ISO/IEC 27001:2022 покривають шість контролів Annex A. Вони не пишуть за вас процедуру, але задають перелік того, що взагалі має існувати й працювати. Ось вони простою мовою:

• A.5.24 — планування та підготовка. Ролі, відповідальні, канали зв'язку й плани реагування визначені заздалегідь, а не вигадуються під час атаки.
• A.5.25 — оцінка й рішення. Є критерії, які відрізняють дрібну подію від справжнього інциденту, і зрозуміло, хто ухвалює рішення про ескалацію.
• A.5.26 — реагування. Дії виконуються за задокументованою процедурою, а імпровізація зведена до мінімуму.
• A.5.27 — навчання на основі інцидентів. Висновки перетворюються на зміни в системі, а не осідають у забутому звіті.
• A.5.28 — збір доказів. Логи й артефакти зберігаються так, щоб мати вагу і в розслідуванні, і в суді.
• A.6.8 — повідомлення про події. Кожен співробітник знає, як і кому повідомити про підозру, швидко й без страху покарання.

Разом ці шість контролів дають те, чого не дає жоден окремий інструмент, — передбачуваність. Сертифікаційний аудит ISO/IEC 27001 перевіряє не наявність красивих політик у файлі, а чи справді компанія знає, що робитиме о третій ночі в неділю. Повний перелік вимог стандарту й етапи впровадження ми розбирали в посібнику з ISO/IEC 27001.

Швидка самоперевірка. Якщо на більшість пунктів відповідь «так», ваша компанія реагуватиме, а не панікуватиме:

• Є актуальний список відповідальних за реагування, з номерами, які працюють і вночі.
• Співробітники знають один канал, куди за хвилину повідомити про підозрілий лист чи пристрій.
• Визначено, що саме вважається інцидентом і хто вирішує про ескалацію.
• Резервні копії ключових систем існують, і їх хоча б раз пробували відновлювати.
• Прописано, у яких випадках звертатися до CERT-UA, а в яких — до Уповноваженого з прав людини щодо персональних даних.
• Логи зберігаються достатньо довго, щоб після інциденту було що аналізувати.
• Після кожного серйозного випадку проводиться короткий розбір із конкретними змінами.

Якщо половина пунктів залишилася без відповіді, це не привід для сорому, а список завдань на найближчий місяць. І майже кожен із них — це один із контролів ISO/IEC 27001, а не окрема бюрократія заради паперу.

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

Ekontrol супроводжує підготовку до ISO/IEC 27001 як частину напряму інформаційної безпеки. Реагування на інциденти тут не окрема послуга, а частина системи: під час попередньої оцінки готовності команда дивиться, чи є у вас плани, ролі й канали, передбачені контролями A.5.24–A.5.28 та A.6.8, і де насправді дірки, про які ви ще не знаєте.

Далі йде впровадження: процедура реагування, порядок звернення до CERT-UA для тих, кому це потрібно за законом, розмежування з повідомленням про витік персональних даних, збір доказів, навчання команди й репетиція сценарію. Для ІТ-компаній, що працюють із клієнтами з ЄС і США, це ще й готова відповідь на security-опитувальниках, де питання про incident response ставлять майже завжди.

Якщо ви хочете, щоб реагування на кіберінциденти у вашій компанії трималося на процедурі, а не на удачі, деталі про сертифікацію ISO/IEC 27001 і форма першої консультації є на сайті. Можна також одразу написати нашій команді й обговорити, з чого почати. Ekontrol працює як партнер Bureau Veritas в Україні з 2014 року.