- •1.2 Механізми безпеки
- •1.3 Класи безпеки
- •2 Інформаційна безпека розподілених систем. Рекомендації X.800
- •2.1 Мережні сервіси безпеки
- •2.2 Мережні механізми безпеки
- •2.3 Адміністрування засобів безпеки
- •3 Стандарт iso/iec 15408 "Критерії оцінки безпеки інформаційних технологій"
- •3.1 Основні поняття
- •3.2 Функціональні вимоги
- •3.3 Вимоги довір’я безпеці
- •4 Гармонізовані критерії європейських країн
- •5 Інтерпретація "Оранжевої книги" для мережних конфігурацій
- •Список літератури
2.3 Адміністрування засобів безпеки
Адміністрування засобів безпеки включає розповсюдження інформації, необхідної для роботи сервісів і механізмів безпеки, а також збір і аналіз інформації про їх функціонування. Прикладами можуть служити розповсюдження криптографічних ключів, установка значень параметрів захисту, ведення реєстраційного журналу і т.п.
Концептуальною основою адміністрування є інформаційна база управління безпекою. Ця база може не існувати як єдине (розподілене) сховище, але кожна з крайових систем повинна мати свій в розпорядженні інформацію, необхідну для реалізації вибраної політики безпеки.
Згідно рекомендаціям X.800, зусилля адміністратора засобів безпеки повинні розподілятися по трьох напрямах:
-
адміністрування інформаційної системи в цілому;
-
адміністрування сервісів безпеки;
-
адміністрування механізмів безпеки.
Серед дій, що відносяться до ІС в цілому, відзначимо забезпечення актуальності політики безпеки, взаємодію з іншими адміністративними службами, реагування на події, що відбуваються, аудит і безпечне відновлення.
Адміністрування сервісів безпеки включає визначення об’єктів, що захищаються, вироблення правил підбору механізмів безпеки (за наявності альтернатив), комбінування механізмів для реалізації сервісів, взаємодію з іншими адміністраторами для забезпечення злагодженої роботи.
Обов’язки адміністратора механізмів безпеки визначаються переліком задіяних механізмів. Типовий список такий:
-
управління ключами (генерація і розподіл);
-
управління шифруванням (установка і синхронізація криптографічних параметрів). До управління шифруванням можна віднести і адміністрування механізмів електронного підпису. Управління цілісністю, якщо воно забезпечується криптографічними засобами, також тяжіє до даного напряму;
-
адміністрування управління доступом (розподіл інформації, необхідної для управління - паролів, списків доступу і т.п.);
-
управління аутентифікацією (розподіл інформації, необхідної для аутентифікації - паролів, ключів і т.п.);
-
управління доповненням трафіку (вироблення і підтримка правил, задаючих характеристики доповнюючих повідомлень - частоту відправки, розмір і т.п.);
-
управління маршрутизацією (виділення довірених шляхів);
-
управління нотаризацией (розповсюдження інформації про нотаріальні служби, адміністрування цих служб).
Ми бачимо, що адміністрування засобів безпеки в розподіленій ІС має багато особливостей в порівнянні з централізованими системами.
3 Стандарт iso/iec 15408 "Критерії оцінки безпеки інформаційних технологій"
3.1 Основні поняття
Ми повертаємося до теми оцінних стандартів, приступаючи до розгляду найповнішого і сучасного серед них - "Критеріїв оцінки безпеки інформаційних технологій" (виданий 1 грудня 1999 року). Цей міжнародний стандарт став підсумком майже десятилітньої роботи фахівців декількох країн, він увібрав в себе досвід існуючих на той час документів національного і міжнаціонального масштабу.
З історичних причин даний стандарт часто називають "Загальними критеріями" (або навіть ОК). Ми також використовуватимемо це скорочення.
"загальні критерії" насправді є метастандартом, визначаючим інструменти оцінки безпеки ІС і порядок їх використовування. На відміну від "Оранжевої книги", ОК не містять приречених "класів безпеки". Такі класи можна будувати, виходячи з вимог безпеки, існуючих для конкретної організації и/или конкретної інформаційної системи.
З точки програміста зору ОК можна вважати набором бібліотек, що допомагають писати змістовні "програми" - завдання по безпеці, типові профілі захисту і т.п. Програмісти знають, наскільки хороша бібліотека спрощує розробку програм, підвищує їх якість. Без бібліотек, "з нуля", програми не пишуть вже дуже давно; оцінка безпеки теж вийшла на зіставний рівень складності, і "Загальні критерії" надали відповідний інструментарій.
Важливо відзначити, що вимоги можуть параметризуватися, як і вважається бібліотечним функціям.
Як і "Оранжева книга", ОК містять два основні види вимог безпеки:
-
функціональні, відповідні активному аспекту захисти, що пред’являються до функцій безпеки і реалізовуючих їх механізмів;
-
вимоги довір’я, відповідні пасивному аспекту, що пред’являються до технології і процесу розробки і експлуатації.
Вимоги безпеки пред’являються, а їх виконання перевіряється для певного об’єкту оцінки - апаратно-програмного продукту або інформаційної системи.
Дуже важливо, що безпека в ОК розглядається не статично, а в прив’язці до життєвого циклу об’єкту оцінки. Виділяються наступні етапи:
-
визначення призначення, умов вживання, цілей і вимог безпеки;
-
проектування і розробка;
-
випробування, оцінка і сертифікація;
-
упровадження і експлуатація.
В ОК об’єкт оцінки розглядається в контексті середовища безпеки, яка характеризується певними умовами і загрозами.
У свою чергу, загрози характеризуються наступними параметрами:
-
джерело загрози;
-
метод дії;
-
вразливі місця, які можуть бути використані;
-
ресурси (активи), які можуть постраждати.
Вразливі місця можуть виникати через недолік в:
-
вимогах безпеки;
-
проектуванні;
-
експлуатації.
Слабкі місця по можливості слід усунути, мінімізувати або хоча б постаратися обмежити можливий збиток від їх навмисного використовування або випадкової активізації.
З погляду технології програмування в ОК використаний застарілий бібліотечний (не об’єктний) підхід. Щоб, проте, структурувати простір вимог, в "Загальних критеріях" введена ієрархія клас-семейство-компонент-елемент.
Класи визначають саме загальне, "наочне" угрупування вимог (наприклад, функціональні вимоги підзвітності).
Сімейства в межах класу розрізняються по строгості і іншим нюансам вимог.
Компонент - мінімальний набір вимог, що фігурує як ціле.
Елемент - неподільна вимога.
Як і між бібліотечними функціями, між компонентами ОК може існувати залежність. Вони виникають, коли компонент сам по собі недостатній для досягнення мети безпеки. Взагалі кажучи, не всі комбінації компонентів мають сенс, і поняття залежності якоюсь мірою компенсує недостатню виразність бібліотечної організації, хоча і не замінює об’єднання функцій в змістовні об’єктні інтерфейси.
Як указувалося вище, за допомогою бібліотек можуть формуватися два види нормативних документів: профіль захисту і завдання по безпеці.
Профіль захисту (ПЗ) є типовим набором вимог, яким винні задовольняти продукти и/или системи певного класу (наприклад, операційні системи на комп’ютерах в урядових організаціях).
Завдання по безпеці містить сукупність вимог до конкретної розробки, виконання яких забезпечує досягнення поставлених цілей безпеки.
Вище ми відзначали, що в ОК немає готових класів захисту. Сформувати класифікацію в термінах "Загальних критеріїв" - значить визначити дещо ієрархічно впорядкованих (що містять вимоги, що посилюються) профілів захисту, в максимально можливому ступені використовуючих стандартні функціональні вимоги і вимоги довір’я безпеки.
Виділення деякої підмножини зі всієї множини профілів захисту багато в чому носить суб’єктивний характер. По цілому ряду міркувань (одним з яких є бажання дотримуватися об’єктно-орієнтованого підходу) доцільно, на наш погляд, сформувати спочатку відправну точку класифікації, виділивши базовий (мінімальний) ПЗ, а додаткові вимоги компонувати у функціональні пакети.
Функціональний пакет - це сукупність компонентів, з’єднаних для досягнення певної мети безпеки, що неодноразово використовується. "загальні критерії" не регламентують структуру пакетів, процедури верифікації, реєстрації і т.п., відводячи їм роль технологічного засобу формування ПЗ.
Базовий профіль захисту повинен включати вимоги до основних (обов’язковим у будь-якому випадку) можливостей. Похідні профілі виходять з базового шляхом додавання необхідних пакетів розширення, тобто подібно тому, як створюються похідні класи в об’єктно-орієнтованих мовах програмування.