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

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей

Спросили сегодня как по инвентаризационным данным из GLPI получать cpe-идентификаторы для последующего детектирования уязвимостей. Сам я таким не занимался. Согласен, что получить из результатов инвентаризации cpe-идентификаторы это проблема. Но основная проблема в том, что получившиеся cpe-идентификаторы тоже достаточно бесполезны, т.к. если детектировать уязвимости с помощью них по данным из NVD, можно обнаружить, что они не всегда мапятся качественно и разбирать получившиеся false positive ошибки придется руками. Возьмем, например, CVE-2020-1102. Все версии sharepoint_server 2016 и 2019 всегда уязвимы что ли? Там патчи есть, их установку нужно учитывать.

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

Linux Patch Wednesday?

Linux Patch Wednesday?

Linux Patch Wednesday? Раз уж значение Linux-а у нас стремительно растёт, выглядит правильным смещать фокус внимания с уязвимостей продуктов Microsoft на уязвимости Linux. При этом для продуктов Microsoft у нас есть единый день повышенного внимания - Microsoft Patch Tuesday, а для Linux такого нет. Слишком там всё фрагментировано и патчи выпускаются буквально ежедневно. Но что нам мешает самостоятельно раз в месяц формировать список исправленных за месяц CVE-шек и подсвечивать критичное? Кажется ничего. Список CVE можно получать, например, через парсинг OVAL-контента дистрибутивов (а кто такое не публикует - позор им 🙂).

Выпускать подобное предлагаю в каждую третью среду месяца и называть Linux Patch Wednesday. Как вам идейка?

Про практический тренинг по MaxPatrol VM

Про практический тренинг по MaxPatrol VM. Легенда была следующая. В некоторой супер позитивной компании развернули MaxPatrol VM, но не настраивали его. И вот наша задача была провести базовую настройку. Сначала шла демонстрация как делается операция, затем мы повторяли её на своей инсталляции самостоятельно. Непосредственно сканы не запускали, но всё остальное было вживую на весьма правдоподобных тестовых данных. Имхо, хорошо разобрали сильные стороны решения: значимость активов, статусы уязвимостей, актуальность данных. До этого я как-то не особо понимал концепцию динамических групп, политик и языка запросов PDQL. Это не самые очевидные штуки, особенно если просто смотреть скриншоты с дашбордами и видяшки. Но если немного разобраться, то инструменты очень крутые и мощные. 👍

Что мы рассмотрели:

1. Создание задач на сбор данных.
2. Группировка активов по сетевым сегментам с помощью динамических групп.
3. Создание задачи на сканирование динамической группы активов.
4. Создание PDQL запроса для фильтрации уязвимостей для динамических групп активов.
5. Изменение статуса уязвимости на "Исправляется" вручную.
6. Создание учётных записей и использование их в профиле сканирования.
7. Удаление активов из динамической группы активов.
8. Задание значимости активов через политики.
9. Задание статусов уязвимостей через политики.
10. Создание политики для контроля актуальности данных.
11. Создание отчёта для отфильтрованных уязвимостей.
12. Получение compliance результатов через запуск политики и работа с ними в PDQL запросах.

В общем, отличный практический тренинг, мне понравилось! 🙂

Взгляд на VM-процесс со стороны Positive Technologies

Взгляд на VM-процесс со стороны Positive TechnologiesВзгляд на VM-процесс со стороны Positive Technologies

Взгляд на VM-процесс со стороны Positive Technologies. Та же методика, которая раньше публиковалась. Задачка в 2DO - попробовать смапить это на руководство ФСТЭК. 😉

Что мешает эффективно работать с уязвимостями?

Что мешает эффективно работать с уязвимостями?

Что мешает эффективно работать с уязвимостями? Хороший набор болей, всё так. 🙂

- Полнота охвата
- Уязвимостей слишком много
- Нужно договариваться с IT

Проглядываю поток новостей про MOVEit и радуюсь, что в наших широтах это зверь редкий

Проглядываю поток новостей про MOVEit и радуюсь, что в наших широтах это зверь редкий
Проглядываю поток новостей про MOVEit и радуюсь, что в наших широтах это зверь редкий

Проглядываю поток новостей про MOVEit и радуюсь, что в наших широтах это зверь редкий.

"Гарантируйте надежность основных бизнес-процессов и передавайте конфиденциальные данные между партнерами, клиентами и системами безопасным и соответствующим [требованиям регуляторов] образом с помощью MOVEit." Ну да. 😏

С 31 мая выходит уже третья активно эксплуатируемая уязвимость.

"Компания призывает всех своих клиентов отключить весь HTTP- и HTTPs-трафик к MOVEit Transfer через порты 80 и 443, чтобы защитить свои среды, пока готовится исправление для устранения уязвимости." 🙂

До этого были SQLi CVE-2023-35036 и CVE-2023-34362 (есть PoC, эксплуатировалась для кражи данных с июля 2021 года!)

Эпично фейлят конечно, но любые подобные корпоративные сервисы для файлообмена будут лакомой целью.

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0?

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0?

Алексей Лукацкий задаётся вопросом: будет ли ФСТЭК переходить на CVSS 4.0? Мне это тоже интересно.

Имхо, CVSS это не священная корова и держаться за него не стоит:

1. CVSS это результат заполнения довольно сомнительного и субъективного опросника. То, что у ресерчера, вендора и у NVD не совпадают CVSS для одной и той же уязвимости это норма.
2. CVSS v2, v3 и v4 несовместимы между собой. Сейчас в NVD есть уязвимости без CVSS, только с v2, с v2 и с v3, только с v3. Будьте уверены, что переход на v4 зоопарк усугубит. Нужно ли это и в БДУ тянуть?
3. Положа руку на сердце, кто при приоритизации уязвимостей полагается исключительно на CVSS? Это один из факторов. И не самый важный. Основная ценность CVSS, что Base метрики предоставляются NIST-ом открыто и бесплатно. А Temporal метрики никто не предоставляет, поэтому их и не используют. Не говоря уж об Environmental, которые надо самим заполнять.

Поэтому я бы рекомендовал не переходить на CVSS v4, а сделать следующее:

1. Создать свой опросник с калькулятором а-ля CVSS. Также с векторами (записываемыми в строчку) и скорами. Назвать как-нибудь оригинально, например "Общая Система Оценки Критичности Автоматизируемая" (ОСОКА). 😉 Какой конкретно это должен быть опросник - предмет отдельного обсуждения. Я бы делал его максимально простым и кратким, пусть даже в ущерб точности оценки. Лишь бы базовый скор явно критичных уязвимостей был около 10, а явно некритичных был около 0. Инфраструктурный компонент из методики оценки критичности уязвимостей также учесть в ОСОКА (сделать как в Environmental метриках CVSS).
2. САМОЕ ГЛАВНОЕ! Выпустить методические указания как использовать CVSS v2, v3, v4 в качестве входящих данных для получения вектора ОСОКА. Очень желательно, чтобы базовая часть ОСОКА автоматом получалась из Base метрик CVSS v2, v3, v4, иначе скорее всего это не взлетит.
3. В перспективе заменить все упоминания CVSS и методику оценки критичности уязвимостей ФСТЭК на ОСОКА.