А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей. Безусловно, недостаточно одной констатации VM-вендором, что тот или иной способ детектирования уязвимостей реализован в полной мере. Нужно идти ещё глубже.

Берём тот же базовый пример: детектирование уязвимостей на Linux хосте в пакетах из официального репозитория. Казалось бы - чего проще. Парсишь бюллетени безопасности (или даже готовый OVAL-контент Linux-вендора берёшь) и сравниваешь версии пакетов.

В реальности ошибиться можно много где. Самое частое:

🔹 Функция сравнения версий пакетов (например, эпоху не учитывают)
🔹 Источник безопасных версий пакетов (когда в бюллетенях source пакеты, а от них нужно перейти к версиям бинарных пакетов).

Особенно наглядно бывает, когда один хост проверяется несколькими сканерами. И в случае расхождений каждый вендор говорит, что их результаты правильные. 🤷‍♂️🤪 Пока не будет доказано обратное. 😏

Оценка адекватности используемых решений по детектированию уязвимостей. Заканчиваю отвечать на пост Алексея Лукацкого с критикой БОСПУУ. Согласен, что оценивать полноту базы детектов уязвимостей и достаточность способов детектирования непросто, и это имеет смысл только в контексте инфраструктуры конкретной организации.

Как оценивать?

🔹 Видим актив в инфре. Задаём вопрос: он в принципе поддерживается средством детектирования?

Если нет, то чешем репу, что делать: стимулировать VM-вендора, покупать другую детектилку / делать её самим, менять инфру.

Если да, идём глубже.

🔹 А как именно происходит детектирование?

Допустим, это Linux хост, и сканер детектирует уязвимости ТОЛЬКО в пакетах установленных из официального репозитория.

Нам этого достаточно? У нас там точно нет софта, установленного по-другому? 😏

Если достаточно, то всё ок.

Если нет - чешем репу как расширить способы детекта (пентест/WEB, анализ контейнеров и т.п.). Или меняем инфру. 🤷‍♂️

Далее