Сергей Лебедев, Positive Technologies: Отличие MaxPatrol EDR — модульная архитектура, гибкие сценарии применения

Классического антивируса недостаточно для защиты конечных устройств корпоративных пользователей. Для эффективного обнаружения сложных киберугроз и реагирования на них нужны более современные средства — например, системы обнаружения целевых атак на конечных устройствах (Endpoint Detection and Response, EDR). О них мы поговорим сегодня с Сергеем Лебедевым, руководителем департамента разработки средств защиты рабочих станций и серверов в Positive Technologies.

Как, на ваш экспертный взгляд, должна выглядеть полноценная защита конечных устройств? Давайте рассмотрим минимальный достаточный вариант и максимальный для особо требовательных заказчиков.

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

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

Правильно ли отказаться от классического антивирусного ядра с сигнатурами и сделать ставку исключительно на EDR, или всё-таки следует использовать некое смешение этих технологий?

С. Л.: Для наших клиентов важен именно «микс»: сочетание возможностей Endpoint Protection Platform и Endpoint Detection and Response, с учётом ограничений инфраструктуры. Важный вопрос для вендора продуктов ИБ заключается в том, как донести подходящие технологии до клиента — например, в виде усиления традиционных средств защиты, основанных на сигнатурном анализе. Принципиально важно, что EDR позволяет обнаружить сложные атаки, когда хакер идёт по цепочке от одного хоста до другого. В организациях государственного, промышленного, финансового и медицинского секторов это особенно актуально.

Несколько лет назад обсуждалась технология отечественного EDR. Потом с нашего рынка ушли все EDR, которые поставляли зарубежные вендоры. У меня сейчас складывается ощущение, что с их уходом эта тема в России стала невостребованной. Я не вижу, чтобы кто-то об этом говорил. Нет ли у вас такого ощущения — что тема уходит из повестки дня? Что сейчас реально происходит на этом рынке?

С. Л.: Как раз наоборот. Точнее, чаще просто говорят о защите конечных устройств в общем, имея в виду и ЕРР, и решения класса EDR — важный компонент комплексной защиты. Согласно исследованию рынка кибербезопасности за 2023 год от Центра стратегических разработок, средства защиты конечных устройств занимают 15,5 % общего объёма рынка, причём почти все поставщики решений — отечественные, и объём рынка продолжает расти. Сама задача по обнаружению действий хакеров, борьбе с вредоносным кодом никуда не делась и с возросшим количеством АPT-атак стала ещё более актуальной. Просто тот рынок, который создавался в прежней геополитической ситуации, сильно изменился. 

Возможно, поэтому и возникает такое ощущение, что продукт EDR невостребован. Наши клиенты используют разные решения, не только системы класса EDR. Однако защита конечных точек — необходимая часть создания киберустойчивости в компании. Да, это можно это делать с помощью других классов продуктов, но сама по себе необходимость защищать конечные устройства остаётся неизменной. Сейчас наша цель — обеспечить средства, которые реально решают стоящие перед клиентами задачи.

Гораздо проще отслеживать и фиксировать атаки, когда они уже подходят к самым чувствительным местам в инфраструктуре, чем пытаться защитить всё, включая конечные точки, на которых, может быть, ничего и не будет. Возможно, следуя такой логике, кто-то осознанно жертвует качеством защиты конечных точек?

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

Наш продукт не менее полезен для сбора событий. Даже если мы обнаружим реальную атаку на хостах, нам нужно разобраться, почему это произошло, и исключить такие ситуации в будущем. А ещё важно правильно отреагировать. Без актуального и надёжного сбора событий полную картину получить невозможно. Поэтому нам нужна защита.

Многое зависит от того, как мы её сконфигурируем. Мы можем поставить её только как сборщик событий, а можем установить какой-то простой модуль и прямо на хосте сделать поведенческий анализ, корреляцию событий и прочее. Важно только не допустить «перегрева» системы.

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

Positive Technologies развивает концепцию результативной кибербезопасности. Её суть заключается в том, что недопустимые события, определённые заказчиком, никогда не должны реализоваться. Как здесь может помочь EDR? Насколько такие решения важны, например, для обнаружения целевых атак и реагирования на них на конечных устройствах?

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

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

Может быть и так, что атака на рабочую станцию сотрудника принесёт лишь неудобства, но не катастрофические последствия для компании. А вот остановка, допустим, контроллера по производству или потеря каких-то данных, которые лежат на сервере, может обернуться реальной проблемой. Чтобы этого не случилось, нужно защищать и системы управления производством, и сами хосты, на которых они работают. 

