Обогащение

• LDAP-обогащение
• GeoIP-обогащение (Геоданными)
• Интеграция CyberTrace с KUMA
• DNS-обогащение
• Обогащение событий информацией об Активах
• Обогащение произвольного поля с утилитой Tracer

LDAP-обогащение

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/217926.htm 

Настройка параметров подключения к LDAP-серверу

Зайдите в веб-интерфейс KUMA с учетной записью Главного администратора или администратора тенанта, для которого необходимо настроить подключение к LDAP-серверу для последующего обогащения событий информацией об учетных записях.

Перейдите на вкладку Параметры – LDAP-сервер и нажмите на кнопку Добавить параметры для нового тенанта.

В открывшемся окне выберите Тенант, укажите Интервал обновления в часах и задайте Время хранения данных. Затем нажмите на кнопку Добавить подключение.

В открывшейся вкладке задайте параметры подключения к LDAP-серверу:

1. Укажите Название подключения
2. В поле Секрет добавьте учетную запись пользователя для подключения к серверу Active Directory. Имя пользователя может быть указано в одном из двух форматов: <user>@<domain> или <domain>\<user>
3. В поле URL укажите адрес одного или нескольких серверов LDAP (через запятую) в формате <hostname или IP-адрес сервера>:<порт>. Для незащищенного и startTLS подключения порт по умолчанию 389, для ssl – 636. В случае использования startTLS или ssl необходимо указывать hostname сервера, если сертификат сервера в поле SAN не содержит IP-адреса сервера.
4. Выберите Тип подключения.
5. Если на прошлом шаге был выбран тип ssl или startTLS, добавьте сертификат для проверки подлинности сервера в поле Сертификат. В случае, если для DC используется не самоподписанный сертификат, необходимо импортировать сертификат корневого центра сертификации.
6. Важно! Сертификат самого DC должен содержать параметр DNS Name в поле SAN, соответствующий доменному имени данного сервера (если в URL был указан hostname сервера) или параметр IP Address в поле SAN, соответствующий IP-адресу данного сервера (если в URL был указан IP-адрес сервера).
7. Задайте Время ожидания в секундах – период, в течение которого KUMA будет ожидать ответа от сервера контроллера домена.
8. В поле База поиска (Base DN) укажите базовое отличительное имя каталога, в котором должен выполняться поисковой запрос.
9. При необходимости укажите Пользовательские атрибуты учетных записей AD, на основе которых вы хотите обогащать события учетными записями.
10. Убедитесь, что галочка для пункта Выключено снята и нажмите на кнопку Сохранить для сохранения параметров подключения к LDAP-серверу.

Нажмите на кнопку Сохранить. При необходимости нажмите на кнопку Импортировать учетные записи для немедленного импорта информации об учетных записях в KUMA.

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

Настройка LDAP-обогащения

LDAP-обогащение настраивается на уровне коллектора и позволяет наполнить события информацией об учетных записях (атрибутах, импортированных из AD). На основе полученных атрибутов доступно выполнение реагирования AD и KASAP, а также написание правил корреляции по атрибуту memberOf. Остальные атрибуты, импортируемые из AD, служат справочной информацией и используются в расследовании алертов и инцидентов.

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

Нажмите на кнопку Добавить домен и введите полное наименовение домена в верхнем регистре. В случае, если обогащение было настроено для нескольких доменов, повторите процедуру необходимое количество раз.
В случае, если вы не знаете полного наименования домена для импортированных учетных записей, подключитесь к компоненту Core KUMA по ssh и выполните команду:

/opt/kaspersky/kuma/mongodb/bin/mongo kuma --eval 'accounts.findOne({},{_id:0, domain:1});'

Либо:

/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma --quiet --eval "db.accounts.findOne({"archived":false},{"domain":1})"

В результате выполнения команды будет выведен домен:

k0s kubectl get pods --all-namespaces

k0s kubectl exec --stdin --tty core-deployment-8659b48bb6-45grz -n kuma -c mongodb -- /bin/sh -c '/bin/mongo localhost/kuma --quiet --eval "db.accounts.findOne({},{_id:0, domain:1});"'

Если используется несколько доменов, то можно воспользоваться следующим запросом (выведет список всех доменов):

/opt/kaspersky/kuma/mongodb/bin/mongo kuma --eval 'db.accounts.distinct("domain");' 

Настройте Обогащение полей KUMA на основе атрибутов AD. Для этого выберите Применить сопоставление по умолчанию, либо через кнопку Добавить элемент укажите атрибуты и поля KUMA. 

