Затверджую
| Вид материала | Документы |
- Затверджую затверджую голова Кримського Голова Державної податкової Республіканського, 117.84kb.
- “Затверджую”, 639.38kb.
- Юрія Федьковича «затверджую», 585.95kb.
- Володимира Даля "затверджую", 183.23kb.
- Затверджую: Проректор з навчальної роботи, 59.36kb.
- «Затверджую», 21.74kb.
- Юрія Федьковича " затверджую, 825.92kb.
- Юрія Федьковича " затверджую, 245.34kb.
- Юрія Федьковича " затверджую, 501.24kb.
- Затверджую прийнятий на засіданні, 1283.44kb.
5.2 Функціональні вимоги безпеки об’єкта експертизи
Кожна функціональна вимога ФПЗ 3.КЦД.1wxp для співставлення з функціями сервісів безпеки ОЕ унікально ідентифікується у цьому документі позначенням, яке має наступну структуру:
| Н- | ХХ - | Н. | Н | |
| | | | | | | | | |
| | | | | | | ------- | Порядковий номер елементу вимоги |
| | | | | ------- | ------------- | Порядковий номер вимоги |
| | | ------- | ------------- | ------------- | Позначення функціональної послуги безпеки |
| ------ | ------------- | ------------- | ------------- | Рівень функціональної послуги безпеки |
Номер вимоги визначається порядковим номером відповідного рядка таблиці вимог окремого підрозділу вимог в документі [3]. Номер елементу вимоги визначається порядковим номером відповідного логічно завершеного положення (речення) окремої вимоги.
5.2.1 Конфіденційність
5.2.1.1 Довірча конфіденційність
Рівень КД 2. Базова довірча конфіденційність
| 2-КД-1.1 | Політика довірчої конфіденційності, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься |
| 2-КД-2.1 | КЗЗ повинен здійснювати розмежування доступу на підставі атрибутів доступу користувача і захищеного об'єкта |
| 2-КД-3.1 | Запити на зміну прав доступу до об'єкта повинні оброблятися КЗЗ на підставі атрибутів доступу користувача, що ініціює запит, і об'єкта |
| 2-КД-4.1 | КЗЗ повинен надавати користувачу можливість для кожного захищеного об'єкта, що належить його домену, визначити конкретних користувачів і/або групи користувачів, які мають право одержувати інформацію від об'єкта |
| 2-КД-5.1 | КЗЗ повинен надавати користувачу можливість для кожного процесу, що належить його домену, визначити конкретних користувачів і/або групи користувачів, які мають право ініціювати процес |
| 2-КД-6.1 | Права доступу до кожного захищеного об'єкта повинні встановлюватись в момент його створення або ініціалізації |
| 2-КД-6.2 | Як частина політики довірчої конфіденційності повинні бути представлені правила збереження атрибутів доступу об'єктів під час їх експорту та імпорту |
5.2.1.2 Повторне використання об’єктів
Рівень КО-1. Повторне використання об'єктів
| 1-КО-1.1 | Політика повторного використання об'єктів, що реалізується КЗЗ, повинна відноситись до всіх об'єктів КС |
| 1-КО-1.2 | Перш ніж користувач або процес зможе одержати в своє розпорядження звільнений іншим користувачем або процесом об'єкт, встановлені для попереднього користувача або процесу права доступу до даного об'єкта повинні бути скасовані |
| 1-КО-1.3 | Перш ніж користувач або процес зможе одержати в своє розпорядження звільнений іншим користувачем або процесом об'єкт, вся інформація, що міститься в даному об'єкті, повинна стати недосяжною |
5.2.1.3 Конфіденційність при обміні
Рівень КВ-2. Базова конфіденційність при обміні
| 2-КВ-1.1 | Політика конфіденційності при обміні, що реалізується КЗЗ, повинна визначати множину об'єктів і інтерфейсних процесів, до яких вона відноситься |
| 2-КВ-2.1 | Політика конфіденційності при обміні, що реалізується КЗЗ, повинна визначати рівень захищеності, який забезпечується механізмами, що використовуються, і спроможність користувачів і/або процесів керувати рівнем захищеності |
| 2-КВ-3.1 | КЗЗ повинен забезпечувати захист від безпосереднього ознайомлення з інформацією, що міститься в об'єкті, який передається |
| 2-КВ-4.1 | Запити на призначення або зміну рівня захищеності повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або користувачів, яким надані відповідні повноваження |
| 2-КВ-5.1 | Запити на експорт захищеного об'єкта повинні оброблятися передавальним КЗЗ на підставі атрибутів доступу інтерфейсного процесу |
| 2-КВ-6.1 | Запити на імпорт захищеного об'єкта повинні оброблятися приймальним КЗЗ на підставі атрибутів доступу інтерфейсного процесу |
5.2.2 Цілісність
5.2.2.1 Довірча цілісність
Рівень ЦД-1. Мінімальна довірча цілісність
| 1-ЦД-1.1 | Політика довірчої цілісності, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься |
| 1-ЦД-2.1 | КЗЗ повинен здійснювати розмежування доступу на підставі атрибутів доступу користувача і захищеного об'єкта |
| 1-ЦД-3.1 | Запити на зміну прав доступу до об'єкта повинні оброблятися КЗЗ на підставі атрибутів доступу користувача, що ініціює запит, і об'єкта |
| 1-ЦД-4.1 | КЗЗ повинен надавати користувачу можливість для кожного захищеного об'єкта, що належить його домену, визначити конкретних користувачів і/або групи користувачів, які мають право модифікувати об'єкт |
| 1-ЦД-5.1 | Права доступу до кожного захищеного об'єкта повинні встановлюватися в момент його створення або ініціалізації. |
| 1-ЦД-5.2 | Як частина політики довірчої цілісності мають бути представлені правила збереження атрибутів доступу об'єктів під час їх експорту і імпорту |
5.2.2.2 Відкат
Рівень ЦО-1. Обмежений відкат
| 1-ЦО-1.1 | Політика відкату, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься |
| 1-ЦО-2.1 | Повинні існувати автоматизовані засоби, які дозволяють авторизованому користувачу або процесу відкатити або відмінити певний набір (множину) операцій, виконаних над захищеним об'єктом за певний проміжок часу |
5.2.2.3 Цілісність при обміні
Рівень ЦВ-2. Базова цілісність при обміні
| 2-ЦВ-1.1 | Політика цілісності при обміні, що реалізується КЗЗ, повинна визначати множину об'єктів КС і інтерфейсних процесів, до яких вона відноситься, рівень захищеності, що забезпечується використовуваними механізмами, і спроможність користувачів і/або процесів керувати рівнем захищеності |
| 2-ЦВ-2.1 | КЗЗ повинен забезпечувати можливість виявлення порушення цілісності інформації, що міститься в об'єкті, який передається а також фактів його видалення або дублювання |
| 2-ЦВ-3.1 | Запити на експорт захищеного об'єкта повинні оброблятися передавальним КЗЗ на підставі атрибутів доступу інтерфейсного процесу |
| 2-ЦВ-4.1 | Запити на імпорт захищеного об'єкта повинні оброблятися приймальним КЗЗ на підставі атрибутів доступу інтерфейсного процесу |
| 2-ЦВ-5.1 | Запити на присвоєння або зміну рівня захищеності повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або користувачів, яким надані відповідні повноваження |
5.2.3 Доступність
5.2.3.1 Використання ресурсів
Рівень ДР-1. Квоти
| 1-ДР-1.1 | Політика використання ресурсів, що реалізується КЗЗ, повинна визначати множину об'єктів КС, до яких вона відноситься |
| 1-ДР-2.1 | Політика використання ресурсів повинна визначати обмеження, які можна накладати, на кількість даних об'єктів (обсяг ресурсів), що виділяються окремому користувачу |
| 1-ДР-3.1 | Запити на зміну встановлених обмежень повинні оброблятися КЗЗ тільки в тому випадку, якщо вони надходять від адміністраторів або від користувачів, яким надані відповідні повноваження |
5.2.3.2 Гаряча заміна
Рівень ДЗ-1. Модернізація
| 1-ДЗ-1.1 | Політика гарячої заміни, що реалізується КЗЗ, повинна визначати політику проведення модернізації КС |
| 1-ДЗ-2.1 | Адміністратор або користувачі, яким надані відповідні повноваження, повинні мати можливість провести модернізацію (upgrade) КС |
| 1-ДЗ-2.2 | Модернізація КС не повинна призводити до необхідності ще раз проводити інсталяцію КС або до переривання виконання КЗЗ функцій захисту |
5.2.3.3 Відновлення після збоїв
Рівень ДВ-1. Ручне відновлення
| 1-ДВ-1.1 | Політика відновлення, що реалізується КЗЗ, повинна визначати множину типів відмов КС і переривань обслуговування, після яких можливе повернення у відомий захищений стан без порушення політики безпеки |
| 1-ДВ-1.2 | Повинні бути чітко вказані рівні відмов, у разі перевищення яких необхідна повторна інсталяція КС |
| 1-ДВ-3.1 | Після відмови КС або переривання обслуговування КЗЗ повинен перевести КС до стану, із якого повернути її до нормального функціонування може тільки адміністратор або користувачі, яким надані відповідні повноваження |
| 1-ДВ-4.1 | Повинні існувати ручні процедури, за допомогою яких можна безпечним чином повернути КС до нормального функціонування |
5.2.4 Спостереженість
5.2.4.1 Реєстрація (аудит)
Рівень НР-2. Захищений журнал
| 2-НР-1.1 | Політика реєстрації, що реалізується КЗЗ, повинна визначати перелік подій, що реєструються |
| 2-НР-2.1 | КЗЗ повинен бути здатним здійснювати реєстрацію подій, що мають безпосереднє відношення до безпеки |
| 2-НР-3.1 | Журнал реєстрації повинен містити інформацію про дату, час, місце, тип і успішність чи неуспішність кожної зареєстрованої події |
| 2-НР-3.2 | Журнал реєстрації повинен містити інформацію, достатню для встановлення користувача, процесу і/або об'єкта, що мали відношення до кожної зареєстрованої події |
| 2-НР-4.1 | КЗЗ повинен забезпечувати захист журналу реєстрації від несанкціонованого доступу, модифікації або руйнування |
| 2-НР-4.2 | Адміністратори і користувачі, яким надані відповідні повноваження, повинні мати в своєму розпорядженні засоби перегляду і аналізу журналу реєстрації |
5.2.4.2 Ідентифікація і автентифікація
Рівень НИ-2. Одиночна ідентифікація і автентифікація
| 2-НИ-1.1 | Політика ідентифікації і автентифікації, що реалізується КЗЗ, повинна визначати атрибути, якими характеризується користувач, і послуги, для використання яких необхідні ці атрибути |
| 2-НИ-1.2 | Кожний користувач повинен однозначно ідентифікуватися КЗЗ |
| 2-НИ-2.1 | Перш ніж дозволити будь-якому користувачу виконувати будь-які інші, контрольовані КЗЗ дії, КЗЗ повинен автентифікувати цього користувача з використанням захищеного механізму |
| 2-НИ-3.1 | КЗЗ повинен забезпечувати захист даних автентифікації від несанкціонованого доступу, модифікації або руйнування |
5.2.4.3 Достовірний канал
Рівень НК-1. Однонаправлений достовірний канал
| 1-НК-1.1 | Політика достовірного каналу, що реалізується КЗЗ, повинна визначати механізми встановлення достовірного зв'язку між користувачем і КЗЗ |
| 1-НК-2.1 | Достовірний канал повинен використовуватися для початкової ідентифікації і автентифікації |
| 1-НК-2.2 | Зв'язок з використанням даного каналу повинен ініціюватися виключно користувачем |
5.2.4.4 Розподіл обов'язків
Рівень НО-2. Розподіл обов'язків адміністраторів
| 2-НО-1.1 | Політика розподілу обов'язків, що реалізується КЗЗ, повинна визначати ролі адміністратора і звичайного користувача і притаманні їм функції |
| 2-НО-2.1 | Політика розподілу обов'язків повинна визначати мінімум дві адміністративні ролі: адміністратора безпеки та іншого адміністратора |
| 2-НО-2.2 | Функції, притаманні кожній із ролей, повинні бути мінімізовані так, щоб включати тільки ті функції, які необхідні для виконання даної ролі |
| 2-НО-3.1 | Користувач повинен мати можливість виступати в певній ролі тільки після того, як він виконає певні дії, що підтверджують прийняття їм цієї ролі |
5.2.4.5 Цілісність КЗЗ
Рівень НЦ-2. КЗЗ з гарантованою цілісністю
| 2-НЦ-1.1 | Політика цілісності КЗЗ повинна визначати домен КЗЗ та інші домени, а також механізми захисту, що використовуються для реалізації розподілення доменів |
| 2-НЦ-2.1 | КЗЗ повинен підтримувати домен для свого власного виконання з метою захисту від зовнішніх впливів і несанкціонованої модифікації і/або втрати керування |
| 2-НЦ-3.1 | Повинні бути описані обмеження, дотримання яких дозволяє гарантувати, що послуги безпеки доступні тільки через інтерфейс КЗЗ і всі запити на доступ до захищених об'єктів контролюються КЗЗ |
5.2.4.6 Самотестування
Рівень НТ-2. Самотестування при старті
| 2-НТ-1.1 | Політика самотестувания, що реалізується КЗЗ, повинна описувати властивості КС і реалізовані процедури, які можуть бути використані для оцінки правильності функціонування КЗЗ |
| 2-НТ-2.1 | КЗЗ має бути здатним виконувати набір тестів з метою оцінки правильності функціонування своїх критичних функцій. Тести повинні виконуватися за запитом користувача, що має відповідні повноваження, при ініціалізації КЗЗ |
5.2.4.7 Ідентифікація і автентифікація при обміні
Рівень НВ-1. Автентифікація вузла
| 1-НВ-1.1 | Політика ідентифікації і автентифікація при обміні, що реалізується КЗЗ, повинна визначати множину атрибутів КЗЗ і процедури, які необхідні для взаємної ідентифікації при ініціалізації обміну даними з іншим КЗЗ |
| 1-НВ-1.2 | КЗЗ, перш ніж почати обмін даними з іншим КЗЗ, повинен ідентифікувати і автентифікувати цей КЗЗ з використанням захищеного механізму |
| 1-НВ-1.3 | Підтвердження ідентичності має виконуватися на підставі затвердженого протоколу автентифікації |
5.2.4.8 Автентифікація відправника
Рівень НА-1. Базова автентифікація відправника
| 1-НА-1.1 | Політика автентифікації відправника, що реалізується КЗЗ, повинна визначати множину властивостей і атрибутів об'єкта, що передається, користувача-відправника і інтерфейсного процесу, а також процедури, які дозволяли б однозначно встановити, що даний об'єкт був відправлений (створений) певним користувачем |
| 1-НА-2.1 | Встановлення належності має виконуватися на підставі затвердженого протоколу автентифікації |
5.2.4.9 Автентифікація отримувача
Рівень НП-1. Базова автентифікація отримувача
| 1-НП-1.1 | Політика автентифікації одержувача, що реалізується КЗЗ, повинна визначати множину властивостей і атрибутів об'єкта, що передається, користувача-одержувача і інтерфейсного процесу, а також процедури, які дозволяли б однозначно встановити, що даний об'єкт був одержаний певним користувачем |
| 1-НП-2.1 | Встановлення одержувача має виконуватися на підставі затвердженого протоколу автентифікації |