19 мон ГЮІ 2015. 1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації

• Название: 1. 9 Вимоги та їх реалізація при побудування засобів криптографічного захисту інформації
• Дата: 11.01.2022
• Размер: 227.06 Kb.
• Имя файла: 19 мон ГЮІ 2015.docx
• Тип: Документы; #328148
• страница: 24 из 29

2.2.29 Поставка та експлуатація

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

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

Рівні безпеки 2 і 3.На додаток до вимог рівня безпеки 1, документація повинна визначати процедури, необхідні для забезпечення безпеки під час розповсюдження, встановлення та ініціалізації версій криптографічного модуля для уповноважених операторів. Ці процедури повинні визначати, як виявити вторгнення під час доставки, установки та ініціалізації модуля для уповноважених операторів.

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

2.2.30 Кінець існування модуля

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

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

Рівні безпеки 3 і 4. На додаток до вимог Рівнів безпеки 1 і 2, документація повинна визначати процедури, необхідні для безпечного знищення модуля.

2.2.31 Керівні документи

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

Керівна документація складається з керівництва адміністратора і не‑адміністратора.

Керівництво адміністратора повинне визначати:

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

Керівництво не-адміністратора повинне визначати:

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

2.2.32 Відбиття інших атак

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

Повинні виконуватися вимоги до документації.

Рівні безпеки 1, 2 і 3. Якщо криптографічний модуль спроектований відбивати одну або декілька конкретних атак, не визначених в цьому міжнародному стандарті, то супутня документація на модуль повинна перерахувати атаки, які модуль повинен відбивати. Існування і належне функціонування механізмів безпеки, що використовуються для відбиття атак буде підтверджено, коли вимоги та пов'язані з ними тести будуть розроблені.

Рівень безпеки 4. На додаток до вимог для рівнів безпеки 1, 2 і 3, наступна вимога відносяться до криптографічних модулів з Рівнем безпеки 4:

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