Проект

Общее

Профиль

Действия
История

Wiki » ISM »

Безопасность в разработке программного обеспечения

Введение

По данным исследований, более 70% успешных кибератак эксплуатируют уязвимости в программном коде, а не в сетевой инфраструктуре. При этом устранение уязвимости на этапе проектирования обходится в 30–100 раз дешевле, чем после выпуска продукта.

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

Безопасность в разработке — это подход, при котором требования, практики и инструменты ИБ интегрируются в каждый этап жизненного цикла создания ПО, а не добавляются к уже готовому продукту.

Этот подход известен под несколькими названиями: Secure SDLC, DevSecOps, «сдвиг влево». По сути, все они описывают одно: безопасность должна присутствовать с первого дня разработки.

Эта тема завершает курс. Она связывает воедино оценочные стандарты из темы Оценочные стандарты (Common Criteria, ОУД), управление рисками из темы Управление рисками (моделирование угроз как частный случай оценки рисков), криптографию из темы Аудит и криптография (подпись артефактов, хранение секретов) и технические меры из темы Управление доступом (WAF, SIEM, аутентификация в приложениях).

Почему безопасность нельзя «добавить потом»

Стоимость исправления уязвимости нелинейно возрастает с течением цикла разработки. Ошибка в требованиях, обнаруженная на этапе проектирования, исправляется за час. Та же ошибка, обнаруженная после выпуска в продакшн, потребует обновления продукта, уведомления пользователей, возможно — регуляторного расследования.

Но дело не только в деньгах. Многие архитектурные решения необратимы: если система спроектирована без разграничения доступа между модулями, добавить его после завершения разработки значит переписать ядро системы. Именно поэтому безопасность должна закладываться в архитектуру, а не накладываться поверх неё.

Жизненный цикл разработки и меры безопасности

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

Фаза 1. Требования

На этапе сбора требований формулируются требования безопасности наравне с функциональными:

  • какие данные обрабатывает система и какой им присвоен класс защиты (персональные данные по 152-ФЗ, объекты КИИ по 187-ФЗ, коммерческая тайна по 98-ФЗ);
  • каким регуляторным требованиям должна соответствовать система (приказы ФСТЭК, требования ЦБ для финансовых систем, PCI DSS для систем, обрабатывающих платёжные карты);
  • нужна ли сертификация по ОУД и какой уровень требуется;
  • применяется ли принцип Privacy by Design — конфиденциальность данных закладывается в архитектуру, а не добавляется потом.

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

Фаза 2. Проектирование

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

Моделирование угроз — это, по сути, оценка рисков применительно к конкретной системе. Методология та же, что описана в теме 5. Управление рисками ИБ: идентификация активов → выявление угроз → оценка вероятности и ущерба → выбор мер. Разница — в уровне детализации и специфике инструментов.

Наиболее распространённые методологии моделирования угроз:

STRIDE — классификация угроз по шести категориям: подмена идентичности, изменение данных, отказ от совершённых действий, утечка информации, отказ в обслуживании, повышение привилегий. Каждая категория STRIDE соответствует нарушению одного из свойств триады КДЦ или смежных свойств безопасности.

PASTA — ориентированный на бизнес-риски подход с семью этапами, включая имитацию атак с точки зрения злоумышленника.

DREAD — методика количественной оценки серьёзности угрозы по пяти параметрам. Позволяет приоритизировать меры защиты.

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

Фаза 3. Реализация (кодирование)

Стандарты безопасного кодирования — задокументированные правила для разработчиков: как обрабатывать пользовательский ввод, как работать с криптографией, как избегать конкретных классов уязвимостей. Примеры: CERT Coding Standards, OWASP Cheat Sheet Series.

SAST — статическое тестирование безопасности. Инструменты анализируют исходный код без его выполнения, выявляя SQL-инъекции, XSS, небезопасное использование криптографических функций, жёстко заданные пароли в коде. Примеры: SonarQube, Checkmarx, Semgrep. SAST интегрируется в IDE — разработчик видит предупреждение сразу при написании уязвимого кода.

SCA — анализ состава ПО. Выявляет уязвимые сторонние компоненты и open-source библиотеки. Результатом является SBOM — реестр всех компонентов продукта с версиями и лицензиями. Инцидент Log4Shell (CVE-2021-44228, декабрь 2021) затронул тысячи продуктов именно потому, что организации не знали, используют ли они Log4j: SBOM позволяет ответить на этот вопрос за минуты.

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

Фаза 4. Тестирование

DAST — динамическое тестирование работающего приложения. Инструменты имитируют действия злоумышленника: отправляют вредоносные запросы, проверяют реакцию. Находят уязвимости, незаметные при статическом анализе: проблемы конфигурации, логические ошибки в бизнес-процессах, небезопасные заголовки HTTP. Примеры: OWASP ZAP, Burp Suite.

