Решил вернуться я к теме, поднятой неделю назад, относительно приоритезации устранения уязвимостей. Никита Ремезов в Фейсбуке справедливо заметил, что она ориентирована в первую очередь на госов и надо признать, что это так. К этой схеме он предложил добавить привязку к критичности сканируемых ресурсов для бизнеса. Да, и это тоже верно и контекстные метрики в CVSSv3 могут помочь это сделать. Преимуществом данной методики является ее простота. Чтобы ею воспользоваться не нужно ничего, кроме сканера безопасности, поддерживающего CVSS. Хотя даже он не нужен. Идентифицировать уязвимости можно либо путем анализа сетевого трафика
либо использованием средств защиты ПК, которые часто имеют такие возможности.
В последних двух случаях останется только выгрузить все данные об уязвимостях и провести их приоритезацию по описанной методике (это можно легко автоматизировать через обычный Excel).
Но что делать в крупных организациях, в которых десятки и сотни тысяч устройств. Даже если представить, что на каждом устройстве по одной уязвимости (а может быть и гораздо больше), то число строк в Excel станет неподъемным для анализа и составления списка дыр для устранения. Например, вот так выглядит картина всей сети Cisco, в которой насчитывает около полумиллиона устройств (200 тысяч пользовательских, около полусотни тысяч сетевых устройств, а также различные Интернет вещи).
Детализация карты сети сильно не улучшает ситуацию. Описанная в прошлой заметке методика не поможет в такой масштабной сети.
А надо ли это? Надо ли устранять все уязвимости? Даже те, у которых CVSS больше 6.5? А если попробовать пойти по иному пути и в scope работ по устранению уязвимостей включать не все, а только то, что может быть использовано извне? Вспомним историю с Equifax. Злоумышленники воспользовались уязвимостью на публичном Web-портале и через нее проникли во внутреннюю сеть бюро кредитных историй. Таких уязвимостей будет на порядки меньше и именно с них можно начинать устранение (по методике или без нее).
По сути речь идет о построении графа атак, который опирается на данные об уязвимостях, которые могут быть использованы для попадания из Интернет во внутреннюю сеть компании.
Интерес представляют только те уязвимости, которые позволяют путем многоходовой комбинации проникнуть внутрь. Именно их мы и будем устранять в первую очередь. Обратите внимание на иллюстрацию. Дыр внутри сети может очень много, но путь к ним всего один (отмечен красной линией). Устранив уязвимость в демилитаризованной зоне, мы получаем возможность существенно снизить плоскость будущей атаки, ограничив ее только ДМЗ.
Разумеется, для реализации данного подхода нам не обойтись уже только одним сканером . Придется использовать специализированные решения по построению векторов атак (у Cisco их нет - это не реклама :-), которые, анализируя настройки текущей инфраструктуры (сетевого оборудования и средств защиты), увязывают их с уязвимостями, и показывают масштаб будущих проблем. Для одной из точек выхода в Интернет в Cisco это выглядит так.
 |
| Список уязвимостей, идентифицируемых NGFW |
 |
| Список уязвимостей, найденных на защищенных EDR узле |
Но что делать в крупных организациях, в которых десятки и сотни тысяч устройств. Даже если представить, что на каждом устройстве по одной уязвимости (а может быть и гораздо больше), то число строк в Excel станет неподъемным для анализа и составления списка дыр для устранения. Например, вот так выглядит картина всей сети Cisco, в которой насчитывает около полумиллиона устройств (200 тысяч пользовательских, около полусотни тысяч сетевых устройств, а также различные Интернет вещи).
Детализация карты сети сильно не улучшает ситуацию. Описанная в прошлой заметке методика не поможет в такой масштабной сети.
А надо ли это? Надо ли устранять все уязвимости? Даже те, у которых CVSS больше 6.5? А если попробовать пойти по иному пути и в scope работ по устранению уязвимостей включать не все, а только то, что может быть использовано извне? Вспомним историю с Equifax. Злоумышленники воспользовались уязвимостью на публичном Web-портале и через нее проникли во внутреннюю сеть бюро кредитных историй. Таких уязвимостей будет на порядки меньше и именно с них можно начинать устранение (по методике или без нее).
Но даже это число уязвимостей может быть еще больше сокращено, если привязать дыры к векторам атаки, то есть проанализировать возможные пути, которыми злоумышленники могут воспользоваться для проникновения внутрь.
По сути речь идет о построении графа атак, который опирается на данные об уязвимостях, которые могут быть использованы для попадания из Интернет во внутреннюю сеть компании.
Интерес представляют только те уязвимости, которые позволяют путем многоходовой комбинации проникнуть внутрь. Именно их мы и будем устранять в первую очередь. Обратите внимание на иллюстрацию. Дыр внутри сети может очень много, но путь к ним всего один (отмечен красной линией). Устранив уязвимость в демилитаризованной зоне, мы получаем возможность существенно снизить плоскость будущей атаки, ограничив ее только ДМЗ.
Разумеется, для реализации данного подхода нам не обойтись уже только одним сканером . Придется использовать специализированные решения по построению векторов атак (у Cisco их нет - это не реклама :-), которые, анализируя настройки текущей инфраструктуры (сетевого оборудования и средств защиты), увязывают их с уязвимостями, и показывают масштаб будущих проблем. Для одной из точек выхода в Интернет в Cisco это выглядит так.
Методика из прошлой заметки дешева и не требует дополнительных затрат, но плохо работает в крупных инфраструктурах. Подход, описанный сегодня, более практичен, но и требует больших ресурсов / усилий по реализации. Зато полностью автоматизирован. Однако у него есть и еще один недостаток. Он предполагает, что мы не имеем других способов проникновения в корпоративную сеть или можем их минимизировать. Однако, если в сети есть незащищенный Wi-Fi, пользователи падки на подброшенные флешки, а руководство может безконтрольно приносить свои домашние ноутбуки и подключать их к внутренней сети, то второй подход может создать ложное чувство защищенности. Ищите баланс...