Перейдите на вкладку коллектора Проверка параметров и нажмите на кнопку Сохранить и перезапустить сервисы для применения всех настроек.

На этом настройка обогащения LDAP завершена. В следующем разделе будут рассмотрены известные проблемы и пути их решения.

Известные проблемы

С версии KUMA 2.1.3, LDAP идет после других обогащений. Править нормалайзер (что неудобно) не нужно, а достаточно сделать правило обогащения, которое будет заменять EXAMPLE на EXAMPLE.LOCAL (если много разных доменов - можно сделать обогащение через словарь), чтобы все NetBIOS названия менялись на DNS названия доменов.

В некоторых событиях журналов Windows вместо DNS-имени домена может присутствовать NetBIOS-имя домена, которое не будет совпадать с DNS-именем домена, импортированных в KUMA учетных записей. Например, DEMO вместо DEMO.LAB.

Данная проблема решается доработкой нормализатора Windows.

Для этого откройте на редактирование используемый нормализатор Windows и перейдите в Основной парсинг событий – Обогащение.

Пролистайте раздел до кнопки Добавить обогащение и нажмите ее.

Задайте Тип источника – событие, Исходное поле – SourceNtDomain, Целевое поле – SourceNtDomain и нажмите на значок гаечного ключа рядом с исходным полем.

Нажмите кнопку Добавить преобразование. Выберите Тип преобразования replaceWithRegexp.

В левой части, в графе выражение укажите NetBIOS-имя домена в формате ^<NetBIOS-имя>$. В правой части, в графе чем заменить укажите DNS-имя домена. Нажмите кнопку ОК.

Выполните аналогичные действия для поля DestinationNtDomain.

Сохраните нормализатор и выполните Обновление параметров сервиса для сервиса коллектора Windows.

Проверка работы LDAP-обогащения

Для проверки работы обогащения перейдите на вкладку События и выполните поисковой запрос:

SELECT * FROM `events` WHERE SourceAccountID !='' OR DestinationAccountID!='' ORDER BY Timestamp DESC LIMIT 250

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

В случае если проведенные выше действия не обогащают данные перезагрузите службу коллектора и снова проверьте обогащение

GeoIP-обогащение (Геоданными)

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/3.2/ru-RU/233257.htm 

Скачанная и конвертированная база (IP2Location) - https://box.kaspersky.com/f/b961a874400a4a0ab66b/ 

Конвертация mmdb файла базы в CSV для KUMA - https://github.com/KUMA-Community/mmdb2kuma 

Российская база (требуется регистрация) - https://geoip.noc.gov.ru/ 

Скачивание БД

IP2Location

MAXMIND

Конвертация БД

python converter.py --type ip2location --input IP2LOCATION-LITE-DB11.CSV.ZIP --out geoip_ip2location.csv

Загрузка БД в KUMA

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

Обогащение GeoIP

Формат файла CSV:

Network,Country,Region,City,Latitude,Longitude
10.0.0.0/8,Russia,Moscow,Butovo,,
192.168.0.0/16,Russia,SPB,Zelenograd,,

Интеграция CyberTrace с KUMA

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/217924.htm

Описание CyberTrace: https://support.kaspersky.ru/datafeeds/about/13850?_ga=2.203307089.1316632250.1728285594-385727687.1689681277 

Видеоматериалы CyberTrace: https://rutube.ru/plst/1042259/ 

Ссылка на актуальный дистрибутив CyberTrace : https://support.kaspersky.com/datafeeds/download/15920#block0 

Системные требования для CyberTrace

Минимальные системные требования (обработка ~4K EPS): 8 vCPU; 20 RAM; 200 HDD

• OC – Linux x64 (CentOS 7.x/8.x или RedHat 7.x предпочтительно, но зависит от стандартов и политик организации)
• RAM – как минимум 16 ГБ должно быть свободно для использования только СТ
• HDD – не менее 100ГБ доступных в /opt (без использования Retroscan, для продуктивного сервера потребуется около 1ТБ)
• Network – сетевой интерфейс 1Гбит/с со статическим IP

Подробнее: https://support.kaspersky.com/help/CyberTrace/4.4/ru-RU/270383.htm 

Для загрузки фидов Лаборатории Касперского нужен доступ до  https://wlinfo.kaspersky.com (TCP/443). Важно: НЕ должен подменяться сертификат (SSL inspection) на периметре при доступе к ресурсу. Для загружки других фидов может потребоваться доступ, в зависимости от их размещения.