Penetration Testing (пентест) — ручная имитация атаки профессиональными специалистами. Наиболее глубокий вид тестирования: выявляет цепочки уязвимостей, которые по отдельности кажутся незначительными, и бизнес-логические проблемы, невидимые автоматическим инструментам. Проводится перед значимыми релизами и не реже раза в год.

Fuzzing — автоматизированная подача случайных и некорректных данных на вход системы для обнаружения сбоев и уязвимостей. Эффективен для API, парсеров, протоколов передачи данных.

Именно на этапе тестирования наиболее значимы требования ОУД 4 — подробнее в соответствующем разделе ниже.

Фаза 5. Выпуск и деплой

Security Gates в CI/CD — автоматические проверки, останавливающие выпуск, если найдены уязвимости выше заданного порога серьёзности. Это операциональное воплощение принципа «безопасность как код»: политики безопасности выражены в форме кода, версионируются и применяются автоматически.

Подпись артефактов — криптографическая подпись собранных пакетов и образов контейнеров. Гарантирует целостность цепочки поставок: потребитель может проверить, что артефакт создан именно тем, кем заявлено, и не был изменён после подписания. Механизм ЭЦП для этого — тот же, что описан в теме Аудит и криптография. Фреймворк SLSA определяет четыре уровня зрелости этих практик.

Secrets Management — секреты (пароли, токены, ключи API) не хранятся в коде или переменных среды, а управляются специализированными инструментами: HashiCorp Vault, AWS Secrets Manager, CyberArk Conjur. Это продолжение темы управления привилегированным доступом из темы Управление доступом применительно к машинным идентичностям.

Hardened Configuration — минимизация поверхности атаки: отключение неиспользуемых сервисов, применение принципа наименьших привилегий для сервисных учётных записей, шифрование данных в покое.

Фаза 6. Эксплуатация

Patch Management — систематическое отслеживание и применение обновлений безопасности. Связан с SCA: обнаружение новой CVE в используемом компоненте должно автоматически инициировать процесс обновления.

WAF и RASP — WAF защищает приложение на уровне HTTP-трафика, блокируя атаки из OWASP Top 10. RASP встраивается внутрь приложения и перехватывает атаки прямо в среде выполнения.

Мониторинг безопасности приложения — интеграция с SIEM, отслеживание аномалий в поведении пользователей, журналирование критических операций. Применение SIEM для этой задачи подробно рассмотрено в теме Управление доступом.

VDP и Bug Bounty — политика ответственного раскрытия уязвимостей и программы вознаграждения за найденные баги. Организованный механизм приёма сообщений от независимых исследователей безопасности — зрелая практика, принятая в крупных технологических компаниях.

OWASP Top 10

OWASP — некоммерческий фонд, публикующий открытые материалы по безопасности веб-приложений. Его наиболее известный документ — OWASP Top 10 — список десяти наиболее критичных классов уязвимостей, обновляемый каждые 3–4 года.

Текущая версия (2021):

Код Категория Типичный пример Связь с курсом
A01 Broken Access Control Пользователь меняет ID в URL и получает чужие данные Нарушение DAC/RBAC из темы 9
A02 Cryptographic Failures Пароли хранятся в MD5 без соли Уязвимость, описанная в теме 10
A03 Injection SQL-инъекция через поле поиска SAST обнаруживает при статическом анализе
A04 Insecure Design Нет ограничений на число попыток входа Выявляется при моделировании угроз (фаза 2)
A05 Security Misconfiguration Открытый порт отладчика в продакшне Устраняется Hardened Configuration (фаза 5)
A06 Vulnerable Components Библиотека с известной CVE Выявляется SCA; управляется через SBOM
A07 Authentication Failures Сессионные токены не инвалидируются при выходе MFA и управление сессиями из темы 9
A08 Software Integrity Failures Обновления загружаются без проверки подписи Подпись артефактов, ЭЦП из темы 10
A09 Logging Failures Неудачные попытки входа не фиксируются Требования к протоколированию из темы 10
A10 SSRF Сервер делает запросы к внутренним ресурсам по URL из запроса Выявляется DAST; блокируется WAF

OWASP также публикует специализированные Top 10 для API, мобильных приложений, LLM-приложений и облачных сред.

ОУД 4 и Common Criteria в контексте разработки

Стандарт Common Criteria (ISO/IEC 15408, в России — ГОСТ Р ИСО/МЭК 15408) подробно рассмотрен в теме Оценочные стандарты. Здесь рассматриваем его с точки зрения разработчика: что конкретно нужно делать, чтобы продукт мог быть сертифицирован по ОУД 4.

Требования ОУД 4 к процессу разработки

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

Требования к разработчику, релевантные для каждой фазы SDLC:

Фаза SDLC Требование ОУД 4 Артефакт для оценщика
Проектирование Полная спецификация функций безопасности — описание всех внешних интерфейсов безопасности Функциональная спецификация, описание архитектуры
Проектирование Описание архитектуры безопасности — как механизмы защиты соотносятся друг с другом ADV_ARC.1: документ архитектуры безопасности
Реализация Предоставление исходного кода критических функций безопасности оценщику Исходный код подсистем аутентификации, управления доступом, криптографии
Тестирование Анализ покрытия тестами — соответствие между тестами и функциями безопасности из спецификации ATE_COV.2: анализ покрытия
Тестирование Независимое тестирование оценщиком — оценщик воспроизводит часть тестов разработчика и проводит собственные ATE_IND.2: независимое тестирование
Тестирование Анализ уязвимостей — поиск очевидных уязвимостей в публичных базах и через анализ документации AVA_VAN.3: анализ уязвимостей
Процесс разработки Управление конфигурацией — каждая версия продукта документирована, изменения отслеживаются ACM: документация управления конфигурацией
Процесс разработки Управление жизненным циклом — безопасность процесса разработки и дистрибуции продукта ALC: свидетельства безопасности процессов

Почему ОУД 4 не означает «продукт безопасен»

Сертификация по ОУД 4 фиксирует состояние на момент оценки. Оценка занимает от нескольких месяцев до двух лет для крупного продукта. За это время в продукте или его зависимостях могут появиться новые уязвимости. После выхода CVE на сертифицированный продукт организация должна оценить, затрагивает ли уязвимость сертифицированную конфигурацию, и при необходимости инициировать поддержание сертификата.

Сертификат ОУД 4 означает: «процесс разработки и тестирования соответствовал строгим требованиям стандарта, а заявленные функции безопасности независимо проверены на момент оценки». Это необходимое условие доверия к продукту — но не достаточное условие отсутствия уязвимостей.

Фреймворки зрелости безопасной разработки

OWASP SAMM

OWASP SAMM — модель оценки и улучшения зрелости практик безопасности ПО в организации. SAMM описывает 15 практик безопасности, сгруппированных в пять бизнес-функций:
  1. Governance,
  2. Design,
  3. Implementation,
  4. Verification,
  5. Operations.

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

SAMM используется как инструмент оценки текущего состояния («где мы находимся?») и как дорожная карта улучшений («куда двигаться?»).

NIST SSDF

NIST SSDF — руководство NIST по практикам безопасной разработки, обязательное для поставщиков ПО в адрес федеральных органов США и де-факто ставшее международным ориентиром.
SSDF организован вокруг четырёх групп практик:
  1. Prepare the Organisation,
  2. Protect the Software,
  3. Produce Well-Secured Software,
  4. Respond to Vulnerabilities.

PCI Software Security Framework

PCI SSF — стандарт Совета по стандартам безопасности платёжных карт (PCI SSC) для безопасной разработки платёжного ПО. Пришёл на смену стандарту PA-DSS в 2022 году.

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

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

DevSecOps: операционализация безопасной разработки

DevSecOps — культура и практика интеграции безопасности в DevOps-процессы, при которой каждый член команды несёт ответственность за безопасность, а проверки автоматизированы и встроены в конвейер доставки.

Shift Left («сдвиг влево») — выявлять и устранять проблемы безопасности как можно раньше. Стоимость исправления уязвимости на этапе требований — условная единица. На этапе проектирования — пять. На этапе кодирования — десять. После выпуска — сотни.

Security as Code — политики безопасности выражаются в форме кода: правила SAST, пороги Security Gates, конфигурации WAF. Код версионируется, проверяется и применяется автоматически — никакого «ручного нажатия кнопки» для применения политики безопасности.

Security Champion — разработчик внутри команды, проходящий углублённое обучение по безопасности и помогающий коллегам применять практики безопасного кодирования в ежедневной работе. Это масштабируемая модель: один Security Champion на команду из 8–10 разработчиков эффективнее одного централизованного эксперта на всю организацию.

Metrics-Driven Security — измеримые показатели зрелости: MTTR уязвимостей (среднее время устранения), плотность уязвимостей на 1000 строк кода, процент критических уязвимостей, закрытых в течение SLA, покрытие тестами безопасности.

Что дальше

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

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

Список литературы и стандартов

  • ISO/IEC 15408-1:2022 (ГОСТ Р ИСО/МЭК 15408) — Общие критерии
  • OWASP Top 10 2021
  • OWASP SAMM v2 — Software Assurance Maturity Model
  • NIST SP 800-218 — Secure Software Development Framework
  • PCI Software Security Framework — Secure Software Standard и SLC Standard
  • SLSA Framework — Supply-chain Levels for Software Artifacts
  • OWASP Cheat Sheet Series — практические руководства по безопасному кодированию
  • McGraw G. — Software Security: Building Security In. Addison-Wesley, 2006
  • Kim G., Humble J., Debois P. — The DevOps Handbook. IT Revolution Press, 2016
  • Руководящий документ ФСТЭК России — Методология оценки безопасности ИТ

Обновлено С. Антошкин около 14 часа назад · 12 изменени(я, ий)