Обзор публикации NIST SP 800-218 "Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities"

Руслан Рахметов, Security Vision

Новости об обнаружении опасных уязвимостей в популярных приложениях и операционных системах публикуются на профильных ресурсах практически ежедневно, при этом наиболее громкие уязвимости получают даже имена собственные - так было, например, с HeartBleed (CVE-2014-0160), EternalBlue (CVE-2017-0144), Log4Shell (CVE-2021-44228). Обнаружение подобного рода уязвимостей, ошибок конфигурирования или реализации протоколов становится значимым событием, поскольку вслед за публикацией исследователем или вендором технической информации злоумышленники начинают разрабатывать эксплойты в надежде атаковать пока что непропатченные системы (о важности процесса управления уязвимостями мы говорили в одной из предыдущих статей).

Настоящий пост будет посвящен обзору документа NIST SP 800-218 "Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities" («Фреймворк создания безопасного программного обеспечения: рекомендации по снижению рисков программных уязвимостей»), который содержит рекомендации по использованию фреймворка создания безопасного программного обеспечения - набора высокоуровневых практик безопасной разработки ПО. Следование ему поможет сократить количество уязвимостей в коде, снизить потенциальный ущерб от их эксплуатации, устранить корневые причины возникновения уязвимостей.

В документе NIST SP 800-218 вводится термин Secure Software Development Framework (SSDF), т.е. фреймворк создания безопасного программного обеспечения, который является набором базовых целесообразных практик для разработки ПО. Внедрение фреймворка SSDF позволит организации выполнить следующие рекомендации по безопасной разработке ПО:

• Подготовка людей, процессов и технологий к осуществлению циклов безопасной разработки;

• Защита всех программных компонентов от несанкционированного доступа и вредоносного вмешательства;

• Разработка защищенных программных продуктов с минимальным количеством уязвимостей;

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

В документе дается определение SDLC (software development life cycle, жизненный цикл разработки программного обеспечения) как формальной или неформальной методологии по проектированию, созданию, поддержке программного обеспечения, включая микропрограммы («прошивки») аппаратных устройств. Несмотря на большое количество методологий разработки ПО (каскадная модель, спиральная модель, agile, DevOps и другие), применение в любой из них фреймворка SSDF и практик безопасной разработки поможет снизить количество уязвимостей в релизах, снизить потенциальный ущерб от эксплуатации оставшихся уязвимостей, а также выявить и устранить корневую причину возникающих уязвимостей для предотвращения их появления в дальнейшем. В NIST SP 800-218 подчеркивается важность фундаментального правила безопасной разработки софта: стратегия "Shifting Left", т.е. буквально «сдвиг влево», подразумевает максимально ранее включение вопросов безопасности кода в жизненный цикл разработки продуктов. Решение вопросов безопасности разрабатываемого продукта на самом раннем этапе проектирования и написания технического задания, с дальнейшим контролем на этапах непосредственной разработки, выпуска, внедрения, обновления, поддержки поможет снизить будущие затраты на устранение уязвимостей и последствий от их эксплуатации. В документе NIST SP 800-218 подчеркивается, что указанные во фреймворке рекомендации являются гибкими и высокоуровневыми, что позволяет применять их вне зависимости от специфики разработки, сектора экономики, IT/OT/IoT-инфраструктуры, методологии разработки, применяемого стека технологий или языка программирования. В случае же использования сервисной модели (SaaS, PaaS, CaaS и т.д.), будет разумно применять принцип разделения ответственности между провайдерами, разработчиками, тенантами.

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

1. Подготовка организации:

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

1.1.1. Выявление, документирование и периодическая актуализация требований безопасности к инфраструктуре и процессам разработки ПО;

1.1.2. Выявление, документирование и периодическая актуализация требований к разрабатываемому компанией ПО;

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

1.2. Распределение ролей и ответственных:

1.2.1. Создание новых ролей и назначение ответственных, с периодическим пересмотром актуальности назначений;

1.2.2. Проведение обучения ответственных за безопасную разработку сотрудников, с периодическим проведением аттестаций;

1.2.3. Получение поддержки руководства компании и доведение позиции топ-менеджмента до всех ответственных и заинтересованных лиц.

1.3. Внедрение средств автоматизации безопасной разработки:

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

1.3.2. Следование рекомендациям при внедрении, использовании, поддержке инструментов автоматизации процессов безопасной разработки;

1.3.3. Настройка инструментов автоматизации процессов безопасной разработки для создания цифровых артефактов их применения при разработке ПО.

1.4. Разработка и применение критериев оценки безопасности разработки ПО:

1.4.1. Определение критериев оценки и их контроль в рамках цикла безопасной разработки ПО;

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

