Пентест — потужний інструмент, але аж ніяк не перший крок. Якщо базового захисту немає, перевірка лише підтвердить очевидне: «зламати можна, і легко». Розберемо, де саме вона стоїть у стратегії кібербезпеки, коли виправдана, коли гроші краще витратити інакше — і чия це взагалі зона відповідальності. Як усе влаштовано технічно — в оглядовій статті Пентест: що це і як проходить.
Що пентест дає — і чого не дає
Дає: підтверджені шляхи атаки замість теоретичних ризиків, які досі жили лише в реєстрі. Показує, як три дрібниці, кожна з яких окремо здається безневинною, складаються в робочий сценарій зламу.
Не дає: сталого захисту. Це знімок стану однієї дати. Завтра вийде нова версія бібліотеки, з'явиться свіжий дефект — і знімок застаріє. Перевірка не замінює ані процедур, ані засобів захисту, ані людей, які читають журнали.
Чия це зона: IT чи безпека
Одну й ту саму послугу в пошуку набирають по-різному — і формулювання видає, до чиєї відповідальності її відносять:
- penetration testing IT та IT penetration testing — перевірку вважають завданням технічного відділу;
- penetration testing безпеки й penetration testing кібербезпеки — її відносять до служби захисту;
- тестування на проникнення IT, тестування на проникнення безпеки, тестування на проникнення кібербезпеки — ті самі запити українською.
Порядок слів результату пошуку не змінює. А от відповідь щодо зони відповідальності змінює багато чого. Робочий розподіл такий:
- замовляє й приймає результат власник ризику — керівник напряму, чий бізнес постраждає;
- виправляє знайдене технічний відділ;
- веде процес і стежить за строками служба безпеки.
Класична пастка: перевірку замовляє те саме ІТ, чиї помилки вона й шукає. Межі тихо звужуються до безпечних, а звіт лягає в теку «врахуємо».
Коли для перевірки зарано
Якщо в компанії досі:
- немає переліку систем — мало хто скаже напевно, що взагалі працює (див. реєстр інформаційних активів);
- не оновлюється програмне забезпечення, відомі діри роками відкриті;
- відсутній базовий контроль доступу й двофакторна автентифікація;
- немає резервних копій із перевіреним відновленням;
- інфраструктура пласка, без поділу зон.
Тоді пентест знайде десятки очевидних проблем, а ви заплатите за те, що й так відомо. Просте правило: якщо ви заздалегідь знаєте, що напишуть у звіті, платити за звіт немає сенсу. Спершу — базова гігієна й сканування вразливостей, яке дешевше й дає ту саму «низько висячу» картину.
Ознаки готовності: п'ять питань
Швидкий самотест перед підписанням договору:
- Чи є актуальний перелік систем — і чи має кожна власника?
- Чи працює процедура оновлень із термінами, а не «коли дійдуть руки»?
- Чи є резервні копії, які хоч раз розгортали по-справжньому?
- Чи прибираються доступи після звільнення?
- Чи читає хтось журнали — і помітить, коли команда почне роботу?
Чотири «так» із п'яти — можна замовляти. Два — спершу закривайте базу.
Коли пентест справді потрібен
- Базовий захист уже є, і треба переконатися, чи він працює насправді.
- Перед запуском нового сервісу, застосунку або великого оновлення.
- Після суттєвих змін: переїзд у хмару, злиття, новий підрядник, зміна архітектури.
- Зовнішня вимога — партнер, тендер, страховик, стандарт.
- Чутливі дані або привабливість мішені — фінанси, медицина, критична інфраструктура.
- Після інциденту — переконатися, що всі шляхи закрито.
Окремо про строки. Пентест перед релізом призначають завчасно: треба закласти час для виправлень та повторного прогону. Інакше ви отримаєте звіт, який уже нікому не потрібен, — реліз усе одно поїде.
Драбина зрілості: де стоїть пентест
Логічна послідовність, у якій вибудовується кібербезпека компанії:
- Інвентаризація — знати, що ми захищаємо.
- Оцінка ризиків — розуміти, що для компанії критично (див. ISO 27005).
- Базові заходи — оновлення, доступи, поділ зон, резервні копії.
- Управління вразливостями — регулярне сканування й усунення знайденого.
- Пентест — іспит, чи все це справді працює.
- Моніторинг і реагування — SIEM і SOC, план дій при інциденті.
Тобто пентест — це іспит зрілості, а не її замінник. Керовану систему навколо всіх шести сходинок описує СУІБ.
Зовнішній тиск: хто зазвичай просить звіт
Ініціатором рідко буває технічний відділ. Найчастіше просять іззовні:
- партнер або великий клієнт перед підписанням договору;
- тендер, де незалежний звіт — умова допуску;
- стандарт: ISO 27001 вимагає керованої роботи зі слабкими місцями (контроль 8.8), і незалежна перевірка — природний спосіб довести, що процес живий (див. технічні контролі ISO 27001);
- інвестор або покупець — під час перевірки перед угодою;
- страховик кіберризиків.
Важлива точність: сам собою ISO 27001 пентесту не вимагає. Стандарт вимагає керувати вразливостями й перевіряти дієвість заходів. Але аудитор запитає, звідки ви знаєте, що заходи працюють, — і незалежна перевірка стає найпростішою відповіддю.
Як часто
Загальна практика — щонайменше раз на рік, а також після значних змін в інфраструктурі чи застосунках. У проміжках працює регулярне сканування.
Але календар — не головне. Якщо за рік інфраструктура лишилася тією самою, а список сервісів тим самим, річний прогін у тих самих межах дасть майже ідентичний звіт. Прив'язуйте перевірку до змін, а не лише до дати: новий сервіс, нова хмара, новий підрядник, нова архітектура. Різні цілі потребують різних робіт — мережа і сайт із застосунками перевіряються по-різному.
Якщо звіту вимагають, а ви ще не готові
Ситуація типова: партнер просить документ, а базу ще не закрито. Три робочі варіанти:
- Провести свідомо — розуміючи, що звіт буде довгим, і одразу заклавши бюджет для виправлень.
- Спершу закрити очевидне — сканування, оновлення, доступи, копії; повноцінна перевірка — після цього.
- Домовитися про строк — партнерові часто достатньо плану усунення зараз і незалежної перевірки за квартал.
Найгірший сценарій — провести, отримати звіт і нічого не змінити. Тоді у вас з'явиться документ, який доводить: ви знали.
Не впевнені, чи час для перевірки? Фахівці оцінять зрілість захисту й підкажуть, із чого почати саме вам — отримати консультацію.