ГОСТ Р 54582—2011
администратора, механизмы проверки должны распространяться на сигнальные, связанные с безопас-
ностью события, и должна возникать потребность в процедурах восстановления систем. Система в
значительной степени должна быть защищена от проникновения.
Класс А1: верифицированный проект — системы класса А1 функционально эквивалентны систе-
мам класса В3 в отсутствиe дополнительных архитектурных особенностей или требований к полити-
ке безопасности. Отличительной характеристикой систем этого класса являются анализ, следующий
из формальной спецификации проекта и методов верификации, и полученная высокая степень дове-
рия к правильности реализации ТСВ. По своему характеру это доверие является экспериментальным
(опытным), начиная с официальной модели политики безопасности и официальной высокоуровневой
спецификации (FTLS) проекта. FTLS является высокоуровневой спецификацией системы, записанной
на формальном математическом языке для формирования гипотез из теорем (демонстрирующих со-
ответствие спецификации системы ее формальным требованиям) и их формального доказательства.
Для соответствия расширенному проекту и анализу проекта ТСВ, необходимых для систем класса А1,
требуется более строгое конфигурационное управление и формирование процедур безопасного рас-
пределения системы по местам эксплуатации. Администратору безопасности системы должна быть
оказана поддержка.
6.2.3 Источники
См. [45].
Примечание — Все TCSEC, их интерпретации и руководства имеют разноцветные обложки и ино-
гда называются «Радужной серией». TCSEC являются внутренним стандартом и продуктом Министерства
обороны США.
6.3 ITSEC/ITSEM — методология и критерии оценивания безопасности информационных
технологий
D
I
O
10
6.3.1 Цель
Предоставление структуры критериев и методологии оценивания безопасности ИТ для европей-
ского рынка.
6.3.2 Описание
«Критерии оценивания безопасности информационных технологий (ITSEC)» и «Руководство по
оцениванию безопасности информационных технологий (ITSEM)» находятся среди документов, пред-
шествующих общим критериям и общей методологии оценки. Они были разработаны четырьмя евро-
пейскими странами: Францией, Германией, Нидерландами и Великобританией.
Доверие в ITSEC основано на подходе, представленном в TCSEC. Однако разделение между
функциональными требованиями и требованиями доверия в ITSEC допускает большую гибкость. Тре-
бования доверия, в свою очередь, делятся на два аспекта — эффективность и правильность. Оценка
эффективности включает в себя рассмотрение следующих аспектов объекта оценки (ОО):
- приемлемость функций обеспечения безопасности ОО для противодействия угрозам безопас-
ности ОО, идентифицированным в нем;
- способность функций и механизмов обеспечения безопасности ОО объединяться на основе вза-
имной поддержки и формировать интегрированное и эффективное целое;
- способность механизмов обеспечения безопасности ОО противостоять прямым атакам;
- возможность на практике компрометации безопасности известными уязвимостями безопасности
в конструкции ОО;
- невозможность конфигурирования или использования ОО небезопасным способом, но считаю-
щимся безопасным администратором или конечным пользователем ОО;
- возможность компрометации на практике безопасности известными уязвимостями безопасности
при функционировании ОО.
Требования к эффективности доверия сосредоточены в основном на случаях, когда оценщику
приходится применять собственные знания и опыт для оценки обоснованности подхода к безопасности в
оцененном продукте или системе ИТ.
Требования доверия к правильности в ITSEC сосредоточены в основном на аспектах, которые
должны подтверждать правильность информации разработчика относительно безопасности ИТ оце-
ненного
продукта
или
системы.