Алексей Вишняков: Как получить реальную защиту от вредоносных программ «из коробки»

В этом году отечественному рынку ИБ была представлена новая версия песочницы PT Sandbox. Ранее мы опубликовали первую часть нашей беседы с одним из идеологов этого продукта — Алексеем Вишняковым, руководителем отдела обнаружения вредоносного ПО экспертного центра безопасности Positive Technologies (PT ESC). Сегодня продолжим и поговорим о механизме приманок, роли машинного обучения в продукте и месте песочницы в экосистеме Positive Technologies.

Алексей, на презентации PT Sandbox 5.0 вы рассказывали, что в песочницу поступают результаты ежедневного анализа вредоносных объектов. За счёт этого вы усиливаете возможности продукта?

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

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

Недавно прокатилась волна инцидентов с шифрованием и уничтожением баз 1С, содержащих значимую информацию, которую трудно восстанавливать. Как можно использовать приманки для защиты таких баз?

А. В.: Когда мы разрабатывали базу приманок, рассматривали и банковские трояны. Тут стоит упомянуть подразделение группы Lazarus, которое занималось финансовыми атаками и промышленным шпионажем. Вспомним также группировку RTM, которая была популярна в 2019 году. Все они активно атаковали 1С и приложения SWIFT: буквально внедрялись в них и запускали программный код, чтобы он собирал платёжные данные в отдельный файл, который потом можно было куда-то переместить. Мы эмулировали эти процессы и теперь контролируем доступ к ним. Сразу замечаем, когда кто-то начинает манипулировать процессами, и таким образом обнаруживаем банковские трояны. В России мы нечасто сталкиваемся с использованием таких вредоносов, но в атаках на другие страны — да. Например, таких троянов очень много в Латинской Америке. Они оперируют финансовыми данными, на которые у нас уже есть приманки, благодаря чему мы умеем их обнаруживать.

Расскажите, пожалуйста, подробнее о механизме приманок. Представляется, что это пересечение с системами обмана злоумышленников (deception). Здесь же, получается, эта часть функций «переехала» на уровень песочницы? Делают ли это ваши конкуренты?

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

У нас есть конкурентное преимущество — архитектурная особенность наблюдения из гипервизора, которая не пропускает обращение к приманке.

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

А. В.: Забегу вперёд: всё, что мы ранее создали для Windows, мы сделали и под Linux.

Начну издалека. Все мы знаем о MITRE ATT&CK — классификационной базе тактик и техник атак, актуальных для разных ОС. Когда мы начали работу с Windows, использовали матрицу MITRE в контексте применимости к PT Sandbox — выделили техники, которые наиболее актуальны для песочницы: инъекции в процессы, закрепление, эксфильтрацию данных, повышение привилегий и другие. Самой сложной задачей было установить мониторинг из гипервизора.

А теперь вернёмся к вопросу. Детект событий на базе Linux вполне прост, потому что в этой ОС почти всё можно считать файлом или процессом. Таким образом, все вредоносные действия так или иначе сводятся к манипуляциям с файлами: чтение, замена или удаление информации. Просто нужно знать, где именно происходит действие. Мы разложили эти «места» по полочкам, распределили соответствующие детекты и «приземлили» всё это на матрицу MITRE. Сейчас можем уверенно сказать, что PT Sandbox полностью охватывает релевантные тактики и техники атак на Linux. Кроме этого, мы занимаемся изучением уходов от обнаружения по классифицированным техникам, но таких зловредов для Linux гораздо меньше.

А что можно предложить пользователям macOS?

А. В.: Мы следим за вредоносными программами для этой ОС, понимаем, как в неё попадают загрузчики, как вредоносы обходят встроенную защиту и закрепляются в системе. Кстати, 99 % зловредов под macOS закрепляются через конфигуратор пользовательских и системных демонов.

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

Так, Windows тоже постоянно приходится «реверсить», чтобы понять, где и какие структуры данных расположены. Здесь — тот же самый путь. Прежним остаётся подход — анализ из гипервизора.

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

А. В.: Расскажу о том, как это сделали мы. Наблюдали за событиями в системе и формировали трассу событий, затем проходили по ней с анализатором и обнаруживали вредоносы при помощи «точечных» правил. Далее решили консолидировать информацию из всех источников о событиях, реестрах, именованных каналах, сокетах — вообще обо всём.

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

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

Гигантские объёмы этой информации объединили в целостный алгоритм, выбор которого занял у нас определённое время. Одним из решающих факторов при выборе был аспект производительности, то есть потребление памяти.

В результате масштабного обучения на разном объёме данных у нас получился классный категоризатор, который умеет проследить за одним процессом в трассе и сказать, «хорошая» она или «плохая».

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

Так мы выпустили боевое ML-решение, которое сообщает об обнаружении так же, как наши обычные детекты, не нарушив при этом существующие процессы. То, что блокировалось, продолжает блокироваться, клиент не страдает от шквала ложных срабатываний, а специалист SOC анализирует то же количество событий в сутки, что и прежде.

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

Понятно, что ML нужно обновлять реже, чем, например, сигнатуры для классического детектирования, о котором мы говорили в предыдущей части интервью. Расскажите, как часто требуется обновление обычных сигнатур и ML-модели в таком продукте, как PT Sandbox?

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

Мы по умолчанию обновляем правила трижды в день. Если необходимо выпустить срочное обновление (например, при обнаружении уязвимости в Exchange), то за несколько часов. Если говорить о сигнатурном анализе поведения — в среднем раз в неделю. Если же мы имеем в виду ML-решение и говорим о клиенте, у которого пройден путь стабилизации и знакомства с моделью, обновление потребуется раз в квартал.

