Структура ТЗ за НД ТЗІ 3.7-003-2005, обов'язкові розділи, модель загроз, типові помилки при підготовці.
Технічне завдання — головний документ експертизи захищеності. Експерт Адміністрації Держспецзв’язку працює не з системою, а з ТЗ. Якщо ТЗ написане погано, експертиза затягнеться на місяці незалежно від того, як добре реалізована сама система. Ця стаття описує, що очікує побачити експерт.
Структура та зміст ТЗ на створення комплексної системи захисту інформації регулюються НД ТЗІ 3.7-003-2005 «Порядок проведення робіт зі створення комплексної системи захисту інформації в інформаційно-телекомунікаційній системі». Класифікація автоматизованих систем, на яку посилається ТЗ — НД ТЗІ 2.5-004-99. Без цих двох документів ТЗ не пройде формальну перевірку.
ТЗ на створення КСЗІ має 10-12 розділів. Зміст кожного фіксований, відхилення викликають зауваження.
Назва системи, повне найменування замовника та розробника, перелік документів, на підставі яких проводяться роботи (договір, технічне завдання основної системи, рішення про створення КСЗІ). Найчастіша помилка — відсутність посилання на ТЗ основної АС: експерт не може зрозуміти, що захищаємо.
Конкретні відомості з обмеженим доступом, які обробляються в АС. Не «персональні дані» загалом, а: ПІБ працівників, посади, заробітна плата, медичні відомості — за категоріями. Без переліку категорій неможливо побудувати модель загроз.
Опис АС, для якої будується КСЗІ: клас (АС-1/АС-2/АС-3), функціональність, кількість користувачів, режим обробки, фізичне розміщення серверів та клієнтів. Якщо клас не зазначено або зазначено помилково — зауваження критичне (див. матеріал «Як вибрати клас АС»).
Найскладніший розділ. Описує: джерела загроз (зовнішній порушник, внутрішній порушник з різним рівнем повноважень, технічна несправність, природна подія); канали реалізації (мережа, фізичний доступ, побічні електромагнітні випромінювання, акустичний канал); можливі вразливості (помилки конфігурації, нестійка криптографія, відсутність контролю цілісності).
Експерт перевіряє повноту переліку. Якщо в моделі немає «внутрішнього порушника з адміністративними правами», а система — АС-2 чи АС-3, це автоматичне зауваження.
Окремий розділ, що деталізує можливості порушника. Зазвичай — три категорії: зовнішній порушник без авторизації, авторизований користувач з обмеженими правами, привілейований користувач (адміністратор). Для кожної категорії — перелік дій, які він теоретично здатний здійснити.
Перелік функцій безпеки, які мають бути реалізовані. Зазвичай 30-60 пунктів за категоріями: ідентифікація та автентифікація, керування доступом, реєстрація подій, контроль цілісності, криптографічний захист, забезпечення доступності, фізичний захист, антивірусний захист.
Експерт перевіряє відповідність функцій безпеки класу АС. Для АС-3 не можна обійтися мінімальним набором — потрібні розширені функції контролю цілісності та реєстрації.
Як кожна функція безпеки буде перевірена. Для кожної функції — окремий тест-кейс: вхідні дані, дії, очікуваний результат. Часта помилка — формулювання «функція реалізована штатними засобами ОС» без конкретного тесту. Експерт цього не приймає.
| Помилка | Наслідок | Виправлення |
|---|---|---|
| Не зазначений клас АС або зазначений помилково | Зауваження критичне, повне переписування | Свідома класифікація на старті, перевірка з експертною організацією |
| Модель загроз без внутрішнього порушника | Повторне подання | Завжди включати 3 категорії порушника |
| Розпливчасті формулювання функцій безпеки | Експерт не може скласти програму випробувань | Кожна функція — конкретно, з посиланням на нормативний документ |
| Програма випробувань копіює перелік функцій | Зауваження «методика відсутня» | Для кожної функції — окремий тест-кейс |
| ТЗ не узгоджене з ТЗ основної АС | Експерт не розуміє об’єкт | Посилання на ТЗ АС у розділі 1 |
Орієнтовний час підготовки ТЗ на КСЗІ — 4-8 тижнів за умови наявності повної документації основної АС. Якщо основна АС не описана (наприклад, замовник модернізує застарілу систему без ТЗ), додається 2-4 тижні на її попереднє обстеження.
Стандартний цикл: 1-2 ітерації внутрішнього перегляду, узгодження з замовником, формальна перевірка перед поданням до експертної організації.
UBD має чинний експертний висновок Г-3 за НД ТЗІ 2.5-004-99. Це означає: розділ «Вимоги до функцій безпеки» можна формувати на основі вже сертифікованих функцій платформи, а не описувати їх з нуля. Інженер описує тільки прикладну специфіку — функції безпеки наслідуються від платформи з посиланням на висновок.