Процессы разработки безопасного программного обеспечения

Реферат отчета участников форума National Cybersecurity Summit

В декабре 2003 года в Санта-Кларе состоялся форум National Cybersecurity Summit. Участники форума — представители компаний отрасли, академических институтов и министерства национальной безопасности США — сформировали пять рабочих групп. Каждой из них было поручено заниматься определенной темой. В статье отражены ключевые рекомендации, сформулированные коллективом Software Process, который входил в состав рабочей группы Security Across the Software Development Lifecycle («Безопасность в жизненном цикле разработки программного обеспечения»).

При создании безопасного программного обеспечения необходимо учитывать множество факторов, связанных с процессами его проектирования, обеспечением защиты и с организацией управления. Разработка начинается с определения наилучших методов проектирования, дополняется хорошо зарекомендовавшими себя техническими подходами и подкрепляется управленческой практикой, способствующей удачному завершению процесса создания безопасного программного обеспечения. Группа Security Across the Software Development Lifecycle не рассматривает проблемы физической защиты, безопасного ведения операций, организации связей и взаимодействия, контроля за оборудованием и вопросы защиты, связанные с персоналом, однако охватывает огромное количество уязвимых мест современного программного обеспечения. Ознакомиться с данной тематикой подробнее можно, изучив полный вариант отчета [1].

Постановка задачи

По данным Computer Emergency Readiness Team Coordination Center (CERT/CC), с 1998-го по 2002 годы число инцидентов, связанных с вопросами безопасности, увеличилось на 2099%. Их ежегодный прирост составил в среднем 116%. Только на протяжении 2003 года зарегистрировано 137529 таких случаев, тогда как годом ранее их было 82 094 (см. рисунок). Большинство инцидентов возникло из-за наличия в программах уязвимых мест, которые стали причинами нарушения целостности критически важной инфраструктуры, систем ведения бизнеса и обеспечения безопасности.

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

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

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

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

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

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

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

В Microsoft обнаружили, что около половины всех проблем, связанных с безопасностью программ, обусловлены недостатками проектирования [2]. А чтобы устранить последние, необходим высококвалифицированный персонал, обладающий большим опытом работы в области проектирования и обеспечения безопасности. Для использования рассмотренных в отчете подходов многим организациям недостает сотрудников с хорошими математической подготовкой, навыками проектирования программного обеспечения, средств защиты и написания сложных программ. Прежде чем приступить к созданию чего-то нового, нужно тщательно проработать процедуры проектирования и решить вопросы, связанные с квалификацией персонала.

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

Методы разработки

Многие уязвимые места появляются вследствие ошибок, которые непреднамеренно возникают при проектировании и разработке программного обеспечения. Согласно анализу, выполненному специалистами CERT/CC, появление большинства уязвимых мест обусловлено общими причинами (10 таких причин порождают около 75% всех «брешей»), причем источниками более 90% уязвимых мест являются известные типы дефектов. Мы трактуем понятие «дефект» шире, относя к ним все то, что обуславливает необходимость каких-либо изменений продукта (вне зависимости от того, связано ли это с несоответствием требованиям, неудачными конструкторскими решениями, недостаточным уровнем безопасности и удобства использования или с ошибками кодирования).

При использовании сегодняшних технологий разработки на каждую тысячу строк нового или измененного кода приходится, как правило, от 1 до 7 дефектов. В типичных современных системах, содержащих миллионы строк кода, имеются тысячи дефектов [3]. Естественно, такое программное обеспечение редко гарантирует безопасность. Для создания действительно безопасного программного обеспечения организациям необходимо сократить на один-два порядка число дефектов в спецификациях, ошибок при проектировании и реализации.

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

Коллективное проектирование

Процесс коллективного проектирования программного обеспечения (Team Software Process, TSP) был определен специалистами института Software Engineering Institute (SEI), созданного при университете Карнеги-Меллона. Данный процесс представляет собой использование при коллективной разработке определенного набора операций. В настоящее время процесс TSP задействуется достаточно широко. Проведенное недавно исследование 20 проектов в 13 организациях показало, что применяющие его команды выпускают программное обеспечение, в котором имеются около 0,06 дефектов проектирования и реализации на каждую тысячу строк нового и измененного кода. Сроки выпуска этих продуктов по сравнению с намеченными увеличиваются в среднем на 6%. Такой результат весьма неплох, если учесть, что более половины программных проектов завершаются неудачей, либо на их реализацию уходит минимум вдвое больше времени, чем планировалось [3].

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

