Привет, Хабр! Меня зовут Михаил Синельников @m_sinelnikov, я DevSecOps TeamLead в РСХБ‑Интех. В сфере ИТ тружусь с 1999 года, в РСХБ попал в 2021 году. Ранее работал в качестве ведущего специалиста и руководителя направлений информационной безопасности в Эр‑Телеком, Монета.ру. Сейчас занимаюсь контейнерной безопасностью и безопасностью kubernetes, развиваю и поддерживаю платформу ИБ. Сегодня расскажу, как мы в РСХБ в кротчайшие сроки построили ИБ‑платформу с использованием OpenSource‑инструментов и для чего нам это понадобилось.

Материал основан на докладе, зачитанном мною в ходе RSHB DevSecOps Meetup, посвященному теме информационной безопасности в процессах. Митап прошел 27 октября, запись выступлений доступна на сайте РСХБ в цифре.

В рамках материала мы рассмотрим следующие вопросы:

• Можно ли платформу ИБ построить бесплатно и в кратчайшие сроки?

• Можно ли ASOC сделать понятным для бизнеса? Бизнес — наш основной заказчик. Понятно, что все процессы и все что мы делаем не для себя, дома ASOC нам не нужен. ИБ‑специалистам это тоже не нужно, все это нужно бизнес‑заказчику. Поэтому нужно сделать платформу, которая будет понятна всем.

• Как оптимизировать процессы ИБ, сократив Time‑to‑Market до минимума? Меня сразу поставили в определенные рамки: проверки практик DevSecOps в CI/CD не должны занимать больше 10–15 минут. Нужно как‑то вписаться в них.

• Как оценить жизненный цикл уязвимости и эффективность работы специалистов ИБ?

• Как подготовиться к включению QG так, чтобы ни один из разработчиков не пострадал?

Инструменты

Когда я пришел в РСХБ‑Интех в качестве руководителя ИБ‑направления у нас был прекрасный пул инструментов. Мы их встраивали, интегрировали, настраивали, помогали вендорам завозить это все в CI, получали отчеты, настраивали корреляции, в общем мы делали безопасность. Нам очень это нравилось и добавляло драйва.

Но вот пришел май 2022 года, и вся наша безопасность обнулилась. Мы не знали, что с этим делать, как жить дальше, техдолг рос, что тянуло нас вниз. Ко всему прочему добавилась ответственность перед коллегами из ИБ‑области, перед банком и всеми структурами, с которыми мы связаны.

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

Почему мы не стали ждать, пока не появится наш энтерпрайз поставщик?

• Бэклог всего на два месяца. Вендор не успевал поставить ИБ‑инструменты в этот срок. Мы понимали, что, если отстанем, нагонять будет очень сложно. Время очень дорого для нас, и резервирование в случае отказа от энтерпрайза нам будет крайне необходимо.

• Потребность в прозрачности, полная видимость процессов во время разработки и тестирования.

• Нужны гибкие и функциональные инструменты, та же система ASOC. Мы в свое время не смогли завести туда OpenSource, что, возможно, решило бы часть проблем.

• Экономия. Тут все просто — платформа должна стоить 0 рублей, поскольку на тот момент никто не запрашивал бюджет, ситуация внештатная.

• Нам необходимо быстрое обновление. То есть сегодня выходит релиз или патч, завтра мы его должны протестировать и уже послезавтра выкатить в прод.

В самом начале мы не понимали, какую ASOC‑систему нам выбрать. После анализа присутствующих решений мы собрали все варианты, соотнесли их с основными внутренними требованиями, которые обязаны учитывать:

• Локальная установка. Естественно, мы ни в коем случае не должны передавать данные за пределы контура, как и исходный код. То есть нужны инструменты, способные работать в закрытом контуре.

• Из‑за отсутствия средств «здесь и сейчас» нужно было OpenSource‑решение.

• Критично было наличие формата SARIF. С его помощью мы можем загружать уязвимости непосредственно в ASOC‑систему из любого сканирующего компонента.

В итоге мы остановились на DefectDojo.

Перейдем к выбору сканеров, которые мы можем использовать. У нас довольно разнообразный стек, но из него нужно выбрать только 1–2 сканера с максимальной эффективностью и достоверной экспертизой.

