Архив за месяц: Июнь 2024

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера. Такая вот невероятно глубокая мысль. 🙂 Сканер уязвимостей это просто инструмент. Если этот инструмент не выполняет заявленные функции, это не снимает ответственность с того, кто этот инструмент закупил и использует.

Представим ситуацию: сканер фолснегативил при детекте уязвимости, через неё поломали организацию. VM-щик бежит с претензией к VM-вендору. После боданий, если получилось доказать проблему, вендор извиняется и выпускает обновлённый детект. И всё. А из-за этой уязвимости возможно всю инфру пошифровали. 🤷‍♂️ И кто в этой ситуации будет крайним и будет иметь бледный вид?

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

Что там у Greenbone и OpenVAS?

Что там у Greenbone и OpenVAS?

Что там у Greenbone и OpenVAS? Попался на глаза относительно свежий ролик Greenbone AG "Demystifying Greenbone" (вышел 3 месяца назад). Хороший такой ликбез по OpenVAS/GVM и куда ветер дует.

Что для себя отметил:

🔸 Greenbone корректно, но настойчиво отдаляются от бренда OpenVAS. Формула теперь такая: "Greenbone - это программное обеспечение с открытым исходным кодом и богатой историей". 😉

🔸 Greenbone Community Feed это для домашних продуктов "Home Application (only)", таких как Ubuntu Linux, AVM Fritzbox, MS Office. Если хотите комплаенса и "Enterprise grade" ПО, такого как MS Exchange, Palo Alto, Cisco IoT/OT, то нужен платный Greenbone Enterprise Feed. Был удивлён, что в бесплатном фиде есть немного комплаенса - German Policy IT-Grundschutz. Видимо для демки.

🔸 Методично отказываются от NASL-ового движка OpenVAS в пользу своего нового сканера Notus. В последнем стабильном релизе пишут, что Notus потенциально заменяет логику всех NASL-скриптов для локальных проверок: "Replaces the logic of potentially all NASL-based local security checks". Правда я что-то не нашёл в коде логику проверок для Windows, возможно имеются ввиду проверки только для Linux. 🤷‍♂️ Кстати, последней релиз был в июле 2022. В прошлом году стейбл так и не выпустили, но на GitHub новые пакеты выходят довольно часто.

В целом, прикольно, что до сих пор что-то движется и даже выкладывается в open source, но позывов бежать тестить это дело как не было, так и нет. Во-первых, с куцым контентом непонятен практический смысл, т.к. сканы будут заведомо недостоверными. Но даже не в контенте дело. Контент можно и собственный нагенерить, если прям очень хочется. Сама архитектура кажется переусложнённой и с кучей легаси. Одних репозиториев с какими-то либами и утилитами 62. 🫣 Вот уж действительно порождение "сумрачного германского гения". 🙂 Всё вроде так-то по уму, параллельно и перпендикулярно, но работать с этим решительно невозможно. 😣 Но будем наблюдать дальше. 😉

Сценарии таргетированного фишинга от имени службы поддержки

Сценарии таргетированного фишинга от имени службы поддержки

Сценарии таргетированного фишинга от имени службы поддержки. Материал от Известий и R-Vision.

✉️ Письмо от поддержки о смене доменного адреса внутренних рабочих систем. Просят перейти по ссылке и проверить доступ к своим проектам.

✉️ Письмо от поддержки о "выборочном тестировании перехода пользователей на новый алгоритм шифрования при работе с почтой". Также просят перейти по ссылке.

В обоих случаях собирают доменные учётки.

Маячки:

🪝 письмо от настоящего сотрудника компании
🪝 письмо персонифицированное
🪝 реальные имена сервисов, используемых в компании

Про "алгоритм шифрования" мне раньше не встречалось. А вот аналогичное про "ящик переполнен, нажмите, чтобы увеличить размер" или "переход на новый Exchange" - прямо классика с очень высокой эффективностью попадания. 🤷‍♂️ Обязательно попробуйте такие сценарии в своих антифишинговых рассылках и курсах.

Нужно ли ставить целью снижение количества уязвимостей до нуля?

Нужно ли ставить целью снижение количества уязвимостей до нуля?

Нужно ли ставить целью снижение количества уязвимостей до нуля? В канале у Алексея Лукацкого сегодня про снижение веса как метафору исправления уязвимостей:

"Поэтому не надо ставить целью снижение количества инцидентов или уязвимостей до нуля - это опасно для службы ИБ. Выброшенные на ветер деньги, стресс… 🤔 Нужен баланс, приоритизация и вот это вот все."

Имхо, цель снижения количества уязвимостей до 0 нужно ставить. Но нужно уточнить: каких именно уязвимостей?

❌ Речь не о том, что в инфре не должно быть известных уязвимостей в любой момент времени. Это нереалистично.

✅ Речь о том, что каждая известная уязвимость должна находиться в процессе исправления (планового или приоритетного). Должно быть понимание кто, как и в какие сроки её исправляет. А уязвимостей, на которые мы тупо забили (вообще не продетектили, или продетектили, но посчитали не требующими исправления и т.п.) должно быть 0.

