Архив метки: vulnerability

Борьба со "слепыми пятнами" в базе знаний VM-решения от Qualys

Борьба со "слепыми пятнами" в базе знаний VM-решения от Qualys. Это и будет примером для п.3 из прошлого поста. Модуль называется Qualys Custom Assessment and Remediation (CAR). Идея следующая. Для детектирования уязвимостей Qualys использует в первую очередь легковесные "облачные агенты". Почему бы не дать возможность выполнять пользовательские скрипты на хостах посредством этих агентов? И эти скрипты связывать с идентификаторами уязвимостей и мисконфигураций (QIDs, CIDs), так чтобы с результатами этого кастомного детектирования можно было работать в рамках общего VM/CM процесса. Это в Qualys и сделали.

Причем это позиционируется не как компенсация для дырявой базы знаний Qualys, а как решение отдельной задачи "tactical security workflow". Т.е. это когда вам нужно добавить детект по-быстрому, а не ждать, когда он появится в VM-решении. А ещё для всяких самописных приложений ("custom in-house applications"), для которых иначе детектов вообще не было бы. В общем, трансформируют компенсацию недостатков в конструктив и позитив - мудро.

Скрипты можно писать на PowerShell, Python, Lua, Perl и Shell. Есть встроенная Script Testing Sandbox для тестирования перед запуском на хостах. Есть ролевая модель доступа к скриптам. Планируют интеграцию со сторонними репозиториями, включая Github, для упрощения разработки. Можно автоматизировать работу через API.

Скрипты можно использовать не только для детектирования уязвимостей и мисконфигураций, но и для исправления проблем: изменять конфигурации, закрывать порты, удалять файлы, завершать процессы, удалять нежелательное ПО и т.д.

В целом, прикольная штука и кажется всем VM-вендорам есть смысл присмотреться. Из минусов, пока это касается только хостов с установленными агентами. Про сетевые устройства, например, никто не говорит. Хотя теоретически тоже можно было бы добавить возможность выполнения кастомных скриптов активным сканером.

Что делать со "слепыми пятнами" в базах знаний Vulnerability Management решений?

Что делать со "слепыми пятнами" в базах знаний Vulnerability Management решений? 🤔 В прошлый раз показали, что VM решения могут детектировать не все уязвимости. Это данность. Что можно предложить VM-вендорам, чтобы эта ситуация начала меняться к лучшему.

1. Чтобы бороться, с проблемой нужно для начала её измерить. А для этого нужно понимать для каких продуктов VM-решение может детектировать уязвимости. Rapid7 поддерживает такой список. А как насчёт других VM-вендоров? Также было бы неплохо, чтобы во время аудита VM-решение подсвечивало продукты, которые были обнаружены, но детектов уязвимостей для них нет. Если это будет наглядно видно, клиент сможет выбирать как реагировать: пушить VM-вендора, чтобы добавляли поддержку; подобрать дополнительный специализированный сканер уязвимостей; отказаться от использования продуктов, для которых не работают детекты уязвимостей; принять риски.

2. Не можете детектировать сами, но хотите быть единственным решением для Vulnerability Management в организации? Тогда будьте любезны дать возможность заводить уязвимости в вашем решении, продетектированные, например, другим специализированным сканером уязвимостей. Технически это означает необходимость добавить возможность заводить уязвимости и редактировать списки активов, где они детектируются, через API.

3. Неплохо бы дать возможность пользователям управлять скриптами для кастомных детектов непосредственно внутри VM-решения. В какой-то степени это уже реализуется в некоторых VM-решениях через возможность добавления собственных детектов на специализированных языках (OVAL, NASL, Nmap scripting language). Но добавлять детекты с помощью более привычных, мощных и универсальных инструментов (Bash, Python) было бы гораздо предпочтительнее. Одну такую реализацию рассмотрим в следующий раз.

А ваше Vulnerability Management решение точно умеет все уязвимости детектировать?

А ваше Vulnerability Management решение точно умеет все уязвимости детектировать? Естественно нет! 😀 Софтов и железок настолько много, настолько они разнообразные, что покрыть их все детектами уязвимостей невозможно. О некоторых IT продуктах VM-вендоры могут вообще не знать. Знают ли в Qualys или Tenable об 1С, Континент-АП, Astra Linux? В курсе ли в российских VM вендорах об IT-решениях используемых где-нибудь в Бразилии или ЮАР? Сомнительно. Даже если в курсе, то с каким приоритетом начнут пилить детекты уязвимостей для них? С нулевым или даже отрицательным. Важно же покрыть в первую очередь то, что у текущих и потенциальных клиентов используется.

