10 найчастіших причин повторного подання на експертизу: документація, реалізація, тестування.
За 8 років роботи з експертизою захищеності ми бачили близько 90% повторних подань через 10 повторюваних причин. Список нижче — не теоретичний, а сформований за реальними протоколами зауважень. Якщо перед поданням пройти його як чек-лист — більшість проблем уловлюється до контакту з експертом.
ТЗ описує одну архітектуру, реалізація — іншу. Найчастіше це наслідок того, що ТЗ писалося на старті, а реалізація змінювалася упродовж року-двох без оновлення документації. Експерт читає ТЗ і не знаходить описаних компонентів у системі.
Виправлення: перед поданням оновити ТЗ під фактичну реалізацію або, навпаки, привести реалізацію у відповідність до ТЗ. Не вкладається у тиждень — переносьте подання.
Модель загроз — шаблонна, не відображає особливостей конкретної системи. Наприклад: система працює у хмарі провайдера, а в моделі загроз згадуються тільки внутрішні порушники.
Виправлення: модель загроз має враховувати: де фізично розміщені сервери, хто має до них фізичний доступ (включно з провайдером), які канали зв’язку використовуються, чи є мобільні клієнти.
У переліку функцій безпеки 50 пунктів, у програмі випробувань — тести для 30. Експерт не може провести перевірку 20 функцій.
Виправлення: для кожної функції безпеки — окремий тест-кейс. Допустимо групувати схожі функції (наприклад, всі функції журналювання), але кожна має бути явно зазначена.
Адміністратор системи входить тільки по паролю, без другого фактора. Для АС-2 і АС-3 це автоматичне зауваження. Норматив вимагає посиленої автентифікації для привілейованих ролей.
Виправлення: двофакторна автентифікація обов’язкова для всіх адміністративних облікових записів. Допустимі засоби: апаратні токени з ДСТУ 4145, OTP, біометрія (для деяких категорій).
Журнали подій записуються у звичайний log-файл, який може бути модифікований. Це не WORM. Експерт перевіряє: чи можна змінити запис у журналі, не залишивши слідів?
Виправлення: WORM-журнал з криптографічним підписом, контролем хешів послідовних записів, періодичним архівуванням з підписом.
У системі використовується MD5, SHA-1, DES, 3DES або інший застарілий алгоритм. Хоча б у одному компоненті — наприклад, у legacy-частині інтеграції.
Виправлення: інвентаризація всіх криптографічних алгоритмів. Для нових — ДСТУ 7624 (Калина) або AES-256, SHA-256/SHA-3. Для електронного підпису — ДСТУ 4145.
Між клієнтом і сервером — HTTP без TLS. Або TLS 1.0/1.1. Або правильний TLS 1.2/1.3, але з небезпечним cipher suite (наприклад, з RC4).
Виправлення: TLS 1.2 мінімум, краще 1.3. Cipher suites — тільки сильні (AES-GCM, ChaCha20-Poly1305). Тест: запуск testssl.sh або nmap –script ssl-enum-ciphers перед поданням.
Програма випробувань є, але немає документа, який підтверджує, що випробування проведені. Експерт не може взяти на віру.
Виправлення: для кожного тест-кейсу — окремий запис у акті: дата, виконавець, вхідні дані, спостережений результат, відповідність очікуваному. Підпис відповідального.
Випробування виконувались у тестовому середовищі. Експерт не впевнений, що промислова система ідентична.
Виправлення: у програмі випробувань явно зазначити: які тести проводяться на проді, які на стенді, чим обґрунтована еквівалентність. Для критичних функцій (автентифікація, контроль доступу) — обов’язково проводити на проді.
При випробуваннях знайдено помилки. У звіті — все «успішно». Експерт під час перевірки натрапляє на дефект і запитує: чому в акті випробувань цього немає?
Виправлення: чесне ведення журналу випробувань. Виявлений дефект → запис у журналі → виправлення → повторне випробування → запис про закриття. Це не послаблює позиції, а посилює: експерт бачить, що замовник серйозно відноситься до якості.
Якщо зауваження все ж надійшли, формат відповіді стандартний:
| Структура | Зміст |
|---|---|
| Цитата зауваження | Дослівне відтворення тексту з протоколу експертизи |
| Класифікація | Прийнято / не прийнято / прийнято частково |
| Опис вжитих заходів | Конкретні дії: змінено документ X, реалізовано функцію Y |
| Посилання на докази | № сторінки оновленого ТЗ, № тест-кейсу, № запису у журналі |
| Дата виконання | Календарна дата |
| Виконавець | Конкретна особа з посадою |
З 10 типових зауважень 5 стосуються технічних механізмів, які у UBD реалізовані штатно і покриті експертним висновком Г-3: двофакторна автентифікація, WORM-журнал, ДСТУ 4145, контроль цілісності журналів, TLS з сильними cipher suites. UBD проходить регулярну переатестацію — поточний висновок чинний, оновлювався у 2018 та повторно з розширенням обсягу функцій.