авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:   || 2 |
-- [ Страница 1 ] --

Санкт-Петербургский государственный технический

университет

На правах рукописи

УДК 50.41.00 50.37.23

Корт Семен Станиславович

РАЗРАБОТКА МЕТОДОВ И СРЕДСТВ ПОИСКА

УЯЗВИМОСТЕЙ ПРИ СЕРТИФИКАЦИОННЫХ

ИСПЫТАНИЯХ ЗАЩИЩЕННЫХ ВЫЧИСЛИТЕЛЬНЫХ

СИСТЕМ.

Специальность:

05.13.16 - "Применение вычислительной техники, матема тического моделирования и математических методов в на учных исследованиях" 05.13.19 - "Методы и системы защиты информации и ин формационной безопасности" Диссертация на соискание ученой степени кандидата технических наук

Научный руководитель:

Доктор технических наук, профессор Зегжда П.Д.

Санкт-Петербург 1998 Введение.................................................................................................... 1. Постановка задачи........................................................................... 1.1. Существующие методики поиска уязвимостей в ЗВС............. 1.1.1. Метод поиска уязвимостей Липаева.................................... 1.1.2. Анализ защиты....................................................................... 1.1.3. Методика поиска уязвимостей, связанных с несоответствием данных во времени............................................. 1.1.4. Методика поиска уязвимостей, связанных с остаточными данными выделения - освобождения ресурсов............................. 1.1.5. Методика поиска уязвимостей, связанных с ошибками последовательности......................................................................... 1.1.6. Проект RISOS......................................................................... 1.1.7. Метод гипотез об уязвимостях............................................. 1.2. Существующие модели нарушителя.......................................... 1.3. Постановка задачи........................................................................ 1.4. Выводы.......................................................................................... 2. Разработка теоретических основ методики анализа ЗВС............ 2.1. Формальное описание проблемы................................................ 2.1.1. Представление системы защиты в виде монитора безопасности пересылок................................................................. 2.1.2. Представление системы защиты в виде ТСВ..................... 2.1.3. Жизненный цикл ЗВС........................................................... 2.1.4. Доказательство условий безопасности преобразования модели ЗВС.................................................................



...................... 2.2. Систематизация причин возникновения уязвимостей............. 2.2.1. Уязвимости, вносимые в систему на стадии разработки математической модели системы................................................... 2.2.2. Уязвимости, вносимые в систему по причине некорректного отображения модели безопасности...................... 2.3. Классификация признаков, характеризующих действия нарушителя, использующего уязвимость в системе........................ 2.3.1. Выбор модели нарушителя для автоматизации методики поиска уязвимостей в ЗВС.............................................................. 2.3.2. Метрика, характеризующая последствия атаки на уязвимость системы......................................................................... 2.3.3. Метрики, характеризующая сложность обнаружения и использования уязвимости.............................................................. 2.4. Методика поиска уязвимостей в ЗВС......................................... 2.5. Выводы.......................................................................................... 3. Методы поиска уязвимостей в ЗВС............................................... 3.1. Уязвимости, обнаруживаемые при выборе модели нарушителя первого уровня..................................................................................... 3.1.1. Недостатки моделей дискреционного доступа................... 3.1.2. Недостатки моделей мандатного доступа........................... 3.2. Уязвимости, обнаруживаемые при выборе модели нарушителя второго уровня..................................................................................... 3.3. Уязвимости, обнаруживаемые при выборе модели нарушителя третьего уровня.................................................................................... 3.3.1. Уязвимости начального состояния...................................... 3.3.2. Некорректность изменения состояния системы................. 3.3.3. Искажение понятий субъекта и объекта............................. 3.4. Сводная таблица описания уязвимостей.................................... 3.5. Выводы.......................................................................................... 4. Система автоматизации поиска уязвимостей в ЗВС.................... 4.1. Модульная структура системы автоматизации поиска уязвимостей в ЗВС.............................................................................. 4.1.1. Реализация модуля определения условий поиска уязвимостей в ЗВС......................................................................... 4.1.2. Реализация модуля поиска уязвимостей в ЗВС при выборе нарушителя первого уровня.......................................................... 4.1.3. Реализация модуля поиска уязвимостей методом непосредственного тестирования ЗВС........................................ 4.1.3.1. Модуль выбора интерфейсов, подлежащих тестированию.............................................................................. 4.1.3.2. Генератор тестов............................................................ 4.1.4. Реализация модуля поиска уязвимостей методом формального анализа..................................................................... 4.1.6. Реализация модуля выходных данных.............................. 4.2. Применение системы автоматизации поиска уязвимостей при сертификационных испытаниях...................................................... 4.3. Выводы........................................................................................ 5. Заключение..................................................................................... 6. Список литературы........................................................................ Введение.





Прогресс в области применения информационных техноло гий, обусловленный развитием вычислительных систем (ВС) и про граммных средств, сопровождается повышением требований к ста бильности функционирования информационных систем и устойчи вости при попытках нарушения их безопасности. Вышеуказанные требования сформулированы в различных нормативных документах, в том числе в требованиях Гостехкомиссии Российской Федерации.

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

Методологическая и теоретическая база изучения проблем, возникающих при поиске уязвимостей в защищенных вычислитель ных системах (ЗВС), как специфического объекта научных исследо ваний в настоящее время только формируется усилиями таких уче ных, как В.С. Анашина, С.В. Герасименко, А.А. Грушо, С.П. Растор гуева, М. Л. Ухлинов, М. Бишоп, К. Лендвер, П. Ньюман. Данная работа опирается на результаты этих исследований и развивает их отдельные положения применительно к задаче формализации мето дов обнаружения уязвимостей в ЗВС, представляющей одно из на правлений общей проблемы обеспечения информационной безопас ности. Процесс сертификации и поиска уязвимостей в ЗВС дорог и должен обладать надежностью выводов. Поэтому разработка сис темных основ и практических методов анализа безопасности, по вышение их надежности и эффективности, автоматизация процесса анализа безопасности и методики его проведения составляют акту альную проблему, имеющую большое научное и практическое зна чение.

В диссертационной работе рассмотрен системный подход к задаче анализа информационной безопасности ЗВС, предложены ме тоды и разработаны практические средства поиска уязвимостей.

Целью работы является объективизация и автоматизация сер тификационных испытаний защищенных вычислительных комплек сов безопасности путем разработки и применения формальных ме тодов и автоматизированных средств поиска уязвимостей, а также выработка рекомендаций по повышению безопасности ЗВС.

Для достижения поставленной цели в работе решались сле дующие задачи:

1. Разработка формальной постановки задачи поиска уязви мостей в ЗВС, позволяющей автоматизировать и объективизировать процесс поиска уязвимостей в ЗВС.

2. Формализация условий корректности преобразования мо дели безопасности в процессе проектирования ЗВС.

3. Построение систематизации уязвимостей в ЗВС на основа нии разработанных условий преобразования модели безопасности.

4. Разработка модели нарушителя, используемой при описа нии уязвимостей в ЗВС.

5. Разработка методики, направленной на поиск уязвимостей в ЗВС.

6. Разработка языка описания политик безопасности, позво ляющего описать недостатки в математических моделях ЗВС.

7. Разработка автоматизированных средств поиска уязвимо стей в ЗВС на основании предлагаемой методики на основании предлагаемой методики, позволяющих увеличить надежность про цесса сертификационных испытаний, а также уменьшить их стои мость.