Когда я разговаривал с представителями VM-вендоров об этом, мучил в основном сейлов/пресейлов, то получал обычно риторический прием "ну зачем же говорить про отдельные детекты, мы же Vulnerability Management процесс строим"! Ну типа главное, чтобы оно в целом работало, а частные недочёты значения не имеют. Но как оно может работать с такими "слепыми зонами" для меня так и осталось загадкой. 🤨 К сейлам и пресейлам претензий нет, у них задача с возражениями работать и сделки закрывать, а не с потенциальным клиентом по душам говорить. Но замалчивать принципиальную проблему это тоже такое себе.

Ещё раз, допустим есть продукт, софт или устройство, которое в компании используется, но VM-решение его не поддерживает, уязвимости детектить не может. А в продукте точно есть уязвимость критичная. Допустим нам вендор этого продукта сам о ней сообщил. Как теперь учесть эту уязвимость в этом навороченном VM-решении с дашбордиками, приоритизацей на нейронках и прочим? Да в общем случае никак. И к чему это приведет? Будет навороченная энтерпрайзная VM-красота и рядом с ней костыльный процесс. Этот костыльный процесс будет покрывать те уязвимости, с которыми дорогое VM-решение не справилось. Так и к чему тогда все эти размышления о том, чем "обычный сканер" отличается от продвинутого решения по управлению уязвимостями, если это решение может работать только с ограниченным набором уязвимостей, для которых есть готовые детекты у VM-вендора, а не со всеми, которые есть в компании-клиенте?

Есть, конечно, мысли как сделать лучше и есть примеры как некоторые VM-вендоры эту проблему решают, но об этом после.

февральскому Microsoft Patch Tuesday

Обновил Vulristics-отчет по февральскому Microsoft Patch Tuesday. Пофиксил детекты софтов и типов уязвимостей, добавил комментарии из обзоров Tenable, Qualys, Rapid7, ZDI, KrebsOnSecurity. Блогопостом и вядяшкой вероятнее всего займусь уже под конец праздников.

С днём защитника Отечества всех!

Антифишинг и Управление Уязвимостями

Антифишинг и Управление Уязвимостями. Возвращаясь к обзору рынка Vulnerability Management систем от Anti-Malware, наибольший интерес у меня вызвал вендор Holm Security.

1. Раньше я о них не слышал. Из шведских VM-щиков я знал и общался только с Outpost24 . А тут оказывается есть ещё один шведский вендор, да ещё и существует с 2015 года. Круто!
2. Основная их фишка в том, что они совместили в одно решение Антифишинг и Управление Уязвимостями. 🤯 Очень необычно. Это меня особенно порадовало, т.к. на работе я как раз занимаюсь и Управлением Уязвимостями, и Антифишингом. 😅 Так сложилось. О нашей системе антифишинга был доклад на прошлом Offzone (презентацию готовил я, а докладывал Павел Жерелин). Так вот, мне всегда казалось, что Антифишинг это для меня непрофильная нагрузка. А оказалось, что в Holm Security всерьез позиционируют Антифишинг как часть VM-а. "Благодаря Next-Gen подходу [Vulnerability Management] платформа борется со всеми векторами атак, которым подвергается организация, включая защиту одного из самых важных активов — ваших сотрудников". Если сотрудники попадаются на фишинг, то это тоже своего рода уязвимость, которая исправляется обучением и другими мероприятиями. Согласитесь, довольно нестандартный подход. Так что теперь при случае могу говорить, что занимаюсь VM-ом не только для IT-инфраструктуры, но и для людей. 😁

Я, конечно, сомневаюсь, что в Holm Security действительно считают Антифишинг такой уж неотъемлемой частью процесса Управления Уязвимостями. Вероятнее, что у них были эти 2 решения в портфеле и их маркетологи решили, что они будут эффективнее продаваться в рамках одной платформы. Ну и подвели некоторую базу под это. Однако, если в эту тему поиграться, то действительно можно сделать некоторые занимательные выводы и для Антифишинга, и для Управления Уязвимостями.

