Як часто робити пентест?

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

Нижче таблиця подій, після яких потрібен новий тест, що саме перевіряти і наскільки глибоко, що кажуть PCI DSS, DORA і NIST, і як скласти графік перевірок на рік.

Коротко

• Базовий ритм: один пентест на рік для кожної важливої системи. Так його описують PCI DSS для платіжного середовища і NIST для мережі компанії. ^{[1] [4]}
• Річний графік не скасовує тестів після змін. Новий платіжний модуль, нове API чи переїзд у хмару перевіряють до запуску або одразу після.
• Між пентестами працює сканування вразливостей, наприклад щокварталу і після змін. Воно знаходить відомі проблеми, але не бачить помилок логіки.
• Після виправлень потрібен ретест. PCI DSS прямо вимагає повторити тест, щоб підтвердити виправлення. ^[1]
• Фінансові компанії в ЄС за DORA щороку тестують системи критичних функцій, а визначені регулятором установи раз на три роки проходять TLPT. ^[3]

Чому календаря мало: пентест показує стан на одну дату

Будь-яка оцінка безпеки дає знімок системи на момент перевірки. NIST пише про це прямо і додає, що через це компанії можуть вимагати частіших перевірок. ^[4] Через місяць після звіту команда випускає новий функціонал, відкриває API партнеру, змінює права доступу. Звіт лишився тим самим, а система вже інша.

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

Коли потрібен новий пентест: таблиця подій

Що вважати суттєвою зміною, компанія вирішує сама. Рада PCI SSC у посібнику з пентесту пояснює: це залежить від оцінки ризиків і конфігурації середовища, а зміну, яка може вплинути на безпеку мережі чи доступ до даних карток, можна вважати суттєвою. ^[5] Просте правило для будь-якої галузі: якщо зміна торкається входу, прав доступу, грошей або персональних даних, вона суттєва.

Для хмари окремо пояснюю, що перевіряють, у статті пентест хмари AWS, Azure і GCP. Для приєднаної компанії зручно почати з Security Assessment: він показує загальну картину до глибокого тестування.

Що кажуть стандарти і регулятори

PCI DSS (стандарт безпеки даних платіжних карток). Пентест описує вимога 11.4. Внутрішній (11.4.2) і зовнішній (11.4.3) пентест роблять щонайменше раз на 12 місяців і після будь-якого суттєвого оновлення чи зміни інфраструктури або застосунку. Знайдені вразливості виправляють, а тест повторюють, щоб підтвердити виправлення (11.4.4). ^[1] Якщо середовище карткових даних відокремлене сегментацією, її перевіряють раз на 12 місяців і після змін (11.4.5), а сервіс-провайдери раз на шість місяців (11.4.6). ^{[1] [2]} Сканування вразливостей стандарт вимагає щонайменше раз на три місяці (11.3.1 і 11.3.2). ^[1] Чинна версія 4.0.1 вийшла в червні 2024 року і не додала нових вимог порівняно з 4.0. ^[6]

DORA (регламент ЄС 2022/2554 про цифрову операційну стійкість фінансового сектору, діє з 17 січня 2025 року). Фінансові установи, крім мікропідприємств, щонайменше раз на рік тестують усі ІКТ-системи і застосунки, що підтримують критичні або важливі функції (стаття 24(6)). Пентест прямо названо серед таких тестів (стаття 25(1)). Установи, яких визначив регулятор, щонайменше раз на три роки проходять TLPT, тобто пентест на основі розвідки загроз на робочих системах (стаття 26). Регулятор може зменшити або збільшити цю частоту. ^[3] Чим такий тест відрізняється від звичайного пентесту, пояснюю в статті Red Team чи пентест.

NIST SP 800-115 (технічний посібник NIST з тестування безпеки). Через вартість і можливий вплив на робочі системи пентест мережі раз на рік може бути достатнім. Між пентестами NIST радить регулярне сканування мережі і вразливостей. Частоту часто визначають вимоги, які компанія мусить виконувати, а ресурси насамперед ідуть на найважливіші системи. ^[4]

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

Графік на рік для компанії з власним продуктом

Пентест і сканування виконують різну роботу, тому в графіку є обидва:

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

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

Типові помилки

• Один пентест на рік і жодного після змін. Великий реліз через місяць після звіту лишається неперевіреним до наступного року.
• Щороку той самий обсяг. Минулого року тестували сайт, а цього року з’явилися мобільний застосунок і API. Межі переглядають перед кожним тестом.
• Сканування замість пентесту. Сканер не знайде, що покупець бачить чужі замовлення, якщо змінить номер у запиті.
• Немає ретесту. Без повторної перевірки ви не знаєте, чи виправлення спрацювало.
• Чекати річного тесту після інциденту. Шлях, яким зайшов зловмисник, перевіряють одразу після розслідування.
• Тест посеред великої міграції. NIST згадує, що тест інколи відкладають до завершення великого оновлення. ^[4] Інакше звіт описує систему, якої за тиждень уже не буде.

Чекліст: графік пентестів на рік

• Є список систем із пріоритетом: що найважливіше для грошей і даних клієнтів.
• Для кожної ключової системи останній пентест був не раніше ніж 12 місяців тому.
• Записано, які зміни вважаються суттєвими і запускають позаплановий тест.
• Великі релізи і нові інтеграції мають у плані час на тест до запуску.
• Автоматичне сканування налаштоване і працює щонайменше щокварталу.
• Після кожного пентесту заплановано ретест критичних і високих знахідок.
• Відомо, які вимоги діють саме для вас: PCI DSS, DORA, вимоги клієнтів у договорах.
• У плані реагування є цільова перевірка після інциденту.
• Річний бюджет включає позапланові тести, а не лише один щорічний.

Завантажити чекліст підготовки (PDF)PDF · A4

FAQ

Чи достатньо робити пентест раз на рік?

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

Чи можна замінити пентест скануванням вразливостей?

Ні. Сканер знаходить відомі вразливості, а пентест перевіряє, що зловмисник зробить із системою, зокрема через помилки логіки. PCI DSS вимагає обидва: сканування щокварталу, пентест щороку і після змін. ^[1]

Як часто PCI DSS вимагає пентест?

Внутрішній і зовнішній пентест щонайменше раз на 12 місяців і після суттєвих змін. Тест сегментації раз на 12 місяців, для сервіс-провайдерів раз на шість місяців. ^{[1] [2]}

Що DORA вимагає щодо пентесту?

Фінансові установи щороку тестують системи, що підтримують критичні або важливі функції, і пентест входить у перелік тестів. Установи, яких визначив регулятор, раз на три роки проходять TLPT. ^[3]

Чи потрібен пентест після кожного релізу?

Ні. Для звичайних релізів вистачає автоматичних перевірок. Окремий пентест потрібен, коли реліз змінює вхід, права доступу, оплату, роботу з персональними даними або відкриває нові API.

Посилання

1. Microsoft Learn: PCI DSS Requirement 11 (requirement text for 11.3 and 11.4) learn.microsoft.com
2. PCI SSC FAQ 1447: How often must service providers test segmentation controls? pcisecuritystandards.org
3. EUR-Lex: Regulation (EU) 2022/2554 (DORA) eur-lex.europa.eu
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment nvlpubs.nist.gov
5. PCI SSC: Penetration Testing Guidance v1.1 listings.pcisecuritystandards.org
6. PCI SSC: Just Published: PCI DSS v4.0.1 blog.pcisecuritystandards.org