Лабораторна робота №12, Оцінка безпеки інформаційних технологій за стандартом ISO/IEC 15408

« Назад

Мета: Ознайомитись із основними положеннями стандарту ISO/IEC 15408 «Інформаційна технологія. Методи і засоби забезпечення безпеки. Критерії оцінки безпеки інформаційних технологій». Навчитись створювати профілі безпеки на основі специфічних вимог до різних сервісів безпеки їх комбінацій і додатків.

Теоретичні відомості

1. Подання і загальна модель інформаційних технологій для узагальнених критеріїв

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

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

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

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

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

1.1. Цільова спрямованість загальних критеріїв

Оцінка безпеки ІТ — це методологія дослідження властивостей безпеки виробу або системи інформаційних технологій, званих в ЗК об'єктами оцінки.

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

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

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

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

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

1.2. Організація загальних критеріїв

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

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

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

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

Розділ Попередньо визначені профілі захисту — містить приклади профілів захисту, що включають функціональні вимоги безпеки і вимоги гарантії оцінки, які були ідентифіковані в початкових критеріях (ITSEC, CTCPEC, FC, TCSEC), а також вимоги, не представлені в початкових критеріях. Розділ Попередньо визначені профілі захисту, кінець кінцем, стане каталогом профілів захисту, які пройшли процес реєстрації.

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

1.3. Можливості і застосовність

ЗК підтримують вибір і оцінку безпеки об'єкту ІТ. ЗК корисні при розробці виробів або систем ІТ з функціями безпеки і при придбанні комерційних виробів і систем з такими функціями. ЗК дають основу для оцінки об'єкту, щоб встановити рівень довіри до безпеки ІТ.

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

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

ЗК можуть бути також застосовні і до інших аспектів безпеки ІТ.

ЗК застосовні при оцінці безпеки ІТ, включаючи як апаратні засоби, так і програмне забезпечення.

1.4. Концепції загальних критеріїв

Відповідно до концепції ЗК вимоги безпеки об'єкту оцінки підрозділяються на дві категорії:

- функціональні вимоги;

- вимоги гарантованості.

У функціональних вимогах ЗК описані ті функції об'єкту оцінки, які забезпечують безпеку ІТ. Наприклад, функціональні вимоги включають вимоги ідентифікації, встановлення достовірності (аутентифікації) користувачів, протоколювання (аудиту) та ін.

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

У ЗК функціональні вимоги і вимоги гарантованості представлені в одному і тому ж загальному стилі і використовують одну і ту ж організацію і термінологію.

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

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

Члени сімейства названі компонентами. Компонент описує певний набір вимог безпеки - найменший вибираний набір вимог безпеки для включення в структури, визначені в ЗК.

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

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

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

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

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

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

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

ЗК визначають також набір структур, які об'єднують компоненти вимог безпеки.

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

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

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

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

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

Завдання по Безпеці — основа для угоди між Розробниками об'єкту оцінки, Споживачами і Оцінювачами щодо безпеки об'єкту оцінки.

При виразі функцій безпеці і гарантій в Профілях Захисту і Завданнях по Безпеці необхідно враховувати наступні обмеження.

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

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

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

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

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

Концептуальна схема оцінки безпеки ІТ на основі ЗК представлена на рисунку 12.1.

Рис. 1 - Концептуальна схема оцінки безпеки ІТ на основі Загальних критеріїв

2. Загальні вимоги до сервісів безпеки

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

- загальні вимоги, застосовні до всіх або багатьох сервісів;

- спеціальні вимоги, специфічні для конкретного сервісу.

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

2.1. Загальні припущення безпеки

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

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

- Передбачається можливість віддаленого адміністрування сервісу.

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

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

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

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

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

- Передбачається неможливість обходу сервісу безпеки.

- Передбачається, що шкідливий код не може мати підпису довіреної сторони.

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

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

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

2.2. Загальні загрози безпеці

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

- Обхід зловмисником захисних засобів.

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

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

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

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

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

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

- Несанкціонована зміна зловмисником конфігурації сервісу і/або конфігураційних даних.

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

