Обнаружение уязвимостей на начальных этапах проектирования программного продукта Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.056.4

ОБНАРУЖЕНИЕ УЯЗВИМОСТЕЙ НА НАЧАЛЬНЫХ ЭТАПАХ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ПРОДУКТА Ю.А. Торшенко, Ю.М. Шубин, Л.Г. Осовецкий

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

Ключевые слова: мертвый код, промышленное проектирование, разработка программного обеспечения.

Введение

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

Уязвимости процесса разработки

Чтобы разработка завершилась успешно, необходимо уделять внимание всем этапам этого процесса, в первую очередь - процессам постановки задачи и системного анализа, так как выполненные в рамках этих этапов действия наиболее сильно влияют на качество всего проекта. Каждый из этапов процесса выполняется собственным исполнителем (или исполнителями) на подходящем для конкретной цели описательном языке, отсюда возникают проблемы, связанные с переходом от одного этапа проектирования к следующему. Интуитивно понятные для одного человека инструкции могут быть неверно истолкованы следующим участником разработки. Как следствие, возникают ошибки, связанные с неточностями преобразования моделей одного уровня в модели другого. Поскольку конечный продукт проходит как минимум три таких преобразования, вероятность появления подобных ошибок чрезвычайно велика. Их наличие может повлиять не только на функциональность продукта, но и на его надежность, так как при возникновении подобных ошибок появляются уязвимости, связанные с тупиковыми технологическими процессами, а следовательно, и с избыточностью конечного кода программы [2].

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

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

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

«Мертвый код» в бизнес-процессах

Однако проблема с возникновением участков «мертвого» кода может появиться не на этапе формирования кода, а значительно раньше, так как функциональные требования к ПО также образуют некую логическую структуру, а, значит, и здесь могут наблюдаться тупиковые пути исполнения модели [3] .

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

х1 х3 х2

х3

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

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

- персональные данные заказчика;

- кредитная история;

- выбор кредитной программы.

Для осуществления последнего действия необходимо выбрать минимальную ставку по кредиту. Рассмотрим ситуацию, когда выбор происходит из трех вариантов - А, В и С -параллельно другим процессам (структура проверки условий должна быть последовательной, чтобы это не повлияло на другие действия). Пусть А: х1 < х2, В: х2 < х3, а С: х1 < х3. Тогда при их последовательной проверке мы придем к тому, что в некоторых случаях существуют такие пути, прохождение которых невозможно в силу несогласованности условий (рис. 2).

Заключение

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

Литература

1. IBM Rational Software. Обзор продуктов и решений-2007. - М., 2007. - 92 с.

2. Торшенко Ю.А. Угроза появления вирусов и НДВ в приложениях, разработанных программно // Сб. трудов н.-т. конф. «День антивирусной безопасности». - СПб: СПбГУ ИТМО, 2007.

3. Торшенко Ю.А. Методика поиска мертвого кода в приложениях, разработанных программно // Сб. трудов н.-пр. конф. «Теория и технология программирования и защиты информации». - СПб: СПбГУ ИТМО, 2008.

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

Шубин Юрий Михайлович

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

— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, ulka@cit.ifmo.ru

— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, w59265@yandex.ru

— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, доктор технических наук, профессор, director@cit.ifmo.ru

УДК 004.056.4

МЕТОД ФОРМИРОВАНИЯ ПРОФИЛЯ ЗАЩИТЫ АВТОМАТИЗИРОВАННОЙ БАНКОВСКОЙ СИСТЕМЫ

Ю.М. Шубин, А.О. Сидоров, Л.Г. Осовецкий

Рассматривается формирование профиля защиты применительно к автоматизированным банковским системам.

Ключевые слова: профиль защиты, оценка риска, банковские системы.

Введение

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