CC BY
23
БЕЗОПАСНОСТЬ И ПРОТИВОДЕЙСТВИЕ ТЕРРОРИЗМУ. ЗАЩИТА ИНФОРМАЦИИ
ИСТОЧНИКИ «МЕРТВОГО КОДА» ПРИ ИСПОЛЬЗОВАНИИ ТЕХНОЛОГИИ IBM RATIONAL Ю.А. Торшенко Научный руководитель - д.т.н., профессор Л.Г. Осовецкий
Цель работы - определить, каким образом, и на каком этапе проектирования появляются уязвимости типа неиспользуемого «мертвого кода», к каким последствиям может привести их реализация и какими методами можно не допустить их появление. В статье рассмотрены методы, позволяющие диагностировать появление «мертвого кода» и «вычистить» исходный код приложения от уязвимостей подобного характера.
Введение
На сегодняшний день для разработки приложений масштаба предприятия в короткие сроки все чаще применяются многофункциональные программные среды, построенные на базе CASE-технологий. Использование данного инструментария позволяет ускорить и облегчить процесс разработки, однако привносит с собой в исходный код новые уязвимости, связанные с появлением неиспользуемого «мертвого кода».
К причинам, приведшим к подобному положению, можно отнести частое изменение и недостаточно четкую формулировку требований по безопасности к программному обеспечению (ПО) как со стороны заказчика, так и со стороны руководителей проекта, нехватку ресурсов (в первую очередь временных) и т.п. Таким образом, ощущается острая необходимость в детальном анализе и регулировании всего процесса разработки ПО с точки зрения обеспечения его безопасности в процессе создания и разработки.
Потребность контролировать процесс разработки ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела еще в конце 70-х гг. к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия»(80Йжаге engineering) [1].
Понятие «программная инженерия» подразумевает, что сам процесс проектирования и создания ПО может являться объектом для исследования. Совершенствование методов проектирования, средств создания и систем контроля функциональности ПО поможет повысить качество вновь разрабатываемых информационных систем (ИС), увеличить их надежность и долговечность.
Уязвимости программного проектирования
Перечисленные выше проблемы породили потребность в программно-технологических средствах специального класса - CASE (Computer-Aided Software En-gineering)-средствах, реализующих CASE-технологию создания и сопровождения ПО ИС. В рамках программной инженерии CASE-средства представляют собой основную технологию, используемую для создания и эксплуатации систем ПО [2].
Под CASE-средством (согласно стандарту ISO/IEC 14102:1995) понимается программное средство, поддерживающее процессы жизненного цикла ПО, включая анализ требований к системе, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, управление конфигурацией
ПО и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют среду разработки ПО. В результате при использовании данных технологий количество ролей персоналий, задействованных в разработке ИС, в целом возросло и приняло следующий вид: автор исходной задачи, системный аналитик, системный аналитик-программист, прикладной программист и системный программист [3].
Таким образом, весь процесс проектирования с использованием CASE-технологии можно схематично представить в виде последовательности действий, выполняемых различными персоналиями (см. рис. 1)
Постановка задачи
Неточности преобразования
Формирование требований
Неточности преобразования
Разработка логической структуры
Неточности преобразования
Формирование кода
Рис. 1. Этапы проектирования приложения
Каждый из этапов данного процесса выполняется собственным исполнителем (или исполнителями) на подходящем для данной конкретной цели описательном языке, отсюда возникают проблемы, связанные с переходом от одного этапа проектирования к следующему. Интуитивно понятные для одного человека инструкции могут быть неверно истолкованы следующим участником разработки. Как следствие, возникают ошибки, связанные с неточностями преобразования моделей одного уровня в модели другого. А поскольку конечный продукт проходит как минимум три таких преобразования, вероятность появления подобных ошибок чрезвычайно велика. Их наличие в процессе производства ПО может повлиять не только на функциональность продукта, но и на его надежность, так как при возникновении подобных ошибок появляются уязвимости, связанные с тупиковыми технологическими процессами и, как следствие, с избыточностью конечного кода программы.
Методология Rational Unified Process
Одним из наиболее успешных примеров комплексной реализации CASE-технологии можно назвать серию программных продуктов компании IBM, объединенную в методологию Rational Unified Process (RUP). Методология RUP позволяет объединить проектную команду, предоставляя в ее распоряжение проверенные мировой практикой лучшие подходы к разработке ИС. К ним относятся такие процессы жизненного цикла создания ПО, как управление проектами, бизнес-моделирование, управле-
й
и
в
з
я
у
и к о б и
0
о а в т
ч и л о к е и н е ч и л е в
ние требованиями, анализ и проектирование, тестирование и контроль изменений. Внедрение КОР в организации способствует выработке качественных внутрикорпоративных стандартов и повышению общей культуры разработки [4].
Основа КОР - итеративный процесс разработки. В условиях активно развивающегося мирового бизнеса практически невозможно создавать современные сложные программные системы последовательно, т. е. сначала выявлять все проблемы, затем принимать проектные решения, потом формировать программное обеспечение и, наконец, проверять полученное изделие. Итеративный подход позволяет улучшать понимание проблем на основе последовательных усовершенствований и конкретизировать их в эффективных решениях. Этот подход обеспечивает большую гибкость при изменяющихся требованиях и тактических коррективах в бизнес-целях, что позволяет более эффективно и заблаговременно идентифицировать и снижать проектные риски. КОР -управляемый процесс. Итеративный подход предполагает управление требованиями и изменениями, чтобы между всеми участниками проекта обеспечивать единое понимание ожидаемых функциональных возможностей, требуемый уровень качества, наилучшее управление затратами и графиками выполнения работ [4].
о К л
н
¡а
к
«
о и эт К о Л
с
Шаблоны
Язык высокого уровня
Машинно-ориентированный язык
збыточность при совмещении шаблонов
Избыточность вследствие трансляции
Избыточность вследствие трансляции
Объем кода
Рис. 2. Усложнение исходного кода при переходе на более высокий уровень программирования
Применение комплексной методологии, такой как КиР, позволяет уменьшить риск возникновения описанных выше ошибок, связанных с неточностями преобразования моделей различного уровня. Однако на данном этапе могут появиться и новые уязвимости: различные элементы модели более высокого уровня преобразуются в элементы моделей более низких уровней программно при помощи заранее предопределенных функций, следовательно, при подобном преобразовании не могут быть учтены все случаи взаимодействия этих элементов друг с другом, что может вызвать за собой усложнение модели и увеличение кода проектируемого программного продукта вследствие повторения некоторых функций или появления ненужных, тупиковых путей развития бизнес-процессов.
Но не только проблемы перехода между моделями влияют на качество конечного программного продукта. Сам процесс непосредственного формирования кода программы нуждается в пристальном рассмотрении (см. рис. 2).
Пути поиска уязвимостей в процессе разработки ПО
На сегодняшний день текст программы формируется при помощи уже имеющихся у программиста шаблонов, библиотек функций, которые при сборке их в единое целое могут неожиданным образом могут повлиять на работу программы. Также использование подобных программных вставок может увеличить и усложнить код относительно того, если бы программа была написана без их использования (что в наше время практически неприемлемо, так как сильно увеличивает время разработки).
Еще одна проблема возникает при компиляции программы, когда компилятор транслирует стандартные функции языка высокого уровня (ЯВУ) в машинные коды. Конечно, каждая функция или оператор ЯВУ в большинстве случаев транслируются оптимальным образом, однако, как показывает практика, программа, написанная на ЯВУ, занимает больший объем памяти, так как совместное использование различных функций языка может отразиться на оптимальности уже откомпилированной программы. Вследствие компиляции могут появиться фрагменты «мертвого» (неисполняемого) кода. Наличие таких фрагментов приводит не только к увеличению кода, но и является значительной уязвимостью, так как увеличивает вероятность появления в данном ПО дефектов и облегчает проникновение в программу вирусов.
Чтобы обнаружить данные уязвимости, необходимо отслеживать процесс производства программного продукта, начиная с самого первого этапа проектирования - постановки требований. Действительно, грамотно сформулированные требования уже представляют собой некоторую логическую структуру будущей программы, а значит -могут быть представлены в виде графа логических взаимодействий. В подобной форме описываются и все промежуточные модели, и исходный код программы. Получив представления продуктов каждого этапа проектирования в идентичной форме, мы будем иметь возможность сравнивать их логику и проверять правильность преобразования моделей и трансляции кода на низкоуровневые языки.
Заключение
В настоящее время для качественной организации бизнес-процессов и обеспечения конкурентоспособности фирм и предприятий требуется все больше функционального ПО, создание которого происходит с использованием инструментально-технологических средств промышленного производства, примером которых является технология IBM Rational. Поэтому сейчас крайне важно уделять внимание решению проблем, связанных с появлением избыточного кода, неточностями преобразования моделей разного уровня, появляющихся в программных продуктах в процессе разработки.
Литература
1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика, 2005. - 544 с.
2. Вендров А.М. Case-технологии Современные методы и средства проектирования информационных систем. - М.: Финансы и статистика, 1998. - 176 с.
3. Громов Г.Р. От гиперкниги к гипермозгу: информационные технологии эпохи Интернета. Эссе, диалоги, очерки - М.: Радио и связь, 2004. - 208 с.
4. IBM Rational Software. Обзор продуктов и решений 2007. - М., 2007. - 92 с.
