Содержание к диссертации
Введение
Глава 1. Обзор уязвимостей программных продуктов технологии промышленного проектирования 6
1.1 Современное состояние рынка функционального программного обеспечения. 6
1.2 Развитие программной инженерии 7
1.3 Уязвимости CASE-проектирования 13
1.4 Применение комплексных методологий для снижения уязвимости программного продукта на примере Rational Unified Process 16
Глава 2. Модель обнаружения неисполняемых путей на начальных этапах проектирования программного продукта 38
2.1 Проблема «мертвого кода» в логической структуре требований 38
2.2 Использование графо-аналитической модели структуры артефакта для построения комплексного кубического покрытия 47
2.3 Результаты функционирования модели 53
Глава 3. Метод обнаружения предпосылок к возникновению «мертвого кода» 55
3.1 Метод выделения логической структуры артефакта RUP 56
3.2 Преобразование логической структуры артефакта RUP в ГАМ 60
3.3 Выявление основных показателей наличия «мертвого кода» в проектируемом программном продукте 63
Глава 4. Методика снижения количества уязвимостеи в конечном программном продукте 75
4.1 Область применения метода обнаружения уязвимостей 75
4.2 Обнаружение недекларируемых возможностей на начальных этапах проектирования программного продукта 80
4.3 Динамика роста уязвимостей в сложных программных продуктах 86
Заключение 92
Литература 93
Приложение 98
- Развитие программной инженерии
- Использование графо-аналитической модели структуры артефакта для построения комплексного кубического покрытия
- Преобразование логической структуры артефакта RUP в ГАМ
- Обнаружение недекларируемых возможностей на начальных этапах проектирования программного продукта
Введение к работе
Актуальность темы
В настоящее время для качественной организации бизнес-процессов и обеспечения конкурентоспособности фирм и предприятий требуется все больше функционального программного обеспечения. Создание таких программных систем происходит с использованием инструментально-технологических средств промышленного производства приложений. С одной стороны, это приводит к сокращению сроков создания функционального ПО и повышению их качества, с другой - появляются новые проблемы, связанные с появлением избыточного кода, неточностями преобразования моделей разного уровня и, как следствие, с появлением в составе функционального ПО неисполняемого «мертвого кода», который является целью угроз безопасности и ростом уязвимости конечного программного продукта.
Цели и задачи диссертации
Целью работы является разработка метода, позволяющего обнаружить предпосылки к возникновению «мертвого кода» в программном продукте на начальных стадиях его проектирования. Для достижения данной цели были поставлены следующие задачи:
обосновать возможность появления неисполняемых путей в логической структуре программы, на этапе ее формирования;
разработать модель, позволяющую идентифицировать данную уязвимость на начальных этапах проектирования программного продукта
предложить методы обнаружения предпосылок к возникновению «мертвого кода» на стадиях проектирования, предшествующих формированию программного кода.
4 Объект исследования
Объектом исследования является функциональное программное обеспечение, создаваемое при помощи инструментально-технологических средств промышленного проектирования программного обеспечения.
Предмет исследования
Предметом исследования является технология промышленного проектирования программного обеспечения, а в частности средства поддержки начальных этапов проектирования, такие как продукты компании IBM из линеек Rational и WebSphere, входящие в общую методологию средств создания программного продукта IBM Rational Unified Process.
Методы исследования
Для решения поставленных задач были использованы методы математической логики, моделирования и графо-аналитические методы.
Научная новизна
В данной работе исследована и проанализирована проблема уязвимости «мертвого кода» на начальных этапах промышленного проектирования программного продукта, на базе методологии Rational Unified Process компании IBM.
Практическая ценность
В результате данных исследований разработана методика, позволяющая эффективно выявлять «мертвый код» на любом этапе промышленного проектирования приложения, начиная с анализа функциональных требований и построения логической структуры будущего программного продукта.
Применение данной методики позволит сделать программное обеспечение, разрабатываемое промышленным способом более надежным и безопасным, а также уменьшить объем кода, а, следовательно, ускорить
5 работу программы и уменьшить количество угроз информационной безопасности.
Структура работы
Диссертация состоит из введения, четырех глав, заключения и списка литературы.
В первой главе представлен обзор технологий промышленного проектирования, а так же обозначены основные уязвимости, возникающие в программном продукте во время разработки, и причины их появления.
Во второй главе описана модель обнаружения неисполняемых путей на начальных этапах проектирования программного продукта.
В третьей главе описан метод обнаружения предпосылок к возникновению «мертвого кода» на стадиях проектирования, предшествующих формированию программного кода.
В четвертой главе описывается методика снижения количества уязвимостей в конечном программном продукте, разработанная на основе построенной ранее модели и предложенного на ее базе метода.
В заключении приведены основные результаты диссертационной работы, сделаны выводы о теоретической значимости и о возможности практического применения данного исследования для улучшения качества программного обеспечения, разрабатываемого промышленным способом: повышения таких качеств, как надежность и безопасность, а также уменьшения объем кода, что, в свою очередь, поможет ускорить работу программы и снизить риск возникновения уязвимостей.
В приложении приведены примеры работы с UML-диаграммами.
Развитие программной инженерии
Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела еще в конце 70-х гг. к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием "программная инженерия "(software engineering). Впервые этот термин был использован как тема конференции, проводившейся под эгидой NATO в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии. Тогда же появилось первое издание, посвященное программной инженерии, — IEEE Transactions on Software Engineering. В процессе становления и развития программной инженерии можно выделить два этапа: 70-е и 80-е гг. — систематизация и стандартизация процессов создания ПО (на основе структурного подхода) и 90-е гг. — начало перехода к сборочному, индустриальному способу создания ПО (на основе объектно-ориентированного подхода) [7].
Для массового эффективного производства программного продукта необходимо создание и внедрение современных технологий, позволяющих создавать сложные комплексы программ в сжатые сроки и при минимальных затратах труда [25].
Понятие «программная инженерия» подразумевает, что сам процесс проектирования и создания ПО может являться объектом для исследования. Совершенствование методов проектирования, средств создания и систем контроля функциональности ПО поможет повысить качество вновь разрабатываемых информационных систем (ИС), увеличить их надежность и долговечность [38].
Понятие технология включает совокупность производственных процессов, предназначенных для создания определенных видов изделий, а также научное описание способов производства. Превращение программ для ЭВМ в изделия и программный продукт, создаваемый коллективами специалистов разной квалификации при больших трудовых затратах, значительно повысило актуальность создания современной технологии для массового производства таких программ [25].
Для того чтобы разработка завершилось успешно необходимо уделять внимание всем этапам этого процесса, и в первую очередь процессам постановки задачи и системного анализа, так как выполненные в рамках этих этапов действия наиболее сильно влияют на качество всего проекта. Владимир Васильевич Липаев указывает на важность данного этапа разработки и связанные с ним трудности следующим образом: "...наиболее специфическим, трудноформализуемым и тесно связанным с
функциональным назначением программ является этап системного анализа. На этом этапе формулируются назначение и основные показатели качества создаваемых программ, решаемые задачи практически полностью определяются предметной областью системного анализа. Поэтому здесь трудно обобщать технологические процессы и критерии качества при создании различных типов программ" [26].
Следующим этапом разработки является моделирование, то есть построение полного в определенном качестве описания системы. Модели включают в себя полное описание архитектуры ИС, ее структурных элементов, взаимосвязей между ними и примеров поведения взаимодействующих элементов всей системы в целом.
При помощи моделирования можно предварительно протестировать свойства системы, уменьшить риски возникновения внештатных ситуаций и облегчить процесс дальнейшего проектирования ПО.
Однако для того чтобы применение модели стало эффективным средством, облегчающим, а не усложняющим разработку, необходимо, чтобы моделирование производилось на четко заданном языке, имеющим четко определенный синтаксис и семантику.
Перечисленные выше проблемы породили потребность в программно-технологических средствах специального класса — CASE-средствах (Computer-Aided Software Engineering), реализующих CASE-технологию создания и сопровождения ПО ИС. В рамках программной инженерии CASE-средства представляют собой основную технологию, используемую для создания и эксплуатации систем ПО [8].
Под CASE-средством понимается программное средство, поддерживающее процессы жизненного цикла ПО, включая анализ требований к системе, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, управление конфигурацией ПО и управление проектом, а также другие процессы [29]. CASE-средства вместе с системным ПО и техническими средствами образуют среду разработки ПО.
В 80-х годах в среднем три четверти трудозатрат на разработку прикладных программ составляют расходы на анализ приложений, постановку задачи и формулировку требований на программный продукт [5]. В то же время центр тяжести научных исследований в программировании и подавляющее большинство публикуемых результатов научных трудов были все еще сосредоточены, как 10, 20 и 30 лет назад, на этапе реализации программ. Более того, и здесь из всего спектра вопросов технологии разработки и повышения надежности программ на этапах их логического проектирования, кодирования, тестирования и отладки за основной объем научных исследований выбирался наиболее далекий пока от практического использования раздел: аналитическая верификация и автоматический синтез программ [12].
Таким образом, к концу 80-х гг. назрела необходимость в CASE-технологиях и CASE-средствах и возникли предпосылки для их появления: было проведено много исследований в области программирования (разработка и внедрение языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описания системных требований и спецификаций и т. д.). Кроме того, были обеспечены: подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования; широкое внедрение и постоянный рост производительности компьютеров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования; внедрение сетевой технологии, предоставившей возможность объединения усилий отдельных исполнителей в единый процесс проектирования путем использования разделяемой базы данных, содержащей необходимую информацию о проекте [8]. CASE-средствам присущи следующие основные особенности: наличие мощных графических средств для описания и документирования системы, обеспечивающих удобный интерфейс с разработчиком и развивающих его творческие возможности; интеграция отдельных компонентов CASE-средств, обеспечивающая управляемость процессом разработки ПО; использование специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты: репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость; графические средства анализа и проектирования, обеспечивающие создание и редактирование комплекса взаимосвязанных диаграмм, образующих модели деятельности организации и системы ПО; средства разработки приложений, включая языки 4-го поколения и генераторы кодов; средства управления требованиями; средства управления конфигурацией ПО; средства документирования; средства тестирования; средства управления проектом; средства реверсного инжиниринга ПО и баз данных [7].
Использование графо-аналитической модели структуры артефакта для построения комплексного кубического покрытия
Для того чтобы провести дальнейшие исследование модели бизнес-процесса, описанной в примере, определяются линейные и условные вершины, обозначаются связи между ними, вводятся булевы функции и переменные: функции а, р, у, обозначающие действия условий и переменные"А1, Л2, A3, определяющие минимальную из трех входных переменных: xl, х2, хЗ (рис. 2.12). Начачо процесса (5Ї Конец процесса Рис. 2.12 Подробная диаграмма деятельности Описание нашей модели можно задать, определив несколько условий. 1. Предопределим неравенства входных переменных: xl x2 (1) xl#3 (2) х2#3 (3) 2. Зададим значения формирующих условия функций: a = true:xl x2 (4) P = true:x2 x3 (5) у = true: xl хЗ (6) 3. Зададим значения выходных переменных: Al=true:xMHH = xl (7) А2= true: Хмин = х2 (8) Л3= true: Хмин = хЗ (9) Тогда выходные данные по работе нашей модели в каждом конкретном случае, можно будет описать следующими выражениями: Casel: a = true &P = true — ЛІ = true (10) Case2: a = true&p = false&y = true—»Al = true (11) Case3: a = true & p = false & у = false — ЛЗ = true (12) Case4: a = false & P = true —»Л2 = true (13) Case5: а = false & p = false — A3 = true (14)
Для проведения дальнейшего исследования артефакта преобразуем UML-диаграмму действия в графоаналитическую модель (ГАМ).
ГАМ задается в виде множества вершин: условных, описывающих ветвления по условиям предикатам, линейных, описывающих вычисления переменных по аналитическим формулам - выражениям, и дуг связи между ними. Сходящиеся дуги описываются с применением виртуальных вершин объединения дуг [14].
Граф вычислительного процесса В некоторых случаях (10, 13, 14) для нахождения минимального элемента проверка последнего условия не понадобилась, поэтому при записи комплексного кубического покрытия (табл. 2.2) значение у в данных кубах обозначены х как оставленные без вычисления.
Упрощенная структура артефакта Соответственно расчетный граф вычислительного процесса так же будет отличаться от исходного (рис 2.15). На рисунке расчетный граф построен поверх реального, обозначенного светлыми пунктирными линиями. Рис. 2.15 Граф расчетного процесса
Как можно заметить, три из семи условий остались непроверенными, однако, нас интересует не результат вычислений, а сам процесс функционирования профаммы, поэтому рассмотрим эти условия подробнее. 2.3 Результаты функционирования модели Комплексное кубическое покрытие, полученное в предыдущем разделе данной работы, было построено без учета утверждения о том, что структура проверки условий должна быть последовательной. Чтобы удовлетворить требованию данного утверждения, нам необходимо вычислить значения переменных АЛ, А2 и A3 для каждого случая. Для этого вместо выражений easel, case4, case5 (10,13,14) введем пары: case la, case lb (15,16); case4a, case4b (19,20) и case5a, case5b (21,22) соответственно, а выражения case2 и case3 (11,12) дополним значениями всех выходных переменных (17,18): Casela: а = true&P = true& у = true — Лі = true, Л2 = false, A3 = false (15) Caselb: a = tme &p = true&y = false —»A1 = false, A2 = false, A3 = false (16) Case2: a = true & 3 = false & у = true — Al = true, A2 = false, A3 = false (17) Case3: a = true & (3 = false & у = false — A1 = false, A2 = false, A3 = true (18) Case4a: a = false & p = true & у = true —» A1 = false, A2 = true, A3 = false (19) Case4b: a = false & p = true & у = false -» Л1 = false, A2 = true, A3 = false (20) Case5a: a = false & p = false & у = true — A1 = false, A2 = false, A3 = false (21) Case5b: a = false & p = false & у = false -+ A1 = false, A2 = false, A3 = tine (22) По полученным данным (15-22) построим новое комплексное кубическое покрытие (табл. 2.3). Табл. 2.3 Комплексное кубическое покрытие с учетом значения у a P 7 Л1 Л2 A3 Casela 1 1 1 1 0 0 Caselb 1 1 0 0 0 0 Case2 1 0 1 1 0 0 Case3 1 0 0 0 0 1 Case4a 0 1 1 0 1 0 Case4b 0 1 0 0 1 0 Case5a 0 0 1 0 0 0 Case5b 0 0 0 0 0 1 Как можно заметить из табл. 2, пары выражений case а и case b дают одинаковые тройки значений переменных X только в одном случае — case4, а не во всех трех (отличия выделены в табл. 2 полужирным шрифтом), как это предполагалось при отсутствии вычисления у (10,13,14), причем для case lb и case5a все переменные X принимают значение 0. Обратившись к графической модели артефакта рис. 2.11, находим соответствие: выражения case lb и case5a (16, 21) описывают именно те пути, исполнение которых невозможно, а значит, при последующем формировании текста программы именно в этой логической структуре возникнет «мертвый код» (табл 2.4).
Метод обнаружения предпосылок к возникновению «мертвого кода» на стадиях проектирования, предшествующих формированию программного кода основывается на детальном анализе UML-диаграмм действий бизнес-процессов организации-заказчика программного продукта (как поставщика основных функциональных требований) и бизнес-логики артефакта RUP посредством построения комплексных кубических покрытий.
Преобразование логической структуры артефакта RUP в ГАМ
Теоретико-графовый подход используется... в быстроразвивающихся разделах линейного программирования и исследования операций при изучении потоков в сетях[43].
В графосимволическом языке операции представляются вершинами некоторого графа. Отношение управления задается в виде дуг этого графа. Отношение информационной зависимости задается путем перечисления имен переменных, являющихся входными и выходными для данной операции [15].
Наличие предпосылок к дальнейшему формированию «мертвого кода» определяется по значениям выходных переменных: если все булевы переменные на выходе дают значение false, то в логической структуре исследуемого артефакта присутствуют несогласованные условия, а значит и возникают неисполняемые пути.
На сегодняшний день автоматизированные системы (АС) играют ключевую роль в обеспечении эффективного выполнения бизнес-процессов как коммерческих, так и государственных предприятий. Вместе с тем повсеместное использование АС для хранения, обработки и передачи информации приводит к повышению актуальности проблем, связанных с их защитой. Подтверждением этому служит тот факт, что за последние несколько лет, как в России, так и в ведущих зарубежных странах имеет место тенденция увеличения числа информационных атак, приводящих к значительным финансовым и материальным потерям.
По данным Главного информационного центра МВД России в 1997 г. доля компьютерных преступлений составила 0,02% от общего числа преступлений в области кредитно-финансовой сферы. В абсолютных цифрах общее количество компьютерных преступлений в этом году превысило сотню, а суммарный размер ущерба — 20 млрд. рублей [2].
Однако к этой статистике следует относиться осторожно... Российским правоохранительным органам становятся известны не более 5-10% совершённых компьютерных преступлений. Их раскрываемость тоже не превышает 1-5%. Это связано с тем, что хищение информации долгое время может оставаться незамеченным, поскольку зачастую данные просто копируются [2].
Обнаружение недекларируемых возможностей на начальных этапах проектирования программного продукта
«Мертвый код» - это неисполняемый участок программы, а значит, что при тестировании традиционными методами он не может быть обнаружен, а при функционировании программного продукта в штатном режиме, он не будет влиять на результат его работы. Однако при незначительном изменении программы, «мертвый код» может превратиться в недекларированную возможность или программную закладку.
Программные закладки, которые могут выполнять хотя бы одно из перечисленных ниже действий: вносить произвольные искажения в коды программ, находящиеся в оперативной памяти компьютера (программная закладка первого типа); переносить фрагменты информации из одних областей оперативной или внешней памяти компьютера в другие (программная закладка второго типа); искажать выводимую на внешние компьютерные устройства или в канал связи информацию, полученную в результате работы других программ (программная закладка третьего типа) [2].
Программные закладки, содержащие в себе недекларированные возможности и другие угрозы безопасности можно разделить на несколько категорий, в зависимости от метода внедрения в компьютерную систему (табл. 4.2).
Тип закладки Средство ассоциации Расположение программно-аппаратные закладки ассоциированы с аппаратными средствами компьютера Их средой обитания, как правило, является BIOS — набор программ, записанных в виде машинного кода в постоянном запоминающем устройстве -ПЗУ загрузочные закладки ассоциированы с программами начальной загрузки Располагаются в загрузочных секторах (из этих секторов в процессе выполнения начальной загрузки компьютер считывает программу, берущую на себя управления для последующей загрузки самой операционной системы) драйверные закладки ассоциированы с драйверами В драйверах содержится информация, необходимая операционной системе для управления подключенными к компьютеру периферийными устройствами прикладные закладки ассоциированыс прикладнымпрограммнымобеспечениемобщегоназначения
Рассмотрим такую ситуацию: в исследуемом нами случае (раздел 2.2) оговорено, что переменные xl,x2, хЗ не равны между собой (1-3), но рассматриваемый нами модуль получает их из вне: от оператора или из другого модуля, предполагающего проверку условий неравенства (предшествующие этапы исследования данного процесса подробно рассмотрены в Приложении). Допустим, оператор ошибся или в модуле, поставляющем эти переменные, подобная проверка была устранена.
Точно также, как и в рассмотренном ранее примере, здесь возникают 2 некорректных пути: casela и case5b (26,33), однако, если все 3 неравенства (1-3) не были выполнены, то в случае case5b (33) это уже не будет «мертвым кодом», так как данный путь все же сможет быть исполнен, хоть эта возможность и не была ранее описана. А значит в исследуемом артефакте уже на уровне бизнес-модели появится программная закладка (рис. 4.4).
Переменная определена, но никогда не используется — это один из самых часто встречающихся случаев. Чаще всего он просто говорит о неаккуратном написании кода. Однако наличие таких переменных в принципе может означать потенциальную ошибку в реализации алгоритма, ведь зачем-то она была объявлена. Именно поэтому любой компилятор обязан обращать внимание разработчика на эту переменную.
По мере создания и развития некоторого набора программ, некоторые ранее используемые переменные и аргументы функций могут оказаться ненужными. Нередко случается, что внешние переменные или даже целые функции, перестают быть необходимыми но пока еще не удаляются из исходного текста. Подобные "ошибки" могут затруднить понимание и изменение программ. Вместе с тем, информация о таких неиспользуемых переменных и функциях может иногда оказаться полезной для обнаружения ошибок: ведь если некоторая функция выполняет необходимую работу, но никогда не вызывается, значит что-то не в порядке. Код, расположеный в таких местах программы, которые никогда не выполнятся, в силу синтаксиса используемого языка.
Специальные «бессмысленные» вставки, добавляемых разработчиком целью усложнения обратного инжиниринга. Запутанной (obfuscated) называется программа, которая на всех допустимых для исходной программы входных данных выдаёт тот же самый результат, что и оригинальная программа, но более трудна для анализа, понимания и модификации.