Установка CyberTrace на Linux

Распаковать загруженный архив: 

tar -C /opt -xvzf CyberTrace-rpm.tar.gz --no-same-owner

Переход в папку установки:

cd /opt/cybertrace

Учетная запись пользователя, выполняющего установку DEB|RPM-пакета, должна иметь права root.

Запуск скрипта установки:

./run.sh install

Установка CyberTrace выполняется в каталог /opt/kaspersky/ktfs.

После установки DEB|RPM пакета скрипт установки автоматически запускает конфигуратор, в котором нужно прочитать и принять лицензионное соглашение (EULA). После этого выполняется запуск сервисов CyberTrace: cybertrace_db и cybertrace.

Вход в веб-интерфейс по адресу https://<IP_or_Hostname>, УЗ по умолчанию admin / CyberTrace!1

Отключите фаервол на ОС или откройте доступ до нужных портов для работы CyberTrace 

Настройка на стороне CyberTrace

Вход в CyberTrace по: https://<IP_or_Hostname>, пароль по умолчанию: admin / CyberTrace!1

При первом входе после установки CyberTrace появится окно мастера первоначальной настройки (Initial Setup Wizard), в котором необходимо:

• Выбрать используемую SIEM-систему: в данном примере это KUMA
• Указать параметры подключения для используемой SIEM-системы: IP-адрес интерфейса сервера CyberTrace. В последнем поле указать IP-адрес интерфейса или Hostname сервера CyberTrace.

• Опционально указать настройки прокси-сервера
• Опционально импортировать файл лицензионного ключа и файл сертификата для возможности загрузки коммерческих потоков данных об угрозах
• Указать потоки данных об угрозах, использование которых планируется в Kaspersky CyberTrace.

Для завершения первоначальной настройки нажать Close.

После завершения первоначальной настройки рекомендуется изменить пароль администратора, используемый по умолчанию.

Проверить успешность загрузки индикаторов компрометации можно следующим способом:

1. Перейдите во вкладку Indicators и убедитесь в наличии индикаторов компрометации
2. Перейдите во вкладку Dashboard -> виджет Supplier statistics и проверьте, что столбец Indicators для каждого фида отличен от 0.

Настройка на стороне KUMA

Начиная с версии 3.2 в KUMA доступно 2 метода интеграции с CyberTrace для потокового обогащения событий данными об индикаторах компрометации:

1. С использованием API CyberTrace
2. С помощью Kaspersky CyberTrace Service

Интеграция с использованием API CyberTrace

Данный метод позволяет отправлять большое количество объектов одним запросом на API-интерфейс CyberTrace. Рекомендуется применять в системах с большим потоком (>50k EPS) событий. Производительность Сybertrace-http значительно превосходит показатели прежнего метода cybertrace, который по-прежнему доступен для обеспечения обратной совместимости.

В веб-интерфейсе CyberTrace создайте новую учетную запись пользователя, которая будет использоваться KUMA для подключения к API CyberTrace. Для этого перейдите в раздел Settings -> Users  и нажмите Add new user. В появившемся окне New user укажите следующие параметры:

• Login - <имя учетной записи пользователя>
• Password - <пароль учетной записи пользователя>
• Confirm password - <пароль учетной записи пользователя>
• Role - Analyst

Нажмите Add.

Далее в веб-интерфейсе KUMA создайте секрет для подключения к API CyberTrace: перейдите в Ресурсы -> Секреты и нажмите Добавить. В появившемся окне укажите следующие параметры:

• Название - <название секрета>
• Тенант - <название тенанта, например, Main>
• Тип - credentials
• Пользователь - <Имя пользователя, созданного на предыдущем шаге>
• Пароль - <Пароль, созданного пользователя на предыдущем шаге>
• Описание (опционально)

Создайте правило обогащения в веб-интерфейсе KUMA: перейдите в Ресурсы -> Правила обогащения и нажмите Добавить. В появившемся окне укажите следующие параметры:

• Название - <название правила обогащения>
• Тенант - <название тенанта, например, Main>
• Исходный тип - cybertrace-http
• URL - <IP-адрес/FQDN сервера CyberTrace>:443
• Секрет - <секрет, созданный на предыдущем шаге>
• Ключевые поля - <поля, значения которых будут передаваться в CyberTrace на анализ. Как пример, укажите поля со скриншота ниже>
• Время ожидания - 0
• Максимальное кол-во событий в очереди обогащения - 1000000
• Описание (опционально)
• Параметры фильтра - <условия срабатывания правила обогащения. В качестве примера, ниже используется набор условий, при котором правило будет срабатывать для событий обращения внутренних IP-адресов к внешним IP-адресам>