Структурная корректность

Формальные методы представляют собой математически обоснованные подходы к созданию программного обеспечения. При этом математические модели и формальная логика используются для поддержки строгих программных спецификаций, корректного проектирования, кодирования и контроля качеством. Один из таких способов — обеспечения структурной корректности (Correctness-by-Construction) — был предложен компанией Praxis Critical Systems [4]. Он позволяет с помощью формальных методов проверять программное обеспечение и своевременно устранять в нем дефекты на протяжении его жизненного цикла.

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

Использование метода структурной корректности позволило с 1992-го по 2003 годы завершить пять проектов почти без дефектов: на 1 тыс. строк кода пришлось 0,04-0,75 ошибок. Надо сказать, в двух из этих проектов к системе безопасности предъявлялись весьма серьезные требования.

«Стерильная комната»

Проектирование программного обеспечения методом «стерильной комнаты» (он назван по аналогии с высокоточным проектированием стерильных комнат, предназначенных для производства аппаратуры) представляет собой теоретически обоснованный, ориентированный на командную разработку процесс создания и сертификации корректных программных систем со статистическим контролем качества [5-7]. Данный процесс охватывает весь жизненный цикл разработки, включая управление проектом в ходе итерационного проектирования, определение спецификаций функций и архитектуры, проверку правильности функционала, а также статистическое тестирование при сертификации программ на пригодность к использованию. Роли сотрудников, которые выполняют соответствующие проекты, распределяются так: отдельные коллективы занимаются определением спецификаций, непосредственно разработкой и сертификацией. Проектирование методом «стерильной комнаты» предусматривает статистический контроль качества в ходе разработки, который осуществляется путем последовательного отделения процедуры проектирования от процедуры статистического тестирования.

Многие проекты, основанные на методе «стерильной комнаты», связаны с секретными сведениями и не фигурируют в общедоступных отчетах. Однако опыт показывает, что общее число ошибок в данных случаях — примерно 0,1 дефекта на 1 тыс. строк для приложения, полностью соответствующего принципам «стерильной комнаты», и 0,4 ошибки для приложения с частичным соответствием. Большинство дефектов в программном обеспечении, построенном с использованием метода «стерильной комнаты», относится к ошибкам кодирования. Проблемы, связанные со спецификациями и архитектурой, встречаются гораздо реже.

Процессные модели

Процессные модели содержат определения целей и ключевые атрибуты конкретных процессов (например, построения системы безопасности), но не включают в себя практических руководств по определению и реализации процессов. Среди наиболее известных моделей совершенствования процессов можно выделить модель Capability Maturity Model (CMM), отражающую зависимость возможностей системы от ее зрелости. Хотя об отказе от оценки продукта или сертификации системы речь не идет, методы CMM можно использовать для общей оценки эффективности работы организации (в зависимости от определенных в модели критериев) и поиска путей ее повышения. Практика свидетельствует, что применение процессных моделей для улучшения качества программного обеспечения позволяет существенно сократить количество дефектов архитектуры и реализации в конечных продуктах [8, 9].

Для повышения уровня безопасности используются три разновидности CMM.

• CMM Integration (CMMI) помогает организациям совершенствовать процессы, связанные с проектированием систем, разработкой программного обеспечения, созданием интегрированных продуктов и процессов, организацией взаимодействия с поставщиками, управления процессами и проектами (www.sei.cmu.edu).
• Integrated CMM (iCMM) представляет собой единую модель, обобщающую передовой опыт совершенствования процессов в масштабе всего предприятия, включая управление аутсорсингом и взаимоотношениями с поставщиками. Широко применяется Федеральным управлением гражданской авиации США (www.faa.gov/ipg).
• Systems Security Engineering CMM (SSE-CMM) предназначена для определения требований к реализации компонентов защиты в программных системах, которые разрабатываются в интересах ИТ-отрасли (www.sse-cmm.org). Модель SSE-CMM является стандартом ISO (ISO/IEC 21827:2002).

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

Технические решения

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

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

Принципы проектирования безопасного программного обеспечения

Конечно, для создания безопасного программного обеспечения недостаточно лишь соблюдения принципов, но они способны помочь определиться с методами разработки. Восемь принципов разработки, сформулированные еще в 1974 году [10], сегодня отнюдь не менее актуальны:

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

Более поздние работы [11, 12], а также документы Open Web Application Security Project (www.owasp.org) базируются на тех же основных принципах, успешно выдержавших испытание временем.

