Контрольно-испытательные методы поиска недекларированных возможностей

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

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

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

1. На стадии предварительных стен­довых испытаний (проводится не во время штатного функционирования программы).

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

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

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

Определенную роль ФД играет и при «взрывах» так называемых логических бомб, так как позволяет так же как и в предыдущем случае вовремя перейти на резервную параллельно работающую ВС (может быть и с большими потерями).

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

Построение контрольно-испытательного стенда

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

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

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

Рис. 64. Структурная схема контрольно-испытательного стенда

Контрольно-испытательный стенд состоит из следующих модулей.

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

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

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

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

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

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

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

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

Метод Нельсона оценки технологической безопасности

программного обеспечения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Определение для каждого j величины P' = a_jP_j, где a_j определяется в соответствии со следующими правилами:

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

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

· a_j =0,90, если подмножество G_j не включает ни одного контрольного примера, но в процессе проверки программы были найдены все сегменты и все сегментные пары ветви L_j;

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

· a_j =0,80-0,20 m, если m сегментов (1£ m £4) ветви L_j не были опробованы в ходе испытаний;

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

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

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

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

Дата добавления: 2014-01-11