Самая важная часть Vulnerability Management-а не имеет прямого отношения к уязвимостям. Подумал, что если суммировать весь опыт практического внедрения VM-а и выделить самое важное, то это будет оно.
В первую очередь у безопасника VM-щика должна голова болеть не об автоматически продетектированных на каком-то скоупе уязвимостях, а о том, что где-то есть какие-то IT-активы, о которых он вообще ни сном, ни духом.
По закону подлости именно там будет основное адище и именно там будут резвиться злоумышленники. А когда произойдёт инцидент, VM-щику будет нечего сказать кроме "а я не знал, что у нас такие активы есть" и вид он будет иметь весьма бледный. 😱
К существующей в организации системе инвентаризации должно быть максимальные недоверие. У вас действительно нет неучтённых активов? А если найду? (с)
Вопросы навскидку к системе инвентаризации:
🔹 А филиалы все? А дочерние/купленные компании все?
🔹 А десктопы все? И ноутбуки все? И у удалёнщиков, которые по VPN-у не подключаются? И на всех ОС?
🔹 А сервера все? И которые не в домене? И которые в закрытых сетках? И которые в облаке? И которые на других внешних хостингах когда-то подрядчиками развенуты? А ERP-система? А Kubernetes?
🔹 А сетевые устройства все?
А вот телефония? А вот камеры? А вот СКУДы? А вот экраны в переговорках? А вот система бронирования переговорок?
Можно до бесконечности продолжать.
Поддерживать такую систему инвентаризации в актуальном состоянии это прям работа-работа. И это имеет мало общего с тем, что обычно VM-вендоры говорят: ну вот вы сеточки просканите, получите активы и запустите VM-сканы с аутентификацией. Нет, ребята. Может посканить сеточку (ещё нужно понимать какую и получить права), поснифать трафик (опять же где именно), сделать выгрузку из AD (опять же из какого именно) и т.д. это и неплохо, но это скорее нужно для того, чтобы найти ошибки в основной системе инвентаризации активов, а не её замена.
Когда есть информация, что активы в принципе есть, можно копать вглубь:
🔸 А кто ответственный за актив? Кто должен обновлять этот актив? С какой периодичностью это делается? Что будет, если обновление по факту не производится?
🔸 А что это за актив? Какая у него критичность?
🔸 А можем ли мы сканировать этот актив на уязвимости? А если не можем, то как мы будем с этим активом дальше жить? Откажемся от использования актива, купим сканер, напишем свой сканер, будем руками проверять?
🔸 Если это сервер/десктоп можно уже инвентаризацией софтов заниматься и тоже прикидывать есть ли у нас средства для детектирования уязвимостей для этих софтов и как жить, если нет. Откажемся от использования софта, купим сканер, напишем свой сканер, будем руками проверять?
Посыл такой:
➕ С более-менее адекватной инвентаризацией активов и возможностью транслировать политики в сторону IT нам (крамола!) возможно и детектировать уязвимости не так и важно. 🙄 Видим хосты и то, что они полностью обновляются раз в месяц - отлично. Скорее всего там всё +- нормально. Если видим хост с EOL операционкой, то тоже сканировать на уязвимости излишне - нужно мигрировать. Если видим хост, который не обновлялся год, то тоже сканировать смысла нет - критичных уязвимостей за год гарантированно набежит, нужно разбираться почему процесс регулярного обновления не сработал.
➖ А вот когда у нас нормальной инвентаризации активов нет, то VM-процесс будет напоминать мальчика, который увлеченно ковыряет в грязной луже палочкой. Ну, чего-то там сканим, как-то эти сканы разбираем, какие-то таски на обновление заводим, как-то эти таски закрывают. Можно график нарисовать. Насколько этой активности достаточно и насколько она вообще реальный уровень защищенности повышает - да пёс его знает. Соблазнительно сказать: а вот мы пока на ограниченном скоупе запустимся, а потом - ух! Как расширимся на всё! Очень маловероятно, что это расширение действительно произойдет, т.к. в итоге мало кто в этом расширении скоупа оказывается заинтересован. Так что гораздо лучше изначально правильно акценты расставлять.
