Управление Уязвимостями и прочее

ITшникам не до уязвимостей. Мне написал подписчик, которого триггернули мои слова в посте про Vulnerability Management как порождение хаоса в IT.

"Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. "

Привожу его сообщение: "У меня есть некоторый опыт работы в ИТ, включая ИБ-шные компании. ИТ нужна не живительная стимуляция со стороны, а ресурсы и нормально простроенные процессы. Я не видел ещё ни одной конторы, в которой бы подразделения ИТ не были бы тотально перегружены (из-за нехватки людей, большого количества задач или неудовлетворительной организации процессов их работы — в частности, недостаточного внимания к автоматизации IT ops. Потому что в условиях, когда критериями является "чтобы не падало", и чтобы никто не жаловался [на сроки исполнения]", и очередь задач в десятки на одного сотрудника — совсем не до VM. Вспоминаются слова одного руководителя ИБ-шной компании: "Смотрю я на наше ИТ, и постоянно возникает желание разгонать всех нахер, и нанять других, порасторопнее". В то время как ИТ страдала совсем не от недостатка расторопности — люди херачили днями и ночами." Полностью согласен. Проблема не в том, что специалисты не осознают важность исправления уязвимостей, а в процессах организации. Они строятся таким образом, что ITшникам становится совсем не до уязвимостей. И не до информационной безопасности в целом. 🤷‍♂️ @avleonovrus #VMprocess #ITops #ITchaos #feedback

Linux Patch Wednesday: вот где этот майский пик! 🤦‍♂️ Помните, я в посте про майский Linux Patch Wednesday радовался, что, несмотря на введение правила по Unknown датам, пик в мае был незначительный. Хотя "32 406 oval definition-ов без даты получили номинальную дату 2024-05-15". Оказалось пик не был виден из-за ошибки в коде. Ба-дум-тсс! 🥸🤷‍♂️ То, что не все CVE-шки у меня попадаются в LPW бюллетени, несмотря на введение номинальных дат, я заметил на примере громкой уязвимости Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086), которой действительно нигде не было. Подебажил функцию распределения по бюллетеням, добавил тесты. Добился того, что все 38 362 CVE-шки из Linux-ового OVAL-контента действительно раскидываются по бюллетеням. Включая CVE-2024-1086. Вот она в феврале:

$ grep "CVE-2024-1086"  bulletins/*
bulletins/2024-02-21.json:        "CVE-2024-1086": [
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",

Ну и пик в мае действительно есть. Да ещё какой! 11 476 CVE! 😱 Настолько много, что я перегенерил Vulristics отчёт для него только с использованием 2 источников: Vulners и БДУ. И даже из Vulners данные подгружались не быстро. В отчёте 77 уязвимостей с признаком активной эксплуатации вживую и 1 404 уязвимости с эксплоитами, но без признаков активной эксплуатации. Т.к. по больше части это уязвимости старые, для которых просто не было понятно когда именно они были исправлены, например, Remote Code Execution - Apache HTTP Server (CVE-2021-42013), я не буду подробно их разбирать - кому интересно смотрите отчёт. Но обратите внимание, что размер отчёта очень большой. 🗒 Отчёт Vulristics по майскому Linux Patch Wednesday (31.3 мб.) Что касается июньского Linux Patch Wedneday, который финализируется 19 июня, то там 1053 уязвимости. Тоже довольно много. Почему так? С одной стороны правило по Unknown датам добавило 977 Debian-овских OVAL дефинишенов без даты. Не 30к, как в мае, но тоже значительно. Из 1053 уязвимостей 855 это уязвимости Linux Kernel. Причём, довольно много "старых" идентификаторов уязвимостей, но заведенных в 2024 году. Например, CVE-2021-47489 с NVD Published Date 05/22/2024. 🤔 Что-то странное творит CNA Linux Kernel. 🔻 С признаками эксплуатации вживую опять Remote Code Execution - Chromium (CVE-2024-5274, CVE-2024-4947), как и Microsoft Patch Tuesday. Судя по данным БДУ, Remote Code Execution - Libarchive (CVE-2024-26256) также активно эксплуатируется. 🔸 Ещё 20 уязвимостей с публичным эксплоитом. Можно подсветить отдельно Remote Code Execution - Cacti (CVE-2024-25641) и Remote Code Execution - onnx/onnx framework (CVE-2024-5187). В следующую среду я, по техническим причинам, отчёт по июньскому Linux Patch Wednesday выпускать не буду. Обновлю позже. 🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday (4.4 мб) @avleonovrus #LinuxPatchWednesday #Vulristics #NVD #Linux #Cacti #onnx #Chromium #Libarchive #OVAL #Apache #БДУ #BDU

Коллеги из команды MaxPatrol SIEM-а запилили офигенные скетчи про самопальный SIEM в организациях. 😁 Отсылка к культовой передаче из 90х очевидна. Мне ещё напомнило ролики "I'm a Mac I'm a PC". 🎞 Самостоятельное построение SEIM-системы 🎞 Поддержка нового источника 🎞 Мониторинг источников 🎞 Валидация событий информационной безопасности ➡️ Онлайн-запуск MaxPatrol SIEM 8.2 пройдет 27 июня в 14:00, регистрируйтесь! Надо бы по самопальному VM-у подобные придумать. 😅 Есть идеи, что можно было бы обыграть? Пишите в комментарии. @avleonovrus #PositiveTechnologies #MaxPatrolSIEM #SIEM

Резко повысилась критичность уязвимости Elevation of Privilege - Windows CSC Service (CVE-2024-26229). Уязвимость из апрельского Microsoft Patch Tuesday. В апреле эту уязвимость вообще никто не подсвечивал. "На Танечку внимания никто не обращал" (c) Microsoft про неё писали "Exploitation Less Likely". Известно было только то, что в случае успешной эксплуатации злоумышленник может получить привилегии SYSTEM. Но через 2 месяца, 10 июня, на GitHub появился рабочий эксплоит. 🤷‍♂️ Сюрприз! Критичность уязвимости скачкообразно повысилась. Можно было это как-то прогнозировать? Имхо, вообще никак. Ещё одно подтверждение, что прогнозирование трендовости это, конечно, хорошо и правильно, но регулярный безусловный патчинг согласно установленному SLA (AIT) не отменяет. Небольшая подробность. Автор эксплоита уточнил CWE уязвимости. Было: CWE-122 - Heap-based Buffer Overflow Стало: CWE-781 - Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code @avleonovrus #CSC #Microsoft #Windows

До End of Life CentOS 7 осталось 2 недели. Самое время проверить не осталось ли где-то в инфраструктуре хостов с этой операционной системой. Куда мигрировать с CentOS 7 не особо понятно. RedHat превратили CentOS в нестабильный дистрибутив CentOS Stream и начали бороться с традиционными альтернативами в виде Alma и Rocky. Можно, конечно, посмотреть в сторону SberLinux и Роса «Кобальт», но, имхо, будущее RPM-based дистрибутивов в России достаточно туманно и стоит целиться скорее в Астру или Альт. Судя по статистике, в мире в основном бегут на Ubuntu. @avleonovrus #Linux #RHEL #RedHat #AlmaLinux #RockyLinux #CentOS #CentOS7 #CentOSStream #SberLinux #ROSALinux #AstraLinux #ALTLinux #Ubuntu

Vulnerability Management как порождение хаоса в IT. Тема очевидная и несколько избитая. Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. 🤷‍♂️ А как бы было хорошо: ITшники сами устанавливают регламент по обновлениям (включая экстренные обновления) и сами следят за его выполнением, сами разбираются в харденинге и внедряют его. А ИБ только периодически проводят аудиты и поражаются насколько же всё грамотно выстроено и работает как отлаженный смазанный механизм. И, со слезами умиления на глазах, закупают ITшникам всякие вкусняшки, поют соками-водами и долго трясут руки героям невидимого фронта. Нет, без шуток. Мой идеальный VM это полное отсутствие VM-а вообще, ввиду его ненужности, ведь безопасность в организации наступает сама, by design, без каких-либо избыточных костылей. Но вот что-то в реальной жизни так решительно не получается. И чем больше масштаб организации, тем больше хаоса, адища, скверны и пагубы там образуется со временем. Возможно оттого, что цели разные. У кого-то учёт в рублях, а у кого-то в сутках. Когда в IT платят за то, чтобы просто надёжно работало, нужно быть отбитым фанатиком, чтобы ещё и по собственной инициативе постоянно обновлять своё хозяйство для исправления уязвимостей. Сложная задача становится сложной задачей со звёздочкой. И зачастую без какой-либо положительной мотивации, скорее наоборот - втыки за то, что опять что-то отъехало после обновления. И всё равно продолжать это делать. Потому, что "так надо", "так правильно". Мало таких буйных и не надолго их хватает. Поэтому дорога одна - вниз, в адище и хаос. Из которого, после инцидентов или под воздействием регуляторной дубины, рождается то, что должно с ним как-то бороться - Vulnerability Management. Порождение по природе своей ограниченное, компромиссное и неполное. Ну а что вы хотели? От осинки не родятся апельсинки. По определению неполная база известных уязвимостей становится отправной точкой для ещё более неполной базы уязвимостей с формализованными детектами. Детектами, которые не всегда могут достоверно найти уязвимость ввиду многообразия способов установки ПО. Затем набор продетектированных уязвимостей о большей части которых неизвестно вообще ничего: "а ну малыш, давай, попробуй отгадай" какая из них станет трендовой завтра. 🙂 Чистый кайф. И, к сожалению, ничего лучшего для борьбы с IT-хаосом пока не придумали. 🤷‍♂️ @avleonovrus #VMprocess #ITchaos