



Добрался до Кибердома под самый конец Standoff / Moscow Hacking Week. Первый раз на площадке. Впечатления - пока ничего не понятно как здесь что, но просторно и масштабно, впечатляет. 🙂
Приехал на выпускной PT-шного курса по VM-у.
Добрался до Кибердома под самый конец Standoff / Moscow Hacking Week. Первый раз на площадке. Впечатления - пока ничего не понятно как здесь что, но просторно и масштабно, впечатляет. 🙂
Приехал на выпускной PT-шного курса по VM-у.
В CISA KEV только вчера, 21 ноября, добавили Looney Tunables CVE-2023-4911. Это при том, что уязвимость вышла 3 октября, публичный PoC для неё был готов уже на следующий день, и она уже как минимум 2 недели эксплуатируется в зловреде Kinsing. Не спешат товарищи, ой не спешат. 🤷♂️
🟥 Positive Technologies относит эту уязвимость к трендовым с 4 октября. 😎
Любопытная статья с критикой CISA KEV за медлительность вышла на Dark Reading. "Эксплуатируемым уязвимостям требуются месяцы на то, чтобы попасть в CISA KEV". Показывают на примерах:
1. RCE уязвимость в Adobe Acrobat и Reader (CVE-2023-21608). Вышла эта уязвимость 18 января. PoC для неё вышел в феврале. С июня эксплоит доступен в коммерческих фреймворках. А в CISA KEV уязвимость добавили только 10 октября. 🤷♂️ 10 месяцев получается потребовалось.
2. Множественные уязвимости в Juniper серий EX и SRX. Объявили об уязвимостях в середине августа. 25 августа Shadowserver сообщили о попытках эксплуатации вживую. В CISA KEV добавили только 13 ноября.
3. Обход аутентификации Veeam Backup & Replication (CVE-2023-27532). Обнаруженна в марте, начала эксплуатироваться позже в том же месяце, добавлена в список KEV только в августе.
И почему так?
Всё из-за жёстких критериев к доказательствам фактов эксплуатации уязвимости вживую и к наличию исправления от вендора (т.к. CISA KEV это фактически перечень требований для федеральных агентств по исправлению уязвимостей).
В статье рекомендуют использовать дополнительные источники данных об уязвимостях эксплуатируемых вживую.
Тоже порекомендую такой источник -
Трендовые Уязвимости
от 🟥 Positive Technologies
😉
Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости. Гостями подкаста в этот раз были Юрий Шкодин и Егор Подмоков из PT Expert Security Center (ESC). Для меня особенно интересный эпизод, т.к. ответ на вопрос куда именно в PT я вышел - вот конкретно к ним. 🙂 Выписал некоторые тезисы.
1. Трендовые уязвимости - уязвимости, которые эксплуатируются сейчас (на которые есть эксплоиты) или которые будут эксплуатироваться в ближайшее время. Это те уязвимости, на которые заказчики должны обратить внимание в первую очередь в своей инфраструктуре.
2. Трендовых уязвимостей не должно быть везде в инфраструктуре или только в DMZ? Дискуссионный вопрос, нужно исходить из модели рисков. Трендовая уязвимость на тестовом стенде внутри IT-инфраструктуры это не очень важная уязвимость.
3. Трендовость Уязвимости зависит от уязвимого продукта. Они могут быть очень специфичными: Church Management система, управления автомобилями и т.п. Необходимо учитывать реальные возможности по детектированию. Продукты, которые неинтересны ни нам, ни заказчикам, мы добавляем в black list, который, при необходимости, пересматриваем.
4. Исходные данные для оценки трендовости собираем из баз уязвимостей, бюллетеней безопасности вендоров, социальных сетей и мессенджеров, баз эксплоитов, публичных репозиториев кода.
5. Фолзы детектов уязвимостей, отчего они? Например, в детекте уязвимостей Windows по KB-шкам. Могут быть ошибки роботов-сборщиков данных. Может быть задержка реагирования на изменение в контенте вендора. Может быть вендор ПО предоставляет информацию об обновлениях недостаточно прозрачно.
6. Форки Open Source продуктов, которые не фиксят и не сообщают об уязвимостях исходного продукта. Призываем вендоров за этим следить. И желательно, чтобы вендоры публиковали информацию о своих уязвимостях в одном месте, идеально в БДУ ФСТЭК.
7. Сложности с детектами. Версионные детекты: уязвимость в выключенной фиче или выключенном ПО это уязвимость? Детекты с эксплуатацией: проверка не сработала, а насколько этому можно верить? Насколько правильно проверки реализованы и на основе каких эксплоитов?
8. Пользовательские детекты для софтов и уязвимостей - крутая тема. Идём в эту сторону.
9. Для отладки детектов необходимы реальные стенды с уязвимыми продуктами. Здесь вопросы с оценкой популярности софта (невозможно поддерживать всё) и нотификациями о выпуске новых версий софта. В эти темы тоже идём.
10. Доставка трендовых уязвимостей в MP VM за 12 часов. Трендовые уязвимости, как правило, начинают эксплуатировать через 24 часа (плюс это требование ФСТЭК из методики оценки критичности). Из них 12 нужно VM вендору на реализацию проверки и 12 нужны клиенту на детекты и исправление. Для более быстрой доставки идём к тому, что в базе MP VM будут все уязвимости, не только те, для которых есть детекты. Нужно будет только быстро добавлять детекты (возможно силами самих клиентов). Ассетная модель позволяет получить сработки без пересканирования по имеющимся данным.
11. BugBounty может использоваться для контроля известных уязвимостей сетевого периметра и выполнения SLA (например хантер может сдавать известные уязвимости старше 30 дней).
12. HCC PT Essentials это минимальный набор требований к конфигурациям, которые обязательно должны выполняться. Идём в сторону возможности реализовывать свои проверки.
13. Идеальный VM вендор. Прозрачность по текущим и будущим фичам (открытый roadmap). Улучшение покрытия продуктов. Самостоятельность заказчиков в плане наполнения базы знаний уязвимостей и детектов, возможность делиться этим контентом через маркетплейс. Метапродукты работающие с минимальным количеством людей. Автоматизированное исправление уязвимостей с аппрувом от IT.
Прослушал второй эпизод подкаста КиберДуршлаг с Эльманом Бейбутовым. Выписал тезисы.
1. Об управлении уязвимостями должно болеть у SOCоводов, т.к. активность закрепившегося злоумышленника будет выглядеть как более-менее легитимная активность пользователя и они её не поймают.
2. Людям склонно заниматься тем, что проще. Внедрять антивирусы гораздо проще, чем VM процесс.
3. VM не панацея. Нужен контроль конфигураций и действий внутреннего напушителя, нужно реагирование, нужна экосистема.
4. SIEM для VMа позволяет актуализировать инфу об активах, VM для SIEMа позволяет подсветить активы с высокой вероятностью эксплуатации (где нужно обмазать детектами).
5. Связка VM с EDR позволяет использовать EDR в качестве агента для инвентаризации и response (погасить хост, собрать инфу на доп. расследование)
6. В VM нужно интегрировать и апсечные уязвимости, и куберовые.
7. Можно такие интеграции замутить не в экосистеме одного вендора, а из разных решений через APIшки? Можно, но сложно. Из опенсурса ещё сложнее.
8. Куда дальше? Виртуальный патчинг, автоматический патчинг, детект любых уязвимостей и везде, анализ MLем.
9. Много фидов это хорошо, т.к. они друг друга дополняют, но должна быть Threat Intelligence платформа, чтобы эффективно с ними работать.
10. Вершина эволюции VMа - автопилот. Автоматизированный Patch Management, сквозной virtual patching, построение цепочки атак и отслеживание действий злоумышленника. Реализуется в метапродуктах PT.
В официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями. По сюжету злобный хацкер старается сломать инфраструктуру, но у него ничего не получается, т.к. для организации с выстроенным VM-процесом страшные зловреды превращаются в банан. 🍌🙂 В инфраструктуре, которая регулярно патчится особенно не развернёшься. 🤷♂️
Не, ну это, конечно, утрированно. Не от любых атак и уязвимостей VM защитит. Да и совсем почилить не получится - внедрение и поддержание VM-процесса требует усилий. Но уровень защищённости организации повысится и пожарной работы станет меньше - факт.
Так что рекомендую записаться и пройти курс. Как минимум его бесплатную вводную часть. Ну а в идеале выбить у руководства бюджет на полноценный месячный курс. Не зря же я там участвовал. 😉
Старт 29 октября.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.