Новое слово в управлении уязвимостями: как повысить эффективность vulnerability management?

По данным проведенного нами опроса^[1] среди специалистов по ИБ, в процессе управления уязвимостями больше всего времени уходит на разбор результатов сканирования и убеждение ИТ-отделов в необходимости ставить обновления. Службам ИБ требуются инструменты, которые помогут анализировать и приоритизировать уязвимости, определять регламенты их устранения и контролировать выполнение всех обновлений. Сканеры уязвимостей и средства анализа защищенности не могут полностью охватить весь процесс управления уязвимостями — для этого нужны системы vulnerability management (VM) нового поколения.

Какие существуют инструменты анализа защищенности сегодня? Какой должна быть система управления уязвимостями нового поколения? Как грамотно выстроить процесс vulnerability management? Пока мы искали ответы на эти вопросы, обнаружили ряд нюансов, закономерностей и правил, которые могут заметно упростить работу специалистов по ИБ.

Без чего VM не сработает?

Прежде чем начать строить процесс управления уязвимостями, важно учесть несколько ключевых моментов. Во-первых, придется начать мыслить не категориями IP-адресов, а ИТ-активов (серверы, компьютеры, сетевое оборудование и другие элементы инфраструктуры, подключенные к сети). В ИТ-инфраструктуре компании появляются новые системы, IP-адреса также могут меняться от сканирования к сканированию. Опираться на них не эффективно: представьте, вы сканировали узел с Windows XP, а через неделю по тому же адресу уже размещен Windows 7 с другим набором софта. Если вы задаете список IP-адресов для сканирования, то невозможно отследить, насколько полон ваш список: учтены ли те узлы, которые появились в сети в интервале между сканированиями, или те, о которых вам, возможно, забыл сказать ИТ-отдел. Для управления уязвимостями важно видеть всю инфраструктуру в любой момент времени. Поэтому мы рекомендуем начать с обнаружения и идентификации активов и получения полных сведений об узлах и системах. TAdviser Security 100: Крупнейшие ИБ-компании в России 59.8 т

Во-вторых, у каждого актива должен быть определен уровень его значимости. После обнаружения и идентификации активов нужно определить, какие из них наиболее важные, как они влияют на конфиденциальность и целостность данных, работоспособность значимых сервисов. Именно на это вам придется опираться, когда будете решать, какие уязвимости устранять в первую очередь.

В-третьих, нужно научиться приоритизировать уязвимости. Устранить их все не получится, ведь их число ежедневно растет. Только на одну систему в среднем приходятся 22 уязвимости^[2], четыре из которых имеют высокий уровень риска. По итогу сканирования специалист по ИБ сталкивается с огромным списком уязвимостей. Поэтому важно определить, какие из них необходимо устранить в первую очередь, а какие — в рамках заданных внутренней политикой сроков.

В-четвертых, стоит определить, как будут устраняться и проверяться уязвимости, как будет выстроено взаимодействие между службой ИБ и ИТ-подразделением. Как правило, за обнаружение и контроль устранения уязвимостей отвечают специалисты по ИБ, а закрывает уязвимости служба ИТ. ИТ-отдел как ответственный за систему лучше знает специфику ИТ-инфраструктуры и периоды времени, подходящие для установки патчей. Но в таком случае специалист по ИБ лишен возможности быстро закрыть горящую уязвимость самостоятельно — для этого нужно обращаться в ИТ. Поэтому важно договориться заранее, какими будут действия в случае появления опасных и менее серьезных уязвимостей, и, конечно, добиться устранения в срок даже не самых существенных из них.

Таким образом, эффективное управление уязвимостями должно включать: сбор информации об активах, классификацию активов, поиск уязвимостей, их приоритизацию и задание правил на обработку, устранение уязвимостей и проверку результатов устранения.

Сетевые сканеры уязвимостей

Сетевые сканеры уязвимостей, в том числе XSpider^[3], предназначены для оценки защищенности узлов сети. Их можно отнести к первому поколению систем vulnerability management. Этот класс решений сканирует не всю инфраструктуру, чаще всего это проверки компьютеров и серверов по открытым портам. Контроль происходит по задаваемому списку IP-адресов, без поддержки одновременного сканирования нескольких элементов. В основе процесса метод черного ящика, когда оценка защищенности информационной системы производится путем имитации внешней атаки без предварительного получения дополнительной информации о тестируемом продукте от владельца. В итоге пользователь получает отчет, который содержит список уязвимостей.

Но у сканеров есть существенные ограничения. Они выявляют только уязвимости в программных продуктах, имеющие сетевой вектор эксплуатации, и не обнаруживают ошибки конфигурации и слабые пароли. Этот класс решений не дает возможность проводить полную инвентаризацию активов, так как не позволяет что-либо узнать о ПО, не «торчащем» портами в сеть.

