Автоматизация ИБ: кейсы и сценарии по построению комплексных систем на примере DevSec

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

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

Обеспечить эффективность внедрения автоматизации безопасности в процесс разработки необходимо, используя комплексный подход с применением специализированных инструментов, процессов и методик. Несмотря на то, что выработанный подход DevSecOps, который собирает разработку (Development), безопасность (Security) и операционную деятельность (Operations) в единую формулу, позволяет в целом организовать процесс, у него есть и определенные недостатки. В этой статье сфокусируемся только на части DevSec, внимательно разбирая особенности именно этой связки внутри комплекса процессов.

Стандартный процесс и встраивание инструментов на примере работы с кодом

В классическом варианте DevSecOps является CI/CD-центричным и подразумевает под собой встраивание инструментов класса AST (Application Security Testing) в pipeline разработки. Сам перечень инструментов, точек встраивания и запуска может сильно отличаться от проекта к проекту, но минимальным «джентельменским» набором на базе Open source можно считать: статические (Semgrep, Bandit, Horusec, GoSec) и композиционные (Dependency Check, Trivy, OpenSCA), а также поддерживающие сканирование Docker-образов (Trivy, Grype) анализаторы. Помимо этого, сканеры секретов (GitLeaks и TruffleHog). Особенно важно правильно выбрать базу данных уязвимостей, которая позволит определять актуальные угрозы безопасности для большинства объектов, используемых в производстве ПО.

На каждый контроль необходим как минимум один, а то и несколько анализаторов, чтобы обеспечить высокое качество анализа. Каждый придется отдельно инсталлировать, настраивать, встраивать в процесс разработки, интегрировать с экосистемными продуктами компании. При этом нужно выстроить процесс проверки на уязвимости таким образом, чтобы была возможность управлять как перечнем анализаторов, которые проводят тестирование на безопасность, так и правилами анализа. Параллельно необходимо настроить Vulnerability management, который в классическом варианте выстраивается либо вручную, либо с использованием оркестраторов (Defect Dojo, Dependency Track и других). А также важно найти способы показать эффективность встраивания всех этих инструментов.

Минусы классического подхода

Внедрение отдельных инструментов по безопасности в DevSecOps имеет ряд недостатков: отсутствие прозрачности, гибкости интеграции (нужно настраивать каждый инструмент по отдельности), поддержка и стоимость лицензии, разные вендоры, отчеты в PDF, поиск данных в разных системах и отправка их команде. К тому же, в каждой команде разный уровень зрелости, из-за чего не всегда получается гибко и быстро встроить проверки в pipeline. Инженеру ИБ необходимо глубоко погружаться в разработку каждого продукта, а если в корпорации более 100 продуктовых команд и всем им безопасность нужна здесь и сейчас, то один специалист просто не успеет настроить все команды – придётся набирать штат дорогостоящих экспертов. Или терять очень много времени.

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

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

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

Если бы в этот процесс была внедрена автоматизация, то мы бы получили экономию времени разработчиков и инженеров ИБ, прослеживаемость всего процесса, обращение к ИБ через единое окно Self-Service, а не через запрос в почту, и встроенный Vulnerability management.

Что дает автоматизация процесса

С помощью автоматизированной платформы можно интегрировать разные Git-системы, что в дальнейшем позволит постоянно отслеживать появление новых коммитов и отправлять их на проверку. К тому же, при правильном UI-интерфейсе без сильного вовлечения команды разработки можно с легкостью отправить на анализ необходимый репозиторий (или даже группу) и получить результаты SAST и SCA.

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

А если команда уже имеет высокую зрелость? В таком случае проверки можно встраивать в билды через API или CLI. Тогда разработчик будет через командную строку просматривать статус и разрешать деплой в случае прохождения всех точек контроля.

А что лежит под капотом?

Внутри платформы интегрированы анализаторы, например: Semgrep, CodeQL, Bandit, GoSec, Dependency Check, которые покрывают разные языки программирования и передают полученные результаты в виде коде. Далее производится исследование методами статического и композиционного анализа, начинается поиск hardcoded секретов в исходном коде. При запуске анализа создается так называемая «задача на анализ», которая включает в себя всю необходимую информацию о составе кода, pipeline выполнения анализа (какие именно инструменты и с какими правилами нужно запустить). Созданная задача принимается в работу оркестратором, позволяющим распараллелить одновременные сканирования. После окончания анализа результаты поступают в систему корреляции, где происходит процесс нормализации и дедупликации найденных уязвимостей, их фильтрация по уровню критичности и предварительная разметка для выявления ложноположительных срабатываний. Также к каждой найденной уязвимости подкрепляется рекомендация по устранению, описание и фрагмент кода, где содержится данная уязвимость.

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

Метрики

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

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

Метрики могут отвечать на вопросы совершенно разных потребителей – ИБ, ИТ, HR, C-Level, Compliance IP. Например, специалисты ИБ прослеживают динамику обнаружения уязвимостей, последние сканирования, время жизни уязвимостей, работу разработчиков, которые допускают ошибки при написании кода. Помимо поиска уязвимостей, можно отследить и используемые лицензии в open-source библиотеках, что помогает работе юристов, так как они могут принять решение об области применимости данной лицензии и о рисках ее использования.

Кейс из моей практики. Юристы компании запросили у разработчиков информацию об используемых лицензиях, для чего им было необходимо собрать все данные в Excel и отправить коллегам. Как мы понимаем, весь процесс занимает достаточно много времени: пока разработчики все опишут, а юристы проанализируют все лицензии и сообщат о возможности ее применения, пройдет несколько дней или недель, а результат, собранный вручную, может не совпадать с реальностью из-за фактора человеческих ошибок. Весь процесс составления SBOM (Software Bill of Materials) достаточно трудоемкий и не всегда может быть выполнен в поставленные сроки качественно. А если нужно принять срочное решение и нет возможность ждать недели?

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

Чаще всего руководство компании не видит, какие именно риски и угрозы закрывают определенные контроли ИБ, но за счет сбора статистики и отрисовки в BI подсвечиваются как сильные, так и слабые стороны безопасности и защищенности продуктов компании. Система может автоматически анализировать профиль разработчика, генерировать необходимые рекомендации по их обучению, отправляя ссылки на почту или в таск-менеджер. Таким образом можно прокачать слабые стороны разработчиков и повысить качество кодирования.

В целом, можно сказать, что автоматизация позволяет эффективно распределять время инженеров ИБ и разработчиков, объединяет их на всех этапах процесса, а также предоставляет качественную и более точную информацию в любой момент и под разные запросы. Но самое главное – меняется свойство самой информационной безопасности для разработчиков, потому что она перестает блокировать процесс, а наоборот, помогает ускорить и улучшить его. Если сервис ИБ работает в режиме Self-Service и контроли проводятся «прозрачно» на протяжении всего жизненного цикла продукта без влияния на Time-to-Market, то не успех ли это?

Автор: Алина Князева, руководитель направления информационной безопасности Дзен.