Пример готового кода для добавления в правило обогащения:

SourceAddress insubnet [
  '10.0.0.0/8',
  '172.16.0.0/12',
  '192.168.0.0/16'
]
AND NOT DestinationAddress insubnet [
  '10.0.0.0/8',
  '172.16.0.0/12',
  '192.168.0.0/16'
]

Указываем поля DestinationHostName | RequestURL и DestinationNtDomain | DestinationDnsDomain, потому что в событии может быть только одно поле из пары. Если есть оба поля, коннектор CyberTrace в KUMA возьмет только уникальное значение и отправит в CyberTrace на анализ

Если объекты (IP, URL, Domain, Hash) расположены в “кастомных” полях, напр., DeviceCustomString1, то можно создать отдельное правило обогащения, в котором в качестве ключевого поля будет указано необходимое "кастомное" поле/поля

Добавьте созданное правило обогащения в параметрах сервиса коллектора (или коррелятора): перейдите в Ресурсы -> Активные сервисы и нажмите на название сервиса коллектора . В появившемся окне Редактирование коллектора перейдите на шаг Обогащение событий и в секции справа нажмите Добавить обогащение.

В поле Правило обогащения выберите ранее созданное правило обогащения.

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

Интеграция с помощью Kaspersky CyberTrace Service 

Для повышения прозводительности, можно изменять число рабочих процессов коллектора (1 шаг настройки) / самого правила обогащения (для асинхронных задач эффективнее работа)

В KUMA перейдите в раздел Ресурсы - Правила обогащения. Нажмите на кнопку Добавить правило обогащения. В поле URL укажите IP адрес CyberTrace, остальные поля заполните по аналогии со скриншотом ниже. Затем нажмите на кнопку Сохранить.

Для снижения нагрузки на CyberTrace рекомендуется использовать фильтр на правиле обогащении, пример фильтра из пресейл пака: https://box.kaspersky.com/f/39a48398202543dbb9c9/ 

Добавьте созданное правило обогащения на нужные коллеторы или корреляторы. Ниже пример добавления в коррелятор.

После выполнения настроек необходимо сохранить и обновить (можно и перезапустить) параметры ресурса.

Проверка работы интеграции CyberTrace с KUMA

Подразумевается, что настроена интеграция событий с KSC на KUMA, на хосте, где будет проводиться тест установлен KES с последними обновлениями. Иначе используйте другие системы, с которыми осуществлена интеграция по событиям.

В CyberTrace в разделе Индикаторы, скопируйте любой URL из списка содержимых.

С хоста, где установлен KES осуществите переход в браузере по ссылке, например - http://www.kasprsky.com/test/wmuf и получите "отбивку" от KES. Через некоторое время появится событие от KSC. В событии будет обращение по вредоносной ссылке с дополнительным контекстом от CyberTrace, пример ниже:

Сопоставление названия фида и категории https://support.kaspersky.com/help/CyberTrace/5.0/ru-RU/166083.htm 

Количество обнаружений на основе объектов, полученных от KUMA, можно увидеть в дашборде статистики на CyberTrace:

При API интеграции обнариужения и статистика будут отсутствовать

В качестве упрощенного варианта проверки корректной работы обогащения CyberTrace можно отправить тестовое событие в коллектор с помощью утилиты netcat или утилиты kuma. В примере ниже используется тестовое событие в формате CEF, отправленное средствами netcat.

Для коллектора с транспортом TCP:
nc <IP-адрес> <порт> <<< 'CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|request=<любой URL из вкладки Indicators CyberTrace>'

Для коллектора с транспортом UDP:
nc -u <IP-адрес> <порт> <<< 'CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|request=<любой URL из вкладки Indicators CyberTrace>'

Пример обогащенного события на скриншоте ниже

Для создания алертов и отслеживания обращений к IP-адресам/доменам/URL, информация о которых есть в фидах CyberTrace, необходимо привязать к коррелятору следующие правила корреляции из SOC Package:

R201_Обнаружено соединение с подозрительным IP-адресом
R202_Обнаружено обращение на подозрительный Domain
R203_Обнаружено обращение на подозрительный URL

DNS-обогащение

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/217863.htm