Работа состоит из четырех глав.

В первой главе рассмотрены проблемы, возникающие при анализе ЗВС в процессе сертификационных испытаний. Под защи щенной вычислительной системой понимается вычислительная сис тема, содержащая в своем составе механизмы защиты, удовлетво ряющие требованиям некоторого класса защищенности в соответст вии с положениями нормативных документов. Под уязвимостью по нимается некоторое процедурно-декларативное описание состояние системы, в котором возможно осуществление атаки. Подчеркнута необходимость поиска уязвимостей в ЗВС в процессе сертификаци онных испытаний. Рассматриваются существующие методики поис ка уязвимостей в ЗВС и указываются их недостатки. Рассматривают ся известные модели нарушителя, используемые при анализе, и рас сматриваются их особенности и недостатки. Глава завершается формулировкой общей постановки задачи.

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

Разработана модель нарушителя, приведены основные этапы мето дики поиска уязвимостей в ЗВС.

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

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

Основные положения, выносимые на защиту:

1. Формальная постановка задачи и общие принципы анализа безопасности ЗВС.

2. Условия преобразования модели безопасности в процессе проектирования ЗВС.

3. Систематизация уязвимостей в ЗВС на основе нарушения условий преобразования модели безопасности ЗВС.

4. Модель нарушителя, используемая при поиске уязвимо стей в ЗВС.

5. Общие положения методики поиска уязвимостей в ЗВС.

6. Методы поиска неудачных характеристик в математиче ских моделях ЗВС.

Научная новизна диссертационной работы состоит в сле дующем:

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

2. На основе разработанного описания предложена система тизация уязвимостей в ЗВС.

3. Разработана модель нарушителя, позволяющая выбрать глубину анализа при сертификационных испытаниях, а также объек тивизировать процесс анализа ЗВС.

4. Для каждого типа уязвимостей, которые могут существо вать в ЗВС, сформулированы принципы поиска, методы устранения данного типа уязвимостей, а также оценки сложности его обнаруже ния и последствий его использования.

5. Разработана оригинальная методика поиска уязвимостей в ЗВС.

Практическая ценность работы определяется возможностью использования предложенных в ней методик и полученных резуль татов для осуществления поиска уязвимостей в ЗВС при сертифика ционных испытаниях. К таким результатам относятся:

1. Разработка методики поиска уязвимостей в защищенных вычислительных системах (акт об использовании от Регионального Центра Защиты Информации Санкт-Петербурга).

2. Применение разработанной методики при сертификацион ных испытаниях в Центре Защиты Информации СПбГТУ.

3. Дополнения к стандарту «Требования к устройствам типа межсетевые экраны» Федерального Агентства Правительственной Связи и Информации при Президенте РФ.

4. Реализация системы поиска уязвимостей в математической модели ЗВС.

5. Реализация системы поиска уязвимостей в ЗВС методом непосредственного тестирования.

6. Разработка и реализация комплекса лабораторных работ для курсов специальности 22.06.00 — «Организация и технология защиты информации».

Основные результаты диссертационной работы использованы при выполнении научно-исследовательских работ, проводимых в Центре защиты информации СПбГТУ, и реализованы в научных и проектных разработках, проводимых Региональным Центром Защи ты Информации. Акты о внедрении результатов работы приведены в приложении к диссертации.

Содержащиеся в работе методические материалы, а также разработанные программные средства используются в учебном про цессе на кафедре “Информационная безопасность компьютерных систем” Санкт-Петербургского государственного технического уни верситета в лекциях и практических занятиях по ряду дисциплин для студентов специальности 22.06.00 — ”Организация и технология защиты информации”[10, 11], а также в курсовых и дипломных ра ботах студентов.

1. Постановка задачи.

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

Для того, чтобы показать, что система является безопасной требуется анализ, подтверждающий данное свойство. Как показано на рисунке 1.1., анализ безопасности ЗВС опирается на требования, сформулированные в различных нормативных документах, в том числе в требованиях по сертификации Гостехкомиссии Российской Федерации[12 - 16]. Сертификация определяется как действия треть ей стороны, доказывающие, что обеспечивается необходимая уве ренность в том, что должным образом идентифицированная продук ция, процесс или услуга соответствует конкретному стандарту или другому нормативному документу [54]. За рубежом можно выделить такие нормативные документы, как [21, 22]. В данных документах описаны требования к таким механизмам ЗВС, как управление дос тупом, контроль целостности, аудит и т.д. Однако в этих документах слабо отражено понятие уязвимости, тогда как поиск уязвимостей должен стать неотъемлемой частью процесса сертификационных испытаний.

В идеале процесс сертификационных испытаний можно представить как процесс анализа системы, состоящий из двух час тей, как это показано на рисунке 1.1.

Анализ безопасности ЗВС Проверка соответствия Поиск уязвимостей системы в ЗВС требованиям нормативных документов Требования Типовые нормативных уязвимости в ЗВС документов Рисунок 1.1. Анализ безопасности ЗВС К сожалению, процесс сертификационных испытаний в на стоящее время в основном сводится к тому, что проверяется соот ветствие сертифицируемой системы требованиям, предъявляемым к ней со стороны нормативных документов. При этом процесс серти фикационных испытаний не может носить объективного характера ввиду отсутствия общепринятых подходов к оценке уровня безопас ности и расплывчатого характера документов Гостехкомиссии Рос сии в части требований к поиску в них уязвимостей. На практике весьма часты случаи фактического нарушения безопасности серти фицированных систем. Причиной этого является то, что ряд особен ностей программного обеспечения (в том числе и импортного про изводства) предоставляют нарушителю возможности, которые не проверяются в ходе сертификационных испытаний при поиске уяз вимостей. Данная ситуация возникает вследствие того, что если процесс определения соответствия сертифицируемой системы тре бованиям, предъявляемым к ней со стороны нормативных докумен тов, является достаточно стандартизованным, то методики поиска уязвимостей в каждом сертификационном центре свои собственные и нередко не являются адекватными.

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

Всякое нарушение безопасности компьютерной системы мо жет быть рассмотрено в терминах угроз, уязвимостей и атак. Под угрозой вычислительной системе будем понимать любое возможное происшествие, преднамеренное или нет, которое может оказать не желательное воздействие на активы и ресурсы, связанные с вычис лительной системой. Таким образом, задача поиска уязвимостей в ЗВС, является важнейшей составляющей процесса анализа безопас ности ЗВС.

Уязвимости могут вноситься в ЗВС на различных этапах жизненного цикла системы. Стандартный жизненный цикл ЗВС, как и у всякого программного продукта [51], включает следующие эта пы: выработка требований, проектирование, реализация, тестирова ние, эксплуатация и поддержка.

После этапа реализации ЗВС обычно подвергается анализу и тестированию и проходит сертификационные испытания в соответ ствии с требованиями нормативных документов, относящихся к за щите информации.

Уязвимостям, вносимым в систему на этапе эксплуатации и поддержки, посвящена работа [42]. Существует много автоматизи рованных средств, осуществляющих поиск уязвимостей, как в ло кальных, так и в распределенных вычислительных системах. Приме ром программного обеспечения (ПО) данного типа являются такие программные продукты, как Cops, Satan, Internet Security Scanner.

Необходимо отметить, что ошибки, вызванные некорректной реали зацией ЗВС, имеют более тяжкие последствия, чем ошибки эксплуа тации системы, т.к. они приводят к наличию уязвимостей не у от дельно взятой системы, а у целого класса систем.

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

