PT NGFW: как мы упаковали девять лет экспертизы в новый продукт

На Positive Hack Days 12 Денис Кораблев поднял важную тему. Несмотря на то, что в России есть вендоры, которые называют себя производителями Next-Generation Firewall, регуляторы чувствуют: проблема не решена. К сожалению, на рынке отсутствуют решения, которые могут закрыть все текущие потребности заказчиков — хороший NGFW и правда сложно «собрать». При этом от надежности решения зависит функционирование всей компании, поскольку оно контролирует весь корпоративный трафик. Осенью этого года Positive Technologies презентует рынку коммерческую версию своего NGFW, а сегодня я расскажу, как нам удалось так быстро наполнить его экспертизой. Начнем с истоков: 2015 г., PT NAD...

Первые шаги: PT NAD и Suricata

PT Network Attack Discovery (PT NAD) — это система поведенческого анализа сетевого трафика. В ее задачи входит обнаружение зараженных узлов, инсайдеров и нарушений политик безопасности. Разработка PT NAD началась в 2015 г., когда термина NTA (Network Traffic Analysis) в принципе не существовало. Продукт должен был выявлять вредоносную активность в трафике и помогать аналитикам расследовать инциденты в сети.

Для старта мы выбрали систему Suricata как наиболее подходящую нам технологически. Она также фактически была стандартом синтаксиса сигнатур обнаружения, и вокруг нее собралось большое комьюнити аналитиков, поэтому мы не стали грести против течения. Но с самого начала мы поняли, что в ней есть проблемы с производительностью и не хватает нужных функций. Поэтому одновременно наше R&D начало активно улучшать ее, дорабатывать и переписывать, сохраняя только одно — обратную совместимость самих сигнатур. А в последнее время мы переделали и то, ради чего изначально была выбрана Suricata, — движок сигнатур. Причем переделали его дважды. Фактически у нас сейчас есть две версии: одна используется в PT NAD (продукт может потреблять больше ресурсов, но глубже анализирует трафик), а другая — в PT NGFW (он должен быть максимально производительным и делать упор на блокировку). Параллельно с R&D мы начали развивать собственную экспертизу: изначально акцент был на атаках, но в дальнейшем, с ростом команды, мы начали покрывать активность вредоносного ПО.

Кроме того, мы стали контрибьютить в сообщество, чтобы получить фидбек и впитать мировой опыт. Возможностей синтаксиса сигнатур, применяемых в Suricata, было достаточно для детектирования вредоносного трафика на основе последовательностей длин сообщений в канале связи с управляющим сервером. На конференции SuriCon 2018 мы презентовали концепт построения сигнатур, способных с высокой точностью детектировать ВПО, скрытое под TLS или под кастомным протоколом шифрования. Одновременно с концептом мы представили его реализацию и получили поддержку других разработчиков.

Что мы знаем: активность вредоносного ПО и атаки

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

Под активностью вредоносного ПО мы подразумеваем сетевые соединения, возникшие, когда машина была заражена — неважно, майнером или трояном. Для детектирования такой активности нам нужно непрерывно отслеживать появление нового вредоносного ПО и придумывать, как его детектировать в сетевом трафике. Для этого у нас есть большой выстроенный процесс. 

Как это работает? Наша команда Threat Intelligence (TI) создала собственный «VirusTotal». Куча роботов автоматически собирают подозрительные файлы из различных источников в сети. Часть файлов в этот же пайплайн вручную добавляют наши коллеги из TI по результатам их исследований активности группировок злоумышленников. Каждый файл на потоке пропускается через несколько подсистем статического и динамического анализа; его метаинформация обогащается за счет накопленных данных из TI-систем коллег. 

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

Атаки

Вторую составляющую накопленной сетевой экспертизы мы называем «атаки». Сюда попадает все, что злоумышленники используют вручную: эксплуатация уязвимостей, активность утилит для тестирования на проникновение, различные техники атакующих, артефакты атак и пр. 

Как и с активностью вредоносного ПО, у нас есть несколько процессов, которые наполняют наш бэклог разработки экспертизы.

