Андрей Амирах, Security Vision
Тимур Галиулин, Infowatch
В этой статье мы расскажем о процессе автоматизации рутинной деятельности в одном из подразделений ИБ крупной компании.
Исходные данные: подразделение информационной безопасности (далее – ИБ) крупной компании с филиальной структурой обрабатывает большое количество событий информационной безопасности как в головном, так и в дочерних офисах по всей стране. Группа специалистов, для которых была проделана работа по автоматизации, занимается в основном событиями, связанными с утечками данных. Первоисточником для событий ИБ является DLP-система InfoWatch Traffic Monitor, которая собирает и анализирует события ИБ по всем филиалам централизованно. Поскольку собираемая DLP-системой информация конфиденциальна, доступ к консоли имеет ограниченный круг лиц, а разбор утечек, расследования и дополнительные мероприятия могут проводить как сотрудники с полным доступом, так и сотрудники, не имеющие доступ к DLP-системе. Для того, чтобы передать информацию сотрудникам без расширенного доступа, в консоли DLP-системы привилегированные пользователи просматривают события, помечают их как нарушения и после вручную заводят задачу на «разбор полетов» для сотрудника филиала, в котором произошла утечка. DLP-система собирает большую доказательную базу, и к задаче также прикладывался файл с вложениями содержащими чувствительную информацию. Для надежности этот файл шифруется при помощи личного сертификата и «КриптоПРО». Все это до внедрения решения делалось в ручном режиме.
Задачи, которые было необходимо автоматизировать:
-
создание заявки в трекере задач
-
назначение задачи на сотрудников филиала в котором произошла утечка
-
шифрование файлов вложений из DLP-системы
- добавление к созданной задаче зашифрованных файлов вложений
Дополнительные задачи, которые возникли в процессе реализации:
-
мониторинг состояния личных сертификатов пользователей
-
формирование предупреждающих сообщений о просроченных сертификатах
-
отправка инструкций по обновлению сертификата пользователя
- формирование отчетности по события DLP-системы
Для достижения поставленных целей, в первую очередь, нужно было получить данные о событиях из DLP-системы. Как выяснилось, у DLP InfoWatch Traffic Monitor есть целых два API:
-
Data Export API
- Push API
Data export отвечает за получение сторонними системами данных из DLP-системы, а Push API позволяет загрузить данные из сторонних систем в Traffic Monitor. Как вы, наверное, и сами уже догадались, для решения задач проекта использовалcя интерфейс Data Export API. На время пилотного тестирования была запрошена временная лицензия, и дело осталось за малым – выбрать подходящий оркестратор, чтобы сделать все быстро и без особых «танцев с бубном». Выбор пал на платформу Security Vision, так как из коробки она обладала расширенным функционалом для написания интеграций со сторонними сервисами и также на руку нам играл тот факт, что платформа позволяла выстраивать отчетность, используя встроенный механизм построения отчетов.
Дело осталось за малым – реализовать интеграции и подружить между собой следующие компоненты:
-
DLP-система (источник данных о событиях ИБ)
-
SOAR система (основной механизм автоматизации процессов)
-
КриптоПРО (механизм шифрования файлов)
- Трекер задач (инструмент для распределения задач по филиалам)
Для начала нам нужно было получить доступ к Traffic Monitor Data Export API из платформы Security Vision. Для этого мы запросили лицензию на API у разработчика и активировали ее на нашей инсталляции сервера DLP InfoWatch Traffic Monitor. После активации лицензии достаточно просто указать в заголовках запроса версию API, company ID, importer name и token (company ID и importer name нужно указать при запросе лицензии).
Скриншот 1 – Заголовки запросе в конструкторе коннекторов Security Vision
После того как связь SOAR и DLP налажена, начинается самое интересное – получение данных о событиях информационной безопасности. Согласно плану реализации интеграции, нам необходимо получить следующие сведения:
-
Идентификатор события в DLP InfoWatch Traffic Monitor
-
Заголовок события
-
Дата перехвата
-
Уровень нарушения
-
ФИО отправителя чувствительной информации
-
Электронная почта отправителя
-
Сработавшие политики безопасности
-
Перехваченные файлы, содержащие чувствительную информацию
-
ФИО администратора, обнаружившего и пометившего событие как нарушение
Для решения этой задачи пришлось сделать четыре независимых типа запросов на сервер InfoWatch Traffic Monitor:
-
Получение событий ИБ с метаданными
-
Получение описания файлов событий
-
Получение самих файлов
-
Получение данных из аудита системы
В первом запросе формируется список задач, отвечающих критериям выборки для опытной эксплуатации:
Скриншот 2 – Запрос на получение событий ИБ
URL/xapi/event?filter[date][from]=start_unix_time&filter[user_decision]=
Violation&filter[object_type_code]= D2B5132E27DA11E28444C2DB6088709B00000000
&with[senders]&with[policies]&with[recipients]
В ответ на запрос сервер InfoWatch Traffic Monitor отдает массив с событиями, попадающими под фильтр в запросе. Запрос выполняется с цикличностью в две минуты. Дальнейшая нормализация данных выполняется на лету в обработчике Security Vision:
Скриншот 3 – Окно обработки результата HTTP запроса в платформе Security Vision
Во втором запросе на основании полученного идентификатора события формируются данные о связанных файлах, перехваченных DLP-системой в рамках выявления нарушения. В данном случае нужно получить именно названия файлов, в том числе в архивах:
Скриншот 4 – Запрос на получение описания связанных файлов
URL/xapi/event/event_id?with[]=files
Ответом на второй запрос является JSON, содержащий подробную информацию о перехваченном файле, но наибольшую ценность для нас представляет значение OBJECT_CONTENT_ID:
Скриншот 5 – Результат запроса на получение описания связанных файлов
В третьем запросе происходит загрузка перехваченного файла события ИБ из DLP-системы:
Скриншот 6 – Запрос на загрузку связанных файлов
URL/xapi/event/file_id/raw?download=1
Здесь FILE_ID – название переменной, в конструкторе запросов в нее передается параметр Traffic Monitor OBJECT_CONTENT_ID. И, наконец, для получения сведений об администраторе DLP-системы, отметившем событие как нарушение, нам пришлось обратиться к данным аудита системы при помощи следующего запроса:
Скриншот 7 – Запрос на получение последних 200 событий аудита
URL/xapi/audit?filter[entity_type]=Object&sort[change_date]
=desc&start=0&limit=200
Здесь limit - количество событий аудита между двумя синхронизациями, стоит настраивать по месту. После небольшого преобразования ответа получаем нормализованные данные по каждому событию аудита DLP-системы. Поле CHANGER_NAME является тут полем ФИО администратора, изменившего статус события на событие с нарушением:
Скриншот 8 – Нормализация данных по событию аудита в платформе Security Vision
На этом с DLP все, теперь нужно обогатить данные, зашифровать файлы, завести задачи в трекер и построить аналитику по всем собранным данным.
Обогащение происходит за счет интеграции с Active Directory. У платформы Security Vision в стандартном функционале есть тип коннектора LDAP, он позволяет писать запросы в графическом интерфейсе. Коннектор выглядит следующим образом:
Скриншот 9 – LDAP запрос пользователей из AD с фильтрацией по полю mail
В результате выполнения команды можно получить расширенную информацию по конкретному пользователю, даже если входной параметр один ─ электронная почта.
Скриншот 10 – результат LDAP запроса
После того как данные получены и файлы вложений скачаны на сервер, Security Vision нужно сформировать зашифрованную копию файла для отправки в трекер. Приведем пример коннектора, который выполняет операцию скачивания и шифрования:
Скриншот 11 – Загрузка файла непосредственно из DLP в файловую систему шифрующего сервера
curl -k -s \
-H "X-API-Version: 1.1" \
-H "X-API-CompanyId: SecurityVision" \
-H "X-API-ImporterName: SV5Platvorm" \
-H "X-API-Auth-Token: api_key" \
-o "/distr/shared/dlp/dlp_event_id.eml" \
"https://dlp_server_name/xapi/event/dlp_event_id/raw?download=1"
В приведенном запросе идет скачивание на другой сервер, затем файл шифруется с помощью цифровой подписи и КриптоПро. Обратите внимание, что скачивание корневого контента происходит аналогично запросу, приведенному в начале статьи, но происходит в другом контейнере с установленным КриптоПро.
Скриншот 12 – Шифрование файла посредством вызова команды из контейнера с Крипто Про
docker exec cryptopro bash -c "yes Y | cryptcp -encr /shared/dlp/dlp_event_id.eml /shared/dlp/dlp_event_id.eml.p7m"
rm -f /distr/shared/dlp/dlp_event_id.eml
Итогом работы двух команд коннектора является исполнение команды curl на загрузку файла вложения из DLP-системы, команды docker exec для выполнения шифрования файла с использованием контейнера КриптоПро и последующее удаление оригинального файла. Если вдаваться в детали, то на шифрующем сервере поднят контейнер с КриптоПро, который использует расшаренную вместе с хостом папку /shared/dlp, поэтому контейнер видит скачанные файлы и может с ними взаимодействовать.
Последний этап процесса автоматизации – отправка полученной информации на трекер задач. С этой задачей справиться было проще всего, так как современные трекеры задач в большинстве своем обладают хорошо задокументированными API. В данном случае использовался трекер Redmine, и вся работа платформы Security Vision сводилась к двум простым действиям:
-
загрузить зашифрованный файл на сервер Redmine и получить токен файла
- используя API создать задачу и сделать линк к загруженному файлу
При помощи HTTP коннектора можно легко выполнять POST запросы и обрабатывать ответы удаленного сервера.
Скриншот 13 – Команда на загрузку файла в Redmine
URL/redmine/uploads.json?filename=event_id.eml.p7m
Скриншот 14 – Обработка результата загрузки файла и получение токена
Далее с помощью токена, загруженного файла и HTTP коннектора, можно сделать запрос к API Redmine для создания задачи и получить идентификатор задачи непосредственно в трекере задач Redmine.
Скриншот 15 – Запрос на создание задачи в Redmine
<?xml version="1.0"?>
<issue>
<uploads type="array">
<upload>
<token>file_token</token>
</upload>
</uploads>
<project_id>163</project_id>
<subject>subject</subject>
<description>description</description>
<category_id>org_unit_id</category_id>
<status_id>7</status_id>
<watcher_user_ids>manager_id</watcher_user_ids>
<watcher_user_ids>reporter_id</watcher_user_ids>
<custom_fields type="array">
<custom_field name="Филиал" id="25">
<value>нормализация филиала</value>
</custom_field>
</custom_fields>
</issue>
Скриншот 16 – Обработка запроса на создание задачи в трекере и получение id задачи
Хотелось бы отметить тот факт, что задача назначается на определенный филиал, и переменная org_unit_id из запроса на создание задачи формируется посредством запроса данных из AD по электронной почте нарушителя. Также интересным образом формируется user_api_key (см. Скриншот 13), он по факту является уникальным идентификатором пользователя в Redmine. Система Security Vision хранит в виде таблицы связку ФИО ответственных за DLP-систему и этих токенов. На этапе запроса метаданных из DLP-системы (см. Скриншот 8) платформа Security Vision автоматически сравнивает результат и преобразует ФИО в токен. Это нужно для того, чтобы в трекере задач явно было видно, от чьего имени заведена задача.
Итогом проекта стало значительное увеличение скорости обработки инцидентов, связанных с утечками информации. Раньше после обнаружения утечки администратор DLP-системы тратил около 30 минут на заведение одной задачи, так как ему нужно было в ручном режиме обогатить карточку задачи, найти филиал, грамотно выставить ответственного и наблюдателей, зашифровать файл. После внедрения решения Security Vision эти процессы выполняются в автоматизированном режиме, не отвлекая специалиста от другой работы. Заведение задач на большое количество филиалов практически полностью автоматизировано. Администратору DLP-системы теперь достаточно пометить события как нарушение, а всю рутинную работу на себя берет SOAR система.
Справка
API InfoWatch содержит несколько «пасхалок», которые позволяют и далее улучшить производительность высоконагруженных запросов SOAR систем. DLP-cистема InfoWatch Traffic Monitor позволяет творчески реализовать задачу разными способами. Например, объединить несколько однотипных запросов, исключить запомненные в предыдущей итерации события и эффективно использовать потоки обработки. Если вы хотите узнать другие варианты решения - добро пожаловать в Академию InfoWatch.
Ссылка на документацию, используемую в статье (DataExport API): https://kb.infowatch.com/display/TMSDK
Security Vision SOAR обеспечивает автоматизацию реагирования на инциденты информационной безопасности при помощи динамических плейбуков с применением СЗИ, выстраиванием цепочки атаки и объектно-ориентированным подходом. Решение снижает влияние человеческого фактора, повышает скорость реакции на инциденты, выстраивает проактивную защиту в соответствии с международными стандартами информационной безопасности.
Security Vision SOAR агрегирует события и инциденты, осуществляет автоматическое выполнение команд на различных внешних системах для оперативного сдерживания и устранения негативных последствий согласно методологии NIST, с предоставлением экспертных рекомендаций на различных этапах управления инцидентами.
Подробнее о продукте: https://www.securityvision.ru/products/soar/