Окно между публичным раскрытием уязвимости и её массовой эксплуатацией сейчас составляет от 24 до 48 часов. Для самых серьёзных угроз. По прогнозам проекта Zero Day Clock, к 2028 году это окно сожмётся до минут. Стандартный процесс реагирования — запуск сканирования, ожидание результатов, создание тикета, согласование приоритетов, установка патча, верификация — физически не укладывается в такие сроки. А если раскрытие уязвимости происходит в выходной, всё растягивается ещё сильнее. Проблема, впрочем, не в скорости патчей. Проблема в том, что на поверхности атаки торчат сервисы, которым там нечего делать.
Хрестоматийный пример — история с уязвимостью ToolShell в Microsoft SharePoint. Речь шла об удалённом выполнении кода без аутентификации. SharePoint, как правило, тесно связан с Active Directory, то есть успешная атака давала злоумышленнику доступ к одной из самых чувствительных частей корпоративной инфраструктуры. Microsoft опубликовала информацию об уязвимости в субботу. Но к тому моменту китайские хакерские группы, связанные с государством, уже эксплуатировали ToolShell на протяжении двух недель. Сразу после публичного раскрытия к ним присоединились оппортунисты — массовое сканирование и атаки начались мгновенно.
Команда безопасности Intruder в момент раскрытия обнаружила тысячи публично доступных экземпляров SharePoint. И вот что здесь принципиально: SharePoint структурно не нуждается в том, чтобы быть доступным из интернета. Каждый непропатченный сервер с открытым внешним доступом был, по сути, дверью, которую никто не запер, хотя замок давно купили. Если бы эти серверы просто убрали из внешнего периметра, уязвимость ToolShell для них перестала бы существовать как угроза.
Почему же команды безопасности пропускают такие экспозиции? Проблема кроется в классификации результатов сканирования. В стандартных внешних сканах так называемые «информационные» находки оказываются в самом низу списка — после критических, высоких, средних и низких. Туда же попадают по-настоящему опасные вещи: выставленные в интернет серверы SharePoint, базы данных MySQL и Postgres, протоколы вроде RDP или SNMP, которые предназначены исключительно для внутренних сетей. Сканер видит сервис, не находит у него известной уязвимости и ставит пометку «информационное». Формально верно. Практически — катастрофа.
Контекст при этом решает всё. Сервис, доступный внутри частной подсети, действительно может быть низкорисковым. Но тот же самый сервис, торчащий наружу, несёт реальную угрозу — даже если прямо сейчас для него нет известного эксплойта. Завтра он появится. Традиционные сканеры обе ситуации трактуют одинаково. Это создаёт слепые зоны.
Руководитель безопасности Intruder предлагает трёхшаговый подход, который он называет проактивным сокращением поверхности атаки. Первый шаг — обнаружение активов. Нужно найти так называемое «теневое IT»: системы, которые организация эксплуатирует, но не мониторит. Для этого стоит интегрировать сканеры напрямую с облачными и DNS-провайдерами — тогда новая инфраструктура начнёт сканироваться автоматически, сразу при создании. Это преимущество, которого у атакующих нет. Плюс к этому — перечисление поддоменов для поиска внешне доступных хостов, не попавших в инвентарь (особенно актуально после слияний и поглощений), и выявление инфраструктуры у мелких, малоизвестных облачных провайдеров.
Второй шаг — начать относиться к экспозиции как к риску. Конкретно: повысить статус находок с «информационного» до реальной категории риска с присвоением соответствующей серьёзности. Открытый SharePoint-сервер должен быть как минимум «средним» риском, а не заметкой на полях. И ещё один момент, практический: нельзя ставить работу по сокращению поверхности атаки в один ряд с экстренным латанием дыр. Она всегда проиграет. Вместо этого имеет смысл выделить отдельное время — скажем, ежеквартальный пересмотр экспозиций — или назначить конкретного ответственного.
Третий шаг — непрерывный мониторинг. Поверхность атаки меняется постоянно: кто-то отредактировал правило файервола, кто-то развернул новый сервис, кто-то забыл про поддомен. Полные сканы уязвимостей слишком тяжелы, чтобы запускать их каждый день. Между плановыми сканированиями может пройти до месяца, и всё это время новый открытый сервис будет висеть незамеченным. Решение — ежедневное сканирование портов. Оно легковесное, быстрое. Если кто-то случайно открыл RDP наружу, правя правило фаейрвола, ежедневный скан портов поймает это в тот же день.
Вся эта логика, в общем, сводится к одной мысли: организации не могут контролировать, когда появится следующая zero-day уязвимость. Но контролировать, что именно из их инфраструктуры видно из интернета — вполне в их силах. И если убрать лишнее с внешнего периметра заранее, то очередной ToolShell превращается из авральной субботней катастрофы в новость, которую читаешь с утренним кофе.
Изображение носит иллюстративный характер
Хрестоматийный пример — история с уязвимостью ToolShell в Microsoft SharePoint. Речь шла об удалённом выполнении кода без аутентификации. SharePoint, как правило, тесно связан с Active Directory, то есть успешная атака давала злоумышленнику доступ к одной из самых чувствительных частей корпоративной инфраструктуры. Microsoft опубликовала информацию об уязвимости в субботу. Но к тому моменту китайские хакерские группы, связанные с государством, уже эксплуатировали ToolShell на протяжении двух недель. Сразу после публичного раскрытия к ним присоединились оппортунисты — массовое сканирование и атаки начались мгновенно.
Команда безопасности Intruder в момент раскрытия обнаружила тысячи публично доступных экземпляров SharePoint. И вот что здесь принципиально: SharePoint структурно не нуждается в том, чтобы быть доступным из интернета. Каждый непропатченный сервер с открытым внешним доступом был, по сути, дверью, которую никто не запер, хотя замок давно купили. Если бы эти серверы просто убрали из внешнего периметра, уязвимость ToolShell для них перестала бы существовать как угроза.
Почему же команды безопасности пропускают такие экспозиции? Проблема кроется в классификации результатов сканирования. В стандартных внешних сканах так называемые «информационные» находки оказываются в самом низу списка — после критических, высоких, средних и низких. Туда же попадают по-настоящему опасные вещи: выставленные в интернет серверы SharePoint, базы данных MySQL и Postgres, протоколы вроде RDP или SNMP, которые предназначены исключительно для внутренних сетей. Сканер видит сервис, не находит у него известной уязвимости и ставит пометку «информационное». Формально верно. Практически — катастрофа.
Контекст при этом решает всё. Сервис, доступный внутри частной подсети, действительно может быть низкорисковым. Но тот же самый сервис, торчащий наружу, несёт реальную угрозу — даже если прямо сейчас для него нет известного эксплойта. Завтра он появится. Традиционные сканеры обе ситуации трактуют одинаково. Это создаёт слепые зоны.
Руководитель безопасности Intruder предлагает трёхшаговый подход, который он называет проактивным сокращением поверхности атаки. Первый шаг — обнаружение активов. Нужно найти так называемое «теневое IT»: системы, которые организация эксплуатирует, но не мониторит. Для этого стоит интегрировать сканеры напрямую с облачными и DNS-провайдерами — тогда новая инфраструктура начнёт сканироваться автоматически, сразу при создании. Это преимущество, которого у атакующих нет. Плюс к этому — перечисление поддоменов для поиска внешне доступных хостов, не попавших в инвентарь (особенно актуально после слияний и поглощений), и выявление инфраструктуры у мелких, малоизвестных облачных провайдеров.
Второй шаг — начать относиться к экспозиции как к риску. Конкретно: повысить статус находок с «информационного» до реальной категории риска с присвоением соответствующей серьёзности. Открытый SharePoint-сервер должен быть как минимум «средним» риском, а не заметкой на полях. И ещё один момент, практический: нельзя ставить работу по сокращению поверхности атаки в один ряд с экстренным латанием дыр. Она всегда проиграет. Вместо этого имеет смысл выделить отдельное время — скажем, ежеквартальный пересмотр экспозиций — или назначить конкретного ответственного.
Третий шаг — непрерывный мониторинг. Поверхность атаки меняется постоянно: кто-то отредактировал правило файервола, кто-то развернул новый сервис, кто-то забыл про поддомен. Полные сканы уязвимостей слишком тяжелы, чтобы запускать их каждый день. Между плановыми сканированиями может пройти до месяца, и всё это время новый открытый сервис будет висеть незамеченным. Решение — ежедневное сканирование портов. Оно легковесное, быстрое. Если кто-то случайно открыл RDP наружу, правя правило фаейрвола, ежедневный скан портов поймает это в тот же день.
Вся эта логика, в общем, сводится к одной мысли: организации не могут контролировать, когда появится следующая zero-day уязвимость. Но контролировать, что именно из их инфраструктуры видно из интернета — вполне в их силах. И если убрать лишнее с внешнего периметра заранее, то очередной ToolShell превращается из авральной субботней катастрофы в новость, которую читаешь с утренним кофе.
