5 шагов к безопасной разработке

Разработка безопасного программного обеспечения — это набор различных контролей и связанных с ними гейтов, которые встраиваются в процессы производства, чтобы выявить и устранить уязвимости в коде и в компонентах, используемых при разработке ПО или на этапе сборки. Давайте рассмотрим, какие базовые шаги нужно обязательно сделать, чтобы разрабатываемое ПО было безопасным. А поможет нам в этом руководитель Центра платформ кибербезопасности МТС RED Денис Шефановский.

Проектирование

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

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

Одно дело разместить некий API для мобильного приложения в интернете, а другое – проверить его динамическим анализом (DAST) или фаззингом (FUZZ testing) и разместить за API-гейтвеем, который реализует необходимые контроли и минимизирует поверхность атаки.

Архитекторы ИБ также могут учитывать разнообразие вариантов применения «коробочных» продуктов и вводить дополнительные контроли или меры защиты.

Разработка

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

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

Сборка

Во-первых, при сборке ПО можно использовать только код, проверенный инженерами AppSec (Application Security).

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

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

Управление уязвимостями

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

— SAST (статический анализ кода),
— SCA (компонентный анализ ПО),
— DAST (динамический анализ ПО),
— FUZZ testing (фаззинг-тестирование),
— MAST (тестирование безопасности мобильных приложений),
— IAST (интерактивное тестирование безопасности приложений),
— RASP (самозащита приложения во время выполнения).

Эти инструменты нужно интегрировать в pipeline разработки и управлять ими для проведения сканирований. Даже для одного вида анализа может одновременно применяться несколько разных инструментов, поэтому при большом количестве таких одновременных проверок необходима оркестрация (управление «оркестром» анализаторов).

Конечно, анализаторы могут выдавать немалый объем ложноположительных срабатываний или пропускать часть уязвимостей. Поэтому любые инструменты анализа необходимо, во-первых, настраивать, а во-вторых, обрабатывать результаты проверок. Делать это можно, используя методы дедупликации (устранения дублей кода), корреляции (соотнесения результатов разных типов анализа между собой). Эти методы сложны в реализации и не могут быть выполнены вручную человеком.

Чтобы решить эти проблемы, используются системы класса ASOC (Application Security Orchestration and Correlation). В них реализована автоматизация управления различными инструментами анализа ПО, которые нужны для обнаружения уязвимостей. Уязвимости, выявленные разными инструментами, собираются в едином представлении и приоритизируются по критичности – так AppSec специалист может быстрее и эффективнее их обработать. Кроме того, такие системы внутри себя содержат всю необходимую функциональность для построения процесса разработки безопасного кода ПО в компании.

Управление рисками, связанными с уязвимостями

Как и во многих процессах, в разработке безопасного программного обеспечения существует процесс управления рисками. Можно использовать все стандартные подходы в зависимости от ситуации: принятие риска, избегание, передача или его снижение. Это позволяет быть более гибкими с точки зрения скорости выпуска релизов, условий применения разрабатываемых продуктов и улучшает лояльность бизнеса к процессам AppSec.

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

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

Другой пример, когда уязвимость может содержаться в компоненте, который сложно заменить, или исправить уязвимость в его исходном коде невозможно. В этом случае могут использоваться меры предотвращения эксплуатации найденных уязвимостей: например, виртуальный патчинг на WAF (межсетевом экране для веб-приложений).

Есть и другие подходы: можно осуществлять мониторинг поведения программного обеспечения непосредственно во время его исполнения на продуктиве (RASP) и уже на основе поведенческой модели делать заключение об эксплуатации уязвимости.

Подытожим

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

Реклама ПАО «МТС» erid: LjN8Jv121