Колядка про Vulnerability Management "Пропатчите уязвимость". 🙂 Наигрывал сегодня разные новогодние и рождественские песенки, и мне пришла в голову идея, что "We Wish You a Merry Christmas" с требованием инжирного пудинга отличное описывает процесс пушинга исправления критичных уязвимостей.
Что, в общем, и накидал по-быстрому. Подозреваю, что это первая песня, которая упоминает "НКЦКИ". 😅
Поздравляю всех с наступающим Новым 2024 Годом! Всем здоровья, счастья и интересных задачек! Ура! 🎄🎉
ИБшники радостно перекидывают друг другу pdf-ку с новогодним поздравлением якобы от НКЦКИ, оформленным под бюллетень безопасности. Хотя на safe-surf такого бюллетеня с поздравлением нет. 🧐 Не буду утверждать, что конкретно эта pdf-ка зловредная. Но выглядит как идеальная тема для атаки на российских ИБшников, пока они на расслабоне. ИБшник, бди!
Upd. По поводу данного конкретного кейса пишут, что pdf-ка прилетела в почтовой рассылке с правильного адреса, а safe-surf выкладывает всё с задержкой. 😉 Так что панику не разводим, но как возможный сценарий атаки учитываем.
Прожектор по ИБ, выпуск №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. 😊 Если не прямо сейчас, то в обозримом будущем.
Vulristics и BDU уязвимости без идентификаторов CVE. Что делать, если уязвимость содержится в базе уязвимостей БДУ ФСТЭК, но CVE-идентификатора у неё нет? Можно ли обрабатывать такие уязвимости в Vulristics?
Например, в случае с
🔻RCE в 1С-Битрикс: Управление сайтом (BDU:2023-05857)
🔻Уязвимость механизма обновления Dr.Web Enterprise Security Suite (BDU:2014-00226)
Сейчас BDU-идентификаторы можно подавать на вход Vulristics также как и CVE-идентификаторы. Обрабатываться они будут одинаково. Но так как коннектор для BDU пока не реализован, а в других источниках данных BDU-идентификаторы не упоминаются, готовые данные придётся подавать самостоятельно через Custom Data Source.
Таким образом, требуется некоторая ручная работа, но обрабатывать такие уязвимости в рамках единого workflow с CVE-шками вполне реально.
Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке. Гостями подкаста в этот раз были Сергей Алешинский и Андрей Исхаков из ПСБ (Промсвязьбанк). Т.к. я тоже 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-интеграции.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.