Отчет об уязвимостях содержит только список уязвимостей. Чтобы понять, что поменялось с момента прошлого сканирования, необходимо вручную сопоставлять результаты сканирования и соотносить, к какому узлу что относится. Если сканирование проводится в компании, у которой несколько филиалов, то чаще всего централизованно выгрузить результаты со всех сканеров нет возможности. Кроме того, если в ИТ-инфраструктуре появляется новый узел, то, как показывает наш опыт, он может не попасть в списки сканирования.

Тем не менее сканеры уязвимостей подходят компаниям с небольшой инфраструктурой (до 2000 узлов). Как правило, в таких организациях список компьютеров условно можно вести в таблице Excel, появление нового устройства — заметное событие, а количество уязвимостей относительно небольшое. В этом случае необходимости в полноценном процессе vulnerability management нет: если в такой компании и происходит сканирование, то редко, и оно касается только важных систем, уязвимости устраняются вручную и нечасто. C этой точки зрения сканер уязвимостей дает лишь общее представление о состоянии защищенности организации. В случае с крупными организациями возможностей сканера явно будет недостаточно.

Системы анализа защищенности

Второе поколение решений для выявления уязвимостей, которые учли некоторые ограничения сканеров, — это системы анализа защищенности, в том числе MaxPatrol 8^[4]. Системы анализа защищенности создавались с прицелом на большие организации, инфраструктура которых распределена и включает большое количество узлов (скажем, более 2000). Такие компании имеют необходимость в параллельном сканировании и консолидации результатов.

Поиск уязвимостей с помощью систем анализа защищенности проводится не только на серверах и рабочих станциях, но и в сетевом оборудовании. В основе решения сканирование не только методом черного, но и белого ящика, когда для оценки защищенности используются все имеющиеся данные об узле (в том числе архитектура и версии ОС и прикладного ПО). Решение собирает информацию об установленном софте и сообщает об уязвимостях в нем, а также включает возможности поиска ошибок конфигурирования и слабых паролей.

По итогам сканирования система анализа защищенности предоставляет дифференциальные отчеты^[5], благодаря которым можно проанализировать, что изменилось с прошлого раза, а также гибкие возможности планирования (повторные запуски, учет периодов времени, доступных для сканирования) и поддержку внешних и внутренних стандартов.

Так же, как и сканеры уязвимостей, системы анализа защищенности имеют свои ограничения. Решения этого класса не сканируют всю инфраструктуру, так как тоже оперируют IP-адресами. За счет активного поиска и импорта списков из Active Directory, каталогов и CMDB^[6]-систем покрытие значительно улучшилось, но системы такого класса все равно не охватывают 100% ИТ-инфраструктуры.

Этот класс продуктов не решает проблему приоритизации и устранения уязвимостей. Все уязвимости априори невозможно закрыть — так какие из них следует устранять в первую очередь? Во-первых, нет понимания, сколько уязвимостей нужно закрыть, чтобы обеспечить достаточный уровень безопасности инфраструктуры. Во-вторых, непонятно, как приоритизировать критически опасные уязвимости. Можно опираться на рейтинг CVSS^[7], но тогда специалисту по ИБ придется соотносить информацию по шкале со спецификой своей инфраструктуры (уязвимости с более низким рейтингом, но на периметре сети, против уязвимостей с высоким рейтингом внутри сети). Некоторые вендоры начали предоставлять свои списки критически опасных уязвимостей на основании оценки CVSS, типа уязвимости и других параметров. Однако это по-прежнему не сокращает количества уязвимостей, которые необходимо закрыть. Кроме того, нет уверенности, что скорингам всех вендоров можно доверять, так как не все имеют необходимую экспертизу.

Системы анализа защищенности централизованно сканируют узлы и сетевое оборудование в режиме черного и белого ящика, экспортируют результаты во внешние системы для ИТ-подразделения, которое будет закрывать уязвимости. Но они не решают проблемы приоритизации уязвимостей, взаимодействия подразделений ИТ и ИБ в части устранения уязвимостей и его контроля (например, нет возможности задать правила устранения уязвимостей среднего и слабого уровней риска, а также проверять соблюдение этих правил).

Системы управления уязвимостями