- Несанкціонований доступ до конфіденційної (наприклад, реєстраційною) інформації, зокрема несанкціонована розшифровка зашифрованих даних.

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

- Несанкціонований доступ до даних (на читання і/або зміну) в процесі їх передачі по мережі.

- Аналіз потоків даних з метою отримання конфіденційної інформації.

- Перенапрямлення потоків даних (зокрема, на системи, контрольовані зловмисником).

- Блокування потоків даних.

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

- Агресивне споживання зловмисником ресурсів, зокрема, ресурсів протоколювання і аудиту, а також смуги пропускання.

- Збереження залишкової інформації в багато разів використовуваних об'єктах.

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

2.3. Загальні елементи політики безпеки

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

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

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

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

• Описи правил протоколювання і аудиту для аналізу функціонування сервісу безпеки.

• Забезпечення доступності комунікаційних каналів.

• Описи правил забезпечення конфіденційності і цілісності інформації, що управляє (зокрема, при віддаленому адмініструванні).

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

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

2.4. Загальні цілі безпеки для об'єкту оцінки

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

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

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

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

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

- Виявлення спроб порушення політики безпеки, завдання реакції на подібні спроби.

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

- Перевірка програмного коду на наявність підпису довіреної сторони перед завантаженням коду в систему.

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

- Забезпечення безпечного відновлення після збоїв і відмов.

- Забезпечення конфіденційності і цілісності інформації при віддаленому адмініструванні сервісу.

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

- Наявність засобів розмежування доступу до компонентів і ресурсів сервісу безпеки.

- Наявність засобів контролю цілісності компонентів і ресурсів сервісу.

- Наявність засобів контролю коректності функціонування сервісу. Забезпечення безпеки багатократного використання об'єктів.

2.5. Загальні цілі безпеки для середовища

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

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

- Управління фізичним доступом до компонентів і ресурсів сервісу.

- Забезпечення неможливості обходу захисних засобів.

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

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

- Ліквідація даних аутентифікації і привілеїв користувачів, позбавлених доступу до сервісу безпеки.

- Розробка і реалізація процедур і механізмів, що оберігають від вторгнення шкідливого програмного забезпечення (ПЗ).

- Розробка і реалізація дисципліни доповіді про порушення інформаційної безпеки.

- Підготовка користувачів і обслуговуючого персоналу для протистояння методам морально-психологічної дії.

- Оперативна ліквідація виявлених уразливостей.

2.6. Загальні функціональні вимоги

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

Клас FAU: Аудит безпеки

Клас FCO: Зв'язок (комунікація)

Клас FCS: Криптографічна підтримка

Клас FDP: Захист даних користувача

Клас FIA: Ідентифікація і аутентифікація

Клас FMT: Управління безпекою

Клас FPR: Приватність

Клас FPT: Захист функцій безпеки

Клас FRU: Використання ресурсів

Клас FTA: Доступ до об'єкту оцінки

Клас FTP: Довірений маршрут/канал.

Розглянемо ці класи детальніше.

2.6.1. Клас FAU: Аудит безпеки

Для сервісів безпеки передбачаються наступні вимоги по протоколюванню і аудиту.

Автоматична реакція аудиту безпеки (FAU_ARP.1.1), наприклад, генерація запису в реєстраційному журналі, локальна або віддалена сигналізація адміністраторові про виявлення вірогідного порушення безпеки.

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

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

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

Вибір подій аудиту безпеки (FAU_SEL.1). Вибірковість реєстрації подій повинна ґрунтуватися, принаймні, на наступних атрибутах: ідентифікатор об'єкту, ідентифікатор суб'єкта, адреса вузла мережі, тип події, дата і час події.

Зберігання даних аудиту безпеки (FAU_STG.1.2). Реєстраційна інформація повинна бути захищена від несанкціонованої модифікації.

2.6.2. Клас FCO: Зв'язок (комунікація)

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

- безвідмовністю джерела (FCO_NRO.1, FCO_NRO.2);

- безвідмовністю приймача (FCO_NRR.1, FCO_NRR.2).

2.6.3. Клас FCS: Криптографічна підтримка

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

