Архив рубрики: Темы

А ваше 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-отчет. Там есть проблемы с детектами софтов, но вроде не критично, пофикшу позже.

Управление уязвимостями в новых реалиях

Управление уязвимостями в новых реалиях. Крутой доклад по VM-ной теме с недавно прошедшего Инфофорума. Представлял доклад Андрей Никонов, старший инженер-программист из Фродекс (Vulns.io). Видео в паблике не нашел, но есть даже лучше - слайды с текстом выступления.

Выписал тезисно:

1. Зарубежные VM-вендоры ушли - нет детектов, IT-вендоры ушли - нет обновлений.
2. Атаки на российские компаний множатся, утечки ПД и оборотные штрафы.
3. Рост отечественного ПО -> рост проблемы анализа защищенности этого ПО -> "VM-решения должны уметь работать с операционными системами и программами российского происхождения".
4. В достаточной степени отечественные VM-решения поддерживают отечественное ПО? Непонятно. "Никто открыто не публикует списки поддерживаемых ПО и не дает внятных ответов по степени покрытия российского софта".
5. Необходимы данные об уязвимостях отечественного ПО.
5.1. Западные компании "публикуют уязвимости, найденные в своих продуктах, причем эти данные являются общедоступными, несмотря на то, что большая часть ПО является коммерческим".
5.2. "Данные NVD также являются общедоступными, содержат огромное количество уязвимостей, но для проведения точного аудита годятся мало. В основном из-за того, что они используют собственный формат данных, и в них не указаны правила, по которым можно определить, является ПО уязвимым или нет". -> Ага, детект по CPE-шкам это зло.
5.3. Все ли вендоры одинаково описывают свои уязвимости? Далеко не все. OVAL стал довольно популярным. Но этого недостаточно.
5.4. У нас хорошие источники это БДУ ФСТЭК и OVAL RedOS. "Остальные вендоры, если и публикуют свои данные, то в намного более расслабленном режиме – обычно это выглядит как лента новостей или запись в блоге. Это очень сильно усложняет их обработку. Более того, не все вендоры публикуют данные открыто, хотя некоторые из них готовы предоставить данные по запросу или в случае приобретения сертификата на техническую поддержку."
5.5. Для прикладного ПО из 65 вендоров в базе ФСТЭК 3 публикуют данные об уязвимостях. А в реестре российского ПО 16000 программных продуктов!
5.6. Одной БДУ ФСТЭК недостаточно, т.к. "не указываются правила применимости той или иной уязвимости, для сканирования использовать эти данные проблематично". Данные в БДУ могут добавляться с запаздыванием, данные не всегда актуальны. Напрямую от вендора было бы быстрее.
6. Итог: "обратить внимание разработчиков российского ПО на важность поиска уязвимостей в своих продуктах, и выпуска обновлений безопасности".
Просьбы к регулятору:
"- принять единый стандарт описания уязвимостей или разработать собственный
- обязать разработчиков ОС и ПО вести базы данных уязвимостей в соответствии с принятым стандартом
- оказывать содействие компаниям при организации мероприятий Bug Bounty при условии публикаций найденных уязвимостей в базу ФСТЭК"

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

А есть ли смысл в "Vulnerability Management Сycle"?

А есть ли смысл в Vulnerability Management Сycle?

А есть ли смысл в "Vulnerability Management Сycle"? Со временем все больше начинают подбешивать картинки циклов управления уязвимостями. Особенно картинка из "The New Vulnerability Management Guidance Framework" (2019). Хотя когда-то сам такое рисовал. 🙃

Чем плохо:

1. Создается иллюзия, что есть какие-то шаги, которые выполняются последовательно. "ручками похлопали, потом ножками потопали". Это представимо в рамках каких-то ежегодных аудитов, но Continuos VM так уже не работает. Все, что в "лепестках" должно идти одновременно, параллельно, автоматически. Нет "сканов-ресканов", есть процесс поддержания инвентори/детектов и его улучшения. Разбор и переоценка уязвимостей отдельный процесс. Пушинг их исправления тоже.
2. Зачастую VM-вендоры пытаются проектировать свои решения по этой схеме, стараясь всё, что отмечено как-то покрыть. Как правило, такие комбайны ни одну из заявленных задач толком не решают, а пользоваться ими так, как рекомендует вендор невозможно.