1.5. Внедрение и поддержка безопасной среды разработки ПО:

1.5.1. Разделение и защита всех инфраструктурных сегментов, применяемых при разработке ПО (например, сегменты разработки, сборки, тестирования, распространения и т.д.);

1.5.2. Обеспечение кибербезопасности и защищенная настройка конечных точек разработчиков, архитекторов, тестировщиков и т.д.

2. Защита программного обеспечения:

2.1. Защита всех видов программного кода от неавторизованного доступа и изменения:

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

2.2. Предоставление механизма для проверки целостности и аутентичности программного продукта:

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

2.3. Архивация и защита всех версий продукта в целях поиска и устранения уязвимостей, обнаруженных после релиза:

2.3.1. Безопасная архивация файлов и сопутствующей информации для каждого релиза продукта;

2.3.2. Сбор, защита, актуализация и передача заинтересованным лицам данных о всех программных компонентах каждого релиза ПО, например, через каталог компонент программного обеспечения (англ. SBOM, Software Bill Of Materials).

3. Создание безопасного программного продукта:

3.1. Разработка ПО для соответствия требованиям безопасности и смягчения рисков:

3.1.1. Использование вариантов моделирования киберрисков (например, моделирование угроз, моделирование кибератак, анализ поверхности атак) для оценки рисков использования программного обеспечения;

3.1.2. Отслеживание и поддержка требований безопасности ПО, рисков, принятых архитектурных решений;

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

3.2. Пересмотр архитектуры ПО для проверки соответствия требованиям безопасности и результатов анализа киберрисков:

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

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

3.3.1. Приобретение/получение и поддержка хорошо защищенных и отлаженных программных компонент (библиотек, модулей, фреймворков) из коммерческих, open source и иных источников;

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

3.3.3. Проверка соответствия приобретенных/полученных программных компонент требованиям безопасности компании, с перепроверками в течение их жизненного цикла.

3.4. Создание исходного кода в соответствии с практиками написания безопасного кода:

3.4.1. Следование всем практиками безопасного программирования, применяемым в соответствующем языке программирования и среде разработки.

3.5. Настройка процессов компиляции, интерпретации и сборки для повышения безопасности исполняемых модулей:

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

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

3.6. Проведение изучения и/или анализа человекочитаемого кода для выявления уязвимостей и проверки соответствия требованиям безопасности:

3.6.1. Выбор способов изучения кода (вручную квалифицированным сотрудником) или анализа кода (с привлечением средств автоматизации) в соответствии с требованиями организации;

3.6.2. Проведение изучения и/или анализа кода на соответствие корпоративным стандартам безопасной разработки ПО, с документированием и анализом всех выявленных проблем, а также с выдачей рекомендаций.

3.7. Проведение тестирования исполняемого кода для выявления уязвимостей и проверки соответствия требованиям безопасности:

3.7.1. Выявление необходимости тестирования исполняемого кода для поиска уязвимостей, не обнаруженных на предыдущих этапах;

3.7.2. Определение объема и границ тестирования, создание тестов, выполнение тестирования, документирование и анализ результатов, выдача рекомендаций по устранению;

3.8. Настройка ПО для использования наиболее безопасных настроек по умолчанию:

3.8.1. Создание baseline минимальных требований безопасности путем выявления всех настроек, которые могут повлиять на безопасность, с выработкой настроек по умолчанию, которые не будут снижать защищенность ПО, среды установки, сервисов;

3.8.2. Внедрение настроек по умолчанию и их документирование для администраторов ПО.

4. Реагирование на уязвимости:

4.1. Выявление и подтверждение уязвимостей на постоянной основе:

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

4.1.2. Проведение изучения, анализа и/или тестирования кода ПО для выявления или подтверждения наличия ранее не выявленных уязвимостей;

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

4.2. Оценка, приоритизация, устранение уязвимостей:

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

4.2.2. Планирование и внедрение мер по реагированию на обнаруженные уязвимости.

4.3. Анализ уязвимостей для выявления корневой причины их возникновения:

4.3.1. Проведение анализа обнаруженных уязвимостей для выявления корневой причины их возникновения;

4.3.2. Проведение анализа корневых причин на протяжении некоторого времени для выявления паттернов в допущенных ошибках (например, невыполнение определенных требований безопасной разработки);

4.3.3. Изучение программных продуктов для нахождения однотипных уязвимостей и проактивного устранения этого класса уязвимостей;

4.3.4. Пересмотр процессов безопасной разработки ПО и их обновление для предотвращения или снижения вероятности повторения корневых причин уязвимостей в обновлениях и новом ПО.