Gartner: Vulnerability Management - это база для обеспечения безопасности серверов и десктопов! Вместе с управлением харденингом, конфигурациями и экспозицями (весьма рад, что Александр Редчиц тоже калькирует этот термин при переводе 🙂👍).
На портале @CISOCLUB вышло большое интервью со мной "Все об уязвимостях и как ими управлять". Знаковое событие для меня. 🥳 Фактически там всё, что я сейчас считаю важным в Vulnerability Management-е.
Подробно отвечаю на вопросы:
🔹 Что такое процесс управления уязвимостями и из каких этапов он состоит?
🔹 В чём состоят сложности при выявлении уязвимостей в современных IT-инфраструктурах?
🔹 Как понять, какие активы в организации требуется покрывать VM-ом?
🔹 В чём состоят сложности детектирования уязвимостей и как оценивать полноту/достаточность способов детектирования уязвимостей для организации?
🔹 Как оценивать и приоритизировать уязвимости и все ли их нужно устранять?
🔹 Кто и как должен определять SLA по устранению уязвимостей?
🔹 Как оценивать эффективность процесса управления уязвимостями?
🔹 Какие источники наиболее эффективны для отслеживания уязвимостей в России?
Русалочка и неудачная закупка VM-решения. Ходили вчера в театр на Русалочку. По интерпретации, мягко говоря, не Дисней. 🫣 Действо максимально приближено к оригинальному тексту Андерсена. Ну, не без режиссёрских находок, конечно. Ведьма почему-то везде ходит с раком-отшельником (в прошлом тоже принцем 🤨) и делится с ним подробностями своих злодейских гешефтов. А он на это только офигивает и жалобно мычит. Жутковатая фигня. В остальном же всё близко к тексту. Финал трагический. 🤷♂️
Так вот, смотрел я эту постановку и думал, что Русалочка там похожа на VM-щика, который крайне неудачно закупил решение у VM-вендора (ведьмы). Спешил, повёлся на маркетинг. В итоге приобрёл пепяку, которой нестерпимо больно пользоваться. А функциональности её недостаточно для решения бизнес-задач. Ещё и вынужден помалкивать - бюджет-то слил и получается сам дурак, что недостаточно тестил решение перед закупкой. Приходится теперь превозмогать и плясать на том, что есть. 🕺
Сегодня на вебинаре в рамках курса Positive Technologies по Vulnerability Management-у (уже третий набор ❗️) обсуждали, в том числе, и способы материальной мотивации IT-шников к устранению уязвимостей. Сразу вспомнилась мемная картиночка. 🙂 Идея-то, в целом, неплохая. Но нужно понимать, что попытка внедрения таких практик встретит всевозможное сопротивление со стороны IT. От рядовых инженера и до CIO. Они не поленятся найти те таски на устранение уязвимостей, где есть какие-то косяки: неочевидная эксплуатабельность, подозрение на false positive и т.п. И они используют эти кейсы, чтобы представить дело так: это вы недостаточно хорошо выполняете свою работу и наваливаете им бесполезные задачи! 🤷♂️😏
Приведите таски в порядок, подготовьте контраргументы и убедитесь, что у вас хватит административного ресурса на продавливание таких непопулярных решений. Без должной подготовки лучше в лобовые атаки не ходить. Вы же не Бессмертный (и не Неувольняемый 😉).
Взгляд на Offensive со стороны Vulnerability Management специалиста. В канале Just Security вышел ролик про церемонию награждения Pentest Awards 2024 от Awillix. В ролике организаторы, жюри и победители рассуждают что это за мероприятие и для чего оно нужно - в первую очередь для нетворкинга специалистов по наступательной кибербезопасности и обмена опытом.
Я, как VM-щик, смотрю на этот движ несколько со стороны, но всегда с интересом.
🔹 Имхо, VM-щику лучше устраняться от игры в "докажи-покажи" с IT-шниками, т.к. это сжирает ресурсы необходимые для поддержания VM-процесса.
🔹 А у оффенсеров (pentest, bug bounty) суть работы как раз в "докажи-покажи" и заключается. Т.е. проломить здесь и сейчас хотя бы в одном месте.
Поэтому VM-щику обязательно нужно дружить с оффенсерами и отслеживать какие векторы популярны, эксплоиты для каких уязвимостей работают надёжно и "не шумят". Чтобы устранять такие уязвимости в первую очередь. 😉
Прочитал про подход DigitalOcean к Vulnerability Management-у и концепцию "Риск безопасности как долг". Основные моменты можно почитать у Security Wine. Как я себе это понимаю, суть в следующем:
🔹 Они якобы отказываются от отслеживания выполнения SLA на устранение уязвимостей. При этом таски на устранение уязвимостей заводят и фиксируют квази-SLA (под названием "Accepted Insecure Time").
🔹 После того как AIT для таска/уязвимости вышел, они "ставят команды на счётчик". 😏 Скорость ежедневного прироста долга зависит от критичности уязвимости.
🔹 Команды, у которых размер общего долга выходит за определённые значения, шеймят и стимулируют. 🥕
🔹 Лицами, принимающими решения за устранение уязвимостей выставляются руководители инженерных и продуктовых отделов, а не безопасники. 🫠 ИБ только счётчик включают. 😈
Не бог весть какая новация, но как вариант построения работы с командами, забивающими на SLA - почему бы и нет. 🙂 БОСПУУ не противоречит.
Уязвимости Шрёдингера и безусловный патчинг. Сегодня в канале Алексея Лукацкого вышел пост в продолжение нашей заочной дискуссии: нужно ли устанавливать все обновления безопасности выпускаемые вендором, или можно устанавливать только те, которые исправляют эксплуатабельные критичные уязвимости?
Я стою на том, что вендору виднее - раз вышло обновление безопасности, значит будь любезен его поставить. Может не прямо ASAP, может с задержкой на недельку-другую ("patch may be delayed" как пишут в ISA/IEC TR 62443-2-3 – 4.1), но НЕ ДОЛЖНО БЫТЬ опции вообще его не ставить только потому, что исправленная уязвимость выглядит как некритичная. Каждая продетектированная уязвимость должна находиться в процессе устранения (планового или приоритетного). Во всяком случае нужно к этому стремиться. 😉
А почему я так считаю, хотя сам делаю утилиту для приоритизации уязвимостей и участвую в определении трендовых уязвимостей? Пчёлы против мёда? 🐝🍯 К сожалению, мир уязвимостей так устроен, что о большей части из них мы не знаем практически ничего, кроме небольшого абзаца текста. 🐈 Кот Шрёдингера в коробке одновременно и жив, и мёртв. А у нас уязвимость одновременно и критичная эксплуатабельная, и нет. 🤷♂️ До момента пока не появятся детали: write-up, эксплоит, подтверждения эксплуатации вживую.
Далеко ходить не нужно, смотрим августовский Patch Tuesday с прошлой недели:
🔻 Вот Remote Code Execution - Windows TCP/IP IPv6 (CVE-2024-38063), от которой все на ушах стоят и ждут подробностей.
🔻 А вот Security Feature Bypass - Windows Mark of the Web "Copy2Pwn" (CVE-2024-38213), которую, по данным ZDI, запатчили в июне, а сообщили о ней только в августе. Вот так и принимай решение на основе данных об уязвимостях, когда вендор о них даже не сообщает, а исправляет тихонько. 😏
Инфа по уязвимостям практически всегда неполная! Выход из этого дурацкого подвешенного состояния один - запатчиться поскорее.
В упомянутой Алексеем Лукацким TSA Security Directive Pipeline-2021-02D в III.E.1 на 7 странице так прямо и написано, что необходимо иметь Patch Management стратегию, которая гарантирует, что все критические системы запатчены:
"A patch management strategy that ensures all critical security patches and updates on Critical Cyber Systems are current"
И только если установка патча ведёт к деградации операционных возможностей (III.E.3, стр.8), тогда нужно исправлять уязвимость workaround-ами с подробным описанием почему мы применяем такие экстраординарные формы митигации (ну и параллельно запрашивать вендора, что это за фигня с патчами, которые функциональность оплаченную портят):
"If the Owner/Operator cannot apply patches and updates on specific Operational Technology systems without causing a severe degradation of operational capability to mect necessary capacity, the patch management strategy must include a description and timeline of additional mitigations that address the risk created by not installing the patch or update."
А как же уязявимости CISA KEV? Где-то написано, что нужно патчить только их? Нет, написано, что список этих уязвимостей нужно учитывать при приоритизации исправления (III.E.2, стр.7):
"2. This strategy required by Section III.E.1. must include:
…
b. Prioritization of all security patches and updates on CISA’s Known Exploited Vulnerabilities Catalog."
И я соглашусь, что CISA KEV-овские уязвимости нужно исправлять раньше других (понимая, что они туда могут попадать с большой задержкой). Как и с тем, что патчи нужно катать не абы как, а после тестирования и в соответствии с рекомендациями из NIST-800-82-r3 и IEC TR 62443-2-3, которые Алексей Лукацкий перечислил в своём посте. Перечень вполне толковый. 👍
В общем, приведённые в посте документы только укрепили меня в моей позиции. Противоречий моей позиции и указанных best practicies не вижу. 😉
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.