Кроме того, хакерам нужно пробраться через цепочку хостов, и на каждом этапе задача — не дать им пройти дальше, обнаружить эту атаку и ответить, например заблокировав учётную запись.

Что важного «под капотом» MaxPatrol EDR, что происходит и учитывается при развитии вашего продукта с технической точки зрения?

С. Л.: Тут можно выделить несколько больших направлений. Первое — менеджмент и администрирование системы. Второе — качество. Третье — экспертиза, которую в продукт регулярно добавляют наши специалисты из PT ESC. Если говорить о первом, то мы прилагаем много усилий, чтобы «облегчить» агент, сделать управление политикой безопасности более удобным, реализовать механизм по созданию шаблонных политик. Также мы добавляем исключения по умолчанию для конкретных операционных систем. 

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

Второе — это экспертиза, то есть наращивание сигнатур, правил обнаружения, корреляций и всего того, что мы используем в продукте для обнаружения реальных угроз. Даже с точки зрения сбора событий в Windows есть разные способы и источники. Мы добавляем такие правила корреляции, которые сами по себе дают срабатывание, а ещё — такие, которые не могут явно фиксировать действие характеризующее атаку, но дадут аналитику SOC дополнительный контекст для последующего принятия решений.

Например, создание пользователя с правами администратора не обязательно говорит о том, что уже происходит какая-то атака. Но если там же запускалась какая-то вредоносная программа, то корреляция, которую обнаруживает агент, даёт дополнительную качественную результативность.

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

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

Есть ли какие-то уникальные возможности, которые отличают MaxPatrol EDR от конкурентов?

С. Л.: Одно из ключевых преимуществ EDR — это готовность связываться с другими нашими системами. Далеко не у всех продуктов есть такие возможности по интеграции через API. Кстати, наш API стал публичным, то есть теперь наши клиенты, применяя партнёрское решение, могут самостоятельно использовать API с хоста для своих целей, в том числе даже связанных с ИТ. 

Второе преимущество — это модульная архитектура, которая даёт ту самую гибкость. У нас — один агент, который очень вариативен в своих действиях. Не нужно ставить много агентов для разных компонентов. Всё делается через один агент и управляется одной политикой. 

Я правильно понял, что при необходимости можно использовать ваш агент EDR в том числе, например, для управления уязвимостями?

С. Л.: Да, это одна из задач, которую решают агенты. Важно сказать, что развитие MaxPatrol EDR — это, с одной стороны, прогресс EDR именно как решения в своём классе, но с другой стороны, и технология для других продуктов. Иначе говоря, у нас — один агент и единая архитектура, которая управляет доставкой политики конкретной конфигурации и позволяет получать результат для разных задач, включая управление уязвимостями, сканирование хоста для управления активами, реагирование из продукта MaxPatrol О2 и так далее.

Сейчас на российском ИТ-рынке идёт движение в сторону импортозамещения. Компании всё активнее переходят на российский стек технологий, в том числе на Linux, на почтовые системы, даже на службы каталогов и так далее. Как вы поддерживаете этот тренд и готов ли ваш EDR работать в такой среде?

С. Л.: Для нас одно из основных направлений деятельности — именно работа с российскими технологиями. Здесь я имею в виду работу агентов и на операционных системах, и на серверных компонентах. Кроме того, у нас есть интерес к сбору событий с хостов виртуализации. Мы также ведём отдельное направление (стрим) по части того, как сделать сбор с хостов для виртуальных машин.

Мы тесно взаимодействуем с производителями самих операционных систем, и это имеет большой приоритет в продуктовом развитии. У нас есть большая таблица ОС, их версий и дистрибутивов, которую мы постепенно закрываем в соответствии с запросами бизнеса. Мы даже построили скоринговую модель, чтобы понимать, что надо будет в соответствии с трендами поддержать в первую очередь.

А на «Авроре», например, можно будет поднять агент?

С. Л.: Мы добавляем поддержку операционных систем в соответствии с их актуальностью для рынка. Для нас это — вопрос приоритизации, ведь важно гибко реагировать на нужды клиента. Если будут запросы от разных клиентов, то мы вполне можем такое сделать. Сегодня существует множество разных систем, которые сложно даже учесть.

Можно использовать EDR как часть корреляции и как элемент детектирующей логики. Тогда встаёт вопрос: как часто его нужно обновлять? Не получится ли новый антивирус, который каждый час будет требовать какого-то обновления?

