Файл: 8_ua_2_.doc

3.3 Вимоги довір’я безпеці

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

Форма представлення вимог довір’я, у принципі, та ж, що і для функціональних вимог. Специфіка полягає в тому, що кожний елемент вимог довір’я належить одному з трьох типів:

• дії розробників;

• уявлення і зміст свідоцтв;

• дії оцінювачів.

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

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

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

• тестування;

• оцінка уязвимостей (включаючи оцінку стійкості функцій безпеки);

• поставка і експлуатація;

• управління конфігурацією;

• керівництво (вимоги до експлуатаційної документації);

• підтримка довір’я (для підтримки етапів життєвого циклу після сертифікації);

• оцінка профілю захисту;

• оцінка завдання по безпеці.

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

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

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

На третьому рівні ведеться контроль середовища розробки і управління конфігурацією об’єкту оцінки.

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

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

На рівні 6 реалізація повинна бути представлена в структурованому вигляді. Аналіз відповідності розповсюджується на проект нижнього рівня.

Оцінний рівень 7 (найвищий) передбачає формальну верифікацію проекту об’єкту оцінки. Він застосуємо до ситуацій надзвичайно високого ризику.

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

4 Гармонізовані критерії європейських країн

Наш виклад "Гармонізованих критеріїв" грунтується на версії 1.2, опублікованої в червні 1991 року від імені відповідних органів чотирьох країн - Франції, Німеччини, Нідерландів і Великобританії.

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

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

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

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

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

Сервіси безпеки реалізуються за допомогою конкретних механізмів. Щоб об’єкту оцінки можна було довіряти, необхідний певний ступінь упевненості в наборі функцій і механізмів безпеки. Ступінь упевненості ми називатимемо гарантированностью. Гарантірованность може бути більшою або меншою залежно від ретельності проведення оцінки.

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

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

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

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

5 Інтерпретація "Оранжевої книги" для мережних конфігурацій

В 1987 році Національним центром комп’ютерної безпеки США була опублікована інтерпретація "Оранжевої книги" для мережних конфігурацій. Даний документ складається з двох частин. Перша містить власне інтерпретацію, в другій розглядаються сервіси безпеки, специфічні або особливо важливі для мережних конфігурацій.

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

Прямої залежності між обчислювальними базами компонентів, що розглядаються як ізольовані системи, і фрагментами мережної обчислювальної бази не існує. Більш того, немає прямої залежності і між рівнями безпеки окремих компонентів і рівнем безпеки всієї мережної конфігурації. Наприклад, в результаті об’єднання двох систем класу B1, що володіють несумісними правилами кодування міток безпеки, виходить мережа, що не задовольняє вимозі цілісності міток. Як протилежний приклад розглянемо об’єднання двох компонентів, один з яких сам не забезпечує протоколювання дій користувача, але передає необхідну інформацію іншому компоненту, який і веде протокол. У такому разі розподілена система в цілому, не дивлячись на слабкість компоненту, задовольняє вимозі підзвітності.

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

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

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

Систематичний розгляд питань доступності є новиною по порівнянню не тільки з "Оранжевою книгою", але і з рекомендаціями X.800. Мережний сервіс перестає бути доступним, коли пропускна спроможність комунікаційних каналів падає нижче мінімально допустимого рівня або сервіс не в змозі обслуговувати запити. Видалений ресурс може стати неприступним і унаслідок порушення рівноправності в обслуговуванні користувачів. Довірена система повинна мати нагоду знаходити ситуації неприступності, уміти повертатися до нормальної роботи і протистояти атакам на доступність.

Для забезпечення безперервності функціонування можуть застосовуватися наступні захисні заходи:

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

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

• розосередженість мережного управління, відсутність єдиної точки відмови;

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

• виділення підмереж і ізоляція груп користувачів один від одного.

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

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