Смотрим на Антифишинг с точки зрения Управления Уязвимостями:
1. Если актив уязвим (сотрудник попался), то должен быть ответственный за актив, который сделает фикс. А кто этот ответственный? Видимо это непосредственный руководитель сотрудника, который должен был проводить инструктаж. И спрашивать нужно в первую очередь с него, а не с попавшегося человека.
2. Если в VM мы стремимся к полному покрытию IT-активов, то Антифишинг не должен быть выборочным, а должен покрывать всех сотрудников.
3. Если в VM мы не проверяем активы только на одну уязвимость, а стараемся проводить проверки для всех возможных уязвимостей, то и Антифишинг должен касаться разнообразных техник и психологических манипуляций, с которыми может столкнуться сотрудник в реальной фишинговой атаке.

Смотрим на Управление Уязвимостями со стороны Антифишинга:
1. Если в Антифишинге мы предлагаем попавшемуся сотруднику пройти обучение по ИБ, почему бы не назначать курс по ИБ для владельца уязвимого актива? Пусть разбирается почему обновляться это важно.
2. Если в Антифишинге мы ограничиваем доступ к входящем письмам тем сотрудникам, которым обучение не помогает, то почему бы не ограничивать работу владельцам уязвимых активов, которые не справились с поддержанием их в безопасном (обновленном) состоянии? Показал, что не можешь полноценно владеть активом и обучение не помогло - теряешь доступ к этому активу, пусть более ответственные люди за него отвечают.

Т.е. возможно подводить Управление Уязвимостями и Антифишинг под некоторый общий базис это не такая бредовая идея, как может показаться на первый взгляд. 🙂

Про недавнюю RCE уязвимость в Webkit (CVE-2023-23529) и браузерные RCE уязвимости вообще

Про недавнюю RCE уязвимость в Webkit (CVE-2023-23529) и браузерные RCE уязвимости вообще.

Описание CVE-2023-23529 довольно типовое. "Обработка вредоносного веб-контента может привести к выполнению произвольного кода. Apple известно об отчете сообщающем о том, что эта проблема могла активно эксплуатироваться". Бюллетени для iPhone/iPad и macOS Ventura. Для iPhone/iPad эта уязвимость затронет не только Safari, ни и вообще все доступные браузеры, т.к. Apple принуждает всех разработчиков использовать единый "rendering framework".

Критичны ли такие браузерные уязвимости? Конечно. Заставить пользователя перейти по ссылке, например через фишинг, дело достаточно тривиальное. Отличный путь для получения первоначального доступа. И если браузер не обновлен, тут только на EDR надежда.

С обновлением всё неоднозначно. Некоторые инсталляции по большей части обновятся сами, такие как Chrome и Firefox под Windows. Но не все. Для других всё упрется в процесс обновления ОС: Microsoft Edge, Safari, Linux-овые браузеры поставленные из репозитория. Возни немало.

Соблазнительной выглядит идея запретить использование любых браузеров, кроме одного выбранного, контролируемого и обновляемого централизованно. 😈 Респект тем, кому удалось такое провернуть. 👍 Но исключения все равно придется предусматривать, как минимум для дизайнеров/разработчиков/qa, которым важно тестить работоспособность своих поделий в нескольких браузерах. Фактор разнообразного легаси, работающего только с определенными браузерами (и зачастую определенными их версиями) тоже исключать нельзя. А отсюда дополнительная операционная нагрузка. И с чем будет больше возни - с обычными обновлениями или запретами/исключениями не очевидно.

В общем, успехов нам всем с фиксом CVE-2023-23529 и прочих бесконечных веб-браузерных радостей. 🙂

Февральский Microsoft Patch Tuesday

Февральский Microsoft Patch Tuesday

Февральский Microsoft Patch Tuesday. Общее впечатление теперь буду сразу выдавать, с пылу с жару, а причесанный блогопост/видяшку с задержкой.

1. Наиболее критичным выглядит RCE - Windows Graphics Component (CVE-2023-21823). Причем ZDI отметили эту уязвимость как EoP и не стали в свой обзор добавлять. Видимо MS поменяли тип уязвимости перед релизом. Будем надеяться, что EDR-ы оперативно начнут блокировать эксплуатацию.
2. EoP - Windows Common Log File System Driver (CVE-2023-23376) с признаком активной эксплуатации.
3. Пачка RCE для Exchange (CVE-2023-21529, CVE-2023-21706, CVE-2023-21707, CVE-2023-21710). Но пока без признаков эксплуатации.
4. Из курьезного Inf. Disclosure в устройствах дополненной реальности HoloLens 1 (CVE-2019-15126), старая уязвимость Broadcom с кучей эксплоитов.

Выкладываю сырой Vulristics-отчет. Там есть проблемы с детектами софтов, но вроде не критично, пофикшу позже.