Привет.
Сегодня хотим поговорить про SIEM, точнее про стандартную задачу – интеграцию системы с другими элементами ИТ-инфраструктуры. Это часто оборачивается проблемой, ведь какую бы SIEM вы ни внедрили у себя, для нее всегда найдется какая-то «неберучка», к которой нет коннектора и для которой стандартный способ «стыковки» через Syslog или Windows event log – не вариант.
Это касается ситуации, когда нужно настроить интеграцию SIEM с самописным ПО или какой-то старой системой. Та же проблема может возникнуть в случае «прикручивания» DIY-оборудования. Или когда интеграция через коннектор есть, но из полученной в ее результате информации нужно выудить дополнительные данные помимо тех, которые она сгружает в нужном формате.
В чём проблема?
Проблема выглядит надуманной только если у вас в компании (или непосредственной близости) есть пара свободных рук разработчика, чтобы написать новый коннектор к SIEM на том языке программирования, который в ней используется. А в некоторых SIEM таких языков программирования используется несколько, плюс они могут быть еще и собственной разработки. Есть и второй вариант – заказать вендору доработку, но это не всегда возможно и по карману.
Сложность ПО – это общая головная боль тех, кто работает с SIEM, из-за которого использование этого полезного софта ограничивается крупным бизнесом, да и то не любым. Программистов не напасёшься, более того, чести администрировать SIEM часто удостаивается системный администратор, которому не улыбается становиться штатным разработчиком. Поэтому проблему подключения новых источников информации, если это невозможно другими способами, мы решили через создание Custom Connector в нашей SIEM. В нём можно написать коннектор самостоятельно на Windows Powershell.
Powershell – удобный инструмент, потому что он уже есть у системных администраторов и не требует от них применения каких-то особых усилий. Тем более, что сейчас мы поставляем SIEM с образцами скриптов, которые писали для себя или клиентов – могут пригодиться. Так что такая реализация решения стала активно применяться заказчиками. Например, в комплекте поставки у нас есть шаблоны скриптов для работы с Kerio: выгрузка отчетов о входах, ошибках аутентификации, вторжения в систему и т.п. Получается такой «облегченный» коннектор к Kerio, который еще можно доработать под себя.
С прелюдией покончено, разберем кейс, как написать коннектор самому.
Заказчик – небольшой банк, в котором с SIEM работают системные администраторы. То есть классика реализации сценария использования системы, как я ее описывал выше. Важно, чтобы SIEM забирала события из Автоматизированной банковской системы. Но автоматом этого не происходило, потому что АБС самописная, никаких сиемовских форматов типа syslog не поддерживала, не поддерживает и не собирается в дальнейшем. Поэтому если с ней что-то не так, разбираться ИТ-службе приходилось с шаманами и бубнами.
Понятно, что если АБС грохнется, то сисадмины об этом узнают и без SIEM. Но если она уже работает в банке, логично настраивать интеграцию, потому что:
удобно получать уведомления самостоятельно, а не от перепуганных пользователей;
некоторые проблемы можно устранить на взлёте, до критического обвала;
ну и вообще полезно собирать через SIEM архив инцидентов.
Чтобы избавить ИТ-службу от этих страданий, предложили наш вариант стыковки SIEM с АБС с помощью скрипта в Customer Connector.
Администраторы накидали свои ожидания: нужно поднять информацию из текстового файла по заданному адресу, каждая строка файла содержит 7 значений с разделителем, для каждой строки нужно сформировать отдельный инцидент, подтянуть и расшифровать значения кодов, определить критичность и скинуть уведомление в случае необходимости.
Собственно, краткое ТЗ на скрипт от компании выглядело так:
Разработать интеграцию с Автоматизированной Банковской Системой. Импорт в SIEM в виде отдельного правила – коннектора файла следующего вида:
Значения разделены точкой-запятой.
Названия полей перечислены ниже:
Date; Time; user; NumbError; MessError; MethodError; LineError; CodeError
Последнее значение может быть пустым, тогда строка заканчивается на ";"
Формализованное так:
1. Выполнить интеграцию с АБС используя импорт данных из автоматически генерируемого в АБС файла «*имя*.txt» (*имя* соответствует любому количеству символов латиницей или цифр. Без спец. символов).
1.1. В качестве источника данных для интеграции используется файл «*имя*.txt» и только он.
1.2. Файл «*имя*.txt» может иметь расширение .txt и только его.
1.3. Файл «*имя*.txt» имеет следующую структуру: Каждая строка файла представляет из себя «массив» значений семи полей, разделителем значений является символ «;». Поля следующие: Date, Time, Username, NumbError, MessError, MethodError, LineError, CodeError.
1.4. Количество полей в файле «*имя*.txt» не может быть изменено.
1.5. Наименование и формат наполнения полей в файле «*имя*.txt» не может быть изменено.
1.6. Значения полей в файле «*имя*.txt» могут быть пустыми.
В банке с написанием скрипта в первый раз повозились – пришлось вспоминать, как это делается. На написание ушло 2 часа, за которые получили работающий скрипт.
Сам скрипт в итоге получился следующего вида:
# Каталог с логами АБС
$absLogPath = "C:\ABS\Logs"
# Разделитель данных
$delimiter = ';';
# Заголовок столбцов
$header = "Date", "Time","Username","NumbError","MessError","MethodError","LineError","CodeError";
# Экспортируемые события
$events = @();
# В конвейере:
# 1. Загрузить список актуальных логов, отсортированные по возрастанию даты записи
# 2. Импортировать данные из файла в виде CSV
# 3. Создать нормализованное событие и добавить в список экспортируемых событий
Get-ChildItem -Path $absLogPath |
Sort-Object -Property LastWriteTime |
ForEach-Object { $events += Import-CSV -Path $_.FullName -Delimiter $delimiter -Header $header};
# Экспортировать в JSON-формате
ConvertTo-Json $events;
Когда его прогнали, увидели, что генерируется множество лишней информации, внесли в скрипт проверку на дубли с уже импортированными записями. Это заняло минут 15, потому что скрипт можно доработать руками в любой момент.
Необходимость направлять уведомления в скрипте не нужно прописывать – это родная функция SIEM. Для удобства у нас есть killer feature, наша «сием» умеет отправлять уведомления не только в почту, но и в Телеграм, для этого не нужно делать сложные настройки.
Со следующими скриптами дело пошло резвее, тем более что – упоминал выше – в распоряжении клиентов есть образцы, используя которые можно управиться гораздо быстрее.
Как показывает наш опыт, такая реализация пользовательского коннектора – это практичное решение в рамках нашей архитектуры SIEM и той концепции, которую пропагандируем – система должна быть простой.
SIEM будут получать все большее распространение, рук на них будет по-прежнему не хватать, нужны доступные инструменты. Мы поэтому изначально разрабатывали свою SIEM-систему такой, чтобы ею мог пользоваться человек даже с базовыми знаниями в администрировании. Хотя у powershell есть свои ограничения, главную задачу в данном случае он решает отлично.
Будем рады вопросам, критике, предложениям в комментариях.