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

003455068

На правах рукописи

Торшенко Юлия Александровна

МОДЕЛЬ И МЕТОД ОБНАРУЖЕНИЯ УЯЗВИМОСТЕЙ НА НАЧАЛЬНЫХ ЭТАПАХ ПРОМЫШЛЕННОГО ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ПРОДУКТА

Специальность 05.13.19. Методы и системы защиты информации, информационная безопасность

Автореферат

диссертации на соискание ученой степени кандидата технических наук

Санкт-Петербург 2008

003455068

УДК 004.056.4/004.4'22

Работа выполнена на кафедре «Безопасные информационные технологии» Санкт-Петербургского государственного университета информационных технологий, механики и оптики (СПб ГУ ИТМО).

Научный руководитель:

Официальные оппоненты:

Ведущая организация:

Доктор технических наук, профессор

Осовецкий Леонид Георгиевич

Доктор технических наук, профессор

Штрик Александр Аркадиевич

Кандидат технических наук, доцент

Безруков Вячеслав Алексеевич

Управление Федеральной службы по техническому и экспортному контролю (ФСТЭК) по Северо-Западному федеральному округу

Защита состоится декабря 2008 г. в 15 часов 50 минут на

заседании диссертационного совета Д 212.227.05 при Санкт-Петербургском Государственном университете информационных технологий, механики и оптики, по адресу: 101197, Санкт-Петербург, Кронверский пр., д. 49.

С диссертацией можно ознакомиться в библиотеке СПб ГУ ИТМО.

Автореферат разослан "/5"" ноября 2008г.

Ученый секретарь Диссертационного совета Д 212.227.05

кандидат технических наук доцент _/¡и> ^ -> У/ Поляков В.И.

Общая характеристика работы

Актуальность темы

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

Цели и задачи диссертации

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

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

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

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

Объект исследования

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

Предметом исследования является технология промышленного проектирования программного обеспечения, а в частности средства поддержки начальных этапов проектирования, такие как продукты компании ШМ из линеек Rational и WebSphere, входящие в общую методологию средств создания программного продукта ШМ Rational Unified Process. Методы исследования

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

1. Методика снижения количества уязвимостей в конечном программном продукте.

2. Модель распознавания неисполняемых путей в логической структуре программы, на этапе ее формирования.

3. Метод обнаружения предпосылок к возникновению «мертвого кода» на стадиях проектирования, предшествующих формированию программного кода.

Основные результаты работы

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

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

3. Разработана методика снижения количества уязвимостей в конечном программном продукте.

4. Предложен метод обнаружения предпосылок к возникновению «мертвого кода» на стадиях проектирования, предшествующих формированию программного кода.

Научная новизна

В данной работе исследована и проанализирована проблема уязвимости «мертвого кода» на начальных этапах промышленного проектирования программного продукта, на базе методологии Rational Unified Process компании IBM.

Практическая ценность

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

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

Апробация работы

Основные положения и результаты диссертационной работы докладывались и обсуждались на семинарах кафедры БИТ и конференциях:

• на IV межвузовской конференции молодых ученых (Санкт-Петербург, апрель 2008);

• на XI научно-практической конференции «Теория и технология программирования и защиты информации» (Санкт-Петербург, май 2007)

• на научно-технической конференции «День антивирусной безопасности» (Санкт-Петербург, октябрь 2007);

• на XXXVII научной и учебно-методической конференции СПбГУ ИТМО (Санкт-Петербург, февраль 2008);

• на V межвузовской конференции молодых ученых (Санкт-Петербург, апрель 2008);

• на XII научно-практической конференции «Теория и технология программирования и защиты информации» (Санкт-Петербург, май 2008);

• на XI Санкт-Петербургской межрегиональной конференции «Региональная информатика 2008 (РИ-2008)» в рамках круглого стола «15 лет российскому закону «о государственной тайне» (Санкт-Петербург, октябрь 2008).

Внедрение результатов

Результаты работы использованы в ОАО «Оптима» при реализации ряда программных проектов, в учебном процессе кафедры БИТ СПбГУ ИТМО по специальности 090103 по дисциплинам «Введение в специальность» и «Теория информационной безопасности и методология защиты информации».

Публикации по теме диссертации

Основные положения диссертации изложены в 8 печатных работах. Структура и объем диссертации

