Зегжда Д.П. Информационная безопасность

Подождите немного. Документ загружается.

Как говорилось в первой главе под безопасностью ПО будем понимать отсутствие

в нем элементов РПС. Следовательно, согласно определению РПС, данному в § 2.3.1,

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

устанавливает нелегитимных отношений с объектами ВС. С учетом введенных понятий

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

Для того чтобы доказать, что исследуемая программа р безопасна, необходимо и

достаточно доказать, что pV, что с учетом предложенного определения РПС означает,

что множество отношений α

, которому принадлежат все отношения с объектами ВС,

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

отношений (α

∩ β

=∅).

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

невозможно построить разрешающую процедуру, определяющую легитимность

отношения доступа. Во-вторых, невозможно получить все элементы для определения их

легитимности.

Способ разрешения этих проблем зависит от того, в каком пространстве —

пространстве отношений или пространстве программ будет рассматриваться задача

анализа безопасности. В следующем разделе будет подробно рассмотрена постановка

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

2.3.3. Методы анализа безопасности ПО.

В области анализа безопасности программ практика значительно опережает

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

элементов РПС — от простейших антивирусных программсканеров до сложных

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

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

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

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

безопасности ПО.

2.3.3.1. Классификация методов анализа безопасности.

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

факторами — неразрешимостью множества отношений нелегитимного доступа и

проблематичностью порождения рабочего пространства отношений программы с

объектами ВС.

В зависимости от способа преодоления этих трудностей предлагается разделить

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

испытательные и логико-аналитические[15]. В такой классификации тип используемых

для анализа средств не принимается во внимание — в ее этом преимущество по

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

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

объект(программу) — контрольно-испытательные методы анализа рассматривают РПС

как феномен, а логико-аналитические —как ноумен.

Если рассматривать РПС как феномен, то задача решается в пространстве

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

содержит РПС, необходимо доказать, что рабочее пространство программы α

содержит

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

осуществления нелегитимного доступа к объектам ВС. Эти методы наиболее

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

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

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

среде с фиксацией попыток нарушения систем защиты и разграничения доступа[16]

Кроме того, эти методы используют специальные программы-сторожа,

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

Если рассматривать РПС как ноумен, то задача решается в пространстве программ

путем аппроксимации множества РПС некоторым разрешимым подмножеством. Процесс

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

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

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

проверку некоторого набора признаков. Подмножество РПС задается в виде

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

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

исследуемой программы — ищут в ней сигнатуру или проверяют совокупность

признаков. Схема разделения методов анализа представлена на рис. 2.6.

Методы анализа безопасности программ

Логико-аналитические Контрольно-испытательные

Определение разрешимого

подмножества РПС.

Определение характеристической

функции.

Вычисление значения

характеристической функции для

исследуемой программы.

Аппроксимация множества

нелегитимных отношений.

Установление критериев безопасности.

Построение программы испытаний.

Контроль за

выполнением

программы.

Контроль за

состоянием ВС.

Применение средств контроля.

Определение значений контролируемых

параметров.

Проверка критериев безопасности

программы.

Рис.2.6. Систематизация методов анализа безопасности ПО.

2.3.3.2. Контрольно-испытательные методы анализа безопасности ПО

Контрольно-испытательные методы решают задачу анализа в пространстве

отношений. Единственный способ решения задачи в этом случае — это проведение

испытаний с целью получения рабочего пространства программы α

и проверка

легитимности отношений, принадлежащих этому множеству. Однако, при этом

возникают проблемы, обозначенные в § 2.3.2 — неразрешимость множества

нелегитимных отношений

и невозможность получить все элементы α

В этом случае проблема разрешимости множества нелегитимных отношений

преодолевается путем установления жестких ограничений на рабочее пространство

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

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

программы и ВС очевидна —те множество нелегитимных отношений β

аппроксимируется объемлющим его разрешимым множеством запрещенных отношений

, α

β

(см рис 2.7).

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

конкретной ВС. Проблема порождения рабочего пространства программы может быть

решена с помощью методов, которые применяются для определения полного множества

испытаний при тестировании правильности программ[17].

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

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

предполагаемого применения исследуемой программы.

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

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

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

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

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

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

Рассмотрим формальную постановка задачи анализа безопасности ПО для решения

ее с помощью контрольно-испытательных методов.

Пусть задана программа р и ВС S, в которой она будет функционировать. Пусть ВС

S содержит множество критичных для ее безопасности объектов С

. Тогда требования по

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

множества запрещенных отношений р с объектами C

— α

. Элементы этого множества

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

правил, позволяющего определить принадлежность отношения к этому множеству.

Множество C

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

=RS

⋃DS

⋃PS

. Необходимо отметить, что состав этих множеств зависит от

