Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте. And I invite all English-speaking people to another telegram channel @avleonovcom.

Полный CTEM

Добавить комментарий

Полный CTEM. У Дениса Батранкова вышел пост про то, что "VM больше не спасает", но есть продвинутая альтернатива - CTEM. Я своё мнение по поводу CTEM высказал в прошлом году и оно не изменилось: это очередной бессмысленный маркетинговый термин от Gartner. Всё "новое" в CTEM-е давно реализовано в VM-решениях.

Посудите сами:

🔹 Разве VM-решения детектируют только CVE и не детектируют мисконфигурации?
🔹 VM-решения приоритизируют уязвимости только по CVSS без учёта признаков наличия эксплоитов и эксплуатации в реальных атаках?
🔹 VM-щики не сканируют периметр?

Это же смехотворно. Всё это даже урезанным Nessus-ом можно делать. Апологеты CTEM придумали удобное соломенное чучело под названием "обычный VM" и решительно его побеждают. 🙂

Но заметьте о чём они молчат: о контроле качества детектирования, покрытия активов, выполнения тасков на устранение (БОСПУУ). То, что является основой, конкретно, проверяемо и требует значительных ресурсов для реализации. 😉

SOC и VOC на одном уровне?

Добавить комментарий

SOC и VOC на одном уровне? Как по мне, выделение Vulnerability Operation Center на одном уровне организационной структуры с Security Operation Center - неплохая идея.

Конечно, в SOC можно, при желании, перевести практически любые ИБ-процессы организации, включая VM. И так частенько делают. Но, думаю никто не будет спорить, что всё же основная задача SOC - детектирование инцидентов и реагирование на них. И, имхо, хорошо, когда SOC на этой реактивной функции и специализируется.

В VOC же можно собрать всё, что касается проактивной безопасности - выявление, приоритизацию и устранение всевозможных уязвимостей (CVE/БДУ, конфигураций, своего кода), технический compliance, контроль состояния СЗИ и САЗ. В общем всё то, что повышает безопасность инфраструктуры и усложняет проведение атак, а значит облегчает работу SOC. 😉

Однако структура департамента ИБ - это, часто, политический вопрос, а не вопрос практической полезности и целесообразности. 😏

Что за зверь "Vulnerability Operation Center"?

Добавить комментарий

Что за зверь "Vulnerability Operation Center"? VOC - не самый распространённый термин, но на западе встречается. Одни компании (небольшие вендоры, такие как Hackuity, Patrowl, YOGOSHA) определяют его как платформу или утилиту для управления уязвимостями, которая имеет преимущества перед "традиционными VM-решениями". Другие (сервис-провайдеры, такие как Orange Cyberdefense и Davidson), определяют VOC как структурные подразделения организаций.

Между VOC и VM примерно такая же смысловая неразбериха, как была межу SOC и SIEM. 🙂 И я склонен разрешать её аналогичным образом. VOС - структурное подразделение организации, специалисты которого реализуют VM-процесс, используя одно или несколько VM-решений для детектирования, приоритизации и устранения уязвимостей (с одним решением удобнее 🙂). VM-процесс может быть выстроен, например, в соответствии с "Руководством по организации процесса управления уязвимостями в органе (организации)" ФСТЭК и расширен с учётом БОСПУУ. 😉

Канал "Управление Уязвимостями и прочее" снова засветился в рейтинге Топ-108 лучших телеграм-каналов по ИБ

Добавить комментарий

Канал "Управление Уязвимостями и прочее" снова засветился в рейтинге Топ-108 лучших телеграм-каналов по ИБ. В категории "Авторские".

Правда, в прошлом году в аналогичном рейтинге я был на третьей позиции, а в этом уже на шестой. 😅 И даже не один, а в компании с Алексеем Комаровым и Денисом Батранковым. Но всё равно очень приятненько. 😇

Рейтинг подготовили Sachok и Пакет Безопасности. Каналы выбирались голосованием уважаемого экспертного совета. Почти Оскар, лол. 😄 Главным критерием было качество контента. Каналы ранжировались по количеству голосов в своей категории.

PS: Самый лучший канал с ИБ-мемами однозначно Memekatz. Пролистал всё до начала, орал в голосинушку. 😆

Compliance-сканирование в R-Vision VM

Добавить комментарий

Compliance-сканирование в R-Vision VM. Эта фича была в роадмапе R-Vision на Q1. Уложились. 👍

Пока реализованы только низкоуровневые технические стандарты CIS Benchmarks БЕЗ маппинга на высокоуровневые (PCI DSS, ISO 27001 и т.п.). Полный список не предоставляют, но сообщают, что это стандарты "для различных ОС Linux и Windows, сетевых устройств Cisco, ПО (Apache Tomcat, Microsoft Exchange и др.) и СУБД (Oracle, MSSQL и др.)".

Для примера показывают 16 стандартов для Ubuntu 24.04 , Rocky Linux 8/9, RHEL 8/9, Microsoft Windows Server 2016/2022, Windows 10/11, Cisco NX-OS, Cisco IOS XR7.x/XE17.x/17.x, Cisco ASA.

❗ Есть возможность загружать собственные проверки в YAML файлах. Формат немного напоминает Wazuh SCA, но не он. Вполне вероятно, что формат кастомный. Стандарты CIS из коробки реализованы на таких же ямликах. Формат гибкий. Например, позволяет проверять переменные, инициализируемые результатами выполнения команды на хосте (sshexec). 👍

О сертификации VM-продуктов по качеству детектирования

Добавить комментарий

О сертификации VM-продуктов по качеству детектирования. Моё мнение - такая сертификация должна быть. Добровольная или обязательная, государственная или негосударственная. Но хоть какая-то должна быть. Это ненормально, когда вендор может начать продавать буквально любой треш, а задача оценки качества детектирования уязвимостей (равно как и ответственность в случае инцидента) целиком ложится на клиента. 🤷‍♂️ Рыночек тут не порешает.

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

И тут встают очень интересные вопросы:

🔹 Какая инфраструктура типичная? Кто это может решить? У кого есть такая статистика?

🔹 Результаты работы какого средства детектирования (с каким движком и контентом) должны браться за эталон?

🔹 Как будут решаться спорные вопросы?

Если с этим определиться, то создание автоматических тестов становится делом техники.

Мартовский Linux Patch Wednesday

Добавить комментарий

Мартовский Linux Patch Wednesday. Всего уязвимостей: 1083. 😱 879 в Linux Kernel. 🤦‍♂️ Для двух уязвимостей есть признаки эксплуатации вживую:

🔻 Code Injection - GLPI (CVE-2022-35914). Старая уязвимость из CISA KEV, но впервые была исправлена 3 марта в Linux репозитории RedOS.
🔻 Memory Corruption - Safari (CVE-2025-24201). В Linux репозиториях исправляется в пакетах WebKitGTK.

19 уязвимостей с признаками наличия публичного эксплоита. Из них можно выделить:

🔸 Remote Code Execution - Apache Tomcat (CVE-2025-24813)
🔸 Command Injection - SPIP (CVE-2024-8517)
🔸 Memory Corruption - Assimp (CVE-2025-2152)
🔸 Memory Corruption - libxml2 (CVE-2025-27113)

Для уязвимости Elevation of Privilege - Linux Kernel (CVE-2022-49264), своего эксплоита пока нет, но в описании обращают внимание на то, что уязвимость напоминает известный PwnKit (CVE-2021-4034).

🗒 Полный отчёт Vulristics