С. Л.: Нет необходимости постоянно запрашивать базу с новыми сигнатурами, чтобы сохранять высокий уровень обнаружения, так как наша экспертиза базируется в первую очередь на поведенческих правилах и на сочетании разнообразных технологий обнаружения. Всё достигается грамотной настройкой, поэтому не приходится каждый час или ещё чаще загружать трафик. Преимущество EDR заключается в том, что он фокусируется на поведении системы.

Как MaxPatrol EDR влияет на производительность конечных устройств? Проводили ли вы какие-то тесты на эту тему?

С. Л.: Конечно. Всё, что мы делаем, применяется и тестируется в нашей компании, на нашей собственной инфраструктуре, как если бы она была инфраструктурой клиента. Реальная нагрузка зависит от того, какие модули мы собрали в политике, и от того, какой объём активности происходит в системе. Если у нас в требованиях значится, что мы хотим ничего не пропустить при корреляции, то можно сконфигурировать так, что на любое изменение в файловой системе ответом будет сканирование этого файла с проверкой разными способами. 

Если мы каждый документ читаем с диска, это занимает какой-то объём ресурсов. Важно стабилизировать количество срабатываний на чтение больших файлов. Если на машине много изменений в правилах системы и мы хотим всё сканировать, это — осознанный выбор того, что мы «съедим» больше ресурсов, потому что такова задача. 

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

Есть соблазн собирать при помощи EDR максимальное количество информации о событиях. Встаёт вопрос о производительности и хранении данных. Как эту задачу решать в действительно больших инфраструктурах?

С. Л.: Большой объём событий нужно переваривать и быстро коррелировать — скажем, прямо на хосте. Задача хранения здесь также важна, есть разные варианты её решения. В одном случае EDR занимается только сбором событий, а корреляция происходит в SIEM; в другом случае необходимо делать корреляции прямо на хосте. Кроме того, мы можем передать информацию через Syslog в рамках интеграции в другие системы, потому что наше решение нужно использовать в комплексе, и расследовать события.

EDR решает задачи по-разному, но есть основная функция: сбор данных, обнаружение и реагирование. 

Очень часто в аббревиатуре EDR на практике выпадает последняя буква: реагированием по разным причинам не пользуются. Насколько готовы решения такого класса, а вместе с ними — и заказчики, к автоматизированному реагированию? В чём оно должно состоять, как должно происходить — автоматически или полуавтоматически?

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

В целом реагирование можно рассматривать как способ дотянуться до хостов в том случае, если сама система скомпрометирована. Для этого у нас есть средства реагирования: например, удалённое подключение (выполнение команд), частичная изоляция (устройство изолируется от интернета, но можно к нему обратиться и почистить его). 

Заказчики часто говорят, что распределение прав и полномочий между ИТ и ИБ в компании не позволяет ибэшникам производить автоматизированное реагирование. Есть ли в вашем EDR какой-то механизм по разграничению ролей, когда мы, допустим, даём определённые полномочия айтишнику и он сам действует через тот же интерфейс? Или такой необходимости на практике нет?

С. Л.: Мы всё чаще сталкиваемся с осторожным принятием реагирования. У нас действительно есть базовое разделение ролей, а вот создание системы, которая позволила бы создать произвольную роль, является одним из векторов нашего развития. Важно грамотно разделять возможности ИБ и ИТ, потому что запрос от клиентов на это есть. Некоторые организации очень трепетно относятся к тому, какие рычаги есть у ИБ. Именно поэтому в MaxPatrol EDR можно гибко управлять такими возможностями технически, на уровне модулей. Это позволяет руководителю ИБ в конечном итоге уверенно сказать ИТ, что важный DMZ-сервер будет под мониторингом, даже вредоносные файлы на нём будут удалены, но никакой изоляции не будет применяться. Для нашего продукта это — возможность обеспечить баланс между запросами ИТ и политиками службы ИБ.

На что смотреть при выборе EDR? Их сейчас много, а критерии выбора весьма размыты.

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

Нужен максимально большой объём детектирующих правил, реально закрывающий задачи. EDR — не просто инструмент, который нужно допустить в систему. Важно опираться на то, как система реально работает и какой приносит результат.

Вы приняли немного удивившее меня решение сделать свой EDR (или одну из его версий) опенсорсным. Зачем это было сделано? По итогам двух-трёх лет, что это дало? Есть ли от этого какой-то эффект?

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

Спасибо большое за интересное и подробное интервью! Мне самому понравилось погрузиться в эту тему. Узнал для себя новые моменты и по-другому посмотрел на уже известные.