Руководства разработчиков и контрольные ведомости

Выстраивая свою деятельность на основе указанных основных принципов, разные организации (от Microsoft до SAP) взяли на вооружение несколько универсальных руководств, в подготовке которых принимала участие и группа OWASP. В процессе создания безопасного программного обеспечения разработчики должны:

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

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

Моделирование угроз

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

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

Шаблоны атак

В [13] выделено 49 шаблонов атак. Эти сведения могут оказаться весьма полезными в ходе проектирования, реализации и тестирования программного обеспечения. Имеет смысл использовать данные шаблоны для выявления потенциальных дефектов в системах безопасности организаций.

Языки программирования

Выбор языка программирования также может оказать существенное влияние на безопасность конечного продукта. Лучшими языками являются те, в которых все действия определены и обоснованы, поддерживаются функции, уменьшающие число ошибок (например, требуется строгое определение типов), осуществляется контроль за распределением памяти и использованием указателей. Еще лучше задействовать языки, прошедшие официальную проверку (например, язык SPARK, являющийся подмножеством Ada, и соответствующие инструментальные средства проверки [14]). Языки C и С++ имеют ряд унаследованных свойств, которые могут оказаться источниками появления уязвимых мест в системе безопасности. Для разработки безопасного программного обеспечения больше подойдут языки типа Java и C#, хотя можно найти вариант и получше.

Инструментарий

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

Инструментальные средства типа Prefast (анализ исходного кода внутри процедур), Prefix (масштабируемый, учитывающий порядок выполнения инструкций анализа исходного кода) [15], а также Software, Languages, Analysis and Modelchecking (SLAM) помогают Microsoft уменьшить число дефектов в программных продуктах. По словам представителей корпорации, применение Prefix и Prefast позволило выявить около 17% всех ошибок, обнаруженных в Microsoft SQL Server 2003 [16]. Обнадеживающие результаты дал проект Fluid. Еще одним инструментальным средством, которое может быть использовано при разработке, является инструментарий Jackpot корпорации Sun Microsystems. В 2004 году ожидается появление еще нескольких средств, созданных на базе технологий компилятора.

Тестирование

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

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

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

Управление рисками

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

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

Методы управления

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

Прежде всего, управление предполагает установку конкретных, измеримых целей — например, уменьшить число уязвимых мест в программных продуктах на 50% (это можно оценить путем подсчета количества выпущенных «заплаток» или отчетов об уязвимых местах). Управление должно ориентироваться на приоритет вопросов обеспечения безопасности, причем не только на организационном уровне, но и на уровне проекта. Некоторые организации уже добились определенных успехов в определении ролей инженера по безопасности, аналитика в области безопасности и архитектора систем безопасности. Модель TSP-Secure, к примеру, предусматривает определение роли менеджера проекта по безопасности. На разных этапах жизненного цикла программного обеспечения ответственность будет перераспределяться, но менеджер по безопасности всегда сосредоточен на вопросах защиты — даже если на протяжении этого цикла исполнители соответствующих обязанностей меняются.

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

Другие факторы

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

Рекомендации

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

Рекомендации на ближайшую перспективу

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

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

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

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

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

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

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

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

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

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

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

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

• стимулировать любого разработчика (будь то поставщик коммерческих продуктов, организация, создающая программы для собственных нужд, или разработчик программ с открытым кодом), как можно быстрее внедрять процессы, которые позволяют создавать программное обеспечение, практически не имеющее дефектов как в спецификациях, так и в архитектуре и реализации;
• стимулировать организации, занимающиеся разработкой программного обеспечения, использовать передовой опыт создания систем безопасности на всем протяжении проектирования;
• требовать от организаций, выпускающих программное обеспечение со значительным числом ежегодно обнаруживаемых уязвимых мест, прибегать к тестированию, которое позволит контролировать ситуацию;
• попросить организации, располагающие соответствующими данными, совместно с группой CERT или другими органами, например с центром Information Technology Information Sharing and Analysis Center (IT-ISAC), заняться поиском конструктивных вариантов, которые помогут точнее определять уязвимые места продукта после его официального выпуска.

Рекомендации на среднесрочную перспективу

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

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

Рекомендации на долгосрочный период

В долгосрочной перспективе группа рекомендует выполнять следующие правила.

