Оценка адекватности используемых решений по детектированию уязвимостей. Заканчиваю отвечать на пост Алексея Лукацкого с критикой БОСПУУ. Согласен, что оценивать полноту базы детектов уязвимостей и достаточность способов детектирования непросто, и это имеет смысл только в контексте инфраструктуры конкретной организации.
Как оценивать?
🔹 Видим актив в инфре. Задаём вопрос: он в принципе поддерживается средством детектирования?
Если нет, то чешем репу, что делать: стимулировать VM-вендора, покупать другую детектилку / делать её самим, менять инфру.
Если да, идём глубже.
🔹 А как именно происходит детектирование?
Допустим, это Linux хост, и сканер детектирует уязвимости ТОЛЬКО в пакетах установленных из официального репозитория.
Нам этого достаточно? У нас там точно нет софта, установленного по-другому? 😏
Если достаточно, то всё ок.
Если нет - чешем репу как расширить способы детекта (пентест/WEB, анализ контейнеров и т.п.). Или меняем инфру. 🤷♂️
Далее
@avleonovrus #БОСПУУ #VMprocess #Detection
Как оценивать?
🔹 Видим актив в инфре. Задаём вопрос: он в принципе поддерживается средством детектирования?
Если нет, то чешем репу, что делать: стимулировать VM-вендора, покупать другую детектилку / делать её самим, менять инфру.
Если да, идём глубже.
🔹 А как именно происходит детектирование?
Допустим, это Linux хост, и сканер детектирует уязвимости ТОЛЬКО в пакетах установленных из официального репозитория.
Нам этого достаточно? У нас там точно нет софта, установленного по-другому? 😏
Если достаточно, то всё ок.
Если нет - чешем репу как расширить способы детекта (пентест/WEB, анализ контейнеров и т.п.). Или меняем инфру. 🤷♂️
Далее
@avleonovrus #БОСПУУ #VMprocess #Detection
А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей. Безусловно, недостаточно одной констатации VM-вендором, что тот или иной способ детектирования уязвимостей реализован в полной мере. Нужно идти ещё глубже.
Берём тот же базовый пример: детектирование уязвимостей на Linux хосте в пакетах из официального репозитория. Казалось бы - чего проще. Парсишь бюллетени безопасности (или даже готовый OVAL-контент Linux-вендора берёшь) и сравниваешь версии пакетов.
В реальности ошибиться можно много где. Самое частое:
🔹 Функция сравнения версий пакетов (например, эпоху не учитывают)
🔹 Источник безопасных версий пакетов (когда в бюллетенях source пакеты, а от них нужно перейти к версиям бинарных пакетов).
Особенно наглядно бывает, когда один хост проверяется несколькими сканерами. И в случае расхождений каждый вендор говорит, что их результаты правильные. 🤷♂️🤪 Пока не будет доказано обратное. 😏
@avleonovrus #БОСПУУ #VMprocess #Detection
Берём тот же базовый пример: детектирование уязвимостей на Linux хосте в пакетах из официального репозитория. Казалось бы - чего проще. Парсишь бюллетени безопасности (или даже готовый OVAL-контент Linux-вендора берёшь) и сравниваешь версии пакетов.
В реальности ошибиться можно много где. Самое частое:
🔹 Функция сравнения версий пакетов (например, эпоху не учитывают)
🔹 Источник безопасных версий пакетов (когда в бюллетенях source пакеты, а от них нужно перейти к версиям бинарных пакетов).
Особенно наглядно бывает, когда один хост проверяется несколькими сканерами. И в случае расхождений каждый вендор говорит, что их результаты правильные. 🤷♂️🤪 Пока не будет доказано обратное. 😏
@avleonovrus #БОСПУУ #VMprocess #Detection
А можно мне, пожалуйста, не заниматься оценкой адекватности средств детектирования уязвимостей? Не проверять достаточность детектов, а тем более их фактическую реализацию.
Да можно. 🙄 Я вообще мало знаю людей, кто этим заморачивается. К сожалению, большинство относится формально. Принимают всё на веру, VM-вендоров лишний раз не стимулируют. 🤷♂️
К чему это приводит? Маркетинг VM-вендоров решает, что детекты это коммодити, качество их никому не интересно и продажи не улучшает. Разработчики в VM-вендорах расслабляются. Главное же, чтобы на полностью обновлённой системе всё зелёненькое было, а на необновлённой красненькое. Остальное не так и важно, правда? 😏 VM-продукты деградируют.
Весь пафос VM-специалистов сыпется от того, что источник продетектированных уязвимостей неадекватный. И так оно тянется вплоть до реальных инцидентов, в которых VM-щики становятся крайними. 🤷♂️
В итоге имеем порочный круг лени и наплевательства, который гробит всю идею VM-а. 😔
@avleonovrus #БОСПУУ #VMprocess #Detection
Да можно. 🙄 Я вообще мало знаю людей, кто этим заморачивается. К сожалению, большинство относится формально. Принимают всё на веру, VM-вендоров лишний раз не стимулируют. 🤷♂️
К чему это приводит? Маркетинг VM-вендоров решает, что детекты это коммодити, качество их никому не интересно и продажи не улучшает. Разработчики в VM-вендорах расслабляются. Главное же, чтобы на полностью обновлённой системе всё зелёненькое было, а на необновлённой красненькое. Остальное не так и важно, правда? 😏 VM-продукты деградируют.
Весь пафос VM-специалистов сыпется от того, что источник продетектированных уязвимостей неадекватный. И так оно тянется вплоть до реальных инцидентов, в которых VM-щики становятся крайними. 🤷♂️
В итоге имеем порочный круг лени и наплевательства, который гробит всю идею VM-а. 😔
@avleonovrus #БОСПУУ #VMprocess #Detection
Защита на 100%? В канале Дениса Батранкова, если кто не знает, он известный эксперт по сетевой безопасности, вышел пост о невозможности стопроцентной защиты. Обосновывает он это как раз со стороны Управления Уязвимостями:
🔹 поток новых уязвимости слишком велик, их необходимо постоянно выявлять и исправлять, что делать трудоёмко
🔹 0day уязвимости начинают эксплуатироваться до появления патчей и от них VM в принципе не спасает
Полностью согласен. Я бы ещё со ссылкой на БОСПУУ, обратил внимание на то, что
🔸 прежде чем заниматься защитой активов необходимо знать, какие активы у нас вообще есть и понимать насколько они критичны
🔸 средства детектирования уязвимостей имеют свои функциональные ограничения, которые необходимо иметь в виду
В целом, речь, конечно, не идёт ни о каком достижении 100% защиты, а об избежании стопроцентного решета, которое возникает, если Vulnerability Management-ом (и информационной безопасностью вообще) не заниматься. 🤷♂️
@avleonovrus #VMprocess #БОСПУУ #Deffensive
🔹 поток новых уязвимости слишком велик, их необходимо постоянно выявлять и исправлять, что делать трудоёмко
🔹 0day уязвимости начинают эксплуатироваться до появления патчей и от них VM в принципе не спасает
Полностью согласен. Я бы ещё со ссылкой на БОСПУУ, обратил внимание на то, что
🔸 прежде чем заниматься защитой активов необходимо знать, какие активы у нас вообще есть и понимать насколько они критичны
🔸 средства детектирования уязвимостей имеют свои функциональные ограничения, которые необходимо иметь в виду
В целом, речь, конечно, не идёт ни о каком достижении 100% защиты, а об избежании стопроцентного решета, которое возникает, если Vulnerability Management-ом (и информационной безопасностью вообще) не заниматься. 🤷♂️
@avleonovrus #VMprocess #БОСПУУ #Deffensive
Верный признак хорошего вендора средств детектирования уязвимости - это то, что его сотрудники делится экспертизой по детектированию уязвимостей на конференциях, в статьях, видео-роликах и т.д.
Когда люди всерьёз занимаются какой-то темой, они неизбежно сталкиваются с проблемами (иногда весьма курьёзными), приходят к каким-то решениям и у них возникает желание поделиться опытом.
А когда этого нет, возникают вопросы:
🔹 Может детектирование уязвимостей это примитивная сфера деятельности и обсуждать там нечего? Но мы-то знаем, что сложностей там хватает. 😉
🔹 Или, возможно, для вендора качество и полнота детектирования уязвимостей не являются приоритетом? 😏 Разработчики правил детектирования что-то пилят на расслабоне. Клиентам вроде норм. В этом случае акцентировать лишнее внимание на детектах невыгодно, так ведь? 🙈🙊
В общем, техническим статьям про детект уязвимостей всегда рад, стараюсь читать и подсвечивать. 😉 Если вдруг что-то пропустил, пишите в личку - исправлюсь.
@avleonovrus #VMprocess #Detection
Когда люди всерьёз занимаются какой-то темой, они неизбежно сталкиваются с проблемами (иногда весьма курьёзными), приходят к каким-то решениям и у них возникает желание поделиться опытом.
А когда этого нет, возникают вопросы:
🔹 Может детектирование уязвимостей это примитивная сфера деятельности и обсуждать там нечего? Но мы-то знаем, что сложностей там хватает. 😉
🔹 Или, возможно, для вендора качество и полнота детектирования уязвимостей не являются приоритетом? 😏 Разработчики правил детектирования что-то пилят на расслабоне. Клиентам вроде норм. В этом случае акцентировать лишнее внимание на детектах невыгодно, так ведь? 🙈🙊
В общем, техническим статьям про детект уязвимостей всегда рад, стараюсь читать и подсвечивать. 😉 Если вдруг что-то пропустил, пишите в личку - исправлюсь.
@avleonovrus #VMprocess #Detection
Тоже сделал мемчик с крутым Юсуфом Дикечем. 😅
🔹 Каждая существующая в инфраструктуре уязвимость должна быть продетектирована.
🔹 Для каждой продетектированной уязвимости должна быть заведена задача на исправление.
Это суровая база. А когда вам говорят, что этого можно не делать, потому что есть какой-то супер-современный инструмент оценки уязвимостей, к этому стоит относиться со скепсисом. 😉
@avleonovrus #fun #meme #БОСПУУ #VMprocess #Prioritization #TruRiskEliminate
🔹 Каждая существующая в инфраструктуре уязвимость должна быть продетектирована.
🔹 Для каждой продетектированной уязвимости должна быть заведена задача на исправление.
Это суровая база. А когда вам говорят, что этого можно не делать, потому что есть какой-то супер-современный инструмент оценки уязвимостей, к этому стоит относиться со скепсисом. 😉
@avleonovrus #fun #meme #БОСПУУ #VMprocess #Prioritization #TruRiskEliminate
На Хабре вышла статья "Надзорщик за инфраструктурой: что делает VM-специалист и как им стать" по мотивам моих постов из Телеграм-канала.
Содержание статьи:
🔹 Кто такой VM-специалист?
🔹 Что делать VM-специалисту, чтобы быть эффективным?
🔹 Тяжело ли стать таким специалистом?
🔹 Почему VM-специалисты высоко востребованы на рынке?
🔹 Как становятся VM-специалистами?
В общем, 🎵 "В ИБшном департаменте есть специалист, чей рабочий путь опасен и тернист". 😉
🟥 По поводу вкатывания в VM. 8-го сентября стартует очередная (уже третья) волна курса "Управление уязвимостями: от теории к практике", в котором есть записанные мной видео-модули. Также планирую участвовать в онлайн "встречах с экспертами" в рамках курса. 😉
@avleonovrus #VMprocess #Education
Содержание статьи:
🔹 Кто такой VM-специалист?
🔹 Что делать VM-специалисту, чтобы быть эффективным?
🔹 Тяжело ли стать таким специалистом?
🔹 Почему VM-специалисты высоко востребованы на рынке?
🔹 Как становятся VM-специалистами?
В общем, 🎵 "В ИБшном департаменте есть специалист, чей рабочий путь опасен и тернист". 😉
🟥 По поводу вкатывания в VM. 8-го сентября стартует очередная (уже третья) волна курса "Управление уязвимостями: от теории к практике", в котором есть записанные мной видео-модули. Также планирую участвовать в онлайн "встречах с экспертами" в рамках курса. 😉
@avleonovrus #VMprocess #Education
Уязвимости Шрёдингера и безусловный патчинг. Сегодня в канале Алексея Лукацкого вышел пост в продолжение нашей заочной дискуссии: нужно ли устанавливать все обновления безопасности выпускаемые вендором, или можно устанавливать только те, которые исправляют эксплуатабельные критичные уязвимости?
Я стою на том, что вендору виднее - раз вышло обновление безопасности, значит будь любезен его поставить. Может не прямо 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 не вижу. 😉
@avleonovrus #VMprocess #Remediation #БОСПУУ #PatchManagement
Я стою на том, что вендору виднее - раз вышло обновление безопасности, значит будь любезен его поставить. Может не прямо 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 не вижу. 😉
@avleonovrus #VMprocess #Remediation #БОСПУУ #PatchManagement
Прочитал про подход DigitalOcean к Vulnerability Management-у и концепцию "Риск безопасности как долг". Основные моменты можно почитать у Security Wine. Как я себе это понимаю, суть в следующем:
🔹 Они якобы отказываются от отслеживания выполнения SLA на устранение уязвимостей. При этом таски на устранение уязвимостей заводят и фиксируют квази-SLA (под названием "Accepted Insecure Time").
🔹 После того как AIT для таска/уязвимости вышел, они "ставят команды на счётчик". 😏 Скорость ежедневного прироста долга зависит от критичности уязвимости.
🔹 Команды, у которых размер общего долга выходит за определённые значения, шеймят и стимулируют. 🥕
🔹 Лицами, принимающими решения за устранение уязвимостей выставляются руководители инженерных и продуктовых отделов, а не безопасники. 🫠 ИБ только счётчик включают. 😈
Не бог весть какая новация, но как вариант построения работы с командами, забивающими на SLA - почему бы и нет. 🙂 БОСПУУ не противоречит.
@avleonovrus #DigitalOcean #SecurityDebt #VMprocess #БОСПУУ
🔹 Они якобы отказываются от отслеживания выполнения SLA на устранение уязвимостей. При этом таски на устранение уязвимостей заводят и фиксируют квази-SLA (под названием "Accepted Insecure Time").
🔹 После того как AIT для таска/уязвимости вышел, они "ставят команды на счётчик". 😏 Скорость ежедневного прироста долга зависит от критичности уязвимости.
🔹 Команды, у которых размер общего долга выходит за определённые значения, шеймят и стимулируют. 🥕
🔹 Лицами, принимающими решения за устранение уязвимостей выставляются руководители инженерных и продуктовых отделов, а не безопасники. 🫠 ИБ только счётчик включают. 😈
Не бог весть какая новация, но как вариант построения работы с командами, забивающими на SLA - почему бы и нет. 🙂 БОСПУУ не противоречит.
@avleonovrus #DigitalOcean #SecurityDebt #VMprocess #БОСПУУ
Взгляд на Offensive со стороны Vulnerability Management специалиста. В канале Just Security вышел ролик про церемонию награждения Pentest Awards 2024 от Awillix. В ролике организаторы, жюри и победители рассуждают что это за мероприятие и для чего оно нужно - в первую очередь для нетворкинга специалистов по наступательной кибербезопасности и обмена опытом.
Я, как VM-щик, смотрю на этот движ несколько со стороны, но всегда с интересом.
🔹 Имхо, VM-щику лучше устраняться от игры в "докажи-покажи" с IT-шниками, т.к. это сжирает ресурсы необходимые для поддержания VM-процесса.
🔹 А у оффенсеров (pentest, bug bounty) суть работы как раз в "докажи-покажи" и заключается. Т.е. проломить здесь и сейчас хотя бы в одном месте.
Поэтому VM-щику обязательно нужно дружить с оффенсерами и отслеживать какие векторы популярны, эксплоиты для каких уязвимостей работают надёжно и "не шумят". Чтобы устранять такие уязвимости в первую очередь. 😉
@avleonovrus #offensive #awillix #pentest #pentestaward #VMprocess
Я, как VM-щик, смотрю на этот движ несколько со стороны, но всегда с интересом.
🔹 Имхо, VM-щику лучше устраняться от игры в "докажи-покажи" с IT-шниками, т.к. это сжирает ресурсы необходимые для поддержания VM-процесса.
🔹 А у оффенсеров (pentest, bug bounty) суть работы как раз в "докажи-покажи" и заключается. Т.е. проломить здесь и сейчас хотя бы в одном месте.
Поэтому VM-щику обязательно нужно дружить с оффенсерами и отслеживать какие векторы популярны, эксплоиты для каких уязвимостей работают надёжно и "не шумят". Чтобы устранять такие уязвимости в первую очередь. 😉
@avleonovrus #offensive #awillix #pentest #pentestaward #VMprocess