“”/
 
21 февраля 2024

KATA
Защита периметра. Теория

Цикл "Kaspersky Symphony XDR"
Введение
Приветствуем вас в нашем цикле статей по Symphony XDR!

Но прежде, чем мы погрузимся в развертывание и настройку решения KATA — добавим немного контекста для понимания продукта и того, какие задачи он решает и как вписывается в понятие XDR.

Давайте начнём с разъяснения понятий KATA и KEDR, и ответа на вопрос: почему KATA включает в себя KEDR, но внедрив KATA нельзя считать, что у вас есть и KEDR.

KATA Platform — это решение класса XDR которое представляет собой техническую базу для технологий NDR, EDR и Sandbox. Для простоты: NDR функционал платформы будем называть просто KATA, а EDR — KEDR. Приобретя и используя решение KATA, мы получаем возможность искать подозрительные элементы и активность только в сетевом и почтовом трафике на периметре сети.

Но на базе самой платформы можно активировать и функциональность решения класса EDR — Kaspersky EDR Expert и в итоге получить XDR. И наоборот, можно используя платформу KATA, активировать функциональность только Kaspersky EDR Expert и пользоваться только защитой от сложных угроз на конечных точках.

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

Давайте рассмотрим как это решение помогает решать конкретные задачи и как интеграция продуктов Symphony XDR помогает автоматизировать рутинные процессы по обнаружению и реагированию. Данная статья будет являться первой частью рассказа про платформу KATA и затронет NDR и Sandbox функционал. Функционал Kaspersky EDR Expert мы будем изучать в рамках следующих статей.
Ландшафт угроз
Обсудим ландшафты угроз и то, как мир пришел к XDR.

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

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

Условно можно разделить угрозы на массовые и целенаправленные (или сложные). Сложные угрозы также именуются как APT или Advanced Persistent Threat.

От первого типа угроз защищают решения класса EPP (Endpoint Protection Platform). Они очень серьезно развились на данный момент. И из продуктовой линейки Лаборатории Касперского, решением этого класса является, например, широко известный Kaspersky Endpoint Security. Задачей решения класса EPP является заблокировать любую угрозу, будь то исполнение файла, открытие веб-страницы или лежащий на диске текстовый документ с макросом, которую на 100% можно считать вредоносной. Решения данного класса нацелены на блокирование массовых и известных угроз.

От сложных угроз, от которых не может защитить EPP, защищают решения класса EDR. Решения данного класса нацелены на выявление потенциальной вредоносной активности, которая не может быть определена на 100% как вредоносная. Например: при целенаправленной атаке, злоумышленник может специально написать вредоносный скрипт, которого не будет в антивирусных базах сигнатур и таким образом обойти защиту EPP. Также всё чаще злоумышленники используют легитимные инструменты операционных систем.

В обоих рассматриваемых случаях мало иметь защиту только на уровне конечных точек.

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

В свою очередь APT атаки могут быть растянуты во времени и каждый этап может занимать недели, а то и месяцы. Поэтому очень важно анализировать не только текущие данные, но и проводить ретроспективный анализ. Для выявления APT нужны уже более сложные инструменты, например, такие как NDR/NTA, SIEM, сканеры уязвимостей и песочницы.

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

Для того, чтобы выявлять такие атаки и пресекать их на ранних этапах нужно иметь качественные инструменты и уметь ими пользоваться. В линейке Symphony XDR возможностью патч-менеджмента обладает Kaspersky Endpoint Security, а серьезная защита от почтового фишинга может быть достигнута благодаря связке решений по защите почты KSMG/KLMS и KATA.

Подробнее посмотреть, как настраивается и работает интеграция KSMG и KATA можно на нашем портале.

Если говорить о том для кого решения XDR будут полезны: существует расхожее заблуждение, что они нужны только крупным компаниям. Но в данный момент можно с уверенностью сказать, что это не так. Согласно статистике, всё чаще в попытке получить доступ к инфраструктуре крупной компании производится атака на её менее крупного и менее защищенного партнера или поставщика. Такие атаки называются атаками на цепь поставок (supply chain).

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

Далее перейдем к архитектуре платформы KATA.
Описание платформы KATA
Платформа KATA получает траффик с помощью сенсоров, обрабатывает и в случае обнаружения вредоносных объектов отображает это в веб интерфейсе для ознакомления администратору. Платформа внедряется в инфраструктуру не интрузивно, то есть существующие потоки данных не изменяются, только настраивается отправка копии данных.

Технологии, которыми KATA анализирует трафик это песочница KATA Sandbox, IDS, антивирусная проверка, проверка репутации через облачную службу Kaspersky Security Network и YARA правила.

А теперь давайте разберемся в архитектуре решения.
Роли серверов в платформе
В платформе KATA существуют 3 роли сервера: сенсор (Sensor), центральный узел (Central Node) и песочница (Sandbox).
Сенсор выступает в качестве получателя трафика: это может быть сырой SPAN трафик, почтовый трафик и веб-трафик переданный по ICAP. Задача сенсора из различных протоколов извлечь потенциально опасные ссылки или файлы, а также системой обнаружения вторжений (IDS) просканировать трафик на предмет аномальной сетевой активности.

IDS позволяет распознать и обнаружить сетевую активность по 80 протоколам, в частности по 53 протоколам прикладного уровня модели TCP/IP, фиксируя подозрительный трафик и сетевые атаки.

Извлеченные ссылки сенсор проверяет через механизм URL Reputation, который задействует Kaspersky Security Network (KSN) для получения актуальной информации. Через KSN также проверяются и извлеченные файлы.

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

Центральный узел осуществляет, помимо упомянутых IDS и URL Reputation, антивирусную проверку, проверку YARA правилами, Cert Check, проверку IOC и проверяет репутацию файлов через KSN. Также центральный узел принимает решения какие элементы как проверять. В случае если проверки стандартными средствами будет недостаточно, то центральный узел может отправить ссылку или файл на проверку в KATA Sandbox.

В случае с функционалом KEDR Центральный узел дополнительно использует Targeted Attack Analyzer, который обнаруживает индикаторы атак (IOA) в событиях телеметрии.

По итогам проверки в веб интерфейсе центрального узла показывается подробная информация о вредоносной активности и/или объектах которые были обнаружены.

Песочница KATA Sandbox эмулирует поведение пользователя в специально подготовленной изолированной виртуальной машине с операционной системой для безопасной проверки объекта. Если передается ссылка, то эмулируется открытие браузера и копирование ссылки в адресную строку и переход по ней, проверяются все объекты на открывшейся странице. Если это файл, то он открывается ассоциированным программным обеспечением, например, exe файл будет запускаться как исполняемый, а docx будет открыт в программе Microsoft Word.

При этом проверяется, какие действия в системе производит данный объект: записи в реестре, изменение файлов, открытие сетевых соединений и прочее. В каких операционных системах в виртуальных машинах будут проверяться объекты выбирает администратор исходя из реальной инфраструктуры, по умолчанию, предлагаются преднастроенные образы ОС Windows 7 и 10, а также Astra Linux 1.7 и CentOS 7. Помимо этого можно создать собственный образ виртуальной машины на ОС Windows, например, если у вас есть специфичное ПО и вы хотите проверять файлы предназначенные для использования в нем.

В виртуальных машинах эмулируются движения мышкой и нажатия кнопок, как если бы это делал реальный человек. Так как злоумышленники давно знают о песочницах и пытаются её обойти, предусмотрено множество механизмов для скрытия того, что файл открывается в виртуальной среде. На основании всех факторов Sandbox выносит вердикт и сообщает Центральному узлу.
Варианты развертывания
В платформе KATA при использовании функциональности NDR все 3 роли являются обязательными к развертыванию. Минимальное количество серверов на которых может быть развернута платформа это 2 — Сенсор/Центральный узел и Sandbox. Сервер с ролью Центрального узла всегда совмещается с ролью Сенсора (с оговоркой, что роль Сенсора может не использоваться и не потреблять ресурсов). Сервер с ролью Sandbox не может быть совмещен ни с какой другой.

Нельзя развернуть Центральный узел без сенсора, но Сенсор развернуть отдельно можно. Это необходимо в случае, когда требуется анализировать большое количество сырого трафика, более 1Гб/с. Также это полезно, когда требуется анализировать трафик из удаленных филиалов, таким образом основную обработку сырого трафика можно производить «на месте», а пересылать на Центральный узел, который располагается в основном дата-центре, только извлеченные объекты. При этом нагрузка на сеть между Сенсором и Центральным узлом сокращается вплоть до 20% от исходного. Например, при анализе сенсором 1Гб/с SPAN-трафика на Центральный узел будет передаваться не более 200 мбит/с.

С точки зрения масштабируемости: здесь поддерживается и вертикальная, и горизонтальная. Вы можете как увеличивать мощность серверов, так и их количество. В случае с серверами Sandbox рекомендуется добавлять новые сервера аналогичные текущим по характеристикам для равномерного распределения нагрузки.
Развертывание в виртуальной среде
Сервера платформы KATA могут быть развернуты на платформе виртуализации, но с рядом ограничений:
  • Для всех ролей поддерживаются гипервизоры VMware ESXi 6.7, 7.0. При этом сервер Sandbox гарантированно не работает на гипервизоре отличном от VMware ESXi. Для небольших защищаемых инфраструктур поддерживается KVM-виртуализация, но только для роли Central Node совмещенной с Sensor. При этом не поддерживается кластерная реализация.
  • Для роли Sandbox можно использовать только серверы с процессорами Intel.
  • Для роли Sandbox на гипервизоре должна быть включена вложенная виртуализация и зарезервированы ресурсы CPU и RAM.
  • Сервер Sandbox в виртуальной среде не поддерживает более 12 виртуальных машин. С учетом этого фактора, а также накладных расходов, связанных с виртуализацией вам может потребоваться в 3−4 раза больше виртуальных серверов, чтобы получить производительность аналогичную физическому серверу.
В версии KATA 6.0 добавилась возможность развертывания функционала KATA на облачной платформе VK Cloud.
Кластер
Поговорим немного и о кластерном варианте, который также имеется, начиная с версии платформы 5.0 и обеспечивает отказоустойчивость. Кластер состоит из двух ролей — серверов хранения и обрабатывающих серверов.
Отказоустойчивость достигается за счет дублирования данных между серверами хранения и избыточностью вычислительных ресурсов. При выходе из строя одного из серверов, его функции выполняет другой с аналогичной ролью.

Существует и несколько моментов о которых требуется упомянуть:
  • Кластер Центрального узла должен включать минимум 4 сервера — 2 хранения и 2 обработки. Количество серверов может быть увеличено для обеспечения большей производительности или большей надежности.
  • В случае если обрабатывающий сервер используется как Сенсор и получает зеркалированный SPAN трафик, то при выходе из строя этого обрабатывающего сервера, SPAN трафик перестает обрабатываться.
Шлюз в качестве сенсора
Как упоминалось выше — платформа KATA внедряется в инфраструктуру не «в разрыв» и поэтому не поддерживает автоматизированное блокирование вредоносных объектов в реальном времени. Администратору после обнаружения угрозы платформой необходимо вручную использовать инструменты реагирования. Это не всегда удобно, создает много ручной работы, а что важнее повышает время реагирования.

Благодаря экосистемному подходу Лаборатории Касперского существует возможность интегрировать продукты между собой и расширять возможности по защите. Один из примеров такой интеграции — это использование решений Kaspersky Secure Mail Gateway (KSMG), Kaspersky Security for Linux Mail Server (KLMS) и Kaspersky Web Traffic Security (KWTS) в качестве сенсоров для платформы KATA. Преимущество такой интеграции в получении инструмента автоматизированного реагирования на сложные угрозы.

Kaspersky Secure Mail Gateway это шлюзовое решение, оно позволяет очищать почту от спама, фишинга, вирусного ПО и др. Преимуществом такого подхода является возможность получать в конечную почтовую систему уже очищенный трафик. Пользователь при этом даже не получит вредоносное письмо в почтовый ящик.

У нас на портале есть статья с обзором и настройкой решения KSMG, вы можете ознакомиться с ней по ссылке.

Kaspersky Web Traffic Security тоже шлюзовое решение, которое работает как веб прокси сервер и позволяет получить помимо потокового антивируса для пользователей, также инструмент веб-контроля и мониторинга. Администратор может задавать на какие ресурсы или категории ресурсов пользователи не могут заходить, а также может отслеживать действия пользователей в интернете. Дополнительным преимуществом решения является возможность интеграции KWTS по протоколу ICAP с решениями класса NGFW.

Вы можете посмотреть на пример такой интеграции с отечественными NGFW решениями — Континент и UserGate по ссылке.

Схематично использование платформы KATA со шлюзами KSMG и KWTS представлено на изображении ниже.
Интеграция платформы KATA с этими решениями позволяет блокировать вредоносные объекты не только используя стандартные встроенные механизмы решений по защите почты и веб-трафика, но и на основании мощного анализа платформы KATA включающей песочницу. Решения KSMG, KLMS и KWTS в случае необходимости дополнительного анализа, отправляют объекты в платформу KATA и ожидают вердикта, в случае если объект является вредоносным, то письмо может удаляться, а скачивание файла через KWTS обрываться в реальном времени. Таким образом можно значительно снизить время, за которое угроза будет устранена.

В KATA 6.0 появилась возможность не только обнаружения по протоколу ICAP, но и блокировки. Можно использовать песочницу в автоматически блокирующем режиме напрямую с NGWF или веб-прокси решениями. Поддерживается два режима работы: стандартный, с использованием только статических методов проверки и расширенный, в котором клиент будет ожидать вердикта песочницы. В будущих статьях мы посмотрим, как настроить эту интеграцию.

Дополнительно можно отметить, что совместное использование KATA и KEDR дает возможность автоматического запрета запуска файлов через агентов на конечных точках. Это помогает в ситуации когда файл уже передавался через почту или веб трафик и был признан вредоносным песочницей KATA, но пользователь каким то образом всё равно смог загрузить его на рабочую станцию. Таким образом максимально повышается эффективность защиты.
Заключение
Первая статья про платформу KATA подошла к концу: в ней мы разобрали, что из себя представляет эта платформа и как она помогает решать задачи по защите от сложных APT угроз.

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

Для большего погружения в тему вы можете посмотреть наш вебинар по решениям KATA/KEDR.