Первое — это трендовые уязвимости. Эксперты нашей компании оценивают каждую уязвимость и выносят вердикт — станет она трендом (возьмут ли ее на вооружение злоумышленники), или нет. Трендовые уязвимости с сетевым вектором эксплуатации сразу попадают в наш бэклог с высоким приоритетом. Если есть публичный эксплойт, задача аналитика — воспроизвести эксплуатацию уязвимости в лабораторных условиях и разобраться в ее работе. Это нужно для того, чтобы охватить как можно больше вариантов эксплуатации, так как изначальный эксплойт может быть узконаправленным. В случае, когда нет публичного POC (proof of concept), мы пытаемся сами сделать эксплойт. Это трудоемкий процесс, к которому мы прибегаем в особых случаях. Например, когда известно, что уязвимость эксплуатируют в дикой природе. В прошлом году мы вынесли эту функцию в отдельную команду, обладающую нужными скилами для такого детального разбора.

Следующий наш источник — информация о 0-day-уязвимостях, которые находит наша red team в своих проектах. Здесь нам особенно важно выпустить детектирующие сигнатуры, так как не каждый производитель ПО может оперативно закрыть уязвимость. Кроме 0-day, у нас есть совместные проекты и коммуникация для обмена опытом с командой наших спецов по анализу защищенности. Наша команда Incident Response также не остается в стороне и приносит нам новый инструментарий и техники атакующих с расследований инцидентов у клиентов. Все это позволяет нам отслеживать тренды в подходах злоумышленников.

Как и в случае с вредоносным ПО, не обошлось без автоматизации. Для отслеживания новых угроз у нас есть внутренний робот-агрегатор, который мы называем VulnMiner. Он собирает информацию с массы различных источников (каналы в Telegram, GitHub, форумы, посвященные эксплойтам, и т. д.) и отправляет нам на оценку и приоритизацию. После этого найденные инструменты отправляются в наш нескончаемый бэклог по разработке сигнатур.

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

Тестирование

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

После этого сигнатуры переходят к стадии динамического тестирования. В качестве подопытного кролика выступает наш SOC. Мы обкатываем на наших сенсорах новые сигнатуры, прежде чем рассылать их в продукты, установленные у клиентов, в том числе добавлять в NGFW. С одной стороны, коллеги из SOC быстрее рынка реагируют на угрозы. С другой, мы проверяем наши сигнатуры в реальном времени и в случае необходимости корректируем их, чтобы не навредить клиентам. Дальше «тестирование» проходит уже в бою. В ходе оказания услуг мы имеем доступ к СЗИ ряда наших клиентов и можем увидеть, что какая-то сигнатура работает некорректно. Ведь сетевой трафик очень разнообразный, и невозможно предвидеть все кейсы.

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

Экспертиза в PT NGFW

Если сильно упростить, мы взяли описанную выше экспертизу и перенесли ее в новый продукт — PT NGFW. Но на самом деле все, конечно, гораздо сложнее...

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

Следующая задача, которая стояла перед нами, — сформировать набор сигнатур, релевантный именно для NGFW. В случае с NTA решениями мы обладаем большим количеством контекста, который помогает аналитику в расследовании по данным сетевого трафика. Это значит, что для NTA также будут полезны сигнатуры, обнаруживающие различные артефакты, которые могут говорить о вредоносной активности, но в то же время могут быть легитимными для конкретной инфраструктуры. Но такие сигнатуры будут бесполезны для NGFW, так как без расширенного контекста не позволят установить факт атаки. А при переключении их в блокировку пользователем, который в них не разобрался, — еще и навредить легитимным соединениям. Кстати о блокировках: IPS в NGFW в первую очередь нацелена на предотвращение. Некачественная сигнатура, дающая большое количество false positive срабатываний, может навредить легитимным соединениям. Все это заставляет аналитиков более ответственно относиться к формированию сигнатур, которые поставляются в продукт. Это также заставило пересмотреть наши процессы тестирования экспертизы и запланировать улучшения.

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

С процессами, связанными с анализом вредоносного ПО, оказалось несколько проще. Адаптация под расшифрованный трафик уже была выполнена ранее, поскольку эта экспертиза используется внутри еще одного нашего продукта — PT Sandbox, который также «снимает» TLS при анализе.

Коротко о планах

В этом году мы планируем внедрить наш PT NGFW в игровую инфраструктуру полигона Standoff. Также мы уже начали переводить некоторые сегменты сети Positive Technologies на использование собственного решения.

Сейчас мы тестируем раннюю версию PT NGFW на клиентах, которых называем early birds. Это дружественные компании, которым достаточно уже имеющейся в решении функциональности. «Пилоты» проходят успешно и помогают понять, в какую сторону нужно улучшать продукт и его экспертизу. На текущей ранней версии PT NGFW мы уже получили скорость 60 Гбит/с на нагрузочном тестировании в режиме IPS с включенным по умолчанию контролем приложений и с 10 000 сигнатур.