Данная методика должна использоваться на этапе тестирования и при сертификационных испытаниях.

Существует два метода анализа программного обеспечения:

метод непосредственного тестирования и формальный анализ сис темы защиты.

Применительно к ЗВС метод непосредственного тестирова ния является менее трудоемким и позволяет относительно быстро выявить типовые ошибки в программном обеспечении, приводящие к возникновению уязвимостей в ЗВС.

Применение методов непосредственного тестирования безо пасности ЗВС описаны в работах [36, 37]. К недостаткам работ мож но отнести отсутствие типовых тестирующих воздействий, направ ленных на обнаружение типичных уязвимостей. Авторами рассмат ривалась только угроза отказа в обслуживании, тогда как больший интерес для нарушителя представляют угрозы несанкционированно го доступа и целостности.

Однако при использовании метода непосредственного тести рования ЗВС нельзя получить должной уверенности о безопасности системы вследствие дискреционного характера отношений между входными данными и выходной реакцией системы. При непосредст венном тестировании систем, содержащих программное обеспече ние, можно говорить только об отсутствии в программном обеспе чении типовых уязвимостей, но не об отсутствии уязвимостей в ЗВС вообще.

В случае формального анализа мы имеем дело не просто с ре акцией системы на некоторые группы входных данных, а с анализом внутренней реализации системы. На практике положение о анализе внутренней реализации системы выполняется путем требования о предоставлении исходных текстов ПО для формального анализа безопасности ЗВС. При выполнении данного требования возникает возможность “декомпозиции” возможных реакций системы на реак ции ее компонентов (с помощью анализа формальных спецификаций компонентов) с последующей их композицией, что дает возмож ность описания всех реакций системы.

Формальные методы позволяют уменьшить количество аргу ментов, необходимых для логического вычисления утверждения о корректности работы системы.

Для автоматизации процесса доказательства безопасности системы используются “доказатели теорем” - программное обеспе чение, проводящее формальную дедукцию и непосредственный по иск и “контроллеры доказательств” - программы, предоставляющие пользователю контролировать последовательность шагов в процессе логических выводов о свойствах системы, но проверяющие коррект ность каждого шага.

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

1.1. Существующие методики поиска уязвимостей в ЗВС.

В отечественной печати можно отметить подход В.В. Липае ва к поиску уязвимостей в ЗВС [52-54]. Рассмотрим данный подход, а также методы поиска уязвимостей в вычислительных системах, из вестные по зарубежным публикациям [44, 45].

1.1.1. Метод поиска уязвимостей Липаева.

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

При этом автор делает ставку на непосредственное тестирование как на средство поиска всех уязвимостей в ВС. В частности, в работе [] предлагается тестировать:

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

функционирование программ в критических ситуациях;

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

параллельное исполнение программ;

защиту от искажения исходных данных;

эффективность защиты от сбоев аппаратуры и не выявленных ошибок программ и данных;

удобство эксплуатации и взаимодействия;

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

Очевидно, что для сложной программной системы, какой, без со мнения, является ЗВС, данный метод обладает большей трудоемко стью, чем формальный анализ системы Применение данного метода позволяет получить только оценку достоверности в безопасности системы.

Таким образом, предлагаемый метод подходит для подтвер ждения выполнения системой требований нормативных документов, но плохо применим для поиска уязвимостей в ЗВС.

1.1.2. Анализ защиты.

Метод “анализа защиты” (protection analis) был разработан в середине 70-х годов для обнаружения ошибок в механизмах защиты в разрабатываемых операционных системах. Исследователи опубли ковали серию статей, каждая из которых описывала определенный тип ошибок и технику поиска данной ошибки. Предлагаемая техни ка базируется на поиске образцов и использования формальных тех ник для поиска образцов.

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

• ошибки доменов, включая ошибки неполного разрушения данных, неполного разрушения контекста, некорректного представления;

• ошибки контроля, включая ошибки контроля границ и ошибки в операторах контроля;

• ошибки наименования;

• ошибки последовательности, включая прерванные атомарные операции и многозначные ссылки.

Разработчики данной методики не достигли поставленной в проекте цели автоматизации процесса поиска ошибок в операцион ных системах. С другой стороны данная работа является основой не скольких описанных ниже методик поиска ошибок в операционных системах.

1.1.3. Методика поиска уязвимостей, связанных с несоответ ствием данных во времени.

В данной работе описан класс проблем, в которых данные становятся несоответствующими после их верификации. Данные ошибки называются ошибками “времени контроля к времени ис пользования”. По отношению к классификации, введенной в мето дике анализа защиты, данные ошибки соответствуют ошибкам кон троля. Если значение некоторой переменной может быть изменено после того, как переменная верифицирована, то это может привести к нарушению защиты, если переменная является частью структуры данных механизма защиты.

Значение переменной может быть изменено одним из сле дующим способов: параметр был передан в процедуру по имени или по ссылке, значение переменной остается в адресном пространстве пользователя и может быть изменено любым процессом, имеющим доступ по записи к пространству данных процесса пользователя.

Описанная техника анализа легко формализуема и примени ма к анализу исходных текстов системы. В частности, автор методи ки обнаружил 47 ошибок в исходных текстах ОС Multics.

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

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

Остаточные данные могут быть:

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

• остатки атрибутов - информация, такая как размер пространства, зарезервированная в множестве ресурсов доступна постороннему процессу (примером является размер области памяти, занимаемой паролем пользователя).

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

1.1.5. Методика поиска уязвимостей, связанных с ошибками последовательности.

Ошибки последовательности возникают вследствие ошибок спецификации последовательности событий. Ошибки последова тельности относятся к ошибкам, влияющим на безопасность систе мы из-за некорректного использования данных системы вследствие применения к ним некорректных операций.

1.1.6. Проект RISOS.

Проект RISOS был осуществлен для изучения компьютерной безопасности в середине 70-х годов. В процессе работы над данным проектом были изучены системы IBM OS/MVT, UNIVAC 1100 OS, TENEX SYSTEM для PDP-10. Важной составляющей данного про екта является классификация ошибок целостности, найденных в изученных операционных системах. Ошибки классифицированы в соответствии со следующими категориями:

• неполная проверка параметров;

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

Недостаточная проверка корректности передачи параметров мо жет привести к ошибкам в процедурах принятия решения о досту пе;

• разделение привилегированных (конфиденциальных) данных;

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

• асинхронная проверка - некорректная последовательность;

данная ошибка происходит при несоответствии прав доступа при провер ке и при обращении к данным.

• неадекватная идентификация / аутентификация / авторизация;

ав торизация относится к правам доступа пользователя к объектам системы. Авторизация базируется на данных идентификации / ау тентификации. Безопасность операционной системы может быть нарушена в случае:

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

1. существуют неидентифицированные ресурсы системы;

• нарушение границ;

код операционной системы может содержать структуры данных определенных размеров, такие как таблицы, очереди, стеки. При переполнении данных, хранимых в данных структурах, безопасность системы может быть нарушена.

• логические ошибки;

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

1.1.7. Метод гипотез об уязвимостях.