Метафора снижения веса тут не работает. Вес может быть нормальным. Уязвимость всегда ненормальна. И про уязвимость всегда недостаточно информации. Сегодня мы считаем, что это неэксплуатабельная ерунда, а через 3 месяца внезапно начинаем одурело бить в рынду. Ну вот так оно работает. 🤷‍♂️ Невозможно со стопроцентной вероятностью угадать, где и когда оно выстрелит.

Нет, ну если нравится подрываться и бежать фиксить, когда появляются признаки эксплуатации - ок. Это тоже не самый плохой вариант. Авось эти признаки будут не в вашей инфре. Но ведь гораздо лучше, если уязвимость будет исправлена в плановом порядке хотя бы за месяц-два и к моменту начала эксплуатации вы будете расслабленно наблюдать всю эту суету со стороны. Разве нет?

Так что как по мне - лучше стремитесь к 0 уязвимостей, которые НЕ находятся в процессе исправления. Да, вряд ли этот идеальный результат удастся достичь, но результат будет всяко лучше, чем если успокаивать себя, что все уязвимости исправлять не нужно, а нужно исправлять только самое-самое "красненькое". Объявлять такое за норму это уже, продолжая метафору снижения веса, бодипозитив в самых его гротескных и нездоровых формах. 😉

Повышение критичности уязвимости Elevation of Privilege - Windows Error Reporting Service (CVE-2024-26169)

Повышение критичности уязвимости Elevation of Privilege - Windows Error Reporting Service (CVE-2024-26169)

Повышение критичности уязвимости Elevation of Privilege - Windows Error Reporting Service (CVE-2024-26169). В случае успешной эксплуатации злоумышленник может получить привилегии SYSTEM. Уязвимость была исправлена в мартовском Microsoft Patch Tuesday. Как это частенько бывает, тогда эту уязвимость никто не выделял. 🤷‍♂️

Однако, через 3 месяца, 12 июня, исследователи Symantec сообщили об атаках, связанных с известным шифровальщиком Black Basta, в которых использовались эксплоиты для данной уязвимости. Если верить меткам времени компиляции, эти эксплоиты были созданы задолго до выхода патчей от Microsoft, в феврале 2024 или даже в декабре 2023 года. Конечно, эти временные метки злоумышленники могли и подделать, но зачем? 🤔

13 июня уязвимость была добавлена в CISA KEV. В паблике эксплоита пока не видно.

Мораль та же: оценка и приоритизация уязвимостей хорошо, а регулярная безусловная установка обновлений - лучше.

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM. Для настройки интеграции нужно ввести в SECURITM адрес API сервиса VulnsIO и токен для аутентификации, при необходимости указать периодичность синхронизации и включить/выключить создание новых активов на основе данных VulnsIO.

Помимо собственно уязвимостей, также прокидывают сырые данные по активам. Это позволяет делать дополнительный анализ в SECURITM:

🔸 контролировать установленное ПО по черным и белым спискам
🔸 контролировать запущенные сервисы
🔸 контролировать учётные записи
🔸 формировать метрики безопасности и использовать их в управлении рисками и соответствии требованиям

Классный пример того, что можно делать поверх сырых данных, собираемых VM-решением. Если вы пользуетесь VulnsIO и хотите сделать что-то такое самостоятельно, то у меня был отдельный пост про работу с их API.

Upd. В первой версии поста было про то, что SECURITM исключительно облачный. Это не так, у них есть on-prem вариант!

Домашний и Человеческий Vulnerability Management

Домашний и Человеческий Vulnerability Management

Домашний и Человеческий Vulnerability Management. Размышлял на неделе как говорить о Vulnerability Management-е на широкую аудиторию. Так, чтобы это касалось не только организаций, но и каждого конкретного человека. В итоге вырисовывается 2 направления.

Домашний (Home) VM - традиционный инфраструктурный VM спроецированный на устройства, которыми владеет и пользуется сам человек или его семья. Начиная просто от персональных устройств (смартфонов, ноутбуков, планшетов) и базовой сетевой инфраструктуры (wifi-роутер), заканчивая сколь угодно сложными системами умных домов (тут сделаю отсылку к "Будет ласковый дождь" Брэдбери), умными автомобилями и прочим. Естественно, для всего этого безобразия появляются уязвимости, которые необходимо как-то контролировать и исправлять, иначе могут быть проблемы. Насколько я могу судить, сейчас с этим полный швах. VM-решений уровня "для дома для семьи" практически нет. Понимания, что такие решения должны быть и их необходимо применять тоже нет.

Человеческий (Human) VM - проецирование подходов инфраструктурного VM-а персонально на человека. По сути это расширение того, что сейчас называется антифишингом, awareness-ом и автоматизированным анализом поведения пользователей в рамках DLP решений. То, что может быть натянуто и на общий VM-процесс. Актив - человек с персональными особенностями, сканирование - наблюдение за поведением, тестирование и практические учения, патчинг - обучение и т.д. Такую тему сейчас двигает, например, Holm Security. Human VM будет актуален и для организации (фишинг в ТОП-2 по первичному проникновению), и для каждого человека (звонки мошенников и разнообразнейшие схемы "разводов" это из той же темы). Если в компаниях этим как-то занимаются, то на персональном уровне всё тоже довольно грустно - только разрозненные предупреждения и социальная реклама.