Одного пентесту на рік вже недостатньо: як часто насправді потрібно перевіряти безпеку компанії

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

Сьогодні ситуація кардинально інша.

Сучасні компанії постійно розгортають нові сервіси, оновлюють програмне забезпечення, інтегрують хмарні рішення та підключають зовнішніх постачальників послуг. У результаті поверхня атаки змінюється щотижня або навіть щодня.

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

В цій статті ми розглянемо:

• чому компанії досі проводять тестування лише раз на рік;
• які ризики виникають між перевірками;
• коли необхідно проводити позапланову оцінку безпеки;
• як визначити оптимальну періодичність тестування для різних типів бізнесу.

Чому щорічне тестування стало стандартом

Основною причиною є вимоги нормативних документів та стандартів.

Наприклад:

• стандарт платіжної безпеки PCI DSS вимагає проводити тестування щонайменше один раз на рік та після суттєвих змін у середовищі;
• стандарт ISO 27001 вимагає регулярної перевірки безпеки, але не встановлює конкретного інтервалу;
• аудитори SOC 2 очікують підтвердження регулярних перевірок, однак також не визначають чітку періодичність.

Через це багато організацій орієнтуються на мінімальні вимоги та проводять тестування один раз на рік перед аудитом.

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

Однак загрози змінюються набагато швидше, ніж графік перевірок.

Що змінюється між щорічними перевірками

Проміжок між двома тестуваннями рідко буває стабільним.

За цей час можуть відбутися десятки подій, які безпосередньо впливають на рівень кібербезпеки.

Оновлення програмного забезпечення

Кожна нова функція означає новий програмний код, тому з часом можуть змінюватися такі важливі компоненти системи:

• механізми автентифікації;
• бізнес-логіка;
• інтерфейси прикладного програмування;
• інтеграції із зовнішніми сервісами.

Система, перевірена у січні, у жовтні може суттєво відрізнятися від тієї, що проходила тестування.

Зміни в хмарній інфраструктурі

Хмарні середовища постійно змінюються, а це часто призводить до появи таких типових проблем безпеки:

• помилково відкриті мережеві порти;
• неправильно налаштовані сховища даних;
• використання шаблонів розгортання без перевірки параметрів безпеки;
• накопичення помилок конфігурації.

Зміни в команді

Кадрові зміни також впливають на безпеку.

Серед поширених ризиків:

• колишні співробітники зберігають доступ до систем;
• нові працівники отримують надмірні привілеї;
• облікові записи підрядників не видаляються після завершення проєкту.

Нові інтеграції

Маркетингові платформи, системи аналітики, сервіси оплати, розширення для браузерів та інші інструменти постійно підключаються до корпоративних систем.

Кожна така інтеграція створює нові точки потенційного проникнення.

Чому проблема стає дедалі актуальнішою

Кількість вразливостей продовжує зростати рекордними темпами.

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

Багато кіберзлочинців починають використовувати нові вразливості вже через кілька днів після їх оприлюднення.

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

Схема: як накопичуються ризики між тестуваннями

Коли необхідно проводити позапланове тестування

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

Після великого оновлення продукту

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

Після міграції інфраструктури

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

Після злиття або поглинання компанії

Після злиття або поглинання компанії ІТ-інфраструктура, програмне забезпечення та цифрові активи нової організації часто об’єднуються з різних середовищ. В таких випадках можуть з’явитися невідомі вразливості, застарілі системи, помилки конфігурації або невідповідності політикам безпеки. Проведення аудиту дозволяє своєчасно виявити потенційні ризики, оцінити рівень захищеності нових активів і забезпечити безпечну інтеграцію всіх систем у єдину інфраструктуру.

Після інциденту безпеки

Навіть якщо атаку вдалося локалізувати, необхідно переконатися, що зловмисники не залишили механізми прихованого доступу.

Як часто потрібно проводити тестування на проникнення

Таблиця рекомендованої періодичності проводення пентесту

Якою має бути сучасна програма тестування

Сучасне тестування на проникнення повинно бути частиною процесу управління ризиками, а не одноразовою перевіркою перед аудитом.

Ефективна програма включає:

• регулярне тестування зовнішнього периметра;
• перевірку вебзастосунків;
• аналіз хмарної інфраструктури;
• повторні перевірки після усунення недоліків;
• тестування після значних змін середовища;
• контроль безпеки сторонніх інтеграцій.

Висновок

Щорічне тестування на проникнення більше не відповідає швидкості змін сучасного бізнесу.

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

Оптимальна періодичність визначається не вимогами стандартів, а тим, наскільки швидко змінюється ваша інфраструктура та наскільки критичними є наслідки потенційного інциденту.

Фахівці ESKA допомагають побудувати програму тестування на проникнення, яка відповідає реальним ризикам бізнесу, а не лише формальним вимогам регуляторів.