Цифровизация так плотно вклинилась в нашу жизнь, что мы сейчас практически все операции в нашей жизни делаем при помощи цифровых продуктов: заказываем себе доставку, оплачиваем услуги, да даже к врачу чаще записываемся через приложение, а не по-старинке походом в поликлинику с ожиданием в живой очереди.
За всей этой магией скрывается огромный труд команды, которая трудится над цифровыми продуктами. Если раньше была упрощенная линейная схема взаимодействия в жизненном цикле продукта: бизнес генерит идею - разработчик пишет и собирает код - тестер ищет баги в том, что отдала разработка - инженер разворачивает продукт в инфраструктуре - бизнес ждёт скорее релиз. Всё этапы проверки проходят в ручном режиме, каждый отвечает за свой этап и уверен в качестве своей работы. В таких условиях выпуск продукта затягивается, так что включать в эти циклы ещё и информационную безопасность было совсем неуместно, потому что можно было зациклить процесс до бесконечности.
Что изменилось в разработке?
В начале 2000-х годов появилась методологий DevOps, которая включает в разработку автоматизацию процессов сборки, настройки и развертывания программного обеспечения, при активном взаимодействии всей команды продукта на жизненных циклах, интеграции процессов с целью снижения time-to-market и повышения качества продукта. Автоматизация, взаимодействие и интеграция — разработка, тестирование и эксплуатация. Во главе всего стоит DevOps-инженер (ну или команда инженеров), который упрощает взаимодействие Dev (разработки) и Ops (эксплуатации), вовлекает участников в понимание работы друг друга.
Итак, DevOps — это набор методик, инструментов и философия культуры, задача которых автоматизировать и интегрировать между собой процессы команды разработки и ИТ‑команды.
Жизненный цикл DevOps непрерывен, на каждом этапе для автоматизации используются свои инструменты, а для схематического обозначения возьмём типовую структуру:
Итак, кратко по концепции DevOps прошлись, но откуда же взялось Sec?
До недавнего времени процесс проверки информационной безопасности проводили или после завершения процесса разработки, а часто было, что и после выхода решения в продакт. Если на первом этапе, то это отправляет продукт на начальный этап разработки, а если на втором, то тут начинается процедура выстраивания «костылей» вокруг готового продукта, что точно не добавляет плюсов к его работоспособности из-за построения искусственных ограничений функционала.
Так и появилась концепция «Shift left», которая изначально была задействована командой тестировщиков, которые включались в оценку «багов» уже на ранних этапах разработки кода. В дальнейшем данная концепция была принята и для специалистов по информационной безопасности — нахождение уязвимых мест на ранних этапах позволяет увеличить безопасность итогового продукта, ускорить процесс выхода проекта на рынок, избежать последующих проблем в рамках эксплуатации.
Когда же надо встраивать этот процесс и какими инструментами?
Раз уж DevOps — это про командную работу, то и Sec тут должен быть в единому русле. Так что чтобы команда двигалась в правильном направлении, правила игры надо обговорить с самого начала — на этапе построения культуры безопасной разработки. Улучшение коммуникаций и повешение осведомленности позволит преодолеть сопротивление команды и обеспечит единство взглядов каждого участника проекта.
Этапы DevOps, которые я приводил выше, можно рассмотреть и точки зрения DevSecOps:
Plan: в концепции DevSecOps закладывает в себя управление требованиями, включая планирование и закладку архитектуры, учёт требований в соответствии со стандартами (ГОСТ, PCI DSS, ISO и т.д.), рекомендациями (OWASP, MITRE, CWE, Минцифры) и регуляторикой (а в текущих реалиях её очень много) в рамках информационной безопасности. Идеальная цель этих мероприятий — это понимание команды разработки как эти требования реализовывать, но это не всегда легко, потому что команда разработки не всегда понимает в кибербезопасности, а безопасники не всегда понимает в коде. Снять некоторую головную позволит моделирование угроз, используя автоматизированные инструменты для этих задач, например OWASP Threat Dragon.
Итак, задачи на этот этап — понять, какие у нас угрозы, какие у нас требования. Готовим фундамент.
Code: в рамках пайплайна DevSecOps данный этап начинается с фазы Pre-commit: позволяет обнаружить незашифрованную конфиденциальную информацию, такие как пароли или API-ключи. Некоторые встроенные инструменты проверок есть на самих веб-сервисах Git, ну или готовые решения вроде Gitleaks, так что используйте их. Забытые ключи — довольно большая проблема, которая в дальнейшем может очень сильно повлиять на безопасность готового продукта.
Следующим фазой идёт Pre-build (Commit по DevSecOps Guideline) — на данном этапе проводится тестирование методом «белого ящика», когда у специалиста DevSecOps есть доступ к исходному коду. Здесь применим классический подход автоматизации проверки кода, а поможет нам в этом решения класса SAST (статическое тестирование программных приложений). Используйте инструменты автоматизации проверки кода, например OWASP Dependency-Check, SonarQube, semgrep и т.д., ну и встроенные инструменты анализа кода есть на самих Git-платформах.
Кроме этого, разработчики часто используют в своих проектах готовые open source компоненты для упрощения разработки. Эти сборки несут в себе дополнительный риск — это и зловреды класса malware, различные закладки для последующих угроз класса «атака на цепочку поставок» (про самую нашумевшую атаку на цепочку поставом можно почитать здесь), ну и не стоит забывать про такие угрозы, как protestware — это когда разработчик закладывает каике-то блокировки, лозунги и призывы, что актуально в современных геополитических реалиях. Так что не забывайте проверять используемые фреймворки и библиотеки, читайте отзывы, проверьте нет ли политических лозунгов на страницах разработчика, ну и используйте SCA (Software Composition Analysis) инструменты для проверок, например Trivy.
Итак, задачи на этот этап — проинспектировать наш код, перед тем, как отдать его в сборку.
Build: итак, код мы проверили на распространенные уязвимости, API-ключи подчистили, пароли удалили, теперь наступает время проверки после сборки приложения. Проверка безопасности артефакта относится к фазе Post-Build (Commit) — анализ сборок из исходного кода, например Docker-образа, JAR, RPM. На данной стадии у нас задача проверить собранный артефакт, окружение и зависимости приложения, выявить устаревшие версии библиотек и пакетов. Поможет нам в этом решения Binary SCA, взять хоть тот же Trivy, который я упоминал выше, Grype, часть инструментов есть в DockerHub.
В целом, задача на данном этапе — безопасно сконфигурировать образы, проверить эти сборки на наличие устаревших версий пакетов и библиотек, обновление версионности.
Test: здесь у нас начинается самое интересное, ну и наверное самое активное участие со стороны Sec. Данная фаза именуется Test-time (Continuous Delivery). Если на ранних этапах мы выступали больше со стороны внутреннего пользователя, тестируя наш продукт изнутри — методом «белого ящика», то на этом этапе мы имитируем действия злоумышленника, метод «черного ящика». Здесь нам помогут решения тестирования безопасности с динамическим анализом (DAST). Внешнее динамическое сканирование позволяет проверить приложение на наличие известных уязвимостей высокой степени критичности, например проблемы с аутентификацией, авторизацией, SQL Injection, проблемы с API. DAST проверяет приложение в рабочем режиме, симулируя атаки и проверяя вектора атак. Если говорить об инструментах тестирования, то из open source можно выделить OWASP ZAP, кроме этого, есть встроенные инструменты в том же Gitlab, мы в своих проектах используем также Acunetix.
Кроме инструментов DAST на данном этапе часто используют решения IAST — это интерактивное тестирование безопасности, которое объединяет в себе функциональность SAST и DAST, сканирование методом «серого ящика». Это гибридный формат и инструментация кода, но имеет и свои недостатки — занимает продолжительное время и инструменты часто заточены под определенные языки разработки. Ну и классическим методом тестирования на данном этапе является фаззинг — передача приложению на вход неправильных, неожиданных или случайных данных. Этой методике тестирования уже более 30 лет, методика старая, хорошо описана, так что останавливаться на ней подробно не будем. Стоит ещё упомянуть решение от PortSwigger — OAST (тестирование безопасности приложений вне диапазона). К сожалению, в Burp Suite Community Edition данное тестирование недоступно.
Итак, задачи на данном этапе — имитация действия взломшиков, желательно разными инструментами, потому что идеального решения пока не существует.
Deploy: предыдущие у нас прошли успешно, значит можно преступать к фазе развертывания в рабочей среде. Если на предыдущих этапах мы проверяли безопасность самого кода и его артефактов, то на этом этапе у нас встаёт вопрос анализа самой инфраструктуры, где будет размещаться наш продукт. Необходимо учитывать и версию ОС самой инфраструктуры, анализировать открытые порты, проводить патчинг, проверить open source компоненты, которые тоже используются в инфраструктуре, кроме этого, надо тщательно проанализировать различия конфигурация тестовой и рабочей среды. На данном этапе используется метод IaC (Infrastructure as Code) — это процесс управления инфраструктурой, при котором для управления ресурсами рабочей среды применяются рекомендации из этапов, которые мы проработали ранее. Автоматизация этого процесса помогает устранить рассинхрон в конфигурации тестовой и рабочей среды, снизить количество багов и сбоев. Существуют руководства и рекомендации по методам усиления инфраструктуры, таким как контрольные показатели Center for Internet Security (CIS) и контрольные списки конфигурации NIST. Кроме этого. даже на стадии деплоя не стоит забывать про безопасность артефактов приложения. Здесь нам поможет упомянутый выше Trivy.
Итак, на данном этапе — мы переносим из тестовой среды в боевую наше приложение, а наша задача подготовить эту среду, проверить окружение, безопасно настроить, ну и желательно автоматизировать этот процесс.
Operate, Monitor: этап Post-deploy (поздне Governance)сопровождения приложения. Это наверное наиболее привычный формат работы со стороны команды кибербезопасности. Здесь подключаются классические методы защиты вроде WAF (Web Application Firewall) — межсетевой экран уровня веб-приложений, который работает на уровне L7 OSI. Из открытых и бесплатных решений на рынке явный лидер в лице Cloudflare. Дополнительным средством защиты, которая перекрывает те атаки,чтт не может обнаружить WAF, являются решения класса RASP (Runtime Application Self‑Protection). Главное преимущество данного класса решений это то, что они работают внутри приложения, поэтому могут понимать контекст, выявлять аномалии и блокировать атаки по умолчанию. Из доступных решений можно выделить OpenRASP от техногиганта Baidu.
Обязательным направлением на данном этапе является внедрение практики анализа уязвимостей инфраструктуры. Существует большое количество сканеров безопасности, как бесплатные полностью OWASP ZAP, так и различные Community версии платных продуктов, так например мы используем Invicti (Netsparker), Tenable Nessus, Burp Suite, Acunetix. Многие компании привлекают внешних исполнителей для проведения различных тестов на проникновение (pentest), внедряют программы BugBounty, когда выплачивают вознаграждения за выявленные уязвимости, внедряю защиту и мониторинг API и контейнеризированных сред.
Итак, задачи на данном этапе — это построение защиты приложения, отслеживание и исправление обнаруженных ошибок и уязвимостей, мониторинг событий безопасности и реагирование на них.
В целом все эти этапы имеют циклический и непрерывный процесс на всех стадиях жизненного цикла приложения, потому что приложения обновляются, дополняются функционалом, дорабатываются. Все участники команды должны быть задействованы на этих этапах вплоть до вывода приложения из обращения.
В целом, каждый этап имеет свои инструменты, свои сложности (разный стек, структура кода, инфраструктура, инструменты, микросервисы и т.д.) и процедуры. Однако, внедрение процесса DevSecOps позволяет добиться значительных результатов, влияющих на конечный продукт:
- сокращение времени time-to-market за счет автоматизации;
- снижение расходов на исправление ошибок и уязвимостей в ПО за счет их обнаружения на ранних этапах разработки;
- снижение рисков для разработчика приложений, например, недопущение встраивания вредоносного кода в компоненты разрабатываемого продукта или защита инфраструктуры от атак типа «цепочка поставок».
Главным правилом успеха от внедрения данной практики является вовлеченность в процессы всей команды и понимание значимости безопасной разработки на всех уровнях иерархии команды — от разработчика, до бизнес-руководства.
