Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

Введение

Широко известны различные программные средства обнаружения элементов РПС - от простейших антивирусных программ-сканеров до сложных отладчиков и дизассемблеров - анализаторов и именно на базе этих средств и выработался набор методов, которыми осуществляется анализ безопасности ПО.

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

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

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

Контрольно-испытательные методы анализа безопасности программного обеспечения

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

ebd895de.gif

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

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

Пусть задано множество ограничений на функционирование программы, определяющих ее соответствие требованиям по безопасности в системе предполагаемой эксплуатации. Эти ограничения задаются в виде множества предикатов С={ci(a1,a2,...am)|i=1,...,N} зависящих от множества аргументов A={ai|i=1,...,M}.

Это множество состоит из двух подмножеств:

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

Для доказательства того, что исследуемая программа удовлетворяет требованиям по безопасности, предъявляемым на предполагаемом объекте эксплуатации, необходимо доказать, что программа не нарушает ни одного из условий, входящих в С. Для этого необходимо определить множество параметров P={pi|i=1,...,K}, контролируемых при тестовых запусках программы. Параметры, входящие в это множество определяются используемыми системами тестирования. Множество контролируемых параметров должно быть выбрано таким образом, что по множеству измеренных значений параметров Р можно было получить множество значений аргументов А.

После проведения Т испытаний по вектору полученных значений параметров Pi,i=1,...,T можно построить вектор значений аргументов Ai, i=1,...,T.

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

Программа не содержит РПС, если для любого ее испытания i=1,...,T множество предикатов C={cj(a1i,a2i...aMi)|j=1,...,N} истинно.

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

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

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

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

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

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

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

Выбирается некоторая система моделирования программ, представленная множеством моделей всех программ - Z. В выбранной системе исследуемая программа представляется своей моделью М, принадлежащей множеству Z. Должно быть задано множество моделей РПС V={vi|i=1,...,N}, полученное либо путем построения моделей всех известных РПС, либо путем порождения множества моделей всех возможных (в рамках данной модели) РПС. Множество V является подмножеством множества Z. Кроме того, должно быть задано отношение эквивалентности определяющее наличие РПС в модели программы, обозначим его Е(x,y). Это отношение выражает тождественность программы x и РПС y, где x - модель программы, y - модель РПС, и y принадлежит множеству V.

Тогда задача анализа безопасности сводится к доказательству того, что модель исследуемой программы М принадлежит отношению E(M,v), где v принадлежит множеству V.

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

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

81e301e8.gif

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

d143a10b.gif

Схема анализа безопасности ПО с помощью логико-аналитических методов

В целом полный процесс анализа ПО включает в себя три вида анализа:

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

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

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

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

  • сигнатуры вирусов;
  • сигнатуры элементов РПС;
  • сигнатуры «подозрительных функций»;
  • сигнатуры штатных процедур использования системных ресурсов и внешних устройств.

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

Синтаксический верификационный анализ предполагает поиск, распознавание и классификацию синтаксических структур РПС, а также построение структурно-алгоритмической модели самой программы.

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

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

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

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

Для сравнения методов предлагаются следующие признаки: представления предметной области, методы решения проблем неразрешимости легитимности и неперечислимости рабочего пространства, а также надежность получаемых результатов. Надежность методов анализа определяется вероятностью ошибок первого и второго рода. Под ошибкой первого рода понимается принятие за РПС безопасной программы, а под ошибкой второго рода - объявление программы безопасной, когда на самом деле она содержит РПС.

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

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

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

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

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

  1. Создать теоретические основы анализа безопасности ПО, создать словарь предметной области и осуществить в рамках этого словаря формальную постановку задачи анализа безопасности ПО;
  2. Создать методы анализа безопасности ПО, используя выбранные формальные определения, доказать их эффективность и реализуемость;
  3. Создать конкретные программные средства, реализующие методы анализа безопасности программ в конкретных аппаратно-программных средах;
  4. Создать методики применения этих средств и оценить их эффективность.

Методы

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

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

Способ представления предметной области

Пространство отношений программы с
объектами КС.

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

Принцип поиска РПС

Фиксация установления программой нелегитимности отношения доступа к объектам КС.

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

Поиск проблемы неразрешимости легитимности отношений

С помощью аппроксимации пространства легитимных отношений для данной программы и КС.

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

Решение проблемы перечислимости рабочего пространства

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

Не требуется.

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

Весьма вероятны. Чем строже требования, предъявляемые в заданной КС, тем больше
вероятность ошибки.

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

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

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

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

Преимущества

Не требует теоретической подготовки.

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

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

Метод отражает требования конкретных КС.

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

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

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

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

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

Недостатки

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

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

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

Татистические и динамические способы исследования ПО

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

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

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

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

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

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

Все средства исследования ПО можно разбить на 2 класса: статические и динамические. Первые оперируют исходным кодом программы как данными и строят ее алгоритм без исполнения, вторые же изучают программу, интерпретируя ее в реальной или виртуальной вычислительной среде. Отсюда следует, что первые являются более универсальными в том смысле, что теоретически могут получить алгоритм всей программы, в том числе и тех блоков, которые никогда не получат управления. Динамические средства могут строить алгоритм программы только на основании конкретной ее трассы, полученной при определенных входных данных. Поэтому задача получения полного алгоритма программы в этом случае эквивалентна построению исчерпывающего набора текстов для подтверждения правильности программы, что практически невозможно, и вообще при динамическом исследовании можно говорить только о построении некоторой части алгоритма.[3]

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

Помимо этих двух основных инструментов исследования, можно использовать:

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

Особенности исследования защищенного ПО

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

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

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

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

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

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

2. «Метод изменения одного байта» - в момент, когда система защиты сравнивает контрольную информацию (состояние операционной среды, контрольную сумму) с эталонной, простым изменением команды перехода она направляется по нужному пути.

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

4. Когда система защиты расшифровала критичный код, он может быть скопирован в другое место памяти или на диск в момент или вскоре после передачи управления на него. Частный случай – после окончания работы программы весь ее код расшифрован и доступен.

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

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

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

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

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

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

Оценка качества ПО может осуществляться при проведении следующих видов работ:

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

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

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

А. Базовые методики.

А.1. Методики испытаний:

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

А.2. Методика оценки показателей качества (ПК):

  • методика выбора номенклатуры ПК;
  • методика автоматизированной оценки ПК;
  • методика экспертной оценки ПК.

А.3. Методики экспертизы ПО:

  • методика экспертизы качества ПО;
  • методика экспертизы безопасности ПО.

А.4. Методики оценки требований к ПО:

  • методика экспертизы требований.

А.5. Методики принятия решений:

  • методика расчета относительных оценок ПК;
  • методика принятия решения о качестве ПО;
  • методика принятия решения о безопасности ПО;
  • методика принятия решения о выдаче сертификата качества;
  • методика расчета страховых рисков.

Б. Частные методики.

Б.1. По показателям качества:

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

Б.2. По видам ПО:

  • методики испытаний, оценки показателей, экспертизы, оценки выполнения требований к отечественным и импортным программным средствам, ОПО, пакетам прикладных программ, системам реального времени, специальному ПО, универсальному ПО, программным средствам защиты информации.[2]

Состав инструментальных средств проведения испытания программ

В состав инструментальных средств проведения испытания программного обеспечения могут входить:

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

Организационные вопросы проведения испытаний ПО

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

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

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

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

Список литературы

1. С.И. Макаренко информационная безопасность, учебное пособие, Ставрополь СФ МГГУ им. М.А.Шолохова 2009.

2. Грибунин В.Г., Чудовский В.В. - Комплексная система защиты информации на предприятии 2009.

3. Ю. Родичев «Нормативная база и стандарты в области информационной безопасности» 2017.

4. А. Бабаш, Е. Баранова, Д. Ларин «Информационная безопасность. История защиты информации в России» 2015.

5. С. Нестеров «Основы информационной безопасности» 2016.