используемого в ВС аппаратного и программного обеспечения (в первую очередь от

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

определяется путем экспертных оценок.

Обозначения:

Полное множество отношений доступа к объектам ВС α

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

Нелегитимный доступ β

Запрещенный доступ α

Сs

Рис. 2.7. Нелегитимный несанкционтрованный доступ и запрещенный доступ. α

В соответствии с предложенной в § 2.3.1 объектно-концептуальной моделью РПС,

множество α

состоит из трех подмножеств: α

= U

⋃R

⋃W

⋃E

где

={u

(x)|xRS

} — ограничения на доступ к ресурсам. Элементы этого

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

и операционной системы, например, оперативной памяти, процессорного времени,

ресурсов ОС, возможностей интерфейса и др.

={r

(x) | xDS

}, W

= {w

(x) | xDS

}— ограничения на доступ к объектам,

содержащим данные(информацию). Это множество запрещает доступ программе к

определенным областям памяти, файлам, базам данных и т. д.

={e(x) | xPS

} — ограничения на запуск программ. Эти ограничения в

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

систем и принимают форму запретов на порождение процессов, установление сеансов

связи и т.д.

Поскольку множество запрещенных отношений α

включает в себя множество

нелегитимных отношений β

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

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

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

устанавливает ни одно из отношений, входящих в множество α

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

Для того чтобы доказать, что программа р безопасна для применения в ВС S

достаточно доказать, что рабочее пространство программы р в ВС S не содержит

запрещенных

отношений, т.е. α

∩ α

= ∅

Очевидно, что набор отношений, устанавливаемых программой с объектами ВС,

зависит от входных данных программы, исходного состояния ВС и интерактивного

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

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

(анализе правильности) программ[18]. С их помощью можно создать представительный

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

ограниченного числа тестов. Однако, с учетом ограниченного объема испытаний,

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

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

средства, заимствованные из теории верификации программ[17,18] Проведение

испытаний заканчивается при наступлении одного из трех условий

— зафиксирована попытка установления запрещенного отношения,

принадлежащего множеству α

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

безопасности, предъявляемым для эксплуатации в ВС S;

— исчерпан лимит тестовых испытаний, отведенный для проведения

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

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

— проведено множество испытаний, покрывающее рабочее пространство

программы — программа р удовлетворяет требованиям по безопасности, предъявляемых

ВС S.

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

представлена на рис. 2.8.

Осуществление контрольного запуска,

получение информации об отношениях,

установленных программой с объектами ВС

Средства

контроля и

протоколирования

Множество

запрещенных

отношений α

Программа р

Составление сценария запуска.

Определение множества условий запуска

—X

Множество

тестов

Анализ протокола запуска, определение

множества установленных программой

отношений — α

(X)

Рис 2.8. Схема анализа безопасности ПО с помощью контрольно—испытательных методов

2.3.3.3. Логико-аналитические методы анализа безопасности ПО.

Логико-аналитические методы решают задачу в пространстве программ. Это

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

что она не принадлежит множеству РПС(V).

В этом случае проблема неразрешимости множества нелегитимных отношений и

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

неразрешимости множества V. Эта проблема преодолевается

за счет того, что множество V аппроксимируется некоторым разрешимым

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

разрешимого подмножества РПС. Тогда задача анализа сводится к вычислению значения

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

Поскольку программа представляет собой нетривиальный объект, характеристическая

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

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

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

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

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

эквивалентность модели исследуемой программы некоторой обобщенной модели РПС.

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

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

программы строкой бит. Тогда в качестве модели программы выступает ее битовый

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

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

Более сложные методы используют формальные модели основанные на

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

РПС[19].

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

методами может быть сформулирована следующим образом.

Выбрана некоторая система моделирования программ, в которой каждая

программа может быть представлена своей моделью, обладающей множеством

Проверка наличия отношений из α

множестве α

и других условий завершения

процесса анализа

атрибутов А={а

| i=1..N}. В выбранной системе исследуемая программа р представляется

своей моделью М

, которая характеризуется множеством атрибутов А

={а

| i=1..N}. В

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

РПС V*V, обладающее определенной на множестве атрибутов А характеристической

функцией X

, a

..a

). Подмножество РПС V* может быть получено либо путем

построения моделей всех известных РПС, либо путем порождения моделей всех РПС,

возможных в данной системе моделирования.

Тогда задача анализа безопасности сводится к вычислению значения

характеристической функции X

на множестве атрибутов программы р — если X

..a

) истинно, то программа р является РПС, принадлежащим подмножеству РПС

V*(pV*), если ложно, то программа не является РПС, принадлежащим выделенному

разрешимому подмножеству РПС V*(pV*).

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

2.9) необходимо, во-первых, выбрать систему моделирования программ. Существует

много научных подходов к решению этой проблемы, например [18,20], большинство из

которых в той или иной степени пригодны для описания РПС. На компьютерную

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

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

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

компьютерных программ, которые будут подробно рассмотрены в § 2.3.4. Можно

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

разрешимое подмножество РПС и конструктивно определить его характеристическую

функцию.

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

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

На этом этапе наиболее серьезной проблемой является создание формальных моделей

хотя бы отдельных классов РПС. В работе[21] была предпринята попытка создания

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

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

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

семантических графов[22] и объектно-ориентированных моделей[23].

