весь мир накроет концепция X-as-a-Code и все будет построено на контейнерах, виртуализации, облаках и т.п. Поэтому те, кто не понимает, как строить ИБ для этих сред, вымрут как динозавры… но не из-за метеорита, а за ненадобностью. Утверждение небесспорное, но задуматься о нем стоит.
Вы, вообще, изучаете современные технологии, которые используются вашей организацией, с точки зрения их защиты?
Вспоминая такое понятие как матрица RACI, пришли к выводу, что за результат борьбы с закладками должна отвечать (A — Accountable) ИБ, а непосредственно выявлять их (R — Responsible) — разработчики или, в более широком смысле, SecDevOps‘еры (хоть QA, хоть сами программисты, хоть AppSec’еры). Могут привлекаться и внешние ресурсы, так как не всегда свои разработчики способны заниматься даже Sec-частью в рамках DevOps, не говоря уже и более специфичной — поиске умышленно оставленных закладок. Это, кстати, напомнило участникам дискуссии концепцию Security Champion‘ов, которые выбираются из числа рядовых сотрудников, но несущих свет ИБ в своем кругу.
Как один из вариантов от занесенных извне закладок упомянули распространенный вариант — создание локального репозитория и загрузку в него нужного open source, который будет отлеживаться какое-то время. Его же можно и обновлять спустя какое-то время, когда будет понятно, что новая выложенная версия ПО не содержит закладок и ее используют многие компании по миру. Также возможный вариант — создание форков используемого ПО, но это работает только при наличии нормальных разработчиков и приводит к тому, что уже новые обновления внешнего ПО вряд ли будут применимы к форку.
Помимо закладок в open source обсудили и возможные закладки к проприетарном ПО, в том числе именитых вендоров, ушедших из России. Вспомнить о закладках с их стороны так никто и не смог (да и регуляторы говорят об этом же), но факты, произошедшие ранее, существуют (но из-за NDA не раскрываются). При этом в идеале применять к таким обновлением схожие с конвейером CI/CD принципы и в зависимости от обновления, его критичности, решаемых задач и т.п., можно «отстаивать» его на стенде, а только потом уже накатывать на всю инфраструктуру или ее часть.
Мы не успели поговорить о закладках в контенте обнаружения (помню историю в середине-конце 90-х, когда в ФИДОнет распространили обновление одного российского антивируса, содержащего исполняемый код (!), который и запустился на компьютерах, куда его закачали. Было неприятно ???? ). Но вот тут, хоть и возможно применение схожих методов анализа (например, Detection-as-a-Code ), инструментарий будет совсем иным, а то и вовсе только ручным.
Не могли не затронуть тему нормативных требований и упомянули и требования ФСТЭК по уровням доверия, и требования ЦБ по оценочным уровням доверия («профиль»), и сам ГОСТ 15408 (а профиль ЦБ далеко ушел от идей 15408), и требования МинОбороны и ФСБ (ну и ГОСТы по безопасной разработки конечно же). Прозвучала интересная мысль, что не надо читать документы регуляторов как догму и под каждый проект можно дописывать и «докручивать» имеющиеся методики, в том числе и расширяя их задачами по поиску именно закладок (все-таки некоторых из документов заточены изначально под немного иные задачи).
Кстати, много говорили про практические шаги и различные примеры, связанные с поиском закладок в зависимостях, библиотеках, коде и т.д. Идея с применением ведомости модулей и зависимостей (SBOM) признана очень правильной и хорошей; особенно автоматизация работы с ней и особенно после зимней истории с Log4J. Вообще примеров было озвучено много разных; как подходов и процессов, так и лайфхаков и трюков.
Мне перед эфиром пришла идея, что как в SOC можно использовать тесты Atomic Red Team для проверки возможности обнаружения атак или их пропуска, то аналогичные тесты можно использовать и для проверки билдов и ПО. Если многократный запуск мини-тестов дает один и тот же результат, то можно считать, что ПО ведет себя предсказуемым образом и это является некой гарантией от совсем явных проблем и закладок. Понятно, что от чего-то серьезного это не защитит, но с чего-то надо начинать (и не забываем про code review).
Наконец, не забыли обсудить и тему включения поиска закладок в процессы SOC и заведение на него решений класса SAST/DAST/IAST с последующей их отработкой на разработанных плейбуках и т.п.
Кстати, о применяемых средствах автоматизации, зарубежных и российских, коммерческих и бесплатных, проприетарных и open source, сертифицированных и нет, мы тоже говорили. И даже про сертифицированные ФСТЭК компиляторы. Но если вам нужны детали, то милости прошу на эфир. Зачем мне пересказывать все, что обсуждалось в течение более двух часов с Дмитрием Гадарем (Тинькофф Банк), Виталиев Вареницей (Эшелон) и Рустемом Хайретдиновым (BI.ZONE).