Управління криптографічними ключами (FCS_CKM). Повинні підтримуватися генерація криптографічних ключів (FCS_CKM.1), розподіл криптографічних ключів (FCS_CKM.2), управління доступом до криптографічних ключів (FCS_CKM.3), знищення криптографічних ключів (FCS_CKM.4).

Криптографічні операції (FCS_COP.1). Для всієї інформації, що передається по довіреному каналу, повинні здійснюватися шифрування і контроль цілісності відповідно до вимог стандартів і інших нормативних документів.

2.6.4. Клас FDP: Захист даних користувача

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

- Політика управління доступом (FDP_ACC.1.1). Повинне здійснюватися розмежування доступу для користувачів, прямо або що побічно виконують операції з сервісом безпеки.

- Функції управління доступом (FDP_ACF.1.1). Застосування функцій розмежування доступу повинне ґрунтуватися, принаймні, на наступних атрибутах безпеки: ідентифікатори суб'єктів доступу, ідентифікатори об'єктів доступу, адреси суб'єктів доступу, адреси об'єктів доступу, права доступу суб'єктів.

- Базовий захист внутрішньої передачі (FDP_ITT.1). Повинна здійснюватися задана політика управління доступом і/або інформаційними потоками, щоб запобігти розкриттю, модифікації і/або недоступності даних користувача при їх передачі між фізично розділеними частинами сервісу безпеки (FDP_ITT.1.1). Захист залишкової інформації (FDP_RIP.2.1). Для всіх об'єктів повинен забезпечуватися повний захист залишкової інформації, тобто недоступність попереднього стану при звільненні ресурсу.

2.6.5. Клас FIA: Ідентифікація і аутентифікація

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

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

- Визначення атрибутів користувача (FIA_ATD.1.1). Для кожного користувача необхідно підтримувати, принаймні, наступні атрибути безпеки: ідентифікатор, аутентифікаційна інформація (наприклад, пароль), права доступу (роль). Зокрема, якщо аутентифікаційна інформація забезпечується криптографічними операціями, повинні підтримуватися також відкриті і секретні ключі.

- Ідентифікація (FIA_UID) і аутентифікація (FIA_UAU) користувача. Кожен користувач повинен бути успішно ідентифікований (FIA_UID.2.1) і аутентифікований (FIA_UAU.2.1) до дозволу будь-якої дії, що виконується сервісом безпеки від імені цього користувача. Необхідно запобігати застосуванню аутентифікаційних даних, які були підроблені або скопійовані у іншого користувача (FIA_UAU.3). Слідує аутентифікувати будь-який представлений ідентифікатор користувача (FIA_UAU.5.2). Необхідно повторно аутентифікувати користувача після закінчення визначеного адміністратором інтервалу часу (FIA_UAU.6.1). Функції безпеки повинні надавати користувачеві тільки прихований зворотний зв'язок під час виконання аутентифікації (FIA_UAU.7).

- Скріплення користувач-суб'єкт (FIA_USB.1.1). Потрібно асоціювати відповідні атрибути безпеки користувача з суб'єктами, що діють від імені цього користувача.

2.6.6. Клас FMT: Управління безпекою

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

- Управління окремими функціями безпеки (FMT_MOF.1.1). Тільки адміністратор повинен мати можливість визначення режиму функціонування, відключення, підключення, модифікації режимів ідентифікації і аутентифікації, управління правами доступу, протоколювання і аудиту.

- Управління атрибутами безпеки (FMT_MSA). Тільки адміністратор повинен мати можливість зміни значень, що маються на увазі, опиту, зміни, видалення, створення атрибутів безпеки, правил управління потоками інформації (FMT_MSA.1.1). Необхідно забезпечити привласнення атрибутам безпеки тільки безпечних значень (FMT_MSA.2.1).

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

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

- Відміна (FMT_REV.1). Тільки у уповноважених адміністраторів повинна бути можливість відміни атрибутів безпеки, що асоціюються з користувачами. Важливі для безпеки повноваження повинні відмінятися негайно (FMT_REV.1.2).

