Колядка про Vulnerability Management "Пропатчите уязвимость". 🙂 Наигрывал сегодня разные новогодние и рождественские песенки, и мне пришла в голову идея, что "We Wish You a Merry Christmas" с требованием инжирного пудинга отличное описывает процесс пушинга исправления критичных уязвимостей.
Что, в общем, и накидал по-быстрому. Подозреваю, что это первая песня, которая упоминает "НКЦКИ". 😅
Поздравляю всех с наступающим Новым 2024 Годом! Всем здоровья, счастья и интересных задачек! Ура! 🎄🎉
Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X
🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"
Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.
00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании MongoDB
05:35 Декабрьский Linux Patch Wednesday
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23-01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р-ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rockstar Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало - Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024-м году
59:24 DevSecOps Maturity Model 2023
1:01:25 Прощание в стихах от Mr. X
ФСТЭК России 50 лет! Сегодня день основания Гостехкомиссии СССР (18 декабря 1973), которая в итоге превратилась во ФСТЭК. С праздником, коллеги! 🎉
ФСТЭК это главный российский регулятор в области Управления Уязвимостями:
🔸 Руководство по организации процесса управления уязвимостями в органе (организации)
🔸 Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств
🔸 База угроз и уязвимостей; регламент добавления
🔸 Бесплатный сканер уязвимостей ScanOVAL
🔸 ГОСТ Р 56546-2015 Классификация уязвимостей информационных систем
🔸 ГОСТ Р 56545-2015 Правила описания уязвимостей
🔸 Методика тестирования обновлений безопасности программных, программно-аппаратных средств
Испытал вчера wow-эффект от того как бесплатный AI сервис для написания кода переписал мой Bash-скрипт на Python. Bash-скрипт был примитивный: скачать zip-архив с XML-выгрузкой из БДУ ФСТЭК, распаковать, поискать уязвимости, которые были добавлены в этом году. Я такое накидываю быстро и на автомате. Расплачиваюсь за это последующим рутинным переписыванием на Python. 😕 Автоматизированную же трансляцию толком не сделаешь - слишком много утилит и их особенностей. Или сделаешь? 😏
На удачу забил этот bash-скрипт в сервис с комментарием "rewrite in python" и железяка практически справилась. 🤩 Скачала архив по урлу, распаковала, циклически прошлась по файлу и поискала то, что нужно. Было только несколько минорных ошибок. Magic. 🪄
Продолжу эксперименты с чем-то посложнее, с кучей sed-ов и awk. Но похоже, что будет можно по кайфу фигачить парсеры на Bash-е и влегкую превращать это потом в приличный Python. 😊 Если не прямо сейчас, то в обозримом будущем.
Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке. Гостями подкаста в этот раз были Сергей Алешинский и Андрей Исхаков из ПСБ (Промсвязьбанк). Т.к. я тоже 6 лет VM-ом в банке занимался, было интересно послушать. 🙂 Выписал некоторые тезисы.
1. IT стремятся занять позицию "давайте мы сейчас построим, а потом вы к нам придёте, мы вас послушаем и может быть что-то поправим". ИБ должны не допускать такого.
2. VM это прежде всего процесс взаимодействия людей. Важно уметь договариваться, в том числе на уровне руководства. Необходимость VM следует доносить грамотно, аргументированно и регулярно.
3. Доказывать необходимость исправления уязвимостей непросто, но это развивает технически и IT, и ИБ.
4. В ПСБ был выстроенный процесс обновления десктопов (АРМов), но после 22 года он усложнился. Теперь есть команда в составе RedTeam, которая проверяет обновления и новые версии западного ПО на закладки (дополнительно к проверенным обновлениям из БДУ). Также проходят проверки и собственные разработки.
5. Также применяется исправление уязвимостей путем отказа от legacy систем или внедрения компенсирующих мер (аудит сетевых подключений, максимальное урезание интеграций, обслуживание через терминальные станции).
6. Есть проблема с отсутствием бюллетеней безопасности отечественных вендоров. Отечественных вендоров СЗИ/САЗ это тоже касается.
7. Категоризация активов по сегментам, бизнесам, выделение наиболее критичных скоупов (например, DMZ).
8. Категоризация уязвимостей по автоматизированной методике оценки критичности уязвимостей ФСТЭК.
9. В идеале информацию об активах нужно забирать из супер-актуальной CMDB, которую обслуживает IT. А ИБ должна проводить поиск теневых активов в факультативном режиме. На практике вовлеченность ИБ в поиск проблем CMDB выше, в т.ч. приходится самим искать владельцев систем и обслуживающих подразделений. Периодичность рескана фиксируется в документации на IT-систему. Статус комплаенса систем будет виден на уровне CMDB. Необходимо внедрять VM в ITSM.
10. Проводится сканирование периметра извне. Необходимо следить за состоянием внешних сканеров, т.к. они зачастую добавлены в white list. Для внутренних сканеров, проводящих сканирование с аутентификацией, это ещё более критично.
11. У каждого компонента IT-систем есть утвержденный стандарт настроек. Разработка стандартов настроек выполняется внешней организацией. Проверки на соответствие реализуют сами. Конкретные требования зависят от контура, в котором находится сервер. Желательно иметь возможность перенести этот набор скриптов в VM-решение.
12. Этапы процесса Управления Соответствием: утверждение стандарта, тестирование на ограниченном скоупе, расширение скоупа и контроль соответствия. Центр IT-архитектуры утверждает единый тех. стек допустимых технологий. Его необходимо ограничивать и иметь в виде реестра а-ля CMDB. Проблема расширения стека (в глобальном смысле) это и проблема VM-вендора, который должен уметь всё.
13. При наслоении стандартов (например, ОС и СУБД) могут быть конфликты. Отхождения от стандарта должны согласовываться и журналироваться.
14. Трендовые уязвимости на периметре фиксятся оперативно без формального обоснования критичности. Согласование в рамках конфколла. Но тестирование патча на ограниченном скоупе всё равно необходимо выполнять.
15. Еженедельные отчёты: новая инфраструктура введенная в эксплуатацию, какая инфраструктура прошла проверки, какие уязвимости выявлены с приоритизацией. Отчёты также нужны для аудиторов.
16. Нужно стремиться к открытости VM-решений: полнота базы знаний детектов, обязательство поддерживать API-интеграции.
Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости. Гостями подкаста в этот раз были Юрий Шкодин и Егор Подмоков из PT Expert Security Center (ESC). Для меня особенно интересный эпизод, т.к. ответ на вопрос куда именно в PT я вышел - вот конкретно к ним. 🙂 Выписал некоторые тезисы.
1. Трендовые уязвимости - уязвимости, которые эксплуатируются сейчас (на которые есть эксплоиты) или которые будут эксплуатироваться в ближайшее время. Это те уязвимости, на которые заказчики должны обратить внимание в первую очередь в своей инфраструктуре.
2. Трендовых уязвимостей не должно быть везде в инфраструктуре или только в DMZ? Дискуссионный вопрос, нужно исходить из модели рисков. Трендовая уязвимость на тестовом стенде внутри IT-инфраструктуры это не очень важная уязвимость.
3. Трендовость Уязвимости зависит от уязвимого продукта. Они могут быть очень специфичными: Church Management система, управления автомобилями и т.п. Необходимо учитывать реальные возможности по детектированию. Продукты, которые неинтересны ни нам, ни заказчикам, мы добавляем в black list, который, при необходимости, пересматриваем.
4. Исходные данные для оценки трендовости собираем из баз уязвимостей, бюллетеней безопасности вендоров, социальных сетей и мессенджеров, баз эксплоитов, публичных репозиториев кода.
5. Фолзы детектов уязвимостей, отчего они? Например, в детекте уязвимостей Windows по KB-шкам. Могут быть ошибки роботов-сборщиков данных. Может быть задержка реагирования на изменение в контенте вендора. Может быть вендор ПО предоставляет информацию об обновлениях недостаточно прозрачно.
6. Форки Open Source продуктов, которые не фиксят и не сообщают об уязвимостях исходного продукта. Призываем вендоров за этим следить. И желательно, чтобы вендоры публиковали информацию о своих уязвимостях в одном месте, идеально в БДУ ФСТЭК.
7. Сложности с детектами. Версионные детекты: уязвимость в выключенной фиче или выключенном ПО это уязвимость? Детекты с эксплуатацией: проверка не сработала, а насколько этому можно верить? Насколько правильно проверки реализованы и на основе каких эксплоитов?
8. Пользовательские детекты для софтов и уязвимостей - крутая тема. Идём в эту сторону.
9. Для отладки детектов необходимы реальные стенды с уязвимыми продуктами. Здесь вопросы с оценкой популярности софта (невозможно поддерживать всё) и нотификациями о выпуске новых версий софта. В эти темы тоже идём.
10. Доставка трендовых уязвимостей в MP VM за 12 часов. Трендовые уязвимости, как правило, начинают эксплуатировать через 24 часа (плюс это требование ФСТЭК из методики оценки критичности). Из них 12 нужно VM вендору на реализацию проверки и 12 нужны клиенту на детекты и исправление. Для более быстрой доставки идём к тому, что в базе MP VM будут все уязвимости, не только те, для которых есть детекты. Нужно будет только быстро добавлять детекты (возможно силами самих клиентов). Ассетная модель позволяет получить сработки без пересканирования по имеющимся данным.
11. BugBounty может использоваться для контроля известных уязвимостей сетевого периметра и выполнения SLA (например хантер может сдавать известные уязвимости старше 30 дней).
12. HCC PT Essentials это минимальный набор требований к конфигурациям, которые обязательно должны выполняться. Идём в сторону возможности реализовывать свои проверки.
13. Идеальный VM вендор. Прозрачность по текущим и будущим фичам (открытый roadmap). Улучшение покрытия продуктов. Самостоятельность заказчиков в плане наполнения базы знаний уязвимостей и детектов, возможность делиться этим контентом через маркетплейс. Метапродукты работающие с минимальным количеством людей. Автоматизированное исправление уязвимостей с аппрувом от IT.
1 ноября официально вышел CVSS v4.0, который и так-то никому не нужен, а особенно он не нужен в России. Технические детали были известны ещё у июне, так что тут мало интересного. В чём там суть? Есть такая организация FIRST (пионЭры). Они с 2005 года занимаются развитием стандарта CVSS для оценки уязвимостей через заполнение опросников. Тема прижилась, стала использоваться в американской National Vulnerability Database, где можно бесплатно получить оценки для CVE уязвимостей в формате CVSS (только базовые метрики).
В принципе и отлично. Но нет покоя одержимым и FIRST периодически выкатывает новую версию CVSS. Причём каждый раз всё более сложную и несовместимую с предыдущей. Строго говоря, нельзя автоматом получить CVSS v3/3.1 из CVSS v2 и наоборот, нужно садиться и перезаполнять опросник. И не просто заполнять, а ориентируясь на разъяснения и примеры заполнения указанные в стандарте.
И ладно бы ещё результат этой оценки был годный, так нет. Поныть на тему того, что оценки по CVSS это какая-то субъективная ерунда это любимое развлечение безопасников. Аз грешный и сам в этом был неоднократно замечен. Достаточно просто погуглить "CVSS critique", чтобы погрузиться в пучины отчаянья.
Станет ли CVSS 4.0 лучше? Посмотрим. Но, имхо нет, т.к. CVSS остаётся таким же опросником, заполняемым субъективно, но теперь несколько иначе и сложнее. Теперь исследователям и аналитикам NIST NVD придётся разобраться в правильном заполнении очередного опросника. Естественно только базовых метрик - остальным никто опять по собственной воле пользоваться не будет. 🙃 На NVD для старых уязвимостей будет только заполнение на CVSS 2.0/3.0/3.1, для новых с какого-то времени будет 3.1 и 4.0, потом только 4.0. Пока First через несколько лет опять всё не поменяют с новым стандартом. 😏🤷♂️
А пользователи как лазили на NVD за цифирей от 0 до 10 (Base Score), так и будут лазить. Ну да, этих цифирей теперь будет несколько для разных версий стандарта. Ну наверное будут брать по максимальной версии стандарта или по максимальному значению. 🌝
Теперь о главном: как это заденет методику ФСТЭК по оценке критичности уязвимостей. Тут, как мне кажется, могут быть 3 пути:
1) Игнор. Ну записано в методике 3.0/3.1, делаем как записано. Всё равно, что у американцев другая версия актуальная. Но понятно, что такое положение дел бесконечно продолжаться не может.
2) Признание 4.0. Ну то есть в тексте добавят 3.0/3.1/4.0 или вообще изменят на 4.0 и будьте любезны всю эту методику CVSS 4.0 для оценки уязвимостей у себя имплементировать as is (всё, а не только базовые метрики!) Кажется наиболее вероятным вариантом, хотя мне он решительно не нравится. 😔
3) Отказ от CVSS в пользу своего аналога с долгосрочной поддержкой и бережным переходом на новую версию (с возможностью автоматического пересчёта метрики). Мне кажется это был бы наиболее правильный вариант. И пусть американцы меняют свои опросники хоть каждый месяц, если им так хочется. Вместе с прочей шизой типа переименования терминов "MiTM", "master/slave" и прочее. У них там своя атмосфера. 🤷♂️
Как можно реализовать российский аналог CVSS в щадящем режиме без особых изменений методики я уже описывал в рамках своего проекта ОСОКА: форкаем базовые метрики CVSS v3, вместо временных метрик CVSS v3 вводим свои простые и автоматизируемые метрики по эксплуатабельности (самое важное!), оформляем Iinfr в инфраструктурные метрики, делаем рекомендации как получать наши базовые метрики из базового вектора CVSS v2/3/4. Всё прозрачно и является по факту упрощением работы с методикой ФСТЭК, чем усложнением.