Инфраструктурные ИБшники скоро будут никому не нужны или как бороться с закладками в ПО?

1. Начался эфир с краткой, как выстрел, но емкой дискуссии о том, есть ли отличие между уязвимостью, НДВ и закладкой, и мы выяснили, что со стороны понять эту разницу невозможно. А так как закладка имеет явный злой умысел, то и выявить его традиционными средствами анализа исходных кодов практически невозможно. Отсюда и первый вывод:
   

   Для анализа закладок нужен не какой-то один инструмент (SAST, DAST, IAST и т.п.), а целая комплексная программа, включающая и работу с людьми, и соответствующие меры предотвращения угроз, и внешнюю оценку, и т.п. Не открытие, но все-таки!

2. Ну а раз речь идет о злом умысле, то необходимо включать в процедуру, как минимум, при работе со своими собственными программистами, такие неприятные вещи, как скрининг и профайлинг персонала. Упоминались даже такие кейсы, как ежемесячное использование полиграфа для разработчиков.
   

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

3. Помню, когда я отвечал за создание и безопасность сайта Информзащиты (во время работы в ней), мы выявили в сдаваемом коде фрагмент, по сути всего одну строчку, который отправлял все сообщения формы обратной связи разработчикам. На вопрос «Какого ***?» последовал ответ, что это была отладочная информация и ее просто «забыли» убрать из финального кода. Но интересно, что я слышал такую же историю и применительно к разработанному сайту одного, уже несуществующего российского банка, но там данные отправлялись из более критичной формы. Обращу внимание, что это был код 90-х годов — о SAST/DAST тогда еще никто не думал, хотя анализаторы кодов уже были, но редкостью. В моем случае фрагмент, который был скорее НДВ, чем закладкой, был найден в процессе ручного анализа кода (code review) и как показала дискуссия, сегодня без него при обнаружении закладок не обойтись. Возьмем известную историю от начала марта про закладку в npm-модуле node-ipc, которая удаляла файлы на инфраструктуре заказчика при условии запуска ее в IP-пространстве России и Беларуси. Я не раз слышал, что такого рода фрагмент легко вычислить автоматически, если научить SAST выявлять нужные библиотеки или вызовы. Тоже самое и с использованием Time Zone. Но я приведу другой, более свежий пример. Надо было защитить от пиратства программу на LISP для AutoCAD. И единственный приемлемый вариант, который нашелся, использовать проверку по IP. А это уже не закладка, а механизм защиты. И как делать вердикт в автоматическом режиме? Только code review.
4. Интересная мысль прозвучала относительно инфраструктурных безопасников, которые вымрут лет через 7-10, так как весь мир накроет концепция X-as-a-Code и все будет построено на контейнерах, виртуализации, облаках и т.п. Поэтому те, кто не понимает, как строить ИБ для этих сред, вымрут как динозавры… но не из-за метеорита, а за ненадобностью. Утверждение небесспорное, но задуматься о нем стоит.
   

   Вы, вообще, изучаете современные технологии, которые используются вашей организацией, с точки зрения их защиты?

5. Вспоминая такое понятие как матрица RACI, пришли к выводу, что за результат борьбы с закладками должна отвечать (A — Accountable) ИБ, а непосредственно выявлять их (R — Responsible) — разработчики или, в более широком смысле, SecDevOps‘еры (хоть QA, хоть сами программисты, хоть AppSec’еры). Могут привлекаться и внешние ресурсы, так как не всегда свои разработчики способны заниматься даже Sec-частью в рамках DevOps, не говоря уже и более специфичной — поиске умышленно оставленных закладок. Это, кстати, напомнило участникам дискуссии концепцию Security Champion‘ов, которые выбираются из числа рядовых сотрудников, но несущих свет ИБ в своем кругу.
6. Как один из вариантов от занесенных извне закладок упомянули распространенный вариант — создание локального репозитория и загрузку в него нужного open source, который будет отлеживаться какое-то время. Его же можно и обновлять спустя какое-то время, когда будет понятно, что новая выложенная версия ПО не содержит закладок и ее используют многие компании по миру. Также возможный вариант — создание форков используемого ПО, но это работает только при наличии нормальных разработчиков и приводит к тому, что уже новые обновления внешнего ПО вряд ли будут применимы к форку.
7. Помимо закладок в open source обсудили и возможные закладки к проприетарном ПО, в том числе именитых вендоров, ушедших из России. Вспомнить о закладках с их стороны так никто и не смог (да и регуляторы говорят об этом же), но факты, произошедшие ранее, существуют (но из-за NDA не раскрываются). При этом в идеале применять к таким обновлением схожие с конвейером CI/CD принципы и в зависимости от обновления, его критичности, решаемых задач и т.п., можно «отстаивать» его на стенде, а только потом уже накатывать на всю инфраструктуру или ее часть.
8. Мы не успели поговорить о закладках в контенте обнаружения (помню историю в середине-конце 90-х, когда в ФИДОнет распространили обновление одного российского антивируса, содержащего исполняемый код (!), который и запустился на компьютерах, куда его закачали. Было неприятно ???? ). Но вот тут, хоть и возможно применение схожих методов анализа (например, Detection-as-a-Code ), инструментарий будет совсем иным, а то и вовсе только ручным.
9. Не могли не затронуть тему нормативных требований и упомянули и требования ФСТЭК по уровням доверия, и требования ЦБ по оценочным уровням доверия («профиль»), и сам ГОСТ 15408 (а профиль ЦБ далеко ушел от идей 15408), и требования МинОбороны и ФСБ (ну и ГОСТы по безопасной разработки конечно же). Прозвучала интересная мысль, что не надо читать документы регуляторов как догму и под каждый проект можно дописывать и «докручивать» имеющиеся методики, в том числе и расширяя их задачами по поиску именно закладок (все-таки некоторых из документов заточены изначально под немного иные задачи).
   

   Была дана рекомендация использования фреймворка SLSA (Supply chain Levels for Software Artifacts), которая является очень полезным подспорьем при проверке кода на предмет всяких нехороших вещей.

10. Кстати, много говорили про практические шаги и различные примеры, связанные с поиском закладок в зависимостях, библиотеках, коде и т.д. Идея с применением ведомости модулей и зависимостей (SBOM) признана очень правильной и хорошей; особенно автоматизация работы с ней и особенно после зимней истории с Log4J. Вообще примеров было озвучено много разных; как подходов и процессов, так и лайфхаков и трюков.
11. Мне перед эфиром пришла идея, что как в SOC можно использовать тесты Atomic Red Team для проверки возможности обнаружения атак или их пропуска, то аналогичные тесты можно использовать и для проверки билдов и ПО. Если многократный запуск мини-тестов дает один и тот же результат, то можно считать, что ПО ведет себя предсказуемым образом и это является некой гарантией от совсем явных проблем и закладок. Понятно, что от чего-то серьезного это не защитит, но с чего-то надо начинать (и не забываем про code review).
12. Наконец, не забыли обсудить и тему включения поиска закладок в процессы SOC и заведение на него решений класса SAST/DAST/IAST с последующей их отработкой на разработанных плейбуках и т.п.

Заметка Инфраструктурные ИБшники скоро будут никому не нужны или как бороться с закладками в ПО? была впервые опубликована на Бизнес без опасности .