- Ролі управління безпекою (FMT_SMR). Повинні підтримуватися, принаймні, наступні ролі: уповноважений користувач, віддалений користувач, адміністратор (FMT_SMR.1.1). Отримання ролей віддаленого користувача і адміністратора може проводитися тільки по явному запиту (FMT_SMR.3.1).

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

2.6.7. Клас FPR: Приватність

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

Прихованість (FPR_UNO). Адміністратор повинен мати можливість спостерігати за використанням ресурсів сервісу безпеки (FPR_UNO.4.1).

2.6.8. Клас FPT: Захист функцій безпеки

Власна захищеність - важлива характеристика будь-якого сервісу безпеки. У число загальних входять наступні вимоги. · Тестування абстрактної машини (FPT_AMT.1). Для демонстрації виконання припущень безпеки, що забезпечуються абстрактною машиною, покладеною в основу сервісу безпеки, при запуску і/або по запиту адміністратора повинен виконуватися пакет тестових програм (FPT_AMT.1.1).

- Безпека при збої (FPT_FLS). Сервіс повинен зберігати безпечний стан при апаратних збоях (викликаних, наприклад, перебоями електроживлення) (FPT_FLS.1.1).

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

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

- Виявлення повторного використання (FPT_RPL). Сервіс повинен виявляти повторне використання аутентифікаційних даних (FPT_RPL.1.1), відмовити в доступі, згенерувати запис реєстраційного журналу і сигналізувати адміністраторові про вірогідне порушення безпеки (FPT_RPL.1.2). · Посередництво при зверненнях (FPT_RVM). Функції, що здійснюють політику безпеки сервісу, повинні викликатися і успішно виконуватися перш, ніж вирішується виконання будь-якої іншої функції сервісу (FPT_RVM.1.1). Компонент FPT_RVM.1 направлений на забезпечення неможливості обходу захисних засобів.

- Розділення доменів (FPT_SEP). Функції безпеки повинні підтримувати окремий домен для власного виконання, який захищає їх від втручання і спотворення не довіреними суб'єктами (FPT_SEP.1.1).

- Мітки часу (FPT_STM). Для використання функціями безпеки повинні надаватися надійні мітки часу (FPT_STM.1.1).

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

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

- Самотестування функцій безпеки (FPT_TST). Для демонстрації правильності роботи функцій безпеки при запуску, періодично в процесі нормального функціонування і/або по запиту адміністратора повинен виконуватися пакет програм самотестування (FPT_TST.1.1). У адміністратора повинна бути можливість веріфікувати цілісність даних (FPT_TST.1.2) і виконуваного коду функцій безпеки (FPT_TST.1.3).

2.6.9. Клас FRU: Використання ресурсів

Цей клас встановлює три сімейства вимог, які забезпечують доступність ресурсів, таких як процесорні ресурси і ресурси пам'яті:

- відмовостійкість (FRU_FLT.1, FRU_FLT.2);

- пріоритет служби (сервісу) (FRU_PRS.1, FRU_PRS.2);

- розташування ресурсу (FRU_RSA.1, FRU_RSA.2).

2.6.10. Клас FTA: Доступ до об'єкту оцінки

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

- Обмеження на паралельні сеанси (FTA_MCS). Повинне обмежуватися максимальне число паралельних сеансів, що надаються одному користувачеві (FTA_MCS.1.1). У цієї величини повинне бути значення, що мається на увазі, встановлюється адміністратором (FTA_MCS.1.2).

- Блокування сеансу (FTA_SSL). Після закінчення встановленого адміністратором значення тривалості бездіяльності користувача сеанс роботи повинен примусово завершуватися (FTA_SSL.3.1).

- Відкриття сеансу з об'єктом оцінки (FTA_TSE). Сервіс повинен бути здатний відмовити у відкритті сеансу, ґрунтуючись на ідентифікаторі суб'єкта, паролі суб'єкта, правах доступу суб'єкта (FTA_TSE.1.1).

2.6.11. Клас FTP: Довірений маршрут/канал

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

