Автор: Андрій Михалюк, CEO CoreWin
Вітаю колег з кібербезпеки й не тільки. Сьогодні хотів би обговорити класичне питання для всього IT-сектору. Як відновлюватись?
Звісно, хотілося б жити в ідеальному світі, де пінг завжди стабільний, оперативка і процесор на всіх системах навантажені не більше ніж на 80% і дані ніколи не під загрозою. Але ми живемо в реальності, саме в тій, що відбувається за вікном, і в тій, яку обслуговують наші роутери та комутатори.
Кожен спеціаліст у сфері інформаційних технологій або вже мав досвід відновлення після інциденту чи поломки або буде мати цей досвід. На жаль, це частина нашої професії, і наскільки добре ми б не планували та адміністрували наші системи (що, звісно, варто робити в першу чергу), халепи трапляються і точно ще траплятимуться на нашій практиці.
Відновлення: що рекомендує NIST?
Дякую всім, хто прочитав вступ і дочитав до цих рядків 😊 Я хотів би підняти тему відновлення систем саме після кіберінциденту, а також особливостей та викликів, з якими ми стикаємось сьогодні.
Для початку видам базу. Що пише книжка? Згідно з NIST SP 800-61 Rev. 2, є 4 етапи реакції на інцидент:
- Підготовка
- Виявлення й аналіз
- Локалізація, ліквідація та відновлення
- Засвоєння уроків
Як зрозуміло зі вступу, я говоритиму про частину 3 етапу, її останню фазу. Тобто приймемо як гіпотезу, що загрозу вже виявлено, локалізовано і ліквідовано.
Також зверну увагу, що NIST – це прямо базована база, і про кожен з пунктів можна написати не те що статтю, а книжку. Тому, якщо ви ще не мали можливості ознайомитися з цим фреймворком, дуже рекомендую. Якщо є натхнення, можна прочитати повний текст, знайти огляд методології стисло, або навіть подкаст чи відеоогляд і послухати по дорозі на роботу, воно того вартує.
Для того, щоб дотриматись формату статті в блог і не розписувати 50 сторінок тексту, приймемо як спрощення, що кіберзагрози, в широкому сенсі, діляться на два основних типи: шкідливі програмні засоби та націлені атаки.
Перші – це, як правило, масові атаки автоматизованими методами, інші – цілеспрямовані кампанії злочинних груп.
Таке спрощення варто зробити «на березі», оскільки саме в цій парадигмі криються тенденції дій кіберзлочинців останніх двох років.
Тенденції
- Ліквідацію та відновлення більше не можна сприймати як одну і ту саму дію. Іншими словами: видалити вірус з усіх систем не означає відновлення безпеки периметра.
- Різні категорії зловмисників оптимізують атаку по-різному. Частина (як правило оператори ransomware) націлюються на швидкість і максимальну шкоду, інша (часто групи, що спонсоруються державами) – на тривале непомітне перебування, або «extreme persistence».
- З’явились спеціалізовані групи, для яких сам доступ вже є активом, кінцевою метою операції. Їхня діяльність спрямована лише на компрометацію з ціллю подальшого перепродажу отриманих доступів іншій групі.
- Перебування зловмисників (прихований доступ в периметрі) часто знаходиться не там, де звикли шукати безпековики. Це можуть бути VPN- і firewall-системи, DevOps pipelines та скомпрометовані токени хмари, тому подібне. Тобто фокусуватись тільки на класичному endpoint – вже не достатньо.
Детальніше про сучасні тенденції атак і поведінку зловмисників можна прочитати у M-Trends 2026 та матеріалах Держспецзв’язку.
Чому усунення загрози не означає завершення інциденту?
Що це нам говорить в контексті поставленої задачі? А саме, як це вплинуло на етап відновлення?
На практиці інцидент фіксується з моменту ідентифікації. Система моніторингу, наприклад, SIEM, або спеціальна команда, наприклад, SOC, реєструє відповідну подію з великим червоним заголовком, умовним номером.
Електронні листи летять CISO та відповідальному підрозділу (наприклад, product owner ураженої системи). Далі всі етапи прийняття: заперечення, гнів, торг і далі по тексту, аж допоки не усунеться причина інциденту.
Бачите як, у цій парадигмі нею вважається той ідентифікатор, на який спрацювала система виявлення. Хай то неправомірний доступ з невідомого джерела, компрометація продуктової системи чи неавторизована передача конфіденційної інформації.
Але, як ми бачимо вище, реальність (так само, як і та, що за вікном) інша. Такий сигнал не можна сприймати як ізольовану історію.
Він геть не означає, що йдеться про початковий етап атаки, це може бути ідентифікатором розширення по мережі, перевірка цінності файлу, спроба відкрити додатковий бекдор.
При цьому сам зловмисник вже може мати доступ до корпоративної техніки через принтер чи кавомашину з WIFI-модулем.
Те, що я напишу далі, не означає, що не варто займатись аналізом й ідентифікацією загроз. Навпаки, засобів виявлення та захисту, має бути якомога більше.
Наприклад:
- EDR/XDR (Cynet)
- DLP (Netwrix Endpoint Protector)
- IAM (Identity Manager)
- аудит AD (Auditor)
- сканер мережі (OPENVAS Enterprise)
- антивірус
- фаєрвол
- VPN
- SIEM
Все це потрібно і навіть необхідно для реалізації наступної концепції.
Від окремих інцидентів до повної картини атаки
Суть концепції. Ми з вами обговорили стан справ, окреслили проблему. Логічне питання – і що нам з цим робити? Тут я викладу свою ідею до обговорення спільнотою.
Мені спадає на думку ситуація, з якою зіткнувся бізнес років 10 тому, а саме проблема Big Data. Так-так, саме той хайповий термін який свого часу пхали в кожну публікацію (десь як зараз відбувається з AI).
Основна складність тоді для фінансистів, продавців, логістів була подібною до тієї, з якою зараз стикається кібербезпека. Інформації стало занадто багато, вона стала занадто розрізненою та без спільних знаменників. А вікно прийняття рішення скоротилось з місяців і років до тижнів, а то і днів.
Свого часу проблему було вирішено комплексом інструментів, таких як Data Virtualization, Data Lake (тобто прошарок для збору й агрегації даних) і Business Intelligence та Data Analysis (для адаптації об’єднаних даних до опрацювання менеджментом).
Осмілюсь запропонувати ідею залучити цей підхід до кібербезпеки. Не лише збирати дані для виявлення інциденту тут і зараз (з цим справляються SIEM та SOC), але й сформувати наступний шар аналізу – збір критичних подій безпеки, їх кореляція для виявлення зв’язків між ними.
Не тільки реагувати на 1 злочин (як патрульна машина, яка виїжджає на місце вбивства), але й зібрати інформацію про всі подібні випадки і докази з них, і спробувати розкрити злочинне угруповання чи маніяка.
Це вже робота умовного відділу розслідувань, де спеціаліст з безпеки може діяти як Шерлок на максималках, швидко формуючи картину подій з використанням власного досвіду й інтелекту.
Такий підхід також дозволить виявити «ждунів» у вашому периметрі на ранніх стадіях, коли після непомітної компрометації зловмисник тільки вивчає інфраструктуру і через необізнаність тригерить на перший погляд не пов’язані між собою алерти.
Відновлення роботи та перевірка безпеки
Але повернемось з країни рожевих поні та «було б добре» до реальності. Навіть без спеціального інструменту, кожному з нас у сфері кібербезпеки треба визнати:
Інцидент варто вважати завершеним не тоді, коли відновився сервіс, а тоді, коли команда може аргументовано пояснити: як зловмисник увійшов, куди він дійшов, які механізми доступу міг створити, чому кожен із них більше не працює – і якою телеметрією це підтверджується.
Як вирішувати цей виклик тут і зараз – питання відкрите.
Очевидно, що необхідно активно працювати з командою реагування на інциденти. А якщо такої групи фахівців немає, варто хоча б доручити ці завдання комусь із працівників і почати діяти.
А далі питання до CISO: як організувати не лише реакцію, але і ретроспективний аналіз виявлених загроз? Як їх корелювати і складати карту можливих дій зловмисників, що приховуються у вашому периметрі?
І зрештою знайти гадину і викинути зі своїх систем 😊
