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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• метод впливу;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Функціональні вимоги

Функціональні вимоги згруповані на основі виконуваної ними ролі або обслуговується цілі безпеки. Всього в "Загальних критеріях" представлено 11 функціональних класів, 66 родин, 135 компонентів. Це, звичайно, значно більше, ніж число аналогічних сутностей в "Помаранчевої книзі".

Перерахуємо класи функціональних вимог ОК:

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

• захист даних користувача;

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

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

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

• доступ до об'єкта оцінки;

• приватність (захист користувача від розкриття і несанкціонованого використання його ідентифікаційних даних);

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

• криптографічний підтримка (управління ключами);

• зв'язок (аутентифікація сторін, що беруть участь в обміні даними);

• довірений маршрут / канал (для зв'язку із сервісами безпеки).

Опишемо докладніше два класи, що демонструють особливості сучасного підходу до ІБ.

Клас "Приватність" містить 4 сімейства функціональних вимог.

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

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

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

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

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

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

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

Розподіл ресурсів. Вимоги спрямовані на захист (шляхом застосування механізму квот) від несанкціонованої монополізації ресурсів.

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

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

У сучасному програмуванні ключовим є питання накопичення та багаторазового використання знань. Стандарти - одна з форм нагромадження знань. Дотримання в ОК "бібліотечної", а не об'єктному підходу звужує коло фіксованих знань, ускладнює їх коректне використання.

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

Вимоги довіри безпеки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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