Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Orange_FAQ.docx
Скачиваний:
6
Добавлен:
30.07.2019
Размер:
2.59 Mб
Скачать

Основные понятия

Если попытаться кратко сформулировать главную концепцию "Общих критериев", то, скорее всего, она будет выглядеть как "угрозы и профили". Окружающий нас мир не просто не идеален, он опасен. И эксплуатируемые в нем комплексные системы и ПО буквально со всех сторон окружают угрозы. В зависимости от того, в каких условиях эксплуатируется конкретный ИТ-объект (например, подключена ли данная система к сетям общего пользования или функционирует автономно), к нему можно предъявить столь же конкретный перечень требований к защите, т. е. формализовать так называемый профиль защиты. Такие требования могут быть сформулированы пользователем в техническом задании на разработку или сформированы самостоятельно создателем системы или средства. В процессе сертификации некой системы по ОК сертифицирующий орган рассматривает документ, который называется "задание по безопасности", - представляемый разработчиком системы в органы сертификации перечень требований к данной системе по безопасности. Сертификат подтверждает факт наличия в системе функционала, выполняющего заявленные требования по безопасности.

Профили

Профиль защиты - одно из основных понятий "Общих критериев". В тексте стандарта это понятие определяется следующим образом: "Независимая от реализации совокупность требований безопасности для некоторой категории продуктов или ИТ-систем, отвечающая специфическим запросам потребителя".

Можно сказать, что в привычных терминах профиль имеет много общего с техническим заданием. Все очень похоже - то же самое описание функционала будущей системы защиты информации (СЗИ), причем минимально привязанное к конкретной реализации (теоретически никак не привязанное). Вообще говоря, профиль допускается создавать как непосредственно для продукта, который представляет собой СЗИ, так и для защитной подсистемы какого-либо (практически любого) программного продукта. Более того, можно написать один профиль для целой совокупности программных продуктов. Так, существуют профили (на сегодняшний день только в виде проектов) для межсетевых экранов, профиль для СУБД (по сути, набор требований по безопасности для защиты СУБД), для клиентской ОС и т. д.

Каталог фбо

Все механизмы защиты, описанные в профиле, называются функциями безопасности объекта (ФБО). Автор профиля не выдумывает ФБО, а берет их из специального "каталога" функций безопасности, который входит составной частью в "Общие критерии" (2-я часть ГОСТ). В данном "каталоге" функции безопасности описаны достаточно жестко и формально. В то же время в этих спецификациях приведены формальные и жесткие правила, которые позволяют "модернизировать" функции безопасности, по сути - уточнить и конкретизировать, сделав их адекватными требованиям к конкретному механизму защиты.

В частности, стандарт предусматривает такие операции, как "уточнение" и "выбор". Операция "уточнение" используется для добавления к требованию некоторых подробностей (деталей), а операция "выбор" - для выбора одного или нескольких элементов из перечня в формулировке требования.

Угрозы, политики и предположения безопасности

Но и набор функций безопасности не формируется автором профиля защиты "из головы". Согласно ОК, в профиль защиты включаются только те функции безопасности, которые должны защищать от угроз и соответствовать политике безопасности. Отсутствие всех остальных функций безопасности "объясняется" предположениями безопасности.

Предположения безопасности - это описание конкретных условий, в которых будет эксплуатироваться система. Например, компьютер с установленной программой должен стоять в помещении, находящемся под охраной. В дальнейшем на основе предположений можно, например, отсекать часть угроз как нереализуемых в данных условиях эксплуатации информационной системы. Другой пример предположения - требования к эксплуатации программного продукта, выполняющего шифрование и расшифровывание данных на диске после идентификации и аутентификации пользователя по имени и паролю. Очевидно, что злоумышленник способен получить доступ к данным, если сможет "перехватить" пароль и имя пользователя с помощью программ-закладок. Однако защита от этой угрозы уже выходит за рамки действия простого ПО шифрования данных (это скорее требование к "доверенной операционной системе"). Поэтому для сужения требований функционала к ПО шифрования вводится предположение безопасности, которое формулируется так: "Предполагается, что программная и аппаратная среда функционирования является доверенной". Введя такое предположение, разработчик профиля защиты для ПО шифрования сокращает избыточные функционалы.

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

Понятие политики безопасности определено в 1-й части ОК следующим образом: "Одно или несколько правил, процедур, практических приемов или руководящих принципов в области безопасности, которыми руководствуется организация в своей деятельности". В общем случае такой набор правил представляет собой некий функционал программного продукта, который необходим для его использования в конкретной организации. Если подходить к политике более формально, то она есть набор неких требований к функционалу системы защиты, закрепленных в ведомственных документах. Например, в финансовых организациях зачастую принято, чтобы в продукте предусматривалось присутствие нескольких административных ролей: администратор, аудитор и оператор системы защиты. Такое ролевое управление информационной безопасностью - скорее дань традиции и теоретически позволяет избежать "сговора" администратора и злоумышленника из числа пользователей. Для того, чтобы включить данный функционал продукта в профиль защиты, целесообразнее всего ввести соответствующую политику безопасности, например, так: "Администраторы должны нести ответственность за свои действия в системе".

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]