Обогащение DNS

А также преобразовывать адреса в доменные имена для следующих полей:

• DestinationAddress -> DestinationHostName
• DeviceAddress -> DeviceHostName
• SourceAddress -> SourceHostName

Важный момент, DNS обогащение работает только для серых сетей

Обогащение происходит если: целевые поля пустые и если резолвится PTR из IP, то будут резолвиться только серые IP

Поле настройки URL - не обязательно. Если оставить пустым, то при обогащении будут использоваться системные настройки сервера. Соответственно, если DNS в ОС серверов коллекторов разные - то и обогащение будет разное

Если событие с адресом 127.0.0.1, то можно перед DNS обогащением в коллекторе в парсинге добавить затирание deviceAddress, если оно равно 127.0.0.1, тогда обогащение DNS должно произойти

Настройка на стороне KUMA

Для повышения прозводительности, можно изменять число рабочих процессов коллектора (1 шаг настройки) / самого правила обогащения (для асинхронных задач эффективнее работа)

В разделе Ресурсы - Правила Обогащения создаем новое правило, ниже пример типового обогащения для DNS:

Далее созданное правило обогащения выше необходимо закрепить в коллекторе в части обогащения.

Обогащение событий информацией об Активах

Активы могут попасть в KUMA следующими способами:

• От KSC (FQDN, IP, MAC, Имя ассета (в KSC, Владелец [Principal name], Информация об уязвимостях, Информация об установленном ПО, Информация о hardware). KUMA импортирует из базы KSC сведения об устройствах с установленным Агентом администрирования KSC, который подключался к KSC, то есть поле Connection time в базе SQL – непустое.
• От KICS
• От Vulnerability Scanner: Из коробки: MP8 Scanner, RedCheck.  Через новые PreSalesPack скрипты: Nessus, OWASP ZAP;
• От CMDB выгрузка в виде CSV, затем скриптом через API добавление в KUMA (скрипт в CommunityPack);
• Вручную

Коллекторы KUMA с периодически получают списки асcетов (активов) от ядра KUMA и хранят их памяти в виде таблиц, позволяющих определить AssetID по IP адресу и/или FQDN.

У ассета может быть указан массив значений IP и/или FQDN. Обогащение проверяет все IP ассета и/или FQDN.

Про склейку информации об активах, подробнее тут: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/243031.htm 

При поступлении события в коллектор, коллектор выполняет:

• нормализацию данных в поля события KUMA;
• если в событии содержится информация о SourceAddress, Destination Address, DeviceAddress, SourceHostName, DestinationHostName, DeviceHostName коллектор выполняет поиск IP - AssetID и/или FQDN - AssetID;
• если информация об ассете найдена, AssetID проставляется в соответствующее поле нормализованного события;
• В общем случае, в нормализованное событие могут быть проставлены 3 типа AssetID: SourceAssetID, DestinationAssetID, DeviceAssetID.
  

После чего события, обогащенные информацией об ассетах направляются в коррелятор и/или хранилище.

Пример обогащенного события (при нажатии открывается карточка актива):

Правила обогащения информацией об активах

Обогащение произвольного поля с утилитой Tracer

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Утилита (скрипт) была написана для получения возможности обогощать событие по значению поля со сторонних систем с использованием языка программирования Python3. Tracer.py мимикрирует под механизм обогащения аналогично CyberTrace, с обогащенными данными можно работать подобно обогащению Threat Intelligence. Утилита может работать как на Linux (рекомендуется), так и Windows платформах (ОС).

Для продвинутых пользователей! Для работы с Tracer.py требуются навыки программирования Python3

Скрипт можно загрузить по ссылке в Пресейл-Паке контенте.

Необходимые библиотеки для работы Tracer.py:

Для использования TCP_FASTOPEN (рекомендуется) на ОС Linux выполните команду ниже:

echo 3 > /proc/sys/net/ipv4/tcp_fastopen

Предварительные правки для Tracer.py:

На стороне KUMA нужно прописать следующее обогащение:

По картинке выше, обогащается значение поля Code и сопоставляется с полем Tracer - url. Производительность скрипта состовляет ~ 50 EPS, при рекомендуемой настройке Enrichment: 50 connections и 100 RPS.

Возможно использовать только поле url в сопоставлении, но туда можно поместить произвольные данные

При обогащении события получаем следующие обогащенные данные:

Так как используется "нелегальный" механизм обогащения в логах коллектора копятся (периодически очищайте) ошибки следующего вида: