Трудности при тестировании «песочниц»: тяжело в учении, легко в бою

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

Первый этап – подготовительные работы

Данный этап является ключевым, от качества его проработки зависит дальнейший успех всего проекта. Он занимает как минимум треть времени пилотного внедрения «песочницы», ведь выбор решения зависит и от цели внедрения, и от архитектуры сети, и от покрытия каналов распространения угроз (web, почта, конечные точки).

Например, если цель – доказать актуальность использования «песочницы» для вашей инфраструктуры, для этого можно использовать облачные решения (подписки к уже существующим шлюзам от Check Point Software Technologies, Fortinet, Palo Alto Networks и др.). Как показала наша практика, при наличии актуальных подписок такая связка показывает достойный результат.

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

Рис. 2. Типовая архитектура решения класса "песочница"

С виду все достаточно просто. Векторы защиты известны: web, почта, конечные точки. Есть отдельная система управления и анализа. Но, как обычно бывает, существуют и нюансы, например, выбор количества компонентов: есть «песочницы» с единым устройством для анализа почтового и web-трафика, есть с отдельными.

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

Рассмотрим типовые варианты внедрения, которые чаще всего используют заказчики.

Способы подключения системы защиты от APT для web-трафика

Существует несколько вариантов подключения «песочниц» для работы с web-трафиком. Но прежде чем перейти к ним, необходимо рассмотреть вопрос вскрытия SSL.

Анализ web-трафика в режиме мониторинга (зеркалирование – TAP/SPAN)

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

Рис. 3. Пример внедрения: анализ копии трафика

Приведу пример из нашей практики: у одного из заказчиков был внедрен BlueCoat Proxy SG, т.е. существовала потенциальная возможность интеграции с «песочницей» по ICAP. Но в этом случае на анализ отправлялись бы только файлы, что с точки зрения анализа самого потока данных малоэффективно. Поэтому мы приняли решение поставить устройство для анализа и расшифровки SSL отдельно. В данном случае интеграция с «песочницей» проходила по SPAN-порту.

Анализ web-трафика в режиме блокировки (Inline, «в разрыв»)

Второй вариант анализа приведен на рис. 4, его поддерживают лишь несколько вендоров. Тут тоже есть один нюанс. Если в сети заказчика для доступа в Интернет используется прокси, «песочницу» необходимо подключать «в разрыв» между прокси-сервером и рабочими станциями. В противном случае в отчетах будет отображаться только внешний IP-адрес прокси-сервера.

Рис.4. Пример внедрения: возможность блокировки трафика

Актуально!

Несмотря на то, что объемы зашифрованного интернет-трафика постоянно увеличиваются, до сих пор многие не инспектируют SSL. А ведь при отсутствии такого анализа некоторые угрозы могут остаться незамеченными. По этой причине, кроме самих компонентов «песочниц», мы довольно часто прорабатываем и внедрение решений для расшифровки SSL (A10, F5 и др.).

Об этом читайте подробнее в Jet Info №9 2016.

«Песочницы» остальных вендоров работают через связку с другими продуктами. Например, отправкой команды TCP RST для сброса сессии сторонними решениями, включая Palo Alto Networks, Blue Coat, Check Point Software Technologies и т.д.

Способы подключения системы защиты от APT для почтового трафика

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

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

Существует несколько способов работы «песочниц» с точки зрения направления на них почтового трафика:

• анализ копии писем – режим BCC;
• режим блокировки – режим MTA;
• режим SPAN (зеркалирование почтового трафика).

Анализ копии писем – режим BCC (blind carbon copy)

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

Рис. 5. Анализ копий писем в "песочнице"

Режим блокировки – режим MTA (Mail Transfer Agent)

Данный режим позволяет подключать оборудование «в разрыв» после существующего MTA/Anti-spam перед внешними корпоративными почтовыми серверами (рис. 6). На время статического и динамического анализа входящие электронные сообщения задерживаются. После проверки они либо пересылаются получателям, либо отправляются в карантин с автоматическим оповещением администратора и пользователей. В зависимости от вендора время задержки может варьироваться от 2 до 10 минут.

Рис. 6. Вариант блокровки писем

На одном из пилотов у нас был интересный случай, связанный с вариантом внедрения «песочницы» для анализа email-трафика. Отдел информационной безопасности планировал установить компонент «в разрыв» для тестирования боевого варианта. Служба ИТ предложила использовать на старте вариант анализа копии писем и сначала набрать статистику, а потом, если решение себя хорошо зарекомендует, включить режим блокировки. ИТ-специалистам не хотелось «что-то ломать». В итоге выбор решения и варианта интеграции растянулся на целых 2 недели.

Режим SPAN (зеркалирование почтового трафика)

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

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

С учетом вышесказанного обсуждение внедрения решения и подготовительные работы могут занимать до 2–3 недель, а довольно часто и более. Этот момент следует учитывать при заказе оборудования. Почему? В большинстве своем продукты класса «песочницы» представлены аппаратными устройствами, а на них существует очередь, которая может быть расписана на несколько месяцев вперед. В таких условиях срок, на который выдается оборудование, жестко ограничен. И здесь важно, чтобы на момент получения комплекта оборудования схема интеграции и тестирования уже была согласована. В противном случае на само тестирование останутся считанные дни.

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

Второй этап – монтаж и настройка оборудования

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

Третий этап – сбор статистики и анализ результатов

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

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

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

Для компонента защиты почты можно использовать дополнительное устройство. Но это не классическая реализация функции отказоустойчивости посредством кластеризации комплексов в связку Active/Standby. В данном случае настраиваются приоритеты MX-записей.

Для web-трафика тоже существуют нюансы. Например, у одного из заказчиков для отказоустойчивости мы установили два аппаратных балансировщика с функцией раскрытия SSL-трафика. У другого компонент «песочницы» был установлен «в разрыв», т.е. представлял собой возможную единую точку отказа. В этом случае для обеспечения доступности сервисов использовали встроенный bypass (кстати, возможен вариант и с внешним bypass).

Еще один вариант отказоустойчивости – использование резервного канала. В случае недоступности основного канала трафик отправлялся в обход. Удалось обеспечить отказоустойчивость на приемлемом уровне, что и было применено на одном из проектов.

На одном из пилотов заказчик тестировал «песочницу» следующим образом: отправлял на анализ свою «коллекцию» ВПО и в режиме реального времени наблюдал за их анализом в «песочнице». Результат был отличный.

Правильное планирование – залог успеха

Не стоит забывать об организационной составляющей любого проекта. Согласование сетевой схемы, выделение портов и IP-адресов, выделение тестовых пользователей и т.д. довольно часто затягивается, поэтому мы всегда рекомендуем закладывать на 10–15% времени больше на эти непредвиденные обстоятельства.

Все вышесказанное можно свести к таблице 1.

Таблица 1. Занятость в проекте

Из таблицы следует, что первый этап является ключевым с точки зрения как продолжительности, так и трудозатрат и со стороны интегратора/вендора, и со стороны заказчика. Чем качественнее будет проработан первый этап, тем лучше и результативнее пройдет сам пилот. И это доказано на практике.

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

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

Приложение 1.

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