Продолжаем говорить о безопасной разработке и Secure SDLC. Сегодня на примере платформы T1 Cloud SDP покажем, какие облачные сервисы привнесут уровень безопасности в жизненный цикл ПО. Среди них есть как ручной анализ кода, так и автоматизированная проверка надежности open source компонентов.
При чем тут провайдеры
Требования к защищенности приложений прописаны в таких документах, как Приказ ФСТЭК России №21 и ГОСТ Р ИСО/МЭК 15408-3-2013, ГОСТ Р 56939-2016 и многих других. Для отдельных отраслей предусмотрены специфические стандарты. Например, в банковской сфере есть PCI DSS, цель которого — защита платежной информации держателей пластиковых карт. Чтобы выполнить предписания нормативных актов и спецстандартов, компании необходимы компетенции в области AppSec. Однако в этой нише по всему миру наблюдается кадровый голод — инженеров в Application Security не хватает и в России.
Определённые особенности есть и при внедрении инструментария, необходимого для построения Secure SDLC. В прошлый раз мы говорили, что этот процесс может потребовать значительных финансовых ресурсов — в том числе для настройки файрволов и систем оценки качества кода — которых может не быть у стартапов и среднего бизнеса. Решить этот вопрос способны облачные провайдеры, которые предлагают настроенную инфраструктуру для тестирования и реагирования на инциденты в рамках Secure SDLC. Покажем, что может предложить облако на примере сервиса T1 Cloud Secure Development Platform.
Такой разный анализ кода
В первую очередь специалисты облачного провайдера консультируют на тему ИБ-требований и процессов, плюс — помогают выбрать и разобраться в DevSecOps-инструментах. Так, наша система SDP имеет несколько сервисов по поиску уязвимостей и оценке качества кода для разных задач и юзкейсов.
Ручной анализ защищенности. В этом случае проверкой кода занимаются наши инженеры. Обычно анализ проходит по методу «черного ящика», но с согласия клиента его можно провести и с доступом к исходникам приложения/сервиса. Оценка качества выполняется регулярно — она проходит каждый раз после существенных изменений, поэтому процесс легко интегрируется в CI/CD.
Длительность таких проектов напрямую зависит от объема задач at hand. В связи с этим начинать анализ защищенности приложения лучше заблаговременно. Очевидно, что ручной метод не позволяет обнаружить все недостатки, однако он хорошо дополняет другие варианты тестирования приложений и инфраструктуры.
Статический анализ исходного кода (SAST). Помогает выявить наиболее распространенные недостатки в процессе разработки — например, небезопасные конструкции языка, некорректную обработку входных и выходных данных, явно прописанные секреты. Анализ автоматизирован и проходит на базе отечественного решения appScreener и зарубежной системы MicroFocus.
Динамический анализ приложений (DAST). Помогает выявить недостатки, которые нельзя обнаружить при помощи SAST (те, что видны только в процессе исполнения кода). Ими могут быть нестойкие пароли, неустойчивость к переборным атакам, состояния гонок и другие. Динамический анализ также позволяет оценить «эксплуатируемость» недостатков, выявленных другими методами.
В облаке T1 Cloud решения DAST построены на базе систем MicroFocus и SolidLab. Эксперты SolidLab предлагают уникальный набор инструментов, в том числе собственной разработки — например, сетевой экран для веб-приложений SolidWall. Он объединяет методы обнаружения атак по сигнатурам и анализ методом «позитивных моделей». Система автоматически строит модели работы приложений, что позволяет использовать решение в активном цикле Secure SDLC.
Отметим, что автоматизированный динамический анализ более эффективен, если логика приложения хорошо покрыта автотестами. Ну и сам по себе процесс анализа более сложный, по сравнению с SAST, поскольку обнаруженные недостатки нужно еще «спроецировать» на программный код.
Анализ внешних компонентов с открытым исходным кодом (OST). Сервис позволяет найти уязвимости в open source компонентах, используемых при разработке. Он построен на базе инструмента DependencyCheck, который сообщает об уязвимостях в библиотеках, фреймворках и утилитах, информация о которых уже доступна публично — это 0-day и 1-day уязвимости. Также можно отслеживать лицензионную чистоту используемых внешних компонентов.
Анализ кодовой базы и компонентов — ключевой этап разработки безопасного приложения, но возможности T1 Cloud SDP выходят за его пределы. Система предлагает инструментарий для защиты ПО на всех этапах жизненного цикла: от постановки задачи до QA и приемки. В комплексе решения позволяют построить полнофункциональную лабораторию защищенной разработки в облаке. Такой проект мы уже реализовали для ретейлера электронной техники, развернув спектр ПО MicroFocus — статический и динамический анализаторы кода, окружение для управления недостатками, а также балансировщик задач. Последний автоматически выбирал свободные ресурсы в облаке или on premise.
На что еще обратить внимание
Прежде чем внедрять инструментарий DevSecOps, нужно оценить ресурсы и установить очередность подключения продуктов к процессу безопасной разработки. В первую очередь стоит учесть критичность разрабатываемого приложения, зрелость процессов, имеющиеся компетенции команд и используемый стек технологий. С этими вопросами также можно обратиться к нашим специалистам и составить алгоритм внедрения инструментария. Так может выглядеть проект по запуску процессов на примере статического анализа:
Выбор приложений для внедрения механизмов безопасной разработки.
Установка системы SAST на предназначенную для нее инфраструктуру, интеграция с репозиториями и первичная настройка.
Проведение сканирования для каждого проекта в итеративном режиме. Ручной разбор результатов, настройка правил с целью повысить полноту определения уязвимостей и устранения ложных срабатываний. Далее, проведение нового сканирования.
Интеграция средств ИБ с инструментами безопасной разработки.
Составление организационной, нормативной и технической документации.
Обучение работе с системой статического анализа сотрудников, вовлеченных в процесс девелопмента и приемки.
Консультационная и техническая поддержка специалистов заказчика в ходе проекта.
Аналогичным образом можно составить план по внедрению динамических систем тестирования, а также решений для выявления уязвимости в open source компонентах, хотя и там есть свои особенности. О них мы поговорим в следующий раз, поэтому подписывайтесь на наш блог.
Дополнительное чтение по теме: