Построили работающую SIEM у оператора среднего масштаба с помощью Kaspersky KUMA
Клиент
Построение работающей SIEM у оператора среднего масштаба с помощью Kaspersky KUMA
Кейс по внедрению Kaspersky Unified Monitoring and Analysis Platform (KUMA) — и превращению груды логов в реальные обнаружения.
Это вторая глава истории, которую мы начали с логистическим и оптовым оператором, которого будем называть Компания N: около 500 сотрудников, головной офис, четыре региональных склада-хаба и 450 хостов. В первом проекте мы поставили KSMG перед их электронной почтой и управляемый агент защиты конечных устройств на рабочие станции, при этом оба решения передавали данные в единую консоль управления. Это закрыло два крупных пробела. Но одновременно возникла более тихая, третья проблема, которой и посвящен этот кейс.
У компании Компания N теперь была хорошая телеметрия. KSMG знал, какие письма были фишинговыми. Агент на конечных устройствах знал, какие процессы вели себя подозрительно. Контроллеры домена знали, кто и откуда входил в систему. Межсетевой экран знал, какие узлы обращались в интернет. Проблема заключалась в том, что всё это находилось в разных местах, а роль интеграционного слоя между ними приходилось выполнять человеку. Когда что-то шло не так, команда безопасности превращалась в археологов: вручную копалась в четырех или пяти консолях, пытаясь уже постфактум собрать единую хронологию.
SIEM существует именно для того, чтобы быть таким интеграционным слоем, чтобы людям не приходилось делать это вручную. Это история о том, как компания Компания N получила SIEM, которая действительно работает, а не дорогое хранилище логов, в которое никто не смотрит.
Триггер
Как и раньше, проект сформировался вокруг конкретного инцидента, хотя на этот раз урок был связан не с самой экспозицией риска, а со скоростью.
Пользователь перешел по ссылке в письме, которое прошло через фильтрацию как пограничное. Вскоре после этого агент на конечном устройстве зафиксировал подозрительное поведение и заблокировал его. Само по себе это выглядело как рутинное, локализованное событие: защита сработала, предупреждение закрыто. Но неделю спустя при плановом просмотре логов контроллеров домена обнаружилась необычная аутентификация с учетной записи того же пользователя — в нестандартное время и на систему, к которой он не должен был обращаться по рабочей необходимости. Связать эти два факта — клик по письму и аномальный вход — старшему аналитику удалось только после почти двух дней ручного сопоставления данных из трех разных инструментов. А сами события произошли с разницей в минуты. Все данные для того, чтобы связать их, существовали с самого начала. Просто не было способа увидеть их как одну историю.
После инцидента руководитель ИТ компании Компания N задал прямой вопрос: если все эти сигналы уже находятся в наших системах, почему нам требуется два дня, чтобы связать два события, которые произошли с разницей в две минуты?
Этот вопрос почти дословно является бизнес-обоснованием для SIEM. Параллельно был и комплаенс-драйвер: аудиторы хотели видеть подтверждаемое централизованное хранение логов и записей об инцидентах. Но именно проблема скорости сделала необходимость внедрения реальной для людей, которые выполняли работу.
анализа
минуты
Почему KUMA
Мы предложили Kaspersky Unified Monitoring and Analysis Platform (KUMA). Несколько факторов сделали ее подходящим выбором именно для организации такого масштаба и уровня зрелости, как Компания N.
Первый фактор
Первый фактор заключался в том, что их наиболее ценные источники событий уже были продуктами Kaspersky. Почтовый шлюз, агент защиты конечных устройств и сервер управления интегрируются нативно, а значит, самые важные данные — в том числе две половины исходного инцидента — можно было коррелировать из коробки, а не через индивидуальную разработку парсеров.
Второй фактор
Второй фактор — архитектура. KUMA построена на микросервисах: Core для управления и интерфейса, один или несколько Collectors, Correlator и Storage. Это значит, что для среды такого размера можно стартовать с умеренным контуром и позже масштабировать отдельные компоненты без смены платформы. SIEM, которая требует большую выделенную команду и стойку оборудования, — неправильный инструмент для компактной службы безопасности. А решение, которое может начать с малого и расти, — правильный.
Третий фактор
Третий фактор — операционная экономика для небольшой команды. KUMA поставляется с несколькими сотнями предварительно настроенных правил корреляции, сопоставленных с фреймворком MITRE ATT&CK, и каждое правило содержит рекомендации по реагированию. Поэтому аналитики компании Компания N не начинали с пустой страницы. Готовый детекционный контент, который не нужно писать самостоятельно, — главный ускоритель для команды, у которой нет свободных инженеров по разработке детектов.
Четвертый фактор
Четвертый фактор — резидентность данных. Платформа разворачивается и эксплуатируется on-premises, а события хранятся локально. Это было важно для компании, которая хотела, чтобы ее телеметрия безопасности оставалась внутри собственного периметра.
Архитектура и проектирование
Мы развернули четыре логические роли KUMA в среде компании, рассчитав их под реальный объем событий с осознанным запасом.
Core работает централизованно и предоставляет веб-интерфейс, в котором работают аналитики и где выполняется вся настройка сервисов. Collectors расположены близко к источникам событий, включая один коллектор на крупнейшем складе-хабе. Они принимают сырые события, нормализуют их в общую схему, фильтруют и агрегируют до передачи дальше. Correlator анализирует нормализованный поток по правилам корреляции и активным спискам и создает оповещения. Слой Storage построен на ClickHouse, что обеспечивает платформе быстрый поиск по большим объемам событий.
Отдельно стоит остановиться на объеме событий. Сырой поток событий компании на пике находился в нижней части пятизначного диапазона событий в секунду — это комфортно укладывалось в возможности одного узла KUMA, поскольку платформа рассчитана на обработку существенно более высоких скоростей на один экземпляр. Инженерная дисциплина здесь не в погоне за максимальной пропускной способностью, а ровно наоборот. Мы использовали агрегацию и фильтрацию на стороне коллекторов, чтобы свернуть высокообъемный, но низкоценный шум — например, повторяющиеся записи сетевых соединений между одними и теми же конечными точками, объединенные в единые агрегированные события, — еще до попадания в хранилище. Это позволило удержать эффективный EPS, а значит, объем хранения и лицензирования, в разумных пределах, не отбрасывая того, что позже понадобится для расследований.
Для хранения мы использовали многоуровневый подход: горячий слой в ClickHouse для недавних событий и быстрого интерактивного поиска и холодный слой для более длительного хранения в целях аудита, при этом поиск мог охватывать оба слоя. Отказоустойчивость была заложена там, где она действительно важна: распределение нагрузки и автоматическое переключение для сервисов обработки, а также дисковый буфер коллекторов, чтобы при кратковременной недоступности нижестоящих компонентов события сохранялись локально и отправлялись позже, а не терялись.
Collectors
Storage
Подключение источников событий
SIEM настолько хороша, насколько хороши данные, которыми вы ее кормите, и порядок подключения источников тоже имеет значение. Мы в первую очередь подключали источники, которые позволили бы разобраться с исходным инцидентом, а затем расширяли охват.
Стек Kaspersky был подключен первым и проще всего, через нативную интеграцию: почтовый шлюз, агент защиты конечных устройств и центральный сервер управления, который также передавал контекст по активам — что представляет собой каждая машина и кому она принадлежит. Сбор событий Windows с контроллеров домена и серверов был настроен через агент Windows платформы и механизм пересылки событий, поэтому события аутентификации централизованно попадали в систему. Затем были подключены Linux-хосты, на которых работали части логистического стека, периметровый межсетевой экран, VPN-концентратор, DHCP и DNS.
Для каждого источника работа имела одну и ту же форму: получить сырые события через коннектор, нормализовать их так, чтобы «пользователь», «исходный IP-адрес» или «хост» означали одно и то же поле независимо от того, какое устройство породило событие, а затем настроить фильтрацию и агрегацию для контроля объема. Предопределенные парсеры платформы для стандартных форматов закрыли большую часть этой работы; основная трудоемкость пришлась на несколько источников, которые не следовали стандартам, — к ним мы еще вернемся.
Нормализация — неприметное сердце всей работы. Корреляция между источниками возможна только потому, что поле пользователя из почтового шлюза и поле пользователя из контроллера домена сопоставлены с одним и тем же нормализованным полем. Пропустите или испортите этот этап — и SIEM превратится в поисковую систему по несогласованным логам, а не в систему обнаружения.
Обнаружение: заставить данные рассказать историю
Когда источники начали передавать события, мы включили обнаружение в три слоя.
Мы начали с предварительно настроенных правил корреляции, сопоставленных с MITRE, как с базовой линии, включая их поэтапно, а не все сразу, чтобы увидеть — и настроить, — что каждое правило дает на реальном трафике компании. Сопоставление каждого правила с ATT&CK и встроенные рекомендации по реагированию означали, что при срабатывании аналитик видел не просто «alert», а какой технике атакующего это соответствует и какие действия стоит рассмотреть. Для команды без глубокого опыта разработки детектов это было особенно ценно.
Поверх этого мы добавили активные списки: динамические списки с состоянием, из которых коррелятор читает и в которые записывает данные. Например, они позволяют отслеживать количество неуспешных попыток аутентификации по каждой учетной записи, чтобы паттерн brute force по множеству событий превращался в одно осмысленное оповещение, а не в тысячу отдельных строк логов.
Затем мы обогатили события контекстом, который ускоряет триаж: данными об активах из сервера управления, чтобы оповещение содержало идентичность хоста и владельца, а не только IP-адрес, и проверками по threat intelligence, чтобы соединение с известным вредоносным индикатором отмечалось автоматически, а не зависело от того, узнает ли аналитик этот адрес.
Наконец, мы написали небольшое количество кастомных правил корреляции под контекст компании N. Самым важным было именно то правило, которое отражало сценарий, запустивший проект: событие, связанное с фишингом, от почтового шлюза по конкретному пользователю, затем в коротком окне — обнаружение подозрительного поведения на конечном устройстве этого пользователя, затем — аномальная аутентификация по этой учетной записи. По отдельности каждое из этих событий может выглядеть незначительным. В цепочке — это инцидент. Мы также использовали ретросканирование: запуск новых или обновленных правил корреляции по уже сохраненным событиям, чтобы улучшенную логику обнаружения можно было проверить на истории, а не только на будущем трафике.
ATT&CK
списки
Реагирование и эксплуатация
Обнаружение без рабочего процесса — это просто более громкая куча логов, поэтому операционную модель мы строили вместе с технологией.
Оповещения в KUMA агрегируются в инциденты, которые объединяют связанные события, обогащение и таймлайн. Именно это превращает исходную двухдневную реконструкцию в одну заранее собранную карточку. Дальше команда работает по определенному процессу. А поскольку KUMA интегрируется обратно в слой управления Kaspersky, некоторые действия реагирования можно инициировать прямо из расследования, не переходя в другую консоль: например, изолировать хост или запустить проверку подозрительного конечного устройства.
Мы реалистично оценивали кадровые возможности. У компании N небольшая команда безопасности и нет желания строить собственный круглосуточный SOC 24/7, поэтому внедрение было спроектировано как совместно управляемое. Платформа остается на территории компании вместе с их данными, а мониторинг в нерабочее время может выполнять внешний партнер, работающий с той же системой. SIEM — это общий технологический слой; кто смотрит в нее в 3 часа ночи — кадровое решение, а не архитектурное.
Где было сложно
Честная часть. Сложность SIEM-проекта почти никогда не заключается в установке — она заключается в настройке, и KUMA не стала исключением.
Бюджетирование EPS и шумные источники.
Пара «разговорчивых» источников грозила раздуть объем событий — а значит, хранилище и стоимость — за счет низкоценных записей. Вместо того чтобы отключать источники, мы настроили агрегацию и фильтрацию на стороне коллекторов так, чтобы сигнал сохранился, а шум был свернут. Найти правильный баланс удалось только после нескольких итераций наблюдения за отчетами по объему.
Ложные срабатывания в базовых правилах.
Некоторые предварительно настроенные правила, разумные в общем случае, создавали шум в конкретной среде компании N: процесс резервного копирования выглядел как массовый доступ к файлам, а администраторский инструмент напоминал lateral movement. Мы настроили пороги и создали ограниченные по области исключения, приняв как факт, что первые недели жизни SIEM — это диалог между правилами и средой, а не финальное состояние.
Согласованность времени и идентичности.
Корреляция зависит от того, синхронизированны ли события между собой в вопросах когда и кто. В начале один источник с уходящими часами и другой источник, который записывал имена пользователей в нестабильном формате, создавали корреляции, которые не сходились. Принудительная синхронизация времени и исправление маппинга нормализации решили проблему. Это неприметная инженерная «сантехника», на которой держится вся ценность корреляции.
Расчет размера хранилища.
Мы сознательно пересчитали прогноз по горячему и холодному хранению после первого месяца реальных данных, когда уже видели фактический ingest, а не оценки. Избыточное горячее хранилище дорого; недостаточное — замедляет расследования по свежим событиям. Это настройка, которую лучше калибровать по реальности, а не по спецификации.
Результаты
После периода настройки разница проявилась не столько в каком-то одном дашборде, сколько в том, как начала работать команда.
Метрика, которая была важна руководству компании N, — среднее время до понимания инцидента: промежуток между «что-то сработало» и «мы знаем полную историю». Оно сократилось с дней до нескольких часов, а для коррелированных многоэтапных кейсов — до почти мгновенного понимания, потому что история приходила уже собранной.
Самое наглядное подтверждение появилось через несколько недель — это был исходный инцидент в миниатюре, только на этот раз в прямом времени. Пользователь взаимодействовал с фишинговой ссылкой, которую шлюз отметил как пограничную; через несколько минут агент на конечном устройстве зафиксировал подозрительное поведение после клика; вскоре после этого та же учетная запись попыталась выполнить необычную аутентификацию. Раньше это были бы три несвязанные записи в трех консолях, которые человек, возможно, связал бы между собой через неделю. На этот раз коррелятор связал их в единый инцидент, пометил соответствующими техниками атакующего, уже приложил идентичность и владельца хоста — и поднял инцидент, пока активность еще продолжалась, а не после ее ретроспективной реконструкции. Двухдневная археология, с которой начался проект, превратилась в одно оповещение.
