Всем привет! Меня зовут Арсений, я работаю инженером анализа машинных данных в команде разработки программного обеспечения STEP Security Data Lake (SDL). Недавно наша команда разработала новый фреймворк противодействия инцидентам информационной безопасности – адаптивные действия, благодаря которым аналитики центров кибербезопасности (Security Operation Center, SOC) смогут быстрее принимать меры по сдерживанию и ликвидации последствий инцидентов непосредственно через единый графический интерфейс нашего продукта. Я использовал этот фреймворк для взаимодействия через Kaspersky Security Center Open API и хотел бы рассказать об этом в статье.
Немного о STEP SDL
Наша платформа предоставляет руководителям и специалистам центров кибербезопасности набор инструментов анализа больших массивов машинных данных для наблюдения за состоянием защищённости вычислительной сети и управления инцидентами информационной безопасности.
SDL реализует принцип единого окна доступа к данным о событиях, активах, угрозах и инцидентах. Он обеспечивает их наглядное представление и корреляцию с использованием единого конструктора визуализаций, языков поисковых запросов и описания алгоритмов. Особенности продукта – полноценная мультитенантность, гибкость и встроенная функциональность сразу нескольких классов решений, таких как SIEM и IRP/SOAR.
Немного о Kaspersky EDR для бизнеса Оптимальный
Kaspersky EDR для бизнеса Оптимальный с расширенными возможностями обнаружения угроз, базового расследования инцидентов и автоматизированного реагирования позволяет идентифицировать, анализировать и нейтрализовывать маскирующиеся угрозы.
Он предоставляет полный обзор происходящего в инфраструктуре, а также управление всеми функциями через единую консоль Kaspersky Security Center c системой отчетов и возможностью распределять зоны ответственности администраторов.
Проблематика
В любой компании есть риск наступления инцидентов информационной безопасности и необходимость применять комплекс мер защиты информации. К ним относятся задачи своевременного обнаружения вредоносной активности и задачи быстрого и эффективного сдерживания угроз, чтобы минимизировать возможный ущерб. Наши заказчики зачастую для этого используют решение Kaspersky EDR для бизнеса Оптимальный, которое обладает функциями по реагированию на инциденты информационной безопасности вручную, например, для помещения подозрительного файла на карантин или сетевой изоляции хоста. Но делают это только в рамках контекста событий сервера Kaspersky Security Center (KSC), в котором он развернут, и только в ручном режиме.
Для обнаружения широкого круга инцидентов информационной безопасности и автоматического реагирования на них заказчики используют STEP Security Data Lake, обладающий функциональностью решений класса Security Information and Event Management (SIEM) и Incident Response Platform (IRP). Чтобы автоматизировать реагирование на инциденты в SOC, и за счёт этого повысить скорость и удобство работы, мы реализовали интеграцию наших решений с использованием открытого API.
Данная статья будет полезна инженерам и разработчикам, реализующим интеграцию своих решений с Kaspersky EDR для бизнеса Оптимальный.
API Kaspersky EDR Optimum
Архитектура Kaspersky EDR для бизнеса Оптимальный включает в себя агента Kaspersky Endpoint Security (KES) с функциональным модулем EDR, агента администрирования KSC и сервер управления агентами Kaspersky Security Center (KSC). Соответственно, взаимодействие с ними предусмотрено через единый API-интерфейс – KSC Open API. В примерах я использовал 14 версию. Подробнее о KSC Open API можно прочитать по ссылке.
API-запрос имеет следующий общий вид:
https://ksc_address:13299/api/v1.0/Instance.Class.MethodName
где:
Class – имя класса
MethodName – имя функции класса
Instance – имя сущности, например, HostTags (тэги хоста) или InventoryTags (тэги ПО). Требуется только для определенных классов, например, ListTags, так что чаще всего применяется запрос https://ksc_address:13299/api/v1.0/Class.MethodName
Классы отвечают за те или иные функции KSC, будь то запуск задач (Task), проставление тэгов, импорт и экспорт политик безопасности и т. д. В данной статье я покажу примеры работы с классами:
Session – создание и прекращение сессии
HostGroup – проведение поиска хоста по его атрибутам
ChunkAccessor – работа с массивами, содержащими данные поисков
Tasks – работа с задачами KSC
ListTags – работа с тэгами
Instance – имя сущности, например, HostTags (тэги хоста) или InventoryTags (тэги ПО)
Взаимодействие всегда начинается с создания сессии, ID которой потом постоянно необходимо добавлять в заголовок при последующих запросах. Желательно предварительно создать отдельную внутреннюю учетную запись в KSC, через которую затем будет осуществляться взаимодействие с API.
Далее пойдут примеры без использования Python и прочих языков программирования (у «Лаборатории Касперского» есть python-модуль для упрощения работы с API). Я буду использовать только API-вебхуки как наиболее универсальный вариант.
Я рассмотрю два варианта реагирования:
помещение файла на карантин;
сетевая изоляция хоста с помощью проставления тэгов.
Помещение файла на карантин
Суть этого действия заключается в запуске специализированной Задачи (Task) на выбранном узле сети с установленным KES, который поместит выбранный файл на карантин. Подробная инструкция по созданию задачи через веб-консоль KSC находится на сайте вендора.
Для реализации нам потребуется предварительно провести небольшую настройку KSC под нужды каждой отдельной задачи.
Необходимо создать внутреннюю учетную запись для API-запросов в KSC и выдать ей права для возможности запуска Задач (Tasks)
Создать отдельную задачу на помещение файла на карантин. Необходимо включить следующую настройку для «Устройства, которым будет назначена задача» – «Задать адреса устройств вручную или импортировать из списка»
Зафиксировать идентификатор задачи, который отображается в адресной строке Веб-интерфейса KSC в виде десятичного числа (например, 145)
Создание удаленной сессии
curl -X POST \
https://ksc_address:13299/api/v1.0/Session.StartSession \
-H 'Authorization: KSCBasic user="<ksc_username_base64>",pass="<ksc_password_base64>",internal="1”'user – имя пользователя API в кодировке Base64
pass – пароль пользователя API в кодировке Base64
internal – число, где 0 – это учетная запись хоста, на котором установлен KSC, а 1 – это учетная запись самого KSC
Ответ сервера:
{
PxgRetVal: <id_сессии>
}Полученный ID указывается каждый раз при последующих обращениях к KSC в заголовке X-KSC-Session.
Получение ссылки на массив, хранящий ID выбранного хоста
curl -X POST \
https://ksc_address:13299/api/v1.0/HostGroup.FindHosts \
-H ' X-KSC-Session: <id_сессии> ' \
-d '{
"wstrFilter": "(| (KLHST_WKS_FQDN=\"<fqdn>\") (KLHST_WKS_DN=\"<display_name>\") (KLHST_WKS_WINHOSTNAME=\"<netBIOS_name>\") (KLHST_WKS_DNSNAME=\"<dns_name>\") (KLHST_WKS_IP_LONG=<host_ip_in_bytes>) )",
"vecFieldsToReturn": [
"KLHST_WKS_HOSTNAME",
"KLHST_WKS_DN"
],
"pParams": {
"KLGRP_FIND_FROM_CUR_VS_ONLY": true
},
"lMaxLifeTime": 120
}
'wstrFilter – содержит фильтр с атрибутами хоста, по которому будет производиться его поиск: KLHST_WKS_FQDN – полное доменное имя узла, KLHST_WKS_DN – имя, присвоенное узлу в KSC, KLHST_WKS_WINHOSTNAME – netBIOS – имя узла, KLHST_WKS_DNSNAME – DNS – имя узла, KLHST_WKS_IP_LONG – IP узла в байтах в порядке little endian
vecFieldsToReturn – содержит список полей, которые будут возвращены в одном элементе массива. Нас в основном интересуют поля KLHST_WKS_HOSTNAME, которое содержит ID нашего узла, а также KLHST_WKS_DN
pParams – содержит один единственный параметр KLGRP_FIND_FROM_CUR_VS_ONLY, который принимает значение true, если необходимо вернуть данные только с текущего сервера KSC, false – со всех доступных серверов
lMaxLifeTime – время жизни запрашиваемого массива в секундах
Ответ сервера:
{
strAccessor: <id_массива>,
"PxgRetVal": 1
}strAccessor – ссылка на массив, содержащий запрошенные нами данные
PxgRetVal – размер массива
Обращение к массиву с ID хоста
curl -X POST \
https://ksc_address:13299/api/v1.0/ChunkAccessor.GetItemsChunk \
-H ' X-KSC-Session: <id_сессии> ' \
-d '{
"strAccessor": "<id_массива>",
"nStart": 0,
"nCount": 1
}
'strAccessor – ID массива, в котором находится результат наших поисков
nStart – номер элемента массива, к которому мы хотим обратиться
nCount – количество элементов в массиве, то есть количество найденных значений, удовлетворяющим фильтру
Ответ сервера:
{
"pChunk": {
"KLCSP_ITERATOR_ARRAY": [
{
"type": "params",
"value": {
"KLHST_WKS_DN": "WIN-TEST-2",
"KLHST_WKS_HOSTNAME": "h6116814-adc1-1fab-9ded-6e219356027a"
}
}
]
},
"PxgRetVal": 1
}В ответе нас интересуют поля KLHST_WKS_DN и KLHST_WKS_HOSTNAME, которые мы будем использовать на одном из следующих этапов при обновлении задачи.
Получаем данные задачи
curl -X POST \
https://ksc_address:13299/api/v1.0/Tasks.GetTaskData \
-H ' X-KSC-Session: <id_сессии> ' \
-d '{
"strTask": "145"
}
'strTask – номер задачи в десятичном формате, которую можно узнать из адресной строки веб интерфейса KSC
Ответ сервера:
{ }Обновляем задачу
curl -X POST \
https://ksc_address:13299/api/v1.0/Tasks.UpdateTask \
-H ' X-KSC-Session: <id_сессии> ' \
-d '{
"pData": {
"TASK_ADDITIONAL_PARAMS": {
"type": "params",
"value": {
"files": [
{
"type": "params",
"value": {
"fileId": {
"type": "params",
"value": {
"filePath": "<путь_к_файлу>"
}
}
}
}
]
}
},
"TASK_INFO_PARAMS": {
"type": "params",
"value": {
"HostList": [
{
"type": "params",
"value": {
"HostDispName": "<KLHST_WKS_DN_с_4_этапа>",
"HostName": "<KLHST_WKS_HOSTNAME_с_4_этапа>",
"Preliminary": false
}
}
]
}
}
},
"strTask": "145"
}
'Ответ сервера:
{
"1": "0"
"2": "0"
"4": "1"
"8": "0"
"16": "0"
"32": "0"
"64": "0"
"KLTSK_NEED_RBT_CNT": "0"
"GNRL_COMPLETED_PERCENT": "100"
}Здесь я не привел все тело запроса, а указал только лишь те параметры, на которых стоит сфокусироваться в первую очередь. Я рекомендую копировать все остальные параметры при обновлении задачи на всякий случай, так как мне не удалось найти в документации информации, что можно обновлять настройки той или иной задачи выборочно.
Запускаем задачу
curl -X POST \
https://ksc_address:13299/api/v1.0/Tasks.RunTask \
-H ' X-KSC-Session: <id_сессии> ' \
-d '{
"strTask": "145"
}
'strTask – номер задачи
Ответ сервера:
{
"1": "0"
"2": "0"
"4": "1"
"8": "0"
"16": "0"
"32": "0"
"64": "0"
"KLTSK_NEED_RBT_CNT": "0"
"GNRL_COMPLETED_PERCENT": "100"
}Таким образом, мы запустили процесс помещения файла на карантин, однако сразу узнать результаты работы задачи не получится. Для этого спустя секунд 30 необходимо выполнить следующее:
Получение статистики запуска задачи
curl -X POST \
https://ksc_address:13299/api/v1.0/Tasks.GetTaskStatistics \
-H ' X-KSC-Session: <id_сессии> ' \
-d '{
"strTask": "145"
}
'strTask – номер задачи
Ответ сервера:
{
"1": "0"
"2": "0"
"4": "1"
"8": "0"
"16": "0"
"32": "0"
"64": "0"
"KLTSK_NEED_RBT_CNT": "0"
"GNRL_COMPLETED_PERCENT": "100"
}1 – количество хостов, на которых задача еще не обновилась
2 – количество хостов, на которых задача запущена
4 – количество хостов, на которых задача завершена успешно
8 – количество хостов, на которых задача завершена с предупреждением
16 – количество хостов, на которых задача завершена с ошибкой
32 – количество хостов, на которых запланирован запуск задачи
64 – количество хостов, на которых выполнение задачи поставлено на паузу
KLTSK_NEED_RBT_CNT – количество хостов, на которых задача запросила перезапуск ОС
GNRL_COMPLETED_PERCENT – общий процент успешности запуска задачи
К сожалению, я не смог найти в документации информации, за какой временной период происходит получение статистики запуска по итогам тестирования. Я пришел к выводу, что берется общая статистка за все время, поэтому альтернативной командой для получения результатов запуска может послужить https://ksc_address:13299/api/v1.0/Tasks.GetTaskHistory
В своем ответе оно возвращает history events, которые содержат в себе гораздо больше информации. В результате мы получим ссылку на массив, который и будет хранить интересующие нас данные, а именно:
task_old_state – предыдущее состояние выполнения задачи
task_new_state – новое состояние выполнения задачи. Тут мы ожидаем увидеть значение 4 (completed successfully)
rise_time – время публикации события в формате UTC
registration_time – время регистрации события сервером администрирования в UTC формате
Теперь у нас есть информация о времени изменения статуса задачи, с помощью которого мы сможем отфильтровать события и узнать статус выполнения именно той задачи, которую мы запускали.
Завершаем сессию
curl -X POST \
https://ksc_address:13299/api/v1.0/Session.EndSession \
-H ' X-KSC-Session: <id_сессии> 'Таким образом, если все выполнено без ошибок, то мы сможем добиться помещения выбранного нами файла на карантин.
Сетевая изоляция хоста
В данном случае посредством проставления тэгов мы будем активировать выбранный профиль политики безопасности с заранее настроенным межсетевым экраном, который будет блокировать все TCP- и UDP-подключения.
Как и в первом примере, нам потребуется сначала провести небольшую настройку KSC и получить ID хоста.
В действующей на устройствах политике KSC создаем профиль политики. Во вкладке «Правила активации» создаем «Правило для использования тега». Добавляем тег, который будет отражать применение сетевой изоляции хоста, например, Network Isolation. Сохраняем правило активации. В созданном профиле политики во вкладке «Параметры программы» → «Базовая защита» → «Сетевой экран» включаем «Сетевой экран» и «Настройки сетевого экрана». Во вкладках «Сетевые правила приложений» и «Сетевые пакетные правила» указываем желаемые настройки, которые будут применяться во время изоляции хоста, например, будем блокировать весь трафик для протоколов TCP и UDP.
Подробная инструкция предусмотрена на сайте вендора.
Далее повторяем этапы из предыдущего примера: создание удаленной сессии, получение ссылки на объект, хранящий ID выбранного хоста, обращение к объекту с ID хоста.
Добавление тэгов
curl -X POST \
https://ksc_address:13299/api/v1.0/HostTags.ListTags.SetTags \
-H ' X-KSC-Session: <id_сессии> ' \
-d '{
"pListItemsTags": [
{
"type": "params",
"value": {
"KLTAGS_ITEM_ID": "<ID_хоста>",
"KLTAGS_TAGS": [
{
"type": "params",
"value": {
"KLTAGS_SET": true,
"KLTAGS_VALUE": "tag1"
}
},
{
"type": "params",
"value": {
"KLTAGS_SET": true,
"KLTAGS_VALUE": "tag2"
}
}
]
}
}
],
"pParams": {
"KLTAGS_FULL_REPLACE": true
}
}
'
pListItemsTags – список, содержащий в себе параметры, простановки тэгов;
KLTAGS_ITEM_ID – ID элемента (в данном случае ID хоста), для которого будут проставлены тэги;
KLTAGS_TAGS – список тэгов, которые содержат следующие параметры: KLTAGS_VALUE – название тэга, KLTAGS_SET – true для проставления тэга и false для его удаления;
KLTAGS_FULL_REPLACE – флаг, принимающий значение true, если требуется полностью перезаписать все тэги на узле, false – не требуется.
Ответ сервера:
{ }Завершаем сессию.
Заключение
KSC Open API предоставляет достаточно широкий спектр возможностей реагирования, который напрямую зависит от типов продуктов «Лаборатории Касперского», подключенных к KSC. Документация у API подробная, однако начинающему разработчику сразу разобраться в тонкостях ее работы будет нелегко. Причина – неоднозначные названия аргументов, которые могут быть не задокументированными, а также неочевидные требования к структуре самих запросов, как, например, тот же тип params. Помочь в решении данной проблемы может приведение примеров напрямую с использованием вебхук-запросов для каждой функции класса, которые содержали бы в себе также примеры ответов со ссылками на объяснение возвращаемых атрибутов.