Метод гипотез об уязвимостях (Flaw Hypothesis Methodology) был разработан System Development Corporation для анализа воз можности нарушения безопасности компьютерных систем с помо щью проникновения в систему. Авторами метода было отмечено следующее: “В отсутствии формальных техник доказательства кор ректности метод проникновения является самым дешевым методом поиска уязвимостей. Исчерпывающее тестирование операционной системы отличается от метода проникновения. При тестировании можно обнаружить ошибки реализации, а при проникновении ана лиз реализации системы используется в целях обнаружения ошибок проектирования”. Метод гипотез о уязвимостях является стратегией обнаружения уязвимостей разработки ОС на основе ошибок, най денных при реализации системы. Метод состоит из четырех этапов.

1. Сбор знаний об управляющих структурах системы.

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

• межмодульных связях;

• внутренних структур модулей системы;

• механизм контроля доступа;

• иерархия объектов управления;

• реализации модулей.

2. Гипотезы об уязвимостях.

На этом этапе нарушитель предлагает гипотезы о существо вании уязвимостей в системе на основании изучения исходных тек стов и документации на систему.

3. Проверка гипотез.

На данном этапе нарушитель подтверждает или отвергает ги потезы об уязвимостях на основании атак на систему с использова нием предполагаемых уязвимостей.

4. Обобщение уязвимостей.

На данном этапе уязвимости анализируемой системы обоб щаются на основе данных об ошибках системы, полученных на эта пе 3.

На основании данной методологии было проанализировано несколько систем. В изучаемых системах исследовались следующие функциональные модули:

• контроль вводом / выводом;

• разделение программ и данных;

• контроль доступа;

• управление инсталляцией.

Метод гипотез об уязвимостях был успешно применен в не скольких исследованиях[44]. К недостаткам данной методологии можно отнести требование глубоких априорных знаний о реализа ции системы и отсутствие формализации алгоритмов тестирования механизмов безопасности.

В данной методике можно отметить следующие недостатки:

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

• отсутствие формальных обоснований алгоритма отбора гипотез об уязвимостях;

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

• на основании данной методики не представляется возможным со ставить формальную классификацию уязвимостей.

Необходимо отметить, что на основании методик поиска уяз вимостей (например, проект «Анализ защиты») в ЗВС, кроме реко мендаций по поиску уязвимостей в ЗВС, часто можно построить классификацию уязвимостей в ЗВС. Самыми известными классифи кациями уязвимостей в ЗВС являются классификации, составленные К. Лендвером и Т. Асланом [43, 44]. Данные классификации, хотя и содержат ряд полезных классификационных признаков, не базиру ются на формальной теоретической основе, и, как следствие, не мо гут быть рекомендованы для построения методики поиска уязвимо стей в ЗВС (в них отсутствует свойство полноты).

Таким образом, известные методики поиска уязвимостей не удовлетворяют требованию формальности. Это связано с тем, что разработчики методик в основном уделяли внимание конкретным ошибкам программирования, приводящим к уязвимостям в защи щенных вычислительных системах, а не причинам их возникнове ния, этапу внесения уязвимости в систему. Следовательно, формали зация существующих методик анализа защищенных вычислитель ных систем является проблематичной.

Существующие методики поиска уязвимостей имеют еще один недостаток: в них не включены параметры, которые позволили бы объективизировать и автоматизировать процесс анализа ЗВС. Та кие параметры могут быть получены из разработки модели наруши теля безопасности. Характеристики нарушителя, которыми он дол жен обладать для использования уязвимости, могут быть использо ваны для описания уязвимости, обнаруженной при анализе.

Учитывая описанные недостатки существующих методик по иска уязвимостей, необходимо построить формальную методику по иска уязвимостей в ЗВС, устраняющую эти недостатки, уточнить существующие классификации уязвимостей в ЗВС, а также автома тизировать процесс поиска уязвимостей при сертификационных ис пытаниях. Разрабатываемая методика должна объединять положи тельные аспекты метода непосредственного тестирования и метода формального анализа систем.

1.2. Существующие модели нарушителя.

Включение модели нарушителя в методику поиска уязвимо сти необходимо с целью объективизации и автоматизации процесса сертификационных испытаний.

В зарубежных документах существует понятие модели нару шителя, но ни одна существующая открытая публикация не описала данную модель.

В руководящем документе Гостехкомиссии Российской Фе дерации [14] нарушители классифицируются по уровню возможно стей, предоставляемых им штатными средствами АС и СВТ. Клас сификация является иерархической, т.е. каждый следующий уровень включает в себя функциональные возможности предыдущего. Пер вый уровень определяет самый низкий уровень возможностей веде ния диалога в АС - запуск задач (программ) из фиксированного на бора, реализующих заранее предусмотренные функции по обработке информации. Второй уровень определяется возможностью создания и запуска собственных программ с новыми функциями по обработке информации. Третий уровень определяется возможностью управле ния функционированием АС, т.е. воздействием на базовое про граммное обеспечение системы и на состав и конфигурацию ее обо рудования. Четвертый уровень определяется всем объемом возмож ностей лиц, осуществляющих проектирование, реализацию и ремонт технических средств АС, вплоть до включения в состав СВТ собст венных технических средств с новыми функциями по обработке ин формации.

Данная классификация нарушителей безопасности после со ответствующей модификации может быть использована для автома тизации процесса поиска уязвимостей, но в связи с отсутствием в ней таких понятий, как оценка ущерба от использования уязвимости, сложность обнаружения уязвимости, она не содержит метрики, по зволяющие объективизировать процесс поиска уязвимостей в ЗВС.

К недостаткам использования данной классификации в целях анализа безопасности системы можно отнести различие понятий ад министрирования системы и ее проектирования. Совершенно оче видно, что администратор любой системы (или уполномоченный для этого пользователь) может умышленно или нет нарушить политику безопасности системы (например, некорректно присвоив уровни безопасности субъектам или объектам системы) и многие исполь зуемые в реальной практике политики безопасности подразумевают, что пользователи эксплуатируют систему корректно (например «Ог раничения безопасности», приведенные в [31]).

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

В работе [20] приведены метрики, оценивающие свойства системы защиты. К сожалению, данная работа описывает безопас ность подсистем защиты информации, и результаты, полученные в работе, не могут быть распространены на ЗВС, удовлетворяющие требованиям нормативных документах к системам высокого уровня защищенности. В данной работе также используется понятие «ква лификации нарушителя» для определения стойкости системы защи ты как один из параметров, участвующих в определении значения данной метрики, что делает классификацию субъективной.

Таким образом, разрабатываемая модель нарушителя должна:

• служить объективизации процесса сертификационных испыта ний;

• облегчать автоматизацию процесса поиска уязвимостей в ЗВС.

1.3. Постановка задачи.

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

1. сформулировать формальное описание проблемы;

2. построить на основании формальной постановки задачи класси фикацию уязвимостей защищенных вычислительных систем, об ладающую полнотой вследствие формальности постановки зада чи;

3. разработать модель нарушителя, используемую для объективиза ции процесса сертификации и выбора метода поиска уязвимо стей, используемого при сертификации системы;

4. разработать методику поиска уязвимостей в защищенных вычис лительных системах, свободную от недостатков существующих методик;

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

1.4. Выводы.

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

2. Ошибки проектирования и реализации являются более серьезны ми по последствиям, т.к. приводят к уязвимостям во множестве конкретных вычислительных систем.

3. В результате анализа существующих методик анализа защищен ных вычислительных систем можно выявить два подхода: метод непосредственного тестирования вычислительной и метод анализа возможных уязвимостей системы на основе априорной информа ции о реализации системы.

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

