Содержание к диссертации
Введение
Глава 1. Обзор литературы и анализ рассматриваемой проблемы 10
1.1. Введение в проблему, основные понятия 10
1.2. Базовые принципы обеспечения информационной безопасности 13
1.3. Существующие математические модели проектирования инфраструктуры обеспечения ИБ 15
1.3.1. Эмпирический подход к оценке ожидаемых потерь от угроз безопасности информации 16
1.3.2. Стоимостная модель «защитник-нарушитель» 17
1.3.3. Модель системы безопасности с полным перекрытием 19
1.3.4. Вероятностная модель для анализа защищенности взаимосвязанных информационных объектов 22
1.4. Стандарты в области информационной безопасности 27
1.4.1. Руководящие документы Гостехкомиссии России 29
1.4.2. Общие критерии безопасности информационных технологий 33
1.5. Анализ рисков 37
1.6. Выводы 38
Глава 2. Разработка математических моделей синтеза инфраструктуры обеспечения информационной безопасности 42
2.1. Формирование множества проектов 42
2.1.1. Теоретико-множественная модель, описывающая АС, требования в сфере безопасности, средства и механизмы защиты 44
2.1.2. Построение множества проектов инфраструктуры обеспечения информационной безопасности АС 50
2.2. Выбор оптимального проекта на основе анализа одношаговых конечных игровых моделей конфликта «защитник - нарушитель» 57
2.2.1. Обоснование применимости игрового подхода и задание игры 57
2.2.2. Выбор оптимальной стратегии 61
2.2.3. Анализ результатов решения игры в смешанных стратегиях 64
2.2.4. Особенности биматричных моделей 68
2.2.5. Использование интервальных оценок потерь от реализации угроз информационной безопасности 69
2.3 Выводы. 73
Глава 3. Разработка системы поддержки принятия решений в области проектирования инфраструктуры обеспечения информационной безопасности 74
3.1. Выбор средств разработки 74
3.2. Разработка базы данных 78
3.2.1. Адаптация теоретико-множественной модели для соответствия требованиям реляционной модели баз данных 78
3.2.2. Структура базы данных 79
3.3. Структура программы 88
3.3.1. Взаимодействие с внешними данными через класс-источник данных 89
3.3.2. Упорядочение стратегий, решение игры в чистых стратегиях 94
3.3.3 Использование симплекс-метода для решения игры в смешанных стратегиях 95
Глава 4. Тестирование программы и сравнение с коммерческими продуктами для анализа рисков 104
4.1. Тестирование программы 104
4.1.1. Тестирование кпасса ЫзОате 104
4.1.2. Тестовый пример для программы в целом 107
4.2. Сравнение разработанного прототипа с коммерческими системами анализа риско 112
Заключение 117
Литература 119
Приложение 1. ЗОЬвыражения для создания базы данных 126
Приложение 2. Акты об использовании результатов работы 132
- Существующие математические модели проектирования инфраструктуры обеспечения ИБ
- Теоретико-множественная модель, описывающая АС, требования в сфере безопасности, средства и механизмы защиты
- Адаптация теоретико-множественной модели для соответствия требованиям реляционной модели баз данных
- Сравнение разработанного прототипа с коммерческими системами анализа риско
Существующие математические модели проектирования инфраструктуры обеспечения ИБ
Необходимость гибкости системы защиты вызвана тем, что структура защищаемой АС, требования к ней, а также внешние условия могут со временем меняться. Следовательно, включаемые в систему средства защиты должны быть по возможности перенастраиваемы, чтобы администраторы могли частично или полностью адаптировать систему защиты к новым условиям, а не менять ее в обязательном порядке.
Открытость алгоритмов и механизмов защиты подразумевает, что стойкость защиты не должна обеспечиваться лишь за счет секретности структурной организации и алгоритмов функционирования ее подсистем. Знание алгоритмов работы систем защиты не должно давать возможности их преодоления. В то же время, это не означает, что информация о конкретной системе должна быть общедоступна.
По сути, этот принцип является расширением на все множество способов защиты известного из криптографии правила Керкхоффа [53], по которому стойкость шифра должна быть обеспечена даже в том случае, когда криптоаналитику противника известен весь механизм шифрования за исключением секретного ключа.
Принцип простоты применения средств защиты определяет, что применение средств защиты не должно быть связано для пользователей со знанием специальных языков или выполнением действий, требующих значительных дополнительных трудозатрат.
На этих принципах и будет строиться описываемый в работе набор методов проектирования подсистемы защиты АС.
Существующие математические модели проектирования инфраструктуры обеспечения ИБ
Процесс построения инфраструктуры обеспечения ИБ АС можно разделить на два этапа:
1) Определение на качественном уровне структуры подсистемы защиты АС, т.е. определение того, в отношении каких элементов системы, какие требования должны выполняться и какими средствами этого достичь.
2) Определение оптимальных количественных характеристик подсистемы защиты, в частности, ее стоимостных показателей. в процессе разработки, в зависимости от особенностей системы и применяемого подхода к обеспечению ИБ, могут решаться как обе эти задачи, так и одна из них.
Задача 2) часто решается в рамках исследования так называемых стоимостных моделей. Рассмотренные ниже модели данного класса основываются на следующем положении: с ростом затрат на защиту информации, ущерб от атак снижается. Соответственно, должна быть такая точка, где сумма затрат и потерь от атаки будет минимальна, ее и надо найти. Рис. 1.1 иллюстрирует данную идею [12,83].
Проблема заключается в том, чтобы определить подобные зависимости для реальных систем.
Одна из первых моделей, позволяющих оценить потенциальные потери от угроз информационной безопасности, была предложена специалистами фирмы IBM. Эмпирическим путем была определена следующая зависимость ожидаемых потерь от i-й угрозы ИБ [12]: где 8 - коэффициент, характеризующий возможную частоту возникновения соответствующей угрозы; У; - коэффициент, характеризующий значение возможного ущерба. Значения данных коэффициентов приведены в табл. 1.1,
Суммарная стоимость потерь в этом случае определяется формулой:
К сожалению, в данном виде модель не имеет достаточного формального обоснования. Кроме того, для этого требуется наличие большого количества достоверных статистических данных о действиях различных атак на различные АС.
Теоретико-множественная модель, описывающая АС, требования в сфере безопасности, средства и механизмы защиты
Как было отмечено ранее, вся АС разделена на зоны безопасности. Множество всех зон обозначим через 2, мощность 2 1.
Обозначим множество требований к функциональности подсистемы защиты через Р. Для V пеР (1=1..п, где п = Р) существует множество значений Vi={Vj}. На каждом множестве \/-, определено отношение порядка " ". Запись \/ \ у", означает, что требование г,v" является не менее строгим, чем П,у , где пеР; v ,v"iV. Тогда решение, удовлетворяющее требованию П,у" , будет удовлетворять и г,v i , а обратное, в общем случае, неверно. Будем считать, что все множества \/, (/=1..п) являются линейно упорядоченными, т.е. \/\/ \У\е У, сравнимы между собой (или \/ \ у"и или v" v ), а (у , у" и v"i v ) = = v .
Набор требований - множество, с элементами вида требование, значение . Набор может формироваться, например, на основе Профиля защиты «Общих критериев» (см. п.1.4.2). Обозначим множество наборов требований через Р:
Пусть р ,р"еР; р ={ Г1,7 1 ,..., Гт,У т }, P"={ r1,V"1 ,..., Гm,v"m }, р =р", Т.О. оба набора базируются на одном и том же сочетании требований и отличаются только значениями. Тогда будем считать, что р р", если и только если v k v"k для всех к=1..т. Множество Р является частично упорядоченным, т.к. в нем могут быть несравнимые между собой элементы. Пусть для каждой зоне тААТ. сопоставлено подмножество допустимых наборов требований РсР, р\ф 2). Проект подсистемы защиты должен в каждой зоне 21е2 обеспечить выполнение набора требований
Кроме того, каждой зоне 2:,&2. должно быть сопоставлено подмножество требований безопасности Р еК, которые должны быть выполнены в отношении данной зоны, как единого целого (а не в отношении отдельных элементов АС, относящихся к данной зоне). Примером такого рода требований могут быть требования по физической защите помещений.
Задание на разработку системы предлагается описать следующим образом:
Структура задания на разработку представлена на рис.2.1, пунктиром обведены те элементы задания, которые включаются в конкретный проект подсистемы защиты АС.
Перейдем к описанию элементов АС. В качестве элемента будет рассматриваться универсальный компьютер, который описывается:
- названием (для группы однотипных элементов, принадлежащих одной зоне, это название группы);
- указанием на аппаратную платформу;
- указанием на операционную систему;
- указанием на используемое ПО (для проекта подсистемы защиты, интерес представляет в первую очередь ПО, обладающее встроенными механизмами защиты);
- дополнительными параметрами, используемыми при задании ограничений для проектов.
Описание прочих элементов АС (например, специализированных ЭВМ или различных сетевых устройств - маршрутизаторов, шлюзов и т.д.) строится аналогично. Разница может заключаться в том, что какие-то атрибуты будут принимать значение «не определено», а дополнительные сведения можно описать путем введения новых параметров. Задание на разработку (Т)
Структура задания на разработку подсистемы защиты. Введем в рассмотрение множества аппаратных платформ - Н={И} где И -название аппаратной платформы; операционных систем - 08, программного обеспечения 8 (структура этих множеств будет описана ниже). ъeZ - зона безопасности, к которой принадлежит элемент (отдельно рыделяются «граничные элементы» принадлежащие нескольким зонам, например, таким элементом может быть сервер удаленного доступа); Р сР - множество требований к защите, которые нужно выполнить в отношении данного элемента (например, требование «контроль над записью данных на съемный носитель» не имеет смысла в отношении элемента, не оборудованного аппаратурой для записи на съемные носители, и этот факт можно отразить в модели, не включив данное требование в соответствующее элементу множество Р ); N - число однотипных элементов в данной зоне (если М 1, то элемент ееЕ описывает группу однотипных элементов АС). Перейдем к описанию операционной системы с точки зрения выполняемых ею функций безопасности. Предварительно нужно уточнить определение самого множества 08 : 08={05 I 08= 05_пате, 08_уег }, где 08_пате - название операционной системы, 08_уег - версия операционной системы. Механизмы безопасности операционной системы М О Ж Н О описать, используя элементы множества OSS, определяемого следующим образом: OSS={oss I oss= os, RV, SERT }, где oseOS, RV={ ri,Vi rieR, VjeVi}, SERT - множество сертификатов, подтверждающих функциональность механизмов защиты данной ОС (структуру его элементов пока уточнять не будем). Определим множество S универсального программного обеспечения, присутствующего в системе: S={s I s= s_name, s_ver, H _ O S }, где s n a m e - название программного продукта; s_ver - версия; H_OS = {h_os h_os= h,os , heH, oseOS} - множество, описывающее операционные системы и аппаратные платформы, для которых существует данная версия программы. Встроенные механизмы защиты универсального ПО описываются по аналогии с механизмами защиты операционных систем: SS={ss I ss= s, RV, SERT }, где seS, RV={ n,Vj ri6R, vieVj}, SERT - множество сертификатов, подтверждающих функциональность механизмов защиты данного ПО.
Предполагается, что операционные системы и универсальное ПО на момент разработки проекта уже присутствуют в АС, тогда как специализированные СЗ нужно специально приобретать (если какие-то средства уже есть их можно включить в описание, например, универсального ПО). Обозначим множество СЗ, доступных на рынке как S E C :
Адаптация теоретико-множественной модели для соответствия требованиям реляционной модели баз данных
Как отмечалось выше, при программной реализации представленной в п.2.1 теоретико-множественной модели представляется целесообразным использовать реляционную базу данных (БД) совместно с программным модулем, реализующим «внешнюю логику». Решение данной задачи осложняется следующим обстоятельством. Реляционная алгебра, используемая в качестве математической основы любой реляционной СУБД, предъявляет достаточно жесткие требования к структуре элементов, над которыми производятся операции. Однако не все элементы разработанной теоретико-множественной модели удовлетворяют этим требованиям.
Ряд элементов модели, представленной в п.2.1 данной работы, описываются кортежами, атрибуты которых не являются не скалярными значениями, как требует реляционная модель, а множествами. Например, введенное описание элемента АС вида: е= пате, Ь, оз, 8 , г, Р , М содержит неатомарные составляющие (в частности, это 8 (подмножество программных продуктов) и Р (подмножество требований)). Для того использования реляционной СУБД данное описание должно быть видоизменено, а сами данные - разнесены в несколько взаимосвязанных таблиц БД. Кроме того, должны быть учтены дополнительные требования -требования соответствия реляционных таблиц нормальным формам (НФ). По определению, реляционное отношение (таблица БД) должно соответствовать первой НФ. Обычно процесс нормализации производится до уровня соответствия НФ Бойса-Кодда, хотя в работе не ставилась задача доказательства соответствия каждой таблицы БД требованиям этой НФ.
Таким образом, можно заключить, что при проектировании структуры базы данных, необходимо описание всех элементов изменить таким образом, чтобы значения атрибутов кортежей были только атомарными. После этого, для сокращения избыточности, нужно будет разнести описание некоторых элементов модели по нескольким взаимосвязанным таблицам БД (таким образом, увеличивая число таблиц, можно уменьшить число повторений одних и тех же значений и снизить риск возникновения противоречивых данных).
В разделе 3.1 было отмечено, что для создания базы данных будет использоваться СУБД MS Access 2000 с механизмом хранения данных Jet 4.0. Рассмотрим более подробно вопросы, связанные с представлением элементов теоретико-множественной модели, описанной в разделе 2.1, в таблицах БД и их взаимосвязях. В терминологии Access столбцы таблицы базы данных именуются полями, и в тех случаях, когда это не оговорено отдельно, будем считать эти термины синонимами.
Структура разработанной базы данных представлена на рис. 3.1-3.4.
Данные схемы подготовлены при помощи CASE-средства Епл/in 4.0 путем обратного преобразования (функция Reverse Engineering) из базы данных, созданной в СУБД Access. В приложении 1 приведены тексты запросов на языке Jet-SQL (диалект SQL, используемый Access), выполнение которых приведет к созданию подобной базы данных. Надо отметить некоторое несовпадение типов, отражаемых Епл/in на схеме и реально поддерживаемых Access. Например, тип Long Integer, который установлен на схеме для некоторых полей, в Access не существует (есть тип Integer, синоним - Long [74]). Так что можно считать, что рис.3.1-3.4 отражают только общую схему. За более подробной информацией рекомендуется обратиться к приложению 1.
Перейдем непосредственно к перечислению элементов теоретико-множественной модели и описанию соответствующих им таблиц. Приводимые ниже названия таблиц взяты в квадратные скобки, как это принято в синтаксисе Jet-SQL.
Сравнение разработанного прототипа с коммерческими системами анализа риско
Как отмечалось в п.1.5, единой общепризнанной методики анализа рисков, связанных с эксплуатацией АС, на данный момент не существует, но есть ряд конкурирующих инструментальных средств, реализующих различные методики. В литературе [68,69,70] называются такие программы, как @Risk, CRAMM, RiskWatch. Ниже будут кратко рассмотрены данные продукты и указаны достоинства и недостатки реализуемых ими методов в сравнении с предлагаемыми в диссертационной работе.
@Risk - это программа, разработанная компанией Palisade Corp. и предназначенная для проведения численного эксперимента в рамках вероятностной модели исследуемой системы (или другого объекта исследования) [79]. Продукт базируется на использовании метода Монте-Карло.
С точки зрения реализации, @Risk - это надстройка над MS Excel, дополняющая данный пакет рядом математических функций (в частности, описывающих различные законы распределения вероятностей) и графических возможностей. Описав с помощью предоставленного инструментария вероятностную модель системы и угроз ИБ, исследователь может поставить численный эксперимент и получить наглядное представление результатов.
При использовании данного пакета основная проблема заключается в получении адекватной модели исследуемой АС. Как отмечалось в п. 1.3.4, на практике решение подобной задачи не всегда осуществимо. Но если это удается сделать, то с помощью @Risk можно, например, уточнить оценки ожидаемых потерь от реализации угроз ИБ. Таким образом, при проектировании подсистемы защиты АС можно использовать предлагаемые в диссертации методы и проверить полученный результат с помощью численного эксперимента, проводимого с использованием @Risk.
CRAMM - это инструментальное средство, реализующее одноименную методику, которая была разработана компанией BIS Applied Systems Limited по заказу британского правительства. Приводимое ниже описание основывается на публикациях [68,69], посвященных данной системе. Методика CRAMM выключает в себя три стадии.
На первой стадии исследования производится идентификация и определение ценности защищаемых ресурсов. Оценка производится по десятибалльной шкале, причем критериев оценки может быть несколько. В описаниях CRAMM [68] в качестве примера приводится такая шкала оценки по критерию «Финансовые потери, связанные с восстановлением ресурсов»:
На второй стадии идентифицируются и оцениваются угрозы ИБ, производится поиск и оценка уязвимостей защищаемой системы. Уровень угроз оценивается по следующей шкале: очень высокий, высокий, средний, низкий, очень низкий. Уровень уязвимости оценивается как высокий, средний или низкий. На основе этой информации вычисляется оценка уровня риска по семибальной шкале.
На третьей стадии GRAMM генерирует варианты мер противодействия выявленным рискам. Продукт предлагает рекомендации следующих типов:
рекомендации общего характера;
конкретные рекомендации;
примеры того, как можно организовать защиту в данной ситуации. GRAMM имеет обширную базу, содержащую описание около 1000
примеров реализации подсистем защиты различных AG. Данные описания можно использовать в качестве шаблонов.
Среди недостатков продукта и реализуемой им методики можно отметить, что GRAMM (судя по описаниям) не может использовать готовые наборы требований, такие как Профиль защиты «Общих критериев». Кроме того, предлагаемая шкала оценки ресурсов на первой стадии исследования представляется не совсем обоснованной: не понятно, почему взята именно такая градация.
Предлагаемью в диссертационной работе методы представляются более предпочтительными в том смысле, что генерация проекта по описанию конкретной AG может дать более адекватный результат, чем подбор подходящего шаблона. Кроме того, выбрав соответствующий набор требований при генерации проекта, можно учесть требования действующих стандартов в сфере ИБ.
В отличие от GRAMM, программа RiskWatch [84] более ориентирована на точную количественную оценку соотношения потерь от угроз ИБ и затрат на создание подсистемы защиты АС. Чтобы облегчить работу пользователей по описанию защищаемой системы, данный продукт предлагает на выбор ряд «заготовок» («коммерческая информационная система», «государственная/военная информационная система» и т.д.). После выбора такого шаблона, более конкретно описываются защищаемые ресурсы, и указывается, от каких обобщенных угроз ИБ их надо защищать. Например, на рис.4.5 показано, что в исследуемой системе базу данных необходимо защитить от угроз, приводящий к несанкционированной модификации данных.
Далее проводится опрос владельцев системы и экспертов для получения оценок объема потерь от реализации угроз (рис.4.6), оценки вероятности реализации угроз и т.д.
Итоговые отчеты включают предложения по использованию различных методов защиты, оценку стоимости СЗ, реализующих эти методы, сроки окупаемости СЗ.
Если сравнивать данный подход, с разрабатываемы в диссертации, то можно отметить, что RiskWatch, также как и CRAMM, скорее предоставляет шаблонное решение, а не генерирует проект. Кроме того, продукт не предоставляет возможности выбора одного из нескольких альтернативных проектов подсистемы защиты АС, т.е. не предлагает решения задачи выбора оптимального проекта.
Таким образом, можно утверждать, что разработанные в диссертации методы, по сравнению с существующими аналогами, обеспечивают более гибкий подход к созданию проектов подсистемы защиты АС и более четкое математическое обоснование выбора проекта, основанное на использовании аппарата теории игр.
