Как вовремя обнаружить, классифицировать, приоритизировать и устранить найденные в софте уязвимости? В эфире AM Live эксперты обсудили, как автоматизировать процесс Vulnerability Management и как могут развиваться молодые стартапы, готовые примкнуть к разработчикам программных систем VM.
- Введение
- Классический подход к процессу поиска и устранения уязвимостей
- Управление уязвимостями
- Эффективная борьба с уязвимостями требует точного выбора действий
- Приоритизация уязвимостей: задача для аналитика или робота?
- «От вендоров, которые сами не ищут уязвимости в своих продуктах, следует отказываться»
- Мнение рынка через опрос зрителей трансляции
- Трудности при устранении уязвимостей
- Качество обнаружения уязвимостей
- Время скриптов ушло
- Импортонезависимость российских систем управления уязвимостями
- Способы детектирования уязвимостей
- Управление уязвимостями — новая ниша для решений
- Выводы
Введение
Обсуждение темы управления уязвимостями (VM) на AM Live проводится уже второй раз, первое обсуждение состоялось год назад. Благодаря этому появилась возможность качественно оценить текущее состояние российского рынка в этой области. Вопросы, на которые могли ответить зрители трансляции, сравнивались затем с результатами, полученными год назад при первом обсуждении.
Модератором дискуссии выступил Лев Палей, начальник службы информационной безопасности АО «СО ЕЭС».
В обсуждении приняли участие следующие эксперты:
- Сергей Уздемир, заместитель генерального директора по ИТ, «АЛТЭКС-СОФТ».
- Александр Дорофеев, генеральный директор компании «Эшелон Технологии».
- Владимир Михайлов, руководитель департамента перспективных проектов, «Фродекс».
- Илья Егоркин, руководитель направления по развитию решений для управления уязвимостями и мониторинга ИБ, Positive Technologies.
- Александр Леонов, ведущий аналитик по ИБ, «Тинькофф».
- Максим Бронзинский, руководитель направления Vulnerability Management платформы Solar MSS, «Ростелеком-Солар».
Классический подход к процессу поиска и устранения уязвимостей
Лев Палей, модератор дискуссии, предложил начать обсуждение с того, чтобы дать определение самому процессу поиска и устранения уязвимостей. Что принято считать классическим? Какие важные отклонения от классического подхода встречаются в последнее время?
Максим Бронзинский предложил следующее описание: «Управление уязвимостями охватывает несколько этапов. Сначала происходит выявление всех возможных “активов” в айти-инфраструктуре компании, которые могут быть подвержены уязвимостям. Получив этот список, можно найти реальные уязвимости, которые уже известны, и заняться их устранением. Проводится также контроль того, что уязвимости действительно устранены».
Самым ответственным и, пожалуй, самым сложным этапом, вызывающим наибольшее внимание, был выбран этап удаления уязвимостей. «На этапе удаления уязвимостей, — дополнил Сергей Уздемир, — важно обратить внимание на приоритизацию последовательности выполняемых работ. Если уязвимости удалять “линейно”, просто перебирая их в случайном порядке появления, например, то процесс становится невероятно долгим. Это не может удовлетворить никого: ни клиентов, ни поставщика услуг».
Причиной затягивания процесса является то, что список возможных уязвимостей может быть «близким к бесконечности». Они связаны с очень разными особенностями ПО и инфраструктуры, при этом в реальности в компаниях могут появляться только часть уязвимостей, известных вендору.
«Следует не просто выявить уязвимости, а также присвоить каждой из них свой приоритет, степень важности. Приоритизацию можно выполнять по разным направлениям: по софтовым продуктам, по активам айти-инфраструктуры, по степени создаваемой угрозы», — уточнил Сергей Уздемир.
Рисунок 1. Используемые инструменты для VM
Управление уязвимостями
Процесс работы с уязвимостями — это не просто перебор всего существующего списка потенциальных угроз. Это — сложный процесс, который требует собственного управления.
«Управление уязвимостями — это часть системы управления существующими рисками, — заявил Александр Дорофеев. — Сначала мы находим уязвимости, занимаемся их приоритизацией. На этом этапе проявляются признаки, требующие управления. Необходимо сразу задать, как будут обрабатываться выявленные риски.
Существуют различные варианты: можно заняться их непосредственным устранением, можно собирать их в группы и передавать на другой уровень для обработки, и т. д. Таким образом, уже на этапе анализа активов на предмет наличия уязвимостей необходимо иметь готовую стратегию для работы с рисками».
Эффективная борьба с уязвимостями требует точного выбора действий
Устранение уязвимостей — это также вполне определённый, а не стохастический процесс. Тактика его реализации во многом определяется тем, какие «инструменты» используются для решения поставленных задач.
Выбор тактики имеет важное значение, считают участники дискуссии. Если она не определена и вопросы решаются стихийно, то задача устранения уязвимостей «теряет границы». У компании возникает «нехватка времени, ресурсов, возможностей», отметил Александр Дорофеев. «На это следует обращать внимание заранее».
Почему нельзя действовать линейно, шаг за шагом, просто искать и устранять уязвимости, о которых приходит информация?
Если заставлять сисадминов постоянно заниматься простым патчингом систем, то они «просто взвоют от чрезмерной нагрузки». Следует действовать иначе: после выбора приоритетных уязвимостей администраторы будут исправлять только те из них, которые относятся к уровню «критические». На уязвимости, которые формально имеют степень «medium» или «low», никто не будет обращать внимания.
Процесс устранения уязвимостей является «творческим», считает Александр Леонов. Он не просто требует выявления брешей, которые могут проявиться в инфраструктуре компании, но и должен выполняться так, чтобы добиться экономии людских ресурсов. Процесс не должен выстраиваться по формальному принципу цикла интерактивной разработки и управления PDCA (Plan-Do-Check-Act).
Когда создаётся поток задач, то сразу возникает вопрос: кому поручать их выполнение? Отдать администраторам? Но тогда они должны переложить их на десятки тысяч хостов. После этого возникнет следующий вопрос: как отследить, что все известные уязвимости были вовремя закрыты на всех хостах?
Возникает прямая связь между приоритизацией уязвимостей и планированием работ. За этим следуют новые вопросы: на кого возлагать задачу по генерации приоритетов? Если назначать приоритеты автоматически, например следуя рекомендациям вендора, то насколько велика уверенность, что в его базе патчей прописаны все новые эксплойты?
Такой поток задач, требующих решения, упирается в другую проблему: наличие в компании компетентного аналитика. Сколько их должно быть? От кадров зависит то, как решается задача устранения уязвимостей в компании.
Рисунок 2. Используемые инструменты для VM
Приоритизация уязвимостей: задача для аналитика или робота?
В ходе дискуссии Александр Леонов высказал мнение, что выбор степени критической значимости уязвимости целиком опирается на работу аналитика. Сам он основывается в своих оценках на различных формальных признаках, которые появляются в новостях из различных источников. «Новости во многом указывают, что нужно делать как можно скорее. Моё мнение: аналитик должен выделить верхний слой критически важных уязвимостей. Все остальные работы с уязвимостями должны выполняться в рамках обработки поступающих патчей от вендоров».
Илья Егоркин добавил, что «в реальной практической работе ключевым становится дефицит ресурсов, дефицит аналитиков, которые могут провести грамотный аудит наиболее важных ресурсов. Важно выстроить правильные коммуникации с сотрудниками отдела ИБ.
В целом процесс во всех компаниях похож: сначала проводится выявление наиболее значимых, “трендовых” уязвимостей. Для этого собираются новости из разных источников, в том числе даркнета. Упоминаемые уязвимости анализируются, проверяются на степень зловредности для текущей инфраструктуры компании. В результате формируется список трендовых уязвимостей, а по ним создаётся список приоритизации».
«В то же время следует признать, что хороших аналитиков не хватает на все компании, — отметил Владимир Михайлов. — Поэтому уровень автоматизации при устранении уязвимостей требует автоматического патчинга. Для достижения постоянного высокого уровня безопасности необходимо стремиться к тому, чтобы устранить в будущем субъективность, возникающую от человеческого фактора».
«Устранить человеческий фактор — это очень сильное заявление!» — заметил модератор дискуссии.
Впрочем, в настоящее время пока рано говорить о том, что забота о безопасности ляжет целиком на плечи программных роботов. Первые оценки приоритета той или иной уязвимости делают вендоры. Вопрос об автоматизации лежит в плоскости того, когда аналитики в компании добавляют или изменяют оценки вендоров с учётом реально используемой в компании инфраструктуры.
«На мой взгляд, экспертиза и архитектура каждой компании предполагают учёт большого количества особенностей. По базовым признакам невозможно оценить приоритет уязвимости с точки зрения конкретной компании. «Поэтому отказ от использования труда человека в компании — это абсолютно нереально», — высказал свою точку зрения Лев Палей.
«От вендоров, которые сами не ищут уязвимости в своих продуктах, следует отказываться»
Выстраивая работу с уязвимостями, необходимо обращать внимание на то, как конкретный вендор работает с ними. Насколько вендор способен выделить уязвимости в собственных продуктах, насколько правильно он назначает их приоритет — вот главные вопросы.
Надо смотреть конкретные решения и явные кейсы из прошлого. Если раньше вендору удавалось “попадать в точку”, выявлять то, что делали аналитики внутри коммерческих компаний, тогда задачу “автоматизации” при назначении приоритетов можно попробовать переложить на вендора». Это позволит внедрить автоматизацию в процесс устранения уязвимостей внутри компании.
«Наилучший подход — это совмещать результаты, которые дают аналитики внешних компаний, представители вендоров, собственные аналитики, — отметил Илья Егоркин. — Если в случае возникающих проблем все участники успевают проработать свою часть вовремя, то это — идеальный вариант».
«Оценивая подготовительную работу вендора, можно переложить на них, частично или полностью, задачу выделения приоритетов в уязвимостях. Это создаёт хорошие предпосылки для дальнейшей автоматизации процесса работы с уязвимостями внутри компаний. Если же вендоры не успевают за темпом появления уязвимостей, то компаниям следует действовать самостоятельно и выполнять приоритизацию собственными силами. Люди останутся важным элементом в процессе», — высказал свою точку зрения Александр Дорофеев.
«Этот вопрос можно рассматривать в двух проекциях: с точки зрения технологий и с точки зрения процессов, — заявил Илья Егоркин. — Технологический подход очевиден: список применяемых технологий автоматически порождает комплекс дальнейших мероприятий. Могут быть разные вендоры, разные классы решений, но по сути — этот подход хорошо согласуется с возможностью дальнейшей автоматизации.
Иначе обстоят дела, когда речь заходит о процессах. Требуется единое управление, которое будет распространяться на все типы применяемого ПО: операционные среды сторонних разработчиков, собственные системы, заказное ПО, DevOps, элементы эксплуатации ПО в компании. Несмотря на существующие принципиальные отличия между этими элементами, они должны быть частью единого процесса управления устранением уязвимостей.
Из этого можно сделать один необычный, но важный вывод. Независимо от того, кто ведёт разработку той или иной системы, если компания или группа разработчиков ведёт себя как вендор, то она обязана придерживаться строгих сроков при выпуске патчей по своему продукту. Если это не выполняется, то от такого вендора / продукта следует избавляться».
Аналогичный подход проявляется и при выборе нового продукта. Как отметил Александр Леонов, «самый простой способ — зайти на сайт разработчика и посмотреть, насколько часто он выпускает бюллетени по безопасности. В реальных разработках невозможно полностью исключить ошибки, какой бы вендор ни стоял за продуктом. Даже если продукт сложен (типа ОС или СУБД), если патчи для него выходят только раз в два-три года, то лучше сразу уходить от такого вендора».
Рисунок 3. Устранение проблемы при ограниченных возможностях VM
Мнение рынка через опрос зрителей трансляции
В ходе дискуссии прошло обсуждение результатов опросов зрителей. Были предложены следующие вопросы:
- Какие программные инструменты используются в вашей компании?
- Что является определяющим при выборе системы Vulnerability Management?
- Какие действия предпринимает ваша компания, если закрыть уязвимость установкой патчей невозможно?
- Какие изменения в процессе управления уязвимостями произошли в вашей компании в 2022 году?
Интерес представляет также то, что аналогичные вопросы задавались год назад. Сравнивая результаты прошлогоднего и нынешнего опросов, можно увидеть динамику происходящих изменений.
Трудности при устранении уязвимостей
Лев Палей предложил Максиму Бронзинскому рассказать о том, с какими трудностями приходится сталкиваться на практике. Главной проблемой стало использование систем, которые предлагают «полный охват процесса устранения уязвимостей», хотя фактически не решают этой задачи. Как заявил Максим, в реальности это больше напоминает «псевдоменеджмент».
Такие системы уже используют встроенные процессы обработки. Это сильно ограничивает возможности аналитика в компании. Они лишают гибкости при принятии решений. Это касается в том числе систем отличающихся наличием огромного количества настроек. Такая избыточность только усложняет процесс по заданию приоритетов для уязвимостей. Более того, подобные системы часто не позволяют выбрать актив или уязвимость, которые в компании хотят признать критическими.
Реальность при использовании таких систем порождает неопределённость: если вдруг какая-то уязвимость не может быть устранена, особенно если выполняется патч-менеджмент в автоматическом режиме, то на кого следует перекладывать ответственность? В этих случаях «программа решает», что виноват сам пользователь.
Ещё одна сложность связана с наличием у таких программ ограничений, наличие которых не очевидно сначала. Чаще всего такие ограничения проявляются, когда структура и инфраструктура компании начинают меняться. Например, это происходит при появлении распределённой или распределённо-удалённой сети в компании. В этом случае возникает необходимость установки нескольких сканеров безопасности, что увеличивает затраты. Возникают и другие трудности, например с агрегированием собираемых данных. При наплыве уязвимостей часто нет возможности даже наглядно отобразить текущую ситуацию.
Качество обнаружения уязвимостей
Острой становится также проблема контроля качества применительно к результатам детектирования уязвимостей. Поиск брешей выполняется на основе постоянно обновляемой базы знаний. Как она формируется? Это вопрос, на который вендор обычно не отвечает.
Свои трудности добавляет и используемая операционная среда. Если в Linux многие проблемы решаются «с лёта» благодаря прозрачности самой системы, то в Windows накладываются проблемы поддержки предпринимаемых действий со стороны VM и продуктов. Найти информацию часто невозможно, разве что опытным путём. Прозрачность в детектировании уязвимостей — это одна из самых важных проблем на текущем этапе.
Вторая «боль» — это уровень детализации регистрируемых проблем. Пользователь получает только информацию в отчёте вендора, содержащую краткие процедуры исправления уязвимостей. В настоящее время производители недостаточно плотно интегрированы в процесс патчинга.
«Им не надо сразу автоматизировать патчинг, потому что это приведёт к проблемам совместимости, — считает Александр Леонов. — Для начала надо выстроить методологическую поддержку, как происходит процесс патчинга, что он затрагивает. Это можно выстроить в виде Excel-дерева, по которому потом будет подготовлен нужный скрипт».
Рисунок 4. Изменения поддержки VM в 2022 году
Время скриптов ушло
«Написание скриптов ушло в далёкое прошлое», — возразил Александр Дорофеев. Сейчас базы данных уязвимостей доступны у регуляторов и аффилированных с ними компаний.
Новые решения строятся по другому принципу: сначала выполняется сбор версий стека установленного ПО с поддерживаемых узлов. После этого осуществляются их парсинг и патчинг. Запросы о необходимости установки того или иного патча выполняются автоматически по известным источникам. Время сканирования узла сокращается с 20–30 минут до одной минуты. При этом доступны инструменты контроля актуальности патчей.
«На практике возникает множество ситуаций, когда идеальные условия не соблюдаются, — возразил в ответ Александр Леонов. — Например, при установке стороннего софта, который не рассматривался вендорами. Другой вариант — это прозрачность экспертизы, использованной при формировании списков поддерживаемых уязвимостей. Далеко не всегда информация меняется своевременно. Это порождает мнимое ощущение безопасности».
Импортонезависимость российских систем управления уязвимостями
Важную часть дискуссии заняло обсуждение темы обеспечения импортонезависимости российских систем управления уязвимостями. Как рассказал Александр Дорофеев, в настоящее время при разработке российских продуктов рассматривается поддержка только Linux-систем (Debian / Astra). Поддержка Windows отсутствует, вопрос о её поддержке может быть рассмотрен только в очень отдалённом будущем.
В то же время уже есть база знаний по уязвимостям. В БДУ ФСТЭК России присутствует информация о 39 тысячах уязвимостей, в том числе самых последних. Часть этой базы публична, другая часть доступна заказчикам, которые имеют доверительные отношения с ведомством. Гарантируется устойчивость применения этой системы даже в случае отключения для России доступа к интернету.
Илья Егоркин также обратил внимание на необходимость импортонезависимости самой разработки продуктов. Если есть зависимость от репозитория кода и других библиотек, то говорить о полной автономности нельзя. В то же время он отметил, что в настоящее время уже сделано очень многое в этом направлении.
Владимир Михайлов добавил, что база данных ФСТЭК России хотя и доступна, но не может быть названа полной. Максим Бронзинский добавил, что ФСТЭК России не делится информацией о том, как происходит детектирование уязвимостей, что также снижает ценность предоставленной информации.
В то же время сохраняются проблемы относительно гарантий доступности информационных ресурсов вендоров. В случае их закрытия для российских пользователей обновлять информацию станет проблематично. Это создаст риски. Выстроить в новых условиях прямые контакты с вендорами может оказаться непосильной задачей.
Сергей Уздемир также отметил, что современные сканеры уязвимостей осуществляют проверку не только ПО, но и оборудования, межсетевых экранов, промышленных систем. Если данные не накапливаются постоянно, то могут возникнуть другие проблемы, связанные с импортонезависимостью.
Способы детектирования уязвимостей
Рассказывая о применяемых способах детектирования уязвимостей, Сергей Уздемир разделил их на два класса: работающие по принципу «чёрного ящика» и «белого ящика». Первые представляют собой своеобразные пентесты, моделирующие действия злоумышленника, вторые больше напоминают работу антивируса, по имеющейся сигнатуре выявляя характерную активность.
Управление уязвимостями — новая ниша для решений
В оставшейся части дискуссии прошло обсуждение практических аспектов применения программных систем. Участники смогли высказать свои мнения о том, какими свойствами, с их точки зрения, должны обладать применяемые детекторы, какие из них можно назвать эталонными, в каких дополнительных функциях испытывают потребность компании.
Отдельное внимание было уделено теме выявления уязвимостей в бизнес-логике. Они являются более сложными для детектирования, при этом их значимость для компаний значительно выше.
Не менее значима и стоимость продуктов. Она напрямую зависит от используемых правил лицензирования. Участники обсудили их особенности, высказали свои предпочтения при анализе. Они также рассказали о том, с какими трудностями сталкиваются при интеграции применяемых детекторов с прикладными решениями.
В завершение каждый участник дискуссии смог высказать своё мнение о ещё нереализованных нишах среди систем анализа уязвимостей. По этим направлениям могут работать стартапы, что будет интересно для получения практических решений.
Эта часть дискуссии была интересна практикам, которые ищут для себя возможности в реализации знаний и хотели бы создать для рынка собственный продукт, полезный и интересный с точки зрения экспертов.
Выслушивая предложения спикеров, Лев Палей оценивал их реализуемость в перспективе ближайших трёх-пяти лет.
Выводы
Ещё в самом начале дискуссии Лев Палей отметил, что характеристикой нынешнего времени является текущий процесс формирования архитектуры безопасности. В новых условиях особое внимание следует обращать на формирование архитектуры безопасности информационных систем.
Самые горячие для российского рынка информационной безопасности темы мы обсуждаем в прямом эфире онлайн-конференции AM Live. Чтобы не пропускать свежие выпуски и иметь возможность задать вопрос гостям студии, не забудьте подписаться на YouTube-канал Anti-Malware.ru. До встречи в эфире!
