ïôï

Волоконно-оптические системы передачи Конспект лекций оглавление Защита информации в сетях связи с гарантированным качеством обслуживания Введение Ни одна сфера жизни современного общества не может функционировать без развитой информационной структуры. Национальный информационный ресурс является сегодня одним из главных источников экономической и военной мощи государства. Проникая во все сферы деятельности государства, информация приобретает конкретное политическое, экономическое и материальное выражение. На этом фоне все более актуальный характер приобретает в последние десятилетия и, особенно в настоящее время, задача обеспечения информационной безопасности Российской Федерации как неотъемлемого элемента ее национальной безопасности, а защита информации превращается в одну из приоритетных государственных задач. Вопросы защиты информации всегда занимали особое место в любом обществе и государстве. В настоящее время, когда сохраняется лавинообразное распространение компьютерных систем и их взаимодействие посредством телекоммуникационных сетей, защита информации пользователей и служебной информации выступает на одно из первых мест. 1 Общие положения 1.1 Основные определения Введем некоторые понятия и определения, необходимые в дальнейшем. На рисунке 1.1 приведена классификация основных определений и понятий предметной области “Защита информации” [1, 2]. Информация [1] – сведения о лицах, предметах, фактах, событиях, явлениях и процессах независимо от формы их представления. Защищаемая информация – информация, являющаяся предметом собственности и подлежащая защите в соответствии с требованиями правовых документов или требованиями, устанавливаемыми собственником информации. Собственником информации может быть: государство, юридическое лицо, группа физических лиц, отдельное физическое лицо. Защита информации – деятельность, направленная на предотвращение утечки защищаемой информации, несанкционированных и непреднамеренных воздействий на защищаемую информацию. Защита информации от утечки – деятельность, направленная на предотвращение неконтролируемого распространения защищаемой информации в результате ее разглашения, несанкционированного доступа к информации и получения защищаемой информации разведками. Защита информации от несанкционированного воздействия – деятельность, направленная на предотвращение воздействия на защищаемую информацию с нарушением установленных прав и (или) правил на изменение информации, приводящего к ее искажению, уничтожению, блокированию доступа к информации, а также к утрате, уничтожению или сбою функционирования носителя информации. Защита информации от непреднамеренного воздействия – деятельность, направленная на предотвращение воздействия на защищаемую информацию ошибок ее пользователя, сбоя технических и программных средств информационных систем, природных явлений или иных нецеленаправленных на изменение информации мероприятий, приводящих к искажению, уничтожению, копированию, блокированию доступа к информации, а также к утрате, уничтожению или сбою функционирования носителя информации. Защита информации от разглашения – деятельность, направленная на предотвращение несанкционированного доведения защищаемой информации до потребителей, не имеющих права доступа к этой информации. Защита информации от несанкционированного доступа – деятельность, направленная на предотвращение получения защищаемой информации заинтересованным субъектом с нарушением установленных правовыми документами или собственником, владельцем информации прав или правил доступа к защищаемой информации. 1.2 Требования к системам телекоммуникаций Приведем основные требования, предъявляемые пользователями к системам телекоммуникаций с позиций обеспечения защиты передаваемой информации. Системы телекоммуникаций должны обеспечить: конфиденциальность информации – обеспечение просмотра информации в приемлемом формате только для пользователей, имеющих право доступа к этой информации; целостность информации – обеспечение неизменности информации при ее передаче; аутентичность информации – обеспечение надежной идентификации источника сообщения, а также гарантия того, что источник не является поддельным. доступность информации – гарантия доступа санкционированных пользователей к информации. 1.2 Классификация нарушений передачи информации Нормальная передача информации (рисунок 1.2 а)) в сетях с гарантируемым качеством обслуживания пользователей подразумевает выполнение трех этапов (рисунок 1.2 а)) [3, 4]. В плоскости менеджмента – формирование и корректировка баз данных (БД) о состоянии элементов сети. Конечным результатом функционирования данного этапа является формирование плана распределения информации на сети - расчет таблиц маршрутизации (ТМ) во всех узлах для каждой службы электросвязи. В плоскости управления (стек протоколов сигнализации) - организацию маршрута между узлом – источником (УИ) и узлом – получателем (УП) в виде виртуального коммутируемого либо постоянного соединения (канала или тракта). Конечным результатом функционирования данного этапа является заполнение и обнуление таблиц коммутации (ТК). В плоскости пользователя - непосредственная передача пользовательской информации. При этом передача всех видов информации в сети (служебной – для формирования БД и ТК; пользовательской) осуществляется по своим отдельно выделенным виртуальным соединениям (каналам и трактам). Под нарушением передачи информации будем понимать одну из ситуаций, которые могут быть организованы нарушителем (рисунок 1.3). Прерывание или разъединение (рисунок 1. 3. а)). Информация уничтожается или становится недоступной либо непригодной для использования. В этом случае нарушается доступность информации. Примером таких нарушений может быть воздействие нарушителя на элементы сети (линии связи (ЛС), узлы коммутации (УК), устройства управления, БД и так далее) с целью их уничтожения или приведение в нерабочее состояние. Перехват (рисунок 1. 3. б)). К информации открывается несанкционированный доступ. Нарушается конфиденциальность передаваемой информации. Примером такого типа нарушений является несанкционированное подключение к каналу связи. Модификация (рисунок 1. 3. в)). К информации открывается несанкционированный доступ с целью изменения информации. При этом нарушается конфиденциальность передаваемой информации и ее целостность. Целью такого типа нарушений является изменение информации, передаваемой по сети. Фальсификация (рисунок 1. 3. г)). Нарушитель выдает себя за источник информации. При этом нарушается аутентичность информации. Примером такого типа нарушений является отправка поддельных сообщений по сети. Приведенные выше типы нарушений можно разделить на две группы: активные; пассивные. К первой группе относятся: прерывание - нарушение доступности и конфиденциальности; модификация - нарушение целостности; фальсификация - нарушение аутентичности. Данный тип нарушений имеет активный характер воздействия на элементы сети и передаваемую информацию. Основная цель этих нарушений состоит в изменении либо уничтожении потоков информации на сети. К пассивным нарушениям относится перехват с целью получения передаваемой информации, ее анализа и использования в определенных целях. Достаточно уверенно можно утверждать, что пассивные нарушения ставят своей конечной целью переход в группу активных нарушений. Приведенная выше классификация нарушений защиты информации представлена в таблице 1.1. Перечисленные виды нарушений могут иметь место, как в плоскости пользователя, так и в плоскостях управления и менеджмента (рисунок 1.2 б)). Причем, активные виды нарушений (прерывание, модификация и фальсификация) в плоскости менеджмента ведут к нарушениям либо уничтожению информации, хранимой в базах данных УК. В результате нарушаются таблицы маршрутизации и как результат – невозможность нормального функционирования плоскостей управления (сигнализации) и пользователя. 1.3 Сервисные службы, профиль защиты и соединения защиты информации Сервисные службы защиты информации (рисунок 1.4) являются ответственными за обеспечение основных требований пользователей, предъявляемых к телекоммуникационным системам (с точки зрения ее надежности). Причем данные службы должны функционировать во всех трех плоскостях: менеджмента, управления и пользовательской. Совокупность сервисных служб защиты информации, обеспечивающих требования пользователей, образуют профиль защиты. За установку и прекращение действия той или иной службы отвечают агенты защиты (Security Agent , SA). Согласование служб защиты между агентами происходит через соединения защиты. По этим соединениям производится обмен информацией защиты. Рисунок 1.5 демонстрирует самый простой вариант организации соединения защиты - агенты защиты размещены в пределах конечных систем пользователей. В данном случае конечные системы и агенты защиты взаимодействуют с сетью через интерфейс “пользователь – сеть + защита” (UNI+Sec). Агенты защиты для виртуального соединения (канала либо тракта), который установлен между конечными системами пользователей, последовательно выполняют следующие действия: определяют вид сервисных служб защиты, которые должны быть применены к данному виртуальному соединению; согласовывают службы защиты между собой; применяют требуемые службы защиты к данному виртуальному соединению. Количество соединений защиты должно быть равно количеству установленных служб защиты. То есть, если для данного виртуального соединения одновременно требуется аутентификация, конфиденциальность и достоверность данных, то устанавливается три самостоятельных соединения защиты. Рисунок 1.6 показывает другой вариант организации соединения защиты. В этом случае один агент защиты размещается на конечной системе пользователя, а другой на коммутаторе виртуальных каналов. Соответственно, пользователи и агенты защиты взаимодействуют с сетью связи через интерфейсы “пользователь – сеть” (UNI) либо UNI+Sec; коммутатор виртуальных каналов через интерфейс “узел – сеть + защита” (NNI+Sec). В данном случае агент защиты, размещенный в пределах коммутатора виртуальных каналов, имеет возможность обеспечивать службы защиты не только для пользователя П2, но и для других узлов и сетей, которые подсоединяются к данному коммутатору виртуальных каналов. Часто таких агентов защиты называют брандмауэрами. Фактически брандмауэр – это шлюз, который выполняет функции защиты сети от несанкционированного доступа из вне (например, из другой сети). Различают три типа брандмауэров (рисунок 1.7). Шлюз уровня приложений часто называют прокси – сервером (proxy server) - выполняет функции ретранслятора данных для ограниченного числа приложений пользователя. То есть, если в шлюзе не организована поддержка того или иного приложения, то соответствующий сервис не предоставляется, и данные соответствующего типа не могут пройти через брандмауэр. Фильтрующий маршрутизатор. Точнее это маршрутизатор, в дополнительные функции которого входит фильтрование пакетов (packet-filtering router). Используется на сетях с коммутацией пакетов в режиме дейтаграмм. То есть, в тех технологиях передачи информации на сетях связи, в которых плоскость сигнализации (предварительного установления соединения между УИ и УП) отсутствует (например, IP V 4). В данном случае принятие решения о передаче по сети поступившего пакета данных основывается на значениях его полей заголовка транспортного уровня. Поэтому брандмауэры такого типа обычно реализуются в виде списка правил, применяемых к значениям полей заголовка транспортного уровня. Шлюз уровня коммутации – защита реализуется в плоскости управления (на уровне сигнализации) путем разрешения или запрета тех или иных соединений. Для увеличения надежности защиты виртуальных соединений (каналов и трактов) возможно использование более одной пары агентов защиты и более одного соединения защиты. В данном случае формируется топология соединений защиты, в основе которой заложен принцип вложения и не пересечения соединений защиты вдоль всего маршрута между УИ и УП (или конечными системами пользователей). Пример принципа вложения и не пересечения соединений защиты приведен на рисунке 1.8. В данном случае защита виртуального канала, организованного между конечными системами, осуществляется четырьмя соединениями защиты и восьмью агентами защиты (SA1 – SA8). Причем, каждое соединение не знает о существовании других соединений и не заботится о том, какую службу защиты последние обеспечивают. То есть, соединения защиты абсолютно независимы друг от друга. Данный подход позволяет применять многочисленные стратегии и тактики защиты различных участков сети. Например, соединение защиты между агентами SA1 и SA8 обеспечивает аутентификацию между конечными системами. Независимо от данного соединения соединение между SA2 и SA7 обеспечивает конфиденциальность, а SA2, SA3, SA4 и SA4, SA5, SA6 достоверность данных. Каждое соединение защиты можно представить в виде сегмента , где k – порядковый номер соединения защиты; i, j – порядковые номера агентов защиты. Для рисунка 1.8 соединения защиты можно записать соответствующими сегментами: ; ; ; . В свою очередь второй сегмент оказывается вложенным в первый. То есть, в символьной форме это выглядит следующим образом: . Не пересечение сегментов и можно представить в виде: . Учитывая, что вложены в , то получим: . Окончательная символьная запись топологии соединений защиты, представленная на рисунке 1.8, выглядит следующим образом: . Из рисунка 1.8 и полученного выражения и видно, что данная топология соединений защиты виртуального канала между конечными системами имеет три уровня вложения. Таким образом: принцип вложения и не пересечения соединений защиты; предельное количество уровней вложения ( для технологии ATM до 16 уровней) являются единственными ограничениями организации топологии соединений защиты для одного виртуального соединения (канала либо тракта). В тоже время, для топологии защиты, изображенной на рисунке 1.8, соединение между агентами SA3 и SA5 не возможно, так как нарушается принцип не пересечения. Таким образом, топология соединений защиты реализует профиль защиты пользователя, который является распределенным по сети. Выбор топологии соединений защиты во многом определяется требованиями пользователей к степени защищенности передаваемой информации и ресурсными возможностями самой сети обеспечить данные требования. Контрольные вопросы Приведите характеристики основных нарушений передачи информации через телекоммуникационные системы. Почему нарушения в служебных плоскостях (менеджмента и управления) затрудняют, а порой делают невозможным функционирование пользовательской плоскости? Дайте определения следующих свойств информации: конфиденциальность; доступность; целостность; аутентичность. Какие нарушения относятся к группе активных и какие свойства информации они нарушают? Назовите основное назначение сервисных служб и соединений защиты информации. Какие функции выполняют брандмауэры? Какие функции выполняет прокси – сервер? Какие функции выполняют следующие устройства: фильтрующий маршрутизатор; шлюз уровня коммутации? Какие ограничения накладываются на организацию топологии соединений защиты? Перечислите основные функции протокола обмена сообщениями защиты. 2 Криптографические системы 2.1 Криптосистема с одним ключом На рисунке 2.1 представлена модель криптосистемы (шифрование и дешифрование), которую часто называют традиционной, симметричной или с одним ключом. Пользователь 1 создает открытое сообщение , элементами которого являются символы конечного алфавита. Для шифрования открытого сообщения X генерируется ключ шифрования . С помощью алгоритма шифрования формируется шифрованное сообщение . Формальное представление алгоритма шифрования выглядит следующим образом: . Данная запись означает, что Y формируется путем применения алгоритма шифрования E к открытому сообщению X при использовании ключа шифрования K. Шифрованное сообщение Y передается по каналу либо тракту связи к пользователю 2. Ключ шифрования также передается пользователю 2 по защищенному (секретному) каналу связи для дальнейшего дешифрования принятого сообщения Y. Общий вид математической записи процедуры дешифрования выглядит следующим образом: . Приведенная модель предусматривает, что ключ шифрования генерируется там же, где само сообщение. Однако, возможно и другое решение создания ключа – ключ шифрования создается третьей стороной (центром распределения ключей), которой доверяют оба пользователя. В данном случае за доставку ключа обоим пользователям ответственность несет третья сторона (рисунок 2.2). Вообще говоря, данное решение противоречит самой сущности криптографии – обеспечение секретности передаваемой информации пользователей. Криптосистемы с одним ключом используют принципы подстановки (замены), перестановки (транспозиции) и композиции. При подстановке отдельные символы открытого сообщения заменяются другими символами. Шифрование с применением принципа перестановки подразумевает изменение порядка следования символов в открытом сообщении. С целью повышения надежности шифрования шифрованное сообщение, полученное применением некоторого шифра, может быть еще раз зашифровано с помощью другого шифра. Говорят, что в данном случае применен композиционный подход. Следовательно, симметричные криптосистемы (с одним ключом) можно классифицировать на системы, которые используют шифры подстановки, перестановки и композиции. 2.2 Криптосистемы с открытым ключом Если пользователи при шифровании и дешифровании используют разные ключи KО и KЗ, то есть: , , то криптосистему называют асимметричной, с двумя ключами или с открытым ключом. Алгоритмы криптографии с открытым ключом в отличие от подстановок и перестановок используют математические функции. На рисунке 2.3 представлена модель криптосистемы с открытым ключом, которая обеспечивает конфиденциальность передаваемой информации между пользователями. Получатель сообщения (пользователь 2) генерирует связанную пару ключей: KО – открытый ключ, который публично доступен и, таким образом, оказывается доступным отправителю сообщения (пользователь 1); KС – секретный, личный ключ, который остается известным только получателю сообщения (пользователь 1). Пользователь 1, имея ключ шифрования KО, с помощью алгоритма шифрования формирует шифрованный текст . Пользователь 2, владея секретным ключом Kс, имеет возможность выполнить обратное преобразование . Для обеспечения аутентификации необходимо использовать криптосистему, изображенную на рисунке 2.4. В этом случае пользователь 1 готовит сообщение пользователю 2 и перед отправлением шифрует это сообщение с помощью личного ключа KС. Пользователь 2 может дешифрировать это сообщение, используя открытый ключ KО. Так как, сообщение было зашифровано личным ключом отправителя, то оно может выступать в качестве цифровой подписи. Кроме того, в данном случае невозможно изменить сообщение без доступа к личному ключу пользователя 1, поэтому сообщение решает так же задачи идентификации отправителя и целостности данных. Для обеспечения аутентификации и конфиденциальности с открытым ключом необходимо использовать криптосистему, изображенную на рисунке 2.5. В данном случае пользователь 1 с помощью личного ключа шифрует сообщение. Тем самым обеспечивает цифровую подпись. Затем с использованием открытого ключа пользователя 2 шифрует сообщение, предназначенное для пользователя 2. Так как шифрованное сообщение может дешифрировать только пользователь 2 личным ключом , то это обеспечивает конфиденциальность передаваемой информации. Таким образом, криптосистемы с открытым ключом характеризуются тем, что при шифровании и дешифровании используют два ключа, один из которых остается в личном пользовании (секретный), а второй открыт для всех пользователей. Из вышеизложенного следует, что криптосистемы с открытым ключом должны удовлетворять следующим условиям: для пользователя процесс генерирования открытого и личного ключей не должен вызывать вычислительных трудностей; для пользователя, отправляющего сообщение, процесс шифрования с помощью открытого ключа не должен вызывать вычислительных трудностей; процесс дешифрования, полученного шифрованного сообщения, с помощью личного ключа не должен вызывать вычислительных трудностей; для противника должны быть значительные вычислительные трудности восстановления личного ключа из имеющего открытого ключа; для противника должны быть значительные вычислительные трудности восстановления оригинального сообщения из имеющегося открытого ключа и шифрованного сообщения. Таким образом, практическая реализация перечисленных условий сводятся к нахождению односторонней функции со следующими свойствами: - вычисляется легко, если известны KО и X; - вычисляется легко, если известны KС и Y; - практически не поддается вычислению, если Y известно, а KС – нет. С подробным описанием различных систем криптографии можно познакомиться в [7]. 2.3 Распределение открытых ключей На сегодняшний день известны следующие методы распределения открытых ключей [7]: индивидуальное публичное объявление открытых ключей пользователями; использование публично доступного каталога открытых ключей; участие авторитетного источника открытых ключей; сертификаты открытых ключей. Рассмотрим каждый из перечисленных методов. При индивидуальном публичном объявлении открытых ключей любая сторона, участвующая в обмене сообщениями (X), может предоставить свой открытый ключ (KО) любой другой стороне. Недостатком данного подхода является невозможность обеспечить аутентификацию отправителя открытого ключа (KО). То есть, при данном подходе у нарушителя появляется возможность фальсификации пользователей (рисунок 1. 3 г)). Использование публично доступного каталога открытых ключей позволяет добиться более высокой степени защиты информации и пользователей сети. В данном случае за ведение и распространение публичного каталога должна отвечать надежная организация (уполномоченный объект) (рисунок 2.6). При этом должны соблюдаться следующие правила. Пользователи должны регистрировать свои открытые ключи в публичном каталоге, который ведет уполномоченный объект. Регистрация должна проходить либо по заранее защищенным каналам связи, либо при личной (физической) явке пользователей на уполномоченный объект. Уполномоченный объект должен периодически публиковать каталог открытых ключей. Например, в виде печатной продукции (книга, газета и тому подобное) либо в электронной версии (размещение на собственном сервере). Недостатком данного подхода является следующее. Если нарушителю удастся изменить записи, хранящиеся в каталоге открытых ключей, то он сможет авторитетно выдавать фальсифицированные открытые ключи и, следовательно, выступать от имени любого из участников обмена данными и читать сообщения, предназначенные любому пользователю. Участие авторитетного источника открытых ключей представлено на рисунке 2.7. Обязательным условием данного варианта распределения открытых ключей пользователей является условие, что авторитетный источник открытых ключей имеет свой секретный ключ, и каждый пользователь знает его открытый ключ. При этом выполняется следующий порядок действий (номера, проставленные у стрелочек, совпадают с последовательностью действий участников обмена сообщениями): Пользователь 1 посылает запрос авторитетному источнику открытых ключей о текущем значении открытого ключа пользователя 2. При этом указывается дата и время запроса (д. вр.). Авторитетный источник, используя свой секретный ключ , шифрует и передает сообщение пользователю 1 , в котором содержится следующая информация: - открытый ключ пользователя 2; д. вр. - дата и время отправки сообщения. Пользователь 1, используя , шифрует и передает пользователю 2 шифрованное сообщение , содержащее: ID1 – идентификатор отправителя (пользователь 1); N1 - уникальную метку данного сообщения. 4, 5. Пользователь 2, получив шифрованное сообщение , дешифрирует его с помощью своего секретного ключа и в соответствии с идентификатором ID1, аналогично с пунктами 1 и 2 выше перечисленных действий получает от авторитетного источника открытый ключ пользователя 1 . Пользователь 2, используя , посылает пользователю 1 шифрованное сообщение , где N2 - уникальная метка данного сообщения. Пользователь 1 шифрует с помощью открытого ключа сообщение Y, предназначенное пользователю 1 и передает . Приведенный вариант распределения открытых ключей имеет некоторые недостатки: каждый раз, когда пользователь намерен передать информацию новому адресату, то он должен обращаться к авторитетному источнику с целью получения открытого ключа; каталог имен и открытых ключей, поддерживаемый авторитетным источником, является привлекательным местом для нарушителя передачи информации пользователей. На рисунке 2.8 представлен сценарий распределения открытых ключей с применением сертификатов открытых ключей. Обязательным условием данного варианта распределения открытых ключей пользователей является условие, что авторитетный источник сертификатов имеет свой секретный ключ , и каждый пользователь знает его открытый ключ . При этом выполняется следующий порядок действий (номера, проставленные у стрелочек, совпадают с последовательностью действий участников обмена сообщениями): Пользователь 1 генерирует пару ключей (соответственно, открытый и секретный) и по защищенному каналу связи обращается к авторитетному источнику сертификатов с целью получения сертификата. Авторитетный источник шифрует с помощью своего секретного ключа сертификат и выдает его пользователю 1. Сертификат содержит: - открытый ключ пользователя 1 (данный ключ пользователь 1 сам сгенерировал и передал авторитетному источнику для сертификации); IDП1 - идентификатор пользователя 1; TП1 - срок действия сертификата пользователя. Пользователь 1 пересылает свой сертификат , полученный от авторитетного источника, пользователю 2. Последний, зная открытый ключ авторитетного источника сертификатов , имеет возможность прочитать и удостовериться, что полученное сообщение является сертификатом . 4, 5, 6. Пользователь 2 выполняет аналогичные действия, которые были выполнены пользователем 1 в пунктах 1, 2 и 3. То есть получает от авторитетного источника сертификат . Пересылает его пользователю 1. Последний, зная открытый ключ авторитетного источника сертификатов , имеет возможность прочитать и удостовериться, что полученное сообщение является сертификатом . В результате перечисленных действий пользователи обменялись открытыми ключами и готовы к передаче и приему пользовательских сообщений. 2.4 Применение криптосистемы с открытым ключом для распределения секретных ключей На сегодняшний день существует несколько подходов применения криптосистемы с открытым ключом для распределения секретных ключей [7]. Рассмотрим некоторые из них. Простое распределение секретных ключей состоит в выполнении следующих действий: Пользователь 1 генерирует пару ключей , соответственно, открытый и секретный. Пользователь 1 передает пользователю 2 сообщение , где – идентификатор пользователя 1. Пользователь 2, получив сообщение от пользователя 1, так же генерирует свою пару ключей . Пользователь 2, используя открытый ключ пользователя 1, шифрует и передает сообщение пользователю 1. Пользователь 1 уничтожает свой секретный ключ , а пользователь 2 уничтожает открытый ключ пользователя 1 . Таким образом, оба пользователя имеют сеансовый (секретный) ключ и могут использовать его для передачи информации, защищенной традиционным шифрованием. По окончании сеанса передачи информации ключ уничтожается. Однако данный подход уязвим для активных нарушений. Действительно, если нарушитель имеет возможность внедрения в соединение между пользователями, то, выполняя следующие действия (рисунок 2.9), он будет иметь возможность знать секретный (сеансовый) ключ. Пользователь 1 генерирует пару ключей и передает пользователю 2 сообщение . Нарушитель перехватывает сообщение , создает собственную пару ключей и передает пользователю 2 сообщение . Пользователь 2, получив сообщение , генерирует свою пару ключей , шифрует (используя открытый ключ нарушителя ) и передает сообщение пользователю 1. Нарушитель перехватывает сообщение , дешифрирует его , определяет сеансовый ключ и передает пользователю 2 сообщение . В результате оба пользователя имеют сеансовый ключ , однако не будут подозревать, что он тоже известен и нарушителю. Сценарий распределения секретных ключей с обеспечением конфиденциальности и аутентичности изображен на рисунке 2.10 и состоит в выполнении следующих действий. Пользователи генерируют пары ключей, соответственно , , и обмениваются между собой открытыми ключами и . Пользователь 1, используя , передает пользователю 2 сообщение , содержащее: свой идентификатор - IDП1; - уникальная метка данного сообщения. Пользователь 2, используя , передает пользователю 1 сообщение , содержащее и - уникальные метки данного сообщения. Наличие метки убеждает пользователя 1 в том, что только пользователь 2 мог дешифрировать сообщение . Пользователь 1, используя , передает пользователю 2 сообщение , содержащее уникальную метку . Данное сообщение выполняет функцию подтверждения для пользователя 2, что его респондентом является пользователь 1. Пользователь 1 генерирует секретный (сеансовый) ключ , который дважды шифруется с использованием: своего секретного ключа и открытого ключа пользователя 2 . После выполнения процедуры шифрования сообщение передается пользователю 2. Последний, имея открытый ключ пользователя 1 и свой секретный ключ, дешифрирует полученное сообщение. В результате перечисленных действия оба пользователя имеют секретный (сеансовый) ключ . 2.5 Применение криптосистемы с открытым ключом для аутентификации пользователя со стороны автономного объекта На рисунке 2.11 представлена структура телекоммуникационной системы, состоящая из удаленного объекта и пользователя. Удаленный объект в автономном режиме выполняет некоторые функции, например, осуществляет сбор информации J. Через неопределенное время пользователь по каналу связи передает автономному объекту некоторое сообщение, например команду K – “Выйти на связь и передать собранную информацию J”. Приведенную систему часто называют системой дистанционного управления объектом. В подобных системах возникает задача аутентификации пользователя со стороны автономного объекта. Действительно, если не принять соответствующих мер по организации защищенного канала доступа к автономному объекту, то нарушитель, используя перехват сообщения K, может несанкционированно управлять автономным объектом. На рисунке 2.12 приведен сценарий, реализующий надежную аутентификацию пользователя со стороны автономного объекта, который содержит два этапа и состоит в выполнении следующих процедур. 1 Этап – предварительная настройка параметров объекта и пользователя. Данный этап выполняется один раз перед началом автономного функционирования объекта. Пользователь генерирует и размещает в оперативной памяти автономного объекта идентификатор ID и временной параметр . 2 Этап: - сеанс связи пользователя с объектом: Пользователь по открытому каналу связи посылает автономному объекту сигнал S, который приводит автономный объект в активное состояние – выйти на связь с пользователем. Автономный объект генерирует сеансовую, связанную пару ключей , включает таймер, фиксирует время начала сеанса и передает пользователю свой открытый ключ . Значения открытого и секретного ключей имеют случайный характер. Пользователь генерирует свою сеансовую, связанную пару ключей , значения которых тоже имеют случайный характер. Используя открытый ключ объекта, передает ему сообщение , содержащее общий идентификатор ID и свой открытый ключ . Автономный объект, используя свой секретный ключ , дешифрирует принятое сообщение от пользователя . По таймеру фиксирует время принятия сообщения . Рассчитывает и принимает решение: если , то конец связи с пользователем. В противном случае проверяет: идентификатор ID, полученный в сообщении от пользователя, совпадает с собственным идентификатором? Если нет, то конец связи. Иначе – используя открытый ключ пользователя , передает ему сообщение , содержащее запрос X на выполнение команды K, и фиксирует время . Пользователь: используя свой секретный ключ , дешифрирует принятое сообщение ; используя открытый ключ объекта , передает удаленному объекту сообщение , содержащее команду управления K и новый идентификатор, который будет использован в будущем сеансе связи (значение нового ID имеет случайный характер); фиксирует в своей оперативной памяти значение нового идентификатора; уничтожает свою сеансовую пару ключей и открытый сеансовый ключ объекта . Объект дешифрирует принятое сообщение. Рассчитывает и принимает решение: если , то конец связи с пользователем. В противном случае размещает в оперативной памяти новый идентификатор ID, уничтожает свою пару ключей и выполняет команду K. Таким образом, каждый сеанс связи пользователя с удаленным объектом характеризуется использованием “своих” сеансовых ключей и “своего” сеансового идентификатора. Значения данных параметров имеет случайный характер, что гарантирует надежную аутентификацию пользователя со стороны удаленного объекта. Контрольные вопросы Изобразите модель криптосистемы с одним ключом и поясните принцип ее работы. Изобразите модель криптосистемы с одним ключом и участием центра распределения ключей и поясните принцип ее работы. Изобразите модель криптосистемы с открытым ключом, обеспечивающей конфиденциальность передаваемой информации. Поясните принцип работы данной модели. Изобразите модель криптосистемы с открытым ключом, обеспечивающей аутентификацию передаваемой информации. Поясните принцип работы данной модели. Изобразите модель криптосистемы с открытым ключом, обеспечивающей конфиденциальность и аутентификацию передаваемой информации. Поясните принцип работы данной модели. Перечислите основные требования, которым должны удовлетворять криптосистемы с открытым ключом. Поясните, в чем состоит суть индивидуального публичного объявления открытых ключей пользователями? Изобразите сценарий распределения открытых ключей с использованием публично доступного каталога открытых ключей. Изобразите сценарий распределения открытых ключей с участием авторитетного источника открытых ключей. Поясните, в чем состоит суть сертификации открытых ключей. В чем суть простого распределения секретных ключей? Поясните сценарий распределения секретных ключей с обеспечением конфиденциальности и аутентичности. Изобразите сценарий применения криптосистемы с открытым ключом для аутентификации пользователя со стороны автономного объекта Поясните, почему применение криптосистемы с открытым ключом гарантирует надежную аутентификацию пользователя со стороны автономного объекта, 3 Общие критерии оценки безопасности информационных технологий 3.1 Основные определения Введем основные определения [5 - 8], которые нам потребуются для дальнейшего изложения материала по ОК. Политика безопасности организации – совокупность правил, процедур в области безопасности, которыми руководствуется организация в своей деятельности. Система ИТ – специфическое воплощение ИТ с конкретным назначением и условиями эксплуатации. Объект оценки (Target of Evaluation) – подлежащая оценке система ИТ. Политика безопасности объекта оценки (Target of Evaluation Security Policy) – совокупность правил, обеспечивающих защиту информации в пределах системы ИТ. Задание по безопасности (Security Target) – совокупность требований безопасности и спецификаций, которая является основой для оценки конкретной системы ИТ. Профиль защиты (Protection Profile) – реализованная совокупность требований безопасности и спецификаций, отвечающая специфическим запросам пользователя системы ИТ. Функция безопасности (Security Function) – функциональные возможности части или частей системы ИТ, обеспечивающие выполнение подмножества взаимосвязанных правил политики безопасности организации. Стойкость функции безопасности (Strength of Function)– характеристика функции безопасности, характеризующая возможности системы ИТ выполнять ее основные функции при прямой атаке нарушителя на профиль защиты. 3.2 История создания "Общих критериев" "Общие критерии" (Common Criteria) представляют собой результат последовательных усилий по разработке критериев оценки безопасности информационных технологий (ИТ) различных стран (рисунок 3.1). В начале 80-х годов в США были разработаны "Критерии оценки доверенных компьютерных систем" (Trusted Computer System Evaluation Criteria, TCSEC). В следующем десятилетии и другие страны мира проявили инициативу по разработке критериев оценки, которые строились на вышеупомянутой концепции, но были более гибки и адаптируемы к природе эволюции ИТ в целом. В свою очередь, в 1991 г. Европейская Комиссия опубликовала свои "Критерии оценки безопасности информационных технологий" (Information Technology Security Evaluation Criteria, ITSEC) версии 1.2, которые были разработаны совместно Францией, Германией, Нидерландами и Великобританией. В начале 1993 г., в Канаде на основе сочетания первых двух подходов TCSEC и ITSEC были созданы "Канадские критерии оценки доверенных компьютерных продуктов" (Canadian Trusted Computer Product Evaluation Criteria, CTCPEC) версии 3.0. В это же время, в США был издан проект стандарта "Федеральные критерии безопасности информационных технологий" (Federal Criteria for Information Technology Security, FC) версии 1.0, который использовал другой подход к объединению североамериканской и европейской концепций критериев оценки. Однако существовала необходимость признания результатов стандартизированной оценки безопасности каждой из стран на мировом рынке ИТ. Поэтому в 1990 г. международной организацией по стандартизации (International Organization for Standardization, ISO) была начата разработка международного стандарта критериев оценки для всемирного использования. Рисунок 3.1 – История создания "Общих критериев" Эта задача была поставлена перед рабочей группой 3 (Working Group 3, WG3) подкомитета 27 (Subcommittee 27, SC27) совместимого технического комитета 1 (Joint Technical Committee 1, JTC1). Однако работа WG3 шла медленно из-за большого объема и необходимости интенсивных многосторонних переговоров с каждой из сторон. Поэтому в июне 1993 г. организации-спонсоры TCSEC, ITSEC, CTCPEC и FC объединили свои усилия и начали действовать совместно, чтобы согласовать различающиеся между собой критерии и создать единую совокупность критериев безопасности ИТ, которые могли бы использоваться в международном масштабе. Эта деятельность получила название "Проект "Общие критерии". Его целью являлось устранение концептуальных и технических различий между исходными критериями и представление в ISO полученных результатов для содействия разработке международного стандарта. Представители организаций-спонсоров сформировали редакционный совет "Общих критериев" (Common Criteria Editorial Board, ССЕВ) для разработки "Общих Критериев" (ОК). Затем было установлено взаимодействие между ССЕВ и WG3. Начиная с 1994 г. ССЕВ представил в WG3 несколько ранних версий ОК, которые потом оформлялись как последовательные рабочие проекты различных частей критериев ISO. Версия 1.0 ОК была завершена ССЕВ в январе 1996 г. и одобрена ISO в апреле 1996 г. для распространения в качестве проекта комитета. Был поведен ряд экспериментальных оценок на основе версии 1.0 ОК, а также организовано широкое публичное обсуждение документа. В результате чего, в рамках проекта ОК была предпринята значительная переработка на основе полученных замечаний, которая уже выполнялась преемником ССЕВ, который в настоящее время называется советом по реализации ОК (Common Criteria Implementation Board, CCIB). CCIB завершил бета-версию 2.0 ОК в октябре 1997 г., и представил ее в WG3, которая одобрила ее как второй проект комитета. Последующие промежуточные версии проекта представлялись неофициально экспертам WG3 по мере их подготовки в CCIB. CCIB учел ряд замечаний, которые были получены как непосредственно от экспертов WG3, так и от национальных органов ISO при обсуждении промежуточных версий проекта. Кульминацией этого процесса явилась публикации версии 2.0 ОК. По историческим причинам и с целью обеспечения преемственности ISO/IEC/JTCI/SC27/WG3 приняла для дальнейшего использования термин "Общие критерии" (ОК) внутри документа, признавая, что его официальным названием, принятым в ISO, является "Критерии оценки безопасности информационных технологий" (Information technology — Security techniques — Evaluation Criteria for IT Security.). 3.3 Структура ГОСТ Р ИСО/МЭК 15408 Российский аналог международного стандарта ОК был разработан центром безопасности информации, 4 ЦНИИ министерства обороны РФ, центром "Атомзащитаинформ", ЦНИИАТОМИНФОРМ, ВНИИстандрт, при участии экспертов международной рабочей группы по ОК. И принят постановлением Госстандарта России от 4 апреля 2002 г. как ГОСТ Р ИСО/МЭК 15408 с полным названием − "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий". Этот стандарт определяет критерии, за которыми исторически закрепилось название "Общие критерии" (ОК), и состоит из трех отдельных, но взаимосвязанных частей, представленных ниже на рисунке 3.2. Рисунок 3.2 – Структура ГОСТ Р ИСО/МЭК 15408 В таблице 3.1 показано, в каком качестве различные части ОК представляют интерес для каждой из трех основных групп пользователей ОК. ГОСТ Р ИСО/МЭК 15408 предназначен для использования в качестве основы при оценке характеристик безопасности продуктов и систем ИТ, делает результаты оценки безопасности ИТ значимыми для более широкой аудитории, путем установления общей базы критериев. ОК дают возможность сравнения результатов независимых оценок безопасности, которая достигается предоставлением общего набора требований к функциям безопасности продуктов и систем ИТ и к мерам доверия, применяемых к ним при оценке безопасности. В процессе оценки достигается определенный уровень уверенности в том, что функции безопасности таких продуктов или систем, а также предпринимаемые меры доверия отвечают предъявляемым требованиям. Результаты оценки помогут потребителям решить, являются ли продукты или системы ИТ достаточно безопасными для их предполагаемого применения и приемлемы ли прогнозируемые риски при их использовании. ОК полезны в качестве руководства как при разработке продуктов или систем с функциями безопасности ИТ, так и при приобретении коммерческих продуктов и систем с такими функциями. При оценке такой продукт или систему ИТ называют объектом оценки (ОО). К таким ОО, например, относятся операционные системы, вычислительные сети, распределенные системы и приложения. ОК направлены на защиту информации от несанкционированного раскрытия, модификации или потери возможности ее использования. Категории защиты, относящиеся к этим трем типам нарушения безопасности, обычно называют конфиденциальностью, целостностью и доступностью соответственно. ОК могут быть также применимы к тем аспектам безопасности ИТ, которые выходят за пределы этих трех понятий. Стандарт сосредоточен на угрозах информации, возникающих в результате действий человека, злоумышленных, так и иных, но возможно также применение ОК и для некоторых угроз, не связанных с человеческим фактором. Некоторые вопросы рассматриваются как лежащие вне области действий ОК, поскольку они требуют привлечения специальных методов или являются смежными по отношению к безопасности ИТ. ОК, в частности, не содержат: критерии оценки безопасности, касающиеся административных мер безопасности, непосредственно не относящихся к мерам безопасности ИТ; оценку специальных физических аспектов безопасности ИТ, таких как контроль электромагнитного излучения, прямо не затрагивается, хотя многие концепции ОК применимы и в этой области; ни методологии оценки, ни административно-правовую структуру, в рамках которой критерии могут применяться органами оценки; процедуры использования результатов оценки при аттестации продуктов и систем ИТ; критерии для оценки специфических качеств криптографических алгоритмов. 3.4 Сфера действия и применения ОК Информация, содержащаяся в системах или продуктах ИТ, является критическим ресурсом, позволяющим организациям успешно решать свои задачи. Кроме того, частные лица вправе ожидать, что их персональная информация, будучи размещенной, в продуктах или системах ИТ, останется приватной, доступной им по мере необходимости и не сможет быть подвергнута несанкционированной модификации. При выполнении продуктами или системами ИТ их функций следует осуществлять надлежащий контроль информации, что обеспечило бы ее защиту от опасностей типа нежелательного или неоправданного распространения, изменения или потери. Термин "безопасность ИТ" охватывает предотвращение и уменьшение этих и подобных опасностей. Многие потребители ИТ из-за недостатка знаний, компетентности или ресурсов не будут уверены в безопасности применяемых продуктов и систем ИТ и, возможно, не захотят полагаться исключительно на решения разработчиков. Чтобы повысить свою уверенность в мерах безопасности продукта или системы ИТ, потребители могут заказать проведение анализа безопасности этого продукта или системы (то есть оценку безопасности). ОК могут использоваться для выбора приемлемых мер безопасности ИТ. В них содержатся критерии оценки требований безопасности. В оценке характеристик безопасности и систем ИТ заинтересованы в основном потребители, разработчики и оценщики. Представленные критерии структурированы в интересах этих групп, потому что именно они рассматриваются как основные пользователи ОК. 3.5 Конструкции, используемые при описании требований безопасности ОК устанавливают базовую структуру конструкций, которая относятся к безопасности ИТ, для проведения оценок. Путем представления требований к свидетельствам и анализу, могут быть получены более объективные и, следовательно, более значимые результаты оценки. Представление этих общих конструкций дает возможность воспользоваться накопленным опытом и специальными знаниями. ОК определяют совокупность конструкций, объединяемых в содержательные наборы требований безопасности, которые затем могут быть использованы при установлении требований безопасности к перспективным продуктам и системам. Взаимосвязь различных конструкций для выражения требований представлена на рисунке 3.3. Рисунок 3.3 – Организация и структура требований Организация требований безопасности в ОК, представленная в виде иерархии класс – семейство – компонент, призвана помочь потребителям в поиске конкретных требований безопасности. Функциональные требования и требования доверия представлены в ОК в едином стиле с использованием одной и той же структуры и терминологии. Термин "класс" применяется для наиболее общего группирования требований безопасности. Все составляющие класса имеют общую направленность, но различаются по охвату целей безопасности. Составляющие класса называются семействами. Семейство – это группа наборов требований безопасности, имеющих общие цели безопасности, но различающихся аспектами и строгостью. Составляющие семейства называются компонентами. Компонент описывает специфический набор требований безопасности, который является наименьшим выбираемым набором требований безопасности для включения в структуры, определенные в ОК. Совокупность компонентов, входящих в семейство, может быть упорядочена для представления возрастания строгости или возможностей требований безопасности, имеющих общее назначение. Они могут быть также упорядочены частично для представления связанных неиерархических наборов. Упорядочение не применимо в том случае, когда в семействе имеется только один компонент. Компоненты составлены из отдельных элементов. Элемент – это выражение требований безопасности на самом нижнем уровне. Он является неделимым требованием безопасности, которое может быть специфицировано при оценке. В ОК определены три типа конструкций требований: пакет, профиль зашиты (ПЗ) и задание по безопасности (ЗБ), представленные на рисунке 3.4. Помимо этого, в ОК определена совокупность критериев безопасности ИТ, которые могут отвечать потребностям разных пользователей и поэтому служат основным исходным материалом для создания этих конструкций. Центральной идеей ОК является концепция максимально широкого использования компонентов. Рисунок 3.4 – Использование требований безопасности Промежуточная комбинация компонентов называется пакетом. Пакет позволяет выразить совокупность функциональных требований или требований доверия, которые отвечают идентифицируемому подмножеству целей безопасности. Пакет предназначен для многократного использования и определяет требования, которые известны как полезные и эффективные для достижения установленных целей. Допускается его применение при создании более крупных пакетов, профилей защиты и заданий по безопасности (рисунки 3.3, 3.4). Оценочные уровни доверия (ОУД) – это предопределенные пакеты требований доверия, содержащиеся в части 3 ГОСТ Р ИСО/МЭК 15408. ОУД является базовым набором требований доверия для оценки. Каждый такой уровень определяет непротиворечивый набор требований доверия. Совместно ОУД формируют упорядоченное множество, которое является предопределенным в ОК шкалой доверия. Профиль защиты (ПЗ) содержит совокупность требований безопасности, взятых из ОК или сформулированных в явном виде, в которую следует включить ОУД (возможно усиленный дополнительными компонентами доверия). ПЗ позволяет выразить независимые от конкретной реализации требования безопасности для некоторой совокупности объектов оценки, полностью согласованные с набором целей безопасности. ПЗ, также как и пакет, предназначен для многократного использования и определения, как функциональных требований, так и требований доверия к ОО, которые полезны и эффективны для достижения установленных целей, также он содержит логическое обоснование требований и целей безопасности. ПЗ может разрабатываться группами пользователей, разработчиками продуктов ИТ или другими сторонами, заинтересованными в определении такой общей совокупности потребностей в безопасности, также профиль облегчает будущую оценку в соответствии с этими потребностями. Задание по безопасности (ЗБ) содержит совокупность требования безопасности, которые могут быть определены: ссылками на ПЗ; ссылками непосредственно на функциональные компоненты; ссылками на компоненты доверия из ОК; в явном виде. ЗБ позволяет выразить для конкретного объекта оценки требования безопасности, которые по результатам оценки ЗБ признаны полезными и эффективными для достижения установленных целей безопасности. ЗБ содержит краткую спецификацию объекта оценки совместно с требованиями и целями безопасности и логическим обоснованием для каждого из них. ЗБ является основой для соглашения между всеми сторонами относительно того, какую безопасность предлагает объект оценки. 3.6 Источники требований безопасности Требования безопасности ОО могут быть скомпонованы с использованием источников, представленных на рисунке 3.5: Рисунок 3.5 – Источники требований безопасности 3.7 Содержание профиля защиты Профиль защиты определяет независимую от конкретной реализации совокупность требований ИТ для некоторой категории объекта оценки, который предназначен для удовлетворения общих запросов пользователей в безопасности. Требования потребители могут выразить, используя существующий или формируя новый профиль, без ссылки на какой-либо конкретный объект. ПЗ следует представлять как ориентированный на пользователя документ с минимумом ссылок на другие материалы, которые ему могут быть недоступны. Логическое обоснование, при необходимости, может быть оформлено отдельно. Содержание представлено на рисунке 3.6, который следует использовать при создании структурной схемы ПЗ. Введение ПЗ должно содержать информацию об управлении документооборотом и обзорную информацию, необходимые для работы с реестром ПЗ: 1. идентификация ПЗ должна обеспечить маркировку и описательную информацию, необходимые, чтобы идентифицировать, каталогизировать, регистрировать ПЗ и ссылаться на него; 2. аннотация ПЗ должна дать общую характеристику ПЗ в описательной форме. Она должна быть достаточно подробной, чтобы потенциальный пользователь мог решить, представляет ли ПЗ для него интерес. Аннотация должна быть также применима для размещения в виде самостоятельного реферата в каталогах реестра ПЗ. Рисунок 3.6 – Содержание профиля защиты Следующая часть ПЗ должна содержать описание ОО, служащее для лучшего понимания его требований безопасности и дающее представление о типе продукта и основных характерных особенностях ИТ применительно к объекту оценки. Описание ОО предоставляет контекст для оценки. Информация, содержащаяся в описании, будет использована в процессе оценки для выявления противоречий. Поскольку ПЗ обычно не ссылается на конкретную реализацию, то характерные особенности объекта могут быть представлены в виде предположений. Если ОО является продуктом или системой, основной функцией которых является безопасность, то эта часть ПЗ может быть использована для описания более широкого контекста возможного применения ОО. Изложение среды безопасности ОО должно содержать описание аспектов безопасности среды, в которой предполагается использовать ОО, и ожидаемый способ его применения, которое включает в себя следующее. 1. Описание предположений, содержащее аспекты безопасности среды, в которой ОО будет использоваться или предполагается к использованию. То есть раздел содержит: - информацию относительно предполагаемого использования ОО, включая такие аспекты, как предполагаемая область применения, потенциальная значимость активов и возможные ограничения использования; - информацию относительно среды применения ОО, включая аспекты физического окружения, персонала и внешних связей. 2. Описание угроз, содержащее все те угрозы активам, против которых требуется защита средствами ОО или его среды. Заметим, что необходимо приводить не все угрозы, которые могут встретиться в среде, а только те из них, которые влияют на безопасную эксплуатацию ОО. Угроза должна быть описана с использованием понятий идентифицированного нарушителя, нападения и актива, который подвергается нападению. Нарушителя следует описать через такие аспекты, как компетентность, доступные ресурсы и мотивация. Нападение следует описать через такие аспекты, как возможность, метод нападения и используемые уязвимости. Если цели безопасности ОО следуют только из политики безопасности организации и предположений, то описание угроз может быть опущено. 3. Описание политики безопасности организации, идентифицирующее и, при необходимости, объясняющее все положения политики безопасности организации или правила, которым должен подчиняться объект оценки. Если цели безопасности следуют только из угроз и предположений безопасности, описание политики безопасности организации может быть опущено. Изложение целей безопасности должно определять цели безопасности как для ОО, так и для его среды. Цели безопасности должны учитывать все установленные аспекты среды безопасности, должны отражать изложенное намерение противостоять всем установленным угрозам и быть подходящими для этого, а также охватывать все предположения безопасности и установленную политику безопасности организации. Должны быть идентифицированы категории целей безопасности, приведенные ниже. Если при этом противостояние угрозе или проведение политики безопасности частично возлагается на ОО, а частично на его среду, соответствующая цель безопасности должна повторяться в каждой категории. 1. Цели безопасности для ОО должны быть четко изложены и сопоставлены с аспектами установленных угроз, которым необходимо противостоять средствами ОО, и/или с политикой безопасности организации, которой должен отвечать ОО. 2. Цели безопасности для среды ОО должны быть четко изложены и сопоставлены с аспектами установленных угроз, которым не полностью противостоит ОО, и/или с политикой безопасности организации и предположениями, не полностью удовлетворяемыми ОО. Необходимо отметить, что цели безопасности для среды могут повторять, частично или полностью, некоторые предположения, сделанные при изложении среды безопасности ОО. В следующей части ПЗ подробно определяются требования безопасности ИТ, которые должны удовлетворяться ОО или его средой. Требования безопасности ОО должны быть изложены следующим образом. 1. При изложении требований безопасности ОО должны быть определены функциональные требования и требования доверия, которым должны удовлетворять ОО и свидетельства поддержки его оценки для достижения целей безопасности ОО. 2. Необязательное изложение требований безопасности для среды ИТ должно определять требования безопасности ИТ, которым должна отвечать среда ИТ этого ОО. Если безопасность ОО не зависит от среды ИТ, то эта часть ЗБ может быть опущена. Замечания по применению ПЗ не является обязательной и может содержать дополнительную информацию, которая считается уместной или полезной для создания, оценки и использования ОО. Обоснование ПЗ представляется свидетельство, используемое при оценке ПЗ. Это свидетельство поддерживает утверждения, что ПЗ является полной и взаимосвязанной совокупностью требований и что соответствующий ему ОО обеспечит эффективный набор контрмер безопасности ИТ в определенной среде безопасности. Обоснование должно включать в себя следующее. 1. Логическое обоснование целей безопасности, демонстрирующее, что изложенные цели безопасности сопоставлены со всеми идентифицированными аспектами среды безопасности ОО и пригодны для их охвата. 2. Логическое обоснование требований безопасности, демонстрирующее, что совокупность требований безопасности (ОО и его среды) пригодна для достижения целей безопасности и сопоставима с ними. 3.8 Содержание задания по безопасности Задание по безопасности содержит требования ИТ для конкретного объекта оценки и специфицирует функции безопасности и меры доверия, предлагаемые объектом оценки для удовлетворения установленных требований. ЗБ для ОО является основой для соглашения между разработчиками, оценщиками и, где необходимо, потребителями по характеристикам безопасности объекта оценки и области применения оценки. Круг лиц, заинтересованных в задании по безопасности, не ограничивается только ответственными за разработку ОО и его оценку, но может включать также ответственных за управление, маркетинг, продажу, инсталляцию, конфигурирование и использование ОО. В ЗБ разрешено включать требования из одного или нескольких ПЗ или утверждать о соответствии ему. ЗБ следует представлять в виде ориентированного на пользователя документа с минимум ссылок на другие материалы. Логическое обоснование, при необходимости, может быть оформлено отдельно. Содержание ЗБ представлено на рисунке 3.7, который рекомендуется использовать при создании структурной схемы ЗБ. Введение ЗБ должно содержать информацию для управления документооборотом и обзорную информацию: 1. Идентификация ЗБ должна обеспечить его маркировку и описательную информацию, необходимые, чтобы контролировать и идентифицировать ЗБ и ОО, к которому оно относится; Рисунок 3.7 – Содержание задания по безопасности 2. Аннотация ЗБ должна дать общую характеристику ЗБ в описательной форме. Она должна быть достаточно подробной, чтобы потенциальный потребитель ОО мог решить, представляет ли ОО для него интерес. Аннотация должна быть применима для размещения в виде самостоятельного реферата в перечнях оцененных продуктов; 3. Утверждение о соответствии ОК должно изложить каждое поддающееся оценке утверждение о соответствии ОО общим критериям. Следующая часть ЗБ должна содержать описание ОО, служащее для лучшего понимания его требований безопасности и дающее представление о типе продукта или системы. Область и ограничения применения ОО должны быть описаны в общих терминах как в отношении физической (аппаратные и/или программные компоненты/модули), так и логической его организации (характерные возможности ИТ и безопасности, предлагаемые объектом оценки). Описание ОО представляет контекст для оценки. Информация, содержащаяся в данном разделе, будет использована в процессе оценки для выявления противоречий. Если объект оценки представляет собой продукт или систему, основной функцией которых является безопасность, то эту часть ЗБ разрешается использовать для более подробного описания контекста возможного применения ОО. Изложение среды безопасности ОО должно содержать описание аспектов безопасности среды, в которой предполагается использовать ОО, и ожидаемый способ его применения. Это изложение должно включать в себя следующее: 1. Описание предположений, содержащее аспекты безопасности среды, в которой ОО будет использоваться или предполагается к использованию. Оно должно также содержать: − информацию относительно предполагаемого использования ОО, включая такие аспекты, как предполагаемая область применения, потенциальная значимость, потенциальная значимость активов и возможные ограничения на использование; − информацию относительно среды применения ОО, включая аспекты физического окружения, персонала и внешних связей. − описание угроз, содержащее все те угрозы активам, против которых требуется защита средствами ОО или его среды. Заметим, что необходимо приводить не все угрозы, которые могут встретиться в среде, а только те из них, которые влияют на безопасную эксплуатацию. Угроза должна быть описана с использованием понятий идентифицированного нарушителя, нападения и актива, который подвергается нападению. Нарушителя следует описать через такие аспекты, как компетентность, доступные ресурсы и мотивация. Нападение следует описать через такие аспекты, как возможность, метод нападения и используемые уязвимости. Если цели безопасности ОО следуют только из политики безопасности организации и предположений, то описание угроз может быть опущено. 3. Описание политики безопасности организации, идентифицирующее и, при необходимости, объясняющее все положения политики безопасности организации или правила, которым должен подчиняться объект оценки. Для представления любого положения политики, позволяющего использовать его для установления четких целей безопасности, могут понадобиться объяснения и интерпретации. Если цели безопасности следуют только из угроз и предположений безопасности, описание политики безопасности организации может быть опущено. Изложение целей безопасности должно определять цели безопасности как для ОО, так и для его среды. Цели безопасности должны отражать изложенное намерение противостоять всем установленным угрозам и быть подходящими для этого, а также охватывать все предположения безопасности и установленную политику безопасности организации. Должны быть идентифицированы категории целей безопасности, Если при этом противостояние угрозе или проведение политики безопасности частично возлагается на ОО, а частично на его среду, соответствующая цель безопасности должна повторяться в каждой категории. 1. Цели безопасности для ОО должны быть четко изложены и сопоставлены с аспектами установленных угроз, которым необходимо противостоять средствами ОО, и/или с политикой безопасности организации, которой должен отвечать ОО. 2. Цели безопасности для среды ОО должны быть четко изложены и сопоставлены с аспектами установленных угроз, которым не полностью противоречит ОО, и/или с политикой безопасности организации и предположениями, не полностью удовлетворяемыми ОО. В следующей части ЗБ подробно определяются требования безопасности ИТ, которые должны удовлетворяться ОО или его средой. Требования безопасности ОО должны быть изложены следующим образом. 1. При изложении требований безопасности ОО должны быть определены функциональные требования и требования доверия, к которым должны удовлетворять ОО и свидетельства поддержки его оценки для достижения целей безопасности ОО. 2. Необязательное изложение требований безопасности для среды ИТ должно определять требования безопасности ИТ, которым должна отвечать среда безопасности ИТ этого ОО. Если безопасность ОО не зависит от среды ИТ, то эта часть ЗБ может быть опущена. Отметим, что хотя требования безопасности среды, не относящиеся к ИТ, часто бывают полезны на практике, не требуется, чтобы они являлись формальной частью ЗБ, поскольку они не связаны непосредственно с реализацией ОО. 3. Перечисленные ниже общие условия в равной степени относятся к выражению функциональных требований и требований доверия как для ОО, так и для его среды ИТ. Краткая спецификация ОО должна определить отображение требований безопасности ОО. Эта спецификация должна представить описание функций безопасности и мер доверия к ОО, которые отвечают требованиям безопасности этого объекта оценки. Краткая спецификация ОО включает в себя следующее. Изложение функций безопасности ОО, которое должно охватывать все функции безопасности ИТ и определять, каким образом эти функции удовлетворяют функциональным требованиям безопасности объекта. Изложение должно включать в себя двунаправленное сопоставление функций и требований с четким указанием, в удовлетворении каких требований участвует каждая функция, и что при этом удовлетворены все требования. Каждая функция безопасности должна участвовать в удовлетворении, по меньшей мере, одного функционального требования безопасности ОО. Изложение мер доверия, которое должно специфицировать меры доверия к ОО, заявленные для удовлетворения изложенных требований доверия. Меры доверия должны быть сопоставлены с требованиями таким образом, чтобы было понятно, какие меры в удовлетворении каких требований участвуют. В ЗБ могут быть утверждения, что ОО соответствует требованиям одного или, возможно, нескольких ПЗ. Для каждого из имеющихся утверждений ЗБ должно включать изложение утверждения о соответствии ПЗ, содержащее объяснение, строгое обоснование и любые другие вспомогательные материалы, необходимые для подкрепления данного утверждения. Содержание и представление в задании по безопасности целей и требований для объекта оценки может зависеть от того, делаются ли для этого ОО утверждения о соответствии профилю защиты. Влияние на ЗБ утверждения о соответствии ПЗ может быть сведено в итоге к одному из следующих вариантов. Если утверждений о соответствии ПЗ нет, то следует провести полное описание целей и требований безопасности ОО. Если в ЗБ утверждается только о соответствии требованиям какого-либо ПЗ без необходимости их дальнейшего уточнения, то ссылки на профиль достаточно, чтобы определить и строго обосновать цели и требования безопасности ОО. Повторное изложение содержания ПЗ не является обязательным. Если в ЗБ утверждается о соответствии требованиям какого-либо ПЗ, и требования этого ПЗ нуждаются в дальнейшем уточнении, то в ЗБ должно быть показано, что требования по уточнению ПЗ удовлетворены. В этом случае может оказаться предпочтительным для ясности повторно изложить содержание ПЗ в составе ЗБ. Если в ЗБ утверждается о соответствии требованиям какого-либо ПЗ, но последний расширяется путем добавления дополнительных целей и требований, то в ЗБ должны быть определены эти дополнения с учетом того, что ссылки на профиль может быть достаточно для определения целей и требований безопасности ПЗ. В некоторых случаях, когда дополнения к профилю существенны, может оказаться предпочтительным для ясности повторно изложить содержание ПЗ в составе ЗБ. Случай, когда в ЗБ утверждается о частичном соответствии ПЗ, не примелем для оценки в рамках ОК, ОК не содержат жестких правил предпочтения ссылки на ПЗ повторению изложения его целей и требований. Основным является требование, чтобы содержание ЗБ было полным, ясным и однозначным настолько, чтобы оценка ЗБ была возможной, а само ЗБ являлось приемлемой основой для оценки ОО, и четко прослеживалось соответствие каждому заявленному ПЗ. Если сделано утверждение о соответствии какому-либо ПЗ, то изложение утверждений о соответствии должно содержать следующий материал для каждого ПЗ. 1. Ссылку на ПЗ, идентифицирующую ПЗ, соответствие которому утверждается, плюс любые дополнительные материалы, которые могут потребоваться в соответствии с этим утверждением. 2. Конкретизацию ПЗ, идентифицирующую те требования безопасности ИТ, в которых выполняются операции, разрешенные в ПЗ, или дополнительно уточняются требования ПЗ. 3. Дополнение ПЗ, идентифицирующее цели и требования безопасности ОО, которые дополняют цели и требования ПЗ. В следующей части ЗБ – Обоснование – предоставляется свидетельство, используемое при оценке ЗБ. Это свидетельство поддерживает утверждения, что ЗБ является полной и взаимосвязанной совокупностью требований и что соответствующий ему ОО обеспечит эффективный набор контрмер безопасности ИТ в определенной среде безопасности, а краткая спецификация ОО согласуется с требованиями. Обоснование также демонстрирует, что все утверждения о соответствии ПЗ справедливы. Обоснование должно включать в себя следующее. Логическое обоснование целей безопасности, демонстрирующее, что изложенные цели безопасности сопоставимы со всеми идентифицированными аспектами среды безопасности ОО и пригодны для их охвата. Логическое обоснование требований безопасности, демонстрирующее, что совокупность требований безопасности (ОО и его среды) пригодна для достижения целей безопасности и сопоставлена с ними. 3. Логическое обоснование краткой спецификации ОО, показывающее, что функция безопасности и меры доверия к ОО пригодны, чтобы отвечать требованиям безопасности ОО. 4. Логическое обоснование утверждений о соответствии ПЗ, объясняющее любые различия между целями и требованиями безопасности ЗБ и любого ПЗ, соответствие которому утверждается. Эта часть ЗБ не может быть опущена, если не сделано утверждений о соответствии ПЗ или если цели и требования безопасности ЗБ и каждого ПЗ, соответствие которому утверждается, полностью совпадают. Этот потенциально объемный материал разрешается распространять отдельно, поскольку он необходим или полезен не для всех пользователей ЗБ. 3.9 Понятия доверия, оценки и нарушения безопасности Основные принципы ГОСТ Р ИСО/МЭК 15408 состоят в том, что следует четко сформулировать угрозы безопасности и положения политики безопасности организации, а достаточность предложенных мер безопасности должна быть продемонстрирована. Более того, следует предпринять меры по уменьшению вероятности наличия уязвимостей, возможностей их проявления (то есть преднамеренного использования или непреднамеренной активизации), а также степени ущерба, который может явиться следствием проявления уязвимостей. Дополнительно следует предпринять меры для облегчения последующей идентификации уязвимостей, а также по их устранению, ослаблению и/или оповещению об их использовании или активизации. Основная концепция ГОСТ Р ИСО/МЭК 15408 – обеспечение доверия, основанное на оценке (активном исследовании) продукта или системы ИТ, которым предполагается доверять. Оценка была традиционным способом обеспечения доверия и являлась основой предшествующих критериев оценки. Предполагается, что имеются нарушители, которые будут пытаться активно использовать возможность нарушения политики безопасности, как для получения незаконной выгоды, так и для незлонамеренных, но, тем не менее, опасных действий. Нарушители могут также случайно активизировать уязвимости безопасности, нанося вред организации. При необходимости обрабатывать чувствительную информацию, при отсутствии доверенных продуктов или систем существует значительный риск вследствие отказов ИТ. Поэтому нарушения безопасности ИТ могут вызвать значительные потери. Нарушения безопасности ИТ возникают вследствие преднамеренного использования или случайной активизации уязвимостей при применении ИТ по назначению. Следует предпринять ряд шагов для предотвращения уязвимостей, возникающих в продуктах и системах ИТ. По возможности уязвимости должны быть: устранены, то есть следует предпринять активные действия для выявления, а затем для удаления или нейтрализации всех уязвимостей, которые могу проявиться; минимизированы, то есть следует предпринять активные действия для уменьшения допустимого остаточного уровня возможного ущерба от любого проявления уязвимостей; отслежены, то есть следует предпринять активные действия для обнаружения любой попытки использовать оставшиеся уязвимости с тем, чтобы ограничить ущерб. Уязвимости могут возникать из-за недостатков: требований, то есть продукт или система ИТ могут обладать требуемыми от них функциями и свойствами, но все же содержать уязвимости, которые делают их непригодными или неэффективными в части безопасности; проектирования, то есть продукт или система ИТ не отвечают спецификации, и/или уязвимости являются следствием некачественных стандартов проектирования или неправильных проектных решений; эксплуатации, то есть продукт или система ИТ разработаны в полном соответствии с корректными спецификациями, но уязвимости возникают как результат неадекватного управления при эксплуатации. Доверие – это основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие могло бы быть получено путем обращения к таким источникам, как бездоказательное утверждение, предшествующий аналогичный опыт или специфический опыт. Однако ГОСТ Р ИСО/МЭК 15408 обеспечивает доверие с использованием активного исследования. Активное исследование – это оценка продукта или системы ИТ для определения его свойств безопасности. Оценка является традиционным способом достижения доверия, и она положена в основу ГОСТ Р ИСО/МЭК 15408. Существует три вида оценок: оценка профиля защиты; оценка задания по безопасности; Оценка объекта оценки. Оценка ПЗ выполняется согласно критериям оценки ПЗ, содержащимся в части 3 ОК. Целью такой оценки является продемонстрировать, что профиль полон, непротиворечив, технически правилен и пригоден для использования при изложении требований к ОО, предполагаемому для оценки. Оценка ЗБ для объекта оценки выполняется согласно критериям оценки ЗБ, содержащимися в части 3 ОК. Такая оценка имеет две цели: продемонстрировать, что ЗБ является полным, непротиворечивым, технически правильным и, следовательно, пригодным для использования в качестве основы для оценки соответствующего ОО; в случае, когда в ЗБ имеется утверждение о соответствии некоторому ПЗ, − продемонстрировать, что ЗБ должным образом отвечает требованиям этого ПЗ. Оценка ОО производится согласно критериям оценки, содержащимся в части 3 ОК, с использованием в качестве основы ЗБ, прошедшего оценку. Цель такой оценки – продемонстрировать, что ОО отвечает требованиям безопасности, содержащимся в ЗБ. Методы оценки могут, в частности, включать в себя: анализ и проверку процессов и процедур; проверку, что процессы и процедуры действительно применяются; анализ соответствия между представлениями проекта ОО; анализ соответствия каждого представления проекта ОО требованиям; верификацию доказательств; анализ руководств; анализ разработанных функциональных тестов и полученных результатов; независимое функциональное тестирование; анализ уязвимостей, включающий предположения о недостатках; тестирование проникновения. Основные принципы ГОСТ Р ИСО/МЭК 15408 содержат утверждение, что большее доверие является результатом приложения больших усилий при оценке и что цель состоит в применении минимальных усилий, требуемых для обеспечения необходимого уровня доверия. Повышение уровня усилий может быть основано на: области охвата, то есть увеличении рассматриваемой части продукта или системы ИТ; глубине, то есть детализации рассматриваемых проектных материалов и реализации; строгости, то есть применении более структурированного и формального подхода. 3.10 Требования доверия к безопасности Ниже описываются конструкции, используемые в представлении классов, семейств и компонентов доверия, оценочных уровней доверия (ОУД), и их взаимосвязь. На рисунке 3.8 показаны требования доверия, определенные в ГОСТ Р ИСО/МЭК 15408. Наиболее общую совокупность требований доверия называют классом. Каждый класс содержит семейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия. Каждому классу доверия присвоено уникальное имя. Имя указывает на тематические разделы, на которые распространяется данный класс доверия. Представлена также уникальная форма имени класса доверия. Она является основным средством для ссылки на класс доверия. Принятое условное обозначение включает в себя букву "А", за которой следуют еще две буквы латинского алфавита, относящегося к имени класса. Каждый класс доверия имеет вводный раздел, в котором описаны состав и назначение класса, также в нем содержится, по меньшей мере, одно семейство доверия. Каждому семейству доверия присвоено уникальное имя, которое содержит описательную информацию по тематическим разделам, на которые распространяется данное семейство доверия. Каждое семейство доверия размещено в пределах класса доверия, который содержит другие семейства той же направленности. Представлена уникальная краткая форма имени семейства доверия. Она является основным средством для ссылки на семейство доверия. Принятое условное обозначение включает в себя краткую форму имени класса и символ подчеркивания, за которым следуют три буквы латинского алфавита, относящегося к имени семейства. Подраздел целей семейства доверия представляет назначение семейства доверия. В нем описаны цели, для достижения которых предназначено семейство, особенно связанные с парадигмой доверия ГОСТ Р ИСО/МЭК 15408. Описание целей для семейства доверия представлено в общем виде. Любые конкретные подробности, требуемые для достижения целей, включены в конкретный компонент доверия. Каждое семейство доверия содержит один или несколько компонентов доверия. Этот подраздел семейства доверия содержит описание имеющихся компонентов и объяснение их разграничения. Его основная цель состоит в указании различий между компонентами при условии, что семейство является необходимой или полезной частью требований доверия для ПЗ/ЗБ. В семействах доверия, содержащих более одного компонента, выполнено ранжирование компонентов и приведено обоснование, которое сформулировано в терминах области применения, глубины и/или строгости. Рисунок 3.8 – Иерархическая структура представления требований доверия Необязательный подраздел замечаний по применению семейства доверия содержит дополнительную информацию о семействе. Эта информация предназначена для пользователей семейства доверия (например, разработчиков ПЗ и ЗБ, проектировщиков ОО или оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания. Каждое семейство содержит хотя бы один компонент доверия. Структура компонентов доверия представлена на рисунке 3.9. Связь между компонентами внутри семейства показана с использованием соглашения о шрифтовом выделении. Для частей требований, которые являются новыми, расширенными или модифицированными по сравнению с требованиями предыдущего по иерархии компонента, применен полужирный шрифт. Такое же соглашение о шрифтовом выделении использовано и для зависимостей. Рисунок 3.9 –Структура компонента доверия Подраздел идентификации компонента содержит описательную информацию, необходимую для идентификации, категорирования, регистрации и ссылок на компонент. Каждому компоненту доверия присвоено уникальное имя, которое содержит информацию о тематических подразделах, на которые распространяется компонент доверия. Каждый компонент входит в состав конкретного семейства доверия, с которым имеет общую цель безопасности. Представлена также уникальная краткая форма имени компонента доверия как основной способ ссылки на компонент. Принято, что за краткой формой имени семейства ставится точка, а затем цифра. Цифры для компонентов внутри каждого семейства назначены последовательно, начиная с единицы. Необязательный подраздел целей компонента доверия содержит конкретные цели этого компонента. Для компонентов доверия, которые имеют этот подраздел, он включает в себя конкретное назначение данного компонента и подробное разъяснение целей. Необязательный подраздел замечаний по применению компонента доверия содержит дополнительную информацию для облегчения использования компонента. Зависимости среди компонентов доверия возникают, когда компонент не самодостаточен, а предполагает присутствие другого компонента. Для каждого компонента доверия приведен полный список зависимостей от других компонентов доверия. При отсутствии у компонента идентифицированных зависимостей вместо списка указано: "Зависимости отсутствуют". Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов. Список зависимостей определяет минимальный набор компонентов доверия, на которые следует полагаться. Компоненты, которые иерархичны по отношению к компоненту их списка зависимостей, также могут использоваться для удовлетворения зависимости. В отдельных ситуациях обозначенные зависимости могут быть применимы. Разработчик ПЗ/ЗБ может отказаться от удовлетворения зависимости, представив обоснование, почему данная зависимость неприменима. Каждый компонент доверия содержит набор элементов доверия. Элемент доверия – требование безопасности, при дальнейшем разделении которого не изменяется результат оценки. Он является наименьшим неделимым требованием безопасности, определенным в ГОСТ Р ИСО/МЭК 15408. Каждый элемент доверия принадлежит к одному из трех типов: Элементы доверия разработчика, определяющие действия, которые должны выполняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в следующем наборе элементов. Требования к действиям разработчика обозначены буквой "D" после номера элемента. Элементы содержания и представления свидетельств, определяющие требуемые свидетельства и отражаемую в них информацию. Требования к содержанию и представлению свидетельств обозначены буквой "С" после номера элемента. Элементы действий оценщика, определяющие действия, которые должны выполняться оценщиком. Этот набор действий непосредственно включает в себя подтверждение того, что требования, предписанные элементами содержания и представления свидетельств, выполнены, а также конкретные действия и анализ, выполняемые в дополнение к уже проведенным разработчиком. Должны также выполняться неуказанные явно действия оценщика, необходимые вследствие элементов действий разработчика, но неохваченные в требованиях к содержанию и представлению свидетельств буквой "Е" после номера элемента. Действия разработчика, содержание и представление свидетельств определяют требования, предъявляемые к разработчику по демонстрации доверия к функции безопасности объекта оценки (ФБО). Выполняя эти требования, разработчик может повысить уверенность в том, что ОО удовлетворяет функциональным требованиям и требованиям доверия из ПЗ или ЗБ. Действия оценщика определяют его ответственность по двум аспектам. Первый аспект – проверка правильности ПЗ/ЗБ в соответствии с требованиями классов оценки профиля защиты и оценки задания по безопасности: APE/ASE. Второй аспект – верификация соответствия ОО его функциональным требованиям и требованиям доверия. Демонстрируя, что ПЗ/ЗБ правильны, и их требования выполняются ОО, оценщик может предоставить основание для уверенности в том, что ОО будет отвечать поставленным целям безопасности. Элементы действий разработчика представляет собой требование для выполнения. Формулировки этих требований должны быть четкими, краткими и однозначными. Поэтому в требованиях отсутствуют составные предложения. Каждое требование изложено как отдельный элемент. Рисунок 3.10 иллюстрирует оценочные уровни доверия и их структуру, определенную в ГОСТ Р ИСО/МЭК 15408. Компоненты доверия, содержание которых показано на рисунке, включены в ОУД посредством ссылок на компоненты. Каждому ОУД присвоено уникальное имя. Имя представляет описательную информацию о предназначении ОУД. Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД. В подразделе целей ОУД приведено назначение ОУД. Необязательный подраздел замечаний по применению ОУД содержит информацию, представляющую интерес для пользователей ОУД (например, для разработчиков ПЗ и ЗБ, проектировщиков ОО, планирующих использование этого ОУД, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания. Рисунок 3.10 – Структура ОУД Для каждого ОУД выбран набор компонентов доверия. Более высокий уровень доверия, чем предоставляемый данным ОУД, может быть достигнут: включением дополнительных компонентов доверия из других семейств доверия; заменой компонента доверия иерархичным компонентом из этого же семейства доверия. Рисунок 3.11 иллюстрирует связь между требованиями и уровнями доверия, определенными в ГОСТ Р ИСО/МЭК 15408. Компоненты доверия состоят из элементов, но последние не могут по отдельности быть включены в уровни доверия. Стрелка на рисунке отображает ссылку в ОУД на компонент доверия внутри класса, где он определен. ГОСТ Р ИСО/МЭК 15408 содержит классы семейств и компонентов, которые сгруппированы на основе, связанной с доверием. В начале каждого класса представлена диаграмма, которая указывает семейства в классе и компоненты в каждом классе. На рисунке 3.12 показан класс, содержащий одно семейство. Семейство содержит три компонента, которые являются линейно иерархичными (т. е. компонент 2 содержит более высокие требования, чем компонент 1, к конкретным действиям, приводимым свидетельствам или строгости действий и/или свидетельств). Все семейства доверия – линейно иерархичны, хотя линейность не обязательна для семейств доверия, которые могут быть добавлены в дальнейшем. Рисунок 3.11 – Связь требований и уровня доверия 3.11 Оценка профиля защиты. Класс АРЕ Цель оценки ПЗ − показать, что он является полным, непротиворечивым и технически правильным и поэтому пригоден для изложения требований к одному или нескольким оцениваемым объектам оценки. Оцененный ПЗ пригоден в качестве основы для разработки заданий по безопасности и приемлем для включения в реестр ПЗ. На рисунке 3.13 показаны семейства этого класса, которые описаны в следующих подразделах. 3.11.1 Описание ОО (APE_DES) Цель: описание ОО способствует пониманию требований безопасности ОО. Оценка описания ОО требуется, чтобы показать, что оно является логически последовательным, внутренне непротиворечивым и согласованным со всеми другими частями ПЗ. АРЕ_DES.1 Профиль защиты, описание OO, требования оценки. Зависимости: АРЕ_ENV.1 Профиль защиты, среда безопасности, требования оценки. АРЕ_INT.1 Профиль защиты, введение ПЗ, требования оценки. АРЕ_ОВJ.1 Профиль защиты, цели безопасности, требования оценки. АРЕ_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки. Элементы действий разработчика: АРЕ_DES.1.1D Разработчик ПЗ должен представить описание ОО как часть ПЗ. Элементы содержания и представления свидетельств: АРЕ_DES.1.1C Описание ОО, как минимум, должно включать в себя тип продукта и общие свойства ИТ, присущие ОО. Элементы действий оценщика: АРЕ_DES.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. Рис. 3.12 – Декомпозиция класса "Оценка профиля защиты" Элементы содержания и представления свидетельств: АРЕ_DES.1.1C Описание ОО, как минимум, должно включать в себя тип продукта и общие свойства ИТ, присущие ОО. Элементы действий оценщика: АРЕ_DES.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. АРЕ_DES.1.2E Оценщик должен подтвердить, что описание ОО является логически последовательным и внутреннее непротиворечивым. АРЕ_DES.1.3E Оценщик должен подтвердить, что описание ОО согласуется с другими частями ПЗ. 3.11.2 Среда безопасности (АРЕ_ENV) Цель: описание среда безопасности необходимо для принятия решения о достаточности требований безопасности ИТ в ПЗ, важно, чтобы решаемая задача безопасности ясно понималась всеми участниками оценки. АРЕ_ENV.1 Профиль защиты, среда безопасности, требования оценки. Зависимости отсутствуют. Элементы действий разработчика: АРЕ_ENV.1.1D Разработчик ПЗ должен представить изложение среды безопасности ОО как часть ПЗ. Элементы содержания и представления свидетельств: АРЕ_ENV.1.1С Изложение среды безопасности ОО должно идентифицировать и объяснить любые предположения о предполагаемом применении ОО и среде использования ОО. АРЕ_ENV.1.2С Изложение среды безопасности ОО должно идентифицировать и объяснить любые известные или допускаемые угрозы активам, от которых будет требоваться защита посредством ОО или его среды. АРЕ_ENV.1.3С Изложение среды безопасности ОО должно идентифицировать и объяснить каждую политику безопасности организации, соответствие которой для ОО необходимо. Элементы действий оценщика: АРЕ_ENV.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. АРЕ_ENV.1.2Е Оценщик должен подтвердить, что описание среды безопасности ОО является логически последовательным и внутренне непротиворечивым. 3.11.3 Введение ПЗ (АРЕ_INT) Цель: введение ПЗ содержит информацию для управления документооборотом и обзорную информацию о документе, необходимую для сопровождения реестра ПЗ. Оценка введения ПЗ требуется для демонстрации, что ПЗ правильно идентифицирован и введение согласуется со всеми другими частями ЗБ. АРЕ_INT.1 Профиль защиты, введение ПЗ, требования оценки. Зависимости: АРЕ_DES.1 Профиль защиты, описание OO, требования оценки. АРЕ_ENV.1 Профиль защиты, среда безопасности, требования оценки. АРЕ_ODJ.1 Профиль защиты, цели безопасности, требования оценки. АРЕ_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки. Элементы действий разработчика: АРЕ_INT.1.1D Разработчик ПЗ должен представить введение ПЗ как часть ПЗ. Элементы содержания и представления свидетельств: АРЕ_INT.1.1C Введение ПЗ должно содержать данные идентификации ПЗ, которые предоставляют маркировку и описательную информацию, необходимые для идентификации, каталогизации, регистрации ПЗ и ссылок на него. АРЕ_INT.1.2C Введение ПЗ должно содержать аннотацию ПЗ с общей характеристикой ПЗ в описательной форме. Элементы действий оценщика: АРЕ_INT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. АРЕ_INT.1.2E Оценщик должен подтвердить, что введение ПЗ является логически последовательным и внутренне непротиворечивым. АРЕ_INT.1.3E Оценщик должен подтвердить, что введение ПЗ согласуется с другими частями ПЗ. 3.11.4 Цели безопасности (АРЕ_OBJ) Цели безопасности - краткое изложение предполагаемой реакции на задачу безопасности. Оценка целей безопасности требуется для демонстрации, что установленные цели адекватны проблеме безопасности. Существуют цели безопасности для ОО и цели безопасности для среды. Необходимо сопоставить цели безопасности для ОО и среды с идентифицированными угрозами, которым они противостоят, и/или с политикой и предположениями, которым они соответствуют. АРЕ_OBJ.1 Профиль защиты, цели безопасности, требования оценки. Зависимости: АРЕ_ENV.1 Профиль защиты, среда безопасности, требования оценки. Элементы действий разработчика: АРЕ_OBJ.1.D Разработчик ПЗ должен представить изложение целей безопасности как часть ПЗ. АРЕ_OBJ.1.2D Разработчик ПЗ должен представить логическое обоснование целей безопасности. Элементы содержания и представления свидетельств: АРЕ_OBJ.1.1С Изложение целей безопасности должно определить цели безопасности для OO и его среды. АРЕ_OBJ.1.2C Цели безопасности для OO должны быть четко изложены и сопоставлены с идентифицированными угрозами, которым будет противостоять OO, и/или с политикой безопасности организации, которая будет выполняться OO. АРЕ_OBJ.1.3С Цели безопасности для среды должны быть четко изложены и сопоставлены с теми аспектами идентифицированных угроз, которым OO противостоит не полностью, и/или с политикой безопасности организации или предположениями, не полностью выполняемыми ОО. АРЕ_OBJ.1.4С Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для противостояния всем идентифицированным угрозам безопасности. АРЕ_OBJ.1.5C Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для охвата всех установленных положений политики безопасности организации и предположений. Элементы действий оценщика: АРЕ_OBJ.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. АРЕ_OBJ.1.2E Оценщик должен подтвердить, что описание целей безопасности является полным, логически последовательным и внутренне непротиворечивым. 3.11.5 Требования безопасности (АРЕ_REQ) Цель: требования безопасности ИТ, выбранные для OO и представленные или указанные в ПЗ, необходимо оценить для подтверждения их внутренней непротиворечивости и пригодности для разработки OO, отвечающего его целям безопасности. Не все цели безопасности, выраженные в ПЗ, могут быть выполнены соответствующими ОО, так как некоторые ОО могут зависеть от требований безопасности ИТ, выполняемых средой ИТ. В этом случае требования безопасности ИТ, относящиеся к среде, необходимо ясно изложить и оценить в контексте требований к ОО. Это семейство представляет требования оценки, которые позволяют оценщику принять решение, что ПЗ пригоден для использования в качестве изложения требований к оцениваемому ОО. Дополнительные критерии, необходимые для оценки требований, сформулированных в явном виде, приведены в семействе АРЕ_SRE. Замечания по применению: термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ". Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО". В компоненте АРЕ_REQ.1 использованы несколько значений термина "appropriate" ("соответствующий", "необходимый", "приемлемый", "целесообразный") для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ПЗ. Подробная информация по этим аспектам содержится в приложении Б ГОСТ Р ИСО/МЭК 15408-1. АРЕ_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки. Зависимости: АРЕ_OBJ.1 Профиль защиты, цели безопасности, требования оценки. Элементы действий разработчика: АРЕ_REQ.1.1D Разработчик ПЗ должен представить изложение требований безопасности ИТ как часть ПЗ. АРЕ_REQ.1.2D Разработчик ПЗ должен представить логическое обоснование требований безопасности. Элементы содержания и представления свидетельств: АРЕ_REQ.1.1С Изложение функциональных требований безопасности ОО должно идентифицировать функциональные требования безопасности ОО, составленные из компонентов функциональных требований ГОСТ Р ИСО/МЭК 15408-2. АРЕ_REQ.1.2C Изложение требований доверия к ОО должно идентифицировать требования доверия к ОО, составленные из компонентов требований доверия ГОСТ Р ИСО/МЭК 15408-3. АРЕ_REQ.1.3C В изложение требований доверия к ОО следует включить оценочный уровень доверия (ОУД), как определено в ГОСТ Р ИСО/МЭК 15408-3. АРЕ_REQ.1.4C Свидетельство должно содержать строгое обоснование, что изложение требований доверия к ОО является соответствующим. АРЕ_REQ.1.5C ПЗ должен, при необходимости, идентифицировать каждое требование безопасности для среды ИТ. АРЕ_REQ.1.6C Все завершенные операции над требованиями безопасности ИТ, включенными в ПЗ, должны быть идентифицированы. АРЕ_REQ.1.7C Любые незавершенные операции над требованиями безопасности ИТ, включенными в ПЗ, должны быть идентифицированы. АРЕ_REQ.1.8C Зависимости между требованиями безопасности ИТ, включенными в ПЗ, следует удовлетворить. АРЕ_REQ.1.9C Свидетельство должно содержать строгое обоснование каждого неудовлетворения АРЕ_REQ.1.10C ПЗ должен включать в себя изложение приемлемого минимального уровня стойкости функций безопасности (СФБ) для функциональных требований безопасности ОО: базовой, средней или высокой СФБ. АРЕ_REQ.1.11C ПЗ должен идентифицировать все конкретные функциональные требования безопасности ОО, для которых целесообразно явное указание стойкости функции, так же, как и конкретной метрики. АРЕ_REQ.1.12C Логическое обоснование требований безопасности должно демонстрировать, что минимальный уровень стойкости функции в ПЗ, как и каждое явное указание стойкости функции согласуются с целями безопасности ОО. АРЕ_REQ.1.13С Логическое обоснование требований безопасности должно демонстрировать, что требования безопасности ИТ пригодны для достижения целей безопасности. АРЕ_REQ.1.14С Логическое обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутреннее непротиворечивое целое. Элементы действий оценщика: АРЕ_REQ.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. АРЕ_REQ.1.2E Оценщик должен подтвердить, что описание требований безопасности ИТ является полным, логически последовательным и внутренне непротиворечивым. 3.11.6 Требования безопасности ИТ, сформулированные в явном виде (АРЕ_SRE) Цель: если после тщательного рассмотрения окажется, что ни один из компонентов требований ГОСТ Р ИСО/МЭК 15408 не применим непосредственно ко всем или к части требований безопасности ИТ, разработчик ПЗ может сформулировать другие требования, которые не ссылаются на ГОСТ Р ИСО/МЭК 15408. Использование таких требований должно быть строго обосновано. Это семейство содержит требования оценки, которые позволяют оценщику сделать заключение, что сформулированные в явном виде требования четко и однозначно выражены. Оценка требований, выбранных из ГОСТ Р ИСО/МЭК 15408 и используемых наряду со сформулированными в явном виде допустимыми требованиями безопасности, определяется семейством АРЕ_REQ. Сформулированные в явном виде требования безопасности ИТ для OO, представленные или указанные в ПЗ, требуется оценить для демонстрации четкости и однозначности их выражения. Замечания по применению: формулировка в явном виде требований по структуре, сопоставимой со структурой существующих компонентов и элементов из ГОСТ Р ИСО/МЭК 15408, включает в себя выбор аналогичного маркирования, способа выражения и уровня детализации. Использование требований ГОСТ Р ИСО/МЭК 15408 как образца означает, что требования могут быть четко идентифицированы, что они автономны, и применение каждого требования возможно и даст значимый результат оценки, основанный на анализе соответствия ОО этому конкретному требованию. Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ". Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО". АРЕ_SRE.1 Профиль защиты, требования безопасности ИТ, сформулированные в явном виде, требования оценки. Зависимости: АРЕ_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки. Элементы действий разработчика: АРЕ_SRE.1.1D Разработчик ПЗ должен представить изложение требований безопасности ИТ как часть ПЗ. АРЕ_SRE1.2D Разработчик ПЗ должен представить логическое обоснование требований безопасности. Элементы содержания и представления свидетельств: АРЕ_SRE.1.1C Все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ГОСТ Р ИСО/МЭК 15408, должны быть идентифицированы. АРЕ_SRE.1.2С Все требования безопасности для среды ИТ, которые сформулированы в явном виде без ссылки на ГОСТ Р ИСО/МЭК 15408, должны быть идентифицированы. АРЕ_SRE.1.3С Свидетельство должно содержать строгое обоснование, почему требования безопасности должны быть сформулированы в явном виде. АРЕ_SRE.1.4С Сформулированные в явном виде требования безопасности ИТ должны использовать компоненты, семейства и классы требований ГОСТ Р ИСО/МЭК 15408 как образец для представления. АРЕ_SRE.1.5С Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, что соответствие или несоответствие им ОО может быть определено и последовательно продемонстрировано. АРЕ_SRE.1.6С Сформулированные в явном виде требования безопасности ИТ должны быть четко и недвусмысленно выражены. АРЕ_SRE.1.7С Логическое обоснование требований безопасности должно демонстрировать, что требования доверия применимы и пригодны для поддержки каждого из сформулированных в явном виде функциональных требований безопасности ОО. Элементы действий оценщика: АРЕ_SRE.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. АРЕ_SRE.1.2Е Оценщик должен определить, что все зависимости сформулированных виде требований безопасности ИТ были идентифицированы. 3.12 Оценка задания по безопасности. Класс ASE Цель оценки ЗБ состоит в демонстрации, что ЗБ является полным, непротиворечивым, технически правильным и поэтому пригодно в качестве основы для оценки и соответствующего ОО. На рисунке 3.14 показаны семейства этого класса. Рисунок 3.13 – Декомпозиция класса "Оценка задания по безопасности" 3.12.1 Описание ОО (ASE_DES) Цель: описание ОО способствует пониманию требований безопасности ОО. Оценка описания ОО требуется, чтобы показать, что оно является логически последовательным, внутренне непротиворечивым и согласованным со всеми другими частями ЗБ. ASE_DES.1 Задание по безопасности, описание ОО, требования оценки. Зависимости: ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки. ASE_INT.1 Задание по безопасности, введение ПЗ, требования ПЗ. ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки. ASE_PPC.1 Задание по безопасности, утверждение о соответствии ПЗ, требования оценки. ASE_ REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки. ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования оценки. Элементы действия разработчика: ASE_DES.1.1DРазработчик должен представить описание ОО как часть ЗБ. Элементы содержания и представления свидетельств: ASE_DES.1.1C Описание ОО, как минимум, должно включать в себя тип продукта или системы, а также область и ограничения применения ОО в общеупотребительных терминах, как в физическом, так и в логическом смысле. Элементы действий оценщика: ASE_DES.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. ASE_DES.1.2E Оценщик должен подтвердить, что описание ОО является логически последовательным и внутренне непротиворечивым. ASE_DES.1.3E Оценщик должен подтвердить, что описание ОО согласуется с другими частями ЗБ. 3.12.2 Среда безопасности (ASE_ENV) Цель: изложение среды безопасности необходимо для принятия решения о достаточности требований безопасности ИТ в ЗБ, важно, чтобы решаемая задача безопасности ясно воспринималась всеми участниками оценки. ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки. Зависимости отсутствуют. Элементы действий разработчика: ASE_ENV.1.1D Разработчик должен представить изложение среды безопасности ОО как часть ЗБ. Элементы содержания и представления свидетельств: ASE_ENV.1.1С Изложение среды безопасности ОО должно идентифицировать и объяснить любые предположения о предполагаемом применении ОО и среде использования ОО. ASE_ENV.1.2С Изложение среды безопасности ОО должно идентифицировать и объяснять любые известные или допускаемые грозы активам, от которых будет требоваться защита посредством ОО или его среды. ASE_ENV.1.3С Изложение среды безопасности ОО должно идентифицировать и объяснять каждую политику безопасности организации, соответствие которой для ОО необходимо. Элементы действий оценщика: ASE_ENV.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. ASE_ENV.1.2Е Оценщик должен подтвердить, что описание среды безопасности ОО является логически последовательным и внутренне непротиворечивым. 3.12.3 Введение ЗБ (ASE_INT) Цель: введение ЗБ содержит материалы по идентификации и индексации материалов. Оценка введения ЗБ требуется для демонстрации, что ЗБ правильно идентифицировано и введение согласуется со всеми другими частями ЗБ. ASE_INT.1 Задание по безопасности, введение ЗБ, требования оценки. Зависимости: ASE_DES.1 Задание по безопасности, описание ОО, требования оценки. ASE_ETV.1 Задание по безопасности, среда безопасности, требования оценки. ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки. ASE_PPC.1 Задание по безопасности, утверждения о соответствии ПЗ, требования оценки. ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки. ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования оценки. Элементы действий разработчика: ASE_INT.1.1D Разработчик должен представить введение ЗБ как часть ЗБ. Элементы содержания и представления свидетельств: ASE_INT.1.1C Введение ЗБ должно содержать данные идентификации ЗБ, которые представляют маркировку и описательную информацию, необходимые для идентификации и применения ЗБ и ОО, к которому оно относится. ASE_INT.1.2C Введение ЗБ должно содержать аннотацию ЗБ с общей характеристикой ЗБ в описательной форме. ASE_INT.1.3C Введение ЗБ должно содержать утверждение о соответствии ГОСТ Р ИСО/МЭК 15408, излагающее все оцениваемые утверждения о соответствии ОО ГОСТ Р ИСО/МЭК 15408. Элементы действий оценщика: ASE_INT.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. ASE_INT.1.2Е Оценщик должен подтвердить, что введение ЗБ является логически последовательным и внутренне непротиворечивым. ASE_INT.1.2Е Оценщик должен подтвердить, что введение ЗБ согласуется с другими частями ЗБ. 3.12.4 Цели безопасности (ASE_OBJ) Цель безопасности – краткое изложение предполагаемой реакции на задачу безопасности. Оценка целей безопасности требуется для демонстрации, что установленные цели адекватны проблеме безопасности. Существуют цели безопасности для ОО и цели безопасности для среды. Необходимо сопоставить цели безопасности для ОО и среды с идентифицированными угрозами, которыми они противостоят, и/или с политикой и предположениями, которым они соответствуют. ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки. Зависимости: ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки Элементы действий разработчика: ASE_OBJ.1.1D Разработчик должен представить изложение целей безопасности как часть ЗБ. ASE_OBJ.1.2D Разработчик должен представить логическое обоснование целей безопасности. Элементы содержания и представления свидетельств: ASE_OBJ.1.1С Изложение целей безопасности должно определить цели безопасности для ОО и его среды. ASE_OBJ.1.2С Цели безопасности для ОО должны быть четко изложены и сопоставлены с идентифицированными угрозами, которым будет противостоять ОО, и/или с политикой безопасности организации, которая будет выполняться ОО. ASE_OBJ.1.3С цели безопасности для среды должны быть четко изложены и сопоставлены с теми аспектами идентифицированных угроз, которым ОО противостоит не полностью, и/или с политикой безопасности организации или предположениями, не полностью выполняемыми ОО. ASE_OBJ.1.4С Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для восприятия всеми идентифицированными угрозами безопасности. ASE_OBJ.1.5С Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для охвата всех установленных положений политики безопасности организаций и предположений. Элементы действий оценщика: ASE_OBJ.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. ASE_OBJ.1.2Е Оценщик должен подтвердить, что описание целей безопасности является полным, логически последовательным и внутренне непротиворечивым. 3.12.5 Утверждения о соответствии ПЗ (ASE_PPC) Цель оценки утверждений о соответствии ПЗ состоит в том, чтобы решить, является ли ЗБ корректным отображением ПЗ. Замечания по применению: семейство применяются только при наличии утверждений о соответствии ПЗ. В противном случае не требуется никаких действий разработчика и оценщика. Хотя при наличии утверждений о соответствии ПЗ необходимы дополнительные действия по оценки, затраты на оценку ЗБ обычно все-таки меньше, чем в случае, когда никакой ПЗ не применяется, потому что при оценке ЗБ можно использовать результаты оценки этого ПЗ. ASE_PPC.1 Задание по безопасности, утверждения о соответствии ПЗ, требования оценки. Зависимости: ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки. ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требованяи оценки. Элементы действия разработчика: ASE_PPC.1.1D Разработчик должен представить каждое утверждение о соответствии ПЗ как часть ЗБ. ASE_PPC.1.2D Разработчик должен представить логическое обоснование утверждений о соответствии ПЗ для каждого представленного утверждения о соответствии ПЗ. Элементы содержания и представления свидетельств: ASE_PPC.1.1С Каждое утверждение о соответствии ПЗ должно идентифицировать ПЗ, соответствие которому утверждается, включая необходимые уточнения, связанные с этим утверждением. ASE_PPC.1.2С Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки требований безопасности ИТ, в которых завершены разрешенные операции или иначе выполнено дальнейшее уточнение требований ПЗ. ASE_PPC.1.3С Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки содержащихся в ЗБ целей безопасности и требований безопасности ИТ, которые дополняют имеющиеся в ПЗ. Элементы действий оценщика: ASE_PPC.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. ASE_PPC.1.2Е Оценщик должен подтвердить, что утверждения о соответствии профилям защиты являются корректным отображением соответствующих ПЗ. 3.12.6 Требования безопасности ИТ (ASE_REQ) Цель: требования безопасности ИТ, выбранные для ОО и представленные или указанные в ЗБ, необходимо оценить для подтверждения их внутренней непротиворечивости и пригодности для разработки ОО, отвечающего его целям безопасности. Это семейство представляет требования оценки, которые позволяют оценщику принять решение, что ЗБ пригодно для использования в качестве изложения требований к соответствующему ОО. Дополнительные критерии, необходимые для оценки требований, сформулированных в явном виде, приведены в семействе ASE_SRE. Замечания по применению: Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ". Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО". В компоненте ASE_REQ.1 использованы несколько значений термина "appropriate" ("соответствующий", "необходимый", "приемлемый", "целесообразный") для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ЗБ. Подробная информация по этим аспектам содержится в приложении В ГОСТ Р ИСО/МЭК 15408-1. ASE_REQ.1 Задание по безопасности, требования ИТ, требования оценки. Зависимости: ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки. Элементы действий разработчика: ASE_REQ.1.1D Разработчик должен представить изложение требований безопасности ИТ как часть ЗБ. ASE_REQ.1.2D Разработчик должен представить логическое обоснование требований безопасности. Элементы содержания и представления свидетельств: ASE_REQ.1.1С Изложение функциональных требований безопасности ОО должно идентифицировать функциональные требования безопасности ОО, составленные из компонентов функциональных требований из ГОСТ Р ИСО/МЭК 15408-2. ASE_REQ.1.2С Изложение требований доверия к ОО должно идентифицировать требований доверия к ОО, составленные из компонентов требований доверия из ГОСТ Р ИСО/МЭК 15408-3. ASE_REQ.1.3С В изложении требований доверия к ОО следует включить оценочный уровень доверия (ОУД), как определено в ГОСТ Р ИСО/МЭК 15408-3. ASE_REQ.1.4С Свидетельство должно содержать строгое обоснование, что изложение требований доверия к ОО является соответствующим. ASE_REQ.1.5С ЗБ должно, при необходимости, идентифицировать каждое требование безопасности для среды ИТ. ASE_REQ.1.6С Операции, предусмотренные в требованиях безопасности ИТ, включенных в ЗБ, должны быть идентифицированы и выполнены. ASE_REQ.1.7С Зависимости между требованиями безопасности ИТ, включенными в ЗБ, следует удовлетворить. ASE_REQ.1.8С Свидетельство должно сдержать строгое обоснование каждого неудовлетворения зависимостей. ASE_REQ.1.9С ЗБ должно включать в себя изложение приемлемого минимального уровня стойкости функции безопасности (СФБ) для функциональных требований безопасности ОО: базовой, средней и высокой. ASE_REQ.1.10С ЗБ должно идентифицировать все конкретные функциональные требования безопасности ОО, для которых целесообразно явное указание стойкости функции, так же, как и конкретной метрики. ASE_REQ.1.11С Логическое обоснование требований безопасности должно демонстрировать, что минимальный уровень стойкости функции в ЗБ, как и каждое явное указание стойкости функции согласуется с целями безопасности ОО. ASE_REQ.1.12С Логическое обоснование требований безопасности должно демонстрировать, что требования безопасности ИТ пригодны для достижения целей безопасности. ASE_REQ.1.13С Логическое обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутренне непротиворечивое целое. Элементы действий оценщика: ASE_REQ.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. ASE_REQ.1.2Е Оценщик должен подтвердить, что описание требований безопасности ИТ является полным, логически последовательным и внутренне непротиворечивым. 3.12.7 Требования безопасности, сформулированные в явном виде (ASE_SRE) Цель: если после тщательного рассмотрения окажется, что ни один из компонентов требований ГОСТ Р ИСО/МЭК 15408-2 или ГОСТ Р ИСО/МЭК 15408-3 не применим непосредственно ко всем или к части требований безопасности ИТ, разработчик ЗБ может сформулировать другие требования, которые не ссылаются на ГОСТ Р ИСО/МЭК 15408. Использование таких требований должно быть строго обосновано. Это семейство содержит требования оценки, которые позволяют оценщику сделать заключение, что сформулированные в явном виде требования четко и однозначно выражены. Оценка требований, выбранных из ГОСТ Р ИСО/МЭК 15408 и используемых наряду со сформулированными в явном виде допустимыми требованиями безопасности, определяются семейством ASE_REQ. Сформулированные в явном виде требования безопасности ИТ для ОО, представленные или указанные в ЗБ, требуется оценить для демонстрации четкости и однозначности их выражения. Замечания по применению: формулировка в явном виде требований по структуре, сопоставимой со структурой существующих компонентов и элементов из ГОСТ Р ИСО/МЭК 15408, включает в себя набор аналогичного маркирования, способа выражения и уровня детализации. Использование требований ГОСТ Р ИСО/МЭК 15408 как образца означает, что требования могут быть четко идентифицированы, что они автономны, и применение каждого требования возможно и даст значимый результат оценки, основанный на изложении соответствия ОО этому конкретному требованию. Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ". Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО". ASE_SRE.1 Задание по безопасности, требования безопасности ИТ, сформулированные в явном виде, требования оценки. Зависимости: ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки. Элементы действий разработчика: ASE_SRE.1.1D Разработчик должен представить изложение требований безопасности ИТ как часть ЗБ. ASE_SRE.1.2D Разработчик должен представить логическое обоснование требований безопасности. Элементы содержания и представления свидетельств: ASE_SRE.1.1С Все требования безопасности ОО, которые сформулированные в явном виде без ссылки на ГОСТ Р ИСО/МЭК 15408, должны быть идентифицированы. ASE_SRE.1.2С Все требования безопасности для среды ИТ, сформулированные в явном виде без ссылки на ГОСТ Р ИСО/МЭК 15408, должны быть идентифицированы. ASE_SRE.1.3С Свидетельство должно содержать строгое обоснование, почему требования безопасности должны быть сформулированы в явном виде. ASE_SRE.1.4С Сформулированные в явном виде требования безопасности ИТ должны использовать компоненты, семейства и классы требований ГОСТ Р ИСО/МЭК 15408 как образец для представления. ASE_SRE.1.5С Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, что соответствие или несоответствие им ОО может быть определено и последовательно продемонстрировано. ASE_SRE.1.6С Сформулированные в явном виде требования безопасности ИТ должны быть четко и недвусмысленно выражены. ASE_SRE.1.7С Логическое обоснование требований безопасности должно демонстрировать, что требования доверия применимы и пригодны для поддержки каждого из сформулированных в явном виде функциональных требований безопасности ОО. Элементы действий оценщика: ASE_SRE.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. ASE_SRE.1.2Е Оценщик должен определить, что все зависимости сформулированных в явном виде требований безопасности ИТ были идентифицированы. 3.12.8 Краткая спецификация ОО (ASE_TSS) Цель: краткая спецификация ОО предоставляет определение в самом общем виде функций безопасности, заявленных для удовлетворения функциональных требований, и мер доверия, выбранных для удовлетворения требований доверия. Замечания по применению: отношение между функциями безопасности ИТ и функциональными требованиями безопасности ОО может быть отношением типа "многие ко многим". Тем не менее, каждая функция безопасности должна способствовать удовлетворению, по меньшей мере, одного требования безопасности, чтобы модно было четко определить ФБО. Функции безопасности, которые не соответствуют этому требованию, обычно необязательны. Заметим, однако, что требование, чтобы функция безопасности способствовала удовлетворению, по меньшей мере, одного требования безопасности, сформулировано в наиболее общем виде с тем, чтобы для всех функций безопасности, которые полезны для ОО, существовала бы возможность обоснования. Изложение мер доверия уместно во всех случаях, когда ЗБ включены требования доверия, не входящие в стандарт. Если требования доверия к ОО в ЗБ основаны исключительно на оценочных уровнях доверия или других компонентах доверия из ГОСТ Р ИСО/МЭК, то меры доверия могут быть представлены в форме ссылки на документы, которые указывают на удовлетворение требований доверия. В компоненте ASE_TSS.1 использованы несколько значений термина "appropriate" ("соответствующий", "необходимый") для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ЗБ. Подробная информация по этим аспектам содержится в приложении В ГОСТ Р ИСО/МЭК 15408-1. ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования ОО. Зависимости: ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки. Элементы действий разработчика: ASE_TSS.1.1D Разработчик должен представить краткую спецификацию ОО как часть ЗБ. ASE_TSS.1.2D Разработчик должен представить логическое обоснование краткой спецификации ОО. Элементы содержания и представления свидетельств: ASE_TSS.1.1С Краткая спецификация ОО должна содержать описание функций безопасности ИТ и мер доверия к ОО. ASE_TSS.1.2С Краткая спецификация ОО должна сопоставить функции безопасности ИТ и функциональные требования безопасности ОО таким образом, чтобы можно было отметить, какие функции безопасности ИТ каким функциональным требованиям безопасности ОО удовлетворяют и что каждая функция безопасности ИТ способствует удовлетворению по меньшей мере одного функционального тебования безопасности ОО. ASE_TSS.1.3С Функции безопасности ИТ должны быть определены в неформальном стиле на уровне детализации, необходимом для понимания их назначения. ASE_TSS.1.4С Все ссылки на механизмы безопасности, включенные в ЗБ, должны быть сопоставлены с соответствующими функциями безопасности так, чтобы можно было отметить, какие механизмы безопасности использованы при реализации каждой функции. ASE_TSS.1.5С Логическое обоснование краткой спецификации ОО должно демонстрировать, что функции безопасности ИТ пригодны для удовлетворения функциональных требований безопасности ОО. ASE_TSS.1.6С Логическое обоснование краткой спецификации ОО должно демонстрировать, что сочетание специфицированных функций безопасности ИТ в совокупности способно удовлетворить функциональные требования безопасности ОО. ASE_TSS.1.7С Краткая спецификация ОО должна сопоставить меры и требования доверия так, чтобы можно было отметить, какие меры способствуют удовлетворению каких требований. ASE_TSS.1.8С Логическое обоснование краткой спецификации ОО должно демонстрировать, что меры доверия удовлетворяют все требования доверия к ОО. ASE_TSS.1.9С Краткая спецификация ОО должна идентифицировать все функции безопасности ИТ, которые реализованы вероятностным или перестановочным механизмом соответственно. ASE_TSS.1.10С Краткая спецификация ОО должна установить для каждой функции безопасности ИТ, для которой необходимо, требование стойкости функции либо по специальной метрике, либо как базовую, либо как среднюю или высокую СФБ. Элемент действий оценщика: ASE_TSS.1.1Е Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. ASE_TSS.1.2Е Оценщик должен подтвердить, что краткая спецификация ОО является полной, логически последовательной и внутренне непротиворечивой. 3.13 Оценочные уровни доверия Оценочные уровни доверия (ОУД), структура которых представлена на рисунке 3.10, образуют возрастающую шкалу, которая позволяет соотнести получаемый уровень доверия со стоимостью и возможностью достижения этой степени доверия. ГОСТ Р ИСО/МЭК 15408 идентифицирует разделенные понятия доверия к объекту по завершению оценки и поддержки этого доверия в процессе эксплуатации ОО. Важно обратить внимание, что не все семейства и компоненты ГОСТ Р ИСО/МЭК 15408 включены в оценочные уровни доверия. Это не означает, что они не обеспечивают значимое и полезное доверие. Напротив, ожидается, что эти семейства и их компоненты будут рассматриваться для усиления ОУД в тех ПЗ и ЗБ, для которых они полезны. В таблице 3.3 представлено сводное описание ОУД. Таблицы представляют иерархически упорядоченный набор ОУД., а строки – семейства доверия. Каждый номер в образованной ими матрице идентифицирует конкретный компонент доверия, применяемый в данном случае. Как показано далее, в ГОСТ Р ИСО/МЭК 15408 определены семь иерархически упорядоченных оценочных уровней доверия для ранжирования доверия к ОО. Каждый последующий ОУД представляет более высокое доверие, чем любой из предыдущих. Увеличение доверия от предыдущего ОУД к последующему достигается заменой какого-либо компонента доверия иерархичным компонентом из того же семейства доверия (т. е. увеличением строгости, области и/или глубины оценки) и добавлением компонентов из других семейств доверия (т. е. добавлением новых требований). ОУД состоят из определенной комбинации компонентов доверия. Точнее, каждый ОУД включает в себя не более одного компонента каждого семейства доверия, а все зависимости каждого компонента доверия учтены. Хотя в стандарта ГОСТ Р ИСО/МЭК 15408 определены именно ОУД, можно представлять другие комбинации компонентов доверия. Специально введенное понятие "усиление" ("augmentation") допускает добавление (из семейства доверия, до этого не включенных в ОУД) или замену компонентов доверия в ОУД (другими иерархичными компонентами из того же самого семейства доверия). Из конструкций установления доверия, определенных в ГОСТ Р ИСО/МЭК 15408, только ОУД могут быть усилены. Понятие "ОУД" за исключением какого-либо составляющего его компонента доверия" не признано в ГОСТ Р ИСО/МЭК 15408 как допустимое выражение. Входящий усиление обязан строго обосновывать полезность и дополнительную ценность, добавленного к ОУД компонента доверия. ОУД может быть также расширен требованиями доверия, сформулированными в явном виде. Следующие пункты содержат определения ОУД с использованием полужирного шрифта для выделения новых требований и их описания. Класс АСМ. управление конфигурацией. Управление конфигурацией (УК) помогает обеспечить сохранение целостности ОО, устанавливая и контролируя определенный порядок процессов уточнения и модификации ОО и предоставления связанной с ними информации. УК предотвращает несанкционированную модификацию, добавление или уничтожение составляющих ОО, обеспечивая тем самым доверие, что оцениваются именно те ОО и документация, которые подготовлены к распространению. Семейство "Автоматизация управления конфигурацией" − ACM_AUT, устанавливает уровень автоматизации, используемый для управления элементами конфигурации. Семейство "Возможности управления конфигурацией" − АСМ_САР, определяет характеристики системы управления конфигурацией. Семейство "Область управления конфигурацией" − АСМ_SCP, указывает на те элементы ОО, для которых необходим контроль со стороны системы управления конфигурацией. Класс ADO. Поставка и эксплуатация. Класс доверия ADO определяет требования к мерам, процедурам и стандартам, применяемым для безопасной поставки, установки и эксплуатации ОО, обеспечивая, чтобы безопасность ОО не нарушалась во время его распространения, установки и эксплуатации. Семейство "Поставка" − ADO_DEL, распространяется на процедуры, используемые для поддержки безопасности во время передачи ОО пользователю при первоначальной поставке и последующих модификациях. Оно включает в себя специальные продукты или действия, необходимые для демонстрации подлинности поставленного ОО. Такие процедуры и меры – основа обеспечения безопасности ОО во время передачи. Несмотря на то, что при оценке ОО не всегда может быть определено его соответствие требованиям поставки, можно оценить процедуры, предусмотренные разработчиком для распространения ОО пользователям. Семейство "Установка и запуск" − ADO_IGS, предусматривает, чтобы копия ОО была конфигурирована и активизирована администратором так, чтобы показать те же самые свойства защиты, что и у оригинала ОО. Процедуры установки, генерации и запуска предоставляют уверенность в том, что администратор будет осведомлен о параметрах конфигурации ОО и о том, как они способны повлиять на функции безопасности объекта оценки. Класс ADV. Разработка. Класс доверия ADV определяет требования для пошагового уточнения функции безопасности объекта оценки, начиная с краткой спецификации ОО в ЗБ и вплоть до фактической реализации. Каждое из получаемых представлений функции безопасности объекта оценки содержит информацию, помогающую оценщику решить, были ли выполнены функциональные требования к ОО. Семейство "Функциональная спецификация" − ADV_FSP, описывает функцию безопасности объекта оценки, и необходимо, чтобы она была полным и точным отображением функциональных требований безопасности ОО. Функциональная спецификация также детализирует внешний интерфейс ОО. Предполагают, что пользователи ОО взаимодействуют с ФБО через этот интерфейс. Семейство "Проект верхнего уровня" − ADV_HLD − проектная спецификация самого верхнего уровня, которая уточняет функциональную спецификацию ФБО в основных составляющих частях ФБО. Проект верхнего уровня идентифицирует базовую структуру ФБО, а также основные элементы аппаратных, программных и программно-аппаратных средств. Семейство "Представление реализации" − ADV_IMP − наименее абстрактное представление ФБО. Оно фиксирует детализированное внутреннее содержание ФБО на уровне исходного текста, аппаратных средств и т. д. Семейство "Внутренняя структура ФБО" − ADV_INT − требования к внутренней структуре ФБО определяют необходимое внутреннее структурирование ФБО. Семейство "Проект нижнего уровня" − ADV_LLD − детализированная проектная спецификация, уточняющая проект верхнего уровня до уровня детализации, который может быть использован как основа для программирования и/или проектирования аппаратуры. Семейство "Соответствие представлений" − ADV_RCR − демонстрация отображения между всеми смежными парами имеющихся представлений ФБО, от краткой спецификации ОО до наименее абстрактного из имеющихся представлений ФБО. Семейство "Моделирование политики безопасности" − ADV_SPM − структурные представления политик безопасности ПБО, используемые для обеспечения повышенного доверия, что функциональная спецификация соответствует политикам безопасности из ПБО и, в конечном счете, функциональным требованиям безопасности ОО. Это достигается посредством определения соответствия между функциональной спецификацией, моделью политики безопасности и моделируемыми политиками безопасности. Класс AGD. Руководства. Класс доверия AGD определяет требования, направленные на обеспечение понятности, достаточности и законченности эксплуатационной документации, предоставляемой разработчиком. Эта документация, которая содержит две категории информации (для пользователей и администраторов), является важным фактором безопасной эксплуатации ОО. Семейство "Руководство администратора" − AGD_ADM − требованию к руководству администратора способствует обеспечению, что ограничения среды будут поняты администраторами и операторами ОО. Руководство администратора − основное средство, имеющееся в распоряжении разработчика, для предоставления администраторам ОО детальной и точной информации о том, как осуществлять администрирование ОО безопасным способом и эффективно использовать привилегии ФБО и функции защиты. Семейство "Руководство пользователя" − AGD_USP − требования к руководству пользователя способствует обеспечению, что пользователи могут эксплуатировать ОО безопасным способом (например, ограничения пользователя, предусмотренные ПЗ или ЗБ, необходимо четко объяснить и проиллюстрировать). Руководство − как основное средство, имеющееся в распоряжении разработчика, для предоставления пользователям ОО необходимой общей и специфической информации о том, как правильно использовать функции защиты ОО. В руководстве необходимо осветить два аспекта. Во-первых, требуется объяснить, что делают доступные пользователю функции безопасности, и как они будут использоваться, чтобы пользователи имели возможность последовательно и действенно защищать свою информацию. Во-вторых, требуется разъяснить роль пользователя в поддержании безопасности ОО. Класс ALC. Поддержка жизненного цикла. Класс доверия ALC определяет требования доверия посредством принятия для всех этапов разработки ОО четко определенной модели жизненного цикла, включая политики и процедуру устранения недостатков, правильное использование инструментальных средств и методов, а также меры безопасности для защиты среды обработки. Семейство "Безопасность разработки" − ALC_DVS, охватывает физические, процедурные, относящиеся к персоналу и другие меры безопасности, используемые применительно к среде обработки. Оно также содержит требования к физической безопасности местоположения разработки и к контролю за отбором и наймом персонала разработчиков. Семейство "Устранении недостатков" − ALC_FLR, обеспечивает, чтобы недостатки, обнаруженные потребителями ОО, отслеживались и направлялись, пока ОО сопровождается разработчиком. Несмотря на то, что при оценке ОО не может быть принято решение о потенциальном соответствии требованиям устранения недостатков, можно оценить политики и процедуры, которые разработчик предусмотрел для выявления и устранения недостатков и распространения исправлений потребителям. Семейство "Определение жизненного цикла" − ALC_LCD, устанавливает, что технология разработки, используемая разработчиком для создания ОО, включает в себя положения и действия, указанные в требованиях к процессу разработки и поддержке эксплуатации. Уверенность в соответствии ОО требованиям больше, когда анализ безопасности и подготовка свидетельств осуществляются на регулярной основе как неотъемлемая часть процесса разработки и поддержки эксплуатации. В задачи этого семейства не входит предопределение какого-либо конкретного процесса разработки. Семейство "Инструментальные средства и методы" − ALC_TAT, связано с необходимостью определения инструментальных средств разработки, используемых для анализа и создания ОО. Сюда включены требования, относящиеся к инструментальным средствам разработки и опциям этих инструментальных средств, зависящим от реализации. Класс АТЕ. Тестирование. Класс доверия АТЕ устанавливает требования к тестированию, которое демонстрирует, что ФБО удовлетворяют функциональным требованиям безопасности ОО. Семейство "Покрытие" − ATE_COV, имеет дело с полнотой функциональных тестов, выполненных разработчиком для ОО. Оно связано со степенью тестирования функций безопасности ОО. Семейство "Глубина" − ATE_DPT, имеет дело с уровнем детализации, на котором разработчик проверяет ОО. Тестирование функций безопасности основано на увеличивающейся глубине информации, получаемой из анализа представлений ФБО. Семейство "Функциональное тестирование" − ATE_FUN, устанавливает, что ФБО действительно демонстрируют свойства, необходимые для удовлетворения требований своего ЗБ. Функциональное тестирование обеспечивает доверия, что ФБО удовлетворяют, по крайней мере, требованиям выбранных функциональных компонентов. Однако функциональные тесты не устанавливают, что ФБО не выполняют больше, чем от них ожидается. Это семейство сосредоточено на функциональном тестировании, выполняемом разработчиком. Семейство "Независимое тестирование" − ATE_IND, определяет степень выполнения функционального тестирования ОО кем-либо, кроме разработчика (например, третьей стороной). Это семейство повышает ценность тестирования добавлением тестов, которые дополняют тесты разработчика. Класс AVA. Оценка уязвимостей. Класс доверия AVA определяет требования, направленные на идентификацию уязвимостей, которые могу быть активизированы. Особое внимание уделено уязвимостям, которые вносятся при проектировании, эксплуатации, неправильном применении или неверной конфигурации ОО. Семейство "Анализ скрытых каналов" − AVA_ССА, направлено на выявление и анализ непредусмотренных коммуникационных каналов, которые могут применяться для нарушения предписанной ПБО. Семейство "Неправильное применение" − AVA_MSU, позволяет выяснить, способен ли администратор или пользователь, используя руководства, определить, что ОО конфигурирован или эксплуатируется небезопасным способом. Семейство "Стойкость функции безопасности" − AVA_SOF − анализ стойкости направлен на функции безопасности ОО, которые реализованы с помощью вероятностного или перестановочного механизма (например, пароля или хэш-функции). Даже если такие функции нельзя обойти, отключить или исказить, не исключено, что их все же можно преодолеть прямой атакой. Может быть заявлен уровень или специальная метрика стойкости для каждой из этих функций. Анализ стойкости функции выполняют для принятия решения, отвечают ли такие функции сделанным заявлениям. Например, анализ стойкости механизма пароля может быть, показав достаточность области задания пароля, продемонстрировав, что функция, использующая этот механизм, отвечает заявленной стойкости. Семейство "Анализ уязвимостей" − AVA_VLA, заключается в идентификации недостатков, которые могли быть внесены на различных этапах разработки. В результате определяются тесты проникновения, позволяющие получить всю совокупность необходимой информации относительно: полноты ФБО (противостоят ли ФБО всем ожидаемым угрозам?); зависимостей между всеми функциями безопасности. Эти потенциальные уязвимости оценивают посредством тестирования проникновения, позволяющим сделать заключение, могут ли они в действительности быть использованы для нарушения безопасности ОО. 3.13.1 Оценочный уровень доверия 1 (ОУД1) Оценочный уровень доверия 1 (ОУД1) предусматривает функциональное тестирование. Цель: ОУД1 применим, когда требуется некоторая уверенность в правильном функционировании, а угрозы безопасности не рассматриваются как серьезные. Он будет полезен там, где требуется независимо полученное доверие утверждению, что было уделено должное внимание защите персональных данных или подобной информации. ОУД1 обеспечивает оценку ОО в том виде, в котором он доступен потребителю, путем независимого тестирования на соответствие спецификации и экспертизы представленной документации. Предполагается, что оценка может успешно проводиться без помощи разработчика ОО и с минимальными затратами. При оценке на этом уровне следует представить свидетельство, что ОО функционирует в соответствии с документацией и предоставляет приемлемую защиту против идентифицированных угроз. Компоненты доверия: ОУД1 (см. таблицу 3.2) предоставляет базовый уровень доверия посредством анализа функций безопасности с использованием для понимания режима безопасности функциональных спецификации, спецификации интерфейсов и руководств. Анализ поддержан независимым тестированием функции безопасности объекта оценки. Этот ОУД обеспечивает значимое увеличение доверия по сравнению с неоцененным продуктом или системой ИТ. 3.13.2 Оценочный уровень доверия 2 (ОУД2) Оценочный уровень доверия 2 (ОУД2) предусматривает структурное тестирование. Цель: ОУД2 содержит требование сотрудничества с разработчиком для получения информации о проекте и результатах тестирования, но при этом не следует требовать от разработчика усилий, превышающих обычную коммерческую практику. Следовательно, не требуется существенного увеличения стоимости или затрат времени. Поэтому ОУД2 применим в случаях, когда разработчикам или пользователям требуется независимо подтверждаемый уровень доверия от невысокого до умеренного при отсутствии доступа к полной документации по разработке. Такая ситуация может возникать при обеспечении безопасности разработанных ранее (наследуемых) систем или при ограниченной доступности разработчика. Компоненты доверия: ОУД2 (см. таблицу 3.4) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональных спецификации, спецификации интерфейсов, руководств и проекта ОО верхнего уровня. Анализ поддержан независимым тестированием функций безопасности объекта оценки, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций и свидетельством поиска разработчиком явных уязвимостей (например, из общедоступных источников). ОУД2 также обеспечивает доверие посредством списка конфигурации ОО и свидетельства безопасных процедур поставки. Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД1, требуя тестирование и анализ уязвимостей разработчиком, а также независимое тестирование, основанное на более детализированных спецификациях ОО. 3.13.3 Оценочный уровень доверия 3 (ОУД3) Оценочный уровень доверия 3 (ОУД3) предусматривает методическое тестирование и проверку. Цель: ОУД3 позволяет добросовестному разработчику достичь максимального доверия путем применения надлежащего проектирование безопасности без значительного изменения существующей практики качественной разработки. ОУД3 применим в тех случая, когда разработчикам и пользователям требуется независимо подтверждаемый умеренный уровень доверия на основе всестороннего исследования ОО и процесса его разработки без существенных затрат на изменение технологии проектирования. Компоненты доверия: ОУД3 (см. таблицу 3.5) обеспечивает доверие путем анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, спецификации интерфейсов, руководства и проекта ОО верхнего уровня. Анализ поддержан независимым тестированием функции безопасности объекта оценки, свидетельством разработчика об испытаниях, основанных на функциональной спецификации и проекте верхнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций и свидетельством поиска разработчиком явных уязвимостей (например, из общедоступных источников). ОУД3 также обеспечивает доверие посредством использования контроля среды разработки, управления конфигурацией ОО и свидетельства безопасных процедур поставки. Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД2, требуя более полного покрытия тестированием функций и механизмов безопасности и/или процедур безопасности, что дает некоторую уверенность в том, что в ОО не будут внесены искажения во время разработки. 3.13.4 Оценочный уровень доверия 4 (ОУД4) Оценочный уровень доверия 4 (ОУД4) предусматривает методическое проектирование, тестирование и углубленную проверку. Цель: ОУД4 позволяет разработчику достичь максимального доверия путем применения надлежащего проектирования безопасности, основанного на обычной коммерческой практике разработки, которая, даже будучи строгой, не требует глубоких специальных знаний, навыков и других ресурсов. ОУД4 – самый верхний уровень, на который, вероятно, экономически целесообразно ориентироваться при оценке уже существующих продуктов. Поэтому ОУД4 применим, когда разработчикам и пользователям требуется независимо подтверждаемый уровень доверия от умеренного до высокого в ОО общего назначения и имеется готовность нести дополнительные, связанные с обеспечением безопасности производственные затраты. Компоненты доверия: ОУД4 (см. таблицу 3.6) обеспечивает доверие посредством анализа функций безопасности с использованием режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также подмножества реализации. Доверие дополнительно достигается применением неформальной модели политики безопасности ОО. Анализ поддержан независимым тестированием функции безопасности объекта оценки, свидетельством разработчика об испытаниях, основанных на функциональной спецификации и проекте верхнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с низким потенциалом нападения. ОУД4 также обеспечивает доверие посредством использования контроля среды разработки и дополнительного управления конфигурацией ОО, включая автоматизацию, и свидетельства безопасных процедур поставки. Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД3, требуя более детальное описание проекта, подмножество реализации и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки или поставки. 3.13.5 Оценочный уровень доверия 5 (ОУД5) Оценочный уровень доверия 5 (ОУД5) предусматривает полуформальное проектирование и тестирование. Цель: ОУД5 позволяет разработчику достичь максимального доверия путем проектирования безопасности, основанного на строгой коммерческой практике разработки, поддержанного умеренным применением узко специализированных методов проектирования безопасности. Такие ОО будут, вероятно, проектироваться и разрабатываться с намерением достичь ОУД5. Скорее всего, дополнительные затраты, сопутствующие требованиям ОУД5 в части строгости разработки, не будут большими без учета применения специализированных методов. Поэтому ОУД5 применим, когда разработчикам или пользователям требуется независимо получаемый высокий уровень доверия для запланированной разработки со строгим подходом к разработке, не влекущим излишних затрат на применение узко специализированных методов проектирования безопасности. Компоненты доверия: ОУД5 (см. таблицу 3.7) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также всей реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО и полуформального представления функциональной спецификации и проекта верхнего уровня, а также полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное проектирование ОО. Анализ поддержан независимым тестированием функции безопасности объекта оценки, свидетельством разработчика об испытаниях, основанных на функциональной спецификации и проекте верхнего уровня и проекте нижнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с умеренным потенциалом нападения. Анализ также включает в себя проверку правильности анализа разработчиком скрытых каналов. ОУД5 также обеспечивает доверие посредством использования контроля среды разработки и всестороннего управления конфигурацией ОО, включая автоматизацию, и свидетельства безопасных процедур поставки. Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД4, требуя полуформальное описание проекта, полную реализации, более структурированную (и, следовательно, лучше анализируемую) архитектуру, анализ скрытых каналов и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки. 3.13.6 Оценочный уровень доверия 6 (ОУД6) Оценочный уровень доверия 6 (ОУД6) предусматривает полуформальную верификацию проекта и тестирование. Цель: ОУД6 позволяет разработчикам достичь высокого доверия путем применения специальных методов проектирования безопасности в строго контролируемой среде разработки с целью получения высококачественного ОО для защиты высоко оцениваемых активов от значительных рисков. Поэтому ОУД6 применим для разработки безопасных ОО с целью применения в ситуациях высокого риска, где ценность защищаемых активов оправдывает дополнительные затраты. Компоненты доверия: ОУД6 (см. таблицу 3.8) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также структурированного представления реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО и полуформального представления функциональной спецификации, проекта верхнего уровня, и проекта нижнего уровня, а также полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное и иерархическое (по уровням) проектирование ОО. Анализ поддержан независимым тестированием функции безопасности объекта оценки, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня и проекте нижнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с высоким потенциалом нападения. Анализ также включает в себя проверку правильности систематического анализа разработчиком скрытых каналов. ОУД6 также обеспечивает доверие посредством использования структурированного процесса разработки, контроля среды разработки и всестороннего управления конфигурацией ОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки. Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД5, требуя всесторонний анализ, структурированное представление реализации, более стойкую структуру (например, с разбиением на уровни), всесторонний независимый анализ уязвимостей, систематическую идентификацию скрытых каналов, улучшенное управление конфигурацией и улучшенный контроль среды обработки. 3.13.7 Оценочный уровень доверия 7 (ОУД7) Оценочный уровень доверия 7 (ОУД7) предусматривает формальную верификацию проекта и тестирование. Цель: ОУД7 применим при разработке безопасных ОО для использования в ситуациях чрезвычайно высокого риска и/или там, где высокая ценность активов оправдывает максимальные затраты. Практическое применение ОУД7 в настоящее время ограничено ОО, которые строго ориентированы на реализацию функциональных возможностей безопасности и для которых возможен подробный формальный анализ. Компоненты доверия: ОУД7 (см. таблицу 3.9) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также структурированного представления реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО, формального представления функциональной спецификации и проекта верхнего уровня, полуформального представления функциональной спецификации и проекта верхнего уровня, полуформального представления проекта нижнего уровня, а также формальной (где это требуется) и полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное, иерархическое (по уровням) и простое проектирование ОО. Анализ поддержан независимым тестированием функции безопасности объекта оценки, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня, проекте нижнего уровня и представлении реализации, полным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с высоким потенциалом нападения. Анализ также включает в себя проверку правильности систематического анализа разработчиком скрытых каналов. ОУД7 также обеспечивает доверие посредством использования структурированного процесса разработки, средств контроля среды разработки и всестороннего управления конфигурацией ОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки. Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД6, требуя всесторонний анализ, использующий формальные представления и формальное соответствие, а также всесторонние тестирование. В РФ нормативными документами по разработке систем защиты информации, средств вычислительной техники и автоматизированных систем являются Руководящие документы Гостехкомисси РФ. До недавнего времени Руководящие документы разрабатывались с учетом международных документов конца 80-х, начала 90-х годов. В июне 1999 года Международной организацией по стандартизации (International Organization Standardization, ISO) при содействии ряда стран был принят стандарт “Критерии оценки безопасности информационных технологий” [5], [6], [7] (в научной литературе и в литературе по стандартизации исторически закрепилось название “Общие критерии” (ОК)). В 2001 г. под эгидой Гостехкомисси России был подготовлен стандарт ГОСТ Р ИСО/МЭК 15408-2001 [8], который после соответствующей апробации вступит в силу с 2004 г.. Данный стандарт является механизмом, предназначенным для разработки нормативных документов, позволяющих оценивать средства безопасности информационные технологий (ИТ) определенного назначения. Для обеспечения действия данного стандарта ожидается выпуск целого ряда организационно-методологических документов, определяющих порядок разработки профилей защиты их оценки, регистрации и применения. ОК направлены на обеспечение аутентичности, конфиденциальности, целостности и доступности информации пользователей. Они дают возможность выработки системы требований, критериев и показателей для оценки уровня безопасности информационных технологий. ОК предназначены для пользователей систем ИТ, разработчиков систем ИТ и специалистов, обеспечивающих оценку характеристик безопасности систем ИТ. Для пользователей систем ИТ общие критерии дают возможность использования определенной структуры требований для обеспечения безопасности ИТ. Данные требования формируют профиль защиты. Для разработчиков систем ИТ общие критерии позволяют определить их обязанности и действия при оценке разработанной системы ИТ. ОК описывают действия, которые разработчик систем ИТ должен выполнить с целью обеспечения требований пользователей. 4 Защита информации в сетях с технологией ATM 4.1 Обмен информацией между агентами защиты Установление и поддержание соединений защиты на сетях ATM достаточно сложный и ответственный процесс, который состоит из двух этапов и базируется на протоколе обмена сообщениями защиты (Security Message Exchange, SME) и передаче специальных ячеек защиты OAM (рисунок 4.1). Протокол обмена сообщениями защиты SME используется для: аутентификации агентов между собой; согласования служб защиты между агентами защиты; установления соединения защиты. Возможно два варианта реализации протокола SME. В плоскости управления (с использованием канала сигнализации). В плоскости пользователя (с использованием канала данных, установленного сигнализацией ранее). В первом случае агенты защиты добавляют к сигнальному сообщению информационный элемент служб защиты (Security Services Information Element, SSIE). Во втором случае протокол SME реализуется через установленное соединение между пользователями сети ATM. При этом на время действия протокола обмена сообщениями защиты передача данных пользователей блокируется. В случае если часть элементов сети не поддерживает протокол SME с использованием сигнализации, то допускается комбинированное применение обоих вариантов. То есть, часть сети применяет протокол SME в плоскости управления (сигнализации), а другая в плоскости пользователей. Передача ячеек защиты OAM используется только для поддержания соединений защиты и применяется после завершения протокола SME. 4.1 Защита информации в плоскости пользователя 4.1 Сервисные службы защиты информации плоскости пользователя Аутентификация плоскости пользователя или аутентификация объекта – эта служба отвечает за определение идентичности вызывающего и/или вызываемого пользователей оригиналу. Аутентификация является основной для установления надежных соединений. Данная служба является базовой для остальных служб защиты. Аутентификация может быть как взаимной (симметричной), так и односторонней (асимметричной). В первом случае оба пользователя аутентифицируются друг для друга. При односторонней аутентификации только один пользователь аутентифицируется для другого. Аутентификация обеспечивается через обмен информацией между агентами безопасности, которые обмениваются между собой сообщениями безопасности (Security Message Exchange, SAsme). В свою очередь, обмен сообщениями безопасности возможен либо в плоскости сигнализации, либо в плоскости пользователя. Конфиденциальность плоскости пользователя обеспечивается криптографическими механизмами, которые защищают данные “пользователя” в виртуальных каналах и трактах от несанкционированного вскрытия. Данная служба функционирует на уровне ячеек АТМ. При этом шифруется только пользовательская часть ячейки ATM.Заголовок ячейки передается незашифрованным. Достоверность данных или “оригинальная аутентификация данных” плоскости пользователя обеспечивается механизмом, который позволяет определять умышленную модификацию данных. Данная служба функционирует между пользователями на уровне AAL (для AAL ¾ и AAL 5) и может быть реализована в двух вариантах: достоверность данных без защиты от повторной модификации; достоверность данных с защитой от повторной модификации. В первом случае источник перед передачей добавляет криптографическую характеристику в конце каждой AAL SDU. Эта характеристика вычисляется по всем AAL SDU. Этот вариант реализации достоверности данных полезен для протоколов верхнего уровня, которые обеспечивают свою собственную нумерацию последовательности (например TCP), без добавления заголовка, требуемого для дублирования данной функции на уровне AAL. Второй вариант реализации достоверности данных детектирует и отбраковывает “старые” или “переупорядоченные” AAL-SDU. Это достигается сначала добавлением номера последовательности в конце каждой AAL-SDU, а затем вычислением характеристики для совокупности AAL-SDU, включая номера последовательности. Это характеристика, которая защищает и AAL-SDU и номер последовательности, затем добавляется к общей AAL-SDU (которая включает номер последовательности). Этот метод обеспечивает защиту приложений ATM, которые не осуществляют свою собственную нумерацию последовательности. Контроль доступа плоскости пользователя – это применение набора правил для запроса услуги. Эти правила могут зависеть от атрибутов вызывающего объекта, таких как идентичность, атрибутов соответствующих параметров, таких как целевой адрес, системных атрибутов, таких как время и история предыдущих запросов данным или другими объектами клиента. Правила контроля доступа могут быть предикатом, сформированным всеми этими атрибутами. Если предикат удовлетворен, то запрашиваемая служба (услуга) предоставляется, если предикат не удовлетворен, то запрашиваемая служба не предоставляется. Контроль доступа плоскости пользователя требует механизмов для транспортировки информации контроля доступа, используемой во время установления соединения, так как механизмы внутри компонентов АТМ используют эту информацию, чтобы определить нужно ли предоставлять доступ к соединению. Контроль доступа плоскости пользователя может основываться на метках защиты (например, стандартные метки защиты [10]), идентичности источника или получателя, времени дня, типе службы, полях вышележащего протокола (например, протокол Интернет), или на других параметрах, которые могут быть определены во время установления соединения. Контроль доступа плоскости пользователя обеспечивается на уровне АТМ. 4.2 Службы поддержки Перечисленные в 4.1 службы защиты информации, которые часто называют базисом служб защиты. Помимо данного базиса существуют также службы поддержки, которые необходимы для обеспечения масштабируемости и повышения эффективности базиса служб защиты (Рисунок 4.1): обмен сообщениями защиты и согласование опций защиты обмен ключами обновление ключей инфраструктура сертификации. Обмен сообщениями защиты и согласование. Для того чтобы предоставить большинство служб, описанных выше, должны передаваться сообщения между вовлеченными агентами защиты (SA). Данная спецификация описывает два метода обмена сообщениями защиты – обмен сообщениями по сигнализации UNI 4.0 и обмен сообщениями in-band (т.е. обмен сообщениями защиты по уместному виртуальному каналу плоскости пользователя). Эти методы обмена сообщениями также обеспечивают механизм для согласования опций защиты. Т.к. требования защиты различные для разных организаций, важно обеспечить ассортимент служб защиты, алгоритмов и длительностей ключей, которые соответствуют широкой области потребностей защиты. Кроме того, законы экспорта и/или импорта некоторых стран накладывают ограничения, через которые зашифрованные продукты могут импортироваться/экспортироваться. По этим причинам механизмы защиты АТМ поддерживают множественные службы защиты, алгоритмы и длительности ключей. Для того чтобы агент защиты соответствовал общим параметрам защиты (таким как алгоритмы и длительности ключей), эти методы обмена сообщениями защиты обеспечивают согласование этих параметров как часть процедуры установления защиты для VC. Обмен ключами – это механизм, посредством которого два агента защиты обмениваются секретными ключами для служб конфиденциальности и/или достоверности. Для того чтобы противостоять атакам типа “человек в середине”, обмен ключом обычно связан со службой аутентификации. Это может быть осуществлено путем включения “конфиденциального” ключа внутри параметров обмена потоков аутентификации. Также как аутентификация, обмен ключом представлен и для симметричных (секретный ключ) и для асимметричных (публичный ключ) алгоритмов. Кроме того, обмен ключом может быть двунаправленным (два пути) и однонаправленным (один путь). Обновление ключа сеанса. Ключи сеанса – это ключи, используемые напрямую для обеспечения служб конфиденциальности и достоверности плоскости пользователя через виртуальные каналы АТМ. Так как скорость данных может быть высокой в VC, крайне необходимо периодически менять ключи, чтобы избежать “повторного использования ключа”. Данная спецификация определяет службу обновления ключа сеанса, которая обеспечивает эту возможность. Эта служба представлена в двух фазах – фаза обмена ключом сеанса и фаза смены ключа сеанса. Фаза обмена ключом сеанса использует “мастер ключ”, которым обмениваются при установлении соединения (используя службу обмена ключом), чтобы зашифровать новый ключ сеанса. При приеме зашифрованного ключа сеанса, приемник расшифровывает ключ сеанса, используя общий мастер ключ, и сохраняет его для второй фазы – смены ключа. Инфраструктура сертификации. В криптосистеме публичного ключа каждая сторона (агент защиты) Х имеет пару ключей: один – публично известный – “публичный ключ” Х (РКХ), и другой, известный только Х – “приватный ключ” Х (SKX). Для того, чтобы сторона А послала секретную информацию стороне В (или чтобы сторона могла проверить характеристику, переданную стороной В), А должна получит публичный ключ В, РКВ. Хотя РКВ – публичный, по определению, никакая сторона Х не должна иметь возможность заменить РКВ на другой (например РКХ). Чтобы предотвратить такого рода воздействия, публичным ключом можно обмениваться в форме “сертификата”. Сертификат содержит имя стороны, ее публичный ключ и некоторую дополнительную информацию и обозначается доверяющей стороной, “орган сертификации” (СА). Эта характеристика жестко связывает публичный ключ с предметной стороной. Любая сторона, имеющая доступ к публичному ключу СА может проверять подлинность сертификата (путем проверки характеристики СА в сертификате) и использовать публичный ключ, который сертифицирован. Один раз отмеченные сертификаты могут передаваться через коммутаторы сообщений не поддерживающие защиту. 4.2 Защита информации плоскости управления 4.2 Сервисные службы защиты информации плоскости управления Плоскость контроля – это механизм, который позволяет устройствам конфигурировать сеть, чтобы добиться определенных целей (например, установить коммутируемый виртуальный канал). Так как сообщение плоскости контроля могут влиять на состояние и работоспособность сети, их защита крайне важна. В данной спецификации защиты определен механизм сигнализации, который может обеспечить устойчивую криптографическую достоверность данных с защитой от повторного воспроизведения/переупорядочивания. Этот механизм позволяет объектам плоскости контроля АТМ проверять источник и содержимое сигнальных сообщений до того, как этот источник выделяется по запросу. Аутентификация и достоверность плоскости контроля – это службы защиты АТМ, которые увязывают сообщения сигнализации АТМ с его источником. Путем создания такой увязки, получатель сообщения может конфиденциально проверить, что сообщение было отправлено именно заявленным источником. Это обеспечивает механизм, который снижает количество воздействий. Например, воздействия, направленные на разрыв активного соединения путем скрытого ввода сообщений RELEASE или DROP PARTY, могут быть предотвращены, если для канала сигнализации обеспечена аутентификация. Эта служба также защищает и от умышленной модификации. В данной спецификации определен механизм аутентификации достоверности плоскости контроля между соседними объектами сигнализации. Используемый механизм идентичен механизму, применяемому для достоверности данных с защитой от повторного воспроизведения/переупорядочивания для плоскости пользователя. приложение 1 англо-русский словарь A Access control Authentication Контроль доступа Аутентификация C Certification authority Ciphertext interface Confidentiality Cryptographic system Орган сертификации Интерфейс зашифрованного текста Конфиденциальность Криптографическая система D DES DH DSA DSS Digital signature Data Encryption Standard Diffie-Hellman Digital Signature Algorithm Digital Signature Standard Цифровая подпись Стандарт шифрования данных Алгоритм совпадения ключа Алгоритм цифровой подписи Стандарт цифровой подписи E ECB ECC ECKAS-DH ECDSA-like ESIGN Electronic CodeBook Elliptic Curve Cryptosystem Elliptic Curve Key Agreement Scheme - Diffie-Hellman Elliptic Curve Digital Signature Algorithm Efficient digital SIGNature scheme Электронная книга кодов Криптосистема с эллиптической характеристикой Схема совпадения ключей с эллиптической характеристикой Diffie-Hellman Алгоритм цифровой подписи с эллиптической характеристикой Эффективная схема цифровой подписи F FEAL Fast Data Encipherment Algorithm Алгоритм быстрого шифрования данных H HMAC H-SHA and H-SHA-1 Hashed Message Authentication Code HMAC using the SHA-1 hash algorithm Кэшированный код аутентификации сообщений HMAC, использующий кэш-алгоритм SHA -1 I ISO In-Band Message Exchange Initiator Integrity International Organization Standardization Обмен сообщениями в полосе Инициатор Достоверность Международная организация по стандартизации K Key Key Exchange Ключ Обмен ключом L LIJ Leaf Initiated Join Наращивание, инициируемое получателем информации M MAC Message Authentication Code Код аутентификации сообщений N NIST (U.S.) National Institute of Standards and Technology (США) Национальный институт стандартов и технологий P Packet-filtering Router Plaintext Interface Private Key Protection Profile Proxy Server Public Key Маршрутизатор фильтрующий пакеты Интерфейс обычного текста Приватный ключ Профиль защиты Прокси - сервер Ключ общего пользования R Replay Prevention Responder Предотвращение повторного воспроизведения Отвечающий S SA SAS SHA-1 SME SSCOP SSIE Security Agent Security Association Security Association Section Security Function Security Target Secure Hash Algorithm (Revision 1) Secret Key Security Message Exchange Security Negotiation Service Specific Connection Oriented Protocol Signaling-Based Message Exchange Security Services Information Element Strength of Function Агент защиты Соединение защиты Секция защиты связи Функция безопасности Задание по безопасности Защитный кэш-алгоритм (первая редакция) Секретный ключ Обмен сообщением защиты Согласование защиты Служебно-ориентированный протокол с установлением соединения Обмен сообщениями, основанный на сигнализации Информационный элемент служб защиты Стойкость функции безопасности T Target of evaluation Target of Evaluation Security Policy Объект оценки Политика безопасности объекта оценки Список сокращений ВК ВТ ИВК ИВТ ИТ МСЭ-Т ОК ТПС УИ УК УП Виртуальный Канал Виртуальный Тракт Идентификатор Виртуального Канала Идентификатор Виртуального Тракта Информационная Технология сектор по стандартизации Телекоммуникаций Международного Союза Электросвязи Общие Критерии Тракт Передачи Сообщения Узел-Источник Узел Коммутации Узел-Получатель Cписок литературы Федеральный закон “Об информации, информатизации и защите информации” принят Государственной Думой 25 января 1995 г. № 24 – ФЗ. ГОСТ Р 50922-96. Защита информации. Основные термины и определения. Новиков С.Н. Методы маршрутизации в цифровых широкополосных сетях связи: Ч. 1 / Учебное пособие. ¾ Новосибирск: 2001.¾ 84 с.: ил. Новиков С.Н. Методы маршрутизации в цифровых широкополосных сетях связи: Ч. 2 / Учебное пособие. ¾ Новосибирск: 2002.¾ 62 с.: ил. Evaluation Criteria for IT Security. Part 1: Introduction and general model. -- ISO/IEC 15408-1: 1999, 1999 Evaluation Criteria for IT Security. Part 2: Security functional requirements. -- ISO/IEC 15408-2: 1999, 1999 Evaluation Criteria for IT Security. Part 3: Security assurance requirements. - ISO/IEC 15408-3: 1999, 1999 ГОСТ Р ИСО/МЭК 15408-2002. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий (часть 1, часть 2, часть3). ATM Security Specification Version 1.0 ¾ ATM Forum ¾ af-sec-0100.000, february, 1999. ATM Security Specification Version 2.0 ¾ ATM Forum ¾ af-sec-0100.002, february, 2002. Иванов М.А. Криптографические методы защиты информации в компьютерных системах и сетях. М.: КУДИЦ-ОБРАЗ, 2001 – 368 с. ITU-T Recommendation X.509 “The Directory: Authentication Framework”, 1993. Interim Inter-switch Signaling Protocol (IISP) Specification v1.0 ¾ ATM Forum ¾ af-pnni-0026.000, december, 1994. 13.1 Canadian Trusted Computer Product Evaluation Criteria, Version 3.0, Canadian System Security Center, Communications Security Establishment, Government of Canada, January 1993. 13.2 Federal Criteria for Information Technology Security, Draft Version 1.0, (Volumes I and II), jointly published by the National Institute of Standards and Technology and the National Security Agency, US Government, January 1993. 13.3 Information technology — Security techniques — Evaluation Criteria for IT Security. Part 1: Introduction and general model. ISO/IEC 15408-1:1999. 13.4 Information technology — Security techniques — Evaluation Criteria for IT Security. Part 2: Security functional requirements. ISO/IEC 15408-2:1999. 13.5 Information technology — Security techniques — Evaluation Criteria for IT Security. Part 3: Security assurance requirements. ISO/IEC 15408-3:1999. 13.6 Information Technology Security Evaluation Criteria, Version 1.2, Office for Official Publications of the European Communities, June 1991. 13.7 Trusted Computer Systems Evaluation Criteria, US DoD 5200.28-STD, December 1985. 13.8 ГОСТ Р ИСО/МЭК 15408-1-2002 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель. 13.9 ГОСТ Р ИСО/МЭК 15408-2-2002 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности. ГОСТ Р ИСО/МЭК 15408-3-2002 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности. оглавление