Я начал с того, что рассказал о гигантском объёме данных, на котором мы обучали систему, и о том, что при помощи ложных срабатываний, которые возникают из-за нового софта, мы можем её дообучать. Мы получаем новые чистые и вредоносные трассы данных из инфраструктуры Positive Technologies и от команды экспертного центра безопасности PT ESC. Новый контент не влияет на модель, на нём мы её только тестируем, проверяя, соизмеримы ли верные положительные и отрицательные срабатывания от сигнатурных детектов со срабатываниями от ML-модели. 

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

Иначе говоря, эволюция мира вредоносных программ не повлияла на стабильность работы решения. Естественно, через пять лет всё изменится.

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

А. В.: Сохранятся классические подходы, но добавится машинное обучение. Приведу два примера. 

Positive Technologies регулярно проводит The Standoff. В прошлом году на нашей кибербитве мы проверяли ML-решения в деле. Среди прочего атакующими была запущена вредоносная программа, которая перед началом своих действий создала цепочку подпроцессов в количестве 100 штук. Получилась своеобразная «матрёшка». ML-решение заметило это и сработало. Позже мы создали для такого поведения и сигнатурный детект. Именно для этого и нужны ML-алгоритмы: обнаруживать аномалии, о которых мы даже не подумали.

И контрпример. Весной вышла статья о новом способе инъецирования, когда для запуска внедрённого кода применяется другой триггер — не асинхронно вызванная процедура, а инструментальный обратный вызов (instrumentation callback). Для ML-решения это всего лишь одно действие в трассе, вызов из записи в 500 мегабайт событий. Оно не улавливает эту принципиальную мелочь, пока его с этим не познакомишь. Когда мы «говорим» ему об этом, оно понимает и учится, но по умолчанию этот вызов не заметит. Иногда такие специфические техники действительно не будут обнаруживаться с помощью ML. При этом они настолько понятны человеку, что не заметить их невозможно.

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

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

А. В.: Песочницы — давно известный класс решений, который при этом не теряет актуальности. Это объясняется тем, что они способны интегрироваться практически со всеми продуктами. Расскажу, как это происходит в экосистеме Positive Technologies.

Например, возьмём взаимодействие PT Sandbox с решением класса NTA — анализатором сетевого трафика PT Network Attack Discovery (PT NAD). Когда атакующие хотят проникнуть внутрь периметра путём фишинга, они используют почту, и в этом случае все знают, что для защиты требуется песочница. Если же злоумышленники уже попали внутрь и совершают перемещения, например, с помощью утилиты Mimikatz, PT NAD видит файлы внутри трафика, извлекает и передаёт в PT Sandbox, которая проверяет их и подтверждает, что это та самая утилита. Неважно, была использована утилита или нет: если в трафике есть передаваемые объекты, песочница проанализирует и опознает их.

История с решениями класса WAF — это уже больше про бизнес. Если говорить, например, о порталах, куда люди отправляют свои документы, интеграция PT Sandbox с PT Application Firewall позволяет проверять их оперативно. Встаём на потоке, принимаем данные на прокси-сервере, затем в зависимости от построения процессов перенаправляем их в песочницу. Если хотим работать синхронно, то данные отправляются в статике, если асинхронно — в динамике. Возможность анализа таких файлов появляется из самого бизнес-процесса, что не создаёт никаких проблем. Протокол ICAP для взаимодействия с песочницей существует и поддерживается, это стандарт.

PT ICS — это комплексная платформа Positive Technologies для выявления киберугроз и реагирования на инциденты в промышленных системах. Решение объединяет в себе несколько продуктов, и PT Sandbox является его компонентом. Чтобы защитить индустриальную сеть, нужно противодействовать вредоносным программам, которые нацелены именно на неё. К ним относятся, например, Stuxnet и Industroyer. Все вредоносные программы, «заточенные» под атаки на контроллеры, нужно ловить в PT Sandbox. Песочница использует специфические приманки для SCADA; кроме того, в неё заложены все принципы отлова зловредов.

Что же касается EDR (XDR), за счёт PT Sandbox возможен эффективный и тщательный анализ на конечных точках, поскольку вынесение нагрузки и проверки позволяет регулировать производительность. Как выстроен сам процесс? Что-то удаётся проанализировать в динамике на конечной точке, и это делает MaxPatrol EDR, а что-то приходится анализировать дополнительно, например в песочнице. После этого необходимо распространить результат анализа на все агенты и везде отреагировать, пока зловреды не «убежали» слишком далеко. Это происходит в рамках экосистемного решения PT XDR. MaxPatrol EDR и PT XDR тесно связаны между собой, и такие сложные сценарии в решении уже учтены.

Сюда также, наверное, можно отнести все средства защиты почтового трафика.

А. В.: С этого всё начиналось, и это продолжает оставаться актуальным. Так работают, например, Microsoft Exchange и другие MTA, управляющие маршрутизацией почты: позволяем почте «застрять» ненадолго, но не принести зловред, и не так уж страшно, если письмо будет доставлено через пять минут.

Кроме того, существует ещё и API — если специфика требует интеграции или если есть SOAR, который не предусмотрен в линейке Positive Technologies, но стоит у клиентов. Если есть API и возможность написать интеграционный модуль, то можно установить сопряжение с чем угодно.

Алексей, спасибо за глубокий экскурс в работу песочницы. Было интересно узнать, что заложено внутри PT Sandbox. Часто мы не задумываемся над тем, как работает система. На самом деле, в ней очень много интересных технологий и техник.

Нашим читателям, как всегда, желаем всего самого безопасного!

Реклама. Рекламодатель АО «Позитив Текнолоджиз», ИНН 7718668887, ОГРН 1077761087117