5. Достоинством второго подхода является возможность обнаруже ния уязвимостей защищенной вычислительной системой, внесен ных не только на этапе реализации, но и на этапе проектирования системы.

6. Существующие методики поиска уязвимостей в ЗВС имеют сле дующие недостатки:

• трудно формализуемы;

• не включают модель нарушителя;

• не позволяют объективизировать и автоматизировать процесс сертификационных испытаний.

7. Описанная в руководящих документах модель нарушителя не удовлетворяет поставленной задаче объективизации и автомати зации процесса сертификационных испытаний.

8. Задачей данной работы является:

описать формальную постановку задачи;

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

разработать модель нарушителя, используемую для объективиза ции процесса сертификации и выбора набора тестов, используе мых при сертификации системы;

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

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

2. Разработка теоретических основ методики анализа ЗВС.

В данной главе разработаны теоретические основы методики поиска уязвимостей в ЗВС. Для построения данной методики было необходимо выбрать формальное описание объекта исследования, а также проанализировать процесс проектирования ЗВС. На основа нии данного анализа были выявлены условия безопасного преобра зования модели ЗВС. Нарушение этих условий приводит к возник новению уязвимостей в ЗВС, которые можно формально системати зировать. Данная систематизация обладает свойством полноты и по зволяет выявить причины возникновения уязвимостей и их характе ристики.

Также для оценки системы в соответствии с разрабатываемой методикой автором разработаны метрики, характеризующие уязви мости с точки зрения нарушителя безопасности системы, что позво лит оценить найденные в ЗВС уязвимости.

2.1. Формальное описание проблемы.

Для того чтобы разработать методику анализа ЗВС необхо димо сформулировать представление объекта исследования. Исходя из поставленной цели, анализируемая система может быть представ лена в виде формализма, в котором можно выделить четыре состав ляющие:

1. множество запросов;

2. автомат, представляющий систему;

3. требования политики безопасности;

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

представляющий работы автомата корректности Множество запросов Решение о Автомат, систему Требования политики безопасности Рисунок 2.1. Представление функционирования ЗВС.

Рассмотрим составные части данного формализма. Элемен тами множества запросов являются запросы субъектов на доступ к объектам. Данное множество мы будем обозначать символом IN.

Элементы данного множества, запросы, (in IN) представлены в виде тройки:

in = s, o, op (2-1) где:

s - субъект системы, s S;

o - объект системы, o O;

op - некоторая операция системы, op OP.

Требования политики безопасности определяют правила дос тупа субъектов системы к объектам системы. Они могут быть выра жены в виде некоторой функции доступа:

Fpb(in ) = {TRUE, FALSE} (2-2) Данная функция принимает значение TRUE тогда и только тогда, когда политикой безопасности субъекту s, осуществляющему запрос in разрешена операция op по отношению к объекту o. Вид функции Fpb зависит от типа политики безопасности, принятой в системе. Данная функция определяется на основании модели безо пасности, принятой в системе.

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

Решение о корректности работы автомата принимается на ос новании анализа соответствия между результатами, полученными в результате работы автомата (описываются функцией Fa(in))и ре зультатами, определяемыми политикой безопасности в системе.

out = {Fa (in ), Fpb(in )} = {TRUE, FALSE} (2-3) При ложном значении данной функции мы считаем, что в ре зультате определенной последовательности запросов мы смогли об наружить некорректное поведение автомата.

Рассмотрим возможные представления автомата, характери зующего систему защиты.

2.1.1. Представление системы защиты в виде монитора безопасно сти пересылок.

Очевидно, что в защищенной вычислительной системе долж на существовать некая процедура принятия решений о том, какой из запрашиваемых пользователем в системе доступов разрешить, а ка кой нет. Иначе данное понятие можно представить, как фильтр, че рез который должны пройти все запросы на доступ, сделанные субъ ектами. Схема такого фильтра получила название монитора безо пасности пересылок[47].

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

Таким образом, монитор безопасности пересылок может быть опи сан в терминах функции, с запросами на обслуживание, разреше ниями доступа, и другими компонентами состояния системы на вхо де (т. е., элементами области определения) и разрешениями или за претами на обслуживание на выходе (т. е., элементами области зна чения).

Fa(in) = {TRUE, FALSE} (2-4) Данная функция принимает значение TRUE тогда и только тогда, когда система защиты разрешает субъекту s, осуществляю щему запрос in, применить операцию op по отношению к объекту o.

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

1. ни один запрос на доступ субъекта к объекту не должен проходить мимо монитора безопасности пересылок;

2. целостность монитора безопасности пересылок должна строго контролироваться;

3. представление монитора безопасности пересылок должно быть достаточно простым для доказательства корректности его ра боты.

В настоящее время система защиты является не единым мо дулем, а совместно работающим программным обеспечением, воз можно распределенным. Таким образом, более адекватным поняти ем является понятие доверенного программного обеспечения систе мы (ТСВ).

2.1.2. Представление системы защиты в виде ТСВ.

Как определено в [46], ТСВ это: «совокупность защитных механизмов в компьютерной системе, включая аппаратное, специ альное и программное обеспечение, объединение которого реализу ет политику безопасности. ТСВ состоит из одного или более компо нентов, которые совместно реализуют единую политику безопасно сти в системе. Способность доверенного программного обеспечения корректно реализовывать политику безопасности зависит только от механизмов ТСВ и корректной администрации системы».

Основной причиной выделения ПО ТСВ является необходи мость обеспечения независимости свойства безопасности системы от ПО системы в целом.

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

in op’ (2-5) где op’ – функция, предоставляемая ТСВ.

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

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

Но с другой стороны, использование ТСВ позволяет говорить о том, что некорректное поведение системы невозможно [41].

Свойства безопасности системы в целом могут быть описаны следующим выражением:

op ' : P( ) (2.6.) где:

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

P() - есть предикат, определяющий выходную реакцию в системе в зависимости от входного воздействия.

Выражение (2-6) является предикатом второго порядка и оп ределяет следующее свойство.

Определение 2.1. Любая операция, выполняемая пользова тельским программным обеспечением, преобразуется в последова тельность вызовов функций ТСВ (функций в множестве op’) и, при условии защиты программного обеспечения ядра системы от моди фикации, свойство P() является свойством системы в целом (данное свойство не зависит от поведения программного обеспечения, не принадлежащего ядру системы). Необходимо отметить, что требо вание целостности ТСВ входит в определение 2-1.

В любом случае доказательство безопасности системы сво дится к демонстрации инвариантности состояний модели по отно шению к некоторому свойству безопасности, описываемому преди катом P (компонент безопасности модели). Данный предикат опре деляет возможность выполнения операции доступа в системе. Моде ли предоставления прав определяют предикат P с помощью понятия права доступа субъекта системы к объекту. Информационные моде ли выражают этот предикат в виде требований к несмешиванию по токов данных пользователей с различной степенью доверия.

Характеристики множества операций op’ в выражении (2.6) описывают системный компонент модели. Системный компонент определяет функциональные требования доступа к объектам вычис лительной системы в контексте модели безопасности. Соответствие анализируемой модели реальности определяется уровнем абстракт ности системного компонента. Недостаточная детализация данного компонента ведет к тому, что модель системы безопасности не от ражает реальной системы, и, как следствие, делать выводы о реаль ной безопасности системы на основании данной модели не предос тавляется возможным.

Наиболее известной интерпретацией выражения (2-6) являет ся основная теорема безопасности системы, в которой безопасность системы доказывается путем анализа состояний системы[27, 28, 29]:

«если начальное состояние системы безопасно и все переходы сис темы из состояния в состояние безопасны, то система является безо пасной». Данная интерпретация является упрощением выражения (2-6), заменяющим доказательство инвариантности предиката второ го порядка относительно операций в системе на описание системы в виде множества состояний. Доказательство основной теоремы безо пасности является в настоящее время обязательной составляющей описания моделей безопасности [31].

Таким образом, разработчик для каждой модели ЗВС опреде ляет:

1. Предикат P(), т.е. что является безопасным для данной системы (определяется политикой безопасности системы). Данный преди кат определяет множество угроз (раскрытия, целостности, отказа в обслуживании или их комбинации), от которых защищает ин формацию ЗВС.

2. Множество переменных, определяющих состояние системы (оп ределяет адекватность модели). К переменным, оказывающим влияние на безопасность системы в общем случае можно отнести:

1. переменные, описывающие субъект системы;

2. переменные, описывающие объекты системы;

3. прочие переменные, оказывающие влияние на состояние системы.

Сформулируем основные определение уязвимости ЗВС в со ответствии с основной теоремой безопасности. На основании данной теоремы все состояния системы можно охарактеризовать как авто ризованные и неавторизованные. В свою очередь, уязвимым состоя нием является авторизованные состояние, из которого может быть достигнуто неавторизованное состояние. Скомпрометированное со стояние – неавторизованное состояние системы, достигнутое из ав торизованного состояния. При этом атакой является последователь ность авторизованных состояний, приводящих к скомпрометирован ному состоянию. Тогда под уязвимостью понимается характеристи ка, отличающая уязвимое состояние от неуязвимого.

2.1.3. Жизненный цикл ЗВС.

Как было отмечено в первой главе, стандартный жизненный цикл программного продукта включает следующие этапы:

выработка требований;

проектирование;

реализация;

тестирование.

эксплуатация и поддержка.

Задачей синтеза ЗВС, безопасность которой может быть до казана, является поддержка корректности условий основной теоре мы безопасности на всех этапах жизненного цикла системы.

Таким образом, для доказательства безопасности ЗВС основ ная теорема безопасности системы, доказанная для модели системы, должна быть доказана для ТСВ: «Если ТСВ начинает свои операции в безопасном состоянии, и все переходы ТСВ из состояния в состоя ние безопасны, то все состояния ТСВ безопасны».

Обычно в процессе проектирования ЗВС высокой степени надежности должны выполняются следующие шаги.

1. Формулировка математической модели безопасности.

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

• набор функциональных требований к ЗВС (многопользователь ская, распределенная и т.д.);

• классы угроз, от которых должна защищать проектируемая ЗВС;

• степень надежности защиты информации, обрабатываемой в ЗВС для каждого класса угроз.

В математической модели системы защиты должны находить адекватное отражение все угрозы ВС, возможные со стороны зло умышленника, и все меры безопасности, которые реализует система защиты, для предотвращения этих угроз. Как было сказано выше, для защищенных систем высокой степени надежности формулиро вание математической модели ЗВС должно заканчиваться доказа тельством основной теоремы безопасности системы.

2. Создание формальных дескриптивных высокоуровневых спецификаций ТСВ (ВФС). Следующим шагом в процессе проекти рования ЗВС является создание ВФС. Этап создания ВФС соответ ствует этапу проектирования вычислительной системы. Обычно язык описания ВФС не является процедурным. Чаще всего требова ния ВФС записываются в форме логики первого порядка. Все требо вания ВФС должны быть однозначно идентифицированы и выписа ны отдельно. В основании данных спецификаций лежит математиче ская модель проектируемой ЗВС. На данном этапе проводится мо дульная и иерархическая декомпозиция ТСВ системы. На данном этапе проектирования системы все интерфейсы ТСВ и требования к ее реализации должны быть описаны. В свою очередь ВФС служат основой для проектируемого аппаратного и программного обеспече ния.

3. Синтез программного и аппаратного обеспечения системы.

Для отображения ВФС в ТСВ необходимо выполнить алгоритм, со стоящий из следующих шагов:

• идентифицировать все отображаемые элементы ТСВ;

• идентифицировать все отображаемые элементы ВФС;

• синтезировать отображение элементов ТСВ в элементы ВФС;

Для идентификации отображаемых элементов ТСВ необхо димо проанализировать код, образующий ТСВ. При этом надо иметь ввиду следующие моменты:

- процесс отображения управляется кодом ТСВ. Каждый фрагмент кода анализируется для определения того, как он удовле творяет требованиям ВФС. При этом должно четко выделяться соот ветствие между ВФС и соответствующими фрагментами кода. В хо рошо спроектированной системе данное отображение должно быть взаимно однозначным. Но при этом возможно, что один фрагмент кода соответствует нескольким требованиям ВФС или несколько фрагментов кода соответствует одному требованию ВФС. Код ТСВ, который не может быть отображен в ВФС, должен тщательно анали зироваться и при синтезе системы при возможности удаляться из ТСВ. Чаще всего причиной возникновения неотображаемых фраг ментов кода являются функциональные требования к системе.

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

- исполняемый код - не единственный элемент ТСВ, который необходимо поставить в соответствие ВФС. Состояние ТСВ опре деляют структуры данных, хранящие информацию о состоянии ТСВ.

Данные структуры также должны отображаться в соответствующие элементы ВФС. Создание списка структур данных, определяющих текущее состояние ТСВ, является ключевым вопросом в синтезе отображения между ТСВ и ВФС.

Таким образом, приведенный процесс, позволяет синтезиро вать ЗВС с формально доказанными свойствами защищенности.

Данные свойства сохраняются в ТСВ при корректной реализации каждого шага алгоритма синтеза и корректном отображении требо ваний предыдущего шага проектирования на последующем.

2.1.4. Доказательство условий безопасности преобразования моде ли ЗВС.

Утверждение 2.1. (О достаточных условиях безопасности преобра зования модели ЗВС). Если модель безопасности M, удовлетворяю щая основной теореме безопасности системы, преобразуется путем некоторого отображения Z в другое описание системы M', то данное описание удовлетворяет требованиям формальной безопасности системы, если:

1. для любых субъектов и объектов модели М существуют субъекты и объекты описания M', причем отношения доступа, описанные в модели М сохраняются в описании M'.

2. если в описании M' не существует функции, изменяющей состоя ние системы (изменяющей значение отображения субъектов и объ ектов модели M в модель M'), посредством субъектов из модели M', не описанных в модели М.

Доказательство:

M={S, O, A} - модель безопасности, для которой доказана основная теорема безопасности системы;

S - множество субъектов модели M, S=s1 s2 s3.. sn где si - тип субъекта в модели М;

O - множество объектов модели M, O=o1 o2 o3.. om где oj - тип объекта в модели М;

А - множество ограничений на доступ субъектов к объектам в модели М, A=a1 a2 a3.. ak где al - тип ограничений на доступ субъектов к объектам в модели М;

M' = {S', O', A'}: M'=Z(M) - описание системы, полученное из модели M путем применения к ней некоторого преобразования Z.

S' - множество субъектов описания M', S'=s1 s2 s3.. sn O' - множество объектов описания M', O'=o1 o2 o3.. om А' - множество ограничений на доступ субъектов к объектам в описании M';


Для модели M состояние системы в соответствии с (2.6.) оп ределяется как: (s, o, F). Для модели M' состояние определяется как (s', o', F').

