Внедрение безопасности в функцию на этапе проектирования

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

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

Сегодня мы поговорим об одной из таких практик, с которой многие из вас могут быть знакомы, называемой DevSecOps (Операции безопасности разработки). Итак, что такое DevSecOps?

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

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

Обычно процесс отправки функции включает в себя:

1. Разработку – где функция создается
2. Дистрибуцию – где создаются артефакты и готовятся к доставке
3. Развертывание – где функция выпускается в производственную среду

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

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

Проведите моделирование угроз

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

Давайте рассмотрим пример, чтобы понять это. Представьте, что вы разрабатываете API, который:

• Перечисляет продукты в вашем каталоге.
• Ищет продукт или тип продукта.

GET /api/products?search=laptop

​

Модель угроз может выглядеть следующим образом:

Это то, на что мы можем обратить внимание при рассмотрении конечных точек продукта. Лучшая часть в том, что вам не нужно быть экспертом в области безопасности, чтобы распознать эти уязвимости.

Инструменты, такие как инструменты Threat modeling от Microsoft и Threat Dragons от OWASP, могут помочь их выявить.

Пример модели угроз в инструменте Threat Modeling от Microsoft

Просмотр анализа

Вид анализа инструмента моделирования угроз показывает различные атаки, которые могут произойти на API.

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

• Слабые криптографические методы. Например, использование SHA1 или MD5 считается слабым. CA530 является примером предупреждения, которое C# создает, когда в коде используются любые слабые хеш-функции.
• Атаки SQL-инъекций. CA2100 является примером, который проверяет, подвержен ли код атакам инъекций
• Зашитые пароли, слабые механизмы аутентификации и авторизации, а также неправильные настройки инфраструктуры также могут быть обнаружены с помощью статических анализаторов.

В этой области также существуют существующие инструменты. SonarQube, CodeQL, Roslyn Analyzer, OWASP Dependency Check и Snyk также предлагают несколько отличных возможностей в этой области.

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

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

Кодовые ревью с точки зрения безопасности

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

Вывод

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

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