VM-решения^[8] нового поколения нацелены исключить оставшиеся ограничения и дать специалисту по ИБ возможность построить полноценный процесс управления уязвимостями в рамках организации. Конечно, этот класс продуктов должен включать преимущества предыдущих: сканировать активы в режиме черного и белого ящика, по гибкому расписанию, централизованно выгружать результаты сканирования и экспортировать их в сторонние системы, предоставлять дифференциальные отчеты, но вместе с тем опираться на активы вместо IP-адресов. VM-система позволит учитывать изменения любой информации в инфраструктуре — смену IP-, MAC адресов, модернизацию оборудования, восстановление системы из бэкапа, появления новых сетевых карт, кластеров, систем с несколькими интерфейсами, — а также хранить данные о конфигурации и историю сканирования для каждого актива, что поможет при расследовании инцидентов.

VM-система призвана обеспечить актуальность сведений об инфраструктуре за счет получения данных из множества источников: самостоятельного сканирования активов, импорта данных из SCCM^[9], Active Directory, использования экспертизы, присутствующей в других решениях ИБ. Также VM позволяет проводить пассивное сканирование — за счет интеграции с SIEM-системой^[10] мониторить сеть и извлекать данные о том, кто из пользователей и по каким протоколам взаимодействовал, и на основании этого создавать новые активы и обновлять данные по существующим.

С помощью VM специалисты по ИБ смогут приоритизировать активы — их классификация поможет сконцентрироваться на работе с приоритетными узлами и отследить появление новых активов.

Система позволит задать и контролировать регламент по актуализации данных об узлах и сетевом оборудовании: информация об активах будет регулярно обновляться, поэтому в компании должна быть принята и исполняться политика сканирования активов в режиме черного и особенно белого ящика. Если какие-то активы были выключены, недоступны или находились на техобслуживании, то плановое сканирование может быть пропущено. Это может привести к тому, что уязвимость в таком ПО будет использована злоумышленником при развитии атаки. Политика сканирования должна соблюдаться в обязательном порядке, а ее нарушения должны фиксироваться и устраняться. Лучше, если необходимые функции для этой работы будет предоставлять VM-система.

Поддерживать политику по устранению уязвимостей (патч-менеджмент) тоже будет проще. Как правило, в компаниях организуют так называемые вторники патчей (patch Tuesday), когда вечером ИТ-служба устанавливает необходимые патчи для устранения уязвимостей на всю сеть. Такой вторник может случаться каждую неделю, раз в две недели или раз в месяц, но он должен быть, чтобы найденные уязвимости исправлялись за установленный промежуток времени (факт того, что это не сделано, будет означать, что что-то пошло не так). Таким образом мы получаем следующее требование к политике: работать в штатном режиме, если найденная уязвимость передана в ИТ и SLA по устранению уязвимостей выдерживается, и сигнализировать, если SLA не выполнен. Это и есть тот самый контроль взаимодействия с ИТ, которого так не хватало в системах VM второго поколения.

Решение также позволяет исключить некоторые уязвимости из стандартного цикла обработки, провести быструю идентификацию уязвимых систем, выборочное и точечное сканирование (чтобы убедиться, что уязвимость устранена), проверить и соответствующим образом обозначить принятые компенсационные меры там, где по каким-то причинам было принято решение не обновлять систему.

VM-система также должна уметь информировать о критически важных уязвимостях. Устранение особо опасных из них, например как это было в случае эпидемии WannaCry^[11], нужно проводить быстро и в экстренном режиме. При этом процесс не должен останавливать деятельность самой организации. Современные VM-решения это обеспечивают. Вендоры, которые основывают свои разработки на исследованиях активности злоумышленников, понимают, какими уязвимостями и в каких сценариях атакующие пользуются в реальной жизни, поставляют списки критически важных уязвимостей. Лучше, если это конечное перечисление трендовых уязвимостей, а не переработанный документ по всем найденным уязвимостям. Конечно, это предъявляет серьезные требования к квалификации самого вендора: на рынке не так много производителей VM, которые имеют экспертизу не только в разработке ПО, но и в обеспечении реальной информационной безопасности.

Резюмируя все перечисленные возможности систем управления уязвимостями, отметим их главную миссию: продукт помогает компании построить полноценный процесс, включающий все этапы и тонкости работы с уязвимостями — их выявление, приоритизацию, взаимодействие служб ИТ и ИБ, формирование политик актуализации и устранения. Такая система полностью закроет недостатки предыдущих поколений решений и позволит наиболее успешно выстроить процесс управления уязвимостями в компании.

16 ноября 2020 года состоялась онлайн-встреча, на которой мы представили средство управления уязвимостями нового поколения MaxPatrol VM. Мы рассказали, как грамотно выстроить процесс управления уязвимостями в компании и продемонстрировали отличия MaxPatrol VM от систем анализа защищенности. Посмотреть запись мероприятия можно на сайте Positive Technologies.

Примечания