Как организациям выстроить процесс контроля уязвимостей (Vulnerability Management, VM), подобрав при этом правильный инструмент для поиска изъянов в безопасности — сканер? Разберём подходы к построению процесса VM внутри компании и ключевые параметры, по которым можно выбрать сканер уязвимостей.
- Введение
- А нужен ли VM?
- Облако или ИТ-периметр
- Нужен ли сканеру агент
- Не всякий сканер — это VM
- Откуда сканер узнаёт об уязвимостях
- Выводы
Введение
За последние годы ИТ-инфраструктуры многих компаний сильно усложнились, а на периметрах появились новые цифровые активы. Пропустить незакрытые уязвимости в такой разрозненной инфраструктуре весьма просто. При этом одна незакрытая ошибка обязательно будет найдена и использована злоумышленником. Поэтому первый шаг в обеспечении кибербезопасности организации — это выстраивание процесса по контролю уязвимостей (Vulnerability Management, VM). Он включает в себя поиск и учёт всех информационных активов, оценку уровня защищённости сетевой инфраструктуры и веб-приложений, разработку рекомендаций по исправлению обнаруженных уязвимостей и проверку выполнения этих рекомендаций.
В своё время проект AM Live посвятил один из эфиров теме выбора систем управления уязвимостями. На онлайн-конференции эксперты рассказали, для чего нужны такие системы и могут ли они заменить ручной пентест. Обобщение можно найти в соответствующей статье.
А нужен ли VM?
В том, что контроль уязвимостей необходим, уже не возникает сомнений. Так, по оценке экспертов компании «Ростелеком-Солар», 57 % веб-приложений содержат критические уязвимости, которые позволяют хакерам похищать конфиденциальные данные и полностью контролировать работу атакуемого ресурса. А на внешних периметрах компаний встречаются старые, но функциональные уязвимости (BlueKeep, EternalBlue, Heartbleed), обновления для закрытия которых были выпущены ещё несколько лет назад.
Слабые места можно найти практически в каждом уголке инфраструктуры, поэтому в рамках VM проверяют разные объекты:
- сетевую инфраструктуру (как внешний периметр, так и локальные сети);
- веб-приложения (корпоративные порталы, клиентские сервисы и т. п.);
- процессы (например, программы, которые запущены в сети, имеют интерфейсы взаимодействия);
- софт, установленный на хостах.
Определившись с тем, что сканировать, надо решить — как. Сегодня на рынке представлено несколько вариантов реализации VM. Кто-то предлагает только сканер без экспертизы, кто-то — комплекс услуг, включающий подготовку отчётов. Сканеры можно разместить в облаке или на периметре компании, они могут мониторить хосты с помощью агентов или без них, а вендоры используют разные источники данных для пополнения своих баз уязвимостей.
Облако или ИТ-периметр
Существует два основных способа размещения сканера: на периметре компании и в облаке.
Первый вариант гарантирует полный контроль за доступом (как к оборудованию, так и к программному обеспечению) и независимость от сторонних организаций. Однако компания должна потратить средства на закупку самого сканера и лицензий, на обучение персонала, а также на обслуживание самого сканера и работу аналитика с результатами сканирования. Для небольшого бизнеса эти траты составят несколько миллионов рублей, для крупного — уже десятки миллионов.
Облачный сервис позволяет не расходовать большое количество ресурсов на обслуживание и размещение сканера — компании нужно просто оплатить доступ в облако, где расположен сканер. Этот вариант также обеспечивает высокую отказоустойчивость за счёт виртуализации, распределения нагрузки и т. п. Но привлечение внешнего провайдера сопряжено с рисками: качество его услуг может оказаться неудовлетворительным. Поэтому важно выбрать надёжного партнера с хорошей репутацией.
Нужен ли сканеру агент
Есть две базовые механики сканирования: с агентом и без агента. Оба варианта актуальны как для облачного сервиса, так и для сканера размещённого на периметре.
Агенты размещаются на конечных точках сканирования (то есть на хостах) как ПО или как служба. Они собирают данные об этих хостах и регулярно отправляют информацию на основной сканер. Этот подход позволяет мониторить устройства находящиеся вне периметра сети (например, ноутбуки сотрудников на «удалёнке»). Но получение данных о результатах сканирования возможно только при подключении устройства к интернету. Кроме того, установка агентов на ноутбуки, которые не имеют сетевой связанности (то есть сотрудники не приезжают в офис и не пользуются VPN), является весьма сложной технической задачей.
Кроме того, некоторые агенты могут быть несовместимы с отдельными операционными системами. В компании могут быть компьютеры, которые работают на неподдерживаемых или на специализированных (например, Astra Linux) ОС. Также приобретение каждого агента для сканирования — это дополнительные траты на очередную лицензию.
Сканирование безагентским способом позволяет проверять как локально размещённые активы, так и активы на внешнем периметре без предъявления требований по совместимости, так как установка ПО на устройство не требуется. Кроме этого, компания не несёт дополнительных затрат на развёртывание агентской сети, поддержку и закупку лицензий. Однако данная технология требует, чтобы все объекты сканирования имели сетевую связанность со сканером.
Не всякий сканер — это VM
Сегодня на рынке ИБ можно увидеть различные предложения, связанные с Vulnerability Management. Однако разные вендоры и ИБ-провайдеры интерпретируют эту услугу неодинаково. В качестве VM предлагают:
- ПО для самостоятельного проведения сканирования;
- комплексные услуги по обеспечению ИБ, включающие VM;
- сервисы VM.
Если организация покупает ПО для проведения сканирования, она приобретает инструмент для самообслуживания. Это — наиболее дорогой вариант сканирования инфраструктуры. В зависимости от того, где размещается ПО, у компании возникают следующие затраты:
- при размещении сканера в своей инфраструктуре — на закупку, установку и поддержку оборудования, на лицензии, а также фонд оплаты труда для штатных ИБ- и ИТ-специалистов;
- при размещении ПО в облаке — на обслуживание этого облака, на лицензии, на ФОТ сотрудников.
Другой вариант предоставления VM — в рамках комплексного решения по обеспечению кибербезопасности. Как правило, это дешевле самообслуживания. С другой стороны, функциональность VM в таких комплексных решениях обычно сильно урезана. Например, на рынке часто можно встретить такое комплексное предложение, как аудит информационной безопасности, в рамках которого часто бывает заявлен и VM. Но аудит представляет собой разовое действие по инвентаризации активов, сканированию и приоритизации уязвимостей, тогда как эффективность сканирования достигается только за счёт регулярности этого процесса. В противном случае невозможно увидеть динамику появления новых уязвимостей, построить стратегию по их устранению и следить за её реализацией. Поэтому при выборе подобных услуг важно понимать полный их состав и закрываемые проблемы, а также сравнивать их с текущими потребностями компании.
Наконец, третий вариант — сервис VM. В этом случае сканер размещён в облаке сервис-провайдера, который занимается техническим обслуживанием и предоставляет свою экспертную квалификацию по обработке и анализу собранных данных. Также некоторые провайдеры предлагают в виде дополнительной опции доступ к сканеру ещё и для штатных ИБ-специалистов заказчика.
Если сервис-провайдер оказывает качественную услугу, то для компании сервисный подход окажется наиболее выгодным по ряду причин. Во-первых, за меньшие деньги можно получить более совершенные технологии. Во-вторых, эксперты сервис-провайдера имеют доступ к масштабной и актуальной базе уязвимостей, собранной на основе информации из других сервисов. Также услуга обладает большей гибкостью, чем собственное ПО. К ней можно оперативно подключить новые хосты, так как для этого не требуется перенастройка ПО и закупка дополнительных лицензий. Наконец, при самостоятельной реализации сканирования анализ результатов ложится на плечи штатного безопасника, у которого помимо этого есть другие задачи, так что в итоге подготовка отчёта может занять много времени. Сервис-провайдер же обычно стремится сократить срок подготовки отчёта, так как для его специалистов оперативная работа с клиентом является приоритетом и конкурентным преимуществом.
Откуда сканер узнаёт об уязвимостях
Для пополнения банка уязвимостей сканера могут использоваться как международные базы данных (например, vulners.com), так и региональные (например, в РФ это — БДУ ФСТЭК России). Механика пополнения данных об угрозах зависит от ориентированности вендора на международный или внутренний рынок.
Вендоры, которые пополняют свои базы из международных банков уязвимостей, как правило, не учитывают региональную специфику сканируемых объектов. В итоге у них практически не будет информации об уязвимостях в ПО, которое создано, например, российскими компаниями.
Региональные вендоры, напротив, учитывают все особенности используемого в регионе ПО за счёт доступа к местным банкам уязвимостей. Но у таких сканеров — заметно меньшая скорость и полнота получения данных из международных источников.
Безусловно, сканер может использовать одновременно и местные, и международные базы знаний, но постоянная синхронизация с таким количеством разноплановых источников является для вендора сложной задачей. Необходимо договориться с регуляторами из разных стран, реализовать техническую совместимость разных источников, потратить средства на абонирование обновлений множества баз. Поэтому вендору проще и выгоднее либо определить для себя конкретный регион, либо работать глобально, не углубляясь в местную специфику.
Выводы
Как видно, вариантов реализации VM действительно много. Выбирая из разных предложений на рынке, компании стоит учитывать ряд факторов: как построена её ИТ-инфраструктура и насколько она специфична, есть ли региональные особенности, много ли удалённых хостов, есть ли штатные специалисты для обслуживания сканера и финансовые резервы для закупки собственного ПО. Чем чётче компания сформулирует ответы на эти вопросы, тем успешнее получится построить внутренние ИБ-процессы.
