Качество данных и работа с уязвимостями.
Одна из самых полезных вещей, которые я понял, работая с Vulnerability Management и Asset Management: Уязвимость очень часто оказывается проблемой качества данных. У нас были уязвимые активы. Мы знали, что они уязвимы. Но во многих случаях никто не мог нормально начать remediation. И проблема была не в патче, не в сканере и даже не в самой уязвимости. Проблема была в том, что у актива не было понятного владельца. Где-то данные в CMDB были устаревшими. Где-то владелец уже сменился, а запись осталась старой. Где-то сервер существовал, но никто толком не понимал, кто за него отвечает.
На практике remediation часто тормозился на самом базовом этапе: мы видели уязвимость, но не понимали, кому её отдавать. Пока искали владельца актива и нужную команду, время шло, а проблема оставалась открытой.
И вот в этот момент становится очевидно, что ещё один vulnerability scanner ситуацию не исправит.
Потому что проблема уже не в Vulnerability Management как таковом. Проблема в Asset Management.
В одном из проектов мы работали с более чем 1 100 уязвимыми активами, включая серверы, виртуальные машины и сетевые устройства. И довольно быстро стало понятно, что значительная часть работы — это не просто «закрыть уязвимость».
Нужно было найти реального владельца актива, проверить и актуализировать данные в CMDB, договориться между Security, IT и инфраструктурными командами, понять приоритет и только после этого довести remediation до конца.
Лично я довёл до устранения проблем примерно 280 активов — больше четверти общего объёма. И главный вывод для меня был очень простой: Vulnerability Management не может быть зрелым, если Asset Management остаётся незрелым. Мы часто смотрим на CVE, сроки remediation и размер backlog. Но иногда самый важный вопрос намного проще:
«Мы вообще точно знаем, что у нас есть и кто за это отвечает?» Потому что иногда устранение уязвимости начинается задолго до того, как кто-то устанавливает патч.
#Кибербезопасность #VulnerabilityManagement #AssetManagement #CMDB #CyberRisk #InformationSecurity #SecurityLeadership