Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Безпека.docx
Скачиваний:
130
Добавлен:
31.08.2019
Размер:
6.2 Mб
Скачать

9.4. Структура основних документів «Загальних критеріїв»

9.4.1. Профіль захисту

Нижче наведено інформацію про структуру профілю захисту та зміст його основ­них розділів [8, 51, 57].

1. Вступ (Introduction).

У вступі подано інформацію, необхідну для пошуку профілю в бібліотеці про­філів (ідентифікатор) і огляд змісту.

1.1. Ідентифікатор (Identification).

Де унікальне ім'я, що використовують для пошуку профілю в бібліотеці профілів і для посилань на нього.

1.2. Огляд змісту (Overview).

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

2. Опис об'єкта оцінювання (Target of Evaluation Description).

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

    1. Середовище експлуатації (Security Environment).

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

3.1 Загрози безпеці (Threats).

Опис загроз безпеці, яким має протистояти захист. Для кожної загрози

вказуються джерело, метод впливу, об'єкт.

3.2. Політика безпеки (Organizational Security Policies).

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

Наведемо приклади політик безпеки [90].

  • P.AUTHORIZED_USERS (Авторизовані користувачі) — лише ті користувачі, яких було авторизовано для доступу до інформації в системі, можуть мати доступ до системи.

  • P.NEED_TO_KNOW (Необхідність знати) — система повинна об межувати можливість модифікувати та знищувати інформацію в захищених ресурсах для авторизованих користувачів, що потребують

цієї інформації.

  • P.ACCOUNTABILITY (Спостережність) — дії користувачів у системі мають бути контрольованими.

3.3. Умови експлуатації (Security Usage Assumptions).

Тут надається вичерпна характеристика середовища експлуатації в кон

тексті безпеки.

4. Задачі захисту (Security Objectives).

Йдеться про потреби користувачів протидіяти зазначеним загрозам безпеці та (або) реалізовувати політику безпеки. До задач захисту належать такі.

4.1. Задачі захисту, які вирішує сам ІТ-продукт (IT Security Objectives).

4.2. Інші задачі захисту (Non IT Security Objectives).

Як і політики безпеки, задачі захисту формалізовано та стандартизовано. Посилання на них можна робити за їхніми стандартними іменами. Наведемо кілька прикладів задач захисту ІТ-продукту [90].

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

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

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

Далі наведено приклади задач захисту, що здійснюють не ІТ-продукти.

  • O.INSTALL (Інсталяція) — відповідальні за об'єкт оцінювання особи мають гарантувати, що він постачається, інсталюється, обслуговуєть­ся і використовується у спосіб, що забезпечує підтримку успішного виконання задач захисту ІТ-продуктом.

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

  1. Вимоги безпеки (IT Security Requirements).

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

5.1. Функціональні Вимоги (Functional Requirements).

Лише типові вимоги, передбачені у відповідних розділах «Загальних кри­теріїв», які можуть зобов'язувати чи забороняти використовувати кон­кретні методи та засоби.

5.2. Вимоги адекватності (Assurance Requirements). Це також лише типові вимоги.

5.3. Вимоги до середовища експлуатації (Security Requirements for the IT En­vironment).

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

  1. Додаткові відомості.

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

  1. Обґрунтування (Rationale)

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

7.1. Обґрунтування задач захисту (Security Objectives Rationale) Демонструється, що запропоновані у профілі задачі захисту відповідають властивостям середовища експлуатації. За допомогою таблиць і додатко­вих коментарів показується, що кожній загрозі і кожному припущенню що­до безпеки відповідає щонайменше одна із зазначених у п. 4 задач захисту.

7.2. Обґрунтування вимог безпеки (Security Requirements Rationale).

Доводиться, що вимоги безпеки дозволяють вирішити задачі захисту, оскільки:

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

♦ вимоги безпеки є погодженими (не суперечать одна одній);

♦ усі взаємозв'язки між вимогами враховано;

♦ обраний набір вимог і рівень адекватності можуть бути обґрунтовані.

Усі обґрунтування слід подавати з використанням таблиць і доповнювати докладними поясненнями.