- Довірений канал передачі між функціями безпеки (FTP_ITC). Для зв'язку з віддаленим довіреним виробом ІТ функції безпеки повинні надавати канал, який логічно відмітний від інших і забезпечує надійну аутентифікацію його сторін, а також захист даних від модифікації і розкриття (FTP_ITC.1.1). У обох сторін повинна бути можливість ініціації зв'язку через довірений канал (FTP_ITC.1.2, FTP_ITC.1.3).

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

2.7. Загальні вимоги довіри безпеці

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

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

До числа вимог довіри третього оцінного рівня входять:

- аналіз функціональної специфікації, специфікації інтерфейсів, експлуатаційної документації;

- незалежне тестування;

- наявність проекту верхнього рівня;

- аналіз стійкості функцій безпеки;

- пошук розробником явних уразливостей;

- контроль середовища розробки;

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

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

- повна специфікація інтерфейсів;

- наявність проектів нижнього рівня;

- аналіз підмножини реалізації;

- застосування неформальної моделі політики безпеки;

- незалежний аналіз уразливостей;

- автоматизація управління конфігурацією.

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

3. Специфічні вимоги до сервісів безпеки

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

Випуск і управління сертифікатами

Пропонується впорядковане сімейство з чотирьох профілів захисту для апаратний-програмних компонентів, що реалізовують випуск, анулювання і управління сертифікатами відкритих ключів (що задовольняють, наприклад, специфікаціям X.509) (Certificate Issuing and Management Components, CIMC).

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

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

- Центр випуску і анулювання сертифікатів (іменований також центром засвідчення, ЦЗ). Це – ядро ОО. Інформація, що згенерувала, поміщається в сховище. Між різними ЦЗ можуть існувати відносини довіри.

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

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

- Сервери відновлення і/або розповсюдження секретного ключового матеріалу. Ця функція також є додатковою.

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

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

- Криптографічний модуль. Він підписує сертифікати і списки їх анулювання, при необхідності генерує криптографічні ключі. Вимоги безпеки, що пред'являються до криптографічних модулів, викладені у федеральному стандарті США FIPS PUB 140-2, що замінив FIPS PUB 140-1.

- Модуль адміністрування.

- Модуль ідентифікації і аутентифікації.

- Модуль ролевого управління доступом.

- Модуль протоколювання і аудиту.

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

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

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

- оператора (що відповідає за резервне копіювання і відновлення);

- інспектора (що відає запитами і затвердженням сертифікатів і їх статусу);

- аудитора (що відповідає за аналіз реєстраційної інформації).

Відповідно до компоненту FMT_SMR.2 (обмеження на ролі безпеки), один користувач не може виступати більш ніж в одній з перерахованих вище ролей (FMT_SMR.2.3). Середовище повинне забезпечити захист конфіденційності даних користувача при передачі між функціями безпеки (FDP_UCT). Точніше повинна бути забезпечена базова конфіденційність обміну даними (FDP_UCT.1). Аналогічний захист повинен забезпечуватися для конфіденційних даних самого середовища (FPT_ITC.1, FPT_ITT.1). Крім того, потрібний контроль цілісності даних.

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

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

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