Затем надо позаботиться о средствах получения множества значений атрибутов для

исследуемой программы. Это могут быть различные средства применяемые для анализа

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

"взлома" программ[24].

После этого на основании полученных значений атрибутов можно вычислить

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

относительно выбранного разрешимого подмножества РПС.

Программа

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

набора атрибутов А.

Определение разрешимого

подмножества РПС V

характеристической функции

, a

..a

)

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

программ.

Рис. 2.9. Структурная схема логико-аналитических метод

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

2.3.3.4. Сравнение логико-аналитических и контрольно-испытательных методов

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

Комплексная система исследования безопасности ПО должна включать как

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

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

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

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

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

получаемых результатов. Надежность методов анализа может определяться

вероятностью ошибок первого и второго рода. Под ошибкой первого рода понимается

принятие за РПС безопасной программы, а под ошибкой второго рода— объявление

безопасной программы, на самом деле являющейся РПС.

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

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

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

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

множества РПС. Кроме того, они позволяют создать легко применяемые средства

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

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

недостаток — исследование безопасности проводится лишь относительно некоторого

подмножества РПС.

С практической точки зрения — с точки зрения обеспечения безопасности

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

связанными с их привязкой к конкретной ВС и программе, а также с их надежностью в

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

процесса тестирования, являются преградой для их применения, за исключением тех ВС,

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

Определение множества значений

атрибутов исследуемой программы

, a

..a

)

Исследования классов РПС и

их свойств.

Средства анализа и

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

Вычисление значения

характеристической функции для

исследуемой программы

, a

..a

)

Из вышесказанного можно сделать вывод, что ни один из методов не имеет решающего

преимущества над другим Использование методов той и другой группы должно опираться только на их

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

эффективны и оправданы.

Контрольно-испытательные

методы

Логико-аналитические методы

Способ

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

предметной

области

Пространство отношений

программы с объектами ВС

Пространство программ

Пpинцип поиска

РПС

Фиксация установления

программой запрещенного

отношения с объектами ВС

Доказательство принадлежности

программы к множеству РПС

Решение проблемы

разрешимости

легитимности

отношений

С помощью аппроксимации

пространства легитимных

отношений для данной программы

и ВС

С помощью сведения к проблеме

разрешимости множества РПС и анализ

безопасности относительно разрешимого

подмножества РПС

Решение проблемы

перечислимости

рабочего

пространства

Статистические и

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

теории верификации и

функционального тестирования

Не требуется

Ошибки первого

рода

Весьма вероятны. Чем строже

требования, предъявляемые в

заданной ВС, тем больше

вероятность ошибки

При строгом доказательстве разрешимости

подмножества РПС и корректно

определенной характеристической функции

исключены

Ошибки второго

рода

Маловероятны Чем строже

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

меньше вероятность ошибки

Неизбежны. Определяются мощностью

выбранного разрешимого подмножества

РПС

Преимущества Не требует теоретической

проработки. Допускает

использование имеющихся

стандартных программных средств

Устойчивость к ошибкам второго

рода Метод отражает требования

конкретных ВС

Опирается на формальную теорию.

Не требует значительных затрат на этапе

применения Высокая надежность

полученных результатов относительно

выбранного подмножества РПС

Инвариантность метода по отношению к

различным классам программам. Позволяет

создавать автоматические простые и

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

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

существенных затрат времени

других ресурсов Процесс

тестирования требует выделенной

испытательной ВС должен

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

Подвержен ошибкам второго рода —

проверяется лишь часть множества РПС

Таб.2.3. Сравнение контрольно-испытательных и логико-аналитических методов анализа

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

2.3.4. Заключение.

Применение методики ООА для построения концептуальной модели безопасности

ПО ВС позволяет:

— представить процесс взаимодействия компонент ВС с

точки зрения безопасности;

— формализовать свойства РПС и создать основу для их

систематизации;

— дать формальное определение понятия безопасности

программ;

— формализовать задачу анализа безопасности ПО.

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

"легитимность доступа", являющееся обобщением понятия НСД, как способ адекватного

представления действий, присущих современным типам РПС Данное понятие может

быть успешно применено для построения модели безопасности ОС.

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

ПО позволяет предложить два формальных способа ее решения в пространстве программ

(логико-аналитические методы) и отношений (контрольно-испытательные методы).

Представленные результаты являются базой для разрабатываемых в Центре

Защиты Информации СПбГТУ практических средств и методик анализа безопасности

ПО и оценки их эффективности и применимости

Заключение к главе 2.

Изложенные в этой главе теоретические модели безопасности ВС являются

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

безопасности. Однако, корректная реализация этих моделей в рамках современных ОС

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

подробно рассмотрены в главе 6. С другой стороны создание защищенной системы

невозможно без учета практики функционирования существующих систем обеспечения

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

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

классификации и выявлению причин их успешного осуществления.

ГЛАВА 3.

Таксономия нарушений

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

и причины, обуславливающие их

существование.

3.1 Введение. Понятие таксономии.