Проблема: два десятилетия логгирования в глобальном масштабе
Atlassian — глобальный SaaS-провайдер, обслуживающий 350 000 клиентов. Это результат 20 лет роста и долгого списка поглощений, каждое из которых привнесло собственные форматы логгирования. В результате появился конвейер данных безопасности, поглощающий 44 миллиарда событий в день без какого-либо общего языка для различных источников логов.
«У вас есть самые разные временные метки, проприетарные схемы, а также операционные издержки для любого, кто пытается организовать и структурировать эту информацию», — поясняет Закари Шмербер (Zachary Schmerber), старший инженер по логгированию безопасности в Atlassian и один из мейнтейнеров схемы OCSF. Аналитики тратили массу времени на нормализацию данных после их поступления, межплатформенная корреляция была ограничена из-за того, что данные находились в разных местах и имели разную форму, а конвейеры SIEM не успевали за нагрузкой.
Команде требовался способ объединить фрагментированную телеметрию в едином месте и разобраться в ней, сохранив при этом гибкость и избежав привязки к конкретному поставщику.
Решение: открытая схема в озере данных безопасности
Ответом Atlassian стала стандартизация всего на базе Open Cybersecurity Schema Framework (OCSF) и создание озера данных (lakehouse) на платформе Databricks.
OCSF победил, поскольку это был единственный вариант, который команда сочла полностью открытым. По сравнению с альтернативами вроде ECS или UDM, он предложил строго типизированную схему с надежной валидацией, которая минимизирует двусмысленность после трансформации, хорошую эффективность сжатия, расширяемость и открытое сообщество (при поддержке Linux Foundation и с перспективой международной стандартизации). Примерно 40 000 полей поначалу казались пугающими, но эта избыточность оказалась главным достоинством платформы, так как семантический контекст остается вместе с данными.
«Расследования, в которых один запрос может охватывать множество различных источников данных, стали возможны благодаря тому, что данные структурированы», — говорит Шмербер. «Возможно, в вашей системе работает пять сканеров уязвимостей. Теперь у вас есть один набор данных вместо пяти».
Databricks оказалась естественным выбором платформы. Нативные ACID-транзакции значительно упростили миграцию между версиями схем без нарушения работы потребителей ниже по потоку; автомасштабируемые кластеры Spark справились с общими высокоинтенсивными рабочими нагрузками; кроме того, платформа была создана для управления инфраструктурными издержками крупной организации, состоящей из множества команд. Atlassian сознательно выбрала ETL вместо ELT — трансформацию данных «на лету» — чтобы обеспечить обнаружение в реальном времени, сохранить независимость от вендоров и сжимать данные по мере их прохождения через конвейер.
Оптимизация таблиц обеспечила впечатляющий прирост производительности. Благодаря структурированным данным OCSF партиционирование и Z-ORDER позволили сократить время выполнения типичного запроса примерно с 45 секунд до 2–3 секунд — улучшение на 95% при сопоставимом приросте на более крупных запросах. Использование кластеров Graviton с Photon сократило стоимость и время выполнения запросов примерно на две трети.
Типобезопасность: внедрение схемы в код
Определяющим инженерным решением стало внедрение всей схемы OCSF в структуры Go — то, что команда называет «TypeGo». Поскольку схема находится в системе типов, корректность гарантируется на этапе компиляции.
«Каждый раз, когда вы создаете новый лог OCSF, он предварительно валидирован, поскольку он просто не может быть ничем иным, кроме OCSF», — отмечает Шмербер. Вложенные объекты являются нативными, развертывание может осуществляться где угодно, а для всего написаны модульные тесты. Что особенно важно, такая типобезопасность также обуздала ИИ: когда команда автоматизировала трансформацию с помощью агентского рабочего процесса, жесткая схема резко сократила количество галлюцинаций и снизила расход токенов, поскольку агент не мог создавать неверные маппинги и совершать циклы из ошибочных итераций.
От «маппинга как услуги» к платформе самообслуживания
Самой масштабной трансформацией стали изменения в операционных процессах. Команда дата-инженеров безопасности в Atlassian начинала с шестиэтапной ручной процедуры сбора логов, их преобразования в TypeGo, маршрутизации, тестирования, конфигурации и отправки через PR. Со временем они автоматизировали практически все эти процессы и в итоге передали их заказчику в виде платформы самообслуживания.
Теперь аналитик определяет нужные логи и предоставляет канонический датасет. После подтверждения через шлюз рабочий процесс сканирует фреймворк внутри структур Go, генерирует маппинги и DAG, тестирует их локально, развертывает канареечную конфигурацию через PR, выполняет валидацию в масштабе в канареечной среде и — после периода стабилизации — переносит изменения в продакшн, уведомляя пользователя о любых ошибках. Регрессионное тестирование блокирует любые некорректные изменения до их попадания в продакшн.
Инструментарий включает IDE для маппинга схем и библиотеку Go OCSF с открытым исходным кодом, обладающую повышенной производительностью валидации, автоматической обработкой немаппированных полей, вспомогательными инструментами схемы (IP-пути, нормализация) и интеллектуальной маршрутизацией. Результатом стали минимальные издержки на онбординг: «Теперь я могу поручить аналитику SOC выполнять работу ведущего дата-инженера в продакшн-среде», — говорит Шмербер, при этом каждое изменение по-прежнему проходит ревью.
Ускорение поразительно: «У меня ушел год на маппинг примерно трети данных, которые мы замаппили сегодня, — отмечает Шмербер, — и два месяца на маппинг остальных двух третей».
Более эффективное обнаружение: от точечных алертов к сигналам
Для команды обнаружения и реагирования стандартизация изменила подход к написанию алертов. «Принятие схемы OCSF позволило нам трансформировать конвейер обнаружения угроз, перейдя от однократных (one-to-one) алертов к методологии обнаружения на основе сигналов и рисков, при которой множественные находки (findings) объединяются в единый алерт», — рассказывает Джордан из команды обнаружения и реагирования Atlassian.
Используя кастомный инструмент под названием Alert Explorer, находки группируются вокруг стандартизированных значений OCSF — например, единого значения actor.user, которое остается идентичным независимо от того, появляется ли оно в событии аутентификации или сетевом событии. Такая согласованность позволяет команде стандартизировать кластеризацию, обогащение и триаж: вместо обогащения для каждого правила обнаружения они каждый раз вызывают API обогащения для стандартизированного имени пользователя.
«OCSF значительно упростил написание правил обнаружения и предоставление более содержательных, применимых на практике алертов, — говорит Джордан, — в которые аналитики могут глубоко погрузиться независимо от того, откуда поступили данные».
Влияние
Помимо громких цифр по затратам и производительности, стандартизация открыла возможности, которые ранее были непрактичными: многодоменная корреляция с надежным разрешением сущностей, эффективная аналитика поведения пользователей и межприложенияй анализ паттернов. Поскольку все используют единый язык, команда может писать простые запросы для выявления аномального поведения сразу на пяти разных роутерах или в пяти сканерах уязвимостей. Дашборды стали значительно проще, так как классы OCSF используют общие объекты, а хранилище было оптимизировано благодаря четкому пониманию того, какие данные нужно сохранять, а какие отбрасывать.
Что дальше: общение с вашими данными
Шмербер больше всего воодушевлен тем, какие возможности для ИИ открывает семантически богатая схема. «Как можно общаться со своими данными, если у вашего агента нет контекста? Он будет галлюцинировать и выдавать неверный ответ», — отмечает он. Поскольку OCSF содержит определения внутри самой схемы, помощь агентов становится гораздо более точной.
Дорожная карта включает обучение навыкам, позволяющее преобразовывать реальный опыт аналитика в полевых условиях в многократно используемые навыки агентов, оркестрацию агентов, способных проводить поиск угроз с учетом нужного контекста, контекстный SQL, способный отвечать на вопросы вроде «где в этой схеме мой DNS C2-трафик?», а также контекстные графы, построенные на базе OCSF. Более долгосрочная цель носит семантический характер: сделать OCSF канонической отправной точкой, которую излучает все, а не моделью, объединяющей данные постфактум. Команда также продолжит улучшать производительность запросов, рассматривая переход на Liquid Clustering для секционирования данных в таких средах, как корпоративные устройства и облако.