Что же выбрать из SAST? Мы также подобрали несколько решений из топ-10 и начали исключать те, что не соответствуют нашим требованиям: OpenSource, бесплатный, число поддерживаемых языков, скорость сканирования. В подходящую выборку попало всего два инструмента: Horusec и Semgrep. Что примечательно, Semgrep выбрали «классические» специалисты AppSec, Horusec — специалисты AppSec мобильной разработки, поскольку присутствовала поддержка языка DART.

Тут я бы хотел добавить, что периодически необходимо проводить анализ этих сканеров. В настоящее время в Semgrep появился язык DART, и, возможно, вы будете использовать другую конфигурацию сканеров. Периодически проводите исследования в части эффективности и соответствии требованиям не реже чем раз в 2 месяца.

Аналогичное исследование мы проводили относительно SCA/OSA. Всего было пять решений, из которых выбрали два. Причем Dependency‑Track выбрали AppSec, Dependency‑Check — «мобильные» AppSec.

Что выбрать из ВСА? Тут была занятная ситуация. Поскольку у нас была aqua security поддержка, я очень часто общался с архитекторами этого инструмента. В один прекрасный момент мы проводили исследование, и я заметил один момент — бесплатный Trivy на тот момент находил больше уязвимостей чем проприетарный движок непосредственно в Aqua. Я задал вопрос инженерам Aqua, почему OpenSource работает лучше чем‑то, что мы покупаем. Инженеры попросили подождать релиза. Спустя месяц выходит релиз, и мы узнаем, что aqua купила Trivy, и теперь движок Trivy находится непосредственно у aqua.

Нас попросили в итоге просто переключиться на движок Trivy. Мы так и сделали! В итоге Trivy полностью подошел под все наши требования, на нем и остановились.

После того как мы получили ASOC и определились со сканерами мы поняли, что ASOC у нас будет критически важным компонентом, который нужно усиленно защищать. В системе есть уязвимости, поскольку есть лица, заинтересованные в том, чтобы заафектить там данные. Если разработчики, получат доступ по API или Web, то могут скомпрометировать или изменить данные как им будет нужно.

Какие мероприятия были проведены.

• Аутентификация и авторизация. Мы настроили интеграцию с LDAP, определили ролевые модели и включили доступ по API.

• Защита flow от отключения проверок ИБ. У нас есть собственная интеграционная платформа (ИП) 2.0. Команда SRE управляет Flow сборки и доставки. Мы пришли к SRE и спросили, могут ли они гарантировать, что если мы придем к ним и встроим наши проверки в их базовые flow, то они будут неотключаемыми. Нам ответили, что да — это была гарантия для нас.

• Шифрование данных, защиту от CSRF‑атак, валидацию входных данных, ограничение запросов мы также перенесли на сторону ИП 2.0. Мы пришли туда как клиенты и фактически стали бэкендом платформы. Платформа поставляет для нас Ingress и DNS.

• Мониторинг и журналирование настроены на нашей стороне, поскольку там тоже могут храниться конфиденциальные данные.

• Обновление и патчи.

• Сегментация сети со стороны инфраструктурных инженеров.

• Безопасность хранилища и бэкапы с шифрованием данных мы используем свои, т.к. бэкапы содержат критическую информацию.

• Аудит. Проводим регулярно аудит журналов безопасности. Если есть вещи, выходящие за пределы наших политик, разбираемся.

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

Дополнительно нам нужно было выяснить скорость языков программирования, на которых мы будем писать внешнюю обвязку вокруг сканирующего элемента. В данном случае, если есть возможность не переиспользовать библиотеки Python (на котором, допустим, написан сканер), то мы будем использовать тот же самый Bash. Мы боремся за каждую секунду, чтобы сканирование проходило максимально быстро.

После встраивания первых проверок в dev среду мы сразу получили шквал негатива со стороны разработчиков. Проверки даже в течение 10 минут очень сильно замедляли работу. Все дело в том, что разработка мержится очень часто (20–30 раз в день). Это очень большое суммарное время в течение дня. Посовещавшись, мы решили, что есть смысл сделать наши проверки мануальными. Разработчики согласились этот кейс перевести на себя, поскольку им так удобнее.

Второй момент, с которым мы столкнулись — где показывать разработке результаты. Есть много вариантов, например: почта, телеграм, внутренние мессенджеры и так далее. Мы решили результаты сканирования отправлять непосредственно в саму GitLab джобу. Это оказалось предельно удобно. Разработчик запустил скан, скан закончился, разработчики провалились в джобу, получили отчет, проанализировали, пофиксили уязвимости, перезапустили сборку, и все счастливы. ИБ‑специалисты также получают результаты запущенных разработчиками сканирований.

