2.3 Адміністрування засобів безпеки

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

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

Згідно рекомендаціям X.800, зусилля адміністратора засобів безпеки повинні розподілятися по трьох напрямах:

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

• адміністрування сервісів безпеки;

• адміністрування механізмів безпеки.

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

Адміністрування сервісів безпеки включає визначення об’єктів, що захищаються, вироблення правил підбору механізмів безпеки (за наявності альтернатив), комбінування механізмів для реалізації сервісів, взаємодію з іншими адміністраторами для забезпечення злагодженої роботи.

Обов’язки адміністратора механізмів безпеки визначаються переліком задіяних механізмів. Типовий список такий:

• управління ключами (генерація і розподіл);

• управління шифруванням (установка і синхронізація криптографічних параметрів). До управління шифруванням можна віднести і адміністрування механізмів електронного підпису. Управління цілісністю, якщо воно забезпечується криптографічними засобами, також тяжіє до даного напряму;

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

• управління аутентифікацією (розподіл інформації, необхідної для аутентифікації - паролів, ключів і т.п.);

• управління доповненням трафіку (вироблення і підтримка правил, задаючих характеристики доповнюючих повідомлень - частоту відправки, розмір і т.п.);

• управління маршрутизацією (виділення довірених шляхів);

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

Ми бачимо, що адміністрування засобів безпеки в розподіленій ІС має багато особливостей в порівнянні з централізованими системами.

3 Стандарт iso/iec 15408 "Критерії оцінки безпеки інформаційних технологій"

3.1 Основні поняття

Ми повертаємося до теми оцінних стандартів, приступаючи до розгляду найповнішого і сучасного серед них - "Критеріїв оцінки безпеки інформаційних технологій" (виданий 1 грудня 1999 року). Цей міжнародний стандарт став підсумком майже десятилітньої роботи фахівців декількох країн, він увібрав в себе досвід існуючих на той час документів національного і міжнаціонального масштабу.

З історичних причин даний стандарт часто називають "Загальними критеріями" (або навіть ОК). Ми також використовуватимемо це скорочення.

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

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

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

Як і "Оранжева книга", ОК містять два основні види вимог безпеки:

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

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

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

Дуже важливо, що безпека в ОК розглядається не статично, а в прив’язці до життєвого циклу об’єкту оцінки. Виділяються наступні етапи:

• визначення призначення, умов вживання, цілей і вимог безпеки;

• проектування і розробка;

• випробування, оцінка і сертифікація;

• упровадження і експлуатація.

В ОК об’єкт оцінки розглядається в контексті середовища безпеки, яка характеризується певними умовами і загрозами.

У свою чергу, загрози характеризуються наступними параметрами:

• джерело загрози;

• метод дії;

• вразливі місця, які можуть бути використані;

• ресурси (активи), які можуть постраждати.

Вразливі місця можуть виникати через недолік в:

• вимогах безпеки;

• проектуванні;

• експлуатації.

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

З погляду технології програмування в ОК використаний застарілий бібліотечний (не об’єктний) підхід. Щоб, проте, структурувати простір вимог, в "Загальних критеріях" введена ієрархія клас-семейство-компонент-елемент.

Класи визначають саме загальне, "наочне" угрупування вимог (наприклад, функціональні вимоги підзвітності).

Сімейства в межах класу розрізняються по строгості і іншим нюансам вимог.

Компонент - мінімальний набір вимог, що фігурує як ціле.

Елемент - неподільна вимога.

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

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

Профіль захисту (ПЗ) є типовим набором вимог, яким винні задовольняти продукти и/или системи певного класу (наприклад, операційні системи на комп’ютерах в урядових організаціях).

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

Вище ми відзначали, що в ОК немає готових класів захисту. Сформувати класифікацію в термінах "Загальних критеріїв" - значить визначити дещо ієрархічно впорядкованих (що містять вимоги, що посилюються) профілів захисту, в максимально можливому ступені використовуючих стандартні функціональні вимоги і вимоги довір’я безпеки.

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

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

Базовий профіль захисту повинен включати вимоги до основних (обов’язковим у будь-якому випадку) можливостей. Похідні профілі виходять з базового шляхом додавання необхідних пакетів розширення, тобто подібно тому, як створюються похідні класи в об’єктно-орієнтованих мовах програмування.