Цифровая трансформация для служб ИБ вылилась в создание новой области защиты – непрерывной разработки и интеграции (или CI/CD). Безопасность CI/CD в народе стали называть DevSecOps, ну а мы посмотрим, с какого боку к DevSecOps подойти обычному корпоративному безопаснику, который традиционно занимается обеспечением безопасности на уровне ИТ-инфраструктуры и комплаенса.
Также посмотрим на DevSecOpsи с точки зрения обеспечения безопасности ИТ-инфраструктуры и прикладных сервисов для разработки. Вопросы Secure Software Development Lifecycle в фокус обзора не попадут.
Чтобы не изобретать велосипед, применим проверенный фреймворк NIST Cybersecurity Framework, то есть используем последовательность управления ИБ Identify-Prevent-Detect-Respond-Recover.
IDENTIFY
В CI/CD мы можем выделить целый ряд новых для служб ИБ объектов защиты. Выделим семь ключевых.
Системы управления задачами и процессами разработки (Trello, Jira и др.) –позволяют организовать совместную работу в одной команде и между командами. В них зачастую хранятся бизнес-требования, могут лежать секреты, а иногда их без согласования с ИБ используют в облачном варианте. После чего происходят истории вроде публичного доступа к тысячам досок в Trello.
Системы управления знаниями (Confluence, Notion и др.) – хранят различные материалы и позволяют совместную работу над документами и статьями. Основные проблемные ситуации аналогичны предыдущим, плюс отсутствие резервных копий.
Системы хранения кода и конфигурации (Gitlab, CicleCI и др.) – хранят программный код и конфигурации, обеспечивая версионирование изменений, ревью коммитов (изменений) старшими разработчиками, возможность отката изменений и в целом обеспечивая подход инфраструктура-как-код (Infrastructure-as-a-Code). Основные проблемные ситуации – отсутствие резервных копий, отсутствие настроек ролевой модели, хранение секретов в открытом виде.
Системы сборки кода и организации развёртывания (Gitlab, Jenkins) – обеспечивают сборку кода в артефакты (полуфабрикаты программного обеспечения), которые в дальнейшем могут быть развёрнуты на основе, например, Docker образов. Основные проблемные ситуации – отсутствие интеграции security-проверок кода (SAST, DAST, SCA), проверок хранения секретов в открытом виде, проверок Docker-образов на уязвимости.
Системы хранения артефактов/ Docker registry (собранного кода, Docker образов – JFrogArtifactory/harbor, dockerhub) – хранят в себе артефакты/Docker images, массово используются корпорациями всего несколько лет, из-за чего мало кто понимает, какие там роли в целом существуют и как их настраивать. Зачастую используются из облака (dockerhub) или в гибридном режиме, добавляя риск автоматического подтягивания в наши образы произвольных библиотек без какой-либо проверки службой ИБ или любым другим сотрудником. Пример такой ситуации: симуляция тайпсквоттинг-атаки на PayPal, Microsoftи 33 другие компании, где атакующий залил вредоносный код в публичные репозитории с названием, похожим на легитимные зависимости. Кстати, 99,5% организаций, по ощущениям автора, ещё даже не планируют забирать логи из артефактория, более того, даже не хотят понимать, куда уходят наши артефакты.
Системы оркестрации контейнеризации (Kubernetes, OpenShift) – предоставляют новую генерацию уровня абстракции для контейнеров, фактически новый *NIX, являясь интеллектуальным менеджером приложений, ресурсов и процессов в *NIX в реальном времени. Соответственно нечеловеческой сложности этой системы (на два порядка выше *NIX) количество проблемных ситуаций тяжело поддаётся счёту, фактически дублируя все ранее возможные ситуации (отсутствие толкового логирования, дефолтная анонимная аутентификация и др.) и возвращая нас во времена Windows 95.
Системы управления конфигурацией (puppet, helm) – обеспечивают динамическое развёртывание легаси и контейнеризированных инфраструктур и приложений. Основная проблемная ситуация – интеграции с разнообразными сервисными учётными записями, хранение секретов.
Серверная инфраструктура (билд-серверы и др.) – обеспечивают базу для работы других систем. Проблемные ситуации – большое количество уязвимостей, излишний доступ разработчиков к таким серверам.
Рабочие станции разработчиков/DevOps–место, где разработчики разрабатывают и иногда билдят. Проблемные ситуации – билдинг на рабочей станции, хранение кода на рабочей станции, неконтролируемый BYOD, незашифрованные жёсткие диски для мобильных устройств, секреты в открытом доступе, отсутствие ротации секретов.
К сожалению, традиционные практики оценки рисков плохо применимы для CI/CD-инфраструктуры. Это обусловлено большим количеством взаимозависимостей и сервисных учётных записей. Таким образом, качественно изолировать влияние от, например, компрометации registryот влияния на весь CI/CD-пайплайн (автоматизированный процесс развёртывания ПО) невозможно.
PREVENT
Узнав, какие типы объектов защиты у нас есть, мы получаем возможность последовательного внедрения классических корпоративных доменов требований безопасности:
Стоит отметить: чем ближе приложение к модели SaaS,тем меньше в нём механизмов ИБ. Однако даже базовые механизмы нужно контролировать и проверять их работу.
Учитывая, сколько команд разработчиков и разрабатываемых приложений можно найти в корпорациях, работа по внедрению контролей безопасности займёт годы. Также стоит отметить, что работа по обеспечению безопасности CICD во многом подобна работе по обеспечению безопасности SAP. Например, процесс обновления Kubernetes кластера требует разработки и далеко не всегда возвращает предсказуемые результаты.
Для эффективной реализации программы по безопасности CICD предлагается применять следующие 5 принципов:
SecurityasaCode (безопасность как код) – по максимуму хранить проверки и конфигурацию инструментов безопасности в репозиториях и автоматически их применять. Заодно это поможет держать в поле зрения работу молодых падаванов.
Постепенное внедрение – совместно с бизнесом и ИТ выберите один проект и внедрите стандарты безопасности для него. Потом можно будет тиражировать.
Трезвая оценка ситуации – комбинируйте OpenSource и коммерческие инструменты. Первые будут тянуть ваше время, а вторые – деньги, очень удобно иметь возможность балансировать.
Человеческий язык – после понимания ландшафта CI/CD нужно коммуницировать с командами, часто они сами внедряют много улучшений безопасности.
Ответственный подход – в случае инцидентов ИБ служба ИБ так или иначе будет за них отвечать. Это значит, что нужно или внедрять контрольные ворота (приёмку), или регулярно делать аудиты DevSecOps и чётко представлять, что происходит в разработке. Это, в свою очередь, позволит профессионально управлять рисками: принимать (хоть и временно) или снижать их в зависимости от критичности приложения, чувствительности данных, в нём обрабатываемых, наличия людских, финансовых и других ресурсов для реализации контролей по снижению рисков.
Отдельно отмечу, что в данной статье не упомянуты все риски, связанные с Kubernetes, – это большая и сложная тема. Введением в неё будет классический CIS Benchmark, а также некоторое количество лабораторных работ, которое нужно будет сделать, чтобы почувствовать, что такое Kubernetes, на своей шкуре (hands-on), например, O’Reily Katakoda.
DETECT
Однако в ситуациях, где невозможно реализовать ограничения на уровне предотвращения (Prevent), мы можем внедрить детектирующие контроли. Например, если программное обеспечение написано так, что конкретным Docker-контейнерам нужны значительные права, мы можем детектировать опасные системные обращения в Kubernetes-кластере, например:
Стоит понимать, настройка детектирующего контроля – это часть дела, нужны ещё люди, которые будут триажить (сортировать) и расследовать алерты. Учитывая кадровый голод в службах ИБ и SOC, DevSecOps подразделения будут полагаться на себя и максимальную автоматизацию деятельности по мониторингу и DevSecOps в целом.
RESPOND
Автоматизация реагирования в CI/CD весьма новая область, и далеко не всё сейчас можно автоматизировать с приемлемым уровнем falsepositive/falsenegative. Первым делом на ум приходят решения SOAR, но им хватает работы и в традиционных ИТ-инфраструктурах.
На самом деле на уровне инфраструктуры разработки на помощь приходят admission controllers, например,OpenPolicyAgent, которые выполняют роль NAC для Kubernetes на стероидах. На уровне кода – Application Security Orchestration and Correlatio nрешения – SIEM для проблем в коде с учётом инфраструктур разработки различных команд. Например, Archery/DefectDojo.
RECOVER
Резервное копирование нужно производить особенно тщательно там, где у нас нехватка предотвращающих и детектирующих контролей, таким образом, хотя бы снижая риск значительной приостановки цифровых бизнес-процессов.
Recovery Time Objective (RTO) CI/CD равняется наибольшему RTO из компонентов CI/CD ландшафта, за исключением вспомогательных систем по управлению задачами и знаниями.
Recovery Point Objective не так критичен, как в классических информационных системах, потому что данные обычно хранятся вне CI/CD. С точки зрения сохранения состояния среды оркестрации подход GitOps позволяет практически восстанавливать её, однако внедрение GitOps само по себе – отдельная масштабная задача, и не для всех она полезна.
Это также значит, что тестирование бекапов критично как никогда – снова можно провести параллель с SAPsecurity.
ЗАКЛЮЧЕНИЕ
Джинна цифровизации и инхаус разработки уже не загнать назад в бутылку, поэтому пора открыть глаза на реальность. Лучше начать создавать функцию DevSecOps до того, как разработчики и инженеры DevOps, непрерывно создавая и развивая новые незащищённые приложения и инфраструктуры, доведут вашу службу ИБ до неприятной ситуации. Тем более что тема DevSecOps большая, чем привлекает много молодых и энергичных специалистов.
- Стоимость медиауслуг (открыть PDF) -
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