Доказательство будем проводить от противного.

1. Если в описании M' все субъекты, объекты и отношения доступа однозначно соответствуют субъектам, объектам и отношениям доступа, описанным в модели M, то понятие состояния и условия перехода системы из состояния в состояние в модели M и M' сов падают. Предположим, что основная теорема безопасности, спра ведлива для модели M, но ложна для модели M'. Тогда в модели M' существуют переходы системы, изменяющие состояние моде ли M', не описанные в модели M. Но это противоречит условию, по которому все субъекты, объекты и отношения доступа описа ния M' однозначно соответствуют субъектам, объектам и отно шениям доступа, описанным в модели M. Следовательно, наше предположение ложно, и основная теорема безопасности истинна для описания M'.

2. Если в описании M' не существует функции, изменяющей со стояние системы посредством субъектов из модели M', не опи санных в модели М, то понятие состояния и условия перехода системы из состояния в состояние в модели M и M' совпадают.

Предположим, что основная теорема безопасности, справедлива для модели M, но ложна для модели M'. Тогда в модели M' суще ствуют переходы системы, изменяющие состояние модели M', на основании субъектов и объектов системы, не описанных в модели M. Но это противоречит условию, по которому все субъекты, объекты и отношения доступа описания M', не присутствующие в описании модели M, не изменяют состояние системы в описании M'. Следовательно, наше предположение ложно, и основная тео рема безопасности истинна для описания M'.

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

В утверждении 2.1. мы рассмотрели достаточные условия преобразования модели безопасности системы. И, хотя, данные ус ловия не являются необходимыми, их нарушение может являться причиной нарушения безопасности ЗВС, спроектированной с нару шением данных условий.

2.2. Систематизация причин возникновения уязвимостей.

В соответствии с утверждением 2.1. для того, чтобы система была безопасной, необходимо два условия:

1. модель безопасности, лежащая в основе разработки ЗВС безопас на;

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

Необходимо отметить, что кроме этих двух условий безопас ности ЗВС существует еще одно: как следует из комментариев к вы ражению 2-6, ТСВ системы должно обладать свойством целостно сти. Данное требование является фундаментальным требованием безопасности системы, определено для систем самых низких классов безопасности, и должно анализироваться в процессе тестирования выполнения нормативных требований к системе. Следовательно, хо тя нарушение целостности ТСВ системы и является причиной ее уязвимости, поиск уязвимостей данного типа является необязатель ным на этапе поиска уязвимостей, т.к. проблемы этого типа должны быть устранены на этапе тестирования функциональных свойств ЗВС.

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

Проанализируем возможности нарушения первого и второго условий.

2.2.1. Уязвимости, вносимые в систему на стадии разработки ма тематической модели системы.

Из основной теоремы безопасности системы следует, что для безопасности системы необходимо и достаточно выполнение сле дующих условий:

1. начальное состояние системы должно быть безопасно;

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

Таким образом, причинами появления уязвимостей в ЗВС мо гут быть: небезопасность начального состояния системы, а также некорректность выбранной математической модели, лежащей в ос нове разработки ЗВС.

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

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

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

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

Как следует из утверждения 2.1., для доказательства фор мальной безопасности ТСВ системы необходимо проверить требо вание корректности отображения ограничений модели безопасности в ограничения формальных спецификаций и далее в их реализацию в программном и аппаратном обеспечении. Если условия данного отображения удовлетворяют условиям, описанным в доказательстве основной теоремы безопасности для ТСВ, основную теорему безо пасности анализируемой системы можно считать доказанной и сис тема является безопасной.

Таким образом, на основании теоремы 2.1., можно сделать вывод о том, что уязвимости могут возникать в ЗВС по причине не корректного отображения модели безопасности системы на различ ных стадиях жизненного цикла продукта. Из теоремы 2.1. следует, что, причинами появления уязвимостей в ЗВС могут являться:

• изменение понятия субъекта или объекта в процессе преобразо вания математической модели ЗВС;

• некорректность изменения состояния системы;

Первой причиной нарушения безопасности ЗВС может быть некорректное отображение понятий субъекта и объекта. В основной теореме безопасности описываются «идеальные» субъект и объект.

В то же время, в ЗВС объекты, естественно имеют ограниченную емкость. Как следствие, уязвимости в ЗВС могут возникать вследст вие некорректных предположений о бесконечной емкости объектов.

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

Некорректность изменения состояния системы может также возникать из-за упущения в программной реализации подсистемы безопасности такого функционального свойства системы, как ее многозадачность. Если в основу математической модели системы были положены идеальные понятия субъекта и объекта, то в системе может возникнуть уязвимость, вызванная тем, что состояние систе мы может изменяться под воздействием нескольких субъектов одно временно, а не «моментально» под воздействием одного субъекта. В данном случае можно сказать, что в модели безопасности системы было принято понятие «идеального времени», нарушенное при реа лизации.

На рисунке 2.2. показана разработанная систематизация уяз вимостей в ЗВС. Развернутое описание причин возникновения уяз вимостей в ЗВС приведено в данной систематизации на основе уточнения фундаментальных причин, приведенных выше, конкрет ными ошибками программирования ЗВС, соответствующими дан ным причинам. Более подробно элементы данной систематизации раскрыты в главе 3 при рассмотрении различных типов уязвимостей.

Уязвимости в ЗВС Некорректное Некорректное Некорректная Возможность нарушения начальное состояние преобразование математическая модель целостности ТСВ системы математической модели Некорректность Изменение понятия Некорректное изменения состояния Небезопасность перехода субъекта или объекта задание прав системы из состояния в состояние Прерывание Некорректная перехода Канал утечки Ограниченность изоляция системы из информации по емкости объекта деталей состояния в времени Некорректное Зависимость реализации состояние Канал утечки наименование безопасности субъектов информации субъектов и состояния системы.

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

Рисунок 2.2. Систематизация уязвимостей в ЗВС Предлагаемая автором систематизация не отменяет система тизации уязвимостей предложенных ранее [43, 44], а дополняет их, обладая вследствие своей формальной природы, свойством полноты.

Данное свойство позволяет построить методику поиска уязвимостей, учитывающую поиск всех типов уязвимостей в ЗВС.

Также необходимо отметить влияние языка программирова ния на уязвимости, вносимые в ЗВС при разработке. Совершенно очевидно, что применение передовых языков программирования со кратит количество возможных типов уязвимостей в ЗВС. Например, применение объектно-ориентированных языков программирования может при корректной реализации устранить ошибки типа «некор ректная изоляция деталей реализации субъектов», а также «несоот ветствие времени проверки ко времени использования». Некоторые компиляторы с различных языков программирования могут обнару живать и устранять ошибки связанные с ограничением емкости объ екта на этапе реализации.

Безусловно, знание языка, на котором была реализована сис тема, упрощает процесс анализа безопасности ЗВС. Однако можно отметить, что:

ни один из существующих языков программирования не может автоматически устранить все уязвимости в ЗВС на этапе разра ботки;

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

2.3. Классификация признаков, характеризующих действия на рушителя, использующего уязвимость в системе.

Разработанная в данной работе методика поиска уязвимостей в ЗВС, включает модель нарушителя для объективизации (определяя метрики, характеризующие сложность обнаружения уязвимости на рушителем безопасности системы, а также возможные последствия для безопасности системы, вызванные использованием данной уяз вимости) и автоматизации (определяя тип необходимых испытаний) процесса сертификационных испытаний.

2.3.1. Выбор модели нарушителя для автоматизации методики по иска уязвимостей в ЗВС.

В основе модели нарушителя положим описание модели на рушителя, принятое в документе Гостехкомиссии Российской Феде рации[14] и описанное в главе 1. Проанализируем и модифицируем данную модель с целью автоматизации процесса поиска уязвимо стей в ЗВС. Описанная в данном документе модель включает клас сификацию нарушителей безопасности ЗВС в соответствии с иерар хическими уровнями возможностей нарушителя.

Необходимо отметить, что по отношению к разрабатываемой методике поиска уязвимостей в ЗВС модель нарушителя, описанная в [14], содержит избыточный уровень классификации. Третий и чет вертый уровни модели нарушителя могут быть объединены: если нарушитель обладает правами, определенными для этих уровней, то он имеет полный контроль над системой. Таким образом, в зависи мости от выбранной модели нарушителя можно проводить следую щие типы сертификационных испытаний:

1. анализ корректности математической модели, заложенной в ос нову сертифицируемой системы защиты (соответствует первому уровень модели нарушителя);

2. анализ интерфейсов реализации системы защиты на основании тестирования системы с использованием специальных программ ных средств (второй уровень модели нарушителя);

3. формальный анализ исходных текстов ПО ЗВС (третий или чет вертый уровень модели нарушителя).

Поясним выбор типа сертификационных испытаний для со ответствующей модели нарушителя.

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

При выборе второго уровня в иерархии модели нарушителя в процессе сертификационных испытаний требуется анализировать не только математическую модель ЗВС, но и проводить анализ интер фейсов реализации системы защиты. Это связано с тем, что наруши тель имеет доступ к компилятору, а значит, имеет возможность ис пользования программных интерфейсов ЗВС для нарушения безо пасности системы. В связи с тем, что нарушитель не имеет инфор мации о внутренней реализации системы защиты, не требуется про водить формальный анализ системы. Необходимо отметить, что в отличие от тестирования выполнения ЗВС своих функций, данный тип тестирования исследует поведение системы при граничных ус ловиях или в критических ситуациях.

При выборе третьего или четвертого уровней модели нару шителя в процессе сертификационных испытаний требуется прово дить не только анализ математической модели ЗВС и тестировать ее интерфейсы, но и осуществлять формальный анализ ЗВС с целью доказательства ее безопасности, т.к. предполагаемый злоумышлен ник имеет полный контроль над атакуемой системой.

Таким образом, выбор модели нарушителя является первым этапом методики поиска уязвимостей в ЗВС, т.к. он определяет дальнейший алгоритм и средства, используемые при автоматизации процесса поиска уязвимостей в ЗВС.

Обобщим различные методы поиска уязвимостей при серти фикационных испытаниях ЗВС. Результаты данного обобщения приведены в таблице 2.1.

Таблица 2.1. Обобщение методов поиска уязвимостей в ЗВС.

I уровень II уровень III уровень Нарушитель может Нарушитель может Нарушитель имеет Права наруши запускать программы разрабатывать собст- полную информацию теля, описы- из определенного венные программы о системе и неогра ваемые в моде- списка ниченные права ли Анализ математиче- Непосредственное Формальный анализ Метод, исполь ской модели ЗВС тестирование проекта зуемый для по иска уязвимо стей Документация на ЗВС Документация на ЗВС Документация на Данные для и бинарная реализа- ЗВС, бинарная реали анализа ция системы. Резуль- зация системы и ис таты анализа для мо- ходные тексты проек дели нарушителя пер- та. Результаты анали вого рода. за для модели нару шителя первого и второго рода.

Могут быть обнару- Могут быть обнару- Могут быть опреде Определяемые жены только уязви- жены примитивные лены все уязвимости уязвимости мости разработки ошибки программи- в ЗВС рования 6 3 Класс ГТК, на чиная с кото рого целесооб разно прово дить анализ Как было отмечено ранее, более высокий уровень модели на рушителя включает анализ системы, проводимый на более низком уровне. Следовательно:

1. Для более высокого уровня модели нарушителя требуется боль ший объем данных о системе.

2. Трудоемкость поиска уязвимостей в моделях более высокого уровня возрастает.

3. С более высоким уровнем модели нарушителя возрастает количе ство уязвимостей, обнаруживаемых в ЗВС (см. главу 3).

4. Для СВТ класса 6 целесообразно применять модель нарушителя не более первого уровня в связи с низкими требованиями к безо пасности в СВТ данного класса.

5. Для СВТ класса 3 целесообразно применять модель нарушителя второго уровня в связи с определением интерфейса системы за щиты, а также в связи с использованием данных СВТ в АС, обра батывающих секретную информацию.

6. Для СВТ класса 1 целесообразно применять модель нарушителя первого уровня в связи с требованиями формальной защищенно сти данных систем.

2.3.2. Метрика, характеризующая последствия атаки на уязви мость системы.

При рассмотрении последствий атаки, на уязвимость систе мы, в данной работе не будет рассматриваться проблема стоимости информации. Метрика, вводимая ниже, характеризует успешность атаки, но не стоимостные последствия, вызванные раскрытием, на рушением целостности информации или отказом в обслуживании.

Целесообразно рассматривать последствия, вызванные ис пользованием уязвимости, в связи с понятием о компоненте безо пасности, описанном в выражении 2-6. Например, система, предна значенная для предотвращения угрозы раскрытия, не защищает от угрозы целостности информации в системе, за исключением целост ности программного обеспечения ТСВ системы, что отражено в тре бованиях, уточняющих выражение 2-6. Аналогичные утверждения справедливы и для угроз целостности и отказа в обслуживании.

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

Очевидно, что с максимальным значением равным единице должны приниматься последствия атаки, нарушающие безопасность информации в отношении угрозы, от которой защищает компонент безопасности, лежащий в основе проектируемой защищенной вы числительной системы (атаки и уязвимости «первого порядка»). По следствия атак на безопасность информации, связанных с угрозами, от которых проектируемая защищенная вычислительная система не защищает (атаки и уязвимости «второго порядка»), следует учиты вать в проектируемой защищенной вычислительной системе с экс пертными коэффициентами в диапазоне 0…1 в зависимости от серь езности угрозы для области использования ЗВС.

Вторым параметром, входящим в выражение оценки послед ствий использования уязвимости является оценка количества поль зователей, затронутых при успехе атаки на уязвимость ЗВС. Если уязвимость присутствует в ЗВС, защищающей информацию от угро зы раскрытия, то возможны следующие варианты несанкциониро ванного доступа:

• к определенной информации пользователя;

• ко всей информации пользователя;

• ко всей информации группы пользователей;

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

Первый случай характеризует одноразовый несанкциониро ванный доступ к информации некоторого атакуемого пользователя в системе. Примером второго случая является получение злоумыш ленником пароля пользователя системы и использование его для по лучения полного контроля над пользователем системы. Примером третьего случая является несанкционированное получение наруши телем пароля пользователя более высокой степени доверия в систе ме мандатного разграничения доступом. При этом скомпрометиро ванными оказываются все пользователи с данной степенью доверия.

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

Таким образом, материала можно записать метрику, характе ризующую последствия от атаки на уязвимость системы, и инте гральную метрику, суммирующую последствия всех атак на уязви мости системы:



Pages:   || 2 |
 

Похожие работы:





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.