Внедрение процедур безопасной разработки программного обеспечения (Secure SDLC)

Вы разрабатываете программное обеспечение для себя или на заказ? Думаете, что старая шутка про «Тяп ляп и в продакшен!» точно не про вас? Мы поможем вам проверить, так ли это на самом деле, и выстроить процессы разработки ПО в соответствии с лучшими мировыми практиками.

4 главные опасности для заказчика программного обеспечения, с которыми мы поможем справится разработчику:

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

Количество уязвимостей CVE по годам

Количество уязвимостей в ПО не сокращается само по себе

Для чего нужен Secure SDLC

Внедрение процедур безопасной разработки сокращает совокупную стоимость разработки за счёт более раннего обнаружения и устранения уязвимостей. По мнению Национального института стандартов и технологий США (NIST), затраты на устранение уязвимостей на этапе проектирования могут быть в 30 раз ниже затрат на устранение таких же уязвимостей после выпуска продукта[1][2].

Принцип Secure Software Development LifeCycle — классический риск-ориентированный подход из учебника. Его внедрение не устраняет уязвимости полностью (что очень долго и дорого), оно лишь снижает их до минимально приемлемого уровня.

Цикл безопасной разработки Microsoft

Не отстают и регуляторы: ФСТЭК России с 1 июня 2017 года обязывает разработчиков средств защиты информации следовать требованиям ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования».

Состав работ по внедрению Secure SDLC

В качестве методик внедрения цикла безопасной разработки мы используем Рекомендации в области стандартизации банка России РС БР ИББС-2.6 -2014, MS SDL, OWASP Secure SDLC Cheat Sheet.

«Перспективный мониторинг» оценивает процессы разработки на всех стадиях цикла.

Цикл безопасной разработки HP

Пример Secure SDLC от компании HP

  • Наладим мониторинг безопасности используемых сторонних компонентов, который исключит для разработчика роль «догоняющего». Как только уязвимость будет опубликована — разработчику станет о ней известно.
  • Построим модель угроз и модель нарушителя и научим вас это делать.
  • Протестируем на проникновение разработанные продукты методом «черного ящика». В отчёте будет содержаться перечень уязвимостей, отсортированный по степени критичности, сценарии эксплуатации и рекомендации к устранению.
  • Оценим спроектированные решения с точки зрения безопасности и определим поверхность атаки.
  • Поможем внедрить статические анализаторы исходного кода в технологический процесс сборки ПО (Continuous Integration). Использование анализаторов на этапе разработки снижает количество ошибок и дефектов программного кода на 15–20%.
  • Сделаем фаззинг сетевых протоколов, форматов файлов, значимых для ПО переменных окружения, входных параметров веб-приложений. Разработаем кастомизированные фаззинг-решения для самостоятельного применения.
  • Проанализируем исходный код на предмет безопасности.
  • Проведём аудит процесса эксплуатации информационной системы и безопасности системы обновлений.


[1] http://csrc.nist.gov/groups/SMA/forum/documents/october-2012_fcsm-jjarzombek.pdf

[2] ftp://ftp.software.ibm.com/software/rational/info/do-more/RAW14109USEN.pdf