Единые критерии. Уровни адекватности

Каждый уровень характеризуется набором требований адекватности.

1) Функциональное тестирование (минимальный уровень) содержит требования к управлению версиями, установке, настройке и запуску, общим функциональным спецификациям, соответствию описаний различного уровня, руководствам администратора и пользователя, независимому тестированию и некоторые др.

2) Структурное тестирование дополняет первый уровень:

- появляются требование №2 в группе управления версиями;

- появляется требование по поставке;

- архитектура защиты (требование №1);

- полнота и методика тестирования (требование №1);

- анализ стойкости и поиск уязвимостей (требование №1).

3) Методическое тестирование. Дополняет второй уровень:

- появляется требование №3 к управлению версиями;

- конфигурация проекта (требование №1);

- архитектура защиты, полнота тестирования, независимое тестирование (требование №2);

- безопасность среды разработки, глубина тестирования, анализ возможностей неправильного использования (требование №1).

4) Методическое тестирование, разработка и анализ дополняет третий уровень:

- средства управления проектом, форма представления продукта, частные спецификации, ПБ, технология и средства разработки (требование №1);

- управление версиями (требование №4);

- конфигурация проекта, поставка, общие функциональные спецификации, анализ возможностей неправильного использования, анализ на наличие уязвимостей (требование №2).

5) Полуформальные методы тестирования дополняет четвертый уровень:

- структура средств защиты, анализ СКУИ (требование №1);

- конфигурация проекта, общие функциональные спецификации, архитектура защиты, анализ на наличие уязвимостей (требование №3);

- форма представления продукта, соответствие описаний различного уровня, ПБ, технология и средства разработки, глубина тестирования (требование №2).

6) Полуформальные методы верификации разработки и тестирования. Дополняет пятый уровень:

- средства управления проектом, структура средств защиты, частные спецификации средств защиты, безопасность среды разработки, методика тестирования, анализ СКУИ (требование №2);

- управление версиями (требование №5)

- архитектура защиты, анализ на наличие уязвимостей (требование №4);

- форма представления продукта, средства разработки, полнота тестирования, анализ возможностей неправильного использования (требование №3).

7) Формальные методы верификации разработки и тестирования. Дополняет шестой уровень до максимума:

- поставка, структура средств защиты, соответствие описаний различного уровня, ПБ, технология разработки, глубина тестирования, независимое тестирование (требование №3);

- общие функциональные спецификации (требование №4);

- архитектура защиты (требование №5).

Единые критерии являются наиболее широко используемым в мире стандартом, содержащим профиль защиты и задание по безопасности.

Сертификация средств защиты в Российской Федерации

В РФ существует три основных службы по сертификации ИТ-продуктов: ФСТЭК, ФСБ и Министерство Обороны РФ. При этом ФСБ занимается криптографических средств защиты, АС для органов государственной власти, средств связи и телекоммуникационного оборудования. Министерство Обороны занимается только сертификацией средств защиты, используемых им. А ФСТЭК занимается сертификацией всех остальных средств защиты.

Система сертификации в РФ приведена на Рис., где НСД – несанкционированный доступ к информации, НДВ – недокументированные возможности, РДВ – реальные декларированные возможности.

Рис. 3.3. Система сертификации в РФ

При подаче заявки на сертификацию ИТ-продукта во ФСТЭК продукт сначала передается органам сертификации, а затем тестируется в испытательных лабораториях. Результаты тестирования передаются органам сертификации, которые подтверждают соответствие ИТ-продукта профилю защиты (см. рис. 3.4).

Рис. 3.4. Схема сертификации ИТ-продукта

Дата добавления: 2014-11-20