Ініціація і обробка події постановки третьою стороною підписаних міток часу (FPT_CIMC_TSP.2). Цей компонент аналогічний попередньому і забезпечує додатковий контроль цілісності реєстраційних даних (наприклад, на випадок компрометації об'єкту оцінки).

Резервне копіювання і відновлення (FDP_CIMC_BKP.1), з додатковими (криптографічними) заходами контролю цілісності і забезпечення конфіденційності (FDP_CIMC_BKP.2), з точністю до останньої завершеної транзакції (FDP_CIMC_BKP.3). Ці компоненти направлені на безпечне (зокрема вільне від впровадження шкідливого коду) відновлення. Відзначимо, що подібні вимоги корисні також для СУБД і інших систем з транзакціями.

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

Інформація, що експортується, про зміну статусу сертифікатів повинна мати формат, описаний в специфікаціях X.509 для списків анулювання або RFC 2560 для протоколу оперативної видачі статусу сертифікатів (FDP_CIMC_CSE.1).

Захист конфіденційності секретних ключів користувачів (FDP_ACF_CIMC.2) і функцій безпеки (FMT_MTD_CIMC.4). Секретні ключі обслуговуючого персоналу і функцій безпеки об'єкту оцінки повинні зберігатися в стандартному криптографічному модулі або шифруватися стандартними методами. Секретні ключі користувачів повинні шифруватися за допомогою довготривалих ключів захисту. Аналогічні вимоги пред'являються до зберігання секретних ключів симетричних методів шифрування (FDP_ACF_CIMC.3 і FMT_MTD_CIMC.5).

Секретні ключі повинні експортуватися або в зашифрованому вигляді, або з використанням процедур розділення знань (FDP_ETC_CIMC.4, FDP_ETC_CIMC.5, FMT_MTD_CIMC.6, FMT_MTD_CIMC.7).

Контроль цілісності відкритих ключів, що зберігаються (FDP_DSI_CIMC.3). Відкриті ключі, що зберігаються в об'єкті оцінки поза криптографічним модулем, повинні бути захищені від несанкціонованої зміни стандартними криптографічними методами. Перевірка цілісності повинна проводитися при кожному доступі до ключа.

Обнулення секретних ключів (FCS_CKM_CIMC.5). Функції безпеки повинні забезпечити обнулення відкритого представлення секретних ключів в криптографічному модулі.

Контроль допустимості значень полів сертифікатів (FMT_MOF_CIMC.3). Функції безпеки повинні контролювати значення полів сертифікатів відповідно до правил, заданих адміністратором. Аналогічні перевірки повинні проводитися для списків анульованих сертифікатів (FMT_MOF_CIMC.5) і повідомлень протоколу оперативної видачі статусу сертифікатів (FMT_MOF_CIMC.6).

Генерація сертифікатів (FDP_CIMC_CER.1). Повинні генеруватися тільки коректні сертифікати, що задовольняють вимогам стандарту (X.509) і правилам, заданим адміністратором. Аналогічні вимоги повинні виконуватися для списків анульованих сертифікатів (FDP_CIMC_CRL.1) і повідомлень протоколу оперативної видачі статусу сертифікатів (FDP_CIMC_OCSP.1). До випуску сертифікату необхідно переконатися, що його передбачуваний власник володіє секретним ключем, що асоціюється з відкритим ключем з сертифікату.

Вимоги довіри безпеці посилюються паралельно із зростанням вибраного рівня профілю захисту. Для верхнього, четвертого рівня використовуються в основному вимоги оціночний рівень довіри (ОРД4) і, частково, ОРД5, а також вимога ALC_FLR.3 (систематичне усунення недоліків), що не входить ні в один ОРД.

Практичне завдання

1. Створити профіль безпеки для заданих сервісів безпеки їх комбінацій і додатків.

Варіант 1. Профіль захисту для дискреційного (довільного) управління доступом.

Варіант 2. Профіль захисту для мандатного (примусового) управління доступом.

Варіант 3. Профіль захисту для ролевого управління доступом.

Варіант 4. Профіль захисту для системи активного аудиту.

2. Обґрунтувати запропоновані профілі.

3. Оформити протокол роботи у відповідності із додатком.

Контрольні запитання

1. Описати структуру стандарту ISO/IEC 15408.

2. Дати характеристику цільової спрямованості загальних критеріїв.

3. Які можливості і яку застосовність має стандарт ISO/IEC 15408?

4. Охарактеризувати основні концепції загальних критеріїв.

5. Яким чином організовані вимоги безпеки у загальних критеріях?

6. Які дії є дозволеними при перетворенні компонентів профілю захисту?

7. Яке призначення завдання по безпеці?

8. Які припущення безпеки застосовуються при описі середовища?

9. Які загрози розглядаються у середовищі функціонування ІТ?

10. В чому полягають загальні положення політики безпеки організації?

11. Якими є основні цілі безпеки для об’єкту оцінки?

12. Якими є основні цілі безпеки для середовища?

13. Назвіть основні класи функціональних вимог.

14. Які вимоги довіри відносяться до третього рівня?

15. Яку організацію мають специфічні вимоги (на прикладі)?