Security Development Lifecycle

С ростом сложности современных технологий и окружения становится всё труднее разрабатывать приложения, обеспечивающие высокий уровень безопасности системы. Программные продукты, ИТ-системы и сети подвергаются постоянным атакам и угрозам, таким как вирусы, троянские программы, логические бомбы, сетевые черви, агенты и др^[2].

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

В процессе построения программного обеспечения с учётом безопасности участвуют не только разработчики, но также руководство, менеджеры проектов, бизнес-аналитики, специалисты по обеспечению качества, технические архитекторы, специалисты по безопасности, владельцы приложений^[2].

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

Разработка и внедрение SDL на всех этапах жизненного цикла разработки вносит существенный вклад в обеспечение безопасности создаваемых приложений, кардинально меняя подходы к разработке и тестированию программного обеспечения^[1]. Социальная значимость программных продуктов подчёркивает необходимость широкого внедрения SDL в отрасли^[2].

В отличие от методологии CLASP^[3], SDL более гибка и легко интегрируется в любой этап разработки^[2].

Российским аналогом SDL является стандарт ГОСТ Р 56939–2016, который не только содержит набор рекомендуемых практик для разработки программного обеспечения, но и даёт чёткие рекомендации по функциям и обязанностям всех участников процесса^[4].

Для обеспечения информационной безопасности программного обеспечения SDL предусматривает целый ряд руководящих принципов. Навыки и корректное включение заинтересованных сторон на каждом этапе имеют жизненно важное значение для итоговой защищённости продукта. К основным принципам относят^[5]:

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

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

Базовые курсы должны включать^[4]:

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

На этом этапе определяется и интегрируется спектр требований к безопасности и конфиденциальности^[4][5]:

• формулируются минимально приемлемые стандарты защищённости;
• проводится оценка рисков и нормативных требований с точки зрения затрат;
• определяются ответственные по безопасности и консультанты, составляется план внедрения требований, процедуры отслеживания и устранения уязвимостей;
• фиксируется порог брака по критичным ошибкам, связанным с безопасностью;
• все критерии должны быть детально проработаны заранее во избежание компромиссов по безопасности в процессе разработки;
• в ряде случаев требования определяет внешняя команда, например, в Microsoft это обеспечивает специализированная инициатива Secure Windows Initiative^[6].

Этап проектирования включает^[4][5]:

1. Установление требований к архитектуре с точки зрения безопасности и конфиденциальности, проектирование общей структуры, определение доверенных компонентов («доверенная вычислительная база»), выбор методов проектирования (например, строго типизированные языки, минимизация поверхности атаки);
2. Анализ и сокращение поверхности атаки (Attack Surface Reduction), что достигается исследованием, документированием и минимизацией уязвимых элементов;
3. Моделирование угроз — структурированный анализ сценариев угроз на уровне компонентов, проводится с использованием специализированных инструментов, поддерживающих машиночитаемые модели угроз;
4. Определение дополнительных проектных критериев с учётом специфики продукта или организации.

Реализация программного обеспечения в рамках SDL предполагает:

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

Верификация программного обеспечения подразумевает^[4][5]:

• динамический анализ кода во время разработки;
• анализ поверхности атаки;
• проведение фаззинг-тестирования (в т. ч. для сетевых компонентов и интерфейсов).

Перед выпуском продукта создаётся план реагирования на инциденты и проводится финальный обзор безопасности. План реагирования необходим для своевременного устранения новых угроз и включает аварийные контакты, планы обслуживания для унаследованного или стороннего кода. Финальный обзор безопасности (FSR) подразумевает анализ моделей угроз, результатов автоматизированных средств и тестов производительности^[4].

После выпуска продукта важен быстрый отклик на возникающие проблемы. Несмотря на внедрение SDL, программное обеспечение может содержать уязвимости, влияющие на криптостойкость. Значительное число ошибок выявляется уже при эксплуатации продукта, поэтому механизм реагирования и устранения уязвимостей остаётся востребованным^[4].

Компания Microsoft официально внедрила SDL с 2004 года. По собственным данным и отраслевой статистике, это привело к заметному росту качества программных продуктов^[1][7].

Стив Липнер (Steve Lipner), старший директор по стратегическому планированию и развитию безопасности Microsoft, возглавляющий внедрение SDL, отмечал:

В отчёте Microsoft о развитии SDL за 2004–2010 годы указано, что количество уязвимостей в продуктах компании сократилось почти на три порядка по сравнению с общей отраслевой статистикой^[1][8]. По данным Secunia Research Community, независимой фирмы, специализирующейся на анализе уязвимостей, для сервера IIS 5 (до SDL) было зарегистрировано 12 бюллетеней Secunia advisories, для IIS 6 (первая версия с SDL) — 5, для IIS 7 (полный SDL) — 1^[9][10]. Эффективность внедрения SDL подтверждается также опытом компаний VMware^[11] и SAP^[12].

Тем не менее, SDL не устранил уязвимости полностью. В отчётах компании указывается на необходимость постоянного совершенствования самого SDL, внедрения новых подходов к обеспечению безопасности и расширения применения подобных методологий во всех индустриальных сегментах, поскольку масса уязвимостей в одном только приложении порой ставит под угрозу всю систему^[8].