🎞 Видеозапись VM-ной дискуссии на IT ELEMENTS 2025 "Управление уязвимостями в условиях изменчивой ИТ-инфраструктуры: вызовы и стратегии". Таймстемпы и тезисы. 🙂
00:00 Вступительное слово и представление участников
02:08 Блиц-опрос: если бы вы могли изменить одну вещь в индустрии VM, что бы это было?
Плетнев: конкурентная борьба на рынке решений VM-а. Топорков: научить VM-решения говорить на языке бизнеса. Леонов: чтобы в фокусе было качество детектирования. Исхаков: ускорение процесса закрытия уязвимостей.
06:12 Как определять между двумя VM-вендорами кто сканирует качественнее?
Леонов: по декларациям вендоров о поддержке систем и по сравнению сканов (как минимум можно попросить вендоров объяснить расхождения). Топорков: обязать вендоров отмечать возможности детектирования в БДУ?
10:51 Почему заказчики сами начинают писать VM-продукты, из-за недостаточного качества того, что есть на рынке?
Топорков: у нас под капотом коммерческий сканер, сами пишем обработку уязвимостей. Леонов: иногда написание своего сканера оправдано, т.к. нужно заточиться только на те продукты, которые используются в организации. Погребняк: новые вендоры гибкие в плане доработок.
12:40 Как выбрать VM-решение?
Исхаков: учитывайте количество фолзов. Леонов: должна быть доступна логика детектирования. Плетнев: необходима зрелость на стороне клиента, интегратор может быть предвзят.
14:08 ТОП-критерии выбора VM-решения. ТОП-1: Качество.
Плетнев: интегрируемость с IT/ИБ инструментами: SOAR, ITSM, SIEM. Топорков: поддержка отечественных решений, прозрачность базы, информация по фиксам. Исхаков: производительность, интеграции, модули сканирования WEB-а/docker/отечественного стека, интегрируемость с CI/CD, учёт упоминания в рассылках, комплаенс/мисконфиги. Топорков: BlackBox сканы. Леонов: нужно отталкиваться от инфраструктуры вашей организации и оценивать "погруженность вендора" в тему детектирования уязвимостей, должен быть API.
24:00 Необходима ли в VM-решении функциональность по Автопатчингу/Patch Management?
Исхаков: автопатчинг для небольших компаний. Леонов: автопатчинг - вредное слово, нужно полноценное решение по Patch Management (с учётом проверки патчей по методике ФСТЭК). Исхаков: хорошо бы в VM-решении видеть проверенные обновления и возможность проверять шаблоны конфигураций. Топорков: автообновление должно быть поэтапным; хотя бы подтягивать проверенные обновления со ФСТЭК.
32:35 Что делать с системами, которые не поддерживаются VM-решением?
Леонов: писать VM-вендору, смотрим поддерживающие решения, оцениваем возможность отказаться от неподдерживаемой системы, реализуем свой сканер под систему или проверяем руками. Топорков: от вендора неподдерживаемого продукта потребовать рассылку с устранёнными уязвимостями.
35:30 Как правильно приоритизировать уязвимости?
Плетнев: не только CVSS, расположение хоста, критичность хоста, расчёт риска. Топорков: оценка вендора, CISA KEV. Леонов: CISA KEV не учитывает специфику России, учитывать наличие эксплоитов и признаков публичных атак; критичность повышается внезапно; нужен exposure management и построение путей атак. Исхаков: построение путей атак - следующий уровень развития. Леонов: всю инфраструктуру нужно покрыть детектами.
43:17 Как отслеживать устранение уязвимостей?
Плетнев: лучше в единой ITSM. Топорков: не все уязвимости нужно в реальном времени отслеживать. Леонов: таски должны быть, как именно заводить - дискуссионно. Плетнев: нужно формировать культуру безопасности. Леонов: да, но не нужно играть в докажи-покажи.
51:20 Нужно ли на законодательном уровне закрепить SLA на устранение уязвимостей через обязательность методики ФСТЭК или аналог CISA KEV?
Аудитория против. Топорков: "устранение за сутки" требует уязвимости на периметре, эксплоита и т.д. Леонов: устранение не всегда патчинг.
55:15 Вопрос из зала: может не устранять уязвимости, а максимально ограничить права пользователей?
Да, стоит делать "киоск" там, где он возможен.
58:53 Унифицированный SLA на устранение уязвимостей должен быть!
Исхаков.