Диссертация состоит из введения, четырех глав, заключения, списка литературы и одного приложения. Материал изложен на 104 страницах машинописного текста, содержит 64 рисунка и 12 таблиц, список литературы состоит из 54 наименований.

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

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

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

• частое изменение и недостаточно четкую формулировку тре«юваний;

• нехватка ресурсов,

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

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%

1994 15)95 1998 2000 2004

Рис. 1 Динамика появления проблемных проектов Во втором разделе описано становление программной инженерии, и рассмотрена общая схема проеьтирования, создания и сопровождения

программного продукта при помощ* CASE-cpefltTB (Compute г-Aided Software Engineering ! с участием следующих ролей, участвующих в данном процессе:

• зак 1зчик или ко лечный поль зователь;

• системный аналитик;

• сисгемный аналитик/программист;

• пр» кладной про граммист;

• сисгемный программист.

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

Ка>сдый из этапэв процесса 1роектирова тя с испольюванием GASE-технологии выполняется собственный исполнителем (или исполнителями) на подходящем для даннзй конкреггюй цели описательном языке, отсода возникают: 1роблемы, ci язанные с п( реходом от (>дного этапа проектирова ния к следующему. Интуитквно понятнь.е для одного человека инструкции могут быть неверно исголкзваны следующим участником р«работки. Как следствие возникают сшибки, связанные с неточностями преобразования моделей од юш уровня »модели другого.

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

В_чствертом р«зделе рассматривается применени; комплекс 1ых

методологий разработки как (редсгво ди снижения уязвимости программного продукта, которое певволяет уменьшить рися: возникновения описанных выше ошибок, связанных с неточностями преобразования моделей различного уровня.

В качестве одного из наиболее успешных примеров комплексной реализации CASE-технологии приведена серию программных продуктов компании ЮМ, объединенную в методологию Rational Unified Process (RUF), исследование инструментов которой проводится в данной работе.

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

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

Рабочие процессы Стадии

Основные гроцеесы Начальная стадия Уточнение Конструирование Внедрение

Биз;нес - моделирование

Управление требованиями |ГШ|| j

.....■—-— ■------- ? ----- ~ '" :.......*-"•;— '------- " ГШ .... . j

Анализ н проектирование !

Реализация Тестирование ---------- i 1 л \

Í НпЯВь. ¡

Поддерживающие процессы i 1 i 1

Управление конфигурацией -Т

Создание инфраструктуры (среда разработки) 1 1 1

Предварит, итерация итер. ! итер. Ю1 Í №2 итер. 1 итер. Га? п ; N9 п+1 итер. W? 0+2 итер. 1 итез.

Итерации

Рис. 2 Фазы разработки по методологии Я11Р

Однако на данном этапе могут появиться и новые уязвимости: р;1зличные элементы модели более высокого уровня преобразуются в элементы моделей более низких уровней программно при помощи заранее предопределенных функций, а следовательно, при подобном преобразовании не могуп быть учтены все случаи взаимодействия эти:'; элементов друг с другом, что может вызвать за собой усложнение модели и увеличение кода

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

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

В первом разделе рассматривается проблема возникновения предпосылок «мертвого кода» в диаграммах на этапе постанови и требований к будущему программному продукту и на этапе построения ЦМЬ-диаграшиы аюивности для будущего программного продукта.

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

Рассмотрим небольшой пример, на рис. 3 изображена схема, моделирующая бизнес-процесс: обработки кредитной информации. На первый взгляд схема проста, ь ней нет никаких тупиковых путей, однако, если подробно остановиться на каком-либо из ее аюмегаои, можно и здесь найти возможность для возникновения «мертвого» кода пр и дальнейшей разработав ПС).

(

Анализ писков

Г" Управление заявкой

\

Рис. 3 Модель бизнес-процесса

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

данных:

<» персональные Дс1нные заказчика, " кредитная история; » выбор кредитной программы.

Для осуществления после;шего действия нам необходимо выбрать минимальную стазку ло кредиту. Рассмотрим сшуацио, когда выСор происходо из трех вариитгов параллельно другим процессам (то есть струкг/ра проверки условий должш бьпъ послгдоьатегшной, чюбы это не повлияло на другие действия). Пуста, условие а. х1 < х2, [3: х2 < >,3, а у: х1 < >3. Так же особо огогорело, что х1#2, х1£в и х2#3 (та:< как мы рассмагржаем программы кредитования и при равенспе ставок не имело бы смысла уделять внимание возмо:кности пыбсра из шхжольких вариантов). Резу.шгаты обозначим: А1:х1 - минимальное значение, А2:х2 -минимальное значение и АЗ:хЗ - минимальное зьачение. Тоща при их последовательной проверке мы придем к тому, что в некоторых случая? существуют такие пути, прохождение которые невозможно в силу несогласованности условий (рис. 4).

Рис. 4 Тупиковые пути при несогласованных условиях

Из примера следует, что неисполняшая ветвь (ксторая впоследствии приведет к возникновению «мертвого код;л в тексте программы) может появиться на этапе формирования логический структуре, а это зна1ит, что данную уязвимость следует распознавать именно на этом этапе, а не при формировании и тестировании кода, как приюто считать.

Во втором разделе на ос юве графо-аналитическол модели структуры исследуемого артефакта строите:! комплексное кубическое покрытие.

Для модели бизнес-п эоцесса, огисанной в первом пэимере, определяются линейные и условные вершины, обозначаются связи между ними, в водятся булевы функции и переменные: функции а, р, у, обозначающие дейсшю: условий и г временные АI, А2, АЗ, определяющие минимальную из трех входных переменных: х1, х2, хЗ. Тогда описатае нашей модели можне задать, определ] ш несколько; словий.

1. Предопределим неравен ггва входных теременных:

3. Зададим значения выходных перемешых: А1 =Ьие:хша=х1 (7) А2=1гие: х1М„=х2 (8) ЛЗ=йие:хМШ1=хЗ (9)

Тогда выходные данные по работе нашей модели I каждом конкретном случае, можно будет описать следующими выражениями:

Сазе1: а=1пе&(5=Иие-+Л1=1те 110)

х1#2 х1#3 х2#3

(1) (2) (3)

2. Зададим зьачения форм фующих условия функций

а=йг1е: х1 < «2 (4) Р=иг1е:х2< <3 (5) у=1гие:х1 <чЗ (6)

Сгкй: а^Шо&р = £|ке&7==1те--»Л1=йг1е (11) СгвеЗ: а - 1шо & (1 = Л у- - Гаке -»АЗ =т«е (12) &5е4: а-Гаке&Р^хие—>-Л2=Ь11е (13)

Сг Бе5: а=- Ш$е & |3 = Гаке —> ЛЗ = йие (14)

В некоторых случаях (10, 13, 14) для нахождения минимального элемзнга проверка п зеле дне; п условия не понадобилась поэтому при загаси комплексного кубическогэ покрытия (табл. 1) значение у в данных кубах обозначены х как оставленн ие без вычисления

Табл. 1 Комплексное кубическое покрэггие без учета значения у

г а Р у А1 А2 АЗ

Саэе1 | 1 X 1 0 0

Савег | 0 1 1 0 0

Са$еЗ | 0 0 0 0 1

Са$е4 0 1 X 0 1 0

СаБеЗ | 0 X 0 0 1

Не вычислив значение у, ^ы упростили модель, представленною на рис. 4, совратив количество исходящих путей (рис. 5).

Рис. 5 Упрощенная структура артефакта

В третьем ре зделе приведены вычислены результатов функциош- рования модели с последов; ггельной прозеркой всех условий и приведены о;новные показате ли наличия в фтефакте пре^посылок к к зникновешнс «мертвого кода».

Комплексно« кубическое покрытие, полученное в предыдущем разделе данной работы, были построено без учета у!верждения о том, что структура проверю I условий дол жна быть пой гедователык»: Чтобы удов, [егворип. тре( юванию данного утверждения, нам необходимо вычислшь значения переменных 11, Х2 и УЗ для калу ,ого случая. Д пяэтого вмесхэ выражений сазе!, саве4, сазе5 (10,13,14) введем пары: сазе1а, саэеН: (15,16); саМа, сазе4Ь (19,20) и сше5а, сазебЬ (21,22) соответственно, а вьражения сш-2 и саэеЗ (.1,12) дополним значениявсех выходных переменные(17,18):

Сазе1а: а=1гие&Р=йие&у=1гие —»А1=тде,А2=Шзе,А3 = 1аке (15) СавеШ: а=1гае&Р=йие&у=6ке-»'М=Ш8^Л2=-Ш8е,АЗ = &1й (16) Саяе2: а=1те&р=Шзе&у=1ше^л1=Ьда,Л2 = йке,АЗ=&153 (17) СаБеЗ: а=1те&Р=Шзе&у = Га18е — А1 =Ш8е,А2==&18е,АЗ=1ше (18) Сазе4а: а=Шзе&р = Ъгие&у=йие->л1 =Га18е,А2=Иие,АЗ=Га1зг (19) Сазе4Ь: а=1аЬе&р=1гие&у=Ызе — А1 =Ш8е,А2=йие, А3=&8е (20) Сазе5а: а=Ш8е&Р = й1э!&у=1гие-»Л1 =Ш8е, А2 =&Ье, АЗ =&ее (21) Са§е5Ь: а=1аЬе&р=йк5&у = &1зе - * Л1 = Шее,А,'! = Шее, АЗ = (ше (22) По полученным данным (15-22) построим новое комплексное кубическое покрытие (табл. 2).

Табл.. I Комплекса- ое кубичесю >е покрытие ; учетом зна нения у

а Р 7 А1 А2 АЗ

Са$е1а 1 1 1 1 0 0

Саве1Ь 1 1 0 0 0 0

Са$е2 1 0 1 1 0 0

СавеЗ 1 0 0 0 0 1

Са«е4а 0 1 1 0 1 0

Саяе4Ь 0 1 0 0 1 0

Саяс5а 0 0 1 0 0 0

СаиебЬ 0 0 0 0 0 1

Кис можно заметить из та£л. 2, пары выражений са;е*а и сазе*Ь дают одинаковые тройки зн ачений переменных X* тс лько в одном случае - са5е4, а не во все> трех (отлития выделены в табл. 2 полужирным шрифтом), к< к это предпола1 алось при отсутствии вь.числения у (10,13,14), пр «ем для саэгИэ и са8е5а все переменные X* принимают значение 0. Обратившись к графичесюй модели артефакта рис. 4, находим соответствие: выракения савеИэ и :аве5а (16, Л) описываот именно те пути, исголнение которых невозмож 10, а значит, при последующем формировании :~екста программы именно в этой логической структуре возникнет «мертвый кед».

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

1Уетод основывается на детальном анализе ЦМЬ-диагэамм действий бизнес-процессов организации-заказчика програмл-ного продукта (как поставщика основных функциональные требований) и бизнес-логики яртеоакта РХТР пссредстпо л построен ия комплексных, кубических покрытг.й. Суть метода заключается в последовательном выполнение нескольких аналитических задач:

• выделения логической структуры артефактг 1ШР;

• иссле; ювания его J готических связей;

• преоб эазования ар гефакта в гр; 1фо-аналити" гескую моде. 1ь;

• форм1 [рования ко 8. ллексного к; гбического с окрытия;

• выявл ения основн] >к показател ей наличия <• мертвого ко, 1а».

В первом разделе описан метод выделения логической структуры артефа<та RUP и исследования его логических связей и путей. В качеств«: основного объекта для дальнейшего анализа из общей UML-модели бизнес-процесса или бизнес-логики приложения (в загисимости от этапа разработки) выдел гется диаграмма деятельности (Activity diagram), как основ -юй инструмент преобр *зования и? формационных потоков.

Во втором раздел'? построена схема преобраз звания логической структуры артефакта RUP в графо-аналитическую модель и формирования h i ее основе комплексного кубичес<ого покрьг-ия.

Элементы диаграммы деятельности предстг вляются в форме графо-нналитичесгой модели: задачи (task) преобразуются в линейные вершш ы, точки принятия решений (decision) - в условные, а переходы между рими и точки слияния '"merge) обозначаются дугами (рис. .

1

-х

UML

ГАМ

Task

Линеш гая вершила

P/ic.6 Преобразование имЬдиафаммы действий зГАМ

По;ле формирования графо-анали-ической модели на ее основе строится упрсщенное. комплексное кубическое покрытие (без учета фун<ций передачи управлгния) с построением ьубов для всех вариантов прохожден1я условны:!; вершин.

В третьем ргзделе предложен метод выявления основных показателей наличия «мертвого кода» в проектируемом программном продукте.

Наличие предпосылок к далы-ейшему формировав ию «мертвого кода» определяется по значения« выходные переменных: если все оулевы переменные ни выходе дают значете false, тэ в логической структуре исследуемого артефакта присутствуют несогласо!анные условия, а значит и возникают неисполняемые пути.

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

В первом разделе определяете! область примене-шя предложенного в третьей главе метода.

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

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

«Мертвый код» - это неисполняемый участок программы, а

значит, что при тестировании традиционными методами он не может

»

быть обнаружен, а при функционировании программного продукта в штатном режиме, он не будет влиять на результат его работы.

Рассмотрим такую ситуацию: в исследуемом нами случае (раздел 2.2) оговорено, что переменные xl,x2, хЗ не равны'между собой (1-3), но рассматриваемый нами модуль получает их из вне (от оператора или из другого модуля, предполагающего проверь условий неравенства). Допустим, оператор ошибся или в модуле, поставляющем эти переменные, подобная проверка была устранена. Также предложим отличную от используемой нами (6) формулу задания значения переменной у и обозначим ее зау': y'=tme:x3<xl (23)

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

Casela': а=true & Р=true & у' = trae Al =false, А2 = false, A3=false (24) Caselb': a=to¡e&P=tme&y'= falseA1 = trae, A2 = false, A3 = felse (25) Case2': а=tiiie & |3 = felse & y'= true->A1=ase, A2 = ase, A3 = true (26) Case3': а=true & P=false & y' =false ~>A1 =true, A2=false, A3 = false (27) Case4a': а=false & p=trae & у' = true -»A1 = ase, A2 = trae, A3 =ase (28) Case4b':a=false&p=trae&y'=false -> A1 = false, A2 = true, A3 = felse (29) Case5a':a=false&P=ase&y'=true->A1 =false,A2 = false, A3=true (30) Case5b': a=false & P = ase & y= ase A1 = true, A2=trae, A3 = true (31) Точно также, как и в рассмотренном ранее примере, здесь возникают 2 некорректных пуга: casela' и case5b' (24,31), однако, если все 3 неравенства (1-3) не были выполнены, то в случае case5b' (31) это уже не будет «мертвым кодом», так как данный путь все же сможет бьггь исполнен, хоть эта возможность и не была ранее описана. А значит в исследуемом артефакте уже на уровне бизнес-модели появится программная закладка.

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

В третьем разделе приводятся оценка ожидаемого объема «мертвого кода» в зависимости от роста сложности программного продукта, проектируемого промышленным способом.

Появление «мертвого кода» в тексте программы:

• запутывает программистов и системных аналитиков;

• значительно увеличивает объем кода и объем используемой оперативной памяти;

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

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

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

относительно того, если бы программа была написана без их использования (что в наше время практически неприемлемо, так как сильно увеличивает время разработки).

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

уровня

Язык высокого

Шаблоны

совмещении шаблонов

Машинно-ориентированный ^ язык

вследствие трансляции

Избыточность

Двоичные коды

Избыточность вследствие трансляции

Объем кода

Рис. 7. Усложнение исходного кода при переходе на более высокий уровень программирования

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

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

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

снизить риск возникновения уязвимостей.

В приложении приведены примеры работы с иМ Ь-диаграммами.

Список публикаций по теме диссертации

1. Торшенко Ю.А. Проект учебно-методического комплекса оценки рисков информационной безопасности // Научно-технический вестник СПбГУ ИТМО № 39: Исследования в области информационных технологий. Труды молодых ученых. 2007 г., Санкт-Петербург, сс. 73-76.

2. Торшенко Ю.А., Осовецкий Л.Г Моделирование системы управления информационной безопасностью - XI научно-практическая конференция «Теория и технология программирования и защиты информации» 18 мая 2007 г., Санкт-Петербург - Сборник научных трудов, сс. 24-25.

3. Торшенко Ю.А. Угроза появления вирусов и НДВ в приложениях разработанных программно // научно-техническая конференция «День антивирусной безопасности» 22 октября 2007 г., Санкт-Пеггербург -Сборник научных трудов, с. 28.

4. Торшенко Ю.А. Источники "мертвого кода" при использовании технологии IBM Rational // Научно-технический вестник СПбГУ ИТМО № 46: Исследования в области информационных технологий. Труды молодых ученых. 2008 г., Санкт-Петербург.

5. Торшенко Ю.А. Методика поиска «мертвого кода» в приложениях, созданных программно // ХП научно-практическая конференция «Теория и технология программирования и защиты информации» 15-16 мая 2008 г., Санкт-Петербург - Сборник научных трудов, сс. 47-49.

6. Торшенко Ю.А., Ендовский А. С. Методические разработки по IBM Rational Application Developer // XI научно-практическая конференция «Теория и технология программирования и защиты информации» 15-16 мая 2008 г., Санкт-Петербург - Сборник научных трудов, сс. 149-152.

7. Сидоров А. О., Торшенко Ю. А., Павлютеиков А. А., Осовецкий JI. Г. Разработка методики структурированной оценки риска //Научно-технический вестник СПбГУ ИТМО № 55 2008 г., Санкт-Петербург.

8. Торшенко Ю.А., Шубин Ю. М, Осовецкий JL Г. Обнаружение уязвимостей на начальных этапах проектирования программного продукта // Научно-технический вестник СПбГУ ИТМО № 55 2008 г., Санкт-Петербург.

Тиражирование и брошюровка выполнены в Центре "Университетские Телекоммуникации". Санкт-Петербург, Кронверкский пр., 49. Тел. (812) 233-46-69. Лицензия ЦДЛ №69-182 от 26.11.96 Тираж 100 экз.

ВВЕДЕНИЕ.

ГЛАВА 1. ОБЗОР^УЯЗВИМОСТЕЙ ПРОГРАММНЫХ ПРОДУКТОВ ТЕХНОЛОГИИ ПРОМЫШЛЕННОГО ПРОЕКТИРОВАНИЯ.

1.1 Современное состояние рынка функционального программного обеспечения.'.!.

1.2 Развитие программной инженерии.

1.3 Уязвимости CASE-проектирования.

1.4 Применение комплексных методологий для снижения уязвимости программного продукта на примере Rational Unified Process.

ГЛАВА 2. МОДЕЛЬ ОБНАРУЖЕНИЯ НЕИСПОЛНЯЕМЫХ ПУТЕЙ НА НАЧАЛЬНЫХ ЭТАПАХ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ПРОДУКТА.

2.1 Проблема «мертвого кода» в логической структуре требований.

2.2 Использование графо-аналитической модели структуры артефакта для построения комплексного кубического покрытия.

2.3 Результаты функционирования модели.

Актуальность темы

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

Цели и задачи диссертации

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

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

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

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

Объект исследования

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

Предмет исследования

Предметом исследования является технология промышленного проектирования программного обеспечения, а в частности средства поддержки начальных этапов проектирования, такие как продукты компании IBM из линеек Rational и WebSphere, входящие в общую методологию средств создания программного продукта IBM Rational Unified Process.

Методы исследования

Для решения поставленных задач были использованы методы математической логики, моделирования и графо-аналитические методы.

Научная новизна

В данной работе исследована и проанализирована проблема уязвимости «мертвого кода» на начальных этапах промышленного проектирования программного продукта, на базе методологии Rational Unified Process компании IBM.

Практическая ценность

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

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

Структура работы

Диссертация состоит из введения, четырех глав, заключения и списка литературы.

ЗАКЛЮЧЕНИЕ

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

В процессе исследования были достигнуты следующие результаты:

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

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

3. Разработана методика снижения количества уязвимостей в конечном программном продукте.

4. Предложен метод обнаружения предпосылок к возникновению «мертвого кода» на стадиях проектирования, предшествующих формированию программного кода.

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

1. Адлер Ю. П., Хунузиди Е. И., Шпер В. JL. Методы постоянного совершенствования сквозь призму цикла Шухарта-Деминга // Методы менеджмента качества — №3 2005 г.

2. Анин Б. Ю. Защита компьютерной информации — СПб: БХВ-Петербург, 2000 г. 384 стр.

3. Биберштейн Н., Боуз С., Джонс К. и др. Компас в мире сервис-ориентированной архитектуры (SOA) М: Кудиц-Пресс, 2007 г. — 256 стр.

4. Боггс М., Боггс У. UML и Rational Rose 2002 М.: Лори, 2004 г. -528 стр.

5. Брукс Ф. Мифический человеко-месяц или как создаются программные системы СПб: Символ-Плюс, 2000 г. 304 стр.

6. Вендров А. М. CASE-технологии. Современные методы и средства проектирования информационных систем М.: Финансы и статистика, 1998г.- 146 стр.

7. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. М.: «Финансы и статистика», 2005. - 544 стр.

8. Вендров A.M. Case-технологии Современные методы и средства проектирования информационных систем. — М.: «Финансы и статистика», 1998. — 176 стр.

9. Гиббс Р.Д. Управление проектами с помощью IBM Rational Unified Process: практические советы — М: Кудиц-Пресс, 2007 г. 304 стр.

10. ГОСТ 34.003-90 Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Термины и определения.

11. ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств.

12. Громов Г. Р. От гиперкниги к гипермозгу: информационные технологии эпохи Интернета. Эссе, диалоги, очерки — М.: «Радио и связь», 2004 г. 208 стр.

13. Ефимов Г. Жизненный цикл информационных систем // журнал СЕТЕВОЙ №2 2001г.

14. Зыков А.Г., Немолочнов О.Ф., Осовецкий Л.Г., Петров К.В., Поляков В.И. Методы тестирования вычислительных процессов — СПб: Научно-технический вестник СПбГУ ИТМО № 45 2007 г., сс. 121-125

15. Игнатьев М. Б., Фильчаков В. В., Осовецкий JI. Г. Активные методы обеспечения надежности алгоритмов и программ СПб: Политехника, 1992 г.-288 стр.

16. Инновационные решения IBM — М. IBM Восточная Европа/Азия, 2006 г. 368 стр.

17. Йордон Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте М.: Лори, 2001 г. — 264 стр.

18. Крачтен Ф. Введение в Rational Unified Process (2-е издание) М.: Вильяме, 2002 г. 240 стр.

19. Крачтен Ф., Кролл П. Rational Unified Process — это легко. Руководство по RUP для практиков М.: Кудиц-Образ, 2004 г. 432 стр.

20. Круз Р. Л. Структуры данных и проектирование программ М.: Бином. Лаборатория знаний, 2008 г. — 768 стр.

21. Ларман К. Применение UML 2.0 и шаблонов проектирования Киев: Вильяме, 2006 г. — 736 стр.

22. Леоненков А. Самоучитель UML 2 СПб: БХВ-Петербург, 2007 г. -576 стр.

23. Липаев В. В. Технико-экономическое обоснование проектов сложных программных средств М.: СИНТЕГ, 2004 г. — 284 стр.

24. Липаев В. В. Экономика производства сложных программных продуктов М.: СИНТЕГ, 2008 г. 432 стр.

25. Липаев В. В., Серебровский Л. А., Коганов П. Г. и др. Технология проектирования комплексов программ АСУ/В. под ред. Асафьева Ю. В., Липаева В. В. М.: Радио и связь, 1983 г. - 264 стр.

26. Липаев В.В. Качество программного обеспечения. М.: Финансы и статистика, 1983. - 263 с.

27. Липаев В.В. Системное проектирование сложных программных средств для информационных систем. Издание второе, переработанное и дополненное. М.: СИНТЕГ, 2002. - 268 стр.

28. Макконнелл С. Профессиональная разработка программного обеспечения СПб: Символ-Плюс, 2007 г. 240 стр.

29. Международный стандарт ISO/IEC 14102:1995 Информационные технологии. Руководство по оцениванию и выбору инструментальных CASE-средств.

30. Немолочнов О. Ф. Интеграционно-рекурсивная модель как средство анализа риска вирусоопасных машинных кодов// Труды 10-й международной конференции «Теория и технология программирования и защиты информации» СПб: СпбГУ ИТМО, 2006 г. стр. 7-8

31. Нив Г.Р. Пространство доктора Деминга. — М.: МГИЭТ (ТУ), 1996 г.

32. Новичков А. Эффективная разработка программного обеспечения с использованием технологий и инструментов компании RATIONAL — Interface Ltd., 2000 г. код доступа: www.interface.ru

33. Палистрант Дж., Кватрани Т. Визуальное моделирование с помощью IBM Rational Software Arhitect и UML M.: Кудиц-Образ, 2007 г. -192 стр.35.