О разработке специализированных «озёр данных» для ИБ (Security Data Lake) говорят пока совсем немного. Они не входят в списки перспективных технологий по версиям аналитических агентств, таких как Gartner. Тем не менее это — не типовые хранилища данных. В будущем они могут стать инструментами, которые поднимут безопасность компаний на более высокий уровень.
- Введение
- Фундамент Security Data Lake
- Отличие Security Data Lake от Data Lake
- Основные возможности SDL
- Помехи для SDL
- SDL или SIEM?
- Вендоры SDL-решений
- Выводы
Введение
Отвечая на вопрос о путях развития корпоративных SIEM на одном из недавних эфиров AM Live, Евгений Зубов, технический директор центра компетенций компании Positive Technologies, выделил в качестве одного из главных направлений развития ИБ формирование новой сущности — Security Data Lake (SDL), «озера данных по безопасности». «В нём будут накапливаться все положительные индикаторы, собранные через SOC. Анализ этих данных с учётом контекста станет фундаментом для строительства надёжной ИБ в компании», — отметил он.
Такие «озёра данных» уже создаются в России. Например, Павел Гончаров, заместитель директора по развитию бизнеса Solar JSOC «РТК-Солар», относит к их числу комплекс ГосСОПКА, где накапливается информация о произошедших в стране инцидентах. Система даёт участникам информационного обмена необходимые сведения для защиты от компьютерных атак, направляя сообщения об уязвимостях в ПО и бюллетени по безопасности со сводкой актуальных угроз.
Что же такое Security Data Lake? Чем оно отличается от обычного облачного хранилища данных? Какие вендоры занимаются этим направлением? Попробуем ответить на эти вопросы.
Фундамент Security Data Lake
Очевидно, что концепция SDL базируется на традиционном понимании «озера данных» (Data Lake). Само появление концепции связывают со взрывным ростом объёмов собираемых данных и быстрым снижением стоимости их хранения. Gartner уже не рассматривает Data Lake как прорывную технологию и считает её скорее трендом в развитии технологий хранения (Cloud Data Warehouse).
Что такое Data Lake? Это — репозиторий для хранения больших объёмов данных в их оригинальном виде. Согласно определению Gartner, концептуальная модель Data Lake предусматривает набор экземпляров хранилищ различных информационных ресурсов, где активы хранятся в оригинальном (или почти оригинальном) формате и являются дополнением к рабочим массивам исходных данных.
Данные в «озере» могут быть структурированными, частично структурированными или неструктурированными, содержать таблицы, текстовые файлы, системные журналы (логи) и многое другое.
Рисунок 1. Тренды развития технологий хранения данных и СУБД (по Gartner)
Существует ряд ключевых различий между «озёрами данных» и «хранилищами данных». В частности, хранилища предназначены для структурированных, заранее подготовленных данных, а в «озере» применяемая технология не предусматривает приведения оригинального материала к той или иной «удобной» структуре. Такой подход обеспечивает многовариантность обработки для одних и тех же данных. В этом состоит главная ценность Data Lake.
Популярность концепции возросла после того, как специалисты по обработке и анализу данных стали отмечать, что при использовании хранилищ начинают возникать проблемы в решении новых задач. Предварительная обработка влечёт за собой потерю части материала, которую сначала могут считать «мусорной», но потом выясняют, что утраченные данные имели ценность. На больших объёмах информации эта проблема усугубляется.
Отличие Security Data Lake от Data Lake
Типовые корпоративные «озёра данных» содержат неструктурированные данные. Это могут быть сведения о продуктах компании, её финансовые и отчётные показатели, данные о клиентах и поставщиках, всевозможные маркетинговые материалы. Такие «озёра данных» легко масштабируются, их безопасность выстраивается на уже разработанных методиках, как для обычных хранилищ.
Концепция Security Data Lake имеет отличия. Кроме журналов ИБ-продуктов и алертов в таком «озере» содержится разнообразная сопутствующая информация, связанная с обеспечением безопасности: OSINT (Open Source Intelligence) — непубличные сведения, собранные из различных источников; оценка защищённости объекта, безопасности его периметра и возможных направлений атаки; информация о выстроенных средствах противодействия; данные о выявленных утечках; параметры идентификации существующих угроз, источники и векторы кибератак; разбор киберинцидентов и атрибуты атак; базы данных вредоносных программ, информация о репутации IP-адресов, журналы операций; информация об активности в даркнете.
Особенность Security Data Lake состоит в том, что этот централизованный репозиторий предназначен для управления журналами (логами) или другими источниками данных, которые имеют прямое отношение к работе по обеспечению ИБ. Накапливаемые в SDL данные из различных источников в дальнейшем используются вместе с инструментами анализа.
SDL создаётся для того, чтобы упростить доступ к оригинальным логам. Это необходимо для повышения эффективности проведения расследований. Централизация всех журналов в SDL упрощает расследование, сокращает объём необходимой работы по сбору логов из нескольких систем, гарантирует полноту данных.
Формально пользователь (офицер безопасности) может подключиться к различным источникам журналов и проанализировать их «на месте» и без SDL. Но на практике эта на первый взгляд простая задача превращается в трудноисполнимую из-за наличия сотен различных решений для хранения логов безопасности, многочисленных типов сетевых устройств. SDL автоматизирует подключение через API или иным способом, упрощая синтаксический разбор данных и автоматизируя сам процесс накопления информации.
Когда внутри компаний генерируется огромный массив сведений по мониторингу ИБ, традиционные SIEM часто не справляются с задачей сбора данных. Чтобы извлечь ценную информацию, службе ИБ требуется централизовывать данные в локальных, облачных и SaaS-средах, а затем осуществлять аналитический разбор. К тому же в настоящее время многие задачи приходится выполнять вручную. Концепция SDL позволяет реализовать это через автоматизацию.
Рисунок 2. Архитектура SDL-решения по версии Elysium Analytics
Основные возможности SDL
Можно выделить пять ключевых возможностей, которыми должны обладать SDL.
- Автоматизированный сбор и парсинг данных. Это — главный признак SDL. В организациях могут применяться различные системы защиты, сети, компьютеры и мобильные устройства. Сбор логов с каждого из них должен осуществляться автоматически, потому что только так можно обеспечить актуальность собираемых данных и возможность получения аналитики в режиме реального времени.
При оценке требуемой производительности SDL необходимо учитывать статистику для собственных систем. Например, как заявил во время эфира AM Live Андрей Арефьев, директор по информационным проектам компании InfoWatch, «типовая ИБ-система регистрирует в день до миллиона событий, которые попадают в SIEM для обработки. Сто тысяч операций среди них имеют “красный” уровень. Просмотреть это вручную нереально».
Впечатляющие цифры приводит также Евгений Зубов, технический директор центра компетенций компании Positive Technologies: «во время проведения киберучений мы регистрировали за каждый день до одного миллиарда событий, требующих обработки. Из них около 30 тысяч событий являлись срабатываниями по правилам корреляции. Это были явные признаки вторжения, требующие немедленной оценки и реагирования».
Автоматизация сбора данных осуществима, когда загрузка производится через API по определённым протоколам (Syslog, NetFlow, Cisco eStreamer и др.). Эти особенности должны быть учтены в будущем.
- Автоматизация загрузки контекста для журналов безопасности. Собранные данные требуют дополнительной информации — контекста для проведения аналитической обработки. Поэтому в SDL входит также функция обогащения данных контекстом.
Например, если кто-то подключается к корпоративной системе с неизвестного компьютера или из удалённого места, то ИБ может поставить на данную операцию запрет. Однако когда у компании появляются дистанционно работающие сотрудники, без контекста подобная блокировка становится нереализуемой. То же самое происходит при подключении к маршрутизатору Wi-Fi. Собирая с него логи, SDL должна добавить контекст: тип подключаемого устройства, его геолокацию и должность сотрудника авторизовавшего подключение.
- Разметка IP-адресов. Поскольку IP-адреса в корпоративной сети обычно назначаются динамически, один и тот же хост может иметь разные IP-адреса в разные моменты времени. Если в SDL нет механизма контроля IP-адресов по хостам, то отследить злоумышленников становится нереально. В этом случае не поможет даже избыточность собираемых логов.
- Анализ данных по ИБ и интерфейс отчётов. Важно понимать, что в ИБ и ИТ пользуются разными инструментами. Поэтому необходимо решить проблему их совместимости.
- Масштабируемая архитектура. Развитие сложности атак приводит к тому, что со временем приходится собирать всё больше данных от ИБ. Поэтому SDL должна обеспечивать масштабирование.
Масштабирование становится необходимостью также при активности регуляторов. Вводя новые законодательные предписания по срокам хранения данных, они сильно влияют на требуемые объёмы хранилищ.
Рисунок 3. Эволюция систем анализа сохранённых данных (по версии Elysium Analytics)
Помехи для SDL
В отличие от традиционных ИТ-систем, где формирование логов является вспомогательной функцией, для комплексов обеспечения ИБ логи являются частью их функционального аппарата. При этом для сферы ИБ характерно лицензирование по количеству пользователей. Это вызывает чрезмерный рост стоимости лицензий. В результате ИБ-команды иногда намеренно не собирают все доступные данные, которые могли бы быть полезны для защиты от кибератак. Отсутствие логов может стать причиной пропуска атаки.
Существенным фактором является также рост доли неструктурированных данных. По данным IDC, к 2025 году около 80 % всей накапливаемой в мире информации будет относиться к неструктурированным данным. Это сильно затрудняет поиск и анализ.
SDL или SIEM?
SDL и SIEM различаются прежде всего реализацией механизма проактивного поиска угроз.
SIEM — это информационная система, которая позволяет выявлять причины возникновения сигналов тревоги и служит для их устранения. SDL же рассматривается в большей степени как автономная система. Она собирает данные о защищаемом объекте и хранит информацию о возможных вариантах кибератак. Благодаря этому она может применяться для машинного обучения.
SIEM помогает проводить анализ уведомлений и помечать определённые события для дальнейшего расследования. Но все дальнейшие операции проводятся вне этого инструмента.
SDL может использоваться для поиска угроз и выявления их признаков через интерфейс запроса накопленной информации. Задача SDL — выявлять возможные угрозы, предоставлять по ним контекст, предсказывать сигналы, которых следует ожидать в случае начала кибератаки.
Вендоры SDL-решений
Российские облачные провайдеры, к сожалению, не упоминают об SDL в своих информационных материалах. На западном рынке таких вендоров уже несколько. Онлайн-издание eSecurity Planet выделяет прежде всего компанию Snowflake как лидера по данному направлению.
Elysium Analytics
Компания Elysium Analytics ведёт разработку набора сервисов (Security-Analytics-as-a-Service), которые позволяют применять машинное обучение для исследования безопасности. Имеются графические инструменты для анализа и ряд других функций. Разработка инструментов Elysium Analytics ведётся с опорой на SDL-хранилище Snowflake.
Рисунок 4. Набор инструментов Elysium Analytics для анализа данных по безопасности в SDL
Exabeam Data Lake
Компания Exabeam известна своим SIEM-решением. Теперь она дополнила его специальным инструментом лог-менеджмента, назвав новый продукт Exabeam Data Lake. Поддерживается интеграция с другими продуктами Exabeam (Cloud Connectors, Advanced Analytics и Security Intelligence Platform), что позволяет объединить возможности SDL и SIEM.
Gurucul Security Analytics and Operations Platform
Компания Gurucul занимается разработкой средств анализа лог-файлов и уведомлений. Создаваемая ею платформа Gurucul Security Analytics and Operations объединяет в один набор несколько собственных инструментов вендора. Эту платформу можно устанавливать поверх хранилищ других производителей, получая в итоге гибридное SDL.
Panther Security Data Lake
Компания Panther предоставляет инструмент Panther Security Data Lake для сбора журналов по безопасности и проведения парсинга, нормализации и анализа данных. В её арсенале — более 200 настраиваемых алгоритмов детектирования, написанных на Python. Решение Panther можно развернуть в облаке AWS или Snowflake, после чего оно будет автоматически отмечать подозрительные события, сохранять логи и сопутствующую информацию в «озере данных» на стороне клиента.
Snowflake Cloud Data Platform
Это — один из наиболее значимых ИТ-стартапов последнего времени в мире. Год назад, в сентябре 2020 года, Snowflake провела IPO и сумела заработать на нём 3,4 млрд долларов США. Её главным продуктом стала платформа Cloud Data, позволяющая хранить данные всех типов. Имеется ряд интересных функций для анализа, в том числе собственные решения компании для исследования кибербезопасности.
Varada
Платформу Varada можно подключить к уже имеющемуся Data Lake или другому виртуальному частному облачному решению. Задача платформы — обеспечить ускорение поисковых запросов при решении задач по ИБ.
По оценкам вендора, на типовые задачи поиска, такие как сканирование данных, сейчас тратится до 90 % вычислительных ресурсов. Платформа Varada позволяет устранить этот недостаток за счёт кеширования данных и применения более эффективного процесса поиска. По оценкам производителя, время поиска сокращается в 100 раз, затраты снижаются на 60 %.
Выводы
Специализированные «озёра данных» для ИБ, получившие название Security Data Lake, пока находятся на ранней стадии развития. Но уже появились первые продукты, которые обещают поднять безопасность компаний на более высокий уровень.
В российском сегменте это касается прежде всего «озера данных» ГосСОПКА. По мнению экспертов, она может стать очень полезным инструментом для каждого безопасника, помогающим быстрее выявить присутствие злоумышленника внутри организации. Развитие этого инструмента продолжается.
