Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
KP_ZKCM.doc
Скачиваний:
108
Добавлен:
19.02.2016
Размер:
359.42 Кб
Скачать

4 Розробка технічного завдання на створення ксзі

4.1 Загальні положення щодо створення тз

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

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

ТЗ на створення КСЗІ може розроблятися для вперше створюваних ІТС, а також під час модернізації вже існуючих ІТС.

Для оформлення ТЗ на КСЗІ можуть бути використані такі варіанти:

  • у вигляді окремого розділу ТЗ на створення ІТС;

  • у вигляді окремого (часткового) ТЗ;

  • у вигляді доповнення до ТЗ на створення ІТС.

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

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

Для інтегрованих ІТС, які будуються за модульним принципом (п.5.11), вимоги до КСЗІ кожної із складових частин ІТС рекомендується оформляти окремим документом. Дозволяється готувати один документ (доповнення до ТЗ на створення ІТС, окреме ТЗ) на декілька однотипних складових частин КСЗІ, вказавши існуючі між ними відмінності чи особливості.

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

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

Єдиним обмеженням при розробці окремого ТЗ на створення КСЗІ або доповнення до ТЗ на створення ІТС є дотримання в них єдиної системи понять, позначень, ідентифікації об’єктів тощо, які застосовуються в ТЗ на створення ІТС.

Для будь-якого з наведених варіантів розроблення та оформлення ТЗ на КСЗІ його зміст, порядок погодження та затвердження повинен відповідати НД ТЗІ 3.7-001 та ГОСТ 34.601.

4.2 Визначення вимог до засобів захисту

Вихідними даними є:

  • аналіз функцій та завдань ІТС;

  • аналіз ризиків.

На основі цих даних відповідно до НД ТЗІ 2.5-005 [8] вибирається профіль захисту (клас захищеності ІТС від несанкціонованого доступу відповідно до НД ТЗІ 2.5-004-99 [9]) і при необхідності в технічному завданні формулюються додаткові вимоги, специфічні (зв’язані, наприклад, зі специфікою інформаційної безпеки в сучасних розподілених системах) для даної ІТС.

Загальні вимоги до засобів захисту, що виходять із вибраного класу захищеності ІТС та додаткових вимог, можуть бути описані на основі функціонального підходу (по завданням і функціям захисту), або по підсистемах ІТС.

Якщо використовується функціональний підхід, повинні бути визначені функції безпеки (сервіси безпеки), такі як:

  • автентифікація;

  • управління доступом;

  • конфіденційність;

  • цілісність і т.ін.

Для всіх функцій і завдань ІТС повинні бути дані визначення відповідних функцій безпеки. Функції безпеки з однаковими назвами можуть мати різні визначення для різних функцій і завдань ІТС.

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

  • управління доступом до інформації;

  • ідентифікація і автентифікація;

  • криптографія;

  • екранування;

  • забезпечення цілісності і доступності даних;

  • підтримка працездатності ІТС при збоях, аваріях, надзвичайних ситуаціях;

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

  • управління доступом в ІТС;

  • протоколювання дій і подій.

Якщо використовується опис подій по підсистемах, повинні бути сформульовані додаткові вимоги, що не регламентуються у вимогах вибраного профіля захисту (класу захищеності ІТС).

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]