Сертификация. В определенной степени программы сертификации (в частности, Common Criteria и ITSEC) ориентированы на проверку уже существующего программного обеспечения. Пятый, шестой и седьмой уровни программы Common Criteria направлены на то, чтобы показать, что конструктивные решения отвечают требованиям к защите. В них даже предусмотрена проверка использования при разработке методов, обеспечивающих создание программного обеспечения с минимальным количеством дефектов. На практике, однако, эти уровни используются достаточно редко, а число инцидентов, связанных с безопасностью, по-прежнему имеет тенденцию к росту. Государству необходимо следить за разработкой программ контроля и анализа, рекомендованных в данном отчете, оценивать их качество, а также инициировать сертификацию процессов и методов, которые доказали свою высокую эффективность при создании безопасного программного обеспечения.

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

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

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

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

Хотя ассоциация National Cyber Security Partnership и не поддерживает формальных отношений с Министерством национальной безопасности США, на конференции, прошедшей в декабре 2003 года, глава министерства Том Ридж призвал членов ассоциации к действию. В министерстве положительно оценили рекомендации и приступили к рассмотрению инициатив, которым может быть оказана поддержка. В обозримом будущем ассоциация собирается и по-прежнему продвигаться в том же направлении. Некоторые рекомендации уже приняты и выполнены, имеет смысл разобраться с остальными и сформировать новые рабочие группы. Создание ассоциации позволило добиться весьма высоких результатов в деле продвижения технологии и в привлечении экспертов по формированию политик из самых разных организаций. Поддержанию эффективности партнерских отношений и достижению соглашений, как и раньше, будет уделяться самое серьезное внимание.

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

Литература

1. S.T. Redwine, N. Davis. Processes to Produce Secure Software, Nat'l Cybersecurity Partnership Task Force Report, 2004; www.cyberpartnership.org/init-soft.html.
2. G.E. McGraw. DIMACS Workshop on Software Security, IEEE Security & Privacy, vol. 1, no. 2, 2003.
3. N. Davis, J. Mullaney. The Team Software Process in Practice: A Summary of Recent Results, tech. report CMU/SEI-2003-TR-014, Software Eng. Inst., Carnegie Mellon Univ., September 2003.
4. A. Hall, R. Chapman. Correctness by Construction: Developing a Commercial Secure System. IEEE Software, vol. 19, no. 1, 2002.
5. R. Linger, S. Powell. Developing Secure Software with Cleanroom Software Engineering. Cybersecurity Summit Task Force Subgroup on Software Process, February 2004.
6. H. Mills, R. Linger. Cleanroom Software Engineering. Encyclopedia of Software Engineering, 2nd ed., J.Marciniak, ed., John Wiley & Sons, 2002.
7. S. Prowell et al. Cleanroom Software Engineering: Technology and Process, Addison Wesley, 1999.
8. J. Herbsleb et al. Benefits of CMM-Based Software Process Improvement: Initial Results, tech. report CMU/SEI-94-TR-013, Software Engineering Institute, Carnegie Mellon University, 1994.
9. D.R. Goldenson, D.L. Gibson. Demonstrating the Impact and Benefits of CMMI, special report CMU/SEI-2003-SR-009, Software Eng. Inst., Carnegie Mellon Univ., 2003.
10. J. Saltzer, M. Schroeder. The Protection of Information in Computer Systems. Proc. IEEE, vol. 63, no. 9, 1975.
11. P. Neumann. Principles Assuredly Trustworthy Composable Architectures: Emerging Draft of the Final Report, tech. report for SRI Project 11459, as part of DARPA's Composable High-Assurance Trustworthy Systems (CHATS) programs, to be published Sept. 2004.
12. J. Viega, G. McGraw. Building Secure Software: How to Avoid Security Problems the Right Way, Addison Wesley, 2001.
13. G. Hoglund and G. McGraw. Exploiting Software: How to Break Code, Addison-Wesley, 2004.
14. J. Barnes. High Integrity Software: The SPARK Approach to Safety and Security, Addison Wesley, 2003.
15. W.R. Bush, J.D. Pincus, D.J. Siela. A Static Analyzer for Finding Dynamic Programming Errors. Software Practice and Experience, vol. 30, June 2000.
16. S.J. Vaughn. Building Better Software with Better Tools. Computer, vol. 36, no. 9, September 2003.

Noopur Davis, Watts Humphrey, Samuel Redwine, Gerlinde Zibulski, Gary Mcgraw, Processes for Producing Secure Software. Summary of US National Cybersecurity Summit Subgroup Report. IEEE Security & Privacy, May/June 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.