WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 27 |

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

Это отношение выражает тождественность программы x и РПС y, где x - модель программы, y - модель РПС, и y принадлежит множеству V.

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

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

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

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

• лексический верификационный анализ;

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

• семантический анализ программ.

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

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

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

• сигнатуры вирусов;

• сигнатуры элементов РПС;

• сигнатуры (лексемы) «подозрительных функций»;

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

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

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

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

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

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



2.3. МЕТОДЫ ОБЕСПЕЧЕНИЯ НАДЕЖНОСТИ ПРОГРАММ ДЛЯ КОНТРОЛЯ ИХ ТЕХНОЛОГИЧЕСКОЙ БЕЗОПАСНОСТИ При исследовании методов и средств оценки уровня технологической безопасности программных комплексов учитываются факторы, имеющие, как правило, чисто случайный характер. Следовательно, показатели, связанные с оцениванием безопасности ПО лучше всего выражать вероятностной мерой, а для их вычисления можно использовать вероятностные модели надежности ПО [56], которые при осуществлении замены условия правильности функционирования программ на условие их безопасности можно использовать для этих целей.

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

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

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

• машинная программа p может быть определена как описание некоторой вычислимой функции F на множестве E всех значений наборов входных данных, таких что каждый элемент Ei множества E представляет собой набор значений данных, необходимый для выполнения прогона программы: E=(Ei:i=1,2,...,N);

• выполнение программы p приводит к получению для каждого Ei определенного значения функции F(Ei);

• множество E определяет все возможные вычисления в программе p, то есть каждому набору входных данных Ei соответствует прогон программы p, и наоборот, каждому прогону соответствует некоторый набор входных данных Ei;

• наличие дефектов в программе p приводит к тому, что ей на самом деле соответствует функция F', отличная от заданной функции F;

• для некоторого Ei отклонение выхода F'(Ei), полученного в результате выполнения программы не должно превышать уровень безопасности программного обеспечения S(Ei), то есть безопасность обеспечивается при соблюдении ограничения: F'(Ei), S(Ei). (Вопрос о том, приводит ли некоторое отклонение выхода к нарушению условия безопасности, должен решаться в каждом конкретном случае отдельно, поскольку все определяется конкретными особенностями поведения системы после нарушения ее работы).

Совокупность действий, включающая ввод Ei, выполнение программы p, которое заканчивается получением результата F'(Ei) называется прогоном программы p. Необходимо также отметить, что значения входных переменных, образующие Ei, не должны все одновременно подаваться на вход программ p. Таким образом, вероятность P того, что прогон программы приведет к обнаружению дефекта, равна вероятности того, что набор данных Ei, используемый в данном прогоне, принадлежит множеству Ee.

Если обозначить через ne число различных наборов значений входных данных, содержащихся в Ee, то P=ne/N - есть вероятность того, что прогон программы на наборе входных данных Ei, случайно выбранном из E среди равновероятных, закончится обнаружением дефекта. При этом R=1-P - есть вероятность того, что прогон программы p на наборе входных данных Ei, случайно выбранном из E среди априорно равновероятных, приведет к получению приемлемого результата.

Однако в процесс функционирования программы выбор входных данных из E обычно осуществляется не с одинаковыми априорными вероятностями, а диктуется определенными условиями работы. Эти условия характеризуются некоторым распределением вероятностей pi, того, что будет выбран набор входных данных Ei. Распределение P может быть определено через pi с помощью величины yi, которая принимает значение 0, если прогон программы на наборе Ei заканчивается вычислением приемлемого значения функции, и значением 1, если этот прогон заканчивается обнаруN P = pi yi - есть вероятность того, что прогон жением дефекта. Поэтому i=программы на наборе входных данных Ei, выбранных случайно с распределением вероятностей pi, закончится обнаружением дефекта. При этом R=1-P есть вероятность того, что прогон программы p на наборе входных данных Ei, выбранных случайно с распределением вероятностей pi, приведет к получению приемлемого результата.

Введем также определения и обозначения, связывающие структурные характеристики программ с их безопасностью. Структурными характеристиками программы p являются множество ветвей Lj (j=1,...,n), подмножества входных наборов данных Gj, соответствующие ветвям Lj, множества сегментов Segj, из которых состоят отдельные ветви, совокупность операторов ветвления, которые обеспечивают переход от одного сегмента к другому при движении по отдельной ветви программы.





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

1. Определение множества E входных массивов.

2. Выделение в E подмножеств Gj, связанных с отдельными ветвями программы.

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

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

5. Выявление проверенных пар и непроверенных в ходе испытаний сегментов и пар сегментов.

6. Определение для каждого j величины P'=ajPj, где aj определяется в соответствии со следующими правилами [56].

• aj=0,99, если подмножество Gj включает более одного контрольного примера;

• aj=0,95, если подмножество Gj включает ровно один контрольный пример;

• aj=0,90, если подмножество Gj не включает ни одного контрольного примера, но в процессе проверки программы были найдены все сегменты и все сегментные пары ветви Lj;

• aj=0,80, если в ходе испытаний были опробованы все сегменты, но не все сегментные пары;

• aj=0,80-0,20m, если m сегментов (1m4) ветви Lj не были опробованы в ходе испытаний;

• aj=0, если более чем 4 сегмента не были опробованы в процессе испытаний.

7. Вычисление грубой оценки R" осуществляется по формуле k R = Pi, где k представляет собой общее число ветвей програмj=мы.

Приведенные выше параметры aj были определены интуитивно [56] на основе анализа теоретических результатов исследования и экспериментальных результатов тестирования различных программ. Для того, чтобы получить более точные оценки величины R необходимо провести измерения с использованием подходящего метода формирования выборки.

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

2.4. МЕТОДЫ СОЗДАНИЯ АЛГОРИТМИЧЕСКИ БЕЗОПАСНЫХ ПРОЦЕДУР 2.4.1. Постановка задачи Основной отличительной особенностью подхода, связанного с созданием алгоритмически безопасного ПО является то, что начало процесса обеспечения безопасности программ при их разработке можно перенести на более ранние этапы жизненного цикла программного обеспечения, например, на этапы, предшествующие этапу испытания программ, тем самым увеличив общее время на внесение в программы защитных функций. Здесь уместно процитировать слова Э.В. Дейкстра, одного из основоположников современной методологии программирования, сказанные им еще в году ([14], стр.41): «В настоящее время общепринятой техникой является составление программы, а затем ее тестирование. Однако тестирование программ может быть очень эффективным способом демонстрации наличия ошибок, но оно безнадежно неадекватно для доказательства их отсутствия... Не следует сначала писать программу, а потом доказывать ее правильность, поскольку в этом случае требование найти доказательство только увеличит тяготы бедного программиста». Эти слова как нельзя лучше подходят и к современной проблематике, связанной, в данном случае, не столько с разработкой правильных, сколько безопасных программ.

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

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

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

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 27 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

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