- •Методы и средства анализа безопасности программного обеспечения
- •Общие замечания
- •Контрольно-испытательные методы анализа безопасности программного обеспечения
- •Логико-аналитические методы контроля безопасности программ
- •Сравнение логико-аналитических и контрольно-испытательных методов анализа безопасности программ
- •Способы тестирования программного обеспечения при испытаниях его на технологическую безопасность
- •Обобщенные способы анализа программных средств на предмет наличия (отсутствия) элементов разрушающих программных средств Статистические и динамические способы исследования по
- •Особенности исследования защищенного по
- •Описание способов проведения испытаний, оценки качества и сертификации программных средств
- •Состав методического обеспечения проведения испытаний программ
- •Состав инструментальных средств проведения испытания программ
- •Общая номенклатура показателей качества по
- •Выбор номенклатуры показателей качества
- •Оценка значений показателей качества по
- •Организационные вопросы проведения испытаний по
- •Методологические вопросы проведения испытаний по
- •Построение программно-аппаратных комплексов для контроля технологической безопасности программ Состав инструментальных средств контроля безопасности по при его разработке
- •Структура и принципы построения программно-аппаратных средств контрольно-испытательного стенда испытания технологической безопасности по
- •Метод расчета вероятности наличия рпс на этапе испытаний программного обеспечения вычислительных задач
- •Постановка задачи
- •Обоснование состава множества информативных характеристик
- •Алгоритмы приближенных вычислений вероятностных характеристик наличия в программах рпс
- •Алгоритм a
- •Алгоритм б
- •Обоснование критериев принятия решения о наличии в программе рпс
- •Подходы к исследованию сложных программных комплексов
- •Общие замечания
- •Анализ характеристик программных модулей с помощью управляющего графа
- •Алгоритм а
- •Определение характеристик взаимосвязи модулей и структурной сложности программ с учетом полного числа связей
- •Построение критических путей, подлежащих обязательному тестированию
- •Алгоритм б
Анализ характеристик программных модулей с помощью управляющего графа
Для количественной оценки сложности программных модулей используется графовая модель, представляющая собой направленный граф с циклами, вершинами которого являются линейные участки программы, а дугами - управляющие связи между линейными участками. Анализируя такой граф, можно обнаружить неисполняемые участки программы, получить все циклы (явные, заданные операторами цикла, и неявные, построенные с помощью условных операторов), обнаружить входы «сбоку» в структурированные конструкции (например, вход в тело цикла, минуя заголовок), наличие нескольких входов и выходов из процедур, отступления от стандартов программирования и т.д., что существенно важно при анализе технологической безопасности программ и, в частности, при определении критичных путей их выполнения.
Количественная оценка сложности программы при помощи управляющего графа вычисляется [Лип0] как сумма V=e-n+2p, гдеe– число дуг,n- число вершин,p- число связных компонент графа. Оценкой сложности можно пользоваться и при проектировании программ: если сложность превосходит некоторое критическое значение, то программу целесообразно разбить на более мелкие модули для упрощения ее понимания и отладки. В качестве критической сложности обычно принимают значение 10 единиц.
Основные алгоритмы, используемые на данном этапе, связаны с преобразованием управляющего графа, его анализом и построением возможных путей реализации программы. При этом преобразование графа основывается на понятии структурного дерева программы, вершинам которого соответствуют структурированные конструкции программы (условные операторы, циклы и последовательные операторы), вершины управляющего графа и неструктурируемые конструкции.
Неструктурируемой конструкцией графа называется его компонент, не содержащий других конструкций с одним входом и одним выходом и не принадлежащий множеству структурированных конструкций.
Вычисление управляющего графа обычно осуществляется при трансляции программы, но, к сожалению, большинство компиляторов не выдает его программисту в качестве результата своей работы.
При использовании ассемблеров управляющий граф легко может быть восстановлен по машинному коду [Лип0],а для языков высокого уровня необходимо создавать нетривиальные программы, сканирующие исходный текст и выделяющие управляющие конструкции языка.
Однако при разработке методики определения критических путей управляющих программ с позиции обеспечения технологической безопасности можно сделать допущение, что управляющий граф программы известен.
Алгоритм построения структурного дерева программы (алгоритм А) сводится к реализации следующей конструкции. Построение структурного дерева программы осуществляется параллельно со сверткой управляющего графа, когда выделенная конструкция заменяется одной вершиной. Для краткости управляющий граф на очередном этапе свертки будем называть графом программы. Таким образом, граф программы будет последовательно преобразовываться вG0,G1,..., гдеG0- исходный управляющий граф последовательности - граф, состоящий из одной вершины.