Важливо відзначити, що вимоги можуть параметризуватися, як і вважається бібліотечним функціям.
Як і "Оранжева книга", ОК містять два основні види вимог безпеки:
функціональні, відповідні активному аспекту захисти, що пред’являються до функцій безпеки і реалізовуючих їх механізмів;
вимоги довір’я, відповідні пасивному аспекту, що пред’являються до технології і процесу розробки і експлуатації.
Вимоги безпеки пред’являються, а їх виконання перевіряється для певного об’єкту оцінки - апаратно-програмного продукту або інформаційної системи.
Дуже важливо, що безпека в ОК розглядається не статично, а в прив’язці до життєвого циклу об’єкту оцінки. Виділяються наступні етапи:
визначення призначення, умов вживання, цілей і вимог безпеки;
проектування і розробка;
випробування, оцінка і сертифікація;
упровадження і експлуатація.
В ОК об’єкт оцінки розглядається в контексті середовища безпеки, яка характеризується певними умовами і загрозами.
У свою чергу, загрози характеризуються наступними параметрами:
джерело загрози;
метод дії;
вразливі місця, які можуть бути використані;
ресурси (активи), які можуть постраждати.
Вразливі місця можуть виникати через недолік в:
вимогах безпеки;
проектуванні;
експлуатації.
Слабкі місця по можливості слід усунути, мінімізувати або хоча б постаратися обмежити можливий збиток від їх навмисного використовування або випадкової активізації.
З погляду технології програмування в ОК використаний застарілий бібліотечний (не об’єктний) підхід. Щоб, проте, структурувати простір вимог, в "Загальних критеріях" введена ієрархія клас-семейство-компонент-елемент.
Класи визначають саме загальне, "наочне" угрупування вимог (наприклад, функціональні вимоги підзвітності).
Сімейства в межах класу розрізняються по строгості і іншим нюансам вимог.
Компонент - мінімальний набір вимог, що фігурує як ціле.
Елемент - неподільна вимога.
Як і між бібліотечними функціями, між компонентами ОК може існувати залежність. Вони виникають, коли компонент сам по собі недостатній для досягнення мети безпеки. Взагалі кажучи, не всі комбінації компонентів мають сенс, і поняття залежності якоюсь мірою компенсує недостатню виразність бібліотечної організації, хоча і не замінює об’єднання функцій в змістовні об’єктні інтерфейси.
Як указувалося вище, за допомогою бібліотек можуть формуватися два види нормативних документів: профіль захисту і завдання по безпеці.
Профіль захисту (ПЗ) є типовим набором вимог, яким винні задовольняти продукти и/или системи певного класу (наприклад, операційні системи на комп’ютерах в урядових організаціях).
Завдання по безпеці містить сукупність вимог до конкретної розробки, виконання яких забезпечує досягнення поставлених цілей безпеки.
Вище ми відзначали, що в ОК немає готових класів захисту. Сформувати класифікацію в термінах "Загальних критеріїв" - значить визначити дещо ієрархічно впорядкованих (що містять вимоги, що посилюються) профілів захисту, в максимально можливому ступені використовуючих стандартні функціональні вимоги і вимоги довір’я безпеки.
Виділення деякої підмножини зі всієї множини профілів захисту багато в чому носить суб’єктивний характер. По цілому ряду міркувань (одним з яких є бажання дотримуватися об’єктно-орієнтованого підходу) доцільно, на наш погляд, сформувати спочатку відправну точку класифікації, виділивши базовий (мінімальний) ПЗ, а додаткові вимоги компонувати у функціональні пакети.
Функціональний пакет - це сукупність компонентів, з’єднаних для досягнення певної мети безпеки, що неодноразово використовується. "загальні критерії" не регламентують структуру пакетів, процедури верифікації, реєстрації і т.п., відводячи їм роль технологічного засобу формування ПЗ.
Базовий профіль захисту повинен включати вимоги до основних (обов’язковим у будь-якому випадку) можливостей. Похідні профілі виходять з базового шляхом додавання необхідних пакетів розширення, тобто подібно тому, як створюються похідні класи в об’єктно-орієнтованих мовах програмування.
Функціональні вимоги згруповані на основі виконуваної ними ролі або обслуговуваній меті безпеки. Всього в "Загальних критеріях" представлено 11 функціональних класів, 66 сімейств, 135 компонентів. Це, звичайно, значно більше, ніж число аналогічних єств в "Оранжевій книзі".
Перерахуємо класи функціональних вимог ОК:
ідентифікація і аутентифікація;
захист даних користувача;
захист функцій безпеки (вимоги відносяться до цілісності і контролю даних сервісів безпеки і реалізовуючих їх механізмів);
управління безпекою (вимоги цього класу відносяться до управління атрибутами і параметрами безпеки);
аудит безпеки (виявлення, реєстрація, зберігання, аналіз даних, що зачіпають безпеку об’єкту оцінки, реагування на можливе порушення безпеки);
доступ до об’єкту оцінки;
приватность (захист користувача від розкриття і несанкціонованого використовування його ідентифікаційних даних);
використовування ресурсів (вимоги до доступності інформації);
криптографічна підтримка (управління ключами);
зв’язок (аутентифікація сторін, що беруть участь в обміні даними);
довірений маршрут/канал (для зв’язку з сервісами безпеки).
Опишемо докладніше два класи, демонструючі особливості сучасного підходу до ІБ.
Клас "Пріватность" містить 4 сімейства функціональних вимог.
Анонімність. Дозволяє виконувати дії без розкриття ідентифікатора користувача іншим користувачам, суб’єктам и/или об’єктам. Анонімність може бути повною або вибірковою. В останньому випадку вона може відноситися не до всіх операцій и/или не до всіх користувачів (наприклад, у уповноваженого користувача може залишатися можливість з’ясування ідентифікаторів користувачів).
Псевдонімность. Нагадує анонімність, але при вживанні псевдоніма підтримується посилання на ідентифікатор користувача для забезпечення підзвітності або для інших цілей.
Неможливість асоціації. Сімейство забезпечує можливість неодноразового використовування інформаційних сервісів, але не дозволяє асоціювати випадки використовування між собою і приписати їх одній особі. Неможливість асоціації захищає від побудови профілів поведінки користувачів (і, отже, від отримання інформації на основі подібних профілів).
Скритність. Вимоги даного сімейства направлені на те, щоб можна було використовувати інформаційний сервіс із захованням факту використовування. Для реалізації скритності може застосовуватися, наприклад, широкомовне розповсюдження інформації, без вказівки конкретного адресата. Годяться для реалізації скритності і методи стеганографии, коли ховається не тільки зміст повідомлення (як в криптографії), але і сам факт його відправки.
Ще один показовий (з нашої точки зору) клас функціональних вимог - "Використовування ресурсів", що містить вимоги доступності. Він включає три сімейства.
Відмовостійкість. Вимоги цього сімейства направлені на збереження доступності інформаційних сервісів навіть у разі збою або відмови. В ОК розрізняються активна і пасивна відмовостійкість. Активний механізм містить спеціальні функції, які активізуються у разі збою. Пасивна відмовостійкість має на увазі наявність надмірності з можливістю нейтралізації помилок.
Обслуговування по пріоритетах. Виконання цих вимог дозволяє управляти використовуванням ресурсів так, що низькопріоритетним операціям не можуть перешкодити високопріоритетним.
Розподіл ресурсів. Вимоги направлені на захист (шляхом вживання механізму квот) від несанкціонованої монополізації ресурсів.
Ми бачимо, що "Загальні критерії" - дуже продуманий і повний документ з погляду функціональних вимог. В той же час, хотілося б звернути увагу і на деякі недоліки.
Перший ми вже відзначали - ця відсутність об’єктного підходу. Функціональні вимоги не згруповані в осмислені набори (об’єктні інтерфейси), до яких могло б застосовуватися спадкоємство. Подібне положення, як відомо з технології програмування, чревате появою дуже великого числа комбінацій функціональних компонентів, незіставних між собою.
В сучасному програмуванні ключовим є питання накопичення і багатократного використовування знань. Стандарти - одна з форм накопичення знань. Проходження в ОК "бібліотечному", а не об’єктному підходу звужує круг знань, що фіксуються, ускладнює їх коректне використовування.
На жаль, в "Загальних критеріях" відсутні архітектурні вимоги, що є природним слідством вибраного старомодного підходу програміста "від" низу до верху. На наш погляд, це серйозне упущення. Технологічність засобів безпеки, проходження загальновизнаним рекомендаціям по протоколах і програмних інтерфейсах, а також апробованих архітектурних рішеннях, таким як менеджер/агент, - необхідні якості виробів інформаційних технологій, призначених для підтримки критично важливих функцій, до числа яких, безумовно, відносяться функції безпеки. Без розгляду інтерфейсних аспектів системи виявляються нерозширюваними і ізольованими. Очевидно, з практичної точки зору це неприпустимо. В той же час, забезпечення безпеки інтерфейсів - важлива задача, яку бажано вирішувати одноманітно.
Встановлення довір’я безпеці, згідно "Загальним критеріям", грунтується на активному дослідженні об’єкту оцінки.
Форма представлення вимог довір’я, у принципі, та ж, що і для функціональних вимог. Специфіка полягає в тому, що кожний елемент вимог довір’я належить одному з трьох типів:
дії розробників;
уявлення і зміст свідоцтв;
дії оцінювачів.
Всього в ОК 10 класів, 44 сімейства, 93 компоненти вимог довір’я безпеці. Перерахуємо класи:
розробка (вимоги для поетапної деталізації функцій безпеки від короткої специфікації до реалізації);
підтримка життєвого циклу (вимоги до моделі життєвого циклу, включаючи порядок усунення недоліків і захист середовища розробки);
тестування;
оцінка уязвимостей (включаючи оцінку стійкості функцій безпеки);
поставка і експлуатація;
управління конфігурацією;
керівництво (вимоги до експлуатаційної документації);
підтримка довір’я (для підтримки етапів життєвого циклу після сертифікації);
оцінка профілю захисту;
оцінка завдання по безпеці.
Стосовно вимог довір’я в "Загальних критеріях" зроблена вельми корисна річ, не реалізована, на жаль, для функціональних вимог. А саме, введені так звані оцінні рівні довір’я (їх сім), що містять осмислені комбінації компонентів.
Оцінний рівень довір’я 1 (початковий) передбачає аналіз функціональної специфікації, специфікації інтерфейсів, експлуатаційної документації, а також незалежне тестування. Рівень застосовний, коли загрози не розглядаються як серйозні.
Оцінний рівень довір’я 2, на додаток до першого рівня, передбачає наявність проекту верхнього рівня об’єкту оцінки, вибіркове незалежне тестування, аналіз стійкості функцій безпеки, пошук розробником явних вразливих місць.
На третьому рівні ведеться контроль середовища розробки і управління конфігурацією об’єкту оцінки.
На рівні 4 додаються повна специфікація інтерфейсів, проекти нижнього рівня, аналіз підмножини реалізації, вживання неформальної моделі політики безпеки, незалежний аналіз вразливих місць, автоматизація управління конфігурацією. Ймовірно, це найвищий рівень, якого можна досягти при існуючій технології програмування і прийнятних витратах.
Рівень 5, на додаток до попередніх, передбачає вживання формальної моделі політики безпеки, напівформальних функціональної специфікації і проекту верхнього рівня з демонстрацією відповідності між ними. Необхідне проведення аналізу прихованих каналів розробниками і оцінювачами.
На рівні 6 реалізація повинна бути представлена в структурованому вигляді. Аналіз відповідності розповсюджується на проект нижнього рівня.
Оцінний рівень 7 (найвищий) передбачає формальну верифікацію проекту об’єкту оцінки. Він застосуємо до ситуацій надзвичайно високого ризику.
На цьому ми закінчуємо короткий огляд "Загальних критеріїв".
Наш виклад "Гармонізованих критеріїв" грунтується на версії 1.2, опублікованої в червні 1991 року від імені відповідних органів чотирьох країн - Франції, Німеччини, Нідерландів і Великобританії.
Принципово важливою межею європейських Критеріїв є відсутність вимог до умов, в яких повинна працювати інформаційна система. Так званий спонсор, тобто організація, що запрошує сертифікаційні послуги, формулює мету оцінки, тобто описує умови, в яких повинна працювати система, можливі загрози її безпеки і захисні функції, що надаються нею. Задача органу сертифікації - оцінити, наскільки повно досягаються поставлені цілі, тобто наскільки коректні і ефективні архітектура і реалізація механізмів безпеки в описаних спонсором умовах. Таким чином, в термінології "Оранжевої книги", європейські Критерії відносяться до гарантированности безпечної роботи системи. Вимоги до політики безпеки і наявності захисних механізмів не є складовою частиною Критеріїв. Втім, щоб полегшити формулювання мети оцінки, Критерії містять як додаток опис десяти класів функціональності, типових для урядових і комерційних систем.