Книга: Методы оценки несоответствия средств защиты информации

А.С. Марков, В.Л. Цирлов, А.В. Барабанов

Методы оценки

несоответствия средств

защиты информации

Москва

«Радио и связь»

2012

УДК 621.322

ББК 32.973

М26

Рецензенты:

Академик РАН, д-р техн.наук, проф. Ю. В. Бородакий

Член-корр. РАН, д-р техн.наук, проф. Р. М. Юсупов

Марков А. С., Цирлов В. Л., Барабанов А. В.

М26 Методы оценки несоответствия средств защиты информа-

ции / А. С. Марков, В. Л. Цирлов, А. В. Барабанов; под ред. доц.

А. С. Маркова. — М.: Радио и связь, 2012. — 192 с.

ISBN 5-89776-015-2

Книга подготовлена экспертами испытательной лаборатории «Эшелон»

как обобщение опыта исследований в области безопасности информационно-

программных ресурсов. Содержит метрики, модели и формальные методики

испытаний средств защиты информации и тестирования безопасности про-

граммного обеспечения, а также актуальные нормативные и правовые требо-

вания по сертификации средств защиты информации.

Для специалистов и ученых, увлеченных анализом защищенности, ауди-

том, испытаниями и тестированием средств защиты информации, программ-

ных продуктов и систем в защищенном исполнении.

Совместное издание:

Издательство «Радио и связь»

www.radiosv.ru

НПО «Эшелон»

www. cnpo.ru

ISBN 5-89776-015-2

СОДЕРЖАНИЕ

Перечень сокращений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1. ОСНОВЫ ОЦЕНКИ СООТВЕТСТВИЯ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1. Определение оценки соответствия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2. Виды процедур оценки соответствия технических систем . . . . . . . . . . . . 13

1.2.1. Испытания. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.2. Аттестационные испытания . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2.3. Тестирование программных средств . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.2.4. Аудит информационной безопасности . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.2.5. Анализ риска информационной безопасности . . . . . . . . . . . . . . . . . . 20

2. СЕРТИФИКАЦИЯ СРЕДСТВ ЗАЩИТЫ ИНФОРМАЦИИ . . . . . . . . . . 24

2.1. Определение сертификации средств защиты информации . . . . . . . . . . . 24

2.2. Правила и участники сертификации средств защиты информации. . . . 26

2.3. Законодательно-правовые основы сертификации . . . . . . . . . . . . . . . . . . . . 29

2.4. Традиционные руководящие документы Гостехкомиссии России. . . . . . 33

2.4.1. Классы защищенности средств вычислительной техники . . . . . . . 34

2.4.2. Классы защищенности межсетевых экранов . . . . . . . . . . . . . . . . . . . . 37

2.4.3. Классы защищенности автоматизированных систем . . . . . . . . . . . . 37

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

2.5. Требования к защите персональных данных . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.6. Требования к защите информационных систем общего пользования. . 46

2.7. Общие критерии оценки безопасности информационных технологий. 47

2.7.1. Модель критериев оценки безопасности информационных

технологий. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.7.2. Функциональные требования безопасности . . . . . . . . . . . . . . . . . . . . 51

2.7.3. Требования доверия к безопасности . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.7.4. Общая методология оценки безопасности

информационных технологий . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2.8. Современные нормативные документы ФСТЭК России . . . . . . . . . . . . . . . 73

2.8.1.Требования к системам обнаружения вторжений. . . . . . . . . . . . . . . . 74

2.8.2. Требования к средствам антивирусной защиты. . . . . . . . . . . . . . . . . 79

3. МЕТРИКИ И МОДЕЛИ ИСПЫТАНИЙ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.1. Показатели и метрики испытаний . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.1.1. Виды показателей объекта испытаний. . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.1.2. Метрики сложности программного кода. . . . . . . . . . . . . . . . . . . . . . . . 87

Содержание

3.1.3. Метрики покрытия программного кода . . . . . . . . . . . . . . . . . . . . . . . . 92

3.1.4. Метрики полноты функционального тестирования . . . . . . . . . . . . . 95

3.2. Модели оценки технологической безопасности и планирования

испытаний . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3.2.1. Отладочные модели программ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.2.2. Модели роста надежности от времени. . . . . . . . . . . . . . . . . . . . . . . . . 104

3.2.3. Модели полноты тестирования . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

3.2.4. Модели сложности программного обеспечения. . . . . . . . . . . . . . . . 120

3.2.5. Выбор модели оценки и планирования испытаний . . . . . . . . . . . . 122

3.3. Модели управления доступом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

3.3.1. Дискреционная модель управления доступом. . . . . . . . . . . . . . . . . . 125

3.3.2. Мандатная модель управления доступом . . . . . . . . . . . . . . . . . . . . . . 128

3.3.3. Ролевая модель управления доступом . . . . . . . . . . . . . . . . . . . . . . . . . 131

3.3.4. Атрибутная модель управления доступом. . . . . . . . . . . . . . . . . . . . . . 133

3.4. Метрики парольных систем . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

3.5. Модели периодического инспекционного контроля . . . . . . . . . . . . . . . . . 138

3.5.1. Модели инспекционного контроля средств защиты информации. . . . . . 139

3.5.2. Модели инспекционного контроля сред функционирования . . . 142

4. МЕТОДИКИ СЕРТИФИКАЦИОННЫХ ИСПЫТАНИЙ . . . . . . . . . . . . 145

4.1. Формальный базис испытаний

средств защиты информации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

4.2. Методика испытаний средств

вычислительной техники . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

4.2.1. Методика проверки дискреционного принципа контроля до-

ступа. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

4.2.2. Методика проверки мандатного принципа контроля доступа . . 151

4.2.3. Методика проверки механизмов очистки памяти . . . . . . . . . . . . . . 153

4.2.4. Методика проверки механизмов изоляции модулей . . . . . . . . . . . . 154

4.2.5. Методика проверки механизмов идентификации и аутенти-

фикации субъектов доступа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

4.2.6. Методика проверки механизмов контроля целостности. . . . . . . . 156

4.3. Методика испытаний межсетевых экранов. . . . . . . . . . . . . . . . . . . . . . . . . . 157

4.3.1. Проверка механизмов фильтрации данных и трансляции

адресов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

4.3.2. Проверка механизмов идентификации и аутентификации

администраторов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

4.3.3. Проверка механизмов контроля целостности. . . . . . . . . . . . . . . . . . 161

4.4. Методика испытаний автоматизированных систем. . . . . . . . . . . . . . . . . . 163

4.4.1. Методика проверки механизмов идентификации и аутенти-

фикации субъектов доступа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

4.4.2. Методика проверки механизмов управления доступом . . . . . . . . . 166

4.4.3. Методика проверки механизмов контроля целостности. . . . . . . . 166

4.5. Методика проведения испытания по требованиям «Общих крите-

риев» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

4.6. Рекомендации по оптимизации испытаний . . . . . . . . . . . . . . . . . . . . . . . . . 171

4.7. Рекомендации по контролю отсутствия недекларированных воз-

можностей . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

4.7.1. Общий порядок проведения испытаний . . . . . . . . . . . . . . . . . . . . . . . 173

4.7.2. Рекомендации по контролю наличия заданных конструкций . . . 180

Литература. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

АС

Автоматизированная система

АРМ

Автоматизированное рабочее место

ГИР

Государственный информационный ресурс

ЗБ

Задание по безопасности

ИБ

Информационная безопасность

ИСОП

Информационные системы общего пользования

ИСПДн

Информационная система персональных данных

ИТ

Информационная технология

КСЗ

Комплекс средств защиты

МЭ

Межсетевой экран

НДВ

Недекларированная возможность

НСД

Несанкционированный доступ

ОИ

Объект информатизации

ОК

Общие критерии

ОМО

Общая методология оценки

ОО

Объект оценки

ОУД

Оценочный уровень доверия

ПБО

Политика безопасности объекта оценки

ПДИТР Противодействие иностранным техническим развед-

кам

ПЗ

Профиль защиты

ПО

Программное обеспечение

ПОК

Потенциально опасная конструкция

ПРД

Правила разграничения доступом

ПС

Программное средство

РД

Руководящий документ

САВЗ

Средство антивирусной защиты

Перечень сокращений

СБФ

Стойкость функции безопасности

СВТ

Средство вычислительной техники

СЗИ

Средство защиты информации

СКЗИ

Средства криптографической защиты информации

СОВ

Система обнаружения вторжений

СП

Сообщения о проблемах

СРД

Система разграничения доступом

СФБ

Стойкость функции безопасности

ТЗ

Техническое задание

ТУ

Технические условия

ФБ

Функция безопасности

ФБО

Функции безопасности объекта оценки

ФТБ

Функциональные требования безопасности

ПРЕДИСЛОВИЕ

«Тестирование программы может эффективно проде-

монстрировать наличие ошибок, но безнадежно неа-

декватно для демонстрации их отсутствия».

Дейкстра Э. В. «Смиренный программист»

«А что, при сертификации можно что-то найти?»

Форум руководителей испытательных лабораторий

Идея написания книги связана с опытом авторов в области вы-

явления разного рода дефектов, уязвимостей и угроз безопасности

информационно-программных систем и механизмов их защиты.

Данный опыт был получен в процессе сертификационных и госу-

дарственных испытаний, тематических исследований и аудита без-

опасности более 500 средств защиты информации, продуктов, пор-

талов и систем в защищенном исполнении ведущих зарубежных

и отечественных разработчиков.

Необычайный эволюционный рост сложности и динамично-

сти ИТ-продукции показал не только неотвратимость, но и гиперс-

ложность оценки соответствия ИТ-продукции требованиям по без-

опасности информации. Несмотря на героические усилия ведущих

разработчиков, проблема безопасности программных систем не по-

лучила своего окончательного решения: число критических уязви-

мостей не уменьшается, а процесс анализа кода становится чрезвы-

чайно сложной задачей, которую необходимо перманентно решать

в рамках периода жизненного цикла программной системы [63, 75,

94]. В этом плане основным механизмом управления информацион-

ной безопасностью систем остается сертификация средств защи-

ты информации, эффективность которой в реальной жизни пока

зависит от предельной организованности и мозгового штурма экс-

пертов испытательных лабораторий и органов по сертификации.

Поэтому применение адекватных методов, метрик и методических

приемов может быть весьма полезно, что и является основной це-

лью подготовки монографии.

Кроме факторов технической эволюции, следует отметить не-

обычайный социальный интерес к данной проблеме, отмеченный

в нашей стране за последние несколько лет, например, достаточно

упомянуть несколько общественных явлений:

Предисловие

— вступление страны в ВТО и неотвратимость исполнения За-

кона «О персональных данных» глубоко изменили отношение всех

юридических лиц страны к защите информации конфиденциально-

го характера со всеми вытекающими последствиями;

— открытая публикация новейших нормативных документов

ФСТЭК России, ФСБ России и других регуляторов инициировала

всеобщее информирование и внедрение новых современных мето-

дологий, методов и средств защиты информации в различных сег-

ментах ИТ-области;

— диалектическое возникновение «сертификационных войн»

побудило разработчиков средств защиты к соблюдению правил

сертификации на российском рынке компьютерной безопасности

и даже раскрытию ведущими западными компаниями (Microsoft,

IBM, Oracle, SAP и др.) тайн их исходного кода.

Предлагаемая книга включает 4 главы.

В первой главе дается определение оценки соответствия на ос-

нове серии международных стандартов. В ней также описаны про-

цедуры оценки соответствия в области информационной безопас-

ности.

Во второй главе представлено подробное описание понятия

сертификации средств защиты информации, ее законодательных

и нормативных основ.

Третья глава касается применения математических моделей

и методов, которые могут быть использованы при формальных до-

казательствах результатов испытаний, а также при планировании

работ.

В четвертой главе приводятся формализованные методики ис-

пытаний средств и механизмов защиты информации по требовани-

ям традиционных и новейших нормативных документов.

Историческая научная база.

Следует сказать, что книга родилась не в вакууме. Среди от-

крытых публикаций советских и российских ученых в области сер-

тификации программ наиболее известны работы п р о ф е с с о р о в

Л. Г. Осовецкого [88], В. В. Липаева и А.И.Костогрызова [44], в обла-

сти оценки надежности программного обеспечения — В. А. Смагина

[76], А. Д. Хомоненко [90], Л. В. Уткина [99], статистической теории

защиты информации — В. А. Герасименко [22], испытаний комплек-

Предисловие

сов автоматизации — А. С. Шаракшанэ и А.К.Халецкого [86], тести-

рования подпрограмм — Б. А. Позина [98] и других.

В этом же плане авторы выражают большую благодарность уче-

ным с мировым именем, основательно поддержавшим работу в ка-

честве рецензентов по тематике, а именно: академику РАН Ю. В. Бо-

родакию [16] и член-корр. РАН Р. М. Юсупову [70].

Авторы также признательны за ценные указания и мудрые со-

веты научным кураторам: доцентам В. А. Керножицкому, В. В. Кова-

леву, М. М. Котухову и профессору И. А. Шеремету, всем коллегам,

активно участвующим в научных мероприятиях, в особенности: до-

центам И. В. Зубареву, И. В. Рауткину, А. Ю. Добродееву, В. Г. Масло-

ву, экспертам С. А. Щербине и А.А. Лоскутову, руководству и безза-

ветным рыцарям науки кафедр «Информационная безопасность»

МГТУ им. Н. Э. Баумана и «Программирование» ВКА им. А. Ф. Мо-

жайского, всем неутомимым исследователям НПО «Эшелон», а так-

же своим ученым родителям.

Само собой, эта книга была бы невозможна без конструктивно-

го диалога, позитивизма и поддержки со стороны экспертов регу-

лирующих органов и служб. В этой связи авторы выражают самую

глубокую признательность руководству и профессионалам феде-

рального и ведомственных органов по сертификации Генерального

Штаба ВС РФ и федерального органа по сертификации Федераль-

ной службы по техническому и экспортному контролю.

Монография является результатом коллективного труда.

Помимо авторского коллектива при написании отдельных

подразделов участие принимали: В. В. Вареница (подраздел 4.7.1),

М. И. Гришин (подраздел 4.4) и А.А.Фадин (подразделы 3.1.3 и 4.7.2).

Авторы также выражают благодарность за ценные рекоменда-

ции доценту И. Ю. Шахалову и руководителю испытательной лабо-

ратории М. Ю. Никулину.

Алексей Марков

1. ОСНОВЫ ОЦЕНКИ СООТВЕТСТВИЯ

1.1. Определение оценки соответствия

Под оценкой соответствия понимается доказательство того,

что заданные требования к продукции, процессу, системе, лицу или

органу выполнены 1. Допускается, что доказательство может быть

прямым или косвенным, формальным или неформальным. Выда-

чу документально оформленного заявления (удостоверения) о со-

ответствии заданным требованиям называют подтверждением со-

ответствия. Примерами таких удостоверений могут быть сертифи-

каты, аттестаты, заключения, выданные официальными органами

по оценке соответствия.

Согласно ИСО 17000 базовыми видами деятельности по оценке

соответствия являются:

— испытание,

— контроль,

— сертификация,

— аккредитация органов по оценке соответствия.

Виды деятельности могут включать различные процедуры

по оценке соответствия. В области информационной безопасно-

сти примерами видов деятельности по оценке соответствия или

их процедурами являются сертификация средств защиты инфор-

мации, аттестация объектов информатизации, аккредитация орга-

нов, лабораторий, центров, различные виды испытаний и контро-

ля по требованиям безопасности информации, а также аудит безо-

пасности программных средств, информационных систем и систем

менеджмента информационной безопасности.

С точки зрения независимости доказательства оценки соответ-

ствия различают деятельность трех сторон:

ГОСТ Р ИСО/МЭК 17000—2009.

Основы оценки соответствия

— первая сторона, представляющая объект оценки, например:

разработчик или поставщик;

— вторая сторона, заинтересованная в объекте оценки как ее

пользователь, например, представитель заказчика;

Таблица 1.1

Виды и процедуры оценки соответствия по требованиям

безопасности информации

Лицо, организация, орган

Виды и процедуры

Первая

Вторая

Третья сторона

оценки соответствия

сторона

Объекты оценки соответствия

Предварительные ис-

Проекты, ма-

пытания

кеты, образ-

цы СЗИ

Входной контроль

СЗИ

Приемка

СЗИ

Периодический кон-

СЗИ

троль

Экспертиза

Документы

Сертификация

СЗИ

Аттестация

ОИ*

ОИ

Контроль встраивания

Криптографиче-

ские СЗИ

Декларирование

Документа-

ция

Поверка

Средства изме-

рений

Калибровка

Средства из-

Средства изме-

мерений

рений

Спецэкспертиза

Организации

Аккредитация

Организации

Инспекционный кон-

СЗИ, ОИ, орга-

троль

низации

Аудит

СЗИ, систе-

СЗИ, системы,

мы, органи-

организации

зации

* только для лицензиатов ФСТЭК при защите конфиденциальной инфор-

мации

СЗИ — средства защиты, ОИ — объекты информатизации

Основы оценки соответствия

— третья сторона, независимая от первой и второй сторон, на-

пример, аккредитованная испытательная лаборатория.

К примеру, средства защиты информации подлежат оценке со-

ответствия в форме обязательной сертификации. Аккредитован-

ные органы сертификации и испытательные лаборатории, участву-

ющие в процессе сертификации, должны быть независимы от за-

казчика работ, т. е. являться третьими сторонами. В то же время

аттестация объектов информатизации в некоторых случаях может

быть проведена самой организацией, т. е. первой стороной. Под-

тверждение соответствия первой стороной называется деклари-

рованием (декларацией) о соответствии. В таблице 1.1 приведе-

ны примеры видов деятельности и объекты оценки соответствия

по требованиям безопасности информации.

Совокупность участников, правил, процедур и менеджмента,

используемых для выполнения оценки соответствия, представ-

ляет собой систему оценки соответствия. В нашей стране в обла-

сти безопасности информации примерами таких систем являют-

ся обязательные системы сертификации средств защиты инфор-

мации Минобороны России (РОСС RU.0001.01ГШ00), СВР России

(РОСС RU.0001.01СЗ00), ФСБ России (РОСС RU.0003.01БИ00, РОСС

RU.0001.030001) 2 и ФСТЭК России (РОСС RU.0001.01БИ00), а также

добровольные системы сертификации по безопасности информа-

ции.

Международный стандарт ИСО 17000 определяет три функции

оценки соответствия (см.рис.1.1):

1. Выбор, в рамках которого выполняется планирование и под-

готовка к получению доказательств, в том числе определяется мето-

дология оценки и отбирается собственно объект оценки;

2. Определение, в рамках чего проводится исследование харак-

теристик объекта оценки и формируются соответствующие отчет-

ные документы;

3. Итоговая проверка и подтверждение соответствия, в резуль-

тате которых принимается и оформляется решение о соответствии

или несоответствии объекта оценки заданным требованиям.

Важной процедурой оценки соответствия является инспекци-

онный контроль, представляющий собой систематическое наблю-

дение за деятельностью по оценке соответствия.

В области компетенции ФСБ России зарегистрированы две системы сертифи-

кации СЗИ (см. www.fsb.ru).

Основы оценки соответствия

Потребность доказать, что заданные требования выполняются

Выбор

Информация о выбранных

объектах

Информация о выполнении

Определение

заданных требований

Да

Итоговая проверка

Выполнение

Необходимость

и подтверждение

заданных требований

инспекционного

соответствия

доказано

контроля?

Нет

— контур А;

— контур В

КОНЕЦ

Рис. 1.1. Функциональный подход к оценке соответствия по ИСО 17000

Следует сказать, что область определений и терминов по оцен-

ке соответствия имеет весьма размытые рамки. Например, в нацио-

нальном стандарте ГОСТ 17000—2009 под подтверждением соответ-

ствия понимают выдачу документа (заявления) о соответствии или

несоответствии, а в Законе № 184-ФЗ «О техническом регулирова-

нии» понимают вид деятельности: сертификацию или деклариро-

вание соответствия техническому регламенту.

Мы будем придерживаться терминов, используемых в норма-

тивно-методических документах федеральных органов, регулиру-

ющих процессы информационной безопасности, если это не будет

оговорено отдельно.

1.2. Виды процедур оценки соответствия

технических систем

Кроме сертификации средств защиты информации (которая

заслуживает отдельного внимания в разделе 2) можно встретить

Основы оценки соответствия

определения разного рода процедур оценки соответствия техни-

ческих средств и систем защиты, а именно: испытания, аттестация,

тестирование, аудит, анализ рисков.

1.2.1. Испытания

Испытание — вид деятельности или процедура по оценке соот-

ветствия, заключающаяся в экспериментальном определении коли-

чественных или качественных характеристик объекта испытаний

как результата воздействия на него при его функционировании, мо-

делировании или воздействий 3.

Испытания проводятся на основании документа «Программа

и методика испытаний», который разрабатывается в испытатель-

ной лаборатории и оформляется согласно национальным стандар-

там (ГОСТ 19.301—79, РД 50—34.698—90, ГОСТ 51719—2001 и др.).

Результаты испытания оформляются в виде протоколов испы-

таний или технического отчёта.

Как правило, испытания по требованиям безопасности инфор-

мации проводятся на этапе внедрения. Исключение составляют пе-

риодические испытания.

Различают испытания продукции и систем. Например,

в ГОСТ 16504 приведено 46 видов испытаний продукции: предва-

рительные, доводочные, периодические, государственные, межве-

домственные, стендовые, полигонные, натурные, граничные, атте-

стационные, сертификационные испытания и другие.

Для автоматизированных систем согласно ГОСТ 34.603 (п.1.3.)

установлены 3 основных вида испытаний:

1. Предварительные, которые могут быть автономными и ком-

плексными;

2. Опытная эксплуатация;

3. Приемочные.

Национальные стандарты допускают проведение других видов

испытаний систем и их составных частей.

В области информационной безопасности требования и виды

испытаний устанавливаются уполномоченными государственными

регуляторами, в частности, это касается сертификационных испы-

таний средств защиты информации и аттестационных испытаний

объектов информатизации на соответствие ведомственным норма-

тивным документам.

ГОСТ 16504—1981.

Основы оценки соответствия

1.2.2. Аттестационные испытания

Легитимность обработки информации на объектах информа-

тизации подтверждается путем их аттестации, основное содержа-

ние которой составляют аттестационные испытания, представля-

ющие собой комплексную проверку защищаемого объекта инфор-

матизации в реальных условиях эксплуатации с целью оценки соот-

ветствия применяемого комплекса мер и средств защиты требуемо-

му уровню безопасности информации. Положительный результат

аттестации оформляется в виде аттестата соответствия.

Наиболее полно регламентирована система аттестации объ-

ектов информатизации по требованиям ФСТЭК России. Согласно

правилам ФСТЭК России аттестация является частью единой си-

стемы сертификации и аттестации и касается именно объектов (си-

стем) 4.

При аттестационных испытаниях подтверждается соответ-

ствие объекта информатизации требованиям:

— по защите информации от несанкционированного доступа

(в том числе от компьютерных вирусов),

— от утечки за счет побочных электромагнитных излучений

и наводок при специальных воздействиях на объект (высокочастот-

ное навязывание и облучение, электромагнитное и радиационное

воздействие),

— от утечки или воздействия на нее за счет специальных

устройств, встроенных в объекты информатизации.

Проверки, в принципе, зависят от типа объекта информатиза-

ции, который может быть одним из следующих:

— автоматизированная система (в том числе сегмент АС 5);

— помещение, предназначенное для ведения конфиденциаль-

ных (секретных) переговоров;

— системы связи, отображения и размножения вместе с поме-

щениями, в которых они установлены, предназначенные для обра-

ботки и передачи информации, подлежащей защите.

Надо понимать отличие аттестационных испытаний от серти-

фикационных. Так, аттестационные испытания касаются объектов

информатизации ( систем), проводятся органами по аттестации или

лицензиатами ФСТЭК России (при защите конфиденциальной ин-

формации), включают выполнение стандартных детерминирован-

Приказы Гостехкомиссии России № № 199 (1995), 3 (1996).

ГОСТ 0043—003—2012.

Основы оценки соответствия

ных процедур, связанных, главным образом, с фиксацией состава,

проверкой легитимности и корректности установки сертифициро-

ванных средств защиты информации [24,65,83]. В свою очередь,

сертификационные испытания касаются технических средств за-

щиты информации, проводятся испытательными лабораториями,

включают длительные и трудоемкие процедуры проверки этих

средств, в том числе используя методы функционального и струк-

турного тестирования и др.

Особенности аттестационных испытаний регламентируются

специальными требованиями и рекомендациями, но с Положением

по аттестации (Гостехкомиссии России, 1994 г.) можно ознакомить-

ся на сайте ФСТЭК России [69].

1.2.3. Тестирование программных средств

Согласно международным стандартам тестирование — это тех-

ническая операция, заключающаяся в определении одной или не-

скольких характеристик продукта, процесса или услуги по соответ-

ствующей процедуре 6. Что касается тестирования ПО, то его целью

является выявление ошибок (дефектов, недостатков) в программ-

ной реализации заданных свойств ПО. Особенности современного

производства программ подразумевают, что тестирование интегри-

ровано в систему менеджмента качества ПО на всех этапах жизнен-

ного цикла.

Вследствие невозможности всеобъемлющей проверки совре-

менного ПО, тестирование ПО стало отдельной научно-техниче-

ской дисциплиной 7. Мы коснемся только наиболее важных класси-

фикационных признаков, необходимых при оценке соответствия,

таких как: уровень знаний об исходном коде, методология провер-

ки, структурный уровень проверки, детерминированность тестов,

показатели качества и т.п.

По уровню знаний о структуре ПО различают функциональное

(по принципу черного ящика) и структурное (по принципу белого

ящика) тестирование 8. Функциональное тестирование использу-

ет всевозможные комбинации входных данных, допустимые вход-

ным интерфейсом. Если распределение входных данных прибли-

жено к реальному процессу эксплуатации, можно оценить уровень

ГОСТ Р ИСО/МЭК 12119—2000.

IEEE Guide to SWEBOK, 2004.

ГОСТ Р ИСО/МЭК 12119—2000.

Основы оценки соответствия

корректности и надежности функционирования ПО. Для выявле-

ния ошибок, связанных с комбинациями редко используемых дан-

ных (например, программные закладки), более практичны методы

структурного тестирования.

По методологии проверок различают статическое (без выпол-

нения кода) и динамическое (с выполнением кода) тестирование.

Основу динамического тестирования составляют тесты — наборы

входных данных и условий функционирования.

Статическое тестирование подразумевает либо ручной про-

смотр (инспектирование, ревизия) текста программ, либо автома-

тизированный статический анализ. В последнем случае условно

различают синтаксический анализ свойств программы на ее лек-

сических/синтаксических/семантических моделях, ориентирован-

ный на выявление некорректностей кодирования (нефункциональ-

ных дефектов) [23,39,40,74], и сигнатурный анализ, ориентирован-

ный на поиск фрагментов кода повышенного риска (как правило,

программных закладок) [54,71].

Следует уточнить, что в ряде классификаций под понятие те-

стирование подпадают только динамические методы 9.

Выделяют несколько структурных уровней тестирования, на-

пример:

— модульное (компонентное) тестирование, которое позволя-

ет проверить функционирование отдельно взятого элемента си-

стемы 10, например: модулей, подпрограмм, программных файлов,

драйверов, приложений, веб-приложений, протоколов, программ-

ных интерфейсов;

— интеграционное тестирование путем проверки взаимодей-

ствия между программными компонентами (например, путем ре-

ализации методов «сверху вниз», «снизу вверх», распределения по-

токов управления и данных 11 и т.д.);

— системное тестирование, которое охватывает целиком всю

систему и ее внешние интерфейсы.

Большинство функциональных сбоев должно быть иденти-

фицировано еще на уровне модульных и интеграционных тестов.

В свою очередь, системное тестирование обычно фокусируется на

IEEE Std 829—2008.

10 ANSI/IEEE 1008—1987.

11 IEEE Guide to SWEBOK, 2004.

Основы оценки соответствия

нефункциональных требованиях — безопасности, производитель-

ности, точности, надежности т. п.

По степени детерминированности разделяют стохастическое

и детерминированное (экспертное) тестирование и их комбина-

ции. Для стохастического тестирования применяются генераторы

тестов в заданных границах и областях входных данных, что позво-

ляет автоматизировать процесс тестирования. Наиболее известной

является техника фаззинг-тестирования (fuzzing, fuzz-testing), когда

тесты содержат случайные данные, в том числе искаженные и не-

предусмотренные, получаемые путем псевдослучайной генерации

или мутации входных и промежуточных данных.

Надо понимать, что нерегулируемый стохастический процесс

приводит к переборам входных данных астрономического поряд-

ка [95].

Что касается свойств качества, то известны тестирование кор-

ректности, безошибочности, производительности, безопасности

информации и др. При проверке свойств безопасности информа-

ции (целостности, доступности, конфиденциальности и др.) зада-

ются требования к подсистемам, например, идентификации, аутен-

тификации, разграничения доступом (авторизации), целостности,

протоколирования (аудита, журналирования) и др.

Особенностью тестирования безопасности информации явля-

ется то, что ошибки в ПО могут быть внесены искусственно (напри-

мер, отладочная информация, недекларированные возможности)

или даже злонамеренно (программные закладки). Более того, выяв-

ление возможности реализации этих ошибок может быть тоже це-

ленаправленно злонамеренным. Поэтому, кроме функционального

тестирования подсистем безопасности на соответствие заданным

требованиям, целесообразно проводить структурное тестирование

ПО с целью выявления дефектов и уязвимостей, влияющих на без-

опасность.

С точки зрения отечественной нормативной базы можно выде-

лить следующие техники тестирования [69]:

— функциональное тестирование подсистем безопасности

по требованиям, заданным в нормативных документах и докумен-

тации;

— проверочное и периодическое тестирование подсистем за-

щиты информации, согласно тестовой документации;

— статический анализ отсутствия недекларированных возмож-

ностей;

Основы оценки соответствия

— динамический анализ отсутствия недекларированных воз-

можностей.

В таблице 1.2 приведены методы тестирования, используемые

при проверках средств защиты информации.

Таблица 1.2

Методы тестирования средств защиты информации

Метод тестирования

Основные выявляемые дефекты и уяз-

вимости

Верификация

Дефекты проектирования методов

управления доступом

Функциональное тестирова- Дефекты реализации функций и ошиб-

ние

ки документации

Фаззинг-тестирование

Дефекты реализации интерфейсов дан-

ных

Граничное тестирование

Ошибки граничных условий

Нагрузочное тестирование

Ошибки производительности

Стресс-тестирование

Отказ в обслуживании

Профилирование

Недостатки оптимизации кода

Статический семантический Некорректности кодирования

анализ

Статический сигнатурный ана- Заданные потенциально опасные фраг-

лиз

менты

Статический анализ отсут- «Мертвый код»

ствия НДВ [69]

Динамический анализ отсут- «Мертвый код»

ствия НДВ [69]

Мониторинг операционных Нарушения целостности процессов и ре-

процессов

сурсов

Тестирование конфигураций Ошибки администрирования

Сканирование уязвимостей

Известные опубликованные уязвимости

Тест на проникновение

Известные уязвимости и ошибки конфи-

гурирования

Регрессионное тестирование

Повторные ошибки прошлых версий

Рефакторинг

Недостатки качества кода

Основы оценки соответствия

1.2.4. Аудит информационной безопасности

Аудит — систематический, независимый и документированный про-

цесс получения записей, фиксирования фактов или другой соответству-

ющей информации и их объективного оценивания с целью установления

степени выполнения заданных требований 12. Основное отличие аудита

от сертификации состоит в том, что здесь нет жестких рамок в плане

подтверждения соответствия в виде документа государственного образ-

ца (сертификата соответствия строго определенным требованиям), нет

необходимости привлечения третьей стороны (независимой аккредито-

ванной лаборатории), при этом критерии аудита также могут быть более

гибкие, отвечающие реалиям дня.

Аудит может быть внутренним и внешним (во всех смыслах),

проводиться на соответствие любым требованиям, сформулиро-

ванным заинтересованными лицами. Аудит может носить как тех-

нический, так и организационно-нормативный характер. В общем

смысле аудит включает проведение различных (динамических

и статических) форм тестирования подсистем и сегментов, анализ

документации и других информационных источников (например,

бюллетеней), интервьюирование специалистов и т.д.

В области информационной безопасности различают аудит ор-

ганизаций, информационных систем, систем менеджмента и про-

граммного кода. К аудиту безопасности информационных систем

относят комплексный анализ защищенности, анализ уязвимостей,

тесты на проникновение, аудит на соответствие нормативным до-

кументам регуляторов по защите различных тайн [14, 29, 33, 45, 62].

В таблице 1.3 приведены нормативные и методические доку-

менты, используемые при различных видах аудита ИБ.

1.2.5. Анализ риска информационной безопасности

Если в области оценки надежности и устойчивости техниче-

ских систем основополагающими понятиями являются ошибки

и отказы, то в области информационной безопасности таковыми

понятиями являются угрозы. Негативное последствие угрозы безо-

пасности ресурсу оценивается величиной соответствующего риска,

под которым понимается комбинация вероятности «нежелательно-

го» события и его последствий 13.

12 ГОСТ Р ИСО/МЭК 17000—2009.

13 ISO/IEC Guide 73:2002.

Основы оценки соответствия

Таблица 1.3

Нормативно-методические документы, используемые

при аудите безопасности

Категории аудита ин-

формационной безопас-

Нормативные и методические документы

ности

Аудит системы

ГОСТ 27001, ГОСТ 53647, BS 10012, Cobit,

менеджмента

ГОСТ 15.002

информационной

безопасности

Анализ защищенности

ГОСТ 17799

Тесты на

OSSTMM, ISSAF, NIST 800—42, OWASP Testing

проникновение

Guide, Wireless Penetration Testing Framework,

Penetration Testing Framework

Аудит безопасности кода OWASP Top Ten, Fortify SPK, MITRE CWE.

Аудит на соответствие

СТО БР ИББС-1.1

требованиям стандарта

Банка России

по информационной

безопасности

Аудит на соответствие

Нормативные и нормативно-методические

требованиям

документы Роскомнадзора, ФСБ России,

регуляторов по защите

ФСТЭК России

персональных данных

Аудит безопасности

PCI DSS

платежных систем

Следует отметить, что нарушение правил оценки соответствия

тоже может быть риском правового и технического характера.

Систематическое использование информации для идентифи-

кации источников и оценки величины риска называется анализом

риска 14. Методы анализа риска могут быть качественными, полу-

количественными и количественными 15. В качественных методах

используются вербальные понятия уровней риска, например: «ма-

ленький», «большой», «очень большой» и т.д. В полуколичествен-

14 Там же.

15 ISO/IEC 31010:2009.

Основы оценки соответствия

ных методах используются численные шкалы (линейные или лога-

рифмические). Количественные манипулируют конкретными чис-

ловыми единицами. Заметим, что полный количественный анализ

не всегда возможен вследствие эргатичности систем информаци-

онной безопасности [96], сложности получения представительной

статистики и др.

В настоящее время сложилась нормативная база анализа ри-

ска в области информационной безопасности в виде ГОСТ Р ИСО/

МЭК 27005—2010 «Информационная технология. Методы и сред-

ства обеспечения безопасности. Менеджмент риска информаци-

онной безопасности», который определяет процессный подход

к управлению рисками, включающий в том числе оценку и обработ-

ку риска (см. рис.1.2) [61].

Анализ риска включает этапы инвентаризации и категорирова-

ния ресурсов, идентификации значимых угроз и уязвимостей [47,

48], а также оценку вероятностей реализации угроз и уязвимостей.

Оценивание риска заключается в вычислении риска и собствен-

но оценивании его по заданной n-балльной или табличной шкале.

Риск, как правило, вычисляется как функция произведения:

Rij = pij k C

j ,

где: Cj — «стоимость» j-го ресурса, kij — коэффициент компрометации

j-го ресурса при реализации i-й угрозы, pij — вероятность реализа-

ции i-й угрозы безопасности j-го ресурса.

ОЦЕНКА РИСКА

Идентификация ресурсов

Анализ риска

Идентификация требований к ресурсам

Оценивание ресурсов

Идентификация угроз и уязвимостей

Оценка вероятностей уязвимостей

Оценка вероятностей угроз

Вычисление риска

Оценивание риска

Оценивание риска по шкале

Выбор мер

ОБРАБОТКА РИСКА

Осуществление мер

Измерение остаточного риска

Рис. 1.2. Процедура оценки и обработки риска

Основы оценки соответствия

После оценки риска принимается решение относительно об-

работки этого риска — выбору и реализации мер по модификации

риска [25, 28, 67, 89, 91]. В основу принятия решения берутся ожида-

емые потери, частота возникновения инцидента и другие факторы.

В стандарте предложены четыре меры обработки риска:

1. Уменьшение риска, когда риск считается неприемлемым

и для его уменьшения выбираются и реализуются соответствующие

механизмы безопасности;

2. Передача риска, когда риск считается неприемлемым и на

определённых условиях (например, в рамках страхования, постав-

ки или аутсорсинга) переадресуется сторонней организации [15];

3. Принятие риска, если риск считается осознанно допустимым

по причине невозможности внедрения разумных мер и средств без-

опасности.

4. Отказ от риска, когда риск исключается путем отказа от биз-

нес-процессов организации, являющихся причиной риска.

В результате обработки риска остается так называемый оста-

точный риск, относительно которого принимается решение о за-

вершении этапа обработки риска.

ГОСТ 27005 не ограничивает использование каких-либо мето-

дик и методов анализа риска, как-то: «мозговой штурм», структури-

рованные и полуструктурированные опросы, метод Дельфи, кон-

трольные листы, анализ сценариев, BIA, анализ дерева неисправно-

стей, анализ дерева событий, причинно-следственный анализ, ана-

лиз причинно-следственных связей, анализ уровней надежности

средств защиты, анализ дерева решений, HRA, анализ диаграммы

«галстук-бабочка», цепи Маркова (ТМО), метод Монте-Карло, Байе-

совский подход и сети Байеса, FN-кривые, метод индексов рисков,

матрица последствий и вероятностей, многокритериальный ана-

лиз решений и другие 16.

16 Там же.

2. СЕРТИФИКАЦИЯ СРЕДСТВ ЗАЩИТЫ

ИНФОРМАЦИИ

2.1. Определение сертификации

средств защиты информации

Под сертификацией понимается подтверждение соответствия

третьей стороной, относящееся к продукции, процессам, системам

или персоналу 17.

Следует указать ключевые особенности сертификации:

1. Сертификация проводится на соответствие заданным требова-

ниям, а именно техническим регламентам [38], положениям стандар-

тов, сводов правил, условиям договоров и другим требованиям, опреде-

ленным в нормативных документах и соответствующей документации.

Поэтому область сертификации и ее результат однозначно определены

конкретными нормативными документами, а не требованиями и реко-

мендациями по повышению качеству или защищенности вообще.

2. В случае положительно результата процесс сертификации за-

канчивается выдачей официального письменно оформленного удо-

стоверения — сертификата соответствия, а сертифицированная про-

дукция подлежит маркировке знаком соответствия системы сертифи-

кации. В некоторых системах сертификации можно встретить еще

одно официальное удостоверение — заключение, которое применя-

ется для случаев, когда орган по сертификации затрудняется выдать

общепринятый сертификат соответствия.

3. Сертификация является деятельностью третьей стороны, т. е.

должна быть обеспечена независимость оценки соответствия, максималь-

но исключающая любые формы аффилированности или сговора [42].

4. Сертификация может быть добровольной и обязательной.

Сертификация средств защиты информации по требованиям безо-

пасности информации является обязательной.

17 ГОСТ Р ИСО/МЭК 17000:2009, п.5.5.

Сертификация средств защиты информации

5. Так как в стране действует несколько систем сертификации,

то эти системы определяют некоторые свои правила и процедуры

проведения оценки соответствия, включая аккредитацию органов

по сертификации и испытательных лабораторий, разумеется, в рам-

ках российского законодательства и своей компетенции.

Таким образом, сертификация средств защиты информации

по требованиям безопасности информации представляет собой обя-

зательное независимое подтверждение соответствия СЗИ требовани-

ям нормативных документов по защите информации с учетом правил

федеральных органов (Минобороны, СВР, ФСБ, ФСТЭК) в рамках их

компетенции 18. Следует отметить, что федеральные органы по серти-

фикации трактуют СЗИ в широком смысле, как средство защиты от

угроз информационной безопасности и ее составных свойств: целост-

ности, доступности, конфиденциальности и др. В этом смысле под по-

нятие СЗИ при самой общей модели угроз подпадает любое изделие

в защищенном исполнении, например, «безопасное» от программных

закладок ПО.

В таблице 2.1 приведены примеры объектов сертификации в об-

ласти информационной безопасности, к которым определены требо-

вания в открытых нормативных документах.

Следует прокомментировать табл. 2.1. Например, несмотря на то,

что сертификация систем в ФСТЭК проводится в форме аттестации

объектов информатизации, последняя реально (при защите конфиден-

циальной информации) таковой не является, т. к. не полностью соблю-

дается самый главный закон сертификации о третьей стороне. Несмо-

тря на то, что сформулированы требования к системам менеджмента

информационной безопасности (серия ГОСТ 27000), они не нашли от-

ражение в нормативно-методических документах обязательных систем

сертификации. В жизни и в документах регуляторов можно встретить

классы общепринятых СЗИ, таких как: средства контент анализа, сред-

ства контроля утечек, средства анализа защищенности, средства управ-

ления и мониторинга, средства доверенной загрузки, генераторы паро-

лей, защищенные BIOS, средства безопасности программных прило-

жений, средства безопасности виртуализации, средства безопасности

облачных технологий, средства защиты в промышленных системах

и системах высокой готовности и др., однако требования к ним либо

пока отсутствуют, либо (в противоречие 2-му правилу Керкго ффса) не

подлежат публичному информированию или обсуждению.

18 См. ФЗ-347.

Сертификация средств защиты информации

Таблица 2.1

Объекты сертификации по требованиям безопасности информации

Объекты серти-

Объект сертификации средств защиты информации

фикации

Продукция

Средства защиты информации

Средства вычислительной техники

Профили защиты

Межсетевые экраны

Средства обнаружения вторжений

Средства антивирусной защиты

Средства криптографической защиты информации

Средства защиты персональных данных

Системы

Автоматизированные системы

Системы менед- Системы менеджмента (управления) безопасности

жмента

Согласно Доктрине информационной безопасности РФ 19 серти-

фикация СЗИ является важнейшим методом обеспечения безопас-

ности страны, а значит, государственную важность приобретает со-

вершенствование мер, направленных на повышение эффективности

и достоверности результатов сертификации СЗИ [34]. Именно поэто-

му процесс сертификации включает несколько уровней независимых

проверок: экспертизу заявки в федеральном органе, проведение ис-

пытаний в аккредитованной испытательной лаборатории, проверку

материалов испытаний в аккредитованном органе по сертификации

и др. При этом обеспечивается независимость между участниками

сертификации: аккредитованным органом по сертификации, аккре-

дитованной испытательной лабораторией и другими заинтересован-

ными сторонами.

2.2. Правила и участники сертификации средств

защиты информации

Согласно Постановлению Правительства РФ 1995 г. № 608, руко-

водство системами сертификации возложено на федеральные орга-

ны по сертификации: Минобороны России, СВР России, ФСБ России

и ФСТЭК России.

19 Утв. Президентом РФ 09.09.2000 № Пр-1895.

Сертификация средств защиты информации

В общегражданском плане регулирование рынка некриптографи-

ческих СЗИ в стране возложено на ФСТЭК России, а рынка крипто-

графических СЗИ — на ФСБ России.

Участниками сертификации являются федеральный орган по сер-

тификации, аккредитованный орган по сертификации, аккредитован-

ная испытательная лаборатория, заявитель на сертификацию, кото-

рым может быть разработчик, изготовитель или поставщик.

Порядок проведения сертификации выглядит следующим обра-

зом [60].

1. Заявитель подает в федеральный орган заявку на проведение

сертификационных испытаний.

2. Федеральный орган определяет аккредитованную испыта-

тельную лабораторию и орган по сертификации, что фиксируется

в решении на сертификацию.

3. Испытательная лаборатория проводит сертификационные ис-

пытания.

4. Материалы испытаний (программа и методика, протоколы ис-

пытаний, техническое заключение) передаются в орган по сертифи-

кации, который проводит их независимую экспертизу.

5. Федеральный орган по сертификации на основании положи-

тельного технического заключения органа по сертификации оформ-

ляет сертификат соответствия. В случае выявления каких-либо несо-

ответствий федеральный орган может провести дополнительную экс-

пертизу с привлечением экспертов из различных аккредитованных

лабораторий и органов по сертификации (см. рис. 2.1).

В области защиты информации применяются следующие схемы

сертификации СЗИ:

— сертификация единичного образца СЗИ;

— сертификации партии СЗИ;

— сертификация серии (типового образца) с предварительной

проверкой производства.

Сертификационные испытания можно классифицировать по ме-

тоду тестирования:

— функциональное тестирование продукта или системы по ме-

тоду «черного ящика»;

— структурное тестирование исходного кода ПО.

В первом случае при испытаниях используются:

— традиционные нормативные документы (например, руководя-

щие документы Гостехкомисии России);

— документация (например, ТУ);

Сертификация средств защиты информации

Заявитель (разработчик,

изготовитель, поставщик)

Сертификат

Решение

Заявка

Федеральный орган по

сертификации (ФСТЭК России)

Материалы

Решение

Заключение

для проведения

испытаний

Орган по сертификации

Решение

Замечания

Материалы испытаний

Испытательная лаборатория

Рис. 2.1. Участники системы сертификации ФСТЭК России

— задание по безопасности — документ, разрабатываемый в соот-

ветствии с метастандартом ГОСТ ИСО 15408.

Особенность структурного тестирования состоит в том, что оно

проводится в форме статического и динамического анализа исходного

кода программ и касается только вопросов внутренней безопасности

продукта (контроля отсутствия недекларированных возможностей).

Как ранее отмечалось, документом, подтверждающим положи-

тельные результаты сертификационных испытаний, является сер-

тификат соответствия, в котором указаны самые важные моменты:

идентификационные характеристики 20, на соответствие каким доку-

ментам проведены испытания, срок действия, документ (обычно ТУ

или формуляр), в котором определены ограничения на использование

СЗИ и зафиксированы контрольные суммы и др.

Перечень аккредитованных испытательных лабораторий

ФСТЭК России и ФСБ России, аккредитованных органов по серти-

фикации ФСТЭК, открытые реестры сертифицированных СЗИ, пра-

вовые акты и нормативно-методические документы ФСТЭК и ФСБ

можно посмотреть на вебпорталах указанных ведомств: www.fstec.ru

и clsz.fsb.ru.

Требования к сертификации определены федеральными зако-

нами, постановлениями Правительства, стандартами и кодексами,

20 ГОСТ Р 54011—2010.

Сертификация средств защиты информации

а требования к проверкам (сертификационным испытаниям, инже-

нерным или тематическим исследованиям) определены в норматив-

ных документах или в соответствующей документации.

2.3. Законодательно-правовые

основы сертификации

Законодательные и правовые требования определяют, когда сер-

тификация необходима, а также ответственность за несоблюдение

этих требований.

При определении обязательности сертификации СЗИ удобно

провести классификацию защищаемого информационного ресурса

и объектов информатизации.

В качестве признаков классификации информационного ресурса

выделяют два: принадлежность к государственному информационно-

му ресурсу и уровень ограниченности доступа.

Для государственного информационного ресурса требования

устанавливает и контролирует сам собственник (государство). В дру-

гих случаях могут быть неоднозначности.

При идентификации уровня ограниченности доступа выделяют:

— государственную тайну,

— личную и семейную тайны (персональные данные),

— другие виды тайн, не отнесенные к гостайне и персональным

данным,

— открытую общедоступную информацию.

Заметим, что в случае, когда говорят об информации ограничен-

ного доступа, не отнесенной к гостайне, ее исторически часто назы-

вают информацией конфиденциального характера или просто кон-

фиденциальной информацией.

Дополнительно могут быть определены требования к системам

обработки информации, независимо от классификации обрабатыва-

емой информации.

Назовем основные случаи, когда сертификация СЗИ в нашей

стране обязательна (табл. 2.2):

— защищаемая информация составляет сведения, отнесенные

к государственной тайне;

— защищаемая информация ограниченного доступа, но не отне-

сенная к гостайне, при условии, что она относится к государственно-

му информационному ресурсу;

— защищаемая информация относится к персональным данным

и составляет личную и семейную тайну;

Сертификация средств защиты информации

Таблица 2.2

Основание для требования по сертификации средств защиты

информации

Государ- Личная,

Информаци-

ствен-

семей-

Открытая общедо-

онный ресурс ная тай-

ная тай- Другие тайны*

ступная информа-

на

ция

Государствен- Да

Да

Для систем общего

ный инфор-

пользования и для

мационный

специфических си-

ресурс

стем

Негосудар-

—

Да

Только для

Только для специфи-

ственный ин-

специфиче-

ческих систем

формацион-

ских систем

ный ресурс

* Например: коммерческая, журналистская, депутатская, пенсионная,

торговая, промышленная, производственная, профессиональная, служеб-

ная, врачебная тайны, ноу-хау, секретный торговый процесс, информа-

ция о членах политических партий, инсайдерская информация, а также

тайны дневников и личных записей, исповеди, связи, ценных бумаг и еще

около 40 разных интересных тайн.

— к защите объектов информатизации (систем, комплексов) опреде-

лены требования по оценке соответствия независимо от видов тайн.

К примеру, в случае защиты государственной тайны требования

по обязательной сертификации СЗИ определены в Законе РФ «О го-

сударственной тайне» 1993 г. № 5485-I, Постановлении Правитель-

ства РФ 1995 г. № 608 и в других документах.

Требования по сертификации средств защиты информации кон-

фиденциального характера в государственных организациях опреде-

лены в Постановлении Правительства РФ 2010 г. № 330 (п.6), а также

в нормативных документах ФСБ России и ФСТЭК России.

Требования по сертификации средств защиты персональных

данных прямо вытекают из Постановления Правительства РФ 2010 г.

№ 330 (п.6) и косвенно из Постановления Правительства РФ 2007 г.

№ 781 (п.5), а также регламентируются нормативными документам

ФСБ России и ФСТЭК России (рис. 2.2).

В остальных случаях необходимо руководствоваться норматив-

ными требованиями к специфическим объектам. Примерами таких

объектов являются следующие:

— информационные системы критически важных объектов;

Сертификация средств защиты информации

Средства защиты информации, применяемые в

информационных системах, в установленном

порядке проходят процедуру оценки соответствия.

Постановление Правительства РФ 2007 г. № 781, п. 5.

Рис. 2.2. Фрагмент Постановления Правительства РФ № 781

— автоматизированные системы управления технологическим

процессом;

— системы управления экологически опасными производствами,

объектами, имеющими важное оборонное или экономическое значе-

ние и влияющими на безопасность государства;

— федеральные государственные информационные системы об-

щего пользования;

— автоматизированные системы систем вооружений;

— игровые автоматы и др.

Следует сказать, что с практической точки зрения обязатель-

ность сертификации СЗИ диктуется обычно двумя обстоятельства-

ми. Первое связано с требованиями заказчика, который формулирует

их к разработке, поставке, внедрению защищенной информационной

системы. Например, в техническом задании или техническом проек-

те на ОКР (и дальнейшего авторского надзора или техподдержки)

весьма красиво указать ГОСТ Р 51583:2000 «Порядок создания авто-

матизированных систем в защищенном исполнении». Согласно п. 4.15

этого стандарта необходим сертификат соответствия.

Другой случай связан с необходимостью быть уверенным в защи-

щенности объекта с формальной точки зрения, когда требуется за-

получить какой-нибудь официальный документ о подтверждении со-

ответствия информационной системы требованиям российского за-

конодательства. В настоящее время в области информационной без-

опасности таким документом является аттестат соответствия. Никто

не выпишет такой аттестат без сертифицированных СЗИ.

Согласно Закону № 152-ФЗ «О персональных данных» лица, ви-

новные в нарушении требований закона, несут гражданскую, уголов-

ную, административную, дисциплинарную и иную предусмотренную

законодательством Российской Федерации ответственность. То же са-

мое можно сказать и про использование несертифицированных СЗИ.

Что касается административных нарушений в области защиты

информации, то следует в первую очередь отметить Главу 13 действу-

Сертификация средств защиты информации

Таблица 2.3.

Основание для сертификации средств защиты информации

Законодательный или норма-

тивно-правовой документ

Защищаемая информация

Закон «О государственной

государственная тайна

тайне» 1993 г. № 5485-I

Постановление Правитель-

государственная тайна

ства РФ 1995 г. № 608

Указ Президента РФ 2008 г.

гостайна или служебная тайна (при под-

№ 351

ключении к информационно-телекомму-

никационным сетям международного ин-

формационного обмена)

СТР-К

конфиденциальная информация (госуч-

реждений)

Постановление Правитель-

информация конфиденциального харак-

ства РФ 2010 г. № 330

тера (ГИР);

персональные данные

Приказ Председателя Го-

информация с ограниченным доступом;

стехкомиссии России 1995 г.

служебная информация, циркулирующая

№ 199

в системах управления экологически опас-

ными производствами, объектами, имею-

щими важное оборонное или экономиче-

ское значение и влияющими на безопас-

ность государства, а также средствах об-

щего применения, предназначенных для

ПДИТР

Указ Президента РФ 1995 г.

криптограммы

№ 334

Специальные документы

информационный ресурс информацион-

ФСТЭК России по ключевым ных систем критически важного объекта

системам информационной

инфраструктуры

Постановление Правитель-

персональные данные

ства РФ 2007 г. № 781

Методические документы 8

персональные данные

Центра ФСБ России по персо-

нальным данным

Специальные документы

персональные данные

ФСТЭК России по персональ-

ным данным

Постановление Правитель-

информационный ресурс государствен-

ства РФ 2009 г. № 424

ных информационных систем общего

пользования

ГОСТ Р 51583—2000

информация ограниченного доступа

ГОСТ Р 51189—1998

служебная тайна

Сертификация средств защиты информации

ющего КоАП, в котором весьма интересны для изучения следующие

статьи:

— ст. 13.6. Использование несертифицированных средств связи

либо предоставление несертифицированных услуг связи;

— ст. 13.12. Нарушение правил защиты информации;

— ст. 13.13. Незаконная деятельность в области защиты инфор-

мации.

Так, в ст. 13.12 определены административные штрафы для слу-

чая использования несертифицированных СЗИ, включая конфиска-

цию СЗИ, а при отягчающих обстоятельствах и высшую меру адми-

нистративного наказания — приостановление деятельности.

Про УК РФ возникает речь, если внедрение и использование не-

сертифицированных СЗИ квалифицируется как деяние, повлекшее

некоторое преступление. Например, согласно ст. 274 УК РФ наруше-

ние правил эксплуатации средств хранения, обработки или переда-

чи охраняемой компьютерной информации, либо информационно-

телекоммуникационных сетей и оконечного оборудования, а также

правил доступа к информационно-телекоммуникационным сетям, по-

влекшее уничтожение, блокирование, модификацию либо копирова-

ние компьютерной информации может ограничить свободу на пять

лет. Вопросы нарушения правил и условий, халатности, утраты, раз-

глашения тайн при автоматизированной обработке в той или иной

степени отражены в 19, 22, 24, 26—33 главах УК РФ.

Отдельно следует назвать ст. 171 (незаконное предприниматель-

ство), касающуюся деятельности с нарушением обязательных лицен-

зионных требований и условий, в нашем случае, читай, при разработ-

ке, внедрении и сертификации СЗИ [87].

Надо понимать, что ответственность за возникшие проблемы

в области защиты информации, кроме органов по сертификации

и испытательных лабораторий, возлагается также на владельца объ-

екта информатизации, уполномоченного владельцем (по договору)

лицо и разработчика.

2.4. Традиционные руководящие документы

Гостехкомиссии России

В настоящее время наиболее используемыми в области технической

защиты информации (в полном объеме или фрагментарном) во всех си-

стемах сертификации являются «традиционные» руководящие документы

Гостехкомиссии России [69], разработанные в незапамятные времена про-

Сертификация средств защиты информации

шлого века, но остающиеся актуальными до сих пор. Наиболее представи-

тельными из них следует назвать следующие четыре:

— РД. Средства вычислительной техники. Защита от несанкци-

онированного доступа к информации. Показатели защищенности от

несанкционированного доступа к информации (Гостехкомиссия Рос-

сии, 1992 г.);

— РД. Средства вычислительной техники. Межсетевые экраны.

Защита от несанкционированного доступа. Показатели защищенно-

сти от несанкционированного доступа к информации (Гостехкомис-

сия России, 1997 г.);

— РД. Автоматизированные системы. Защита от несанкциониро-

ванного доступа к информации. Классификация автоматизирован-

ных систем и требования по защите информации (Гостехкомиссия

России, 1992 г.);

— РД. Защита от несанкционированного доступа к информации.

Часть 1. Программное обеспечение средств защиты информации.

Классификация по уровню контроля отсутствия недекларированных

возможностей (Гостехкомиссия России, 1999 г.).

Первые три документа касаются требований по защите инфор-

мации, предъявляемых к средствам и системам, и используются при

функциональном тестировании (по методу «черного ящика»).

Четвертый документ касается внутренней безопасности про-

граммных продуктов (защищенности от уязвимостей) и использует-

ся при оценке соответствия структурными методами (по методу «бе-

лого ящика»).

2.4.1. Классы защищенности средств вычислительной техники

Руководящий документ «Средства вычислительной техники. За-

щита от несанкционированного доступа к информации. Показатели

защищенности от несанкционированного доступа к информации»

устанавливает требования к составу документации, а также номенкла-

туру показателей защищенности средств вычислительной техники

(СВТ), описываемых совокупностью требований к защите и опреде-

ляющих классификацию СВТ по уровню защищенности от НСД к ин-

формации [69].

В рамках документа под СВТ понимается совокупность про-

граммных и технических элементов систем обработки данных, спо-

собных функционировать самостоятельно или в составе других си-

стем, и предназначенных для предотвращения или существенного за-

труднения несанкционированного доступа к информации. СВТ как

Сертификация средств защиты информации

комплексное средство защиты информации от НСД может включать

ряд подсистем (механизмов) безопасности, таких как: идентифика-

ция, аутентификация, разграничение доступом, контроль целостно-

сти, протоколирование и другие механизмы противодействия акту-

альным угрозам информационной безопасности [1, 11, 45, 46]. В дан-

ном РД не предъявляются требования к средствам криптографиче-

ской защиты информации (СКЗИ), которые, однако, могут быть ис-

пользованы дополнительно.

Следует заметить, что данный РД релевантен по отношению

к стандарту ГОСТ Р 50739—95 «Средства вычислительной техники.

Защита от несанкционированного доступа к информации. Общие

технические требования».

Документ определяет 7 классов защищенности. Каждый класс

характеризуется заданными значениями показателей защищенно-

сти СВТ, которые описываются соответствующими требованиями

(табл.2.4). Формально требования можно разделить на 4 группы:

— требования к подсистемам идентификации, аутентификации,

авторизации (п. п. 1—4, 6—8 в таблице 2.4);

— требования к подсистеме протоколирования (п. п.5, 10);

— требования к гарантиям разработки (п. п.9,11—17);

— требования к документации (п. п.18—21).

Требования к СВТ варьируются по уровню и глубине в зависи-

мости от соответствующего класса защищенности. С точки зрения

принципиальных моментов безопасности информации можно выде-

лить три группы СВТ:

— СВТ с гарантированной (верифицированной) защитой инфор-

мации — класс 1;

— СВТ с полным (мандатным) управлением доступом — классы 2—4;

— СВТ с избирательным (дискретным) управлением доступом —

классы 5, 6.

Формально в РД определены 7 классов, но к 7-му классу (в табли-

це 2.4 не показан) требования не предъявляются, 5-й класс предусмо-

трен для защиты информации конфиденциального характера, с 4-го

по 2-й класс — для защиты сведений, составляющих государственную

тайну (соответственно секретных сведений, совершенно секретных,

особой важности), 6 и 1 21 — в настоящее время в РФ не имеют юриди-

ческой значимости.

21 Требования по 1 классу предъявляются только к военным системам США (см.

DoD 5200.28-STD: 1983).

Сертификация средств защиты информации

Таблица 2.4

Показатели защищенности средств вычислительной техники

Класс

п/п

Показатель защищенности

защищенности

Дискреционный принцип контроля доступа

+ + = +

Мандатный принцип контроля доступа

–

– + = =

Очистка памяти

–

+ + + =

Изоляция модулей

–

– + = +

Маркировка документов

–

– + = =

Защита ввода и вывода на отчуждаемый физи-

ческий носитель информации

–

– + = =

Сопоставление пользователя с устройством

–

– + = =

Идентификация и аутентификация

= + = =

Гарантии проектирования

–

+ + + +

10 Регистрация

–

+ + + =

11 Взаимодействие пользователя с КСЗ

–

– – + =

12 Надежное восстановление

–

– – + =

13 Целостность КСЗ

–

+ + + =

14 Контроль модификации

–

– – – +

15 Контроль дистрибуции

–

– – – +

16 Гарантии архитектуры

–

– – – –

17 Тестирование

+ + + +

18 Руководство для пользователя

= = = =

19 Руководство по КСЗ

+ = + +

20 Тестовая документация

+ + + +

21 Конструкторская (проектная) документация

+ + + +

* Требования по 1 классу предъявляются только к военным системам США

(см. DoD 5200.28-STD: 1983).

Обозначения: «–» — нет требований к данному классу; «+» — новые требова-

ния, «=» — требования совпадают с предыдущими; серым фоном выделены

требования к защите сведений, составляющих гостайну.

Сертификация средств защиты информации

2.4.2. Классы защищенности межсетевых экранов

Документ «РД. Средства вычислительной техники. Межсетевые

экраны. Защита от несанкционированного доступа. Показатели за-

щищенности от несанкционированного доступа к информации» раз-

работан для оценки соответствия средств межсетевой защиты (меж-

сетевых экранов), используемых для безопасного разграничения до-

ступа между сегментами сетей.

В РД под межсетевым экраном (МЭ) понимается локальное (од-

нокомпонентное) или функционально-распределенное программное

(программно-аппаратное) средство (комплекс), реализующее кон-

троль за информацией, поступающей в автоматизированную систе-

му (АС) и/или выходящей из АС.

Указанным документом определены 12 показателей защищенно-

сти МЭ, требования к реализации которых задают класс защищенно-

сти МЭ (табл. 2.5).

К каждому классу защищенности МЭ сопоставлено в соответ-

ствие требование по защите категории информации ограниченного

доступа. Иначе говоря, для того, чтобы АС возможно было аттесто-

вать, объект информатизации должен быть защищен от внешней сре-

ды межсетевым экраном не ниже следующего класса:

— 5 класс для АС «1Д», «2Б», «3Б»;

— 4 класс для АС «1Г»;

— 3 класс для АС «1В», а также «2А», «3А» в случае обрабатывае-

мой информации с грифом «секретно»;

— 2 класс для АС «1Б», а также «2А», «3А» в случае обрабатывае-

мой информации с грифом «сов.секретно»;

— 1 класс для АС «1А», а также «2А», «3А» в случае обрабатывае-

мой информации с грифом «особой важности».

2.4.3. Классы защищенности автоматизированных систем

Документ «РД. Автоматизированные системы. Защита от несанк-

ционированного доступа к информации. Классификация автомати-

зированных систем и требования по защите информации» определя-

ет требования к защищенности информации в АС. Следует сказать,

что данный документ может быть основным в случае сертификации

системы, но только дополнительным — в случае аттестации. Это свя-

зано с тем, что требования по аттестации уточнены специальными

нормативными документами ФСТЭК России и национальными стан-

дартами ограниченного доступа.

Сертификация средств защиты информации

Таблица 2.5

Показатели защищенности межсетевых экранов

Класс защищен-

№

ности

п/п

Показатель защищенности

Управление доступом (фильтрация данных

и трансляция адресов)

Идентификация и аутентификация

–

Регистрация

–

Администрирование: идентификация и аутенти-

фикация

Администрирование: регистрация

Администрирование: простота использования

–

Целостность

Восстановление

Тестирование

Руководство администратора защиты

Тестовая документация

Конструкторская (проектная) документация

Документ устанавливает требования к группам подсистем безо-

пасности:

— подсистеме управления доступом (включая идентификацию,

аутентификацию и авторизацию);

— подсистеме протоколирования;

— криптографической системе;

— подсистеме обеспечения целостности, а также подсистеме физи-

ческой защиты, администрирования, тестирования и резервирования.

В РД определены девять классов защищенности АС от несанкцио-

нированного доступа к информации (табл. 2.6). Каждый класс задает-

ся определенной совокупностью минимальных требований по защи-

те. Классы разбиты на три группы, различающиеся особенностями

обработки информации в АС.

Третья группа («3А», «3Б») классифицирует АС, в которых рабо-

тает один пользователь, допущенный ко всей информации АС, разме-

щенной на носителях одного уровня конфиденциальности.

Сертификация средств защиты информации

Вторая группа («2А», «2Б») классифицирует АС, в которых пользо-

ватели имеют одинаковые права доступа ко всей информации АС, об-

рабатываемой на носителях различного уровня конфиденциальности.

Первая группа («1А», «1Б», «1В», «1Г», «1Д») классифицирует мно-

гопользовательские АС, в которых одновременно обрабатывается ин-

формация разных уровней конфиденциальности и не все пользовате-

ли имеют право доступа ко всей информации АС.

В рамках выделенных групп установлено упорядочение требова-

ний по защите в зависимости от степени конфиденциальности ин-

формации. Класс, имеющий высшую степень защищенности для кон-

кретной группы, отмечается литерой «A» («1А», «2А», «3А»).

Согласно п. 2.18 документа, при разработке АС, предназначенной

для обработки или хранения информации, являющейся собственно-

стью государства и отнесенной к категории секретной, необходимо

ориентироваться в соответствии с РД «Средства вычислительной тех-

ники. Защита от несанкционированного доступа к информации. По-

казатели защищенности от несанкционированного доступа к инфор-

мации» на классы защищенности АС не ниже (по группам) «3А», «2А»,

«1А», «1Б», «1В» и использовать сертифицированные СВТ:

— не ниже 4 класса — для класса защищенности АС «1В»;

— не ниже 3 класса — для класса защищенности АС «1Б»;

— не ниже 2 класса — для класса защищенности АС «1А».

Следует обратить внимание на то, что в специальных документах

ФСТЭК, используемых при аттестации, требования к п.4.6 таблицы

2.6 однозначно усилены, а к п.3 могут быть снижены за счет ассиме-

тричных мер.

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

Документ «РД. Защита от несанкционированного доступа к ин-

формации. Часть 1. Программное обеспечение средств защиты ин-

формации. Классификация по уровню контроля отсутствия недекла-

рированных возможностей» определяет требования к структурному

анализу ПО с целью выявления недекларированных возможностей

(НДВ), под которыми понимаются неописанные в документации

функциональные возможности, при использовании которых возмож-

но нарушение уровня безопасности системы. В РД указаны два вида

структурного анализа: статический и динамический, что подразуме-

вает необходимость предоставления исходных текстов ПО и спец-

ификаций (в данном случае документации, выполненной в соответ-

ствии с ГОСТ).

Сертификация средств защиты информации

Таблица 2.6

Классы защищенности автоматизированных систем

№

Классы

п/п

Подсистемы и требования

3Б 3А 2Б 2А 1Д 1Г 1В 1Б 1А

Подсистема управления доступом

1.1 Идентификация, проверка

подлинности и контроль досту-

па субъектов:

в систему

к терминалам, ЭВМ, узлам сети

ЭВМ, каналам связи, внешним

–

устройствам ЭВМ

к программам

–

к томам, каталогам, файлам, за-

писям, полям записей

–

1.2 Управление потоками инфор-

мации

–

Подсистема регистрации и учета

2.1 Регистрация и учет:

входа (выхода) субъектов досту-

па в (из) систему (ы) (узел сети) +

выдачи печатных (графиче-

ских) выходных документов

–

запуска (завершения) про-

грамм и процессов (заданий,

–

задач)

доступа программ субъек-

тов доступа к защищаемым

файлам, включая их создание

–

и удаление, передачу по лини-

ям и каналам связи

доступа программ субъектов

доступа к терминалам, ЭВМ,

узлам сети ЭВМ, каналам свя-

зи, внешним устройствам ЭВМ, –

–

программам, томам, каталогам,

файлам, записям, полям запи-

сей

изменения полномочий субъек-

тов доступа

–

Сертификация средств защиты информации

Окончание табл. 2.6

№

Классы

п/п

Подсистемы и требования

3Б 3А 2Б 2А 1Д 1Г 1В 1Б 1А

создаваемых защищаемых объ-

ектов доступа

–

2.2 Учет носителей информации

2.3 Очистка (обнуление, обезли-

чивание) освобождаемых обла-

стей оперативной памяти ЭВМ –

–

и внешних накопителей

2.4 Сигнализация попыток наруше-

ния защиты

–

Криптографическая подсистема

3.1 Шифрование конфиденциаль-

ной информации

–

3.2 Шифрование информации,

принадлежащей различным

субъектам доступа (группам –

–

субъектов) на разных ключах

3.3 Использование аттестованных

(сертифицированных) крипто- –

–

графических средств

Подсистема обеспечения целостности

4.1 Обеспечение целостности про-

граммных средств и обрабаты-

ваемой информации

4.2 Физическая охрана средств вы-

числительной техники и носи-

телей информации

4.3 Наличие администратора

(службы) защиты информации –

–

в АС

4.4 Периодическое тестирование

СЗИ НСД

4.5 Наличие средств восстановле-

ния СЗИ НСД

4.6 Использование сертифициро-

ванных средств защиты

–

Сертификация средств защиты информации

Документ определяет четыре уровня контроля отсутствия НДВ,

в зависимости от этого предъявляются требования к содержанию

проверок, составляющих статический и динамический анализ, а так-

же к составу документации (табл. 2.7). Уровни контроля соответству-

ют уровню ограниченности доступа к информации, а именно: 4-й уро-

вень контроля соответствует средствам защиты информации конфи-

денциального характера, с 3-го по 1-й — соответственно средствам за-

щиты секретных сведений, совершенно секретных, особой важности.

Как видно из таблицы 2.7, основное содержание статического

анализа составляют процедуры идентификации исходного и загру-

зочного кода, а также процедуры декомпозиции кода программы

вплоть до перечня маршрутов (путей), представляющих собой после-

довательность выполняемых функциональных объектов. Динамиче-

ский анализ представляет собой проверку соответствия реальных

маршрутов с перечнем маршрутов, полученным на этапе статическо-

го анализа.

Таблица 2.7

Уровни контроля отсутствия недекларированных возможностей

Уровень

№

Наименование требования

контроля

Требования к документации

Контроль состава и содержания документации

1.1 Спецификация (ГОСТ 19.202—78)

1.2 Описание программы (ГОСТ 19.402—78)

1.3 Описание применения (ГОСТ 19.502—78)

1.4 Пояснительная записка (ГОСТ 19.404—79)

1.5 Тексты программ, входящих в состав ПО

(ГОСТ 19.401—78)

Требования к содержанию испытаний

Контроль исходного состояния ПО

Статический анализ исходных текстов программ

3.1 Контроль полноты и отсутствия избыточности

исходных текстов

3.2 Контроль соответствия исходных текстов ПО его

объектному (загрузочному) коду

Сертификация средств защиты информации

Окончание табл. 2.7

Уровень

№

Наименование требования

контроля

3.3 Контроль связей функциональных объектов

по управлению

3.4 Контроль связей функциональных объектов

по информации

3.5 Контроль информационных объектов

3.6 Контроль наличия заданных конструкций в ис-

ходных текстах

3.7 Формирование перечня маршрутов выполнения

функциональных объектов

3.8 Анализ критических маршрутов выполнения

функциональных объектов

Анализ алгоритма работы функциональных объ-

3.9 ектов на основе блок-схем, диаграмм и т. п., по-

строенных по исходным текстам контролируемо-

го ПО

Динамический анализ исходных текстов про-

грамм

4.1 Контроль выполнения функциональных объектов

Сопоставление фактических маршрутов выполне-

4.2 ния функциональных объектов и маршрутов, по-

строенных в процессе проведения статического -

анализа

Отчетность

Следует обратить внимание на контроль по 2-му уровню, так как

здесь предусмотрены проверки по безопасности кода, а именно кон-

троль конструкций (предполагается, что это фрагменты потенциаль-

но опасного кода) и анализ критических (потенциально небезопас-

ных) маршрутов.

2.5. Требования к защите персональных данных

В настоящее время к категории конфиденциальной информа-

ции, имеющей характер персональных данных (составляющих лич-

ную и семейную тайну), предъявляются особые нормативно-методи-

Сертификация средств защиты информации

Технические условия

Основные параметры и характеристики

(свойства)

Технические требования

Требования к сырью, материалам,

покупным изделиям

Требования охраны

окружающей среды

Комплектность

Маркировка

Правила приемки

Упаковка

Методы контроля

Транспортирование и хранение

Указания по эксплуатации

Гарантии изготовителя

Рис. 2.3. Структура ТУ по ГОСТ 2.114—95

ческие требования к оценке соответствия их средств защиты. При

оценке соответствия выделяют три момента:

— классификация информационных систем персональных дан-

ных (ИСПДн);

— определение требований к составу и классам защищённости

средств защиты;

— формирование требований к СЗИ в конструкторском докумен-

те «Технические условия» (главным образом, в разделах «технические

требования» и «указания по эксплуатации»), в соответствии с которы-

ми и проводится оценка соответствия (рис. 2.3).

Правила классификации введены Приказом ФСТЭК России, ФСБ

России, Мининформсвязи России 2009 г. № 55/86/20 «Об утверждении

порядка проведения классификации информационных систем персо-

нальных данных». Согласно правилам, класс ИСПДн зависит от кате-

гории обрабатываемых персональных данных и их объема (табл. 2.8).

В нормативно-методических документах регуляторов указаны

следующие средства защиты информации:

— средства предотвращения несанкционированного доступа;

— средства защиты информации при межсетевом взаимодей-

ствии;

— антивирусные средства;

— средства анализа защищенности;

— средства обнаружения вторжений;

— криптографические средства.

Сертификация средств защиты информации

Таблица 2.8

Классификация информационных систем персональных данных

Число субъектов персональных данных

Категории персональ-

1000—100 000

Более 100 000

ных данных

До 1000

(организация)

(отрасль, го-

(субъект феде-

род)

рации)

Обезличенные, общедо-

ИСПДн К4

ступные данные

Идентификационные

ИСПДн К3

ИСПДн К2

данные

Дополнительные дан-

ИСПДн К3

ИСПДн К2

ИСПДн К1

ные

Данные о состоянии

ИСПДн К1

здоровья, расовой и на-

циональной принадлеж-

ности, политических,

религиозных и фило-

софских взглядах, ин-

тимной жизни

Таблица 2.9

Требования к системам и средствам защиты персональных данных

е-

- -

р П

он

ти

ом

Класс

Э п

ь к

ь дов С

ь д ан н тву

ИСПДн

Класс АС

те С

я Н

я к ус

ласс М

ол

ен я к

овен и р едс

овен

ласс М

р тр

ов

ср

р р

ви

К защ

У вер

ИСПДн К1 3А, 2А-, 1Г- **

ОУД 3+

ИСПДн К2

3Б, 2Б, 1Д

ОУД 2+

ИСПДн К3

3Б, 2Б, 1Д

ОУД 1+

ИСПДн К4

ОУД 1+

** Знак «-» означает, что требования для указанного класса заданы не в

полном объеме; знак «+» — требования усилены; * — означает, что требова-

ния определяются оператором.

Сертификация средств защиты информации

Независимо от класса ИСПДн, средства криптографической за-

щиты информации (СКЗИ) имеют легитимность только при серти-

фикации по требованиям ФСБ России. Уровень криптографической

защиты персональных данных, обеспечиваемой СКЗИ, определяется

оператором путем отнесения нарушителя (действиям которого долж-

но противостоять криптосредство) к конкретному типу.

К некриптографическим СЗИ требования определены Приказом

ФСТЭК России 2010 г. № 58, а также документами ФСТЭК России, ка-

сающимся систем обнаружения вторжений и систем антивирусной

защиты. С учетом традиционных руководящих документов Гостехко-

миссии России легко получить сводную таблицу требований к подси-

стемам защиты ИСПДн (табл. 2.9) [57].

Из таблицы 2.9 видно, что в настоящее время только по сред-

ствам анализа защищенности пока еще не сформированы требова-

ния по безопасности информации.

2.6. Требования к защите информационных систем

общего пользования

Несмотря на то, что информационный ресурс федеральных ин-

формационных систем общего пользования (порталов, оказываю-

щих конституционные услуги) открытый и общедоступный, он подле-

жит защите сертифицированными средствами. Например, Поста-

новлением Правительства РФ 2009 г. № 424 «Об особенностях под-

ключения федеральных государственных информационных систем

к информационно-телекоммуникационным сетям» определено, что

при подключении таких систем к информационно-телекоммуника-

ционным сетям, доступ к которым не ограничен (например, мета-

сеть Интернет), необходимо использовать СЗИ, прошедшие оценку

соответствия.

Дополнительные требования к СЗИ определены совместным

Приказом ФСБ России и ФСТЭК России 2010 г. № 416/№ 484 «Об ут-

верждении требований о защите информации, содержащихся в ин-

формационных системах общего пользования» в зависимости от

класса системы. Приказ обозначил два класса информационных си-

стем общего пользования (ИСОП):

— системы 1-го класса, в которому относятся ИСОП Правитель-

ства РФ и другие ИСОП, нарушение целостности и доступности ин-

формации, содержащейся в них, может привести к возникновению

угроз безопасности страны.

Сертификация средств защиты информации

Таблица 2.10

Средства защиты информации систем общего пользования

Сертификат соответствия на

Классы средств защиты информации

СЗИ

ИСОП 1

ИСОП 2

СКЗИ (ЭЦП)

ФСБ

СЗИ от неправомерных действий

ФСБ

ФСБ или ФСТЭК

Антивирусные средства

ФСБ

ФСБ или ФСТЭК

Средства контроля доступа

ФСБ

ФСБ или ФСТЭК

Системы обнаружения компьютерных ФСБ

ФСБ или ФСТЭК

атак

Межсетевые экраны

ФСБ

ФСБ или ФСТЭК

— системы 2-го класса, к которым относятся остальные все

ИСОП.

Решение об отнесении к классу ИСОП определяется руководите-

лем соответствующего федерального органа исполнительной власти.

Особенностью объединенного Приказа является введение тре-

бований по использованию сертифицированных классов СЗИ, пред-

ставленных в табл. 2.10.

Заметим, что конкретные требования к классам защищенности

средств защиты общедоступной информации не определены в откры-

той печати, за исключением систем обнаружения вторжений и анти-

вирусных средств для ИСОП 2. Согласно нормативным документам

ФСТЭК России названные средства должны соответствовать ОУД 2+

(усиленный). В остальных случаях необходимо ориентироваться на

модель нарушителя, модель угроз и технологии обрабатываемой ин-

формации.

2.7. Общие критерии оценки безопасности

информационных технологий

В настоящее время в различных системах сертификации прово-

дятся изыскания по созданию и внедрению международной норма-

тивной базы оценки соответствия на основе стандарта ГОСТ Р ИСО/

МЭК 15408 «Информационная технология. Методы и средства обе-

спечения безопасности. Критерии оценки безопасности информа-

ционных технологий». Особенность стандарта состоит в том, что он

Сертификация средств защиты информации

является фактически метастандартом, позволяющим создавать нор-

мативные документы к ИТ-продуктам, причем включающим конкрет-

ные требования как по безопасности (функциональные требования),

так и по качеству (требования доверия), и которые можно предста-

вить в полуформализованном виде [55, 80, 84].

Следует отметить, что стандарту в редакции 2000-го года 22

практически идентичен руководящий документ «Безопасность ин-

формационных технологий. Критерии оценки безопасности ин-

формационных технологий. Части 1, 2, 3» (Гостехкомиссия Рос-

сии, 2002 г.). Именно этот документ является основополагающим

при организации сертификации по инновационным правилам. За

этими документами исторически закрепилось название «Общие

критерии» (ОК), и мы будем придерживаться этой терминологии.

Следует назвать еще нормативно-методические документы

ФСТЭК России, разработанные по линии ОК, например:

— Безопасность информационных технологий. Положение

по разработке профилей защиты и заданий по безопасности (Гостех-

комиссия России, 2003 г.);

— Безопасность информационных технологий. Руководство

по регистрации профилей защиты (Гостехкомиссия России, 2003 г.);

— Безопасность информационных технологий. Руководство

по формированию семейств профилей защиты (Гостехкомиссия Рос-

сии, 2003 г.);

— Руководство по разработке профилей защиты и заданий

по безопасности (Гостехкомиссия России, 2003);

— Требования к системам обнаружения вторжений (ФСТЭК Рос-

сии, 2011 г.);

— Требования к средствам антивирусной защиты (ФСТЭК Рос-

сии, 2012 г.);

— пакет методических документов по профилям защиты [69].

2.7.1. Модель критериев оценки безопасности

информационных технологий

«Общие критерии» включают три части:

1. Введение и общая модель;

2. Функциональные требования безопасности;

3. Требования доверия к безопасности.

22 В н.вр. ожидается редакция ГОСТ 15408—2012, аутентичная ISO/IEC

15408:2008,2009 и Common Criteria 3.1.

Сертификация средств защиты информации

В первой части нормативного документа даются концептуальные

определения процесса оценки соответствия по ОК. В частности, объ-

ект испытаний — объект оценки (ОО) рассматривается не сам по себе,

а в контексте окружающей среды. При подготовке к оценке соответ-

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

так называемые аспекты среды ОО:

— предположения безопасности;

— угрозы безопасности;

— политики безопасности.

Предположения безопасности выделяют ОО из общего контекста

и задают границы его рассмотрения. Предполагается, что среда ОО

удовлетворяет данным предположениям. При проведении оценки

предположения безопасности принимаются без доказательств.

Угрозы безопасности характеризуются следующими параметрами:

— источник угрозы;

— предполагаемый способ реализации угрозы;

— уязвимости, которые являются предпосылкой для реализации

угрозы;

— активы, которые являются целью нападения;

— нарушаемые свойства безопасности активов;

— возможные последствия реализации угрозы.

Выделяются только те угрозы, наличие которых в рассматривае-

мой среде установлено или предполагается.

Аналогично, излагаются положения политики безопасности, при-

меняемые в организации, которые имеют непосредственное отноше-

ние к ОО.

На основании сформулированных предположений безопасно-

сти, при учёте угроз и политик формулируются цели безопасности для

ОО, направленные на обеспечение противостояния угрозам и выпол-

нение положений политики безопасности.

Для достижения поставленных целей к ОО и его среде предъяв-

ляются требования безопасности.

Именно 2-ая и 3-я части нормативного документа представляют

собой каталоги требований безопасности следующих типов:

— функциональные требования — предъявляются к функциям

безопасности ОО и реализующим их механизмам безопасности.

— требования доверия — предъявляются к технологии и процес-

су разработки, эксплуатации и оценки ОО и призваны гарантировать

адекватность реализации механизмов безопасности.

При формулировании требований к ОО могут быть разработаны

два документа:

Сертификация средств защиты информации

— профиль защиты (ПЗ);

— задание по безопасности (ЗБ).

Профиль защиты представляет собой не зависящую от конкрет-

ной реализации совокупность требований для некоторой категории

ОО. Он не привязан к конкретному ОО и представляет собой обоб-

щённый стандартный набор функциональных требований и требова-

ний доверия для определённого класса продуктов (рис. 2.4). Именно

каталог утверждённых (сертифицированных) ПЗ, думается, должен

послужить заменой традиционных руководящих документов Гостех-

комиссии России.

Задание по безопасности — это документ, содержащий требования

безопасности для конкретного ОО и специфицирующий функции

безопасности и меры доверия, предлагаемые ОО для выполнения

установленных требований (рис. 2.5). В ЗБ может быть заявлено со-

ответствие одному или нескольким ПЗ.

ПРОФИЛЬ ЗАЩИТЫ

Идентификация ПЗ

Введение ПЗ

Аннотация ПЗ

Описание ОО

Предположения безопасности

Среда

Угрозы

безопасности

ОО

Политика безопасности организации

Цели безопасности для ОО

Цели

Цели безопасности для среды

безопасности

Требования

безопасности

Функциональные

безопасности

для ОО

требования

ИТ

безопасности ОО

Требования

Замечания

безопасности

Требования доверия

по применению

для среды ИТ

к безопасности ОО

Логическое обоснование целей безопасности

Обоснование

Логическое обоснование требований безопасности

Рис. 2.4. Структура профиля защиты

Сертификация средств защиты информации

ЗАДАНИЕ ПО БЕЗОПАСНОСТИ

Идентификация ЗБ

Введение ЗБ

Аннотация ЗБ

Описание ОО

Соответствие ОК

Предположения безопасности

Среда

Угрозы

безопасности

ОО

Политика безопасности организации

Цели безопасности для ОО

Цели

Цели безопасности для среды

безопасности

Требования

безопасности

Функциональные

безопасности

для ОО

требования

безопасности ОО

ИТ

Требования

Требования доверия

безопасности

к безопасности ОО

Краткая

для среды ИТ

спецификация

Функции безопасности ОО

ОО

Меры доверия

Утверждения о

Ссылка на ПЗ

соответствии ПЗ

Конкретизация ПЗ

Дополнение ПЗ

Логическое обоснование целей безопасности

Обоснование

Логическое обоснование требований безопасности

Логическое обоснование краткой спецификации ОО

Логическое обоснование утверждений о соответствии ПЗ

Рис. 2.5. Структура задания по безопасности

В некотором смысле ЗБ можно рассматривать как техническое

задание на подсистему обеспечения информационной безопасности

для ОО. Именно ЗБ служит основой для проведения оценки ОО с це-

лью демонстрации соответствия его требованиям безопасности.

2.7.2. Функциональные требования безопасности

Систематизированный каталог функциональных требований

безопасности сосредоточен во 2-й части ОК. В текущей редакции

стандарта функциональные требования разбиты на 11 классов, 66 се-

Сертификация средств защиты информации

Функциональный класс

Имя класса

Имя семейства

Представление класса

Характеристика семейства

Функциональные семейства

Ранжирование компонентов

Управление

Аудит

Компоненты

Рис. 2.6. Структура функционального класса

мейств и 135 компонентов. Структура функционального класса при-

ведена на рис. 2.6.

В таблице 2.11 приведена краткая характеристика всех 66 се-

мейств функциональных требований.

Наличие каталога функциональных требований не предполагает

их окончательный и всеобъемлющий характер. В случае необходимо-

Таблица 2.11

Семейства функциональных требований

№

Семей-

п/п

ство

Наименование

Характеристика

Класс FAU — аудит безопасности

FAU_ARP Автоматиче-

Определяются действия, которые не-

ская реакция

обходимо предпринять при выявлении

аудита безопас- возможных нарушений безопасности.

ности

FAU_GEN Генерация дан- Выбираются события, потенциально

ных аудита

подвергаемые аудиту и протоколиро-

ванию.

Определяется минимум регистрируе-

мых данных о событиях безопасности.

Осуществляется привязка событий

к идентификаторам вызвавших их

пользователей.

Сертификация средств защиты информации

Продолжение табл. 2.11

№

Семей-

п/п

ство

Наименование

Характеристика

FAU_SAA Анализ аудита Устанавливаются требования к сред-

безопасности

ствам аудита безопасности, функциони-

рующим:

— на базе правил;

— на базе профилей поведения поль-

зователей;

— на базе сигнатур атак.

FAU_SAR Просмотр ау-

Определяются требования к представ-

дита безопас-

лению данных аудита.

ности

Предоставляются права на просмотр

записей аудита уполномоченным поль-

зователям.

FAU_SEL

Выбор собы-

Определяются требования по отбору

тий аудита без- реально протоколируемых событий

опасности

из числа потенциально подвергаемых

протоколированию.

Выделяются атрибуты, по которым

производится отбор событий.

FAU_STG Хранение дан- Определяются требования по защите

ных аудита без- данных аудита от НСД и повреждения.

опасности

Определяется последовательность

действий, выполняемых системой при

переполнении журнала аудита.

Класс FCO — связь

FCO_NRO Неотказуе-

Задаются требования по ассоциации

мость отправ-

атрибутов отправителя информации

ления

с элементами передаваемых данных.

FCO_NRR Неотказуе-

Задаются требования по ассоциации

мость получе-

атрибутов получателя информации

ния

с элементами передаваемых данных.

Класс FCS — криптографическая поддержка

FCS_CKM Управление

Задаются требования к реализации ме-

криптографи-

ханизмов генерации, распределения

ческими клю-

и уничтожения криптографических

чами

ключей.

10 FCS_COP Криптографи- Декларируется использование тех или

ческие опера-

иных криптографических средств за-

ции

щиты информации.

Сертификация средств защиты информации

Продолжение табл. 2.11

№

Семей-

п/п

ство

Наименование

Характеристика

Класс FDP — защита данных пользователя

11 FDP_ACC Политика

Идентифицируются применяемые по-

управления до- литики управления доступом.

ступом

12 FDP_ACF

Функции

Описываются правила работы функ-

управления до- ций, реализующих заявленные полити-

ступом

ки безопасности.

13 FDP_DAU Аутентифика-

Определяется порядок генерации и ис-

ция данных

пользования данных аутентификации.

14 FDP_ETC Экспорт дан-

Определяется порядок экспорта данных

ных за преде-

за пределы области действия функций

лы действия

безопасности объекта оценки.

ФБО

15 FDP_IFC

Политика

Устанавливаются имена и определяют-

управления ин- ся области действия политик, управляю-

формационны- щих информационными потоками.

ми потоками

Задаются требования к покрытию дан-

ными политиками всех операций пере-

мещения информации.

16 FDP_IFF

Функции

Требуется наличие правил управления

управления ин- информационными потоками.

формационны- Определяются правила контроля ин-

ми потоками

формационных потоков и управления

ими.

17 FDP_ITC

Импорт дан-

Определяется порядок импорта данных

ных из-за пре-

из-за пределов области действия функ-

делов действия ций безопасности объекта оценки.

ФБО

18 FDP_ITT

Передача

Определяется порядок защиты данных

в пределах ОО пользователя при их передаче между

различными частями ОО по внутренне-

му каналу.

19 FDP_RIP

Защита оста-

Задаются требования по уничтожению

точной инфор- предыдущего содержания ресурсов АС

мации

при их освобождении.

20 FDP_ROL Откат

Требуется обеспечение возможности от-

мены последней выполненной операции

(или ряда операций) и возврата к преды-

дущему состоянию.

Сертификация средств защиты информации

Продолжение табл. 2.11

№

Семей-

п/п

ство

Наименование

Характеристика

21 FDP_SDI

Целостность

Задаются требования по контролю це-

хранимых дан- лостности данных пользователя.

ных

22 FDP_UCT Защита кон-

Определяются требования по обеспече-

фиденциаль-

нию конфиденциальности данных поль-

ности данных зователя при их передаче по внешнему

пользователя

каналу между ОО и доверенными внеш-

при передаче

ними объектами ИТ.

между ФБО

23 FDP_UIT

Защита целост- Определяются требования по защите

ности данных целостности данных пользователя при

пользователя

передаче между ФБО.

при передаче

Задаются требования к механизмам кор-

между ФБО

рекции ошибок.

Класс FIA — идентификация и аутентификация

24 FIA_AFL

Отказы аутен-

Задаётся реакция на неудачные запросы

тификации

аутентификации.

25 FIA_ATD Определение

Определяются атрибуты пользователей,

атрибутов

отличные от идентификаторов и ис-

пользователя

пользуемые для реализации установлен-

ных политик.

26 FIA_SOS

Спецификация Задаются требования к механизмам

секретов

проверки качества и генерации секре-

тов (данных аутентификации).

27 FIA_UAU Аутентифика-

Задаются требования к реализации ме-

ция пользова-

ханизмов аутентификации.

теля

Определяются механизмы, доступные

до осуществления аутентификации

пользователя.

28 FIA_UID

Идентифика-

Задаётся порядок идентификации поль-

ция пользова-

зователя.

теля

Определяются действия, которые мо-

гут быть выполнены до идентификации

пользователя.

29 FIA_USB

Связывание

Определяется связь атрибутов безопас-

пользователь-

ности пользователя с субъектом, дей-

субъект

ствующим от имени пользователя.

Сертификация средств защиты информации

Продолжение табл. 2.11

№

Семей-

п/п

ство

Наименование

Характеристика

Класс FMT — управление безопасностью

30 FMT_MOF Управление

Определяются пользователи, уполно-

отдельными

моченные осуществлять управление ре-

функциями

жимами выполнения функций безопас-

ФБО

ности.

31 FMT_MSA Управление

Определяются пользователи, уполномо-

атрибутами

ченные осуществлять управление атри-

безопасности

бутами безопасности.

Регламентируется порядок контроля

безопасности параметров данных атри-

бутов.

32 F M T _ Управление

Определяются пользователи, уполномо-

MTD

данными ФБО ченные осуществлять управление ФБО.

Определяются граничные значения дан-

ных функций безопасности и действия

в случае выхода за допустимые границы.

33 FMT_REV Отмена

Определяется порядок отмены атрибу-

тов безопасности пользователей, субъ-

ектов и объектов.

34 FMT_SAE Срок действия Задаются мероприятия, выполняемые

атрибута без-

по окончании срока действия атрибутов

опасности

безопасности.

35 FMT_SMR Роли управле-

Задаются различные роли пользова-

ния безопасно- телей системы и создаются правила,

стью

управляющие отношениями между ро-

лями.

Класс FPR — приватность

36 FPR_ANO Анонимность

Задаётся возможность выполнения

определённых действий без запроса

идентификатора пользователя

37 FPR_PSE

Псевдоним-

Определяется возможность использова-

ность

ния ресурсов без раскрытия идентифи-

катора пользователя, но с сохранением

подотчётности.

38 FPR_UNL Невозмож-

Требуется невозможность ассоцииро-

ность ассоци-

вания пользователя с применяемым им

ации

сервисом (может потребоваться для за-

щиты от построения поведенческих мо-

делей пользователя).

Сертификация средств защиты информации

Продолжение табл. 2.11

№

Семей-

п/п

ство

Наименование

Характеристика

39 FPR_UNO Скрытность

Требуется предоставление пользовате-

лю возможности работы с определён-

ными сервисами незаметно для кого бы

то ни было.

Класс FPT — защита ФБО

40 FPT_AMT Тестирова-

Задаются требования к тестированию,

ние базовой

демонстрирующему правильность пред-

абстрактной

положений, обеспечиваемых программ-

машины

но-аппаратной платформой, лежащей

в основе функций безопасности.

41 FPT_FLS

Безопасность

Перечисляются типы сбоев, которые не

при сбое

должны приводить к нарушению безо-

пасности системы.

42 FPT_ITA

Доступность

Определяются правила предотвраще-

экспортируе-

ния потери доступности экспортируе-

мых данных

мых данных функций безопасности.

ФБО

43 FPT_ITC

Конфиденци-

Определяются правила защиты от не-

альность экс-

санкционированного раскрытия экс-

портируемых

портируемых данных функций безопас-

данных ФБО

ности.

44 FPT_ITI

Целостность

Определяются правила защиты от не-

экспортируе-

санкционированной модификации экс-

мых данных

портируемых данных функций безопас-

ФБО

ности.

45 FPT_ITT

Передача

Регламентируются требования защиты

данных ФБО

данных функций безопасности при их

в пределах ОО передаче между разделенными частями

ОО по внутреннему каналу

46 FPT_PHP Физическая за- Требуется наличие средств выявления

щита ФБО

и реагирования на несанкционирован-

ный физический доступ к компонентам

ОО.

47 FPT_RCV Надежное вос- Требуется наличие возможности кор-

становление

ректного автоматического или ручного

восстановления функций безопасности

после сбоев.

Сертификация средств защиты информации

Продолжение табл. 2.11

№

Семей-

п/п

ство

Наименование

Характеристика

48 FPT_RPL

Обнаружение Задаются требования по обнаружению

повторного ис- повторного использования сущностей

пользования

различных типов и последующими дей-

ствиями по его устранению.

49 FPT_RVM Посредниче-

Задаются требования по реализации

ство при обра- концепции монитора безопасности об-

щениях

ращений.

50 FPT_SEP

Разделение до- Формулируются требования по органи-

мена

зации защищённого домена для каждой

функции безопасности.

51 FPT_SSP

Протокол син- Требуется надёжное подтверждение

хронизации со- при обмене данными между функциями

стояний

безопасности в распределённой среде.

52 FPT_STM Метки времени Требуется предоставление надёжных

меток времени в пределах ОО (что не-

обходимо, например, для корректной ра-

боты механизмов протоколирования).

53 FPT_TDC Согласован-

Задаются требования по согласованно-

ность данных

сти интерпретации данных, совместно

ФБО между

используемых различными функциями

ФБО

безопасности и другими доверенными

изделиями ИТ.

54 FPT_TRC Согласован-

Определяются требования по синхро-

ность данных

низации данных, дублируемых в преде-

ФБО при ду-

лах ОО.

блировании

в пределах ОО

55 FPT_TST

Самотестиро-

Задаются требования по самотестиро-

вание ФБО

ванию функций безопасности в части

типичных операций с известным ре-

зультатом.

Класс FRU — использование ресурсов

56 FRU_FLT Отказоустой-

Требуется корректное выполнение ча-

чивость

сти функциональных возможностей

в случае сбоев.

57 FRU_PRS Приоритет об- Определяется порядок применения вы-

служивания

сокоприоритетных операций.

Сертификация средств защиты информации

Окончание табл. 2.11

№

Семей-

п/п

ство

Наименование

Характеристика

58 FRU_RSA Распределение Задаются требования к механизму кво-

ресурсов

тирования, используемому для достиже-

ния высокой доступности ресурсов.

Класс FTA — доступ к ОО

59 FTA_LSA Ограничение

Определяются ограничения на атрибу-

области выби-

ты безопасности сеанса, которые может

раемых атри-

выбирать пользователь.

бутов

60 FTA_MCS Ограничение

Задаются требования по ограничению

на параллель-

числа параллельных сеансов, предостав-

ные сеансы

ляемых одному и тому же пользователю.

61 FTA_SSL

Блокирование Определяется возможность блокирова-

сеанса

ния и разблокирования интерактивно-

го сеанса работы пользователя (по же-

ланию пользователя или по инициативе

функций безопасности).

62 FTA_TAB Предупрежде- Определяются требования к отображе-

ния перед пре- нию для пользователей предупреждаю-

доставлением щего сообщения относительно характе-

доступа к ОО

ра использования ОО.

63 FTA_TAH История досту- Задаются требования по отображению

па к ОО

для пользователя при успешном от-

крытии сеанса истории успешных и не-

успешных попыток получить доступ от

имени этого пользователя.

64 FTA_TSE

Открытие се-

Задаются параметры функций безопас-

анса с ОО

ности, на основании которых пользова-

телю может быть отказано в доступе.

Класс FTP — доверенный маршрут/канал

65 FTP_ITC

Доверенный

Определяются правила организации до-

канал переда-

веренного канала между функциями без-

чи между ФБО опасности и другими доверенными про-

дуктами ИТ.

Определяется порядок идентификации

взаимодействующих сторон.

66 FTP_TRP

Доверенный

Определяется порядок организации

маршрут

канала защищённого взаимодействия

между пользователями и функциями

безопасности.

Сертификация средств защиты информации

сти, функциональные требования безопасности, которые отсутству-

ют в каталоге, могут быть сформулированы в явном виде 23.

2.7.3. Требования доверия к безопасности

Требования доверия, приведённые в 3-ей части текущей редак-

ции ОК, сгруппированы в 10 классов, 44 семейства и 93 компонента.

Доверие — степень для уверенности в том, что продукт или система

ИТ отвечают целям безопасности 24. ОК обеспечивают доверие с ис-

пользованием различных методов оценки, например, таким как:

— анализ и проверка процессов и процедур;

— проверка, что процессы и процедуры действительно применя-

ются;

— анализ соответствия между представлениями проекта ОО;

— анализ соответствия каждого представления проекта ОО тре-

бованиям;

— верификация доказательств;

— анализ руководств;

— анализ разработанных функциональных тестов и полученных

результатов;

— независимое функциональное тестирование;

— анализ уязвимостей, включающий предположения о недостат-

ках;

— тестирование проникновением.

Наиболее общую совокупность требований доверия называют

классом. Каждый класс содержит семейства доверия, которые разде-

лены на компоненты доверия, содержащие, в свою очередь, элемен-

ты доверия.

Структура класса доверия приведена на рис. 2.7.

Все семейства доверия в части 3 ОК являются линейно иерархи-

ческими, хотя линейность не обязательна для семейств доверия, ко-

торые могут быть добавлены в дальнейшем. В таблице 2.12 приведена

краткая характеристика всех 44 семейств доверия.

На практике при разработке ПЗ и ЗБ рекомендуется оформлять

требования доверия к ОО в виде одного из определённых в Части 3

ОК оценочных уровней доверия.

Оценочный уровень доверия (ОУД) представляет собой рассчитан-

ную на многократное применение комбинацию требований доверия,

23 ГОСТ Р ИСО/МЭК 15408—2-2008.

24 ГОСТ Р ИСО/МЭК 15408—3-2008.

Методы оценки несоответствия средств защиты информации

Сертификация средств защиты информации

Класс доверия

Имя класса

Представление класса

Семейство доверия

Имя семейства

Цели

Ранжирование компонентов

Замечания по применению

Компонент доверия

Идентификация компонента

Цели

Замечания по применению

Зависимости

Элемент доверия

Рис. 2.7. Структура класса доверия

Таблица 2.12

Семейства доверия

№

п/п Семейство

Наименование

Характеристика

Класс ACM — управление конфигурацией (УК)

ACM_AUT Автоматизация

Устанавливается уровень автомати-

УК

зации, используемый для управле-

ния элементами конфигурации

ACM_CAP

Возможности УК Определяются функциональные ха-

рактеристики системы управления

конфигурацией

Сертификация средств защиты информации

Продолжение табл. 2.12

№

п/п Семейство

Наименование

Характеристика

ACM_SCP

Область УК

Указываются те элементы ОО,

для которых необходим контроль

со стороны системы управления

конфигурацией.

Класс ADO — поставка и эксплуатация

ADO _DEL Поставка

Задаются процедуры, используемые

для поддержки безопасности во вре-

мя передачи ОО пользователю при

первоначальной поставке и при по-

следующих модификациях.

ADO _IGS

Установка, гене-

Обеспечивается, чтобы копия ОО

рация и запуск

была конфигурирована и активизи-

рована администратором так, что-

бы показать те же самые свойства

защиты, что и у оригинала ОО.

Класс ADV — разработка

ADV _FSP

Функциональная Предъявляются требования к со-

спецификация

ставу и содержанию функциональной

спецификации, описывающей функ-

ции безопасности ОО.

ADV _HLD Проект верхнего Предъявляются требования к со-

уровня

ставу и содержанию проекта верхнего

уровня — проектной спецификации

самого высокого уровня, которая

уточняет функциональную специ-

фикацию ФБО в основных состав-

ляющих частях ФБО.

ADV _IMP

Представление

Предъявляются требования к пред-

реализации

ставлению реализации — наименее

абстрактному представлению ФБО.

Оно фиксирует детализированное

внутреннее содержание ФБО на

уровне исходного текста, аппарат-

ных схем и т.д.

ADV _INT

Внутренняя

Задаётся порядок внутреннего

структура ФБО

структурирования функций безо-

пасности ОО.

Сертификация средств защиты информации

Продолжение табл. 2.12

№

п/п Семейство

Наименование

Характеристика

10 ADV _LLD

Проект нижнего Задаются требования к составу и со-

уровня

держанию проекта нижнего уровня —

детализированной проектной спец-

ификации, уточняющей проект

верхнего уровня до уровня детали-

зации, который может быть исполь-

зован как основа для программиро-

вания и/или проектирования аппа-

ратуры.

11 ADV _RCR

Соответствие

Требуется демонстрация отображе-

представлений

ния между всеми смежными парами

имеющихся представлений ФБО, от

краткой спецификации ОО до наи-

менее абстрактного из имеющихся

представлений ФБО.

12 ADV _SPM

Моделирование

Требуется необходимость исполь-

политики без-

зования моделей политики безопасно-

опасности

сти — структурных представлений

политик безопасности ПБО, исполь-

зуемых для обеспечения повышен-

ного доверия тому, что функцио-

нальная спецификация соответству-

ет политикам безопасности из ПБО.

Класс AGD — руководства

13 AGD_ADM Руководство ад-

Задаются требования к составу и со-

министратора

держанию руководства администра-

тора.

14 AGD_USR

Руководство

Задаются требования к составу и со-

пользователя

держанию руководства пользовате-

ля.

Класс ALC — поддержка жизненного цикла

15 ALC_DVS

Безопасность раз- Определяются физические, про-

работки

цедурные, относящиеся к персона-

лу и другие меры безопасности, ис-

пользуемые применительно к среде

разработки.

Сертификация средств защиты информации

Продолжение табл. 2.12

№

п/п Семейство

Наименование

Характеристика

16 ALC_FLR

Устранение недо- Требуется, чтобы недостатки, обна-

статков

руженные потребителями ОО, от-

слеживались и исправлялись в ходе

сопровождения ОО разработчиком.

Оцениваются политики и процеду-

ры, которые разработчик предусмо-

трел для выявления и устранения

недостатков и распространения ис-

правлений потребителям.

17 ALC_LCD

Определение

Задаются требования к технологии

жизненного цик-

разработки, используемой разработ-

ла

чиком для создания ОО.

18 ALC_TAT

Инструменталь-

Задаются требования к инструмен-

ные средства

тальным средствам разработки, ис-

и методы

пользуемым для анализа и создания

ОО.

Класс ATE — тестирование

19 ATE _COV

Покрытие

Предъявляются требования к ана-

лизу полноты функциональных те-

стов, выполненных разработчиком

для ОО.

20 ATE _DPT

Глубина

Определяется уровень детализа-

ции, на котором разработчик про-

веряет ОО.

21 ATE _FUN

Функциональное Задаются требования к содержанию

тестирование

функционального тестирования,

выполняемого разработчиком.

22 ATE _IND

Независимое те-

Определяется объём и порядок не-

стирование

зависимого контроля результатов

функционального тестирования.

Класс AVA — оценка уязвимостей

23 AVA_CCA

Анализ скрытых Определяется порядок выявления

каналов

скрытых каналов передачи инфор-

мации.

Сертификация средств защиты информации

Продолжение табл. 2.12

№

п/п Семейство

Наименование

Характеристика

24 AVA_MSU

Неправильное

Определяется порядок анализа спо-

применение

собности администратора или поль-

зователя, используя руководства,

определить, что ОО конфигуриро-

ван или эксплуатируется небезопас-

ным способом.

25 AVA_SOF

Стойкость функ-

Определяется порядок анализа

ций безопасности стойкости функций безопасности

ОО

ОО, которые реализованы с помо-

щью вероятностного или переста-

новочного механизма (например,

пароля или хэш-функции).

26 AVA_VLA

Анализ уязвимо-

Определяется порядок анализа не-

стей

достатков, которые могли быть вне-

сены на различных этапах разработ-

ки.

Класс AMA — поддержка доверия

27 AMA_AMP План поддержки Идентифицируются планы и проце-

доверия

дуры, которые выполняются разра-

ботчиком для обеспечения поддерж-

ки доверия, установленного к оце-

ненному ОО, после изменений в ОО

или его среде.

28 AMA_CAT Отчет о категори- Определяется порядок категориро-

ровании компо-

вания компонентов ОО (например,

нентов ОО

подсистем ФБО) по их отношению

к безопасности.

29 AMA_EVD Свидетельство

Определяется порядок поддержки

поддержки до-

разработчиком доверия к ОО в со-

верия

ответствии с планом поддержки до-

верия.

30 AMA_SIA

Анализ влияния

Задаётся порядок проводимого раз-

на безопасность

работчиком анализа влияния на без-

опасность всех изменений, воздей-

ствующих на ОО после его оценки.

Сертификация средств защиты информации

Окончание табл. 2.12

№

п/п Семейство

Наименование

Характеристика

Класс APE — оценка профиля защиты

31 APE_DES

Описание ОО

Определяется порядок контроля со-

става и содержания соответствую-

32 APE_ENV

Среда безопас-

щих разделов профиля защиты.

ности

33 APE_INT

Введение ПЗ

34 APE_OBJ

Цели безопасно-

сти

35 APE_REQ

Требования без-

опасности ИТ

36 APE_SRE

Требования без-

опасности ИТ,

сформулирован-

ные в явном виде

Класс ASE — оценка задания по безопасности

37 ASE_DES

Описание ОО

Определяется порядок контроля

состава и содержания соответству-

38 ASE_ENV

Среда безопас-

ющих разделов задания по безопас-

ности

ности.

39 ASE_INT

Введение ЗБ

40 ASE_OBJ

Цели безопасно-

сти

41 ASE_PPC

Утверждения

о соответствии

ПЗ

42 ASE_REQ

Требования без-

опасности ИТ

43 ASE_SRE

Требования без-

опасности ИТ,

сформулирован-

ные в явном виде

44 ASE_TSS

Краткая специ-

фикация ОО

содержащую не более одного компонента из каждого семейства до-

верия.

В стандарте определены 7 оценочных уровней доверия. С возрас-

танием порядкового номера предъявляемые требования усиливаются.

Сертификация средств защиты информации

ОУД 1 предусматривает функциональное тестирование. ОУД 1 при-

меним в тех случаях, когда требуется некоторая уверенность в пра-

вильном функционировании ОО, а угрозы безопасности не рассма-

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

независимое подтверждение утверждения о том, что было уделено

должное внимание защите персональных данных или подобной ин-

формации. Предполагается, что оценка ОУД 1 может успешно прово-

диться без помощи разработчика ОО и с минимальными затратами.

Анализ поддерживается независимым тестированием ФБО.

ОУД 2 предусматривает структурное тестирование. ОУД 2 содер-

жит требование сотрудничества с разработчиком для получения ин-

формации о проекте и результатах тестирования без существенного

увеличения стоимости или затрат времени. Анализ поддерживается

независимым тестированием ФБО, свидетельством разработчика об

испытаниях, основанных на функциональной спецификации, выбо-

рочным независимым подтверждением результатов тестирования

разработчиком, анализом стойкости функций и свидетельством по-

иска разработчиком явных уязвимостей (например, из общедоступ-

ных источников).

ОУД 3 предусматривает методическое тестирование и проверку. ОУД

3 позволяет достичь максимального доверия путем применения над-

лежащего проектирования безопасности без значительного измене-

ния существующей практики качественной разработки. Предпола-

гается проведение всестороннего исследования ОО и процесса его

разработки без существенных затрат на изменение технологии про-

ектирования. Анализ поддерживается независимым тестированием

ФБО, свидетельством разработчика об испытаниях, основанных на

функциональной спецификации и проекте верхнего уровня, выбо-

рочным независимым подтверждением результатов тестирования

разработчиком, анализом стойкости функций и свидетельством по-

иска разработчиком явных уязвимостей (например, из общедоступ-

ных источников).

ОУД 4 предусматривает методическое проектирование, тестирование

и просмотр. ОУД 4 применим, когда разработчикам или пользовате-

лям требуется независимо получаемый уровень доверия от умеренно-

го до высокого в ОО общего назначения и имеется готовность нести

дополнительные, связанные с безопасностью производственные за-

траты. Это самый высокий уровень, на который обычно экономиче-

ски целесообразно ориентироваться для существующих типов про-

дуктов. Анализ поддерживается независимым тестированием ФБО,

Сертификация средств защиты информации

свидетельством разработчика об испытаниях, основанных на функ-

циональной спецификации и проекте верхнего уровня, выборочным

независимым подтверждением результатов тестирования разработ-

чиком, анализом стойкости функций, свидетельством поиска разра-

ботчиком уязвимостей и независимым анализом уязвимостей, демон-

стрирующим противодействие попыткам проникновения нарушите-

лей с низким потенциалом нападения.

ОУД 5 предусматривает полуформальное проектирование и тестиро-

вание. ОУД 5 применим, когда разработчикам или пользователям тре-

буется независимо получаемый высокий уровень доверия для запла-

нированной разработки со строгим подходом к разработке, не вле-

кущим излишних затрат на применение узко специализированных

методов проектирования безопасности. Тем самым, предполагается,

что ОО будут проектироваться и разрабатываться с намерением до-

стичь ОУД 5. Анализ поддерживается независимым тестированием

ФБО, свидетельством разработчика об испытаниях, основанных на

функциональной спецификации, проекте верхнего уровня и проекте

нижнего уровня, выборочным независимым подтверждением резуль-

татов тестирования разработчиком, анализом стойкости функций,

свидетельством поиска разработчиком уязвимостей и независимым

анализом уязвимостей, демонстрирующим противодействие попыт-

кам проникновения нарушителей с умеренным потенциалом нападе-

ния. Анализ также включает проверку правильности анализа разра-

ботчиком скрытых каналов [92].

ОУД 6 предусматривает полуформальную верификацию проекта и те-

стирование. ОУД6 позволяет разработчикам достичь высокого дове-

рия путем применения специальных методов проектирования без-

опасности в строго контролируемой среде разработки с целью по-

лучения высококачественного ОО для защиты высоко оцениваемых

активов от значительных рисков. Анализ поддерживается независи-

мым тестированием ФБО, свидетельством разработчика об испыта-

ниях, основанных на функциональной спецификации, проекте верх-

него уровня и проекте нижнего уровня, выборочным независимым

подтверждением результатов тестирования разработчиком, анали-

зом стойкости функций, свидетельством поиска разработчиком уяз-

вимостей и независимым анализом уязвимостей, демонстрирующим

противодействие попыткам проникновения нарушителей с высоким

потенциалом нападения. Анализ также включает проверку правиль-

ности систематического анализа разработчиком скрытых каналов.

ОУД 7 предусматривает формальную верификацию проекта и тести-

рование. ОУД7 применим при разработке безопасных ОО для исполь-

Сертификация средств защиты информации

зования в ситуациях чрезвычайно высокого риска и/или там, где вы-

сокая ценность активов оправдывает более высокие затраты. Прак-

тическое применение ОУД7 в настоящее время ограничено ОО, кото-

рые строго ориентированы на реализацию функциональных возмож-

ностей безопасности и для которых возможен подробный формаль-

ный анализ. Анализ поддерживается независимым тестированием

ФБО, свидетельством разработчика об испытаниях, основанных на

функциональной спецификации, проекте верхнего уровня, проекте

нижнего уровня и представлении реализации, полным независимым

подтверждением результатов тестирования разработчиком, анали-

зом стойкости функций, свидетельством поиска разработчиком уяз-

вимостей и независимым анализом уязвимостей, демонстрирующим

противодействие попыткам проникновения нарушителей с высоким

потенциалом нападения. Анализ также включает проверку правиль-

ности систематического анализа разработчиком скрытых каналов.

Сводное описание оценочных уровней доверия приведено в та-

блице 2.13. Все уровни являются иерархически упорядоченными,

и каждый ОУД представляет более высокое доверие, чем любой из

Таблица 2.13

Сводное описание оценочных уровней доверия

Компоненты доверия из оценочного

Класс доверия

Семейство

уровня доверия

доверия

ОУД1 ОУД2 ОУД3 ОУД4 ОУД5 ОУД6 ОУД7

Управление

ACM_AUT

конфигураци-

ей

ACM_CAP

ACM_SCP

Поставка и экс- ADO_DEL

плуатация

ADO_IGS

Разработка

ADV_FSP

ADV_HLD

ADV_IMP

ADV_INT

ADV_LLD

ADV_RCR

ADV_SPM

Сертификация средств защиты информации

Окончание табл. 2.13

Компоненты доверия из оценочного

Класс доверия

Семейство

уровня доверия

доверия

ОУД1 ОУД2 ОУД3 ОУД4 ОУД5 ОУД6 ОУД7

Руководства

AGD_ADM

AGD_USR

Поддержка

ALC_DVS

жизненного

цикла

ALC_FLR

ALC_LCD

ALC_TAT

Тестирование

ATE_COV

ATE_DPT

ATE_FUN

ATE_IND

Оценка уязви-

AVA_CCA

мостей

AVA_MSU

AVA_SOF

AVA_VLA

предыдущих. Увеличение доверия от ОУД к ОУД достигается заменой

какого-либо компонента доверия иерархически более высоким компо-

нентом из того же семейства доверия (т. е. увеличением строгости, об-

ласти и/или глубины оценки) и добавлением компонентов доверия из

других семейств доверия (т. е. добавлением новых требований).

Помимо заявленных в части 3 ОК ОУД, можно представлять дру-

гие комбинации компонентов доверия. Операция усиления оценочных

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

мейств доверия, до этого не включенных в ОУД) или замену компо-

нентов доверия в ОУД другими, иерархически более высокими компо-

нентами доверия из того же самого семейства доверия. Исключение

из ОУД какого-либо составляющего его компонента доверия является

недопустимым. В случае, если производится усиление ОУД, необхо-

димо строго обосновать полезность и дополнительную ценность до-

бавленного к ОУД компонента доверия. ОУД может быть также рас-

ширен за счёт применения требований доверия, сформулированных

в явном виде.

Сертификация средств защиты информации

2.7.4. Общая методология оценки безопасности

информационных технологий

Наибольший интерес среди сопутствующих ОК материалов пред-

ставляет ГОСТ Р ИСО/МЭК 18045—2008 «Информационная техно-

логия. Методы и средства обеспечения безопасности. Методология

оценки безопасности информационных технологий», более извест-

ный как «Общая методология оценки» (ОМО). Документ охватывает

все виды деятельности по оценке, соответствующие классам доверия

из части 3 ОК, входящим в оценочные уровни доверия 1—4, кроме свя-

занных с оценкой профилей защиты и заданий по безопасности.

«Общая методология оценки» описывает минимум действий, вы-

полняемых оценщиком при проведении оценки по ОК, с использова-

нием критериев и свидетельств оценки, определенных в ОК. Доку-

мент предназначен, прежде всего, для оценщиков, использующих ОК,

и экспертов органов по сертификации, подтверждающих действия

оценщиков.

Взаимосвязь между ОМО и 3-ей частью ОК показана на рис. 2.8.

Тем самым, ОМО в основном представляет собой детализирован-

ную последовательность действий оценщика при проведении прове-

рок по каждому из компонентов доверия части 3 ОК для ОУД 1—4.

Для более высоких ОУД методология считается в настоящее время

неопределённой.

Процесс оценки состоит из выполнения оценщиком задачи получе-

ния исходных данных для оценки, задачи оформления результатов

оценки и подвидов деятельности по оценке.

По каждому элементу действий оценщик выносит вердикт — поло-

жительный или отрицательный. Общий вердикт является положитель-

Общие критерии

Общая методология оценки

Класс доверия

Вид деятельности

Компонент доверия

Подвид деятельности

Элемент действий оценщика

Действие

Элемент действий разработчика

Элемент содержания и

представления свидетельств

Шаг оценивания

Рис. 2.8. Взаимосвязь между ОК и ОМО

Сертификация средств защиты информации

ным тогда и только тогда, когда все составляющие вердикта положи-

тельные.

Результаты оценки оформляются в виде технического отчёта об

оценке (ТОО), имеющего следующую структуру:

Введение, включающее:

— идентификаторы системы сертификации;

— идентификаторы контроля конфигурации ТОО (название,

дата, номер версии и т.д.);

— идентификаторы контроля конфигурации ЗБ и ОО;

— ссылка на ПЗ;

— идентификатор разработчика;

— идентификатор заявителя;

— идентификатор оценщика.

— Описание архитектуры ОО, представляющее высокоуровне-

вое описание ОО и его главных компонентов, основанное на проекте

верхнего уровня.

1. Оценка, включающая:

— методы, технологии, инструментальные средства и стандарты,

применяемые при оценке;

— сведения об ограничениях, принятых при проведении оценки;

— правовые аспекты оценки, заявления о конфиденциальности

и т.д.

2. Результаты оценки, где для каждого вида деятельности приво-

дятся:

— название рассматриваемого вида деятельности;

— вердикт, сопровождаемый обоснованием, для каждого ком-

понента доверия, определяющего этот вид деятельности, как ре-

зультат выполнения соответствующего действия ОМО и составля-

ющих его шагов оценивания.

3. Выводы и рекомендации:

— общий вердикт;

— рекомендации, которые могут быть полезны для органа

по сертификации.

4. Перечень свидетельств оценки, где для каждого использован-

ного при проведении оценки свидетельства указываются:

— составитель;

— название;

— уникальная ссылка.

5. Перечень сокращений и глоссарий терминов.

6. Сообщения о проблемах:

Сертификация средств защиты информации

— полный перечень сообщений о проблемах;

— их текущее состояние.

Сообщения о проблемах (СП) представляют собой механизм для

запроса разъяснений или для определения проблемы по тому или

иному аспекту оценки. При отрицательном вердикте оценщик обя-

зан представить СП для отражения результата оценки. При этом СП

должны иметь следующую структуру:

— идентификатор оцениваемого ОО;

— задача/подвид деятельности по оценке, при выполнении кото-

рой/которого проблема была выявлена;

— суть проблемы;

— оценка ее серьезности (например, приводит к отрицательному

вердикту, задерживает выполнение оценки или требует решения до

завершения оценки);

— организация, ответственная за решение вопроса;

— рекомендуемые сроки решения;

— влияние на оценку отрицательного результата решения про-

блемы.

Адресаты рассылки СП и процедуры обработки сообщения опре-

деляются правилами, действующими в системе сертификации.

В заключение темы по «Общим критерим», следует отметить, что

основным недостатком ОК является объем и сложность разработки

и восприятия документации по сравнению с традиционными подхо-

дами. В связи с эти можно рекомендовать изучение учебного примера

ЗБ, представленного по адресу: www.cnpo.ru/zb.pdf.

2.8. Современные нормативные документы

ФСТЭК России

Ранее мы отмечали, что на сегодняшний день при проведении

сертификационных испытаний СЗИ по требованиям безопасно-

сти информации в абсолютном большинстве случаев используют-

ся традиционные руководящие документы Гостехкомиссии России

(см. подр. 2.4). Несмотря на некоторое моральное устаревание данных

документов, применение «Общих критериев» при проведении серти-

фикационных испытаний до последнего времени было весьма огра-

ниченно и носило скорее экспериментальный характер.

В то же время перспективы развития оценочных стандартов

в данной области сейчас связаны, прежде всего, с «Общими критери-

ями». В настоящее время в ФСТЭК России разработаны документы,

Сертификация средств защиты информации

Общие требования к тому или иному классу СЗИ

Семейство профилей защиты

Классы

СЗИ

Задание по безопасности

Рис. 2.9. Структура требований для средств защит информации

касающиеся требований к системам обнаружения вторжений и анти-

вирусных средств. Ожидается, что в ближайшее время на базе «Об-

щих критериев» будут разработаны требования к средствам доверен-

ной загрузки, средствам двухфакторной аутентификации, средствам

контроля съемных носителей информации, средствам предотвраще-

ния утечек информации и др.

В общем случае, стандарты нового поколения будут иметь струк-

туру, представленную на рис. 2.9.

Для каждого из основных классов средств защиты информации

будет разработан документ, классифицирующий данный вид средств

защиты и определяющий требования к соответствующему семейству

профилей защиты. В свою очередь, профили защиты должны слу-

жить основанием для разработки заданий по безопасности, на соот-

ветствие которым и будет сертифицироваться конечный продукт.

На момент написания данной монографии ФСТЭК России сфор-

мулировал требования к системам обнаружения вторжений (СОВ)

и системам антивирусной защиты (САВЗ). Документы уже вступи-

ли в силу в 2012 г., но имеют пометку «для служебного пользования».

Профили защиты СОВ и САВЗ, предназначенных для защиты инфор-

мации, не содержащей сведений, составляющих государственную

тайну, являются общедоступными и в настоящее время размещены

на официальном сайте ФСТЭК России [69].

Ожидается, что новые требования к другим классам СЗИ будут

иметь аналогичную структуру.

2.8.1.Требования к системам обнаружения вторжений

В нормативном документе ФСТЭК России «Требования к систе-

мам обнаружения вторжений» под системами обнаружения вторжений

понимаются программные и программно-аппаратные технические

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

в информационных системах действий, направленных на преднаме-

Сертификация средств защиты информации

ренный несанкционированный доступ к информации, а также специ-

альных воздействий на информацию в целях её добывания, уничто-

жения, искажения или блокирования. Система обнаружения вторже-

ний рассматривается как один из базовых элементов системы защиты

информационной системы.

В соответствии с общепринятой практикой [9], в документе вы-

деляются два типа систем обнаружения вторжений: это системы об-

наружения вторжений уровня сети и системы обнаружения вторже-

ний уровня узла. Основной задачей системы обнаружения вторжений

уровня сети является сбор информации о сетевом трафике, переда-

ваемом в пределах информационной системы, и ее дальнейший ана-

лиз с целью выявления вторжений. Система обнаружения вторжений

уровня узла должна обнаруживать вторжения на основе анализа дан-

ных с узлов контролируемой информационной системы, включаю-

щих: сетевой трафик, проходящий через контролируемые узлы, со-

бытия, регистрируемые в журналах аудита операционной системы

и прикладного программного обеспечения, вызовы функций, об-

ращения к ресурсам.

Для каждого из типов выделяются 6 классов защиты систем об-

наружения вторжений, требования ужесточаются от шестого класса

к первому. Каждому классу защиты соответствует определенная кате-

гория информационных систем:

— СОВ, соответствующие 6 классу защиты, применяются в ин-

формационных системах персональных данных 3 и 4 классов;

— СОВ, соответствующие 5 классу защиты, применяются в ин-

формационных системах персональных данных 2 класса;

— СОВ, соответствующие 4 классу защиты, применяются в ин-

формационных системах персональных данных 1 класса, информа-

ционных системах общего пользования II класса, а также в государ-

ственных информационных системах, в которых обрабатывается ин-

формация ограниченного доступа, не содержащая сведений, состав-

ляющих государственную тайну;

— СОВ, соответствующие 3, 2 и 1 классам защиты, применяют-

ся в информационных системах, в которых обрабатывается инфор-

мация, содержащая сведения, составляющих государственную тайну.

Состав функциональных требований к системам обнаружения

вторжений является достаточно традиционным. Помимо непосред-

ственно возможностей по выявлению, анализу и реагированию на

те или иные события, предъявляются требования к системе управле-

ния параметрами СОВ (табл.2.14).

Сертификация средств защиты информации

Таблица 2.14

Функциональные требования безопасности для СОВ уровня сети

4 класса

Компонент

Название компонента

FAU_GEN.1

Генерация данных аудита

FAU_GEN.2

Ассоциация идентификатора пользователя

FAU_SAR.1

Просмотр аудита

FAU_SAR.2

Ограниченный просмотр аудита

FAU_SAR.3

Выборочный просмотр аудита

FMT_MOF.1

Управление режимом выполнения функций безопас-

ности

FMT_MTD.1

Управление данными функций безопасности СОВ

FMT_MTD.2

Управление ограничениями данных функций без-

опасности СОВ

FMT_SMR.1

Роли безопасности

FPT_TST.1

Тестирование функций безопасности СОВ

FID_COL_EXT.1

Сбор данных о сетевом трафике

FID_ANL_EXT.1

Базовый анализ данных СОВ

FID_MTH_EXT.1

Методы анализа

FID_MTH_EXT.2

Детализация эвристического метода анализа

FID_RCT_EXT.1

Базовое реагирование СОВ

FID_PCL_EXT.1

Анализ протоколов

FID_CON_EXT.1

Механизмы администрирования

FID_UPD_EXT.1

Обновление базы решающих правил СОВ

FID_INF_EXT.1

Интерфейс СОВ

Из табл. 2.14 видно, что часть ФТБ сформулирована в явном виде

(имеют постфикс «EXT»). Остальные требования — разработаны на

основе стандартных ФТБ, приведенных во второй части стандарта

ГОСТ Р ИСО/МЭК 15408.

Новый нормативный документ устанавливает требования дове-

рия, сформулированные на основе предопределенных в третьей ча-

сти стандарта ГОСТ Р ИСО/МЭК 15408 оценочных уровней доверия

(ОУД):

Сертификация средств защиты информации

— СОВ 6 класса защиты должны соответствовать ОУД 1+ (усилен-

ный);

— СОВ 5 класса защиты должны соответствовать ОУД 2+;

— СОВ 4 класса защиты должны соответствовать ОУД 3+;

— для СОВ 3, 2 и 1 классов защиты предъявляются требования

более высоких ОУД.

Надо заметить, заявитель должен разработать и реализовать зна-

чительное количество технологических процедур, обеспечивающих

обновление баз решающих правил СОВ. Например, перечень проце-

дур для систем 4 класса представлен в табл. 2.15.

Интерес вызывает уточнение стандартных (приведенных в тре-

тьей части стандарта ГОСТ Р ИСО/МЭК 15408) требований дове-

рия для обеспечения преемственности требованиям по контролю

отсутствия недекларированных возможностей, изложенных в руко-

водящем документе Гостехкомиссии России «Защита от несанкци-

онированного доступа к информации. Часть 1. Программное обе-

спечение средств защиты информации: Классификация по уров-

ню контроля отсутствия недекларированных возможностей» (см.

подр.2.4.4). Например, для 4-го класса защиты разработчик должен

обеспечить представление реализации для всех функций безопас-

ности СОВ на уровне исходных текстов всего программного обе-

спечения, входящего в состав СОВ, а также указать в документации

значения контрольных сумм файлов, входящих в состав СОВ. При

этом, испытательная лаборатория должна сделать независимое за-

ключение, что представление реализации — точное и полное ото-

бражение функциональных требований безопасности СОВ, в том

числе на основе результатов контроля исходного состояния про-

граммного обеспечения и контроля полноты и отсутствия избыточ-

ности исходных текстов на уровне файлов.

Важно отметить, что в документе впервые в отечественной прак-

тике в явном виде допускается обновление баз решающих правил раз-

работчиком. При этом разработчик ежегодно предоставляет в испы-

тательную лабораторию, проводившую испытания соответствующей

системы, подробный отчет обо всех внесенных изменениях и об их

возможном влиянии на безопасность системы. Такой подход позволя-

ет значительно ускорить процедуру обновления по сравнению с тра-

диционным, требовавшим в некоторых случаях проведения инспек-

ционного контроля после внесения каждого изменения в изделие.

В то же время жесткая формализация требований к свидетель-

ствам оценки накладывает определенные обязательства на систему

Сертификация средств защиты информации

Таблица 2.15

Технологические процедуры для СОВ 4 класса

Наименование процедуры

Краткое описание процедуры

Уникальная маркировка

Процедура уникальной маркировки каждого

сертифицированного изделия

Управление конфигурацией Система управления конфигурацией, отсле-

живающая: представление реализации из-

делия, проектную документацию, тестовую

документацию, документацию пользователя,

документацию администратора и документа-

цию управления конфигурацией.

Поставка системы обнару- Процедуры, необходимые для поддержки

жения вторжений пользова- безопасности при распространении версий

телю в соответствии с разра- к местам использования.

ботанной процедурой

Обновления базы решаю- Фиксация момента получения нового типа

щих правил

вторжения.

Выпуск обновления базы сигнатур за задан-

ное время.

Уведомление об обновлении базы сигнатур.

Поставка обновления базы сигнатур.

Контроль целостности обновлений базы

данных решающих правил.

Представление обновлений для проведения

внешнего контроля.

Анализ влияния обновлений на безопас-

ность системы обнаружения вторжений.

менеджмента качества заявителя: перечень документов, которые ему

придется разрабатывать и предоставлять для оценки выглядит доста-

точно внушительным. Так, например, для 4 класса защищенности не-

обходимо разработать следующие документы:

— задание по безопасности;

— руководство по установке;

— функциональная спецификация;

— анализ соответствия между всеми смежными парами имею-

щихся представлений функций безопасности;

— руководство администратора;

— руководство пользователя;

— результаты анализа стойкости функции безопасности;

— описание процедуры фиксации момента появления нового

типа вторжения;

— описание процедуры выпуска обновления базы сигнатур за за-

данное время;

Сертификация средств защиты информации

— описание процедуры уведомления об обновлении базы сигна-

тур;

— описание процедуры поставки обновления базы сигнатур;

— описание процедуры контроля целостности обновлений базы

решающих правил;

— описание процедуры представления обновлений для проведе-

ния внешнего контроля;

— методика анализа влияния обновлений на безопасность систе-

мы обнаружения вторжений.

2.8.2. Требования к средствам антивирусной защиты

В нормативном документе ФСТЭК России «Требования к сред-

ствам антивирусной защиты» под средствами антивирусной защиты

(САВЗ) понимаются программные средства, используемые в целях

обеспечения защиты информации, и реализующие функции обна-

ружения компьютерных программ либо иной компьютерной инфор-

мации, предназначенных для несанкционированного уничтожения,

блокирования, модификации, копирования компьютерной информа-

ции или нейтрализации средств защиты информации (вредоносные

компьютерные программы, компьютерные вирусы), а также реагиро-

вания на обнаружение этих программ и информации. Нормативный

документ выделяет четыре типа САВЗ:

— САВЗ типа «А», предназначенные для централизованного ад-

министрирования САВЗ, установленными на компонентах информа-

ционных систем (серверах, АРМ);

— САВЗ, типа «Б», предназначенные для применения на серверах

информационных систем;

— САВЗ, типа «В», предназначенные для применения на АРМ ин-

формационных систем;

— САВЗ, типа «Б», предназначенные для применения на автоном-

ных АРМ.

Для каждого из типов выделяются 6 классов защиты САВЗ, тре-

бования ужесточаются от шестого класса к первому. Каждому клас-

су защиты соответствует определенная категория информационных

систем:

— САВЗ, соответствующие 6 классу защиты, применяются в ин-

формационных системах персональных данных 3 и 4 классов;

— САВЗ, соответствующие 5 классу защиты, применяются в ин-

формационных системах персональных данных 2 класса;

Сертификация средств защиты информации

— САВЗ, соответствующие 4 классу защиты, применяются в ин-

формационных системах персональных данных 1 класса, информа-

ционных системах общего пользования II класса, а также в государ-

ственных информационных системах, в которых обрабатывается ин-

формация ограниченного доступа, не содержащая сведений, состав-

ляющих государственную тайну;

— САВЗ, соответствующие 3, 2 и 1 классам защиты, применяют-

ся в информационных системах, в которых обрабатывается инфор-

мация, содержащая сведения, составляющих государственную тайну.

Рассматриваемый нормативный документ определяет требова-

ния ко всем 24-м классам САВЗ, в нем в явном виде сформулирова-

ны все функциональные требования и требования доверия, которые

должны войти в соответствующие ПЗ и, в дальнейшем, в ЗБ на кон-

кретные изделия.

По аналогии с требованиями к СОВ, в состав функциональных

требований безопасности к САВЗ, помимо непосредственно возможно-

стей по выявлению и удалению компьютерных вирусов, входят требо-

вания по обновлению базы данных признаков компьютерных вирусов

и требования к системе управления параметрами САВЗ. Важной осо-

бенностью документа является то, что помимо собственно требований

по обнаружению компьютерных вирусов, предъявляются требования

к методам такого обнаружения (сигнатурный, эвристический).

Нормативный документ устанавливает требования доверия,

сформулированные на основе предопределенных в 3-ей части стан-

дарта ГОСТ Р ИСО/МЭК 15408 оценочных уровней доверия (ОУД):

— САВЗ 6 класса защиты должны соответствовать ОУД 1+ (уси-

ленный),

— САВЗ 5 класса защиты — ОУД 2+,

— САВЗ 4 класса защиты — ОУД 3+,

— для САВЗ 3, 2 и 1 классов защиты предъявляются требования

более высоких ОУД.

Как и в случае с СОВ, заявитель должен разработать и реализо-

вать значительное количество технологических процедур и докумен-

тов, обеспечивающих безопасную (доверенную) разработку САВЗ.

Надо заметить, что при проведении сертификации для 4 класса защи-

ты и выше разработчик должен представить в испытательную лабо-

раторию представление реализации функций безопасности САВЗ —

исходные тексты ПО.

В документе в явном виде допускается обновление базы данных

признаков компьютерных вирусов (данное положение представлено

Сертификация средств защиты информации

в виде требований доверия, сформулированных в явном виде). При

этом разработчик ежегодно предоставляет в испытательную лабора-

торию, проводившую испытания САВЗ, подробный отчет обо всех

внесенных изменениях и об их возможном влиянии на безопасность

системы. Такой подход позволяет ускорить процедуру обновления

по сравнению с традиционным, требовавшим в некоторых случаях

проведения инспекционного контроля после внесения каждого изме-

нения в изделие.

3. МЕТРИКИ И МОДЕЛИ ИСПЫТАНИЙ

3.1. Показатели и метрики испытаний

3.1.1. Виды показателей объекта испытаний

При выполнении оценки соответствия по требованиям безопас-

ности информации используются полуколичественные и количе-

ственные показатели. Полуколичественными показателями обычно

выступают частные показатели, оцениваемые по некоторой бальной

шкале. Например, при сертификационных испытаниях на соответ-

ствие традиционным РД используются частные показатели положи-

тельного результата проверок, принимающие значения, скажем, {0,

1}.

Количественные показатели могут принимать различные точ-

ные числовые значения. Примером использования таких показателей

является проведение тематических исследований и сертификацион-

ных испытаний на соответствие ТУ, сертификационных испытаний

по надежности обработки информации, обеспечению полноты, без-

ошибочности, актуальности и защищенности информации в процес-

се функционирования информационных систем и другие [16, 64, 93].

Значения показателей могут быть, например, определены экс-

пертным, регистрационным или расчетным путем.

В подразделах 2.4—2.8 рассмотрены полуколичественные пока-

затели защищенности информации. В таблицах 3.1 и 3.2 приведены

примеры показателей качества, регламентированные национальны-

ми стандартами для программных и автоматизируемых систем: ГОСТ

28195 и ГОСТ 15987 [26].

Допускаются различные подходы к формированию комплексных

показателей, обычно, путем получения полиномиальной зависимости

от частных показателей (метрик):

Метрики и модели испытаний

Таблица 3.1

Частные показатели «технологической безопасности» по ГОСТ 28195

Наименование

Метод оценки

На личие требований к программе Экспертный

по устойчивости функционирования при

наличии ошибок во входных данных

Возможность обработки ошибочных ситу- Экспертный

аций

Полнота обработки ошибочных ситуаций Экспертный

Наличие тестов для проверки допустимых Экспертный

значений входных данных

Наличие системы контроля полноты вход- Экспертный

ных данных

Наличие средств контроля корректности Экспертный

входных данных

Наличие средств контроля непротиворе- Экспертный

чивости входных данных

Наличие требований к программе по вос- Экспертный

становлению процесса выполнения в слу-

чае сбоя операционной системы, процессо-

ра, внешних устройств

Наличие требований к программе по вос- Экспертный

становлению результатов при отказах си-

стемы

Наличие средств восстановления процесса Экспертный

в случае сбоев оборудования

Наличие возможности разделения по вре- Экспертный

мени выполнения отдельных функций про-

грамм

Наличие возможности повторного старта Экспертный

с точки останова

Наличие проверки параметров и адресов Экспертный

по диапазону их значений

Наличие обработки граничных результа- Экспертный

тов

Наличие обработки неопределенностей Экспертный

(деление на 0, квадратный корень из отри-

цательного числа и т.д.)

Метрики и модели испытаний

Продолжение табл. 3.1

Наименование

Метод оценки

Наличие централизованного управления Экспертный

процессами, конкурирующими из-за ре-

сурсов

Наличие возможности автоматически об- Экспертный

ходить ошибочные ситуации в процессе

вычисления

Наличие средств, обеспечивающих завер- Экспертный

шение процесса решения в случае помех

Наличие средств, обеспечивающих выпол- Экспертный

нение программы в сокращенном объеме

в случае ошибок или помех

Показатель устойчивости к искажающим P ( Y) = 1 — D/K, где: D — число

воздействиям

экспериментов, в которых ис-

кажающие воздействия при-

водили к отказу, К- число экс-

периментов, в которых ими-

тировались искажающие воз-

действия

Вероятность безотказной работы

P = 1 — Q/N, где: Q — число заре-

гистрированных отказов, N —

число экспериментов

Оценка по среднему времени восстановле-

1,

если

≤ T доп

ния



Q = T

 доп





, если T > T доп



 T

 в

где: T доп — допустимое сред-

нее время восстановления;

Т — среднее время восстанов-

ления, которое определяется

по формуле:

T =

∑ T ,

где: N — число восстановле-

ний; T — время восстановле-

в i

ния после i-го отказа

Метрики и модели испытаний

Окончание табл. 3.1

Наименование

Метод оценки

Оценка по продолжительности преобразо-



доп

1

≤

вания входного набора данных в выходной

, если T





Q = T доп

 п



, если T > T доп,

 T

п i

 п



где: T доп — допустимое время

преобразования i-го входного

набора данных; T — фактиче-

п i

ская продолжительность пре-

образования i-го входного на-

бора данных

Таблица 3.2

Типовая номенклатура показателей автоматизированных систем [26]

Характеристики качества

Основные показатели качества функциони-

функционирования АС

рования АС, для которых должны быть за-

даны допустимые значения

Надежность представления Средняя наработка объекта на отказ или

запрашиваемой или выда- сбой — Тнар

ваемой принудительно ин-

формации (выполнения за- Среднее время восстановления объекта по-

даваемых технологических сле отказа или сбоя — Т

операций)

вос

Коэффициент готовности объекта — Кг

Вероятность надежного представления и/

или доведения запрашиваемой (выдаваемой

принудительно) выходной информации Р

над

в течение заданного периода функциониро-

вания АС Т

зад

Вероятность надежного выполнения техно-

логических операций Р в течение заданно-

над

го периода функционирования АС Тзад

Метрики и модели испытаний

Окончание табл. 3.2

Характеристики качества

Основные показатели качества функциони-

функционирования АС

рования АС, для которых должны быть за-

даны допустимые значения

Своевременность представ- Среднее время реакции системы при обра-

ления запрашиваемой или ботке запроса и/или доведении информа-

выдаваемой принудительно ции Т

или вероятность своевременной

полн

информации (выполнения обработки информации Р за заданное вре-

св

задаваемых технологиче- мя Тзад

ских операций)

Среднее время выполнения технологиче-

ской операции Т

или вероятность выпол-

полн

нения технологической операции Р за за-

св

данное время Тзад

Полнота используемой ин- Вероятность обеспечения полноты опера-

формации

тивного отражения в АС новых реально су-

ществующих объектов предметной обла-

сти — Рполн

Актуальность используемой Вероятность сохранения актуальности ин-

информации

формации на момент ее использования Ракт

Безошибочность информа- Вероятность Р после отсутствия ошибок

бум

ции после контроля

во входной информации на бумажном носи-

теле при допустимом времени на процедуру

контроля Тзад

Вероятность Р после отсутствия ошибок

маш

во входной информации на машинном носи-

теле при допустимом времени на процедуру

контроля Тзад

Корректность обработки ин- Вероятность Р получения корректных ре-

корр

формации

зультатов обработки информации за задан-

ное время Тзад

Конфиденциальность ин- Вероятность сохранения конфиденциально-

формации

сти информации Р

в течение периода ее

конф

объективной конфиденциальности Тконф

Безошибочность действий Вероятность безошибочных действий долж-

должностных лиц

ностных лиц Р в течение заданного перио-

чел

да функционирования АС Тзад

Защищенность от опасных Вероятность отсутствия опасного воздей-

программно-технических ствия Р в течение заданного периода функ-

возд

воздействий

ционирования АС Тзад

Защищенность от НСД

Вероятность сохранения защищенности от

НСД информационных и программных ре-

сурсов АС РНСД

Метрики и модели испытаний

P =

b p + b p p + b p 2 + …

i i

ij i

ii i

i=1

i j№

i=1

где: bi — коэффициент i-й метрики, k — число метрик.

ГОСТ 28195 регламентирует линейную модель с весовыми коэф-

фициентами иерархических показателей: «фактор-критерий-метри-

ка» (рис. 3.1).

Следует сказать, что в области тестирования ПО измеряемые ко-

личественные частные показатели принято называть метриками.

Обычно выделяют три типа метрик:

— метрики сложности программного кода;

— метрики покрытия программного кода;

— метрики полноты функционального тестирования.

3.1.2. Метрики сложности программного кода

Метрики сложности программного кода являются измеримы-

ми количественными характеристиками особенностей реализации

программ 25. Фактически, эти метрики позволяют получить иденти-

фикационный профиль конкретных программ при статическом ана-

лизе. На практике это позволяет решить задачи аутентификации ПО,

оценить сложность ПО и, как следствие, уровень безошибочности

программного проекта, трудоемкость анализа и доработок ПО, сто-

имость и сроки работ, эффективность технологии разработки и вне-

дрения и др. Часто метрики являются параметрами моделей планиро-

вания испытаний, которые рассмотрены в разделе 3.2.4 [49].

В настоящее время метрики сложности программного кода услов-

но можно разделить на следующие:

— меры длины («объема») программного обеспечения;

— метрики сложности текста программ;

— метрики сложности по управлению;

— метрики сложности по данным;

— объектно-ориентированные метрики;

— интегральные метрики, включающие вышеназванные.

Меры длины кода являются самыми популярными метриками

при предварительной оценке стоимости работ. Основными из них

являются:

— размер дистрибутива в байтах,

25 IEEE Std. 1061—1998.

Метрики и модели испытаний

Фактор

Критерий

Метрика

Полнота

1 Полнота документации

реализации

разработчика

2 Полнoтa программной

документации

Единообразие интерфейсов

3 между модулями и

пользователями

Корректностъ

Согласованность

4 Единообразие кодирования

и определения переменных

5 Непротиворечивость

документации

6 Соответствие документации

стандартам

7 Непротиворечивость

программы

8 Соответствие ПС стандартам

программирования

9 Соответствие ПС

документации

Проверенность

10 Полнота тестирования

проекта

Логическая

корректность

Реализация всех решений

12 Отсутствие явных ошибок

и достаточность реквизитов

Рис. 3.1. Формирование показателя соответствия реальных и декларирован-

ных возможностей по ГОСТ 28195

— размер исходного кода в байтах;

— число строк исходного кода, включая комментарии (SLOC,

source lines of code);

— число операторов (SI, source instructions);

— число функциональных объектов;

— число операторов в эквивалентных командах ассемблера

(AELOC, assembly-equivalent lines of code).

Очень важно, что метрики исходного кода указываются относи-

тельно конкретного языка программирования.

При проведении анализа программного кода меры длины мало

информативны — для этого используются другие классы метрик.

Метрики и модели испытаний

К метрикам сложности текста (линейной сложности) программ

относят измерительные характеристики ПО, касающиеся учета соче-

таний команд программы без анализа ее графа. Наиболее знамениты-

ми являются измерительные метрики Холстеда (Halsted) [82]:

— длина программы N = N + N , где N — число операторов и N —

операндов;

— объем программы (в бит информации) V = N log ( ),

h где

h = h + h — словарь операторов и операндов языка программиро-

вания.

Используя аппарат теории информации и гипотезу Страуда об

умственных операциях, Холстед предложил ряд оценочных метрик

ПО, как-то:

— теоретическая длина программы N = h log h + h log h ;

— теоретический объем программы V = N log ( );

2 h

— уровень программы L =

2 ;

h N

— трудоемкость кодирования D = 1 / L = 1

2 ;

2 h2

— интеллектуальное содержание программы

I = LV =

2 � N log h

( );

I = LV =

2 � N log h

( );

h1 2

h N N log h

— сложность программы E = V / L = 1 2

;

2 2

log h

— время реализации программы (в секундах)

N N

T =

= 1 2

;

36h2

h N N log h

T =

= 1 2

;

36h2

h + h

— число программных ошибок ˆ

log (

)

B =

2 .

3000

Помимо метрик Холстеда, к метрикам линейной сложности

относят всевозможные количественные показатели числа разных

операторов, уровней вложенности, а также комментарий. Напри-

мер, метрики Джилба (Gilb) определяют насыщенность программы

и максимальную вложенность операторами цикла и условными опе-

раторами.

К метрикам сложности по управлению (основанным на управ-

ляющем графе программ) прежде всего относят цикломатическое

число МакКейба (McCabe), характеризующее число независимых

маршрутов в программе:

Метрики и модели испытаний

V G

( ) = e - n +2,

где: e — количество дуг; n — количество вершин управляющего графа

программы.

Цикломатическая сложность программного комплекса, содер-

жащего вызовы подпрограмм, определяется как сумма цикломати-

ческих сложностей самой программы и вызываемых подпрограмм 26.

Существует множество модификаций метрики МакКейба, касаю-

щихся добавления взвешенных коэффициентов сложности линейных

участков, учета уровня вложенности и т.д.

К другим популярным метрикам, основанным на графах разного

рода, относят:

— количество пересечений дуг управляющего графа программы,

известное как метрика Вудворда (Woodward),

— число возможных путей, известное как метрика Шнейдевинда

(Schneidewind),

— цикломатическое число сети Петри,

— число вершин графа параллельности,

— число висячих вершин,

— разница числа входов и выходов вершин управляющего графа

и другие.

К метрикам сложности по данным (основанным на потоке дан-

ных) можно отнести:

— «спен» — число утверждений, содержащих переменную между

ее первым и последним появлением в тексте программы;

— число используемых глобальных переменных в модуле;

— число неиспользуемых информационных объектов;

— соотношение разного рода типов связей по данным между мо-

дулями (подпрограммами);

— соотношение функциональных назначений переменных и др.

Наиболее известным примером последней группы метрик явля-

ется эмпирическая метрика Чепена (Chepen), вычисляемая следую-

щим образом:

Q = P + 2M + 3C + 0,5 T,

где: P — вводимые переменные для расчетов и для обеспечения выво-

да; M — модифицируемые или создаваемые внутри программы перемен-

ные; C — управляющие переменные; T — неиспользуемые переменные.

26 NIST SP 500—235: 1996.

Метрики и модели испытаний

Объектно-ориентированные метрики отражают принципи-

альные особенности парадигмы объектно-ориентированного про-

граммирования и проектирования. Наиболее популярными явля-

ются метрики Ли (Li), а также Чидамбера (Chidamber) и Кемерера

(Kemerer), например:

— количество локальных методов (NLM, number of local methods);

— количество новых методов (NNM, number of new methods);

— количество общедоступных методов в классе (NPM, number of

public methods);

— количество абстрактных классов (NAC, number of abstract

classes);

— количество потомков классов (NDC, number of descendent

classes);

— количество реакций на класс (RFC, responce for class) — число

методов, которые могут выполнить какое-либо действие в ответ на со-

общение, отправленное объектом в этом классе, используя один уро-

вень вложенности;

— отсутствие единства методов (LCOM, lack cohesion of

methods) — число непересекающихся пар методов (не имеющих общих

переменных) за минусом количества подобных пар метода;

— связь через абстрактный тип данных (CTA, coupling through

abstract data type) — число классов, которые используются в качестве

абстрактных типов данных в декларации класса;

— связь через сообщения (CTM, coupling through message

passing) — число различных сообщений, отправленных классом к дру-

гим классам, за исключением сообщений, отправленных объектам,

созданным как локальные объекты в локальных методах класса.

В заключение подраздела следует сказать, что не существует уни-

версальных метрических характеристик ПО — в зависимости от ре-

шающих задач рассматриваются метрики, являющиеся значимыми

для программного проекта [18]. Известно достаточное большое число

анализаторов кода [23,71,74,], которые позволяют рассчитать метри-

ки ПО, например, анализатор безопасности программного кода «АК-

ВС» формирует:

— количество функциональных объектов в проекте;

— количество связей функциональных объектов по управлению;

— количество связей функциональных объектов по информа-

ции;

— общее количество связей функциональных объектов;

— количество висящих функциональных объектов в проекте;

Метрики и модели испытаний

— количество информационных объектов в проекте;

— количество ветвей кода в проекте;

— цикломатическая сложность кода по МакКейбу;

— объем программы по Холстеду;

— количество файлов в проекте;

— количество найденных потенциально опасных конструкций;

— количество файлов с потенциально опасными конструкциями;

— среднее количество объектов в файле;

— средний размер файла;

— объем исходных текстов (Кбайт);

— количество строк кода в проекте.

3.1.3. Метрики покрытия программного кода

Метрики покрытия программного кода используются при струк-

турном тестировании (по методу «белого ящика») с целью подтверж-

дения требуемой полноты проверок и контроля эффективности про-

цесса тестирования, а также выявления наиболее слабо проверенных

модулей и участков кода, тупиковых и избыточных фрагментов и дру-

гих ошибок структуры и логики работы ПО.

Количественная мера покрытия кода часто является частным по-

казателем качества ПО, например:

Q = P × Cov,

где: P — показатель степень безошибочности кода; Cov — показатель

покрытия кода [53].

К наиболее известным метрикам покрытия кода относят следу-

ющие:

— покрытие конструкций;

— покрытие ветвлений условий;

— покрытие условий;

— покрытие веток и условий;

— покрытие маршрутов;

— покрытие потока данных.

Покрытие конструкций (операторов) кода — метрика позволяет

понять, была ли вызвана каждая из исполняемых конструкций кода

(команда).

Частным случаем метрики покрытия конструкций является ме-

трика покрытия базовых блоков, когда в качестве единиц кода вы-

ступает каждая последовательность конструкций без ветвления. За-

Метрики и модели испытаний

метим, что понятие «базовый блок» не совпадает с понятием «ветвь»,

которая всегда начинается с условного оператора 27.

Одним из основных преимуществ метрики покрытия конструк-

ций кода является то, что она может быть применена непосредствен-

но к объектному (бинарному) коду, и при этом ей же можно пользо-

ваться без обработки исходных текстов. По этой причине она получи-

ла широкое распространение и в других областях (например, в про-

филировке кода).

Главный недостаток метрики покрытия конструкций — это от-

сутствие «чувствительности» к некоторым управляющим структу-

рам и логическим операциям. Например, покрытие операторов не

позволяет определить, достигли ли циклы условий своего заверше-

ния — оно лишь показывает, был ли факт хотя бы однократного вы-

полнения тела цикла.

Метрика покрытия ветвлений (decision 28) определяет, были

ли проверены (как на значение true, так и на false) булевы выражения

в управляющих структурах (таких как выражения if или else). Всё бу-

лево выражение целиком считается одним предикатом, который мо-

жет быть либо истинным, либо ложным, вне зависимости от того, со-

держит ли он операторы логического-И или логического-ИЛИ. Мож-

но встретить альтернативные названия метрики: покрытие ветвей

(branch), покрытие ребер, покрытие дуг.

Основное преимущество этой метрики — простота и отсутствие

проблем с покрытием операторов.

Ее же недостатком является то, что метрика игнорирует ветви

внутри булевых выражений, которые происходят в случае использо-

вания сокращенной схемы вычислений.

Метрика покрытия по условиям возвращает вывод «истина»

или «ложь» для каждого условия в программе. Условие — это операнд

логического оператора, который не содержит внутри себя других ло-

гических операторов. Покрытие по условиям измеряет условия неза-

висимо друг от друга.

Эта метрика во многом схожа с покрытием ветвей условий, но

она имеет более высокую чувствительность к потоку выполнения.

В стандартах 29 разделяют покрытие ветвлений и покрытие усло-

вий, считая первое более слабым. Однако полное покрытие по усло-

27 IEEE Std 100—1992.

28 RTCA/DO-178BВ. FAA, 1992.

29 Там же.

Метрики и модели испытаний

виям не гарантирует полного покрытия ветвей условий (из проблемы

«мертвого кода»).

Метрика покрытия по веткам и условиям — это гибридный ме-

тод, полученный на основе объединения покрытия ветвлений и по-

крытия условий. Его основное преимущество — это простота и отсут-

ствие ограничений его компонентных метрик.

Метрика покрытия маршрутов выдает информацию о том,

были ли пройдены все возможные маршруты в каждой функции.

Маршрутом называют уникальную последовательность ветвей логи-

ческих условий (branches) от входа в функцию до выхода из неё. Эта

метрика также известна под названием «покрытие предикатов».

У покрытия маршрутов имеются два принципиальных недостат-

ка. Первым является то, что число маршрутов экспоненциально зави-

сит от числа ветвей. Например, функция, содержащая 10 выражений

типа if, будет требовать для тестирования 1024 маршрута. Добавление

хотя бы ещё одного выражения if удваивает их число до 2048. Второй

недостаток — многие маршруты просто невозможно выполнить из-за

связей по информации.

Еще один недостаток касается циклов. Поскольку циклы приво-

дят к неограниченному количеству маршрутов, данная метрика рас-

сматривает лишь ограниченное количество возможных итераций.

Однако имеется огромное количество вариаций этой метрики, рабо-

тающих с циклами. Например, граничное тестирование маршру-

тов, которое предполагает лишь две ситуации для циклов в програм-

ме: нулевое число повторов и отличное от нуля число повторов. Для

циклов do-while возможны следующие два варианта: с одной итераци-

ей и большим, чем одна итерация.

Метрику покрытия потока данных относят к вариации покры-

тия маршрутов, когда рассматриваются только подмаршруты от при-

сваивания переменных до последующих ссылок на эти переменные.

Преимуществом этой метрики является то, что обнаруженные

с помощью нее маршруты имеют непосредственное отношение к ре-

жиму, в котором программа обрабатывает данные. Основной её недо-

статок — сложность реализации.

Кроме перечисленных фундаментальных метрик, известны ме-

трики, используемые на практике при решении отдельных задач:

— метрика покрытия функций (процедур);

— метрика покрытия вызовов;

— метрика покрытия циклов;

— метрика покрытия операторов сравнения;

Метрики и модели испытаний

— метрика покрытия по гонкам;

— метрика покрытия таблиц (массивов).

Мы можем сравнить относительные преимущества показателей,

при этом более сильная метрика включает в себя результаты более

слабой метрики.

Например, покрытие ветвлений условий включает в себя по-

крытие конструкций, поскольку выполнение каждой ветви должно,

по идее, привести к выполнению каждой её конструкции. Но это ут-

верждение справедливо, только когда поток выполнения непрерывен

до самого конца всех базовых блоков. Например, C/C++ функция мо-

жет никогда не вернуть управление вызвавшему её базовому блоку,

поскольку внутри неё используются throw, abort, семейство вызовов

exec, exit или long jmp.

Покрытие по ветвям/условиям включает в себя покрытие ветвле-

ний условий и покрытие по условиям (по определению). Покрытие

маршрутов включает в себя покрытие ветвей условий.

Анализ покрытия кода является одним из методов структурного

тестирования, которые помогают обеспечить целостность и отсут-

ствие пропусков в тестовом наборе. При анализе кода продуктов, раз-

работанных на самых распространенных языках программирования

(C/C++ и Java) из всех метрик наиболее универсальной и эффектив-

ной в целом показало себя покрытие по ветвям/условиям.

Разумеется, из-за чрезвычайно высокой сложности ПО контроль

покрытия кода ограничивается разумной долей детализации.

3.1.4. Метрики полноты функционального тестирования

Метрики полноты функционального тестирования (по методу

«черного ящика») раскрывают содержание тестовых процедур, с од-

ной стороны, и позволяют детально оценить уровень завершенности

тестирования в процессе работ — с другой.

При проведении функционального тестирования ПО полнота

тестирования, как правило, оценивается по следующим параметрам:

— полнота покрытия требований;

— подсистем (модулей) ПО;

— полнота функциональных возможностей;

— полнота пространства входных параметров.

Полнота покрытия требований описывается следующей фор-

мулой:

M = t ,

тр

Метрики и модели испытаний

где: R — число требований, предъявляемых к ПО, проверенных

в ходе тестирования набором тестовых процедур, R — общее число

требований, предъявляемых к ПО.

В ходе разработки набора тестовых процедур {t , t ,..., t ,..., t }

выполняется сопоставление требования r ∈ R , предъявляемого

к ПО, и тестовых процедур, которые тестируют выполнение данного

требования. Для наглядности данное сопоставление представляют

в форме матрицы трассировки: в заголовках колонок матрицы (табл.

3.3) расположены требования r , а в заголовках строк — процедуры

тестирования t . На пересечении расположена отметка, означающая,

что требование текущей колонки покрыто процедурой тестирования

текущей строки.

В качестве метрики полноты покрытия подсистем (модулей)

ПО можно выбрать следующее соотношение:

M = t ,

где: S t — число подсистем (модулей) ПО, проверенных в ходе тести-

рования набором тестовых процедур, S — общее число подсистем (мо-

дулей, функциональных объектов) ПО. Предполагается, что тестиру-

емое ПО состоит из совокупности подсистем (например, подсистема

контроля целостности), а подсистемы — из модулей (например, a.exe,

b.dll). Для наглядности данное сопоставление представляют в форме

матрицы покрытия тестовыми процедурами (табл. 3.4, m j — i-й модуль

j-й подсистемы).

Полнота покрытия функциональных возможностей описыва-

ется следующей формулой:

M = t ,

где: Fτ — число функциональных возможностей ПО, проверенных

в ходе тестирования набором тестовых процедур {t , t ,..., t ,..., t };

F — общее число функциональных возможностей ПО. По аналогии

с метрикой покрытия требований можно ввести понятие матрицы

трассировки функциональных возможностей (табл. 3.5): в заголовках

колонок таблицы расположены функциональные возможности f , а в

заголовках строк — процедуры тестирования τ . j

Рассмотрим метрику полноты покрытия входных параме-

тров. Пусть A = {a , a ,..., a } — множество параметров, при-

Метрики и модели испытаний

Таблица 3.3

Матрица трассировки требований

Тестовая

Требование

процедура

…

нимаемых на вход тестируемым ПО P (факторы тестирования),

а B = {b ,b ,...,b } — множество выходных параметров тести-

руемого ПО. Каждый параметр может принимать одно из не-

скольких значений: a

∈ D , b

∈ D , где DP и DP — области до-

пустимых значений входного α и выходного β параметров со-

ответственно. При тестировании на вход ПО подается кортеж

a = a

( , a ,..., a ) ∈ P × P

× P

D и выполняется сравнение факти-

ческого поведения ПО b = b

( ,b ,...,b ) =

( ) ∈ P × P ...× P

с ожидаемым b , определенным в спецификации.

Полноту покрытия пространства входных параметров можно

оценить следующим образом:

DP DP … DP

вх

DP DP … DP

где: ˆ

DP — мощность множества значений входного параметра α i, по-

a i

крытого при выполнении тестирования, DP — мощность множе-

a i

ства значений входного параметра α . i

Таким образом, при выполнении полного тестирования

на вход ПО должно быть подано DP

⋅ DP

⋅... ⋅ DP

корте-

жей a . Для оценки сложности проблемы тестирования положим

DP = DP = ... = DP = N , тогда мощность пространства входных

значений равна N s . Пусть некоторая программа принимает на вход

s = 34 бинарных ( N = 2) значения. При проведении тестирования на

всем пространстве значений входных параметров на вход ПО необхо-

Метрики и модели испытаний

Таблица 3.4

Матрица покрытия подсистем (модулей)

Объект тестирования

Тестовая

Подсистема 1

Подсистема 2

…

Подсистема h

процедура

…

Таблица 3.5

Матрица трассировки функциональных возможностей

Тестовая

Требование

процедура

…

дим подать 234 = 1,7 · 1010 кортежа. Для современного ПО проведение

тестирования на всем пространстве значений входных параметров

(исчерпывающее тестирование) является практически неразреши-

мой задачей.

К основным путям решения данной проблемы следует отнести

следующие.

1. Тестирования с использованием случайных значений

входных параметров. Значение компонент α входного кортежа

a = a

( , a ,..., a ) генерируются случайным образом из областей до-

пустимых значений DP . Тестирование заканчивается при достиже-

a i

нии приемлемого покрытия пространства входных значений.

2. Тестирования с использованием разбиения области допу-

стимых значений на эквивалентные подмножества. Области допу-

стимых значений DP компонент входного кортежа разбиваются

a i

на подмножества, значения которых считаются эквивалентными

Метрики и модели испытаний

с точки зрения функциональных особенностей тестируемого ПО:

DP = DP ∪ DP ∪ ... ∪ DP . При тестировании на вход ПО в качестве

i 1

i 2

компонента кортежа подается один представитель подмножества

DP .

a il 3. Тестирование граничных значений. При использовании дан-

ной стратегии в первую очередь тестируются граничные значения об-

ластей допустимых значений DP компонент входного кортежа.

a i

4. Тестирование методом комбинаторного покрытия. При ис-

пользовании метода t-факторного комбинаторного покрытия выпол-

няется генерация входных кортежей, покрывающих все возможные

значения подкортежей из t компонент 30.

3.2. Модели оценки технологической безопасности

и планирования испытаний

Одним из путей повышения уровня безопасности ПО является

использование на этапах тестирования и испытаний ПО математи-

ческих моделей, позволяющих получить достоверные оценки показа-

телей безопасности ПО и эффективности технологии его разработ-

ки. Большинство таких моделей заимствованы из теории надежности

технических систем, поэтому в литературе их часто называют моде-

лями надежности ПО [72, 85]. С точки зрения испытаний программ-

ных средств по требованиям безопасности информации, понятие

«надежность функционирования ПО» эквивалентно понятию «тех-

нологической безопасности ПО», где под ошибкой понимается уязви-

мость (дефект, недекларированная возможность), потенциально вли-

яющая на безопасность системы и инфраструктуры [17, 44].

Опыт испытательных лабораторий показывает, что применение

математических моделей не должно отвлекать экспертов от реального

трудоемкого и ответственного процесса исследования ПО и должно,

главным образом, способствовать принятию правильных решений.

Поэтому модели целесообразно классифицировать по целевому при-

знаку и имеющимся входным статистикам, получаемым на различных

этапах жизненного цикла ПО, а именно на следующие:

1. Отладочные модели, позволяющие оценить показатели техно-

логической безопасности ПО в зависимости от прогонов на заданных

областях входных данных и последующих доработок ПО;

30 NIST SP 800—53A: 2010; NIST SP 800—142: 2010.

Метрики и модели испытаний

2. Временные модели роста надежности, позволяющие оценить

показатели технологической безопасности ПО в зависимости от вре-

мени испытаний;

3. Модели полноты тестирования, позволяющие получить оцен-

ки показателей доверия к процессу оценки соответствия ПО;

4. Модели сложности ПО, позволяющие оценить метрики слож-

ности ПО и связанные с ними показатели качества и безопасности

ПО.

3.2.1. Отладочные модели программ

В основе отладочных моделей лежит утверждение, что свойство

надежности программы меняется только при ее доработках, а изме-

ряется путем прогона программы на заданных областях входных дан-

ных. Такие модели часто называют моделями надежности, основан-

ными на областях входных данных (input-domain models).

Условно отладочные модели можно разделить на модели, ориен-

тированные на величину доработки [53], и модели, ориентированные

на покрытие входных данных [70,78]. Приведем примеры подобных

моделей.

3.2.1.1. Немонотонная модель отладки

и обновлений программного обеспечения

В основе модели положена гипотеза, что степень надежности

ПО при его изменениях может как повышаться, так и понижаться

(рис. 3.2):

P = P +

∑ ,

j =1

где: u — число проведенных доработок ПО, ∆ P — приращение степени

надежности после j-й доработки.

Изменение степени надежности ПО после j-й доработки можно

представить линейным оператором:

D P = A (1- P

-1 ) - B P

j -1

где: P — вероятность безошибочной работы ПО после ( j - 1)-й дора-

j - 1

ботки; (1 - P ) — вероятность обнаружения ошибок ПО после ( j - 1)-й

j - 1

доработки; A — коэффициент эффективности доработки, характери-

зующий уменьшение вероятности ошибки за счет j-й доработки; B —

100

Метрики и модели испытаний

P∞

P 0

1 2

u-1

доработки

0 1 2 3 4 5 …

… L – 1 L

прогоны

Рис. 3.2. Изменение степени надежности по результатам доработок

коэффициент негативности доработки, характеризующий снижение

степени надежности за счет j-й доработки.

Перейдя к рекуррентному выражению и считая предельную сте-

пень надежности равной P

, можно получить модель оцен-

∞

A + B

ки надежности ПО:

P = P -

∞

( P - P

∞

0 ) ∏( - A

P∞)

j =1

Для учета различной степени эффективности доработки можно

ввести метрику величины измененного кода kij, например, при ис-

правлении ошибок и при обновлении ПО. Это позволяет получить

основное расчетное выражение для показателя надежности ПО:

u 



P = P -

∞

( P - P

∞

0 )

 - a k P 

∏

∑

∞ 



i ij





j =1 

i=1



где: α — коэффициент эффективности доработки ПО с целью исправ-

ления ошибки или обновления; P — начальная степень надежности;

P∞ — предельная степень надежности.

Данная модель зависит от 4-х параметров ( P , P

, α ), расчет ко-

∞, α1

торых удобно осуществить, например, с помощью метода максималь-

ного правдоподобия [53].

Приведем пример расчета параметров модели. В качестве ис-

ходной статистики можно использовать множества испытаний { n} и

101

Метрики и модели испытаний

отказов { ˆ m } между доработками, а также множество метрик по до-

работкам { k }. Тогда при допущениях о независимости прогонов ПО

функция максимального правдоподобия представляет собой вероят-

ность получения общей выборки ( n , mˆ , j = ,

1 u ) числа отказов в про-

веденных сериях прогонов ПО:

- ˆ

j P n m

j 1

(

P mˆ j

- ) .

∏ m j

j =1

Для удобства можно прологарифмировать и преобразовать функ-

цию Lu к следующему виду:

u 



j 







a k 







2 a k





 ˆ ln 1







∑

 + ( n - ˆ m ) ln P -( P - P ) (1-

i ij ).



∞

( P P

i ij

- +

∞



0 )



∏ -





∑



∞



∏

∑









P 





1 



=1 



i=1

∞ 



l =1

i=1

∞ 

u 



j 







a k 







2 a k





 ˆ ln 1







∑

 + ( n - ˆ m ) ln P -( P - P ) (1-

i ij ).



∞

( P P

i ij

- +

∞



0 )



∏ -





∑



∞



∏

∑









P 





1 



=1 



i=1

∞ 



l =1

i=1

∞ 

Полученная функция является выпуклой и задана на выпуклом

множестве. Поэтому, для нахождения максимума функции правдо-

подобия можно, например, использовать модифицированный метод

наискорейшего спуска с переменным параметром шага h:





∂ ln L ( P r , P r , ar , ar ) 

P r 1

+ = P r + h

∞



 







∂







 





∂ ln L ( r+

P 1, P r , ar , ar



∞

2 )



P r 1

+ = P r + 



∞





∞







∂







∞

 



,

∂ ln L ( P r 1

+ , P r 1

+ , ar , ar



∞

) 

r +

a 1 = ar + h



 



 



∂







 





∂

L ( Pr 1

P r 1

+ ar 1

, ar 

∞

)

ar 1

+ = ar + h











∂









где: r — номер итерации.

Следует сказать, что модель позволяет получить формулы для пла-

нирования испытаний, например, рассчитать число j необходимых до-

работок ПО для достижения требуемой степени надежности P :

тр

102

Метрики и модели испытаний





P - P











ln ∞

тр 















 



 P - P  



 ∞

 

ceil







 ,

ln(1 - a / P 

∞ )

где: a — усредненный коэффициент эффективности доработки ПО.

Считая, что при доработках не вносятся дополнительные ошиб-

ки, т. е. B = 0, можно получить формулу числа оставшихся ошибок по-

сле u-й доработки:



1 - P







0 

ln(

)





1 - P 

ceil 



.

 ln(1 - a) 

3.2.1.2. Структурная модель Нельсона

Модель, получившая название модели Нельсона (Nelson) [78], яв-

ляется биноминальной моделью Бернулли с наложенными правила-

ми по использованию входных данных.

В частности, область входных данных ПО задается в виде k не-

пересекающихся областей — { Z }, которым однозначно соответствует

множество вероятностей { p } того, что соответствующий набор дан-

ных будет выбран для очередного прогона ПО. Таким образом, если

при выполнении N прогонов программы (на Z наборе входных дан-

ных) n из них закончились отказом, то степень надежности функци-

онирования ПО определяется выражением:

= 1 -

∑

N i

i=1

Модель позволяет рассчитать вероятность P безотказного вы-

полнения n прогонов программы:

 u











ln(1 Q

∑ - )

j 

P =

(

- ) = e



j 1

,

∏

j =1

где: Q =

p c ; χ — характеристическая функция отказа на i-ом на-

∑ ji i i

i=1

боре данных; p — вероятность появления i-го набора в j-ом прогоне.

103

Метрики и модели испытаний

Заметим, в структурной модификации модели Нельсона пред-

лагается для нахождения p использовать анализ графа ПО. К сожа-

лению, проведение анализа структурно-сложного модифицируемого

ПО для решения указанных задач на практике не представляется эф-

фективным 31.

Можно продемонстрировать переход от моделей отладки к вре-

менным моделям. Полагая, что ∆ t — время выполнения j-го прогона,

можно получить следующее расчетное выражение:

(

l t( ) t

∑

D )

P = e j=1

-ln(1 - Q )

где: l t

( ) =

— интенсивность отказов; t =

∑D — сум-

i=1

марное время выполнения j прогонов ПО.

Полагая, что ∆ t становится относительно малой величиной c

ростом u-числа испытаний, имеем известную формулу безотказной

работы технических средств (экспоненциальная временная NHPP-

модель роста надежности):

- l z

( d) z

∫

P t() = e 0

где: λ( z) — функция риска.

Несмотря на очевидную адекватность моделей отладки процессу

доработки ПО, к общим недостаткам моделей отладки относят тре-

бования по большому количеству испытаний для получения точных

оценок. Однако данная категория трудностей решается путем приме-

нения статистического метода Вальда [37,76].

3.2.2. Модели роста надежности от времени

Модели роста надежности (reliability growth model) относят к ве-

роятностным динамическим моделям дискретных систем с непрерыв-

ным или дискретным временем [12,21,43,49,76,85,90]. Большинство

популярных моделей данного класса можно свести к Марковским од-

нородным, неоднородным или полумарковским моделям массового

обслуживания.

В однородных Марковских моделях полагается, что общее чис-

ло ошибок ПО — неизвестная конечная постоянная величина. Число

31 IEEE Guide to SWEBOK, 2004.

104

Метрики и модели испытаний

ошибок, оставшихся в ПО в процессе тестирования и отладки, опи-

сывается экспоненциальным законом распределения. Интенсивность

ошибок λ( i) зависит от текущего i-состояния системы и не зависит от

прошлых состояний.

По сравнению с однородными Марковскими моделями, в полу-

марковских моделях полагается, что λ( t ) интенсивность ошибок за-

висит не только от числа оставшихся ошибок в ПО, но и от t времени

в этом состоянии.

В настоящее время все более популярным классом временных

моделей становятся неоднородные Марковские модели. В данных

моделях общее число ошибок ПО является случайной величиной,

описываемой Пуассоновским законом распределения, причем интен-

сивность потока ошибок не является линейной функцией от време-

ни. По этой причине модели часто называют Пуассоновскими (Non-

Homogeneous Poisson Process model, NHPP-модели). В зависимости от

вида функции интенсивности Пуассоновского потока NHPP-модели

разделяют на выпуклые, S-образные, бесконечные.

Существуют модификации моделей надежности ПО путем приме-

нения Байесовского подхода, которые иногда выделяют в отдельный

класс моделей [99].

Следует сказать, что для расчета параметров динамических моде-

лей традиционно используется метод максимального правдоподобия,

в редких случаях — методы линейной регрессии.

Приведем примеры самых популярных временных моделей роста

надежности каждого вида.

3.2.2.1. Экспоненциальная модель роста надежности программ

Экспоненциальная модель роста надежности, получившая назва-

ние модели Елинского-Моранды (Jelinski-Moranda, JM-модель), осно-

вана на допущениях, что в процессе тестирования ПО длительность

интервалов времени между обнаружением двух ошибок имеет экспо-

ненциальное распределение с интенсивностью отказов, пропорци-

ональной числу необнаруженных ошибок. Все ошибки одного типа,

равновероятны и независимы друг от друга. Каждая обнаруженная

ошибка мгновенно устраняется, число оставшихся ошибок уменьша-

ется на единицу 32.

Согласно указанным предположениям интенсивность ошибок

в JM-модели имеет следующий вид:

32 IEEE Std. 1633—2008.

105

Метрики и модели испытаний

l = f( N - i( - )

1 ,

где: N — число ошибок, первоначально присутствующих в программе;

( i — 1) — число обнаруженных ошибок.

Функция плотности распределения времени обнаружения i-й

ошибки, отсчитываемого от момента выявления ( i — 1)-й ошибки, име-

ет вид:

f t

l e-l t = f N

(

))

1 e-f( N-( i- ))

1 t

i i

( ) =

- -

где: φ — коэффициент пропорциональности, интерпретируемый как

интенсивность выявления ошибок; N — число ошибок, первоначально

присутствующих в программе; ti — интервал между ( i — 1)-й и i-й ошиб-

ками.

Полученное выражение позволяет, например, найти формулы

для вероятности безошибочной работы, вероятности устранения

всех ошибок за заданное время [76], средней наработки на ошибку,

среднего времени устранения всех ошибок:

P t

f t dt

e-l t

-f( N -( i- ))

i i

1 ti

( ) = ∫ ( ) =

;

N i

Ci-1

(

l зад

;

зад ) =

- N

N -

∑( )

e- ti

≥ N

N - i( -1)

i=1

∞

t = tf t

∫ ( ) dt = =

;

( N ( i )1

- -

N  

t =

 

∑ .

 i 

i=1

JM-модель имеет два неизвестных параметра: N и φ. Приведем

пример получения параметров модели, используя метод максималь-

ного правдоподобия. В качестве исходной статистики можно исполь-

зовать множество интервалов времени между отказами ˆ t

{ }. Тогда

при допущениях о независимости данной выборки функция макси-

мального правдоподобия представляет собой произведение функций

плотностей f ( t ):

106

Метрики и модели испытаний

f t

∏

(f( N i( )1 e- (f N- i(- )1 t) i

( ) =

- -

)×

i=1 u

×∏ f( N - i( - )

1 e- (f N -( i- )1

(

ti ).

i=1

Для случая u = N можно получить формулу:

-f

( N - i(- )

1 t

∑

)

L = N

f e i=

Прологарифмировав функцию и найдя ее производные, получа-

ем условия нахождения экстремума:

 u 

















f t

 ∑

=0







1 



( - ) - 





 u



1









 -







( N - i

∑

( - )1 t =0



f

i 

 i=1

Решение системы уравнения можно найти численными методами.

В табл. 3.6 представлены примеры популярных Марковских моде-

лей, причем, параметр N интерпретируется в качестве числа первона-

чальных ошибок в ПО [49].

Таблица 3.6

Марковские модели роста надежности программ

Название модели

Интенсивность ошибок, λ i

JM-модель*

f( N -( i - ))

Модель Липова

i-1

f( N -

N )

∑

j =1

Xui-модель

f( e k

- ( N i

- + )

1 - )

Shanthikumar-модель

f( N ( i

)) k

- -1

Bucchianico-модель

i 1

- -

f( ( ))

JM-отладочная модель

f( N - p( i - ))

* IEEE Std. 1633—2008.

107

Метрики и модели испытаний

3.3.2.2. Рэлеевская модель роста надежности программ

Развитием JM-модели является модель Шэка-Волвертона (Schick-

Wolverton, SW-модель), в которой полагается, что интенсивность оши-

бок пропорциональна не только количеству необнаруженных ошибок

в ПО, но и интервалу времени отладки:

l = f( N - i( -1 )) t ,

где: N — число ошибок, первоначально присутствующих в программе;

i — число обнаруженных ошибок; j — коэффициент пропорционально-

сти, интерпретируемый как интенсивность выявления ошибок, t —

интервал времени между ( i–1) -й и i-й ошибками.

Отсюда выводится распределение Рэлея со следующей функцией

плотности:

t 2 i

1 )

f t

( ) = f( N - i( -1 )) t e- N- i(- 2 ,

причем, параметр релеевского распределения

s = 1 / f( N -( i -1 ))

Полученное выражение позволяет, например, найти форму-

лы для вероятности безошибочной работы и средней наработки на

ошибку:

 t 2 













1 )

P t

( ) = e



-( -



0  = e

2 ;

t =

s =

2 0

2 ( N - i( -1 )

)

Для расчета значений параметров N и φ модели по аналогии с JM-

моделью удобно использовать метод максимального правдоподобия.

Примеры популярных полумарковских моделей представлены

в таблице 3.7, причем параметр N также интерпретируется как число

первоначальных ошибок в ПО [49].

3.3.2.3. Экспоненциальная NHPP-модель роста надежности

программ

Первая NHPP-модель предложена Гоул и Окьюмотиу (Goel-

Okumoto, GO-модель). В GO-модели полагается, что количество оши-

108

Метрики и модели испытаний

бок, проявляющихся в единицу времени,— это независимые случай-

ные величины, распределенные по закону Пуассона с интенсивно-

стью потока (функцией количества ошибок) m ( i), пропорциональной

ожидаемому числу остающихся в программе ошибок на заданный мо-

мент времени.

Считая, что общее число ошибок конечно и равно a, имеем следу-

ющее дифференциальное уравнение:

m ′( t) = ag - gm t().

Решая указанное уравнение, можно получить основное расчет-

ное выражение модели:

m t

e( gt

( )

(

)

- -

где: a — коэффициент, характеризующий число ожидаемых ошибок

в ПО (которые будут найдены в бесконечности); g — коэффициент ин-

тенсивности выявления ошибок.

Функция m( t) показывает количество ошибок к моменту t, она вы-

пуклая, монотонно возрастающая, стремящаяся к значению a- ожи-

даемому числу ошибок, которые будут выявлены при тестировании,

т. е.: lim m

( t() = a.

t →∞

Таблица 3.7

Полумарковские модели роста надежности программ

Название модели

Интенсивность ошибок, λ i

SW-модель

f( N -( i - ))

1 ti

Гиперболическая модель

f( N - i( - )

- 2

(

+ bt + c)

Sukert-модель

f( N -( i - N )) t

Модифицированная модель



i-1



i-1 

Липова



 t



f N - N  i



∑ � + t 

j 

∑ i



 2









j 1 

SW-отладочная модель

f( N - p( i - ))

1 ti

109

Метрики и модели испытаний

Ожидаемое число ошибок, оставшихся к моменту t, можно рас-

считать следующим образом:

m t

ae gt

( ) = ∞

( )- ( ) = - .

Функция интенсивности возникновения ошибки (показывающая

среднее число ошибок к моменту t) имеет следующий вид:

l t

m t

age gt

( ) = ′( ) = - .

Полученные выражения позволяют найти формулы для вероят-

ностей того, что за заданное время будет выявлено и локализовано

(или нет) то или иное количество ошибок, например:

(

t k

( ))

( ( - e gt))

P t k

e m t()

e- a((1 e- gt

( , )

)

k !

где: k — число выявленных ошибок за заданное время t.

Параметры NHPP-модели можно найти с помощью метода макси-

мального правдоподобия. Следует заметить, что если имеется стати-

стика моментов t обнаружения ошибок, можно получить следующую

функцию максимального правдоподобия:

L t

( , t , t

… ) =

t( e m

- t

)

( ) =

age- gt e- a( 1( e

u )

1 2

∏ j

∏

j 1

Для случая фиксации количества обнаруженных ошибок N на ин-

тервалах времени ( t ; t ], мы имеем следующий вид функции макси-

j-1

мального правдоподобия:

N j

( t( )- m t( - )

L ( N , N ,… N

j 1

) =

e m

- t

( )

∏

N !

j 1

N j

( e g

( t

j -1

- e

))

- gt

= ∏

- a

( 1( e- k

)).

N !

j 1

3.3.2.4. S-образная NHPP-модель роста надежности программ

В настоящее время одной из самых популярных NHPP-моделей

роста надежности является S-образная NHPP-модель Ямады

(Yamada), в которой, в отличие от JM- и SW-подобных выпуклых моде-

лей, делается дополнительное предположение о S-образной зависимо-

110

Метрики и модели испытаний

сти числа ошибок от времени тестирования. Понятийно S-образная

зависимость числа обнаруженных ошибок от времени объясняется

тем, что в начальной стадии тестирования имеется фаза изучения

экспертом ПО.

Функция количества ошибок задается следующей формулой:

m t

a(1 (1 gt) e- gt

( ) = - +

где: a — коэффициент, характеризующий число ожидаемых ошибок

в ПО; g — коэффициент интенсивности выявления ошибок.

Ожидаемое число ошибок, оставшихся к моменту t, можно рас-

считать следующим образом:

m t

a 1 gt e gt

( ) = + -

(

)

Соответственно, интенсивность возникновения ошибки опреде-

ляется следующим образом:

l t

ag t 2 e gt

( ) =

- .

Полученные выражения позволяют легко найти формулу для ве-

роятностей того, что за заданное время будет выявлено и локализо-

вано (или нет) то или иное количество ошибок. Параметры модели a

и g можно найти с помощью метода максимального правдоподобия.

3.3.2.5. Степенная NHPP-модель роста надежности программ

В модели надежности, получившей название модели Дьюэйна

(Duane), полагается, что функция количества ошибок задается формулой:

 t 

m t

( ) =   ,

 a 

где: a — коэффициент, характеризуемый масштаб; g — коэффициент

интенсивности выявления ошибок (степень).

Соответственно, интенсивность возникновения ошибки опреде-

ляется следующим образом:

  -1

g t

( ) =   .



 a 

В модели если g> 1, то lim m

( t() = + ,

∞ поэтому модель получила

t →∞

название бесконечной NHPP-моделью (NHPP-infinite).

111

Метрики и модели испытаний

Полученные выражения позволяют легко найти формулу для ве-

роятностей того, что за заданное время будет выявлено и локализо-

вано (или нет) то или иное количество ошибок. Параметры модели a

и g можно найти с помощью метода максимального правдоподобия.

Примеры популярных NHPP-моделей представлены в таблице 3.8

[49].

Таблица 3.8

Неоднородные Марковские модели роста надежности программ

Название NHPP-модели

Функция количества ошибок, m( t)

Duane-модель*

at g

Модель Гомпертца

ag ct

Goel-Okumoto — модель

a 1 - e- gt

(

)

Schneidewind-модель*

a g 1 - e- gt

/ (

)

Модель Вейбулла

a 1 - e- gtc

(

)

Yamada-экспоненциальная модель

a 1 - e( rc

- (1 e( gt

(

)

- - )) )

S-образная модель Релея

a(1 - e

)

( rc

- (1 e

2 )) )

S-образная модель с задержкой*

a 1 - 1

( + gt) e- gt

(

)

a(1 - e- gt )

S-образная модель с точкой перегиба

1 + ce- gt

Параметризованная S-изогнутая мо-

1 - e- gt

дель

1 + y r

( e- gt

)

Dohiya — модель

a 1 - e- gt

1 + e- gt

(

) (

)

Модель Парето

a 1 - 1 + t c 1- g

(

/ )

)









Гиперэкспоненциальная модель

a  -

b e g t 





∑ i





i 1



112

Метрики и модели испытаний

Окончание табл. 3.8

Littlewood –модель

ac g (

)

c g

( + t g

)

 l   m

Параболическая модель

(

-  t3

 +

t2



+ t )

a(1 - e 3 2

)

Логистическая модель

ke gt

1 + -

Pham — модель

a ae- gt

(1 + ( g + d) t + gdt 2

a 

(1 + a e- gt c ( b 

)

) 

Zhang — модель

(1-



)



p - 

b 

1 +





e gt



Xie-логарифмическая модель

alng (1 + t)

Musa-Okumoto-логарифмическая мо-

дель*

1 / a ln( agt + 1)

* IEEE Std. 1633—2008.

3.3.2.6. Байесовская модель роста надежности программ

В рассмотренных ранее моделях надежности используются пред-

положения о характере распределений априорно, причем сами пара-

метры моделей имеют детерминированный вид. Для корректировки

параметров предполагаемых распределений в зависимости от новых

статистических данных (об обнаружении и исправлении ошибок ПО)

можно использовать байесовский подход, заключающийся в интер-

претации параметра модели надежности как случайной величины

с априорной функцией распределения. В общем виде, согласно тео-

реме Байеса, отношение апостериорной оценки параметров модели

имеет вид:

l t( / X ) f X

( )

h X

( / t) =

l t( / X ) f X

( d

) X

∫ W x

где: f( X) — априорная плотность распределения; X — вектор параме-

тров априорного распределения; t — измеримые данные; l( t/ X) — функ-

113

Метрики и модели испытаний

ция правдоподобия; h( X/ t) — апостериорная оценка плотности рас-

пределения вектора X.

Надо понимать, что введение байесовского подхода существенно

усложняет вычислительную сложность моделей. Наиболее простой

байесовской модификацией является гамма-модель Литлвуда и Вэра-

ла (Littlewood -Verrall, LV-модель).

Как и в JM-модели в LV-модели интервалы между ошибками под-

чинены экспоненциальному распределению с условной плотностью

вероятности для интервала t между ошибками:

f t

( l ) = l e-l tii

Рассматривая функцию интенсивности ошибок как стохастиче-

ски убывающую, предлагается описать ее условную плотность вероят-

ности гамма-распределением с параметрами ψ( i) и α:

(y a

i( )

) la- e

1 -y i

( )l i

(l ) =

G a

( )

где: ψ ( i) — возрастающая функция, характеризующая уровень надеж-

ности; i — количество найденных ошибок; α — параметр, задающий

форму кривой роста надежности; G a

( ) — гамма-функция Эйлера.

Кроме того, полагается, что безусловная плотность вероятности

интервала t определяется распределением Парето, а априорная плот-

ность вероятности параметра a является равномерной.

В LV-модели и ее модификациях предложено множество вариан-

тов аппроксимации ψ ( i), наиболее популярной из которых является

линейная: y i

( ) ≈ b +b i , где i — количество найденных ошибок.

В последнем случае для вычисления 3-х неизвестных параметров

( a,b ,b ) необходимо решить лишь следующую систему уравнений:



 n +a



∑(ln(b +b i ln

1 ) -

( +b +b i

1 ) =



i=1





 a

 ∑

(a + )1

= 0

∑

+ b



t + b + b i

i=1

i=1 i

 n



 a

 ∑

-(a + )

1 ∑

= 0

b + b



t + b + b i



i=1

i=1 i

где: t — интервалы времени между ошибками; n — число обнаружен-

ных ошибок.

114

Метрики и модели испытаний

Для случая линейной аппроксимации y i

( ) искомую функцию

интенсивности предлагается рассчитать следующим образом:

-1

( ) =

b2 + b t a

1 (

- )

Модель позволяет также получить расчетные выражения для

средней наработки на отказ и вероятности безотказной работы 33:

y i()

t =

;

a -1



 y i

( ) 

P t

( ) =

 .





 t( + y i



( ))

3.2.3. Модели полноты тестирования

Модели оценки полноты тестирования ПО основаны на методах

независимого внесения и выявления тестовых ошибок и методах про-

ведения независимых экспертиз.

3.2.3.1. Модель учета внесенных ошибок

Модель учета внесенных ошибок, известная также как решение

задачи теории вероятности «меченых рыб» или как модель Миллса

(Mills), предполагает внесение в текст программы S тестовых ошибок.

В процессе тестирования собирается статистика о выявленных ошиб-

ках: s внесенных и n реальных.

Предполагается, что тестовые ошибки вносятся случайным обра-

зом, выявление всех ошибок (внесенных и собственных) равноверо-

ятно. В этом случае, используя метод максимального правдоподобия,

можно получить оценку числа первоначальных ошибок ПО:

N =

где: S — число внесенных тестовых ошибок; s — число найденных вне-

сенных ошибок; n — число найденных реальных ошибок.

Для обеспечения уверенности в результате модели (т. е. для рас-

чета достаточного числа внесенных тестовых ошибок) предложена

33 IEEE Std. 1633—2008.

115

Метрики и модели испытаний

следующая мера доверия при условии выявления в процессе тестиро-

вания всех S внесенных ошибок:

1, при n > N



P = 



, при n ≤ N .

 S + n + 1

В табл.3.9 показаны примеры меры доверия для случая выявле-

ния всех тестовых ошибок.

Из формулы для вычисления меры доверия можно получить фор-

мулу для вычисления количества тестовых ошибок, которые необхо-

димо внести в программу:

P N

( + )

1 - PNS

Пример табличных значений для расчета количества тестовых

ошибок, которые необходимо внести в программу для получения нуж-

ной уверенности в оценке, представлен в табл.3.10.

В случае, если в процессе испытаний выявлены не все внесенные

тестовые ошибки, следует использовать следующую формулу:

1, при n > N



;



P =  C s- n



, при n ≤ N ,

 N n

 S+ N +1

где: s — число обнаруженных тестовых ошибок.

Данная модель носит интуитивный характер. На практике мо-

дель применяется для контроля эффективности работы экспертов,

Таблица 3.9

Мера доверия к модели Миллса

100

116

Метрики и модели испытаний

Таблица 3.10

Количество тестовых ошибок

100

101

проводящих аудит безопасности кода. К основному недостатку моде-

ли относят проблему случайного внесения уязвимостей.

3.2.3.2. Модель учета внесения ошибок в разные модули

В данной модели ПО разделяется на две части. Считается, что

1-я часть ПО содержит N оставшихся ошибок, вторая часть — N , об-

щее число оставшихся ошибок ПО N = N + N . Предполагается,

что выявление оставшихся ошибок равновероятно, обнаруживается

одна ошибка в заданный интервал времени и исправляется после об-

наружения.

Можно показать, что:



 N





( ) = N - i + c ;

∑ j



j =0



 N i



( ) = N - c ,

∑ j



j =0



где: χ — характеристическая функция, такая что:

 , если jя ошибка найдена в 1й части ПО;

c = 

 ,если jая ошибка найдена во 2ой части ПО.



В этом случае можно рассчитать вероятности обнаружения ошиб-

ки на заданном интервале времени тестирования ( t , t ]:

i+1

117

Метрики и модели испытаний





N i

N - i

( )

∑ c j

 p i

j =0

( ) =

 1



N i



( )+ N i() = N - i + N





N i

( )

N -

∑



 p i

( ) =

j =0



N i



( )+ N 2 ( i) = N - i + N



Параметры N и N можно найти, используя метод максимального

правдоподобия. Можно показать, что функция максимального прав-

доподобия имеет следующий вид:

L c c … c =

p i

1-c

-1

p i

( , , ,

)

( (

)

( ( - )

1 ,

∏ 1

i 1

где: n — число удаленных оставшихся ошибок.

Нахождение экстремума логарифма функции позволяет полу-

чить систему уравнений:

 n



1 - c



∑

= 0;

i-1



- + 1

 i=1 N - i

+ 1 +



∑ j j





 ∑

= 0.

i-1



N + N - i +



i=1 N -



∑ j j



Решение системы уравнений можно найти численными методами.

3.2.3.4. Модель контроля функциональных объектов

Данная модель используется аккредитованной лабораторией

«Эшелон» при проведении испытаний на отсутствие недеклариро-

ванных возможностей [49]. Согласно руководящему документу Го-

стехкомиссии России [69], в процессе динамического анализа ПО

контролируется p заданный процент от M идентифицированных

фо

функциональных объектов. В процессе статического анализа произ-

вольно выбираются m функциональных объектов, в которые вно-

фо

сятся тестовые ошибки. При тестировании фиксируются найденные

тестовые ошибки — s и найденные реальные ошибки — n. Используя

метод максимального правдоподобия, можно получить оценку числа

ошибок в ПО:

118

Метрики и модели испытаний

M - m

N = n

фо

фо .

p M - s

фо

100

3.2.3.5. Модель испытаний независимыми группами

Данная модель, получившая также название «парная оценка»,

предполагает проведение тестирования 2-мя независимыми группа-

ми тестирования.

В процессе тестирования подсчитывается количество обнару-

женных ошибок обеими группами — N и N , а также число обнару-

женных обеими группами совпавших ошибок — N .

Обозначив N как число первоначальных ошибок, можно опреде-

лить эффективность тестирования каждой группы: E = N / N и E =

N / N. Гипотетически предполагая одинаковую эффективность тести-

рования обеих групп, можно допустить, что если одна группа обна-

ружила определенное количество всех ошибок, то она же могла бы

определить то же количество любого случайным образом выбранно-

го подмножества. Это позволяет получить следующие равенства для

обеих групп:

N N = N

N ;

N N = N

N .

Считая, что эффективность групп также одинакова между собой,

имеем:

E = E = N N = N

N ,

что и дает основное расчётное выражение числа первоначальных

ошибок в ПО:

N = N N N .

Количество не найденных ошибок будет равно:

N = N - N

(

+ N - N ).

Данная модель полезна на практике, когда тестирование парал-

лельно проводит группа экспертов, имеющих собственные АРМ те-

стирования, что часто бывает при выездных испытаниях при огра-

ничениях по времени работы.

119

Метрики и модели испытаний

3.2.4. Модели сложности программного обеспечения

Модели сложности ПО основаны на гипотезе о том, что уровень

безошибочности ПО может быть предсказан с помощью показателей

(метрик) сложности ПО. Это справедливо для непреднамеренных уяз-

вимостей, так как, чем сложнее и больше программа, тем выше веро-

ятность того, что программист ошибется при ее написании и моди-

фикации, а также тем сложнее локализовать ошибку в ПО [77].

В качестве аргументов моделей, как правило, используются ме-

трики 34 сложности ПО, а сами модели сложности можно разделить

на аналитические и статистические. Приведем примеры наиболее из-

вестных моделей.

3.2.4.1. Метрическая модель ошибок Холстеда

Самой известной аналитической моделью сложности ПО являет-

ся модель Холстеда [82]. В основу разработки модели положены две

базовые характеристики ПО: h = h + h — словарь операторов и опе-

рандов языка программирования и N = N + N — число использо-

вания операторов и операндов в программных реализациях, а также

гипотеза, что частота использования операторов и операндов в про-

грамме пропорциональна двоичному логарифму количества их типов

(по аналогии с теорией информации).

Полагаясь на общие статистические физиологические характе-

ристики программиста, реализующего программы, измеряемые ука-

занными метриками, получен ряд эмпирических моделей оценки по-

казателей качества ПО.

Например, сложность программы предложено рассматривать

как совокупность интеллектуальных усилий (решения элементарных

задач человеком до возникновения ошибки) при кодировании текста

на определенном языке программирования:

h N N log h

E = N log (h / L) = 1 2

2h2

где: N = h log h + h log h — теоретическая длина програм-

мы; h = h + h — число уникальных операторов и операндов язы-

ка программирования; L = 2h / h

( N ) — уровень программы;

N = N + N — число обращений к операторам и операндам в ПО.

34 IEEE Std. 1061—1998.

120

Метрики и модели испытаний

Время кодирования программы рассчитывается следующим об-

разом:

h N N log h

T =

= 1 2

2 S

3 h

где: S = 5;20 — число Страуда (число мысленных сравнений в секун-

ду), Холстед предложил для мужчины-программиста S = 18.

Для расчета B первоначального числа ошибок в ПО предложено

использовать выражение:

E 3

N log ( )

B ≈

≈

3000

где: V = N log ( )

h — объем программы (в бит информации).

3.2.4.2. Многофакторная модель сложности

К простым статистическим моделям сложности можно отнести

феноменологическую модель фирмы TRW [78]. Феноменологическая

модель представляет собой линейную модель оценки показателя без-

ошибочности ПО по 5-ти значимым характеристикам программ,

а именно: уровням логической сложности, сложности взаимосвязей,

сложности вычислений, сложности ввода-вывода и понятности.

Феноменологическая модель представляет собой линейную мо-

дель оценки показателя сложности ПО по 5-ти эмпирическим харак-

теристикам программ, а именно: логической сложности L , сложно-

tot

сти взаимосвязей C , сложности вычислений C , сложности ввода вы-

inf

вода C и понятности U .

read

Показатель логической сложности определяется числом логиче-

ских операторов:

+ x

+ x + 0,

001 ,

tot

loop

где: z — число логических операторов; z — число исполняемых опера-

торов; x — нормированное по вложенности число циклов; x — норми-

loop

рованное по вложенности число условных операторов; z — число всех

(условных и безусловных) переходов.

Показатель сложности взаимосвязей определяется числом вызы-

ваемых программ:

= z + 0, z

5 ,

inf

sys

121

Метрики и модели испытаний

где: z — число вызовов прикладных программ; z — число вызовов си-

sys

стемных программ.

Показатель сложности вычислений определяется числом ариф-

метических операторов:

∑

ПО tot

(

) ,

∑ ПО cs

где: z — число арифметических операций; z — число исполняемых

операторов .

Показатель сложности ввода-вывода измеряется числом опера-

ций ввода-вывода:

∑

ПО tot

(

) ,

∑ ПО io

где: z — число операторов ввода-вывода; z — число исполняемых опе-

раторов .

Показатель понятности определяется числом комментариев:

= z

/ z

( + z ),

read

com

где: x — общее число операторов; z — число комментариев.

com

Общий показатель сложности имеет следующий вид:

С = L + 0, C

+ 0, C

2 + 0, C

+ -

( 0,1 U

)

tot

inf

read

Для расчета числа ошибок N предлагается использовать линей-

ную модель:

N = L k + 0, C

k + 0, C

2 k + 0, C

4 k + -

( 0,1 U

)

k ,

tot 1

inf

read

где: κ — коэффициент корреляции числа ошибок с i-м показателем

сложности.

Значения коэффициентов κ i легко найти методом наименьших

квадратов.

3.2.5. Выбор модели оценки и планирования испытаний

Отметим, что не существует универсальной модели оценки и пла-

нирования испытаний ПО. Более того, кроме рассмотренных классов

моделей в литературе можно встретить имитационные модели [3,73],

структурные [36,66], нечеткие [50], интервальные модели [99], моде-

122

Метрики и модели испытаний

ли динамической сложности программ [51], модели программно-ап-

паратных комплексов [76], а также нейронные сети, получившие при-

менение для решения отдельных научных задач. Для выбора подхо-

дящих моделей можно предложить ряд качественных и количествен-

ных критериев [49].

Качественными критериями можно назвать следующие:

1. Простота использования. В первую очередь касается степе-

ни адекватности модели системе сбора статистики, т. е. используе-

мые входные данные могут быть легко получены, они должны быть

представительны, входные и выходные данные понятны экспертам.

2. Достоверность, т. е. модель должна обладать разумной точно-

стью, необходимой для решения задач анализа или синтеза в области

безопасности ПО. Положительным свойством модели является воз-

можность использования априорной информации и комплексирова-

ния данных других моделей с целью сокращения входной выборки.

3. Применимость для решения различных задач. Некоторые мо-

дели позволяют получить оценки широкого спектра показателей, не-

обходимых экспертам на различных этапах жизненного цикла ПО,

например, показатели надежности, ожидаемое число ошибок различ-

ных типов, прогнозируемые временные и стоимостные затраты, ква-

лификацию специалистов, качество тестов, показатели точности, по-

казатели покрытия ПО и др.

4. Простота реализации, в том числе, возможность автоматизиру-

емости процесса оценки на базе известных математических пакетов

и библиотек, переобучения модели после доработок, учета случаев

неполных или некорректных входных статистик, учета других огра-

ничений моделей.

В качестве количественных критериев используют следующие:

— показатели точности оценки;

— показатели качества прогнозирующих моделей (сходимость,

устойчивость к шуму, точность предсказания, согласованность);

— информационные критерии качества прогнозирующих моде-

лей (размерность, критерии BIC/AIC).

— комбинированные и интегральные показатели, например:

IC = max

∑ c ,

i i

i=1

где: k — весовой коэффициент i-го свойства рассматриваемой модели,

выбираемой экспертом; χ — характеристическая функция i-го свой-

ства.

123

Метрики и модели испытаний

Исследование показало, что существует весьма большое коли-

чество математических моделей, позволяющих получить оценки

показателей технологической безопасности ПО на различных эта-

пах жизненного цикла, что важно при планировании затрат на ин-

формационную безопасность. Рассмотренная классификация мо-

делей позволяет на практике сориентироваться при выборе и ком-

плексировании моделей в зависимости от имеющейся статистики.

Надо понимать, что в виду динамичности, сложности и разно-

родности современных программных проектов, к указанным мо-

делям не могут предъявляться высокие требования по точности,

и они носят зачастую интуитивный характер при принятии реше-

ний по планированию тестирования ПО на всем множестве вход-

ных данных. Несмотря на это, результаты применения моделей

удобно использовать как при обосновании трудоемкости испыта-

ний, так и при предоставлении отчетных материалов, что повыша-

ет уверенность заказчика в результатах выполненных работ.

3.3. Модели управления доступом

Основной подсистемой комплексного СЗИ является подсистема

управления доступом. В руководящих документах Гостехкомиссии

России определены два принципа управления доступом: дискрецион-

ный и мандатный. В ГОСТ ИСО/МЭК 15408, кроме указанных, опи-

сан еще ролевой принцип управления доступом, однако допускаются

любые другие недискреционные принципы управления доступом [10,

45, 81].

Формальные модели управления доступом используются в тех

случаях, когда те или иные утверждения о стойкости систем защиты

информации требуют строгого доказательства — например, в случае,

если оценочный стандарт требует использования формальных ме-

тодов проектирования средств защиты информации 35. На практике

применение таких методов является чрезвычайно трудоемкой и доро-

гостоящей задачей, поэтому их практическое использование весьма

и весьма ограничено [84].

На сегодняшний день используются четыре основных класса мо-

делей управления доступом:

1. Дискреционные модели управления доступом — модели, в кото-

рых владелец ресурса сам задает права доступа к нему. В большинстве

35 ГОСТ Р ИСО/МЭК 15408—3-2008

124

Метрики и модели испытаний

случаев права доступа субъектов к объектам представляются в виде

матрицы или списков доступа.

2. Мандатные модели управления доступом, в которых режим до-

ступа субъектов к объектам определяется установленным режимом

конфиденциальности.

3. Ролевая модель управления доступом, копирующая иерархиче-

скую структуру организации и позволяющая упростить администри-

рование.

4. Атрибутная модель, являющаяся наиболее универсальной и по-

зволяющая контролировать доступ с учетом произвольных параме-

тров среды, субъектов и объектов доступа.

3.3.1. Дискреционная модель управления доступом

Классической дискреционной моделью управления доступом

является модель Харрисона-Руззо-Ульмана (Harrison-Ruzzo-Ullman

model), которая формализует понятие матрицы доступа — таблицы,

описывающей права доступа субъектов к объектам (рис. 3.3).

Строки матрицы доступа соответствуют субъектам, существую-

щим в системе, а столбцы — объектам. На пересечении строки и столб-

ца указаны права доступа соответствующего субъекта к данному объ-

екту: например, на рис. 3.3 субъект subj 3 обладает правами чтения

и записи по отношению к объекту obj 3.

Введём следующие обозначения:

— S — множество возможных субъектов;

— O — множество возможных объектов (напомним, что S ⊂ O );

— R = { r , …, r } — конечное множество прав доступа;

— O × S × R — пространство состояний системы;

— M — матрица прав доступа, описывающая текущие права досту-

па субъектов к объектам;

— Q = ( S, O, M) — текущее состояние системы;

— M[ s, o] — ячейка матрицы, содержащая набор прав доступа

субъекта s ∈ S к объекту o ∈ O .

obj 1 obj 2 obj 3 ...

subj 1

...

subj 2

subj 3

...

r, w

...

Рис. 3.3. Матрица доступа

125

Метрики и модели испытаний

Поведение системы во времени моделируется переходами между

различными её состояниями. Переходы осуществляются путём вне-

сения изменений в матрицу М с использованием команд следующего

вида:

command a( x x )

1 ..., k

if r in M [ x , x ] and r in M [ x , x ] and … r in M [ x , x ]

s 1

o 1

s 2

o 2

then

op ,1

op ,

…

op ,

end

Здесь α — имя команды; x — параметры команды, представляю-

щие собой идентификаторы субъектов и объектов, op — элементар-

ные операции.

Элементарные операции op … op будут выполнены в том случае,

если выполняются все без исключения условия из блока if … then.

При описании элементарных операций мы будем полагать, что

в результате выполнения операции система переходит из состояния

Q = ( S, O, M) в состояние Q' = ( S' , O' , M').

Модель предусматривает наличие шести элементарных опера-

ций:

1. enter r into M[ s, o] ( s ∈ S, o ∈ O ) — добавление субъекту s права r по отношению к объекту o. В результате выполнения команды проис-

ходят следующие изменения в состоянии системы:

— S′ = S,

— O′ = O,

— M′[ x , x ] = M[ x , x ], если ( x , x ) ≠ ( s, o), s

— M′[ s, o] = M[ s, o] ∪ { r}.

Заметим, что содержимое ячейки таблицы рассматривается как

множество. Это, в частности, означает, что если добавляемый эле-

мент уже присутствовал в ячейке, то её содержимое не изменяется.

2. delete r from M[ s, o] ( s ∈ S, o ∈ O ) — удаление у субъекта s права r по отношению к объекту o. Изменения в состоянии системы:

— S» = S,

— O» = O,

— M» [ xs, xo] = M [ xs, x ], если ( x

s, xo) ≠ ( s, o),

— M» [ s, o] = M [ s, o] \ { r}.

Если удаляемое право отсутствовало в ячейке, то состояние систе-

мы в результате выполнения данной команды никак не изменяется.

126

Метрики и модели испытаний

3. create subject s ( s ∉ S ) — создание нового субъекта s. Измене-

ния в состоянии системы:

O′ = O ∪ { s},

S′ = S ∪ { s},

M′[ x , x ] = M [ x , x ] для ∀ ( x , x ) ∈ S × O, s

M′[ s, x ] = Ø для ∀ x ∈ O '

M′[ s, x ] = Ø для ∀ x ∈ S '

Как видим, при создании субъекта в матрицу M добавляются

строка и столбец.

4. destroy subject s ( s ∈ S ) — удаление существующего субъекта s.

Изменения в состоянии системы:

— S′ = S \ { s},

— O′ = O \ { s},

— M′ [ x , x ] = M [ x , x ] для ∀ ( x , x ) ∈ S′× O′ .

5. create object o ( o ∉ O ) — создание нового объекта o.

Изменения в состоянии системы:

— O′ = O ∪ { o},

— S′ = S,

— M′ [ x , x ] = M [ x , x ] для ∀ ( x , x ) ∈ S× O, s

— M′ [ x , o] = Ø для ∀ x ∈ S '

При добавлении объекта в матрице доступа создаётся новый

столбец.

6. destroy object o ( o ∈ O \ S) — удаление существующего объекта o.

Изменения в состоянии системы:

— O′ = O \ { o},

— S′ = S,

— M′ [ x , x ] = M [ x , x ] для ∀ ( x , x ) ∈ S′× O′ .

Формальное описание системы в модели Харрисона-Руззо-Ульмана

выглядит следующим образом. Система S = ( Q, R, C) состоит из сле-

дующих элементов:

1. Конечный набор прав доступа R = { r , …, r }.

2. Конечный набор исходных субъектов S = { s , …, s}.

3. Конечный набор исходных объектов O = { o ,. , o }.

4. Исходная матрица доступа M .

5. Конечный набор команд C = {a x

( ,..., x )} .

Поведение системы во времени рассматривается как последователь-

ность состояний { Q}, каждое последующее состояние является результа-

том применения некоторой команды к предыдущему: Q = C ( Q ).

n+1

Для заданной системы начальное состояние Q = { S , O , M } на-

зывается безопасным относительно права r, если не существует приме-

127

Метрики и модели испытаний

нимой к Q последовательности команд, в результате выполнения ко-

торой право r будет занесено в ячейку матрицы M, в которой оно от-

сутствовало в состоянии Q . Другими словами это означает, что субъ-

ект никогда не получит право доступа r к объекту, если он не имел его

изначально.

Если же право r оказалось в ячейке матрицы M, в которой оно

изначально отсутствовало, то говорят, что произошла утечка права r.

С практической точки зрения значительный интерес представ-

лял бы универсальный метод определения того, является ли заданная

система с некоторым начальным состоянием безопасной относитель-

но того или иного права доступа. Покажем, как эта задача может быть

решена для одного из частных случаев.

Система S = ( Q, R, C) называется монооперационной, если каждая

команда a ∈ C выполняет один примитивный оператор.

Теорема. Существует алгоритм, который проверяет, является ли ис-

ходное состояние монооперационной системы безопасным для данного права a.

К сожалению, расширить полученный результат на произволь-

ные системы невозможно.

Теорема. Для систем общего вида задача определения того, является

ли исходное состояние системы безопасным для данного права a, является

вычислительно неразрешимой.

Классическая модель Харриона-Руззо-Ульмана до сих пор широко

используется при проведении формальной верификации корректно-

сти построения систем разграничения доступа в высоко защищённых

автоматизированных системах. Развитие моделей дискреционного

управления доступом заключается преимущественно в построении

всевозможных модификаций модели Харрисона-Руззо-Ульмана, а так-

же в поиске минимально возможных ограничений, которые можно

наложить на описание системы, чтобы вопрос её безопасности был

вычислительно разрешимым.

3.3.2. Мандатная модель управления доступом

Одной из самых известных моделей мандатного управления до-

ступа является модель Белла-ЛаПадулы (Bell-LaPadula Model). Ман-

датный принцип разграничения доступа, изначально, ставил своей

целью перенести на автоматизированные системы практику секрет-

ного документооборота, принятую в правительственных и военных

структурах, когда все документы и допущенные к ним лица ассоции-

руются с иерархическими уровнями секретности.

128

Метрики и модели испытаний

В модели Белла-ЛаПадулы по грифам секретности распределяют-

ся субъекты и объекты, действующие в системе, и при этом выполня-

ются следующие правила:

1. Простое правило безопасности ( Simple Security, SS).

Субъект с уровнем секретности x может читать информацию из

объекта с уровнем секретности x тогда и только тогда, когда x преоб-

ладает над xo.

2. *-свойство ( *-property).

Субъект с уровнем секретности x может писать информацию

в объект с уровнем секретности x в том и только в том случае, когда

x преобладает над x .

Для первого правила существует мнемоническое обозначение No

Read Up, а для второго — No Write Down.

Диаграмма информационных потоков, соответствующая реали-

зации модели Белла-ЛаПадулы в системе с двумя уровнями секретно-

сти, приведена на рис. 3.4.

Перейдём к формальному описанию системы. Введём следующие

обозначения:

— S — множество субъектов;

— O — множество объектов, S ⊂ O;

— R = { r, w} — множество прав доступа, r — доступ на чтение, w —

доступ на запись;

— L = { U, SU, C, S, TS} — множество уровней секретности, U-

Unclassified, SU — Sensitive but unclassified, C–Confidential, S — Secret, TS — Top

secret;

— L = ( L,≤,•,⊗) — решётка уровней секретности;

— V — множество состояний системы, представляемое в виде на-

бора упорядоченных пар ( F, M), где:

— F : S ∪ O → L — функция уровней секретности, ставящая в со-

ответствие каждому объекту и субъекту в системе определённый уро-

вень секретности;

write

Высокий уровень

Shigh

Ohigh

секретности

read

write

read

write

Низкий уровень

Olow

Slow

секретности

read

Рис. 3.4. Диаграмма информационных потоков по модели Белла-ЛаПадулы

129

Метрики и модели испытаний

— M — матрица текущих прав доступа.

Система S = ( v , R, T ) в модели Белла-ЛаПадулы состоит из следу-

ющих элементов:

— v — начальное состояние системы;

— R — множество прав доступа;

— T : V × R → V — функция перехода, которая в ходе выполне-

ния запросов переводит систему из одного состояния в другое.

Изменение состояний системы во времени происходит следую-

щим образом: система, находящаяся в состоянии v ∈ V , получает за-

прос на доступ r ∈ R и переходит в состояние v∗ = T v

( , r ) .

Состояние v называется достижимым в системе S = ( v , R, T ), n

если существует последовательность {( r , v ),...,( r , v

),( r , v )} : T( r , v ) = v ∀ i = , 0 n -1

n 1

i 1

{( r , v ),...,( r , v

),( r , v )} : T( r , v ) = v ∀ i = , 0 n -1. Начальное состояние v является дости-

n 1

i 1

жимым по определению.

Состояние системы ( F, M) называется безопасным по чтению (или

simple-безопасным), если для каждого субъекта, осуществляющего

в этом состоянии доступ по чтению к объекту, уровень безопасности

субъекта доминирует над уровнем безопасности объекта:

∀ s ∈ S, ∀ o ∈ O, r ∈ M s[, o] → F o ( ) ≤ F s

( ).

Состояние ( F, M) называется безопасным по записи (или * — безопас-

ным) в случае, если для каждого субъекта, осуществляющего в этом

состоянии доступ по записи к объекту, уровень безопасности объекта

доминирует над уровнем безопасности субъекта:

∀ s ∈ S, o ∈ O : w ∈ M s[, o] → F s ( ) ≤ F o

( ).

Состояние ( F, M) называется безопасным, если оно безопасно

по чтению и по записи.

Наконец, система S = ( v , R, T ) называется безопасной, если её на-

чальное состояние v безопасно, и все состояния, достижимые из v

путём применения конечной последовательности запросов из R, без-

опасны.

Теорема ( Основная теорема безопасности Белла-ЛаПадулы). Система

S = ( v , R, T) безопасна тогда и только тогда, когда выполнены следующие

условия:

1. Начальное состояние v безопасно.

2. Для любого состояния v, достижимого из v путём применения конеч-

ной последовательности запросов из R, таких, что T v

( , r ) = v∗ , v = ( F, M)

и v∗

F ∗ M ∗

= ( ,

) , для ∀ s ∈ S, ∀ o ∈ O выполнены условия:

1. Если r ∈ M ∗ s

[ , o] и r ∉ M s[, o] , то F ∗ o

( )

F ∗

≤

( ) .

130

Метрики и модели испытаний

2. Если r ∈ M s

[ , o] и F ∗ s

( )

F ∗

( ) , то r ∉ M ∗ s[, o] .

3. Если w ∈ M ∗ s

[ , o] и w ∉ M s[, o] , то F ∗ s

( )

F ∗

≤

( ) .

4. Если w ∈ M s

[ , o] и F ∗ o

( )

F ∗

( ) , то w ∉ M ∗ s[, o] .

Отметим, что изложенная модель в силу своей простоты имеет

целый ряд серьёзных недостатков. Например, никак не ограничива-

ется вид функции перехода T — а это означает, что можно построить

функцию, которая при попытке запроса на чтения к объекту более

высокого уровня секретности до проверки всех правил будет пони-

жать уровень секретности объекта. Другим принципиальным недо-

статком модели Белла-ЛаПадулы является потенциальная возмож-

ность организации скрытых каналов передачи информации [92]. Тем

самым, дальнейшее развитие моделей мандатного управления досту-

пом было связано с поиском условий и ограничений, повышающих

её безопасность.

В настоящее время модель Белла-ЛаПадулы и другие модели ман-

датного управления доступом широко используются при построении

и верификации АС, преимущественно предназначенных для работы

с информацией, составляющей государственную тайну.

3.3.3. Ролевая модель управления доступом

Ролевая модель управления доступом содержит ряд особенно-

стей, которые не позволяют отнести её ни к категории дискрецион-

ных, ни к категории мандатных моделей. Основная идея реализуемо-

го в данной модели подхода состоит в том, что понятие «субъект» за-

меняется двумя новыми понятиями:

− пользователь — человек, работающий в системе;

− роль — активно действующая в системе абстрактная сущность,

с которой связан ограниченный и логически непротиворечивый на-

бор полномочий, необходимых для осуществления тех или иных дей-

ствий в системе.

Классическим примером роли является root в Unix-подобных си-

стемах — суперпользователь, обладающий неограниченными полно-

мочиями. Данная роль по мере необходимости может быть задейство-

вана различными администраторами.

Основным достоинством ролевой модели является близость к ре-

альной жизни: роли, действующие в АС, могут быть выстроены в пол-

ном соответствии с корпоративной иерархией и при этом привязаны

не к конкретным пользователям, а к должностям — что, в частности,

упрощает администрирование в условиях большой текучки кадров.

131

Метрики и модели испытаний

Управление доступом при использовании ролевой модели осу-

ществляется следующим образом:

1. Для каждой роли указывается набор полномочий, представля-

ющий собой набор прав доступа к объектам АС.

2. Каждому пользователю назначается список доступных ему ролей.

Отметим, что пользователь может быть ассоциирован с несколь-

кими ролями — данная возможность также значительно упрощает ад-

министрирование сложных корпоративных АС.

Перейдём к формальному описанию системы. Введём следующие

обозначения:

− U — множество пользователей;

− R — множество ролей;

− P — совокупность полномочий на доступ к объектам (реализо-

ванная, например, в виде матрицы доступа);

− S — множество сеансов работы пользователей с системой

Управление доступом реализуется с использованием следующих

отображений:

− PA ⊆ P × R — отображение множества полномочий на множе-

ство ролей, задающее для каждой роли установленный набор полно-

мочий;

− UA ⊆ U × R — отображение множества пользователей на мно-

жество ролей, определяющее набор ролей, доступных данному поль-

зователю;

− user : S → U — функция, определяющая для сеанса s ∈ S теку-

щего пользователя u ∈ U :

user s

( ) = u;

roles : S → R

{ } — функция, определяющая для сеанса s ∈ S набор

ролей из множества R, доступных в данном сеансе:

− roles s

( ) = r

{ | u( ser s(), r ) ∈ UA};

permissions : S → P

{ } — функция, задающая для сеанса s ∈ S на-

бор доступных в нём полномочий (иначе говоря, совокупность полно-

мочий всех ролей, доступных в данном сеансе):

permissions s

( ) = ∪ { p | ( p , r) ∈ PA .}

r r

∈ oles( s)

Взаимосвязь пользователей, ролей, полномочий и сеансов пока-

зана на рис. 3.5.

Критерий безопасности системы при использовании ролевой мо-

дели звучит следующим образом: система считается безопасной, если

132

Метрики и модели испытаний

Рис. 3.5. Взаимосвязь ролей, полномочий, пользователей и сеансов

любой пользователь в системе, работающий в сеансе s ∈ S , может

осуществлять действия, требующие полномочий p ∈ P , только в том

случае, если p ∈ permissions s

( ) .

На практике управление доступом в АС при использовании роле-

вой модели осуществляется главным образом не с помощью назначе-

ния новых полномочий ролям, а путём задания отношения UA — т. е.

путём определения ролей, доступных данному пользователю.

3.3.4. Атрибутная модель управления доступом

Атрибутная модель управления доступом является наиболее уни-

версальной. Основная идея данной модели заключается в том, что ре-

шение о предоставлении доступа субъекта к объекту принимается на

основе анализа набора произвольных атрибутов, связанных с субъек-

том, объектом или даже средой их функционирования. Каждый атри-

бут представляет собой некий набор данных, который может быть со-

поставлен с массивом допустимых значений данного атрибута.

Для получения доступа к объекту субъект предъявляет некий

имеющийся у него набор атрибутов. Монитор безопасности обраще-

ний сравнивает значение каждого атрибута с перечнем допустимых

и в случае, если все атрибуты являются допустимыми, предоставляет

доступ.

Формальное описание модели выглядит следующим образом.

Введем ряд обозначений:

− S — множество субъектов;

− O — множество объектов;

− E — множество элементов среды;

− SA , k = ,

1 K — множество возможных атрибутов субъектов;

133

Метрики и модели испытаний

− OA , m = ,

1 M — множество возможных атрибутов объектов;

− EA , n = ,

1 N — множество возможных атрибутов элементов

среды.

Для задания атрибутов конкретным субъектам, объектам или

элементам среды используются следующие три отношения:

ATTR s

( ) ⊆ SA × SA ×…× SA ;

ATTR o

( ) ⊆ OA × OA ×…× OA ;

ATTR e

( ) ⊆ EA × EA ×…× EA .

В общем случае правило политики безопасности, разрешающее

или запрещающее доступ, представляет собой булеву функцию сле-

дующего вида:

Rule X: can_access ( s, o, e) ← f ( ATTR ( s), ATTR ( o), ATTR ( e)) Принципиально важным преимуществом данной модели являет-

ся тот факт, что субъект доступа совершенно не обязательно должен

быть заранее зарегистрирован в системе: необходимым является ис-

ключительно наличие у него соответствующих атрибутов.

В заключении, следует сказать, что можно выделить два основ-

ных подхода к использованию формальных моделей управления

доступом непосредственно при проведении оценки соответствия

средств защиты информации:

1. Независимый контроль факта реализации той или иной моде-

ли в системе, а также контроль выполнения формального критерия

безопасности (если применимо).

2. Формальное доказательство тех или иных положений с исполь-

зованием инструментария той или иной модели.

Первый подход, в частности, характерен для ролевой модели или

модели Белла-ЛаПадулы, а второй — для модели Харрисона-Руззо-Уль-

мана.

3.4. Метрики парольных систем

По статистике парольная подсистема считается самой уязвимой

в современных защищенных АС, поэтому требует самого вниматель-

ного отношения при оценке соответствия.

134

Метрики и модели испытаний

Пароль — идентификатор субъекта доступа, который является

его (субъекта) секретом [69]. Согласно существующей статистике

наиболее популярными паролями пользователей являются «123456»

и «qwerty». Это определяет необходимость формирования критериев

стойкости парольной защиты и методов оценки выполнения установ-

ленных критериев. На сегодняшний момент существует разнообраз-

ное количество рекомендаций по выбору паролей как неофициаль-

ных подходов, так и закрепленных на законодательном уровне 36.

Введем определения, используемые при дальнейшем изложении.

Пусть A — алфавит паролей, обозначим пароль длины n как последо-

вательность символов: p ( p , p , , p

Таким образом,

) ∈ A*

…

, p ∈ A.

число всевозможных паролей длины n, которые можно составить из

символов алфавита A, составляет A .

Среди основных метрик парольной защиты могут быть выделе-

ны следующие:

— длина пароля n: большинство рекомендаций устанавливают

минимальную длину пароля равной 8 символам;

— мощность алфавита пароля | A|: например, расширение алфа-

вита паролей специальными символами или буквами в верхнем реги-

стре повышает стойкость парольной системы;

— срок действия пароля T: большинство документов рекомендует

использовать пароли временного действия, что позволяет повысить

стойкость парольной защиты.

Пусть V — скорость подбора пароля злоумышленником, тогда ве-

роятность PG подбора пароля в течение его срока действия может

быть выражена следующим образом:

P V ⋅ T

Обычно скорость подбора паролей V и срок действия пароля T

можно считать известными. Задав допустимое значение вероятности

P подбора пароля в течение его срока действия, можно определить

требуемую мощность пространства паролей A .

36 РД «Автоматизированные системы. Защита от несанкционированного доступа

к информации. Классификация автоматизированных систем и требования по за-

щите информации» (Гостехкомиссия России, 1992).

135

Метрики и модели испытаний

В случае использования генераторов псевдослучайной последо-

вательности при формировании паролей, сложность пароля можно

оценить с использованием понятия энтропии. Понятие информаци-

онной энтропии было впервые формализовано Шенноном как мера

неопределенности или непредсказуемости информации, неопреде-

лённость появления какого-либо символа алфавита. Энтропия мно-

жества U = u

{ , u , ,

… u

оценивается с использованием следующего

}

выражения:

H U

( )=- p ⋅

∑ log ,

i =1

где: pi– вероятность появления элемента ui. Если все события появле-

ний элементов равновероятны (т. е. p �=�1

для ∀ i ∈ 1, N ), то выра-





жение принимает вид:

H U

( )=- p ⋅log p =-

⋅ log

= log N

∑

∑ N

2 N

i =1

В случае U = A* информационная энтропия парольной системы

определяется по формуле:

H ( A*)=

log

= log A = n ⋅ log A .

Величина H( A*) характеризует степень случайности пароля при

его генерации и показывает, насколько сложно его угадать злоумыш-

леннику. Например, для известного пароля энтропия равна нулю.

Если пароль имеет энтропию равную 1 символу, то угадать его с пер-

вой попытки можно с вероятностью равной 1

. В таблице 3.11 при-

ведены значения энтропии в расчете на один символ для различных

алфавитов.

Для оценки стойкости парольных систем, в которых исполь-

зуются генераторы псевдослучайной последовательности, могут

быть использованы различные статистические тесты. Генератор

псевдослучайной последовательности рассматривается как про-

грамма, которая генерирует битовые последовательности вида

s = s

( , s , ,

… s

0 1 Данные последовательности подвергают-

), s ∈ { , }.

136

Метрики и модели испытаний

Таблица 3.11

Значения энтропии в расчете на один символ

для различных алфавитов

Алфавит А

Число сим-

Энтропия на

волов N

один символ

log2| A|

Арабские цифры (0—9)

3,3219

Шестнадцатеричные числа (0—9, A-F)

4,0

Латинский алфавит (a-z, A-Z)

5,7004

Латинский алфавит с цифрами (a-z, A-Z, 0—9)

5,9542

Таблица ASCII

6,5546

ся различным статистическим тестам, в ходе которых определяется

мера их случайности. Методы тестирования описываются с исполь-

зованием нулевой гипотезы H (тестируемая последовательность яв-

ляется случайной) и альтернативной гипотезы H (тестируемая после-

довательность не является случайной). Тест разрабатывается с целью

проверки нулевой гипотезы H .0

Процесс статистического тестирования в общем случае выглядит

следующим образом.

1. Формулируется гипотеза H — последовательность s является

случайной с равномерным распределением — и противоположная ей

гипотеза H . a

2. Фиксируется уровень значимости a.

3. Задается статистика T :{ ,

0 1} → .

4. Для заданной последовательности s вычисляется статистика:

T � T

=� s

( ).

5. Вычисляется достигаемый уровень значимости p�= p� T

( ) для

полученного значения статистики.

6. Если p ≥ a, принимается нулевая гипотеза H ; иначе гипотеза

H отвергается.

Назовем периодом последовательности s = s

( , s ,…, s такое ми-

)

нимальное число p, что s

� s� для ∀ i > 0. Серией длины k, начи-

i + p

нающейся с символа t, назовем подпоследовательность такую, что

≠ s = s =…= s

≠ s . Соломон Голомб предложил следую-

t -1

t +1

t + k-1

t + k

щие необходимые условия случайности для бинарной последователь-

ности:

1. В каждом периоде количество «1» и «0» должно различаться не

более чем на единицу.

137

Метрики и модели испытаний

2. В каждом периоде 12 числа серий должно иметь длину k: по-

ловина серий должна иметь длину один, четверть — длину два, вось-

мая часть — длину три и т. д.

3. Функция автокорреляции должна принимать только два раз-

личных значения для всех возможных сдвигов.

Приведем примеры статистических тестов 37.

1. Частотный тест для битов. В ходе проведения данного теста

исследуется количество нулей и единиц в последовательности. Тест

оценивает приближение числа единиц последовательности к значе-

нию n .

2. Частотный тест для блоков. Цель теста — определить, при-

ближается ли количество единиц в любом блоке длины m к значению

m .

2 3. Тест серий. Цель теста — сравнить распределение серий в те-

стируемой последовательности с ожидаемым распределением таких

серий для случайной последовательности.

4. Матрично-ранговый тест. Цель теста — проверка линейной за-

висимости между подстроками фиксированного размера — матрица-

ми 32 × 32 бита.

Существуют и другие наборы тестов для исследования статисти-

ческих свойств последовательностей: набор тестов Д. Кнута, набор

тестов CRYPT-X, набор тестов DIEHARD и др. Следует отметить, что

ни один тест не может гарантировать «случайность». Тем не менее,

тесты позволяют выявлять «неслучайные» последовательности.

3.5. Модели периодического инспекционного

контроля

Правилами обязательной сертификации СЗИ, устанавливаемы-

ми в нормативных и методических документах регуляторов, предус-

мотрен периодический инспекционный контроль за стабильностью

характеристик СЗИ. Периодичность и объемы испытаний в рамках

инспекционного контроля сертифицированных СЗИ определяются

в нормативных и методических документах по их сертификации. На

практике после получения сертификата соответствия формируется

календарный план инспекционного контроля за стабильностью ха-

37 NIST SP 800—22: 2010.

138

Метрики и модели испытаний

рактеристик сертифицированных СЗИ, согласно которому проверки

проводятся через детерминированные промежутки времени.

По причине необходимости выделения дополнительных средств

на испытания СЗИ после сертификации, число моментов контроля

является заранее обоснованной конечной величиной. Однако в ре-

альной жизни по ряду случайных факторов сложно организовать ин-

спекционный контроль через строго заданные промежутки времени.

Поэтому, представляет интерес применение моделей инспекционно-

го контроля, в которых период контроля может быть как детермини-

рованным, так и стохастическим, но при заданном числе моментов

контроля.

В широком смысле инспекционный контроль представляет со-

бой систематическое наблюдение за деятельностью по оценке соот-

ветствия как основы поддержания правомерности сертификата соот-

ветствия. При этом согласно ГОСТ ИСО/МЭК 15408 контроль касает-

ся не только СЗИ (объекта оценки), но и среды функционирования.

В таком случае инспекционный контроль может включать как про-

цедуры контроля характеристик СЗИ, так и процедуры контроля ха-

рактеристик среды функционирования. Рассмотрим стохастические

и детерминированные модели указанных процедур.

3.5.1. Модели инспекционного контроля средств защиты

информации

Рассмотрим t период жизненного цикла СЗИ с учетом проводи-

мого инспекционного контроля за стабильностью характеристик. По-

скольку период времени t во много раз превышает время контроля,

положим последнее мгновенным. Тогда степень стабильности харак-

теристик СЗИ характеризуется вероятностью P z

(ˆ< Q) = F Q

( ) того,

zˆ

что время ˆ z обнаружения нарушения (уязвимости, ошибки) в межкон-

трольном интервале T не превосходит допустимое время Q жизнен-

ного цикла СЗИ при наличии нарушения. Фрагмент инспекционного

контроля представлен на рис. 3.6.

i + 1

n + 1

Рис. 3.6. Фрагмент инспекционного контроля средства защиты информации

139

Метрики и модели испытаний

Будем считать поток нарушений (ошибок, уязвимостей) простей-

шим с плотностью распределения интервала ˆ y между ними:

g = l e-l y,

yˆ

где: λ — интенсивность нарушений.

Зададим стохастическую модель обнаружения нарушений. В этом

случае контроль производится определенное число раз с равной ве-

роятностью независимо друг от друга. Таким образом, образованный

всеми моментами контроля ограниченный поток является потоком

Бернулли с плотностью распределения интервала ˆ

T между момента-

ми контроля [52, 97]:

(

)

1 -

-1

n / t(

T / t n

)

где: n — число моментов контроля.

Величина задержки ˆ ˆ

z T

= - ˆ y является функцией двух случайных

величин и имеет следующую функцию распределения:

F s =

/ ( - / ) -

n t

T t n

e ydTdy

∫∫

1 l l

( s)

Определив пределы интегрирования (рис. 3.7), получим:

t z

-  y+ z





F s = 

∫  n / t( - T / t n)-1

l e- y l dT  dy +

zˆ

 ∫



0 





t  t



+ 

n-1

∫ 

l y



∫ n / t(1 - T / t)

l e dT  dy.





t - z  y



T = y + z

T = y

t – z

Рис 3.7. Область интегрирования интервала задержки времени обнаружения

нарушения

140

Метрики и модели испытаний

После упрощения имеем следующее выражение:

t z



n 

F s =l / tn ( e-l y  t

∫

( - y



) - t( - z - y)  dy

e- y

( t( - y) ) dy).

zˆ



 + ∫

t z

Разложив в степенной ряд подынтегральные выражения форму-

лы, получим приближенное значение функции распределения, кото-

рое и является основным расчетным соотношением:

r n+ j +1

l t j+1 l- lz

F s

i + j l

(- ) + +1

CiCl

zˆ

∑∑ ∑

n n+ j +1 j 1

!( + j + i)

i = 0 j = 0 l =1

где: r — число итераций.

Для сравнения стохастической модели с детерминированной

рассмотрим последнюю подробнее. В детерминированной модели

моменты контроля образуют регулярный поток с постоянной вели-

чиной интервала T = t/ ( n+1) и плотностью распределения времени

обнаружения нарушения:

g = e- T( z

- )

l l

; 0 < z < T.

zˆ

Можно показать, что выражение для функции распределения

в детерминированной модели имеет следующий вид:

F d = e-l T e l z

(

- );

1 0 < z < T.

zˆ

Сравнивая выражения моделей, можно говорить о соответствии

рассмотренных моделей процессу выявления нарушений стабильно-

сти характеристик СЗИ (при заданных значениях λ , Q, t и n):

F s z

( ) ≶ Fd z

( ).

zˆ

Вероятность P обнаружения нарушений за t период жизненного

цикла СЗИ можно представить следующим образом:

P = n

( + )

1 ⋅ F ,

zˆ

где: n — число моментов инспекционного контроля;

F = max ( Fs z(), Fd z()).

zˆ

141

Метрики и модели испытаний

Анализ рассмотренных моделей показал преимущество стоха-

стической модели при небольшом числе моментов инспекционного

контроля. Понятийно это может быть объяснено тем, что даже при

малом числе случайных моментов контроля характеристик СЗИ всег-

да существует вероятность того, что обнаружение нарушения будет

произведено сразу же при его возникновении, в то время как при ис-

пользовании детерминированной модели период проверки не может

быть меньше заданной величины.

3.5.2. Модели инспекционного контроля сред функционирования

Контроль ограничений, предъявляемых к СЗИ, в первую очередь

касается проверки среды и условий функционирования и производ-

ства СЗИ. Такие проверки позволяют исключить появление наруше-

ний (ошибок, уязвимостей), касающихся внешнего интерфейса СЗИ.

В этом смысле процедуры обнаружения нарушений среды можно ин-

терпретировать как механизм предупреждения нарушений СЗИ.

При разработке моделей контроля среды будем придерживать-

ся подхода, приведенного в предыдущем разделе. Будем считать, что

степень стабильности характеристик СЗИ характеризуется вероят-

ностью P z

(ˆ< Q)= F Q

( ) того, что время предварительного контро-

zˆ

ля ˆ z между моментом контроля среды и возможным моментом насту-

пления нарушения характеристик СЗИ не превосходит допустимое

время Q. Зададим стохастическую модель контроля нарушений среды

(рис. 3.8).

Можно показать, что величина времени предварительного кон-

троля является функцией двух случайных величин ˆ= ˆ

z y - T и имеет

следующую функцию распределения:

F s =

n / t( - T / t n

) - e- ydTdy,

zˆ

∫∫

1 l l

( s )

i – 1

i + 1

n + 1

Рис 3.8. Диаграмма функционирования системы при наличии механизма

предупреждения нарушений

142

Метрики и модели испытаний

где: n — число моментов контроля среды; λ — интенсивность наруше-

ний характеристик СЗИ.

Определив пределы интегрирования (рис. 3.9) и упростив выра-

жение, получим:

t z

F s =

∫ ( ) -l (1- -l ) + ∫ ( ) -l 1- -l

ˆ T e

e T dT

f ˆ T e T (

e z ) ddT

zˆ

+ f T

∫

ˆ ( ) e - T dT - e - t

( ) ,

t z

Разложив в степенной ряд подынтегральные выражения, полу-

чим приближенное значение функции распределения, которое явля-

ется основным расчетным соотношением:

n-1

F s ≈ n

(

b b ) - e-l t

( ) ,

zˆ

∑ ∑ 1 2

i = 0 j = 0

где: r — число итераций;

- I + J

= (-1)

;

n 1

- ( j ! ti 1

( + j +1 ))

b = ti+ j 1

+ - zi+ j 1

j - e-l z t - z i+ j 1

(

)(

) + e- z l .

Сравним полученную стохастическую модель с детерминирован-

ной. В детерминированной модели моменты контроля образуют регу-

y = 2 T

y = T + z

y = T

t – z

Рис 3.9. Область интегрирования интервала времени предупреждения нару-

шения

143

Метрики и модели испытаний

лярный поток с постоянной величиной интервала T = t / ( n+ 1) и сле-

дующей плотностью распределения времени предварительного кон-

троля:

g = l e-l T(+ z).

zˆ

Следовательно, выражение для функции распределения в детер-

минированной модели будет иметь следующий вид:

F d = e-l T (1 - e-l z ); 0 < z < T.

zˆ

Сравнивая расчетные выражения моделей, при заданных значе-

ниях λ , Q, t и n получаем критерий, позволяющий сделать выбор той

или иной модели:

F S z

( ) ≶ Fd ( ).

ˆ z

Вероятность P предупреждения нарушений за t период жизнен-

ного цикла СЗИ можно представить следующим образом:

P = n

( + )

1 ⋅ Fˆ,

где: n — число моментов контроля; F = max ( F s z

( ), Fd z()).

zˆ

Сравнительный анализ стохастических и детерминированных

моделей показал эффективность первых при малом числе моментов

контроля. Поэтому при управлении информационной безопасностью

систем численными методами можно определить предпочтительные

модели (стохастическую, детерминированную либо комбинирован-

ную), повышающие уровень доверия к СЗИ. Это дает эффект, подоб-

ный введению структурной избыточности, то есть можно говорить об

особом виде избыточности — стохастической, использование которой

практически не увеличивает затрат [52].

144

4. МЕТОДИКИ СЕРТИФИКАЦИОННЫХ

ИСПЫТАНИЙ

Существующие типовые методики сертификационных и атте-

стационных испытаний носят зачастую описательный характер, что

затрудняет автоматизацию и оптимизацию процессов оценки соот-

ветствия средств защиты информации [35]. В разделе рассмотрен но-

вый подход к формализации методик сертификационных испытаний

СЗИ, позволяющий определить факторы, связанные со временем,

стоимостью и полнотой испытаний СЗИ [5,7,8].

4.1. Формальный базис испытаний

средств защиты информации

Пусть R = r

{ }, — множество требований, предъявляемых к СЗИ

S, T = t

{ } — множество тестовых процедур, проверяющих реализа-

цию предъявляемых требований.

Под методом разработки тестовых процедур будем понимать отобра-

жение: M : S× R → T . Функция M на основе требования r ∈ R и ин-

формации о реализации СЗИ S. Как правило, функция M для СЗИ S

является биективным отображением:

— ∀ r , r ∈ R выполняется r

( ≠ r ) ⇒ ( M (S, r ) ≠ M (S, r ) ,

1 2

то есть различные требования безопасности участвуют в формиро-

вании различных тестовых процедур;

— ∀ t ∈ T ∃ r ∈ R : M ( ,

S r ) = t — любая тестовая процедура разра-

батывается с целью проверки определенного требования.

Каждая тестовая процедура t ∈ T характеризуется целью выпол-

нения, последовательностью выполняемых действий, результатом вы-

полнения тестовой процедуры и критерием принятия положитель-

ного решения.

Цель испытания содержит изложение намерения о выполнении

оценки соответствия СЗИ предъявляемым требованиям. Последова-

145

Методики сертификационных испытаний

тельность выполняемых действий определяет набор шагов, осуществля-

емых экспертом для приведения СЗИ в исходное состояние и выпол-

нения тестовой процедуры. Результаты выполнения тестовых процедур

фиксируются с использованием различных программных средств

(ПС) проведения испытаний, таких как: средства генерации и пере-

хвата сетевого трафика, поиска остаточной информации, проверки

системы разграничения доступа. Критерий принятия положительного

решения должен содержать эталонные результаты выполнения тесто-

вых процедур. Введем операторы выполнения требования F и кор-

ректности выполнения тестовой процедуры F .

Оператор выполнения требования r для СЗИ F : S× R → { ,

0 }

1 :

 ,1 если требование r выполнено;

F ( r



S, ) = 

 ,

0 в противном случае.



Оператор корректности выполнения тестовой процедуры t для

СЗИ S F : S× T → { ,

0 }

1 :

 ,1 если тест t выполнен успешно;

F ( t



S, ) = 

 ,

0 в противном

м случае.



Оператор F показывает, что для СЗИ S выполнение тестовой

процедуры завершилось успешно: фактические результаты, зареги-

стрированные при выполнении теста, соответствуют эталонным зна-

чениям, указанным в описании тестовой процедуры.

Методикой испытаний назовем набор из пяти объектов

A = {S, R, M, F , F где R — множество требований, предъявляемых

C },

к СЗИ S, M — метод разработки тестовых процедур, F и F — опера-

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

вой процедуры соответственно, а также для ∀ r ∈ R справедливо

F (S, r ) ⇒ F (S, M (S, r ) .

В общем виде испытания включают три стадии: планирование,

тестирование, анализ результатов.

При планировании выполняется анализ документации и особен-

ностей работы СЗИ. Эксперты должны установить, что в техниче-

ской документации разработчик декларирует соответствие СЗИ

требованиям R, то есть F (S, r ) = 1 для ∀ r ∈ R. На основании ана-

лиза документации, тестовых запусков СЗИ и предъявляемых тре-

146

Методики сертификационных испытаний

бований, формируется множество тестовых процедур T = t

{ }, где

t = M (S, r ).

Тестирование выполняется с использованием набора тестовых

процедур T = t

{ }, в результате чего для каждой тестовой процеду-

ры определяются результаты выполнение тестовой процедуры, под-

лежащие регистрации.

На стадии анализа фактических и эталонных значений получают

множество упорядоченных пар вида ( t , F ( ,

S t )). Для СЗИ S деклари-

руется соответствие требованиям R = r

{ } , если:

n ( F S, r F (S, M S, r ) = n

∑ ( )⋅

( )

i=1

то есть в ходе проведения испытаний установлено соответствие ре-

альных возможностей СЗИ декларируемым в документации или нор-

мативном документе.

4.2. Методика испытаний средств

вычислительной техники

Базовым документом, в котором предъявляются требования к ком-

плексу СЗИ, является руководящий документ Гостехкомиссии России

по средствам вычислительной техники (см. подр. 4.2.1). Документ уста-

навливает 7 классов защищенности и содержит требования к реали-

зации дискреционного и мандатного принципов контроля доступа,

очистки памяти, изоляции модулей, маркировки документов, защиты

ввода и вывода на отчуждаемый физический носитель информации,

сопоставления пользователя с устройством, идентификации и аутен-

тификации, регистрации событий, обеспечения целостности и др. Рас-

смотрим формализованный порядок проверки для указанных наибо-

лее ресурсоемких требований R

= r

{ , r , r , r , r , r } указанного нор-

СЗИ

1 2

мативного документа (см. табл. 4.1.).

4.2.1. Методика проверки дискреционного принципа контроля

доступа

Цель выполнения проверки состоит в определении степени со-

ответствия СЗИ требованиям функциональных возможностей по ре-

ализации дискреционного принципа разграничения доступа.

147

Методики сертификационных испытаний

- -

- - -

4.1

ие и

до-

па

объ-

ест-

при

ио

соот-

иерар н

уров-

сокого

кц

группе

чески

рограм

и ри

Таблица

чен

ли

действи

сопостав-

класси

ном

классиф

сан объекту). и

х доступа, не я, осущ

ям

в иерархи

ов вы х п

есто в

ован

ны

го

в неиерархи

перечислен

Т (

ду

ион

ься

объектам

объекта, и не- ерархи

ен

е тся В

х м

ви

явн

наци но

кац

тся

но

язык

е и ачат би дат

всем

ческой

аи

разгран

дин

для (т. е. от действи

а долж и

все

ий

ан

субъекта

ко

уровне

чаю

слен являю

ла

(и

азн

тся

обствен

ип

н ком м

) к н

ы е есурсу С

аю

, как

но

вклю

у р рави

от

струкц

н иеся вой

н в себя

в иерархи

елей

м п

РД

еваю

ием

тельно

уровен

но е

траж

я в классиф ио

осно

ехн

ын

субъекту

д, ин ован

долж

ен

чаю

и недвусм

дан н

ть

кац

ан

этого принц

кац и

субъекта

ой т

ио

дом

и ф

объекта

ио объектов подразум

вклю

ио ь

ции бъекта, о

при

явно доступа, которы дов) к

ту

оком

использ

за

служ

и т.п.), являю

кац

тельн

ви скрец

и каж

уровне

тов (пользоват

пов

здесь акр

ди ди

ого о и объектам

защ

сти

в класси

уровен м

сли

ти н ь

дискрец

и» х м

доступа

я субъекта

задано

ь м м

исле с

ы но

ие

зн

зн ы ы

ля реали кажд

долж

ть

класси н ио

х субъек

объекту у

и сам

троля

ческая классиф каци овне

бы

руппы и в ж

в ж

«явн

том

субъектам секретно етки

ф ур

кац

ебован

но

бъекта.

дом

й тем од системны

убъектов:

я, в

и е

кон

если кацио иф

Тр

ли г щ

п з с

но

ован

убъекта и еток

едствам в

и т.д.), т. е. тех

вая ). П

ци

класси

ен

долж

ств —

ь да и

к каж

ан

ио бъекта;

ровне о

ср

РД

ви

ействи

П ред

ого с

бого и

й. Д

при

в класси м у

я к

аи

классиф

ди

е д

троля доступа. Д

эти

кац

т.д.). в С

х с

н ретворяю

ен

го

ажд

ческая и

но

ретворяю

но ын н

сти, категори

ы л

ф ровне о

ам и

ь, писат

, п

ри

, п х, обеспечи

а кон

мо егори

м у в объект, только е, чем

ио

ом

тат

зм

датн

егори

зм

ип етки к

т, только если иерархи

ебован

ть

и ты задан

и» —

кат

ан

но

кац

ь доступ н , т объект) (чи

истем м

иерархи

кат и

бы

уязви

и с

е м осредством

о сторон

в класси

больш

е т

ам

убъекта (

ехан

ехан скры

ты

и ио запись

роват

ен

т не

го с ь

дов). ь

ием

вать

ь объек

зрен

и.

и. П

чески

кац

ион

е, чем

и ческие

овн

но ат

ви ат

тат

(субъект — доступа

долж

и для

«скры

(уровн

зовы оступе с

ьш

класси

сн

ди

троли рограм

ан

кац

оступа.

ен

каци

и в

категори

, п

пов

датного принц и

ествляе и

х и

ф иерархи

я д

ет чи

кон

пары ти ля д содерж

с точки

ан

том д

ы содерж

уровн

и реали

ож не

класси

иерархи

ен лам

х и д ен

доступа

го использован

я м

ей е и неиерархи

осущ

егори

ай

ен

дой ы м

устройствам

ласси щ ы х чен

т м

чески и в

ат

м ы

мо е с и т.д., а под

ци

скры

классиф

равн

ы я

за

каж

долж

долж м и

и, и все

З долж

усти

троль

усти

субъекта

егори

ля

С упа. он

чески

субъек

ерархи

субъект

К ектам ( Д доп рован К ст К равно К пользователя, так доп вляем уровн работы с

Реали ляться к ветствую кацио хи разгран К явно — не и кат — ческой кац ческие к

а-н иен r1

r 2

бозО че

148

Методики сертификационных испытаний

З м

бя

а- н-

й а- я я: за- ен

раз-

ро- С ы

ау-

чист-

каж и

ден-

се

ик

ти и

ь ц

ечен

ац и

стви ац

стью

и (пере-

та), от м

рован-

лять

рограм

подли

чат ф тво) К

орм

ти

собы к защ

орм руется

стно

яти. О

ти

и для

ден

кацион с «пом

нф

ио

роват

субъек

еств

нф

кц

пам

рограм

ден

аутен

тие (обслуж

цело

разли и

и еля, чья

ен

вод и

сан

ф осущ

доступ

ая

за

ней

свобож

ли

ии

объекта; дей

регистри

ествовать п

яти

работе

вы

ти

ац

н е

оль

е о

(одного

ное» устройс

следую

ущ

(классиф ри

пам

долж

З ы

та п

ден

ос

ват

ик

тр

и р ен

(если лось собы

и внеш

ече

устройств, так

ф пользоват

следую я

ен с

которого

кон

оцесса

ься

субъекта — ти

ти

р вно

и. К

елей

ли

а; зап чтож ься

естви

вно ять при е

олж п и

ват

ден и

страц

З д

ац

ора

зм

обеспечи

еля

и ун

собы

пам

используем

ого) объек

реги

и роват п

чески

кат

орм

вода на «пом

ен

и для и

ди

операти и в

я в одного

ехан

нф

води обеспечи

используем

пользоват

стри

но ли осущ

аци

, посредством

ти

звольно

(вы но

З долж

зм

от

го

еги

ь ден

пользоват

ествлять

р ствие; ти

перио

орм

одули

тва (вы

но

тель

стройству.

очистку

рован

рои

данными

н дей

нф

ого

. К

у у

м е

долж

звольно

си

ехан м

сть

ного

осущ ио т.д.); создан

руга.

но

ебоват

ей и

но

т д

й как устройс

прои

но

и кац ы долж

ествлять

субъектов), т. е. в операт

бя

тр н

о» вводи

рован

ф м й руемо

ествлять

для

ен

ти

п доступа); успеш

рую

програм ограм

руг о

связи

в се делен

ци

ти

осущ

чески

ног

ь ы

руги

н еткой

подли

осущ

ы д

зи ал

как

долж

собы

мо

аски

рограм

ульти й (д

ече м соответстви

ровки). чат

тиф лась.

в состоян

п х

т и ти

ен

м и

кан

ду е

тся в

ть аутен

регистри

Т щ

й й

еля с устройством

ден

еж

арки вклю

уск

оверять

бы го

эти и

долж

рую

ащ

ды

и м

я. К

ен

и р

неи

ь объек

еобходи

даем

акое

ен но

С записи м

и в

роцессов

одтверди

п ть з

устройство

кац ен

ла, зап

З. Н

чи золи х ы

и каж

долж опоставляе

е п

ио

дого

ечат

утем

вводе с «пом

в С

долж

, и

ай

ства. Т

я пользоват

ен располагать необходимыми

и н

ествляю отм

яти. К

али

ы б

отчуж

ри

кац

зм

а вода

каж

ой

овпаден К но с ти

С и е

и н и други

ля

ет).

сти

пам ться п

входу

. К

ти

олж

е»). П соответствие ь

ри с ы

кац

адеж

ь и й ти

т, осущ

ехан

вода

устр

п н

аутен

З долж

ти

. Д

ли н

стно

м дулей

н ват

х (

и доступ, долж С

ден

РД

зводи

ввода-вы н

вязи.

пользователем

я а . К

ти

и).

й мо елей д

и вы

е н

ель н

и н

е (откры П

цело

очистки

ече

еткой

сопоставлен но

рован

собы

ию

одулей. Пр

кац

ятствоват утен

и я; субъек

оступ и

а прои

чески н

и алом с и ен

и осах ац

ен

я м и м

ввода

обеспечи )

рован ф

ф р ик

ри а

есурсу

а д

зац

ользоват

ан

та

е («пом

р ен

ен

зац

ц ти ользоват

ти

олж ределен

и устройство ы

» к

зап

и преп

страц

м зм и врем

сп

ти

рос н

золяци

х п

запрош

й п

З.

рограм ы

овнем ы

а ф ден ы

ден ри

сть п

спользован

беспечен С

Реали ка д ра

И но-техн п н

Защ дое ван долж ур н

Реали н ти И н

И п тен ци но

Реги и емо по и дат прос на доступ, то следует зап

О К

r 3

r 4

r 6

r 7

r 8

r 9

r 10

149

Методики сертификационных испытаний

Введем определения, используемые при описании тестовой про-

цедуры. Пусть S = S

{ , S ,..., S ,..., S } — множество тестовых субъектов

доступа и O = O

{ , O ,..., O ,..., O } — множество тестовых объектов до-

ступа, R = R

{ , R ,..., R ,..., R } — множество возможных прав доступа

(например, чтение, запись, удаление и т.п.). Определим матрицу до-

ступа M = m

(

) , m ⊆ R , где m — множество прав доступа тестово-

го субъекта S к тестовому объекту O . Строка матрицы доступа соот-

ветствует субъекту S , а столбец — объекту O . На пересечении строки

и столбца указывается множество прав доступа m ⊆ R соответству-

ющего субъекта к данному объекту.

Оператор наличия права доступа субъекта к объекту в матрице

F : M, S , O , R → { ,

0 }

1 :

 , 1если у субъекта S есть право доступа R кк объекту O ; F (M,S ,O , R )





 ,

0 в противном случае.



Оператор фактического наличия права доступа субъекта к объ-

екту F

: S , O , R → { ,

0 }

1 :

fact

 , 1если у субъекта S есть право доступа R к объекту O ; F (S ,O , R )





fact

 ,

0 в противном случае.



Последовательность выполняемых действий может быть следу-

ющей:

1. Создание тестовых субъектов S = S

{ , S ,..., S ,..., S } и объек-

тов доступа O = O

{ , O ,..., O ,..., O } . Проверка должна проводиться

для всех возможных субъектов и объектов доступа, перечень субъек-

тов и объектов определяется на основе анализа документации на СЗИ.

2. Настройка правил разграничения доступа субъектов испыты-

ваемого СЗИ к тестовым защищаемым объектам. Данная операция за-

ключается в настройке матрицы доступа M = m

(

) , m ⊆ R . В ходе

проведения тестирования проверяются все возможные права доступа

субъектов к объектам, а также их комбинации.

3. Тестирование настроек СЗИ: проверка фактического наличия

права r у субъекта S по отношению к объекту O . Таким же образом

определяются все значения оператора F (S ,O , R ) для любых i, j, k.

fact

Проверка осуществляется с использованием тестовых попыток досту-

па (например, чтение, запись, удаление и т. д.) субъектов к объектам.

4. Сравнение фактических прав доступа с требуемыми правами,

определенными в матрице доступа.

150

Методики сертификационных испытаний

Результатами выполнения тестовой процедуры, подлежащими

регистрации, являются:

1. Множество тестовых субъектов доступа S = S

{ , S ,..., S ,..., S },

множество тестовых объектов доступа O = O

{ , O ,..., O ,..., O } ,

R = R

{ , R ,..., R ,..., R } — множество возможных прав доступа.

2. Результаты настройки правил разграничения доступа — матри-

ца доступа M = m

(

) , m ⊆ R .

3. Результаты проверки фактического наличия права R у субъек-

та S по отношению к объекту O — значения оператора F (S ,O , R )

fact

для всех i, j, k.

Определим критерий принятия положительного решения: в ре-

зультате сравнения фактических прав доступа с требуемыми права-

ми, определенными в матрице доступа, должно быть получено совпа-

дение фактических и требуемых прав доступа:

F (M,S ,O , R ) = F (S ,O , R ) для ∀ i, j, k.

fact

Проверка установленных прав доступа осуществляется путем

осуществления попыток «явного» и «скрытого» доступа субъектов

к объектам с фиксацией результатов проведенных попыток доступа:

успешная или неуспешная.

Анализ полученных данных заключается в сравнении результа-

тов проведенных попыток доступа с ожидаемыми результатами, ко-

торые отражены в тестовой матрице доступа.

Аналогично проверке дискреционного разграничения доступа

проводится проверка сопоставления пользователей и устройств, но объ-

ектами доступа в данном случае будут различные устройства ввода-

вывода.

4.2.2. Методика проверки мандатного принципа контроля доступа

Введем определения, используемые при описании тестовой про-

цедуры. Пусть S = S

{ , S ,..., S ,..., S } — множество тестовых субъек-

тов доступа, O = O

{ , O ,..., O ,..., O } — множество тестовых объек-

тов доступа, M = m

{ , m ,..., m ,..., m } — множество классификаци-

онных меток (классификационных уровней) субъектов и объектов

доступа (классификационные метки являются иерархическими:

m < m <,..., m

< m < m ,..., m

< m ), m — классификацион-

k 1

l 1

ная метка i-го объекта доступа, m — классификационная метка j-го

субъекта доступа.

151

Методики сертификационных испытаний

Введем оператор F

: S , O → { ,

0 }

1 проверки наличия права

READ

на чтение и оператор F

: S , O → { ,

0 }

1 проверки права на запись

WRITE

у субъекта S к объекту O :

 , 1если у субъекта S есть право доступа на чтеение



(S ,O ) =  к объекту O ;

READ

0,в противном случае.



 , 1если у субъекта S есть право доступа на заапись



(S ,O ) =  к объекту O ;

WRITE

0,в противном случае.



Последовательность выполняемых действий включает в себя сле-

дующие действия:

1. Создание тестовых субъектов S = S

{ , S ,..., S ,..., S } и объек-

тов доступа O = O

{ , O ,..., O ,..., O } .

2. Присвоение классификационных меток M = m

{ , m ,..., m ,..., m }

субъектам доступа (задается отображение F : S → M, которое позво-

ляет вычислять классификационный уровень любого субъекта досту-

па, т. е. F S

( ) = m ).

3. Присвоение классификационных меток M = m

{ , m ,..., m ,..., m }

объектам доступа (отображение F : O → M, позволяет вычислить

значения классификационного уровня любого объекта доступа

F O

( ) = m ).

4. Выполнение следующих тестовых попыток доступа субъектов

к объектам:

− чтение данных из объектов доступа субъектами доступа, т. е.

вычисление значений F

: S , O → { ,

0 }

1 для ∀ i, j ;

READ

− запись данных субъектами доступа в объекты доступа, т. е. вы-

числение значений F

: S , O → { ,

0 }

1 для ∀ i, j .

WRITE

5. Проверка полученных результатов на соответствие правилам

мандатного разграничения доступа.

Результаты выполнение тестовой процедуры, подлежащие реги-

страции, будут следующими:

1. Множество тестовых субъектов доступа S = S

{ , S ,..., S ,..., S },

множество тестовых объектов доступа O = O

{ , O ,..., O ,..., O },

M = m

{ , m ,..., m ,..., m } — множество классификационных меток

(классификационных уровней) субъектов и объектов доступа.

152

Методики сертификационных испытаний

2. Результаты настройки правил разграничения доступа — ото-

бражения F : S → M, F : O → M (классификационные метки субъ-

ектов и объектов доступа).

3. Результаты проверки фактического наличия прав на запись

и чтение у субъекта S по отношению к объекту O — значения операто-

ров F

: S , O → { ,

0 }

1 и F

: S , O → { ,

0 }

1 для ∀ i, j .

READ

WRITE

В результате проверки правил мандатного разграничения досту-

па имеем следующие данные:

— субъект доступа S с классификационным уровнем m может

осуществлять чтение данных из объекта доступа O с классификаци-

онным уровнем m тогда и только тогда, когда классификационный

уровень субъекта доступа S выше, либо равен классификационно-

му уровню объекта доступа O , т. е. для ∀ i, j , F

(S ,O ) = 1, тогда

READ

и только тогда, когда m ≥ m ;

— субъект доступа S с классификационным уровнем m может

осуществлять запись данных в объект доступа O с классификацион-

ным уровнем m тогда и только тогда, когда классификационный уро-

вень объекта доступа O выше, либо равен классификационному уров-

ню субъекта доступа S , т. е. для ∀ i, j , F

(S ,O ) = 1 , тогда и только

WRITE

тогда, когда m ≥ m .

Аналогично проводится проверка защиты ввода и вывода на отчуж-

даемый физический носитель информации.

4.2.3. Методика проверки механизмов очистки памяти

Введем определения, используемые при описании тестовой про-

цедуры. Пусть A = a

{ , a ,..., a ,..., a } — множество участков памяти,

подлежащих проверке (оперативная память, разделы на жестком дис-

ке, внешние носители и т. д.), S — тестовая последовательность сим-

волов, используемая при проверке (уникальна для каждого участка

памяти A). В ходе описания проверки будем использовать оператор

наличия тестовой последовательности в памяти F

: a , S → { ,

0 }

1 :

check

 , 1 последовательность S присутствует на участкке a ;

(a ,S) = 



check

 , в противном случае.



Последовательность выполняемых действий следующая:

1. Настройка средств очистки памяти.

2. Помещение тестовых данных в память (уникальная последова-

тельность текстовых символов S).

153

Методики сертификационных испытаний

3. Определение расположения тестовых данных в памяти (адрес,

сектор диска и т.д.).

4. Перераспределение (освобождение) памяти с использованием

штатных средств испытательного стенда.

5. Контроль наличия тестовых данных в памяти (повторный по-

иск и обращение по адресам, определенным на начальном этапе) —

определение значения F

(a ,S) .

check

6. Анализ полученных результатов.

7. Применение критериев оценки.

Результаты выполнения тестовой процедуры, подлежащие реги-

страции, следующие:

1. Результаты настройки средств очистки памяти.

2. Результаты контроля наличия тестовых данных в памяти по-

сле ее перераспределения (освобождения).

Критерий принятия положительного решения следующий: по-

следовательность символов S, помещенная в память, после осво-

бождения (перераспределения) памяти не была обнаружена, т. е.

(a ,S) = 0, ∀ a .

check

4.2.4. Методика проверки механизмов изоляции модулей

Обеспечение изоляции модулей следует из наличия у каждого

процесса (запущенного от имени какого-либо пользователя) отдель-

ного адресного пространства и невозможности прямого доступа

к данному пространству процессами, запущенными от имени других

пользователей.

Последовательность выполняемых действий:

1. Запуск программ (процессов) от имени различных пользова-

телей.

2. Попытки доступа к памяти процессов, запущенных от своего

имени.

3. Попытки доступа к памяти процессов, запущенных от имени

других пользователей (субъектов).

4. Попытки доступа к физической памяти ПЭВМ.

5. Анализ результатов.

6. Применение критериев оценки.

Результатами выполнения тестовой процедуры, подлежащими

регистрации, являются факты попыток доступа к памяти процессов,

запущенных от имени других пользователей, и попыток доступа к фи-

зической памяти ЭВМ.

154

Методики сертификационных испытаний

Критерий принятия положительного решения следующий: до-

ступ к памяти процессов, запущенных от имени других пользовате-

лей, и к оперативной памяти в ходе испытаний получен не был.

4.2.5. Методика проверки механизмов идентификации

и аутентификации субъектов доступа

Введем определения, используемые при описании тестовой

процедуры. Пусть A — алфавит паролей и идентификаторов поль-

зователей СЗИ. Обозначим пользователя id ∈ ID ⊆ A*, пароль —

pwd ∈ PWD ⊆ A*. Учетная запись пользователя usr ∈ USR характе-

ризуется следующим кортежем usr = i( d , pwd ). Введем оператор

корректности учетных данных F

: USR → { ,

0 }

1 :

AUT

 ,1 доступ к СЗИ получен;

( sr ) = 

AUT

0, в противном случае.



При проверке корректности реализации механизмов идентифи-

кации и аутентификации субъектов может быть использована следу-

ющая последовательность выполняемых действий:

1. Включение механизма идентификации и аутентификации

СЗИ и создание множества учетных записей субъектов доступа

USR = u

{ sr , usr ,...}.

2. Выполнение запросов на идентификацию и проведение аутен-

тификации с использованием различных сочетаний учетных данных:

зарегистрированный/незарегистрированный идентификатор, вер-

ный/неверный пароль — try = i( d , pwd ).

3. Анализ полученных данных.

Результаты выполнение тестовой процедуры, подлежащие реги-

страции:

1. Конфигурация СЗИ — множество USR учетных записей субъ-

ектов доступа.

2. Полученные результаты тестовых запросов на идентифика-

цию и аутентификации: множество { F

( try ), F

( try ),...}.

AUT

Критерии принятия положительного решения:

1. После ввода зарегистрированного идентификатора и паро-

ля пользователю предоставляется доступ к защищаемым ресурсам:

t( ry ) = 1 ⇔ try ∈ ADM.

AUT

2. После ввода незарегистрированного идентификатора и/или

неверного пароля пользователю отказывается в доступе к защищае-

мым ресурсам: F

t( ry ) = 0 ⇔ try ∉ ADM.

AUT

155

Методики сертификационных испытаний

Проверка надежности связывания идентификации и аутентифи-

кации пользователя со всеми его действиями осуществляется в ходе

проведения проверок дискреционного и мандатного принципов раз-

граничения доступа. По окончании каждой из проверок анализиру-

ется содержимое журналов регистрации событий.

Проверка считается успешно выполненной, если журнал аудита

содержит записи обо всех попытках доступа и всех действиях любых

пользователей (в том числе администраторов безопасности), осущест-

вленных в ходе проверок по предыдущим пунктам. При этом в каж-

дой регистрационной записи присутствует информация об иденти-

фикаторе пользователя, который был предъявлен при попытке досту-

па, и/или под которым пользователь был зарегистрирован в системе

и выполнял различные действия.

4.2.6. Методика проверки механизмов контроля целостности

Пусть FILE = { file , file ,..., file } — множество файлов СЗИ (кон-

фигурационные файлы, программные модули). Введем операторы на-

рушения целостности F

и контроля целостности файлов СЗИ F .

MOD

INT

Оператор нарушения целостности F

: FILE → { ,

0 }

1 :

MOD

 ,1

 целостность файла нарушается при проведении



( file) =  испытаний;

MOD

0, в противном случае.



Оператор контроля целостности файлов СЗИ F

: FILE → { ,

0 }

1 :

INT

 целостность файла нарушена;

F ( file) = 

INT

0, в противном с



ллучае.



Обозначим FILE D

file D file D

file D

= {

,...,

} — множество файлов

СЗИ, модифицированных в ходе проведения испытания. При этом

выполняется модификация файла file в файл file D . При проверке

корректности реализации механизма контроля целостности СЗИ мо-

жет быть использована следующая последовательность выполняемых

действий:

1. Настройка средств контроля целостности (реакция на нару-

шение целостности, способ контроля целостности, период проверки,

условие проверки и т. д.) и идентификация множества файлов СЗИ

FILE = { file , file ,...} .

156

Методики сертификационных испытаний

2. Внесение изменений в файлы СЗИ (изменение конфигурации,

подмена (модификация) исполняемых файлов и т. п.) — получение

множества измененных файлов FILE D

file D file D

= {

,...} .

3. Инициализация проверки целостности файлов СЗИ (создание

условий, при которых СЗИ осуществляет контроль целостности).

4. Анализ реакции СЗИ на нарушение целостности своей про-

граммной или информационной части.

Результаты выполнения тестовой процедуры, подлежащие реги-

страции:

1. Множество файлов СЗИ FILE = { file , file ,...} .

2. Множество модифицированных файлов СЗИ FILE D

file D file D

= {

,...}.

3. Реакции СЗИ на нарушение целостности: F ( file D), F ( file D),...

INT

Критерий принятия положительного решения: СЗИ обнаружены

все факты нарушения целостности:

F ( file D) = F

( file ) для ∀ i ∈ [ ,

1 n] .

INT

MOD

4.3. Методика испытаний межсетевых экранов

Требования к межсетевым экранам (МЭ) по безопасности инфор-

мации определены в РД Гостехкомиссии России, в котором указаны

пять классов защищенности (см. подр. 2.4.2, табл. 2.5). Каждый класс

защищенности МЭ характеризуется минимальной совокупностью

требований. Рассмотрим порядок проверки для наиболее ресурсоем-

ких требований R = r

{ , r , r (см. табл 4.2).

1 2

3 }

4.3.1. Проверка механизмов фильтрации данных

и трансляции адресов

Цель выполнения проверки состоит в определении степени со-

ответствия функциональных возможностей МЭ по фильтрации се-

тевых пакетов с учетом следующих параметров: сетевого адреса от-

правителя, сетевого адреса получателя. Исходными данными для

формирования тестовой процедуры τ являются множество сете-

вых адресов, используемых в тестовых сегментах: IP = IP

IP = IP

∪

{ 1 IP 2 … IP 1 IP 2

, ,

IP = IP

∪

{ 1 IP 2 … IP 1 IP 2

, ,

}. Предполагается, что при проведении тести-

рования выполняется отправление пакетов из внешнего сегмента

сети (сетевые адреса вида IPi ) во внутренний сегмент (сетевые адре-

са вида IP j ).

Проверка включает следующие шаги:

157

Методики сертификационных испытаний

Таблица 4.2

Основные требования к межсетевым экранам

Обозначение

Требование

МЭ должен обеспечивать фильтрацию на сетевом

уровне. Решение по фильтрации может приниматься

для каждого сетевого пакета независимо на основе,

по крайней мере, сетевых адресов отправителя и по-

лучателя или на основе других эквивалентных атри-

бутов.

МЭ должен обеспечивать идентификацию и аутенти-

фикацию администратора МЭ при его запросах на

доступ. МЭ должен предоставлять возможность для

идентификации и аутентификации по идентификато-

ру (коду) и паролю условно-постоянного действия. До-

полнительно МЭ должен препятствовать доступу неи-

дентифицированного субъекта или субъекта, подлин-

ность идентификации которого при аутентификации

не подтвердилась.

МЭ должен содержать средства контроля за целостно-

стью своей программной и информационной части.

1. Настройка правил фильтрации МЭ в соответствии с про-

веряемым требованием, в результате чего формируется множе-

ство запрещающих RULE 0

rule 0

{

, rule 0

,…} и разрешающих

RULE 1

rule 1

{

, rule 1

,…} правил межсетевого экранирования, при-

чем, каждое правило представляет собой упорядоченное множество

вида rule

IPi, IP j

0 1 = (

), где: IPi — сетевой адрес отправителя, IP j —

сетевой адрес получателя.

2. Запуск ПС перехвата и анализа сетевых пакетов во внутрен-

нем и внешнем сегментах сети.

3. Генерация сетевых пакетов из внешнего сегмента сети во вну-

тренний сегмент для всех возможных пар (отправитель, получатель):

packet

IPi, IP j , payload k

= (

4. Завершение перехвата сетевых пакетов. В результа-

те получаем следующие множества перехваченных пакетов

PACKET IN

{ packetIN, packetIN

,… и PACKETOUT

{ packetOUT, packetOUT

,… ,

}

где packet IN

IPi, IP j , payload k

= (

) — сетевые пакеты, перехваченные во

158

Методики сертификационных испытаний

внешнем сегменте, packetOUT

IPi, IP j , payload k

= (

) — сетевые пакеты,

перехваченные во внутреннем сегменте.

5. Экспорт журнала регистрации разрешенных и запрещенных

пакетов МЭ. В результате выполнения формируется множество запи-

сей о запрещении прохождения JOUR 0

{ journal 0, journal 0

,…} и раз-

решении прохождения JOUR 1

{ journal 1, journal 1

,…} сетевого паке-

та. Каждая запись имеет вид: journal 0 1

/ = ( IPi, IP j ).

Результатами выполнения тестовой процедуры являются:

1. Конфигурация МЭ — множества rule 0

{

} и rule 1

{

2. Результаты перехвата сетевых пакетов на внешнем и внутрен-

нем интерфейсах МЭ — множества packet IN

{

} и packetOUT

{

} .

3. Фрагмент журнала регистрации событий МЭ, демонстрирую-

щий результаты фильтрации сетевых пакетов: множества journal 0

{

}

и journal 1

{

В качестве критерия принятия положительного решения при-

мем фиксацию факта соответствия реальных (пакеты на входном ин-

терфейсе МЭ, пакеты на выходном интерфейсе МЭ и фрагмент жур-

нала регистрации событий МЭ) и ожидаемых результатов (правила

фильтрации МЭ):

PACKET



OUT



= RULE 1;

 PACKET



/ PACKET OUT = RULE 0;

 PACKETOUT



= JOUR 1;

 P AACKETIN PACKETOUT

= JOUR 0.



При проведении тестирования могут быть использованы, напри-

мер, следующие ПС: nmap, Packet Generator (генерация сетевых паке-

тов), wireshark, tcpdump (перехват и анализ сетевых пакетов), программ-

ный комплекс «Сканер-ВС» (генерация, перехват и анализ сетевых па-

кетов) [20, 29, 56].

К МЭ предъявляются также аналогичные требования к механиз-

мам фильтрации на других уровнях модели ISO/OSI. Для канально-

го уровня требование выглядит следующим образом: «МЭ должен

обеспечивать фильтрацию с учетом входного и выходного сетевого

159

Методики сертификационных испытаний

интерфейса как средство проверки подлинности сетевых адресов».

Методика проверки аналогична методике, представленной выше,

но в качестве критериев фильтрации используются адреса канально-

го уровня (MAC-адрес). На сетевом уровне проверяется требование

по фильтрации с учетом любых значимых полей сетевых пакетов. При

проведении испытаний, как правило, внимание следует уделять тести-

рованию механизма фильтрации с учетом следующих полей пакета

сетевого уровня: адрес отправителя, адрес получателя, тип протоко-

ла верхнего (транспортного) уровня, время жизни пакета (TTL) [27].

4.3.2. Проверка механизмов идентификации и аутентификации

администраторов

Целью проверки является определение степени соответствия

функциональных возможностей МЭ по идентификации и аутенти-

фикации администратора МЭ.

Будем считать, что A — алфавит паролей и идентификаторов

администраторов МЭ. Обозначим идентификатор администрато-

ра id ∈ ID ⊆ A* , пароль — pwd ∈ PWD ⊆ A*. Учетная запись адми-

нистратора adm ∈ ADM характеризуется следующим кортежем

adm = i

( d , pwd ).

Введем оператор корректности учетных данных F

: ADM → { ,

0 }

1 :

AUT

 , доступ на администрирование получен;

( dm) = 

AUT

 , в проотивном случае.



Предполагается, что идентификация/аутентификация выпол-

няется с использованием сетевых протоколов с ЭВМ внутреннего

сегмента сети. Тогда проверка будет включать следующую последова-

тельность действий:

1. Включение механизма идентификации и аутентификации

МЭ и создание множества учетных записей администраторов МЭ

ADM = a

{ dm , adm ,… .

}

2. Запуск ПС перехвата и анализа сетевых пакетов во внутрен-

нем сегменте сети.

3. Выполнение запросов на идентификацию и проведение аутен-

тификации с использованием различных сочетаний учетных данных:

зарегистрированный/незарегистрированный идентификатор, вер-

ный/неверный пароль — try = i

( d , pwd ).

160

Методики сертификационных испытаний

4. Генерация сетевых пакетов из внутренней сети во внешнюю

(или наоборот), прохождение которых разрешается (запрещается)

в соответствии с правилами фильтрации МЭ.

5. Завершение перехвата сетевых пакетов, экспорт журнала ре-

гистрации событий МЭ.

6. Анализ на предмет наличия учетных данных, передаваемых

в открытом виде.

При выполнении проверки реализации локальной идентифика-

ции/аутентификации шаги 2, 5 последовательности действий не вы-

полняются.

Результатами выполнения тестовой процедуры являются:

1. Конфигурация МЭ — множество ADM учетных записей адми-

нистраторов МЭ.

2. Полученные результаты тестовых запросов на идентифика-

цию и аутентификацию: множество F

{

( ry )}.

AUT

3. Результаты перехвата сетевых пакетов на внешнем и внутрен-

нем интерфейсах МЭ.

4. Фрагмент журнала регистрации событий МЭ, демонстрирую-

щий результаты идентификации и аутентификации.

Определим критерии принятия положительного решения:

1. После ввода зарегистрированного идентификатора и пароля

пользователю предоставляется доступ к средствам администрирова-

ния МЭ: F

( ry ) = 1 ⇔ try ∈ ADM.

AUT

2. После ввода незарегистрированного идентификатора и/или

неверного пароля пользователю отказывается в доступе к средствам

администрирования МЭ: F

( ry ) = 0 ⇔ try ∉ ADM.

AUT

3. Журнал регистрации событий содержит записи обо всех тесто-

вых попытках получения доступа.

4. Попытки поиска идентификационных данных (имя пользова-

теля, пароль) в перехваченных пакетах не дали результатов.

При проведении тестирования механизмов идентификации/ау-

тентификации для перехвата и анализа сетевых пакетов могут быть

использованы, например, программы wireshark, tcpdump, программ-

ный комплекс «Сканер-ВС» и др.

4.3.3. Проверка механизмов контроля целостности

Проверка состоит в определении степени соответствия функци-

ональных возможностей МЭ по контролю целостности программной

и информационной части МЭ.

161

Методики сертификационных испытаний

Пусть FILE = { file , file ,…, file — множество файлов МЭ (кон-

}

фигурационные файлы, программные модули). Введем операторы на-

рушения целостности F

и контроля целостности файлов МЭ F .

MOD

INT

Оператор нарушения целостности F

: FILE → { ,

0 }

1 :

MOD

1, целостность



файла нарушена при проведении исппытаний;

( file) = 

MOD

 в противном случае.



Оператор контроля целостности файлов МЭ F

: FILE → { ,

0 }

1 :

INT

 целостность файла нарушена;

( file) = 

INT



в противном сслучае.



Обозначим FILE D

{ file D, file D, , file D

…

— множество файлов

}

МЭ, модифицированных в ходе проведения испытания. При этом

выполняется модификация файла file в файл file D . При проверке

корректности реализации механизма контроля целостности МЭ мо-

жет быть использована следующая последовательность выполняемых

действий:

1. Включение механизма контроля целостности программной

и информационной части МЭ и идентификация множества файлов

МЭ FILE = { file , file ,…, file .

}

2. Внесение изменений в файлы МЭ (изменение конфигурации,

подмена (модификация) исполняемых файлов и т. п.) — получение

множества измененных файлов FILE D

{ file D, file D, , file D

…

}

3. Инициализация проверки целостности файлов МЭ (создание

условий, при которых МЭ осуществляет контроль целостности).

4. Анализ реакции МЭ на нарушение целостности своей про-

граммной или информационной части.

Результатами выполнения тестовой процедуры следует считать:

1. Множество файлов МЭ FILE = { file , file ,…, file .

}

2. Множество модифицированных файлов МЭ

FILE D

{ file D, file D, , file D

…

}

3. Реакции МЭ на нарушение целостности:

file D , F

file D , , F

file D

(

)

(

) …

(

INT

В качестве критерия принятия положительного решения при-

мем факт, что обнаружены все факты нарушения целостности:

file D

(

) = F ( file ).

INT

MOD

162

Методики сертификационных испытаний

4.4. Методика испытаний

автоматизированных систем

Под автоматизированной системой (АС) будем понимать систе-

му, состоящую из персонала и комплекса средств автоматизации его

деятельности, реализующую информационную технологию выпол-

нения установленных функций38. Таким образом, АС представляет

собой совокупность следующих объектов: средства вычислительной

техники, программное обеспечение, каналы связи, информация на

различных носителях, персонал и пользователи системы, эксплуата-

ционная и организационно-распорядительная документация.

Руководящий документ Гостехкомиссии России по АС устанавли-

вает классификацию АС, подлежащих защите от НСД к информации,

и задаёт требования по защите информации в АС различных клас-

сов (см. подр. 2.4.3, табл. 2.6). Рассмотрим формализованный порядок

проверки для наиболее ресурсоемких требований R = r

{ , r , r (см.

1 2

3 }

табл. 4.3).

Перед началом проведения тестирования эксперты должны уста-

новить, что в технической документации (например, в задании

по безопасности на АС) на объект испытаний декларируется соответ-

ствие АС требованиям R , то есть F (S, r ) = 1 для ∀ r ∈ R .

Таблица 4.3

Основные требования к автоматизированным системам

Обозначе-

ние

Требование

Должна осуществляться идентификация и проверка подлин-

ности субъектов доступа при входе в систему по идентифика-

тору (коду) и паролю условно-постоянного действия, длиной

не менее шести буквенно-цифровых символов

Должен осуществляться контроль доступа субъектов к защи-

щаемым ресурсам в соответствии с матрицей доступа

Должна быть обеспечена целостность программных средств

защиты информации от НСД, а также неизменность про-

граммной среды

38 ГОСТ 34.003-90.

163

Методики сертификационных испытаний

4.4.1. Методика проверки механизмов идентификации

и аутентификации субъектов доступа

Проверка выполняется с целью контроля организационных ме-

роприятий, которые позволяют удовлетворить требования к пароль-

ной политике, анализу установленных параметров функционирова-

ния средств идентификации и аутентификации, контролю коррект-

ности функционирования механизмов идентификации и аутентифи-

кации, а также контролю процедуры смены паролей пользователями.

Введем определения, используемые при описании тестовой про-

цедуры. Пусть A — алфавит паролей и идентификаторов субъектов до-

ступа (пользователей АС). Обозначим идентификатор пользователя

id ∈ ID ⊆ A* , пароль — pwd ∈ PWD ⊆ A* . Учетная запись субъекта до-

ступа s ∈ S характеризуется следующим кортежем. Введем оператор

корректности учетных данных F

: S → { ,

0 }

1 :

AUT

 выполнен вход в систему;

( ) = 

AUT



в противном случаее.



При проверке корректности реализации механизмов идентифи-

кации и аутентификации может быть использована следующая тесто-

вая процедура.

Тогда проверка будет включать следующую последовательность

действий:

1. Проверить наличие эксплуатационных документов на АС,

в которых регламентирован порядок проведения парольной защиты

АС. Проверить наличие следующих положений:

− требования к сложности паролей (длина, сложность);

− обязанности администратора безопасности по реализации па-

рольной политики АС (генерация паролей, распределение паролей);

− обязанности пользователей по реализации парольной полити-

ки АС (генерация паролей, смена паролей).

2. Определить установленные СЗИ от НСД в АС значения для

следующих параметров: минимальная длина пароля, сложность па-

роля (алфавит паролей), максимальный срок действия пароля, макси-

мальное число неудачных попыток входа пользователей в АС, после

которого осуществляется блокировка работы пользователя, реакция

АС на превышение максимального числа неудачных попыток входа

пользователя.

3. Произвольным образом выбрать несколько АРМ и выполнить

запросы на идентификацию и проведение аутентификации с исполь-

164

Методики сертификационных испытаний

зованием различных сочетаний учетных данных: зарегистрирован-

ный/незарегистрированный идентификатор, верный/неверный па-

роль — try = i

( d , pwd ).

4. Под учетными записями пользователей произвести попытки

установить пароль, не соответствующий нормативным требованиям.

Для этого осуществить:

− попытку установить пароль, длина которого менее 6 символов;

− попытки установить пароль, состоящий исключительно из

цифр, либо только из букв.

Результатами выполнения тестовой процедуры, подлежащими

регистрации, являются:

1. Положения документации на АС относительно реализации

и сопровождения системы парольной защиты.

2. Конфигурация СЗИ от НСД АС в части реализации парольной

защиты.

3. Полученные результаты тестовых запросов на идентифика-

цию и аутентификации — множество F

{

( ry )}.

AUT

4. Полученные результаты тестовых попыток изменения паролей.

В данном случае критериями принятия положительного реше-

ния являются следующие:

1. В документах организации, эксплуатирующей АС, установлены

требования (сложность, минимальная длина) к паролям пользователей

рассматриваемой АС, соответствующие нормативным требованиям.

2. В нормативных документах организации, эксплуатирующей

АС, описана процедура действий администратора безопасности

по реализации парольной политики АС (процедуры генерация паро-

лей, распределение паролей);

3. Настройки СЗИ от НСД выполнены таким образом, что длина

пароля для пользователей АС не может быть менее 6 символов, а уста-

новленные ограничения сложности не позволяют использовать паро-

ли, состоящие из однотипных символов.

4. После ввода зарегистрированного идентификатора и пароля

пользователю предоставляется доступ к АС: F

( ry ) = 1 ⇔ try ∈ S.

AUT

5. После ввода незарегистрированного идентификатора и/

или неверного пароля пользователю отказывается в доступе к АС:

( ry ) = 0 ⇔ try ∉ S.

AUT

6. Все попытки установить пароль, не соответствующий норма-

тивным требованиям, завершились неудачно.

165

Методики сертификационных испытаний

4.4.2. Методика проверки механизмов управления доступом

Целью проверки является определение степени соответствия

фактических настроек системы дискреционного разграничения до-

ступа требуемым настройкам, определенным в матрице доступа. Ис-

ходными данными для формирования тестовой процедуры являют-

ся: множество возможных субъектов доступа S = S

{ } , множество

защищаемых объектов O = O

{ } , конечное множество прав доступа

P = P

{ } и матрица доступа.

Последовательность выполняемых действий следующая:

1. Идентификация субъектов (например, пользователей)

S = S

{ } и объектов доступа (например, объектов файловой систе-

мы) O = O

{ }.

2. Идентификация матрицы доступа субъектов к защищаемым

объектам.

3. Для каждой тройки S

( , O , P ) ∈ S × O × P выполнение тести-

рования фактического наличия права P у субъекта S по отношению

к объекту O (тестирование настроек СЗИ АС).

4. Сравнение фактических прав доступа с требуемыми правами,

определенными в матрице доступа.

Результаты выполнения тестовой процедуры, подлежащие реги-

страции:

1. Матрица доступа субъектов к защищаемым объектам.

2. Фактические результаты тестирования системы дискрецион-

ного разграничения доступа.

В качестве критерия принятия положительного решения имеем

полученное соответствие фактических и декларируемых прав досту-

па, определенных в матрице доступа.

4.4.3. Методика проверки механизмов контроля целостности

Целью выполнения процедуры является определение степени со-

ответствия функциональных возможностей СЗИ от НСД АС по кон-

тролю целостности программных СЗИ от НСД.

Пусть FILE = { file } — множество файлов СЗИ от НСД (конфи-

гурационные файлы, программные модули). Введем операторы нару-

шения целостности — F

и контроля целостности файлов СЗИ от

MOD

НСД — F .

INT

Оператор нарушения целостности F

: FILE → { ,

0 }

1 :

MOD

166

Методики сертификационных испытаний

1, целостность



файла нарушена при проведении исппытаний;

( file) = 

MOD

0, в



противном случае.



Оператор контроля целостности файлов СЗИ от НСД

: FILE → { ,

0 }

1 :

INT

 зафиксировано нарушение целостности файла;

( file) = 

INT

 , в противном случае.



Обозначим FILE D

{ file D, file D, , file D

…

— множество файлов

}

СЗИ от НСД, модифицированных в ходе проведения испытания. При

этом выполняется модификация файла file в файл file D . При про-

верке корректности реализации механизма контроля целостности

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

Последовательность выполняемых действий следующая:

1. Идентификация множества файлов СЗИ от НСД

FILE = { file , file ,…, file .

}

2. Внесение изменений в файлы (изменение конфигурации, под-

мена (модификация) исполняемых файлов и т. п.) — получение множе-

ства измененных файлов FILE D

{ file D, file D, , file D

…

}

3. Инициализация проверки целостности файлов СЗИ от НСД

(создание условий, при которых СЗИ от НСД осуществляет контроль

целостности).

4. Анализ реакции СЗИ от НСД на нарушение целостности своей

программной или информационной части.

Результатами выполнения тестовой процедуры, подлежащими

регистрации, являются:

1. Множество файлов FILE = { file , file ,…, file .

}

2. Множество модифицированных файлов

FILE D

{ file D, file D, , file D

…

}

3. Реакции СЗИ от НСД на нарушение целостности:

file D , F

file D , , F

file D

(

)

(

) …

(

INT

Критерием принятия положительного решения является факт,

что средствами защиты информации обнаружены все факты наруше-

ния целостности:

file D

(

) = F ( file ) для ∀ i ∈ 1, n .

INT

MOD





167

Методики сертификационных испытаний

4.5. Методика проведения испытания

по требованиям «Общих критериев»

Процедуру проведения оценки в соответствии с ОК в общем виде

можно сформулировать следующим образом. Пусть C = c

{ , c ,..., c —

}

множество компонент требований доверия к безопасности, предъ-

являемых к ОО S. Как правило, множество C формируется с ис-

пользованием одного из предопределенных ОУД. Для каждой ком-

поненты требования доверия c определено множество действий

E i() = e i()

{ e i() e i()

,...,

( n — число действий оценщика для компоненты

}

c ), которое должен выполнить оценщик (как правило, аккредитован-

ная испытательная лаборатория) для подтверждения соответствия

ОО предъявляемой компоненте c . Для каждого действия оценщика

e i() разрабатывается множество S i() = s i() s i()

s i()

,...,

{

шагов оце-

}

j _

j _ m( i)

нивания — наименьшей структурной единицы работ по оцениванию

( m i() — число шагов оценивания для действия оценщика e i() ).

В табл. 4.4 приведен пример действий оценщика и шагов оцени-

вания для компоненты доверия ATE_IND.2 «Выборочное независи-

мое тестирование».

Следует отметить, что разработка шагов оценивания выполня-

ется экспертами испытательной лаборатории на основе методологии

оценки безопасности информационных технологий, представленной

в ГОСТ Р ИСО/МЭК 18045—2008 (см.подр.2.7.4).

Сформулируем метод разработки шагов оценивания, под которым

будем понимать отображение M : S× E → S.

Функция M на основе действия оценщика e i() и информации

о реализации (свидетельств разработчика) ОО S осуществляет гене-

рацию множества шагов оценивания S i() , выполняемого для провер-

ки удовлетворения ОО множеству C компонент требований доверия.

Как правило, функция M для ОО S является биективным отображе-

нием.

Оператором корректности выполнения действия оценщика e i()

E i()

∈

для ОО S назовем F : S× E → { ,

0 }

1 :

1, для ОО





все шаги оценивания действия e i()



F ( ,

S e i()) =  выполнены успешно;

 , 0в противном случае.



168

Методики сертификационных испытаний

Таблица 4.4

Пример действий оценщика и шагов оценивания

Компонента

( )

Шаг оценивания s i

доверия c

Действие оценщика e

j _ v

ATE_IND.2

ATE_IND.2.1E

ATE_IND.—1 Оценщик должен ис-

Оценщик должен под- следовать ОО, чтобы сделать за-

твердить, что представ- ключение, согласуется ли тести-

ленна я информация руемая конфигурация с оценива-

удовлетворяет всем тре- емой конфигурацией, определен-

бованиям к содержанию ной в ЗБ.

и представлению свиде-

тельств

ATE_IND.—2 Оценщик должен ис-

следовать ОО, чтобы сделать за-

ключение, правильно ли он уста-

новлен и находится ли в состоя-

нии, которое известно

ATE_IND.—3 Оценщик должен ис-

следовать набор ресурсов, пред-

ставленных разработчиком, что-

бы сделать заключение, эквива-

лентны ли они набору ресурсов,

использованных разработчиком

для функционального тестирова-

ния ФБО

…

Процедурой оценки назовем набор из четырех объектов

A = S

{ , C, M, F , где C — множество компонент требований доверия

S }

к безопасности, предъявляемых к ОО S, M- метод разработки шагов

оценивания, а F — оператор корректности выполнения действия

оценщика.

Процедура предусматривает наличие трех стадий: планирова-

ние, выполнение оценки, а также анализ и оформление результатов

оценки (рис. 4.1).

На стадии планирования выполняются задачи получения и ана-

лиза исходных данных для проведения оценки. На основании выпол-

ненного анализа формируются множества E i() = e i()

{ e i() e i()

,...,

дей-

}

ствий оценщика и соответствующих им шагов оценивания. Выпол-

нение оценки осуществляется с использованием сформированного

набора шагов оценивания.

169

Методики сертификационных испытаний

Заключительная стадия предполагает выполнение анализа ре-

зультатов оценки (сравнение фактических и эталонных результатов).

В результате анализа получаем множество упорядоченных пар вида

e i()

( F S e i()

, ( ,

)). Для ОО S декларируется соответствие компоненте

требования доверия c , если в ходе выполнения множества действий

оценщика E i() = e i()

{ e i() e i()

,...,

для каждого получены положитель-

}

ные результаты:

∑( F ( , e( j)

)) = n .

j =1

По результатам проведения оценки оформляется техни-

ческий отчет об оценке. Для ОО декларируется соответствие

требованиям доверия к безопасности C = c

{ , c ,..., c , если

}

∀ i ∈ 

( j )





1, n ∑( F ( ,S e )) = n .

j =1

При проведении оценки, как правило, применяются следующие

методы:

− экспертно-документальный;

− функциональное тестирование;

− статический и динамический анализ исходных текстов;

− тестирование проникновением.

Экспертно-документальный метод заключается в проверке соот-

ветствия ОО установленным требованиям на основании экспертной

Документация, стандарты,

информация об ОО

Оценка соответствия

Планирование

Выполнение

Анализ и

Генерация действий

оценки

оформление

оценщика

Результаты оценки

результатов оценки

Технический отчет

об оценке

Множество требований

Решение

Рис. 4.1. Процедура оценки в соответствии с «Общими критериями»

170

Методики сертификационных испытаний

оценки полноты и достаточности представленных свидетельств и мо-

жет использоваться для:

− анализа и проверки процессов и процедур, связанных с разра-

боткой и реализацией ОО;

− анализа эксплуатационной документации;

− анализа разработанных функциональных тестов и получен-

ных результатов;

− оценки соответствия параметров ОО исходным требованиям.

Функциональное тестирование заключается в проверке функций

безопасности ОО с использованием специализированных тестирую-

щих средств (применяется при независимом функциональном тести-

ровании).

Статический анализ исходных текстов состоит в синтаксическом

и семантическом анализе структуры и взаимосвязей функциональ-

ных и информационных объектов программ и построении маршру-

тов выполнения функциональных объектов. Динамический анализ

представляет собой динамический контроль выполнения функцио-

нальных объектов (ветвей) программы (в отладочном режиме и/или

с фиксацией трассы выполнения программы) и используется для де-

тального исследования алгоритма программы. Данные методы могут

использоваться для выполнения:

− анализа соответствия между представлениями проекта ОО;

− анализа соответствия каждого представления проекта ОО

установленным требованиям;

− анализа программных дефектов;

− проверки корректности представленных доказательств разра-

ботчика.

Тестирование проникновением заключается в санкционирован-

ной попытке обойти существующий комплекс средств защиты ОО.

В ходе тестирования оценщик играет роль злоумышленника, мотиви-

рованного на нарушение информационной безопасности.

4.6. Рекомендации по оптимизации испытаний

Основной проблемой оценки соответствия СЗИ является экспо-

ненциальный рост временных и материальных затрат на выполне-

ние типовых операций при увеличении сложности разрабатываемых

СЗИ и при большом количестве платформ и сред, на которых данные

СЗИ могут функционировать. Например, при проведении проверки

механизма дискреционного разграничения доступа необходимо вы-

полнить S ⋅ O ⋅ R типовых операций (см. разд. 4.3). Можно показать, 171

Методики сертификационных испытаний

что время τS, затрачиваемое на проведение испытаний, носит экспо-

ненциальный характер роста: t ~ nvw , где n — число проверяемых

требований, w — число факторов тестирования (например, «учетная

запись пользователя»), v — число возможных значений фактора тести-

рования.

В общем случае задача оптимизации процедуры оценки соответ-

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

Пусть t : E ×S → N — это время, затрачиваемое оценщиками на

выполнение проверки ОО S с использованием действия оценщика e i() .

Будем считать, что отображение вида G : C ×S → N представляет за-

траты на проведение оценки ОО S требованиям C.

Решение задачи оптимизации может быть определено как по-

лучение минимума времени тестирования при ограничениях на за-

траты:



∑∑ e i()



( ,S) → min;

 i

∑ G c( ,S)≤ G ,

 i

где: G — ограничения, накладываемые на затраты.

Опыт проведения сертификационных испытаний СЗИ позво-

лил определить ряд методических рекомендаций, позволяющих су-

щественно снизить затраты на оценку соответствия, например:

— совмещение проверок,

— использование выборочного контроля и анализа риска [59],

— использование комбинаторного покрытия�,

— использование средств автоматизации.

При проведении независимого функционально тестирования

рекомендуется выполнять совмещение некоторых видов испытаний.

Например, процедура тестирования подсистемы регистрации собы-

тий может быть совмещена с процедурой тестирования подсистемы

разграничения доступа и идентификации/аутентификации.

Существенное сокращение работ может быть достигнуто при

обосновании возможности проведения выборочного контроля, ко-

торый позволяет применение процедуры проверки менее чем к 100%

совокупности контролируемых элементов (например: свидетельств

разработчика, тестируемых функций безопасности). При использо-

вании методов выборочного контроля необходимо установить прио-

ритеты проверяемых требований с целью дальнейшего определения

необходимого количества тестируемых объектов.

172

Методики сертификационных испытаний

Для сокращения временных затрат и повышения качества отчет-

ных материалов при проведении испытаний необходимо использо-

вать программные средства, позволяющие автоматизировать проце-

дуры оценки соответствия. Для независимого тестирования можно

использовать как инструментальные средства, широко представлен-

ные на современном рынке программного обеспечения, так и про-

граммы собственной разработки, написанные на языках сценариев

(например, perl или python), для анализа уязвимостей — сканеры без-

опасности, для документирования — программы типа Doxygen, для

проведения анализа исходных текстов — анализаторы безопасности

кода [2, 4, 19, 56, 71, 79].

4.7. Рекомендации по контролю отсутствия

недекларированных возможностей

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

СЗИ является наиболее проблемным, трудоемким и ответственным

видом испытаний [13, 41, 54, 59, 62, 66, 68, 79]. Требования к сертифи-

кационным испытаниям ПО на отсутствие НДВ определены в РД «За-

щита от несанкционированного доступа к информации Часть 1. Про-

граммное обеспечение средств защиты информации. Классификация

по уровню контроля отсутствия недекларированных возможностей»

(Гостехкомиссия России, 1999), который рассмотрен в подр. 2.4.4. Для

того чтобы выполнить все требования, указанные в таблице 2.7, рас-

смотрим порядок проведения испытаний на отсутствие НДВ для 2-го

уровня контроля.

4.7.1. Общий порядок проведения испытаний

Общий порядок проведения испытаний по контролю отсутствия

НДВ следующий:

1. Контроль состава и содержания документации;

2. Контроль исходного состояния ПО (идентификация объекта

испытаний);

3. Статический анализ исходных текстов;

4. Динамический анализ исходных текстов;

5. Формирование отчетных документов.

В случае доработки ПО, при выявлении НДВ все этапы должны

повторяться для всех изменившихся модулей исходных текстов про-

грамм.

173

Методики сертификационных испытаний

В состав документации, представляемой заявителем, в соответ-

ствии с требованиями РД должны входить:

— Спецификация (ГОСТ 19.202—78), содержащая сведения о со-

ставе ПО и документации;

— Описание программы (ГОСТ 19.402—78), содержащее основ-

ные сведения о составе (с указанием контрольных сумм файлов, вхо-

дящих в состав ПО), логической структуре и среде функционирова-

ния ПО, а также описание методов, приемов и правил эксплуатации

средств технологического оснащения при создании ПО;

— Описание применения (ГОСТ 19.502—78), содержащее сведе-

ния о назначении ПО, области применения, применяемых методах,

классе решаемых задач, ограничениях при применении, минималь-

ной конфигурации технических средств, среде функционирования

и порядке работы;

— Пояснительная записка (ГОСТ 19.404—79), содержащая основ-

ные сведения о назначении компонентов, входящих в состав ПО, па-

раметрах обрабатываемых наборов данных (подсхемах баз данных),

формируемых кодах возврата, описание используемых переменных,

алгоритмов функционирования;

— Исходные тексты программ (ГОСТ 19.401—78), входящих в со-

став ПО.

Контроль состава документации должен проводиться эксперта-

ми ИЛ путем сравнения перечня представленных документов с тре-

бованиями руководящего документа.

Контроль содержания документации осуществляется, как по со-

ответствию формальным требованиям ГОСТ к содержанию состав-

ных частей документов, так и по соответствию реальным возможно-

стям ПО.

Контроль исходного состояния ПО заключается в фиксации ис-

ходного состояния ПО и сравнении полученных результатов с резуль-

татами, приведенными в документации на продукт, например, в Фор-

муляре или Технических условиях.

Результатами контроля исходного состояния должны быть рас-

считанные уникальные значения контрольных сумм модулей дистри-

бутива и исходных текстов программ, входящих в состав сертифици-

руемого программного изделия. Контрольные суммы должны рассчи-

тываться для каждого файла, входящего в состав сертифицируемого

продукта.

Общий порядок проведения сертификационных испытаний на

отсутствие НДВ приведен на рис. 4.2.

174

Методики сертификационных испытаний

Порядок проведения контроля полноты и отсутствия избыточ-

ности исходных текстов ПО приведен на рис. 4.3.

Идентичность файлов загрузочного кода, собранных из одних

и тех же исходных текстов программ, может быть проконтролиро-

вана абсолютно или фактически. Абсолютная идентичность свиде-

тельствует об их равенстве от первого до последнего бита. Доказа-

тельством абсолютной идентичности двух файлов (исполняемых мо-

Рис. 4.2. Схема проведения сертификационных испытаний

175

Методики сертификационных испытаний

Рис. 4.3. Схема анализа полноты и отсутствия избыточности исходных тек-

стов программ

176

Методики сертификационных испытаний

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

трольных сумм, рассчитанных по сертифицированным или иным до-

веренным алгоритмам. Фактическая идентичность свидетельствует

об идентичности тех секций файлов, которые реализуют функционал

программы, то есть секций кода и данных. Доказательством фактиче-

ской идентичности двух файлов (исполняемых модулей) может быть

абсолютная идентичность их секций кода и данных. Абсолютная

идентичность указанных секций может быть доказана как сравнени-

ем их контрольных сумм, рассчитанных по сертифицированным или

иным доверенным алгоритмам, так и побитовым сравнением. Успеш-

ное выполнение проверки по указанному методу подтверждает целе-

сообразность дальнейших испытаний исходного текста ПО.

Идея данного контроля связей функциональных объектов

по управлению и по информации заключается в построении связей

функциональных объектов (модулей, процедур, функций) и получении

информации о модульной структуре программного средства и о логи-

ческой структуре отдельного программного модуля. Для изображения

модульной структуры используются следующие характеристики:

— граф вызовов;

— список путей вызовов;

— матрица вызовов и достижимости;

— точки вызовов.

Для изображения логической структуры можно использовать ха-

рактеристики управляющих графов и трассы выполнения функцио-

нальных объектов. В целях обеспечения достаточности приведенных

характеристик, модульную структуру дополняют метрикой, позволя-

ющей ранжировать вызовы функций и процедур; к логической струк-

туре добавляют метрику, измеряющую сложность управляющей струк-

туры; а к текстовым характеристикам — метрику уровня реализации.

Критериями оценки наличия НДВ в ПО при использовании контро-

ля связей функциональных объектов по управлению могут являться:

— отсутствие недостижимых и незавершенных маршрутов;

— высокая оценка уровня реализации в вершинах управляюще-

го графа;

— отсутствие соответствия формальных решений с признаками

дефектов.

Таким образом, данный метод дает дополнительную возмож-

ность экспертной оценки структуры исходных текстов ПО.

При контроле информационных объектов различных типов про-

изводится построение списка информационных объектов (локаль-

177

Методики сертификационных испытаний

ных переменных, глобальных переменных, внешних переменных)

с указанием их принадлежности к функциональным объектам. Кон-

троль информационных объектов различных типов считается успеш-

но выполненным, если в результате анализа списка информационных

объектов недекларированных возможностей не выявлено, а постро-

енные списки соответствуют алгоритму работы ПО, приведенного

в документации.

Контроль наличия заданных конструкций в исходных текстах за-

ключается в синтаксическом контроле наличия заданных конструк-

ций в исходных текстах ПО из базы потенциально опасных про-

граммных конструкций (сигнатур) с использованием специальных

средств автоматизации [55]. К указанным конструкциям кода отно-

сят фрагменты, содержащие операции, непосредственно связанные

с изменением атрибутов безопасности, и системные операции, потен-

циально способные повлиять на безопасность системы [6, 13, 30, 31,

32, 54, 62, 100].

База сигнатур для поиска программных закладок и уязвимостей

должна включать конструкции, например, способные привести к пе-

реполнению буфера, реализации «логических бомб», реализации тро-

янских атак, компрометации аутентификационных данных, возмож-

ному превышению полномочий, реализации DOS-атак, нелегитимной

низкоуровневой работе с дисками и файловой системой, реализации

скрытых каналов передачи информации и др. (см. подр. 4.7.2).

При выявлении потенциально опасных конструкций (сигнатур)

в исходных текстах необходимо исследовать факт возможности эксплу-

атации данных конструкций на предмет нарушения доступности, це-

лостности и конфиденциальности в сертифицируемом продукте [59].

На рисунке 4.4 приведена структурная схема метода автоматиза-

ции, позволяющего проводить контроль наличия заданных конструк-

ций в исходных текстах.

При формировании перечня маршрутов ПО должны быть по-

строены маршруты выполнения функциональных объектов, проце-

дур, функций, ветвей. Визуальное представление данных маршрутов

может быть оформлено в виде графов, матриц, списков или таблиц.

Формирование перечня маршрутов позволяет экспертам испытатель-

ной лаборатории проследить реальную последовательность выпол-

нения процедур, функций или ветвей и сравнить с тем, как данная

информация описана в документации на сертифицируемое изделие.

После формирования перечня маршрутов проводится анализ

критических маршрутов выполнения функциональных объектов.

178

Методики сертификационных испытаний

Сведения о

Исходные тексты

Бинарные

компонентах ПО

ПО

модули ПО

Обработчик

входных

параметров

Подготовленные

входные данные

Парсеры языков программирования

Сканер

Семантический

Сигнатурный

(лексический

База потенциально

анализатор

анализатор )

опасных сигнатур

ПО

Синтаксический

Модуль

анализатор

логического

База структур ПО

вывода

Модуль

построения

отчетов

Отчет о

потенциально

опасных

конструкциях

Рис. 4.4. Схема проведения контроля наличия заданных конструкций в ис-

ходных текстах

В качестве критических маршрутов выполнения должны рассма-

триваться маршруты выполнения функциональных объектов, в ко-

торых происходит обработка защищаемой информации. Защища-

емая информация может содержать критически важные сведения

о ПО (пароли, лицензии, работа с базой данных). По результатам

анализа должно быть установлено соответствие порядка выпол-

нения критических маршрутов заявленному алгоритму функцио-

нирования программного продукта, представленного в докумен-

тации. Также к критическим маршрутам должны быть отнесены

те маршруты, в которых выполняются функциональные объекты,

попавшие в список потенциально опасных конструкций.

179

Методики сертификационных испытаний

Анализ алгоритма работы функциональных объектов на основе

блок-схем (диаграмм), построенных по исходным текстам контроли-

руемого ПО, заключается в построении по исходным текстам ядра

контролируемого ПО и модулей, отвечающих за безопасность, блок-

схем с использованием средств автоматизации. В дальнейшем должен

быть проведен сравнительный анализ алгоритма работы функцио-

нальных объектов и алгоритма работы, приведенного в программной

документации на изделие.

Порядок проведения динамического анализа исходных текстов

проиллюстрирован на рис. 4.3.

Методика проведения динамического анализа исходных текстов

программ включает следующие технологические операции:

— контроль выполнения функциональных объектов (процедур,

функций, ветвей);

— сопоставление фактических маршрутов выполнения функцио-

нальных объектов (процедур, функций, ветвей) и маршрутов, постро-

енных в процессе проведения статического анализа.

4.7.2. Рекомендации по контролю наличия

заданных конструкций

Наиболее важным пунктом РД по НДВ можно назвать требова-

ние по контролю наличия заданных конструкций в исходных текстах

программ, так как оно касается непосредственно безопасности ПО.

Конечной целью этой проверки является выявление критических

уязвимостей, особенно преднамеренного характера (программных

закладок). Для 2-го уровня контроля отсутствия НДВ необходимо вы-

полнять синтаксический, а для 1-го уровня — семантический контроль

наличия заданных конструкций в исходных текстах ПО из базы дан-

ных потенциально опасных конструкций (ПОК). Указанные ПОК,

по сути, являются признаками возможного присутствия в ПО дефек-

тов безопасности. Как правило, такими признаками могут быть:

— обращения к запрещенным объектам, например: вызовы уста-

ревших функций, использование нестойких криптографических при-

митивов, обращения к API, не выполняющего определенные требова-

ния безопасности);

— типичные ошибки программистов, проявляющиеся на уровне

синтаксиса программного кода, внутренней структуры программной

системы или внешних связей приложения и позволяющие, в конце

концов, снизить уровень целостности, доступности и конфиденци-

альности информации.

180

Методики сертификационных испытаний

Для выявления дефектов, идентифицируемых как преднамерен-

ные, в базу ПОК добавляют шаблоны, связанные с:

— программным кодом проверки условий активации программ-

ных закладок, например: вызовами функций считывания даты и вре-

мени, созданием счетчиков обращений к ресурсам, обращениям к на-

стройкам системы;

— программным кодом реализации программных закладок, каса-

ющихся разного рода деструктивных функций;

— элементами механизмов безопасности;

— элементами реализации скрытого управления и передачи ин-

формации;

— «необычными» объектами программ;

— «необычными» функциями;

— наличием кода, интенсивно использующего ресурсы системы.

Надо понимать, значительная часть дефектов безопасности спец-

ифична для каждой системы программирования, поэтому необхо-

димо поддерживать базу данных ПОК для всех видов используемых

платформ разработки, причем в актуальном состоянии.

В настоящее время отсутствуют нормативные требования к со-

держимому базы ПОК. Однако в мировой практике существуют ряд

таксономий дефектов и уязвимостей ПО, а именно [58]:

1. CWE — Common Weaknesses Enumeration («Общий реестр недо-

статков» компании MITRE);

2. Fortify Seven Pernicious Kingdoms (7 разрушительных «царств»

компании HP Fortify);

3. OWASP Top Ten (10 самых крупных угроз Open Web

Application Security Project — «Открытого проекта безопасности веб-

приложений»).

Текущая версия классификации CWE 2.1 включает в себя 617 ти-

пов дефектов безопасности ПО, разделенных на 104 категории и ото-

браженных на 22 иерархических вида для разного типа пользовате-

ля (Java-программист, аудитор безопасности, веб-программист и т.п.).

Fortify Seven Pernicious Kingdoms представляет собой классифи-

кацию дефектов ПО, ориентированную на языки программирова-

ния: ABAP, ColdFusion, COBOL, C/C++, C#/VB.NET/ASP.NET, HTML,

Java/JSP, Javascript, PHP, Python, PLSQL/TSQL, Visual Basic/VBScript/

ASP, XML. К каждому из этих языков программирования поставлен

в соответствии специальный раздел, содержащий дефекты из 7 групп

(«царств» в терминологии HP Fortify): валидации ввода и представле-

ния, эксплуатации API, механизмов безопасности, времени и состоя-

181

Методики сертификационных испытаний

ния, обработки ошибок, качества кода, инкапсуляции, а также окру-

жения.

В рамках проекта OWASP разработаны различные артефакты,

документы и программные средства для анализа защищенности. Из

ключевых документов, созданных в рамках проекта OWASP, следует

назвать: AppSec FAQ (ответы на распространенные вопросы по веб-

безопасности), Guide to Building Secure Web Applications (руковод-

ство по главным аспектам безопасности веб-приложений), OWASP

Application Security Verification Standard 2009 (стандарт проверки веб-

приложений), Top Ten Web Application Security Vulnerabilities (десятка

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

Общий процесс поиска наличия заданных конструкций включа-

ет 4 этапа, итеративных между собой:

— выбор новых объектов для исследований;

— запуск средств автоматизация анализа кода;

— рецензирование кода экспертом;

— изучение результатов.

Ключевыми факторами успеха в аудите крупных программных

систем являются разделение программного проекта на подсистемы

и компоненты с определением их интерфейсов и выделение приори-

тетов анализа (расположение кода, тип дефектов и т.п.). Определен-

ным подспорьем здесь могут послужить различные метрики, полу-

ченные из анализа ПО (плотность дефектов, SLOC, число внешних

вызовов и т.п.).

В случае использования средств автоматизации выявления ПОК

условно разделяют синтаксический и семантический контроль задан-

ных конструкций.

В случае синтаксического контроля поиск осуществляется либо

непосредственно в исходных текстах, либо в наборе распознанных

лексем языка программирования. В данном случае сигнатуры могут

представлять собой перечень наборов символов или лексем. Этот под-

ход обеспечивает быстрое и легкое создание сигнатур потенциально

опасных конструкций и их анализаторов, что удобно при поиске не-

корректностей кодирования, но мало эффективно при поиске слож-

ных программных закладок. Семантический анализ является по сути

«надстройкой» над синтаксическим. После того, как были определе-

ны лексемы в исходных текстах программного проекта, на их основе

строится, как правило, абстрактное синтаксическое дерево кода. Ана-

лиз узлов этого дерева позволяет определять высокоуровневые поня-

тия, например: тип используемой переменной, наличие обращения

182

Методики сертификационных испытаний

к базе данных, направление передачи информации между объектами.

В литературе все виды анализа, обрабатывающие результаты синтак-

сического анализа исходных текстов в каком-либо контексте, относят

к семантическому анализу [23].

Чтобы лучше иллюстрировать подход, используемый в семанти-

ческом анализе, приведем таблицу по эвристикам обнаружения неко-

торых ПОК из состава таксономии CWE [71] (табл.4.5):

Таблица 4.5

Примеры эвристик выявления потенциально опасных конструкций

Элемент

CWE верх-

Элемент CWE

Признаки нали-

него уровня

нижнего уровня

чия

Методика обнаружения

Проблемы

Изменение поведе- <совпадение вызова

Определить версию сре-

поведения

ния в новой версии со списком проблем-

ды функционирования;

(Behavioral

окружения

ных для зависимости, сравнить вызов со спи-

Problems)

(Behavioral Change используемой в про-

ском функций, изменив-

(438)

in New Version or

екте>

ших свое поведение для

Environment) (438)

заданной версии среды

Ошибки бизнес-ло- Нет

Требуется построение

гики

бизнес-модели кода и её

(Business Logic

сравнение с бизнес-про-

Errors)

цессом (плохо поддается

(840)

автоматизации, требуется

рецензирование кода экс-

пертом)

Нарушение ожида- Нет

Требуется построение

емого поведения

бизнес-модели кода и её

(Expected Behavior

сравнение с бизнес-про-

Violation)

цессом (плохо поддается

(440)

автоматизации, требуется

рецензирование кода экс-

пертом)

Неверный кон-

<нет таймаута или Определить интерактив-

троль частоты

запрета попыток

ность функционального

взаимодействия

в интерактивной

объекта (по наличию API

(Improper Control функции> (взаи-

заданного типа);

of Interaction

модействующей

определить внутри инте-

Frequency)

с пользователем

рактивного объекта на-

(799)

или внешней сто-

личие API по обработке

роной)

задержки

Ошибки ка-

Недостаточная

<отсутствие провер- Определить вызов функ-

налов и пу-

защита выбранно-

ки при показе закры-

ционала отображающего

тей (Channel го пути (Improper той страницы>

содержимое страницы,

and path

Protection of

удостовериться в наличии

errors)

Alternate Path)

функционала контроля

(417)

(424)

сессии доступа пользова-

теля

183

Методики сертификационных испытаний

Продолжение табл. 4.5

Элемент

CWE верх-

Элемент CWE

Признаки нали-

него уровня

нижнего уровня

чия

Методика обнаружения

Ошибки ка-

Скрытый канал

<обращение к нестан- Поиск вызовов функцио-

налов и пу-

памяти (Covert

дартным информаци- нала из списка объектов

тей (Channel storage channel)

онным объектам>

потенциально скрытых

and path

(515)

(файл подкачки,

каналов

errors)

реестр, прямой до-

(417)

ступ к диску, опера-

ции с «кучей»)

Скрытый канал

<обращение к нестан- Поиск вызовов функцио-

времени (Covert

дартным информаци- нала из списка объектов

timing channel)

онным объектам>

потенциально скрытых

(385)

(бесконечные ци-

каналов

клы, работа с оче-

редью сообщений,

таймером, высоко-

производительным

таймером)

Обработка

Обработка данных <поиск включения

Поиск вызовов получе-

данных

(Data Handling)

введенных пользовате- ния пользовательских

(Data

(19)

лем данных при фор-

данных; поиск вызовов

Handling)

мировании строк>

потенциально опасных

(19)

функций с использова-

нием пользовательских

данных

Обработка

Обработка ошибок <наличие в блоке catch Поиск обработчиков ис-

ошибок

(Error Handling)

операции вывода

ключений и определение

(Error

(388)

в журнал>

внутри них вызовов выво-

Handling)

да в журнал

(388)

Ошибки об-

Ошибки обработ-

<выброс исключения, Создание списка всех

работчика

чика (Handler

у которого нет обра-

выбросов исключений;

(Handler

Errors)

ботчика>

создание списка всех об-

Errors)

(429)

работчиков; сравнение

(429)

двух списков

Злоупотре-

Злоупотребление

<использование внеш- Составление списка всех

бление API

API (API Abuse)

них компонент (би-

внешних зависимостей

(API Abuse)

(227)

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

(227)

ными версиями>

циально опасных вызовов

из этих библиотек

Индикатор

Присваивание

<наличие «=» вместо Проверка заданного спи-

плохого ка-

вместо (Assigning

«==» в блоке if, где

ска регулярных выраже-

чества кода

instead of

сравниваются лишь

ний для содержимого за-

(Indicator of Comparing)

переменные>

данных типов блоков

Poor Code

(481)

Quality)

(398)

184

Методики сертификационных испытаний

Продолжение табл. 4.5

Элемент

CWE верх-

Элемент CWE

Признаки нали-

него уровня

нижнего уровня

чия

Методика обнаружения

Ошибки

Неверная инициа- <отсутствие иници-

Поиск объявлений объ-

очистки

лизация (Improper ализации значений

ектов, которые требуют

и иници-

Initialization)

объектов перед их ис-

инициализации перед

ализации

(665)

пользованием>

своим использованием;

(Initiali-

поиск первого использо-

zation and

вания объекта в вызовах

Cleanup

и операциях; при отсут-

Errors)

ствии их инициализации

(452)

(левая часть в присваива-

нии, функции, использу-

ющие их в виде выходных

значений)

Недоста-

Остаточный от-

<наличие отладочно- Поиск присутствия вы-

точная ин-

ладочный код

го кода>

зовов функций из списка

капсуляция (Leftover Debug

отладочных, наличия

(Insuffi cient Code)

подозрительных правил

Encapsu-

(489)

в названиях отладочных

lation)

функций, ключевых слов

(485)

по debug, в т.ч. в коммен-

тариях

Проблемы

Разыменование

<вызов операций

Проверка вызовов функ-

указателей

нулевых указате-

по освобождению па-

ций, возвращающих ука-

(Pointer

лей (NULL Pointer мяти для указате-

затель (на которую может

Issues)

Dereference)

лей, которые равны

повлиять пользователь),

(465)

(476)

NULL>

и факта проверки значе-

ния следом за этим

Механизмы Использование

<наличие паролей

Проверка вызовов функ-

безопасно-

жестко пропи-

и других данных ав-

ций с параметрами авто-

сти (Security санных паролей

торизации непосред-

ризации, использующих

Features)

(Use of hard-coded ственно в коде прило- аргументы со строковы-

(254)

password)

жения>

ми константами; поиск

(259)

функций, требующих ав-

торизации вместе с пере-

менными, которым были

присвоены строковые

константы

Время и со-

Внешнее влияние

<проверка наличия

Поиск вызовов функций,

стояние

на сферу опреде-

функций, использую-

читающих содержимое

(Time and

ления (External

щих значения пере-

переменных окружения>

State)

Influence of Sphere менных окружения>

(361)

Definition) (673)

Ошибки

Нереализованная <наличие скрытых

Поиск наличия

интерфейса или неподдержи-

элементов GUI,

disabled=true hidden=true

пользова-

ваемая функция

а также некоррект-

и других подобных

теля (User

в интерфейсе

ностей в обработчи-

свойств в файле GUI,

Interface

пользователя

ках событий>

контроль отсутствия кода

Errors)

(Unimplemented

в функции-обработчике

(445)

of unsupported

(Qt, Builder)

feature in UI) (447)

185

ЛИТЕРАТУРА

1. Аграновский А.В., Мамай В. И., Назаров И. Г., Язов Ю. К. Основы технологии про-

ектирования систем защиты информации в информационно-телекоммуникацион-

ных системах. Ростов н/Д: Изд-во СКНЦ ВШ, 2006. 258 с.

2. Адамова Л.Е., Амарян М. Р., Варламов О. О., Лысаковский В. А. Об одном подходе

к созданию ревизоров обеспечения безопасности информации на отдельных ком-

пьютерах // Известия Таганрогского государственного радиотехнического уни-

верситета. 2003. № 4 (33). С. 175—176.

3. Александрович А.Е., Бородакий Ю. В., Чуканов В. О. Проектирование высоконад-

ёжных информационно-вычислительных систем. М.: Радио и связь, 2004. 144 с.

4. Баландин А.В., Ващенко А. П., Войнов Ю. В., Мукминов В. А. Об архитектуре

средств тестирования автоматизированных систем в условиях моделирования

информационных воздействий // Известия Института инженерной физики. 2011.

№ 1 (19). С. 36—39.

5. Барабанов А.В., Гришин М. И., Марков А. С. Формальный базис и метабазис оцен-

ки соответствия средств защиты информации объектов информатизации. // Изве-

стия института инженерной физики. 2011. № 3. С. 82—88.

6. Барабанов А.В., Марков А. С., Фадин А. А. Сертификация программ без исход-

ных текстов // Открытые системы. СУБД. 2011. № 4. С.38—41.

7. Барабанов А.В., Марков А. С., Цирлов В. Л. Методический аппарат оценки со-

ответствия автоматизированных систем требованиям безопасности информа-

ции // Спецтехника и связь. 2011. № 3. С.48—53.

8. Барабанов А.В., Марков А. С., Цирлов В. Л. Разработка методики испытаний меж-

сетевых экранов по требованиям безопасности информации. // Вопросы защиты

информации. 2011. № 3. С.19—24.

9. Барабанов А.В., Марков А. С., Цирлов В. Л. Сертификация систем обнаружения

вторжений // Открытые системы. СУБД. 2012. № 3. С.31—33.

10. Баранов А.П., Зегжда Д. П., Зегжда П. Д., Ивашко А. М., Корт С. С., Кузьмич В. М., Медведовский И. Д., Семьянов П. В. Теория и практика обеспечения информационной

безопасности. М.:: Яхтсмен, 1996. 300 с.

11. Барсуков B.C., Дворянкин С. В., Шеремет И. А. Безопасность связи в каналах теле-

коммуникаций. // Технологии электронных коммуникаций. 1992. Том 20. 122 с.

12. Бахтизин В.В., Глухова Л. А. Стандартизация и сертификация программного

обеспечения. Мн.: БГУИР, 2006. 200 с.

13. Беляков И.А., Еремеев М. А. Подход к построению подсистемы принятия реше-

ния о наличии/отсутствии недекларированных возможностей в сертифицируемом

Литература

программном обеспечении на основе данных статического анализа // Проблемы

информационной безопасности. Компьютерные системы. 2008. № 4. С. 66—72.

14. Благодаренко А.В., Лисова Ю. В., Тумоян Е. П. Исследование безопасности гете-

рогенных корпоративных сетей на основе методологии OSSTMM // Информаци-

онное противодействие угрозам терроризма. 2010. № 14. С. 132—135.

15. Бородакий Ю.В., Добродеев А. Ю., Пальчун Б. П., Лоскутов А. А. Страхование и обе-

спечение информационной безопасности // Информационное противодействие

угрозам терроризма. 2006. № 6. С. 59—64.

16. Бородакий Ю.В., Жуков И. Ю., Зубарев И. В., Костогрызов А. И., Родионов В. Н. и др.

Методическое руководство по оценке качества функционирования информаци-

онных систем. М.: Изд-во 3 ЦНИИ МО РФ, 2003. 352 с.

17. Бородакий Ю.В., Тарасов А. А. О функциональной устойчивости информаци-

онно-вычислительных систем // Известия Южного федерального университета.

Технические науки. 2006. № 7 (62). С. 5—12.

18. Вареница В. В. Проблемы вычисления метрик сложности программного обе-

спечения при проведении аудита безопасности кода методом ручного рецензирова-

ния // Вестник МГТУ им.Н.Э.Баумана. Сер. «Приборостроение». 2011. Спецвыпуск

«Технические средства и системы защиты информации». С.79—84.

19. Васильева М.А., Марков А. С. Утилиты скрытого наблюдения: классификация,

методы работы и выявление // РКТ: Фундаментальные и прикладные проблемы.

Секция 7. Информационные технологии и безопасность в ракетно-космических

системах. Изд-во МГТУ им.Н.Э.Баумана. 2005. С.100—101.

20. Ващенко А.П., Кондаков С. Е., Хабибуллин И. В., Фадин А. А. Мобильное место ад-

министратора информационной безопасности // Безопасные информационные

технологии. Сборник трудов I НТК. М.: МГТУ им.Н.Э.Баумана. 2010. С.28—35.

21. Волканов Д.Ю., Зорин Д. А. Исследование применимости моделей оценки на-

дёжности для разработки программного обеспечения с открытым исходным ко-

дом // Прикладная информатика. 2011. № 2. С.26—32.

22. Герасименко В. А. Защита информации в автоматизированных системах обра-

ботки данных. // В 2-х кн. М.: Энергоатомиздат, 1994. 175 c.; 400 с.

23. Глухих М.И., Ицыксон В. М. Программная инженерия. Обеспечение качества

программных средств методами статического анализа. СПб.: Изд-во Политехн. ун-

та, 2011. 150 с.

24. Гончаров И.В., Костина Л. В., Платонов М. С. Построение обобщенной матема-

тической модели типового объекта информатизации на основе использования

мультиномиального распределения // Информация и безопасность. 2010. № 4 (13).

С. 611—614.

25. Горшков Ю.Г., Бельфер Р. А. Анализ риска информационной безопасности сетей

при выполнении функций защиты приватности // Электросвязь. 2012. № 3. С.26—28.

26. Грибков В.В., Федорец О. Н. Модели и методы разработки безопасного про-

граммного обеспечения. М.: Изд-во 3 ЦНИИ МО РФ, 2009. 188 с.

27. Гудков О.В., Марков А. С. Методика анализа безопасности межсетевого экра-

на // РКТ: фундаментальные и прикладные проблемы. Секция 7. Информацион-

ные технологии и безопасность в ракетно-космических системах. Изд-во МГТУ

им.Н.Э.Баумана. 2005. С. 67—69.

28. Дидюк Ю.Е., Лютиков В. С., Макаров О. Ю., Рогозин Е.А. К вопросу оценки уязви-

мости информации в целях задания требований к средствам защиты информации

в автоматизированных системах // Телекоммуникации. 2003. № 4. С. 42—44.

187

Литература

29. Дорофеев А. В. Тестирование на проникновение: демонстрация одной уязвимо-

сти или объективная оценка защищенности? // Защита информации. Инсайд. 2010.

№ 6. С.72—74.

30. Егоров М.А., Марков А. С. Анализ безопасности исходного кода ПО с исполь-

зованием упорядоченных бинарных диаграмм решений // Безопасные информа-

ционные технологии. Сборник трудов II НТК. М.: МГТУ им.Н.Э.Баумана. 2011. С.

33—36.

31. Жидков И.В., Львов В. М. Повышение гарантии выявления программных за-

кладок в программном обеспечении автоматизированных систем военного назна-

чения // Известия Таганрогского государственного радиотехнического универси-

тета. 2003. № 4 (33). С. 53—57.

32. Жилкин С. Д. Использование моделей поведения для выявления НДВ // Из-

вестия Института инженерной физики. 2011. № 1 (19). С. 2—7.

33. Зима В.М., Котухов М. М., Ломако А. Г., Марков А. С., Молдовян А. А. Разработка си-

стем информационно-компьютерной безопасности. СПб: ВАК им. А. Ф. Можайско-

го, 2003. 327 с.

34. Зубарев И. В. Сертификация как направление повышения безопасности ин-

формационных систем и программного обеспечения. // Известия Таганрогского

государственного радиотехнического университета, 2003. № 4 (33). С. 48—53.

35. Кадушкин И. В. Предложения по совершенствованию методического аппа-

рата проведения испытаний средств защиты информации автоматизированных

систем. // Информационное противодействие угрозам терроризма. 2008. № 11.

С.195—203.

36. Карповский Е.Я., Чижов С. А. Надежность программной продукции. Киев: Тэх-

ника, 1990. 159 с.

37. Керножицкий В.А., Марков А. С. Ускоренный метод оценки параметров техни-

ческих систем по малым статистическим выборкам // Вопросы повышения каче-

ства управления движущимися объектами. СПб: БГТУ им. Д. Ф. Устинова, 1995. C.

71—78.

38. Климов С.М., Михайлов Р. А., Пальчун Б. П. Техническое регулирование в обла-

сти обеспечения информационной безопасности // Известия Южного федераль-

ного университета. Технические науки. 2003. № 4 (33). С. 40—44.

39. Клянчин А. И. Семантический анализ исходного кода для построения модели

прикладной области на практике. // Вестник МГТУ им.Н.Э.Баумана. Сер. «Прибо-

ростроение». 2011. Спецвыпуск «Технические средства и системы защиты инфор-

мации». С.85—89.

40. Ковалев В.В., Компаниец Р. И., Маньков Е. В. Экспертиза и защита кода про-

грамм на основе автоматов динамического контроля // Защита информации. Ин-

сайд. 2007. № 3. С. 48—55.

41. Колесников Д.В., Петров А. Ю., Храмов В. Ю. Методика оценки защищенности

специального программного обеспечения при проведении испытаний автомати-

зированных систем // Вестник Воронежского государственного университета. Се-

рия: Системный анализ и информационные технологии. 2010. № 1. С.74—79.

42. Колозезный Э.А., Бужинский В. А., Динеев В. Г., Ковригин М. И., Колозезный А. Э., Мо-

жаров Г. П. Независимая экспертиза — основа сертификации программно-матема-

тического обеспечения изделий ракетно-космической техники // Космонавтика

и ракетостроение. 2001. Вып. 24. С. 154—162.

188

Литература

43. Королев В. Ю. Прикладные задачи теории вероятностей: модели роста надеж-

ности модифицируемых систем. М.: Диалог-МГУ, 1997. 68 с.

44. Костогрызов А.И., Липаев В. В. Сертификация функционирования автомати-

зированных информационных систем. М.: Изд. «Вооружение. Политика. Конвер-

сия», 1996. 280 с.

45. Котенко И.В., Котухов М. М., Марков А. С. и др. Законодательно-правовое и ор-

ганизационно-техническое обеспечение информационной безопасности автома-

тизированных систем и информационно-вычислительных сетей. СПб.: ВУС, 2000.

190 с.

46. Котухов М.М., Кубанков А. Н., Калашников А. О. Информационная безопасность:

Учебное пособие. М.: Академия ИБС–МФТИ, 2009. 195 с.

47. Марков А. С. Анализ атак на сети Novell Netware, основанный на таксономии

угроз информационной безопасности // Известия вузов. Приборостроение. 2000.

Т.43. № 4. С.30—34.

48. Марков А. С. Исследование дефектов операционной системы Windows // Из-

вестия вузов. Приборостроение. 2000. Т.43. № 6. С.46—50.

49. Марков А. С. Модели оценки и планирования испытаний программ-

ных средств по требованиям безопасности информации. Вестник МГТУ

им.Н.Э.Баумана. Сер. «Приборостроение». 2011. Спецвыпуск «Технические сред-

ства и системы защиты информации». С.90—103.

50. Марков А. С. Нечеткая модель оценки надежности и безопасности функци-

онирования программного обеспечения по результатам испытаний. // Вестник

МГТУ им.Н.Э.Баумана. Сер. «Приборостроение». 2011. Спецвыпуск «Технические

средства и системы защиты информации». С.146—151.

51. Марков А. С. Оценка динамической сложности программного обеспечения

на ПЭВМ // Методы и средства совершенствования сложных управляющих систем

и комплексов: Учебное пособие. СПб: Мех. ин-т им. Д. Ф. Устинова (Военмех), 1992.

С. 35—47.

52. Марков А. С. Парадигма ограниченного стохастического контроля // Изве-

стия института инженерной физики. 2012. № 1 (23). C. 15—19.

53. Марков А.С., Годердзишвили Г. М. Модель оценки степени отлаженности про-

граммного обеспечения по результатам испытаний // Методы и средства управле-

ния и контроля. Л.: МО СССР, 1987. С. 51—52.

54. Марков А.С., Миронов С. В., Цирлов В. Л. Выявление уязвимостей в программном

коде // Открытые системы. СУБД. 2005. № 12. С.64—69.

55. Марков А.С., Миронов С. В., Цирлов В. Л. Выявление уязвимостей программного

обеспечения в процессе сертификации // Известия Таганрогского государствен-

ного радиотехнического университета. 2006. № 7 (62). С. 82—87.

56. Марков А.С., Миронов С. В., Цирлов В. Л. Опыт тестирования сетевых сканеров

уязвимостей // Информационное противодействие угрозам терроризма. 2005. № 5.

С.109—122.

57. Марков А.С., Никулин М. Ю., Цирлов В. Л. Сертификация средств защиты персо-

нальных данных: революция или эволюция? // Защита информации. Инсайд. 2008.

№ 5. С.20—25.

58. Марков А.С., Фадин А. А., Цирлов В. Л. Систематика дефектов и уязвимостей про-

граммного обеспечения // Безопасные информационные технологии. Сборник

трудов II НТК. М.: МГТУ им.Н.Э.Баумана. 2011. С. 83—87.

189

Литература

59. Марков А.С., Цирлов В. Л. Аудит программного кода по требованиям безопас-

ности. Часть 2. // Information Security. 2008. № 3. С.46—47.

60. Марков А.С., Цирлов В. Л. Сертификация программ: мифы и реальность // От-

крытые системы. СУБД. 2011. № 6. С.26—29.

61. Марков А.С., Цирлов В. Л. Управление рисками — нормативный вакуум инфор-

мационной безопасности // Открытые системы. СУБД. 2007. № 8. С. 63—67.

62. Марков А.С., Щербина С. А. Испытания и контроль программных ресур-

сов // Information Security. 2003. № 6. С.26.

63. Матвеев В.А., Медведев Н. В., Троицкий И. И., Цирлов В. Л. Состояние и перспек-

тивы развития индустрии информационной безопасности Российской Федерации

в 2011 г. // Вестник МГТУ им.Н.Э.Баумана. Сер. «Приборостроение». 2011. Спецвы-

пуск «Технические средства и системы защиты информации». С.—6.

64. Математические модели и алгоритмы процессов эксплуатации сложных си-

стем / Под общ. ред. В. А. Чобаняна и В.В.Линника. М.: ВА РВСН им. Петра Велико-

го, 2005. 168 с.

65. Машкина И.В., Рахимов Е. А. Модель объекта информатизации // Информаци-

онное противодействие угрозам терроризма. 2006. № 6. С. 82—87.

66. Минаков В.А., Мирошников В. В., Ламинский Е. Ю. Применение аппарата сетей

Петри при контроле программного обеспечения на отсутствие недекларирован-

ных возможностей // Телекоммуникации. 2009, № 10. С.38—41.

67. Минзов А.С., Кольер С. М. Обоснование управленческих решений в сфере обе-

спечения информационной безопасности // Системный анализ в науке и образова-

нии. 2010. № 1. С. 48—53.

68. Николаенко Ю.Н., Шубинский И. Б. Развитие технологии сертификационных

испытаний программного обеспечения по требованиям безопасности информа-

ции // Надежность. 2010. № 1. С. 66—79.

69. Нормативные и методические документы по технической защите информа-

ции. Специальные нормативные документы: официальный сайт ФСТЭК России.—

URL: http://www.fstec.ru/_razd/_karto.htm. Дата обращения: 01.09.2012.

70. Пальчун Б.П., Юсупов P. M. Оценка надежности программного обеспечения.

СПб.: Наука, 1994. 84 с.

71. Патент 114799 Российская Федерация. Система для определения программ-

ных закладок. / В. В. Вылегжанин, А. Л. Маркин, А. С. Марков, Р. А. Уточка, А. А. Фа-

дин, А. К. Фамбулов, В. Л. Цирлов — № 2011153967/08 (081180); заявл. 29.12.11; опубл.

10.04.12, Бюл. № 10. 2 с.

72. Половко А.М., Гуров С. В. Основы теории надежности. СПб.: БХВ-Петербург,

2006. 702 с.

73. Рыжиков Ю. И. Эффективность и эксплуатация программного обеспечения

ЭЦВМ. Л.: МО СССР, 1985. 263 с.

74. Рыжков Е.А., Карпов А. Н. Подходы к верификации и тестированию 64-битных

приложений // Информационные технологии. 2008. № 7. С.41—45.

75. Сводный отчёт по безопасности программного обеспечения в России

и мире. М.: НПО «Эшелон», 2012. Вып.2.— URL: http://cnpo.ru/report_echelon_2012.

pdf. Дата обращения: 01.09.2012.

76. Смагин В. А. Основы теории надежности программного обеспечения. СПб.:

ВКА им.А.Ф.Можайского, 2009. 336 с.

77. Солодовников В.В., Тумаркин В. И. Теория сложности и проектирование систем

управления. М.: Наука, 1990. 168 с.

190

Литература

78. Тейер Т., Липов М., Нельсон Э. Надежность программного обеспечения. М.:

Мир, 1981. 325 c.

79. Темнов О. Д. Анализ и исследование методов и средств обнаружения недекла-

рированных возможностей // Научно-технический вестник Санкт-Петербургского

государственного университета информационных технологий, механики и опти-

ки. 2007. № 39. С. 45—50.

80. Трубачев А.П., Долинин М. Ю., Кобзарь М. Т., Сидак А. А., Сороковников В. И. Оценка

безопасности информационных технологий / Под ред. В. А. Галатенко, Предисло-

вие С. И. Григорова, М.СИП РИА, 2001. 356 с.

81. Ухлинов Л.М., Сычев М. П., Скиба В. Ю., Казарин О. В. Обеспечение безопасности

информации в центрах управления полетами космических аппаратов. М.: МГТУ

им.Н.Э.Баумана, 2000. 366 с.

82. Холдстед М. Начала науки о программах. М.: Финансы и статистика, 1981. 128 c.

83. Хорев А. А. Аттестация объектов информатизации и выделенных помеще-

ний // Специальная техника. 2006. № 4. С. 49—61.

84. Цирлов В. Л. Основы информационной безопасности. Краткий курс. Ростов

н/Д, Изд-во: Феникс, 2008. 254 с.

85. Черкесов Г. Н. Надежность аппаратно-программных комплексов. СПб.: Питер,

2005. 479 с.

86. Шаракшанэ А.С., Халецкий А. К., Морозов И. А. Оценка характеристик сложных

автоматизированных систем. М.: Машиностроение, 1993. 271с.

87. Шахалов И. Ю. Лицензия как продукт осознанной необходимости. // Защита

информации. Инсайд. 2010. № 2. С.53—55.

88. Штрик А.А., Осовецкий Л. Г., Мессих И. Г. Структурное проектирование надеж-

ных программ встроенных ЭВМ. Л.: Машиностроение, 1989. 296 с.

89. Alguliev R.M., Imamverdiev Y. N. About one method of risk measurement of maintenance of information security of corporative networks because of fuzzy sets. // Proc.

of the 4th International Conference on New Information (Technologies»2000). Minsk.

2000. V.1. P. 76—81.

90. Bubnov V., Tyrva A., Khomonenko A. Model of reliability of the software with Coxian distribution of length of intervals between the moments of detection of errors // Proceedings of 34th Annual IEEE Computer Software and Applications Conference COMP-

SAC-2010. 2010. P. 238—243.

91. Gatsenko O. Yu. Method for the design of information protection systems // Automatic Control and Computer Sciences. 2000. Т. 34. № 5. P. 1—8.

92. Grusho A., Knyazev A., Timonina E. Strictly consistent tests for detection of statistical covert channels // Journal of Mathematical Sciences. 2007. Т. 146. № 4. P. 5984—5991.

93. Kostogryzov A., Nistratov G., Kleshchev N. Mathematical Models and Software Tools to Support an Assessment of Standard System Processes. // Proceedings of the 6th International SPICE Conference on Process Assessment and Improvement (SPICE-2006).

Luxembourg. 2006. P. 63—68.

94. Kotenko I., Stepashkin M. Analyzing Vulnerabilities and Measuring Security Level at Design and Exploitation Stages of Computer Network Life Cycle.// Lecture Notes in

Computer Science. 2005. V.3685. P. 317—330.

95. Lipaev V. V. Problems of the development and quality control of large software systems // Programming and computer software. 2005. V. 31. № 1. P. 47—49.

191

Литература

96. Lovtsov D. A. Data Protection Methods for Automatic Controls for Complicated

Dynamic Systems // Automatic Documentation and Mathematical Linguistics. 2000. Vol.

34. № 3. P. 18—37.

97. Markov A.S., Kernozitsky V. A. Economically effective data bases diagnostics method // Advances in Modeling and Analysis (AMSE Press). 1995. B: Signals,

Information, Data, Patterns. Vol.33. № 3. P. 5—11.

98. Pozin B., Giniyatullin R., Galakhov I., Vostrikov D. Model-based Technology of Automated Performance Testing // SYRCoSE. 2009. P. 93.

99. Utkin L.V., Zatenko S. I., Coolen F. P.A. New interval Bayesian models for software reliability based on non-homogeneous Poisson processes //Automation and Remote

Control. 2010. V. 71. № 5. P. 935—944.

100.

Zegzhda P.D., Zegzhda D. P., Kalinin M. O. Vulnerabilities detection in the configurations of MS Windows operating system // Lecture Notes in Computer Science.

2005. V. 3685 LNCS. P. 339—351.

А.С. Марков, В.Л. Цирлов, А.В. Барабанов

Методы оценки несоответствия

средств защиты информации

Издательство «Радио и связь»

www.radiosv.ru

Подписано в печать 24.06.2012. Формат 60×90/16. Бумага офсет. Печ. л. 12.

Тираж 1000 экз. Заказ №______

Отпечатано в

192

Всего проголосовало: 1

Средний рейтинг 5.0 из 5