Про конкуренцию и тестирование. Частенько натыкаюсь на размышления, что в России слишком много каких-то IT/ИБ продуктов (например, Linux-дистрибутивов или NGFW) и нужно их подсократить.
Имхо, конкуренция внутри страны - всегда благо. Но нужно регуляторно контролировать, что и как может называться. 🙂
🔹 Отечественная ОС у вас? 👍 А кто апстримы? Пакеты сами собираете? А как быстро уязвимости апстримов фиксите? У нас тут тестовые эксплоиты есть, прогоним? 🙂 А где ваши бюллетени безопасности? А как вы проверяете, что от апстрима бэкдор не придёт? А у нас тут Challenge Projects, проверите бэкдоры в них? 😎
🔹 NGFW у вас? 👍 А что детектить умеет? А какую нагрузку держит? А у нас есть тестовый трафик с атаками, прогоним? 😉
🔹 Сканер уязвимостей у вас? 👍 У нас тут есть стенды с известными уязвимостями, просканим? 😏
Для конкретных задач, где конкуренцию нужно усилить, неплохо бы и конкурсы проводить с финансированием достаточным "для поддержки штанов".
No Boot - No Hacker! Обновлённый трек. Кажется кейс с инцидентом CrowdStrike BSODStrike подходит к логическому завершению. По причинам уже всё более-менее понятно. Остались только долгие судебные тяжбы клиентов с вендором. Поэтому закрываю для себя эту тему обновлённым треком, сделанным в Suno.
Добавил свою позицию, что дело не столько в проблемах конкретной компании, сколько в проблемах облачных ИБ сервисов с агентами, архитектура которых уязвима, и которым клиенты слишком доверяют. 🤷♂️ Замалчивать это мне не кажется правильным, нужно пытаться хоть как-то это компенсировать. Следует понимать, что сейчас был всего лишь небольшой и относительно безобидный сбой, но когда-нибудь мы увидим кейс с полномасштабной атакой злоумышленников через облачного вендора. И, как мне кажется, в настоящий момент онпрем решения имеют свои преимущества.
CrowdStrike - это успех! Поверь мне, это так. Защищает он лучше всех От любых кибератак. Проактивный подход, Секретное оружие: Не справится хакер, Если ОСь не загружена!
Припев: Синий экран отражает атаки! No boot - No Hacker! No boot - No Hacker!
CrowdStrike работает по лучшей из схем, С которой не может быть никаких проблем! На ваших хостах Falcon сенсоры. Их привилегии максимальны. А CrowdStrike управляют ими из своих облаков. И это нормально! (Якобы…) Команда CrowdStrike даже ночью не спит, Автоматом заливает вам Rapid Response Content "at operational speed". (Когда захочет…)
И если вам кажется, что всё это как-то страшновато, Не переживайте: CrowdStrike пропускает контент через валидатор! (Великий ВАЛИДАТОР!)
Не работает биржа, не летают самолёты - это всё детали… Всего лишь маленький баг в апдейтах, злодеи через вендора вас не атаковали… (Пока что…) За полтора часа сломать 8.5 миллионов хостов - задача нелегка… С таким не справится устаревший онпрем, для такого нужны облака…
А если серьёзно… В 22-ом CrowdStrike из России ушёл… И, как по мне, это очень, очень, ну просто ооочень хорошо!
Ещё одним аспектом инцидента с CrowdStrike является то, что Windows хосты сломало не функциональное обновление агента, а обновление "контента обнаружения". Дальше процитирую блогпост Алексея Лукацкого про CrowdStike (весьма годный 👍):
"Да и вообще, признайтесь, кто из вас проверяет прилетающий контент обнаружения в любом из ваших средств защиты — антивирусу, EDR, IDS, WAF, NGFW, SIEM, NTA, XDR?.. Ведь никто же!"
Я бы ещё и VM сюда добавил до кучи. 😉
И это беда. Почему-то считается, что "контенту обнаружения", который зачастую представляет собой те же мутные бинари, можно слепо доверять и автоматом пробрасывать его на хосты. BSODStrike показал к чему это может привести.
Имхо, необходимо разбираться, что же это за "контент обнаружения" такой и, при любой непрозрачности, также прогонять его на тестовом скоупе. А как иначе, если они и контентом хосты ушатывают. 🤷♂️🤦♂️ А на убеждения вендоров, что у них всё "просчитано до муллиметра", вестись не следует.
Верный признак хорошего вендора средств детектирования уязвимости - это то, что его сотрудники делится экспертизой по детектированию уязвимостей на конференциях, в статьях, видео-роликах и т.д.
Когда люди всерьёз занимаются какой-то темой, они неизбежно сталкиваются с проблемами (иногда весьма курьёзными), приходят к каким-то решениям и у них возникает желание поделиться опытом.
А когда этого нет, возникают вопросы:
🔹 Может детектирование уязвимостей это примитивная сфера деятельности и обсуждать там нечего? Но мы-то знаем, что сложностей там хватает. 😉
🔹 Или, возможно, для вендора качество и полнота детектирования уязвимостей не являются приоритетом? 😏 Разработчики правил детектирования что-то пилят на расслабоне. Клиентам вроде норм. В этом случае акцентировать лишнее внимание на детектах невыгодно, так ведь? 🙈🙊
В общем, техническим статьям про детект уязвимостей всегда рад, стараюсь читать и подсвечивать. 😉 Если вдруг что-то пропустил, пишите в личку - исправлюсь.
Да можно. 🙄 Я вообще мало знаю людей, кто этим заморачивается. К сожалению, большинство относится формально. Принимают всё на веру, VM-вендоров лишний раз не стимулируют. 🤷♂️
К чему это приводит? Маркетинг VM-вендоров решает, что детекты это коммодити, качество их никому не интересно и продажи не улучшает. Разработчики в VM-вендорах расслабляются. Главное же, чтобы на полностью обновлённой системе всё зелёненькое было, а на необновлённой красненькое. Остальное не так и важно, правда? 😏 VM-продукты деградируют.
А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей. Безусловно, недостаточно одной констатации VM-вендором, что тот или иной способ детектирования уязвимостей реализован в полной мере. Нужно идти ещё глубже.
Берём тот же базовый пример: детектирование уязвимостей на Linux хосте в пакетах из официального репозитория. Казалось бы - чего проще. Парсишь бюллетени безопасности (или даже готовый OVAL-контент Linux-вендора берёшь) и сравниваешь версии пакетов.
В реальности ошибиться можно много где. Самое частое:
🔹 Функция сравнения версий пакетов (например, эпоху не учитывают) 🔹 Источник безопасных версий пакетов (когда в бюллетенях source пакеты, а от них нужно перейти к версиям бинарных пакетов).
Особенно наглядно бывает, когда один хост проверяется несколькими сканерами. И в случае расхождений каждый вендор говорит, что их результаты правильные. 🤷♂️🤪 Пока не будет доказано обратное. 😏
Оценка адекватности используемых решений по детектированию уязвимостей. Заканчиваю отвечать на пост Алексея Лукацкого с критикой БОСПУУ. Согласен, что оценивать полноту базы детектов уязвимостей и достаточность способов детектирования непросто, и это имеет смысл только в контексте инфраструктуры конкретной организации.
Как оценивать?
🔹 Видим актив в инфре. Задаём вопрос: он в принципе поддерживается средством детектирования?
Если нет, то чешем репу, что делать: стимулировать VM-вендора, покупать другую детектилку / делать её самим, менять инфру.
Если да, идём глубже.
🔹 А как именно происходит детектирование?
Допустим, это Linux хост, и сканер детектирует уязвимости ТОЛЬКО в пакетах установленных из официального репозитория.
