Требования к безопасности ПО

В мире, где все больше процессов — от общения до финансовых операций — происходит в интернете, защита программного обеспечения становится основой его стабильной работы. Поэтому важно учесть требования к безопасности ПО с самого начала разработки. Уязвимости могут появляться прямо в коде, и злоумышленники используют их для атак: SQL-инъекции, DDoS, перехват данных, межсайтовый скриптинг и другие. Чтобы предотвратить такие проблемы, разработчики используют разные методы тестирования:

• статическое,
• динамическое,
• анализ состава приложений,
• цепочки поставок и лицензионных рисков.

В статье подробнее раскроем требования по безопасности, предъявляемые к ПО, и расскажем о каждом методе контроля.

О требованиях к безопасности ПО

Правила и стандарты информационной безопасности требуют учитывать следующие аспекты:

• Конфиденциальность данных. Вся обрабатываемая информация должна быть защищена от несанкционированного доступа. Особенно важны критичные данные, которые нужно хранить и передавать в зашифрованном виде. Для этого следует использовать протокол TLS и применять алгоритмы шифрования на уровне ПО.
• Целостность данных. Важно, чтобы данные не могли быть изменены без ведома пользователя. Для этого применяются алгоритмы шифрования и надежные механизмы аутентификации.
• Доступность данных и ключевых функций приложений. Одно из требований к безопасности ПО — даже при наличии всех мер безопасности пользователи должны иметь возможность без проблем работать с приложением. Все функции должны быть доступны тем, у кого есть на это права.
• Аудит и контроль безопасности. Разработчикам нужно предусмотреть возможность отслеживания пользовательских действий и событий внутри ПО. Это помогает выявить проблемы и быстро реагировать на них.

Чтобы повысить безопасность программных продуктов, ФСТЭК России рекомендует улучшать качество разработки, обеспечивать безопасность сборочной среды, защиту кода и поддерживать готовые решения.

ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения» задает основные требования к безопасности ПО и определяет порядок работ по созданию защищенных продуктов. Разработчики должны следовать этому стандарту для выпуска надежных программных решений на отечественный рынок.

Концепция DevSecOps для соблюдения требований по безопасности, предъявляемых к ПО

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

Процесс безопасной разработки в рамках подхода DevSecOps можно разделить на пять этапов:

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

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

Методы проверки и контроля соблюдения требований безопасности, предъявляемых к ПО

Подробнее расскажем, как платформа Solar appScreener помогает обеспечить комплексную безопасность при разработке приложений.

Статическое тестирование

Static Application Security Testing (SAST) — самый распространенный метод проверки, с помощью которого можно узнать, соблюдены ли требования по безопасности, предъявляемые к ПО. Он заключается в анализе кода на наличие уязвимостей, ошибок и недекларированных возможностей. Главное преимущество — можно проверить практически 100% написанного кода, не запуская при этом программу. Однако нужно иметь доступ к исходному коду, поэтому такое тестирование называется стратегией белого ящика.

Обобщенный алгоритм статической проверки с помощью Solar appScreener:

• Создается промежуточное представление кода.
• Этот код проверяется с помощью различных методов статического анализа (лексического, синтаксического, семантического, taint-анализа, исследования потока управления и потока данных).
• Применяется комплекс правил обнаружения уязвимостей.

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

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

Применение Solar appScreener позволит нивелировать главный минус анализа SAST — False Positive (ложноположительные срабатывания — сообщения о проблемах, которые фактически отсутствуют). Для минимизации False Positive в анализаторе используется технология Fuzzy Logic Engine, разработанная и запатентованная командой ГК «Солар».

Динамическое тестирование

Dynamic Application Security Testing (DAST) — тестирование уже развернутых и работающих приложений, но не завершенных — могут дорабатываться в процессе. Для такого анализа требуется имитированная рабочая среда, максимально приближенная к реальной. В отличие от статистического тестирования, при DAST не нужно иметь доступ к программному коду и структуре ПО, поэтому этот метод и называется стратегией черного ящика.

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

• традиционный,
• пассивный,
• автоматический,
• AJAX,
• Fuzzer.

Также можно настроить степень агрессивности атаки.

Внедрение DAST на завершающих этапах разработки позволяет соблюдать требования к безопасности ПО, но часть уязвимостей все равно может быть упущена, так как не обеспечивается полное покрытие кода. Поэтому для наиболее эффективного анализа безопасности стоит использовать оба метода — и динамическое, и статическое тестирование. В Solar appScreener можно объединить результаты проверок коррелировать и получать развернутые детальные отчеты.

Анализ состава программ и цепочки поставок, оценка лицензионных рисков

Software Composition Analysis (SCA), Supply Chain Security (SCS) и анализ лицензионных рисков объединены в Solar appScreener в общий модуль — OSA. Особенности этих видов тестирований:

• SCA помогает проверять надежность всех компонентов Open source, которые используются в программе. Этот анализ стоит применять с начальных этапов разработки, чтобы оперативно выявить возможные уязвимости. С помощью SCA можно обнаружить: программные закладки, уязвимости в сторонних библиотеках, которые используют разработчики, а также проблемы с лицензированием открытых компонентов. Чтобы выполнить тестирование, достаточно загрузить программный код, ссылку на репозиторий или SBOM-файл в интерфейсе Solar appScreener. Если SBOM-файл отсутствует, анализатор соберет его самостоятельно из предоставленных исходников. Затем он считает все заимствованные фрагменты и проверит их с помощью баз уязвимостей.
• SCS помогает обеспечить безопасность на всех этапах пути, по которому ПО попадает к пользователям, — от момента создания или покупки продукта до начала эксплуатации. Этот анализ дает комплексную оценку всем используемым сторонним компонентам на основе 8 критериев: популярности, авторскому составу, активности сообщества, уровню заинтересованности в безопасности, давности создания библиотеки, подозрительной «высоты» первой версии, количеству проектов разработчика, процента пул реквестов, которые не выполняют требование рецензии от двух человек.
• Анализ лицензионных рисков нужен для минимизации юридических проблем, связанных с получением лицензий на открытые компоненты. Например, проверка позволит выявить отсутствие лицензий, несовместимость лицензий разных заимствованных компонентов.

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

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

Перечислим ключевые моменты:

• Уменьшение затрат на выпуск ПО без потери качества. Внедрение безопасной разработки помогает заранее устранять недостатки продуктов и сэкономить бюджет на исправление последствий инцидентов ИБ.
• Снижение рисков утечек данных и атак на приложения — помогает избежать санкций и штрафов за несоблюдение требований по безопасности, предъявляемых к ПО.
• Повышение доверия пользователей. Безопасность продуктов напрямую влияет на репутацию разработчика, увеличивая доверие клиентов и пользователей.
• Выполнение требований регуляторов. Соблюдение норм ФСТЭК России, ЦБ и других регулирующих органов по безопасности ПО помогает избежать юридических последствий.

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