Ниже представлен flow с последовательно выполненными проверками ИБ. В данном случае прослеживается принцип shift‑left. То есть мы привлекаем команду на ранних этапах разработки. Если не проходит какая‑то практика, мы ломаем пайплайн.

Обратите внимание, что шаги в данном flow уже не отключаемые, а также посмотрите на шаг bca_trivy. Он подсвечен восклицательным знаком. Это говорит о том, что Quality Gates по этой практике не были пройдены и нужно провалиться в отчет, проанализировать результаты и исправить уязвимости.

Следующий возможный вариант реализации flow в предпрод и прод это параллельно‑открепленные проверки. В данном случае выполняется два flow параллельно. Мы не изменяем наш классический flow сборки и доставки. Мы запускаем параллельно flow с практиками DevSecOps, что позволяет уменьшить время сканирования. Но есть и большой минус: если Quality Gates не пройдены приходится ломать сборку на последнем этапе — публикации в прод.

Разработчики, как правило, очень недовольны. Но есть практики, которые очень долго сканируются. Например, DAST сканируется час и более. Параллельно‑открепленные flow и лучше использовать, если нужно много времени на сканирование.

Особенности построения gitlab CI flow для проверок ИБ

• Принцип Shift‑Left. Привлекаем команду на ранних этапах.

• Фоновые проверки ИБ там, где не можем обеспечить минимальное время этих проверок.

• Нужно выполнять дедупликацию дефектов.

• Отчеты для разработчиков в той среде, где работают разработчики, в данном случае это GitLab.

• Код не покидает контура.

• Единый пайплайн для всего. У нас есть базовые пайплайны, по которым катится весь продакшен.

• Формат результатов сканирований понятен и разработчику, и специалисту ИБ.

Для устранения дубликатов обнаруженных уязвимостей первое, что мы сделали — определили минимальный набор базовых и инфраструктурных образов, которые будут использоваться для сборки и доставки микросервисов в соответствующее окружение. Второе — построили бизнес‑модель выкладки в предпрод и прод, используя процессы наследования артефактов. Ввиду того, что у нас базовые образы, у нас что в dev, что в rc что в prod ветках будут одни и те же уязвимости. Включив дедубликацию на уровне application или микросервисов в ASOC‑системе, мы от них избавимся.

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

В итоге получилась следующая структура ИБ‑платформы. В CI/CD запускается процесс сборки и доставки. Тут же запускаются сканеры, отправляющие результаты в ASOC‑систему. Управление сканерами происходит с использованием внешних.yml манифестов, в которых непосредственно хранится конфигурация. Опять же, это очень удобно с точки зрения того, что мы можем управлять сканерами на лету. В ИП 2.0 (на изображении App.Farm) у нас хранятся данные об информационных системах и каким образом у нас собираются микросервисы в эти информационные системы. Нам тоже очень важно иметь эту информацию о владельцах информационных систем, то есть о тех, к кому мы пойдем, если найдется какая либо серьезная уязвимость.

После того, как ASOC обработает наши результаты, дедублицирует и проведет корреляцию, проанализирует Quality Gates, если они не пройдены создается задача в Jira на конкретного ИБ‑инженера. Мы также подключили в эту схему BI‑систему, поскольку отчеты, которые строит сам ASOC, достаточно скудные, и нам нужна более гибкая аналитическая система.

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

Пример

Статус: Готово
Приоритет: Высокий
Компоненты: SECOPS
Метки: #secopsops #defectdojo #CVE-2023–0401 #alpine #os‑pkgs #Справочники(ID_17 173)
Information system: IPS
Technical Contact: Михаил Синельников
Title: CVE-2023–0401 Libssl3 3.0.7-r0
GitLab link: https://gitlab.xxx.ru/rshbintech/it‑invest/ckips/ips/frm/dictionary
Defect Dojo link: https://defect‑dojo.xxx.ru/finding/488 783
Severity: High
Due Date: Dec. 23, 2022
CWE: CWE-476
CVE: CVE-2023–0401
CVSSv3 Score: 7.5
Product/Engagement/Test: Справочники (ID 17 173) / Олег Проскоряков <p@xx.ru> (ID 435 124) / Trivy Scan
BuildID: 435 124
Commit hash: 6baf3d7e
Vulnerable Component: libssl3 — 3.0.7-r0
Description:
openssl: NULL dereference during PKCS7 data verification
*Target:* registry.xxx.ru/rshbintech/frm/dictionary:1.0.0-RC1 (alpine 3.17.0)
*Type:* alpine
*Fixed version:* 3.0.8-r0
Mitigation: Done
References: https://access.redhat.com/errata/RHSA-2023:0946
https://access.redhat.com/security/cve/CVE-2023–0217

