
- •Предметный указатель
- •Лекция 1 (15.02.2013)
- •Требования к ас и свт
- •Классификация ас
- •Безопасность в Общих критериях
- •Понятие безопасности и их взаимосвязь
- •История создания ок и регламентирующие документы в России и Мире.
- •Цели Общих Критериев и их использование
- •Ключевые понятия Общих критериев
- •Структура проекта защиты и задания по безопасности
- •Лекция 2 (01.03.2013)
- •Краткое изложение концепции ок
- •Механизм использования требований по безопасности
- •Ключевые понятия функциональных требований безопасности (единый оо)
- •Структура требований ок
- •Функциональные классы безопасности
- •Классы требований доверия
- •Сертификационные испытания (оценка) на соответствие
- •Выдержки из гост р исо/мэк 15408-1 (проект)
- •Лекция 3 (15.03.2013)
- •Представление оо
- •Конфигурация оо
- •Активы и контрмеры
- •Достаточность контрмер
- •Корректность оо
- •Корректность среды функционирования
- •Оценка зб и оо
Краткое изложение концепции ок
В Профилях защиты (ПЗ) и Заданиях по безопасности (ЗБ) собраны требования по безопасности.
Для справки: Профиль защиты (ПЗ) – определяет совокупность требований ИТ для некоторой категории ОО. Задание по безопасности (security target – «цель безопасности») – изложение потребностей в безопасности для конкретного ОО. На практике потребитель обращается к разработчику для составления ПЗ. В теории: ПЗ разрабатывает потребитель. ЗБ должно отвечать ПЗ. В ЗБ более детально описывается продукт
.
Механизм использования требований по безопасности
Разработать пакет
Каталог
пакетов
Разработать ПЗ
Разработать ЗБ
Каталог
ПЗ
Требования безопасности
Схема оценки продукта, разработанного в соответствии с ЗБ по ТБ
Схема оценки продукта до v.3.1
Ключевые понятия функциональных требований безопасности (единый оо)
На текущий момент не актуальна. В CC v 3.1 нет.
Структура требований ок
Разработ-
ать и оценить ОО
Требования
безопас – ности
Результаты
оценки
Оцененный
продукт
Аттесто-
вать систему
1, 2, 3, 4 – компоненты семейства. Семейство 1 – иерархичное. Семейства 2 и 3 имеют смешанную иерархию. В семействе 1 компонент 3 имеет самые высокие требования.
Последующий компонент иерархичен предыдущему если он содержит все элементы требований предыдущего компонента и либо содержит элементы усиленные, относительно соответствующих элементов предыдущего компонента и/или содержит дополнительные элементы.
В качестве примера: Функциональный класс «Связь»
FCO_NRO.1 «Избирательное доказательство отправления» содержит требование, чтобы ФБО (функциональная безопасность объекта) предоставила субъектам возможность запросить свидетельство отправления информации.
FCO_NRO.1.1 ФБО должна быть способна генерировать свидетельство отправления передаваемой [назначение: список типов информации] при запросе [выбор: отправитель, получатель, [назначение: список третьих лиц]].
FCO_NRO.1.2 ФБО должна быть способна связать [назначение: список атрибутов] отправителя информации и [назначение: список информационных полей] информации, к которой прилагается свидетельство.
FCO_NRO.1.3 ФБО должна предоставить возможность верифицировать свидетельство отправления информации [выбор: отправитель, получатель, [назначение: список третьих лиц]] при установленных [назначение: ограничения на свидетельство отправления].
Комментарий: Назначение:
В FCO_NRO.1.1 автору ПЗ/ЗБ следует указать типы информационных объектов, для которых требуется предоставление свидетельства отправления, например, сообщения электронной почты.
Выбор:
В FCO_NRO.1.1 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может запросить свидетельство отправления.
Назначение:
В FCO_NRO.1.1 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третьих лиц, которые могут запросить свидетельство отправления. Третьим лицом может быть арбитр, судья или юридический орган.
FCO_NRO.2» «Принудительное доказательство отправления» содержит требование, чтобы ФБО всегда генерировали свидетельство отправления переданной информации.
Компоненты ОК можно использовать точно так, как они сформулированы в ОК, или же можно их конкретизировать, применяя разрешенные операции для выполнения определенной политики безопасности или для противостояния определенной угрозе. Количество требований должно в точности совпадать с их числом в ОК.
Виды операций над формулировкой требований («раскрытие скобок»):
итерация позволяющая неоднократно использовать компонент при различном выполнении в нем операций //одно и то же требование, но с различными параметрами (при входе в систему набрать пароль не меньше 6 символов, при входе в систему управления системой – не менее 10 символов);
назначение, позволяющее специфицировать параметр, устанавливаемый при использовании компонента //привести соответствующий список;
выбор, позволяющий специфицировать пункты, которые выбираются из перечня, приведенного в компоненте //позволяет выбрать пункты из перечисления;
уточнение, позволяющее осуществлять дополнительную детализацию при использовании компонента //не допускает изменения сути требований.