БЕЗОПАСНОСТЬ
Избавляться от ошибок в кодах помогают две методики совместной работы
Деннис Фишер
Когда в безопасности коммерческой программы обнаруживается новая брешь, сразу же начинается поиск виновных. Крайним, как правило, оказывается разработчик или тестер. Первый допустил ошибку в исходном тексте, а второй не выполнил своей задачи - обнаруживать типичные ошибки наподобие переполнения буфера или неверного формата строк. Именно на этих людей обычно и возлагается вся ответственность, по крайней мере в общественном сознании.
Но специалисты в области безопасности и инженеры-программисты все чаще начинают оспаривать такое мнение, считая его устаревшим и недальновидным. Не отрицая вины разработчиков и тестеров, они подчеркивают, что те составляют лишь небольшое звено сложного процесса создания приложений. Основная же слабость, уверены эксперты, заключена в самом процессе, традиционно чреватом ошибками. Именно это приводит к выпуску некачественной продукции.
“Мы находимся в ужасной ситуации, которая все ухудшается. В общем и целом программное сообщество так и не научилось фундаментальным принципам управления качеством. Все ограничивается тестированием и исправлением найденных ошибок, - признается Уоттс Хамфри, научный сотрудник института программной инженерии при университете Карнеги - Меллона. - Проблема в том, что ошибки не мешают программам работать, но ослабляют их защиту. Продукт с дефектами просто не может быть безопасным”.
По мнению Хамфри, выпуску дефектных и слабо защищенных программных продуктов способствуют две вещи. Во-первых, при постановке задач и определении технических требований высшее начальство и руководители проектов продолжают обращать главное внимание на функциональность и удобство, а безопасность и надежность оказываются на втором плане. Даже сегодня мало найдется исполнительных директоров и менеджеров ИТ, которые при покупке ПО ставят вопросы защищенности во главу угла или хотя бы включают их в список основных требований. В результате производители действуют в привычном режиме и продолжают выпускать то, что пользовалось успехом в прошлом, - удобные, но слабо защищенные программы.
Вторая причина в том, что большинство разработчиков и инженеров-программистов слабо подготовлены (если подготовлены вообще) к созданию безопасных кодов и, как правило, полагаются на знания, полученные порой десятки лет назад, еще при обучении в колледже. Конечно, большинство, а то и все производители программных продуктов периодически направляют своих сотрудников на курсы повышения квалификации, но там редко учат новым технологиям. Слушатели зачастую лишь повторяют пройденное и закрепляют плохие привычки.
Пытаясь изменить сложившуюся ситуацию, Хамфри предложил две методики создания программного обеспечения: TSP (Team Software Process - совместная работа над ПО) и PSP (Personal Software Process - индивидуальная работа над ПО). Обе они призваны наладить процесс выпуска качественной продукции с сохранением цены и сроков.
“Сегодняшним планам не хватает управляющего графика, поэтому они просто неприемлемы, - отметил Хамфри. - Приходится передвигаться без ориентиров и вех, а в таких условиях группа будет занята проектом гораздо дольше, чем могла бы. Для совместного написания ПО необходим четкий план - он обеспечит выпуск качественной продукции с максимальной скоростью и эффективностью. Честно говоря, именно менеджер отвечает за то, чтобы проект начался вовремя. Если на выполнение проекта требуется 18 месяцев, а руководство выделяет только девять, понятно, что данный срок нереален. Поневоле задумываешься: где были эти руководители девять месяцев назад, когда нужно было приступать к работе?”
По оценкам Хамфри, даже у опытного программиста на каждые десять строк кода приходится одна ошибка - уровень совершенно неприемлемый. “Проделать брешь в программе способна и одна погрешность на тысячу строк”, - уверен он.
Предложенные им процессы уже применяются на некоторых крупных предприятиях. Microsoft, к примеру, использует их при разработке некоторых внутренних программ. Методики TSP и PSP уже помогли ей обновить одно из приложений, с помощью которого ПО передается производителям комплексных систем. Как рассказала старший программный менеджер корпорации Кэрол Гроджин, исходный текст этого приложения насчитывает свыше 24 тыс. строк и в нем при последней проверке было обнаружено около 350 ошибок. Благодаря применению методик института программной инженерии, надеется она, в новой версии их будет не больше 25. Столь впечатляющего повышения качества Гроджин рассчитывает достичь за счет определения единых ориентиров и задач на всех этапах процесса.
“Большинство ошибок в защите закладывается еще на стадии определения технических характеристик и проектирования”, - убеждена она.
Правда, несмотря на внутренний успех процессов TSP/PSP, применять их при разработке коммерческих приложений Microsoft пока не собирается.
Что же касается перспективы, то, как считают эксперты в области безопасности, ключом к надежной защите приложений является лучшая подготовка разработчиков и совершенствование подхода к программированию.
“Из года в год мы видим одни и те же бреши в системах защиты, - заявил Рик Петья, директор координационного центра CERT при университете Карнеги - Меллона. - Очень часто программы поставляются с крайне низким уровнем безопасности, и после установки их приходится срочно настраивать. Чтобы избежать этого, нужно шире применять анализ рисков и источников опасности, привлекать больше технических специалистов и повышать качество ПО”.