Поясню пункты.

Статус — естественно, всегда необходимо знать статус задач.

Приоритет — зависит непосредственно от уровня или критичности каких‑либо уязвимостей.

Компонент — тоже интересен, поскольку у нас три отдела безопасников: AppSec, мобильные AppSec, SecOps. Если этого раздела не будет, то станет непонятно, к кому относить проблему.

Метки — важный момент, необходимый для фильтрации данных. Мы можем выстроить все по конкретному микросервису, например, отфильтровать по «Справочники».

Информационная система — для нас это верхнеуровневый компонент в нашей отчетности и понимании процессов в целом.

Технический контакт — специалист, отвечающий за разбор уязвимости. Эта информация мапится автоматически из ASOC.

Тайтл — указывает на уязвимые компоненты.

GitLab link и Defect Dojo link — соответственно, ссылки для перехода на ASOC‑систему и GitLab. Очень часто используются теми, кто разбирает уязвимости, связанные с SAST практикой. Описание в задачах, как правило, довольно скудное, поэтому ссылки на первоисточник позволяют восполнить знания.

Severity — уровень уязвимости + описание Due Date, CWE, CVE, CVSSv3 Score.

Product/Engagement/Test — связка микросервиса, пайплайна, кто и когда запускал, id пайплайна и какой тест проходил в этот момент.

BuildID и Commit hash — храним Commit hash чтобы однозначно идентифицировать и не потерять связь с flow.

Пункты Vulnerable Component, Description, openssl, *Target, *Type включают описание уязвимого компонента и краткое описание самой уязвимости, а Fixed version позволяет достаточно быстро определиться с тем, какую версию и каким образом мы будем фиксить.
References — ссылки для получения информации об уязвимости из первоисточников.

Вот такой темплейт у нас получился. Он у нас хорошо работает и позволяет эффективно устранять дефекты в трекере.

Пару слов о построенной нами платформе. Сейчас в нашей ИБ‑платформе на обслуживании находятся 50 информационных систем, включающих 750 микросервисов. У нас большой стек (вы его уже видели), три окружения, в которых проводятся ИБ‑проверки (Dev, pred‑prod, prod). Мы проводим около 300 мержей в день и находим около 70 уязвимостей критического и высокого уровня в день, более 70% дубликатов обрабатываем автоматически. Все это выполняет всего 5 AppSec и 2 SecOps специалиста.

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

Остается вопрос — как оценить эффективность работы? Все что‑то делают, работают, но на каком этапе мы находимся? Может нам еще триажить лет 20, и мы только в самом начале пути. Для этого у нас есть BI‑система. Ниже представлен пример отчета по числу обнаруженных дефектов и закрытых уязвимостей. То, что графики сходятся, говорит о том, что наши безопасники очень хорошо трудятся, и все фиксится вовремя.

Через BI также можно посмотреть аналитику по уязвимостям в информационных системах. Прошу обратить внимание на количество дубликатов. Кто‑то говорит, что в ASOC не работает схема с удалением дубликатов. Если применить методики, которые я описал, все работает.

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

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

И, напоследок, аналитика по работе непосредственно ИБ‑специалистов. Такая же аналитика есть по времени устранения дефектов, времени и жизни дефектов и так далее.

Закончу материал на выводах и рекомендациях.

• Выбор инструментов безопасности — ответственный момент. От него зависит эффективность и качество защиты систем от угроз и уязвимостей. Если вы ошибетесь при выборе инструментов, можно считать, что вы ничего не делали и не строили.

• Оптимизация процессов безопасности — ключевой фактор для повышения эффективности защиты систем.

• Грамотно построенный пайплайн ускоряет процесс проверки.

• Недостаточно просто создать ИБ‑систему — ее нужно правильно защищать. Об этом нужно думать заранее.

• Хорошая система ИБ — это информативная и понятная система для бизнеса, разработчиков и ИБ‑специалистов.

• Правильно построенная ИБ‑система может быть запущена в кратчайшие сроки (мы запустили за два месяца) и обслуживаться небольшой командой инженеров.