Введение и проблематика

В информационной инфраструктуре крупных организаций генерируется огромный объём данных: события безопасности средств защиты и оконченных устройств, события работы инфраструктурных сервисов, результаты сканирования уязвимостей, корреляционные события SIEM-систем, записи об инцидентах ИБ, данные инвентаризации активов, информация из Active Directory и LDAP каталогов, сведения об индикаторах компрометации, белых и черных списках и множество иной информации из различных источников данных. При этом каждый источник обладает собственной структурой, форматом выгрузки и периодичностью обновления данных.

На практике в большинстве организаций работа с этими данными при анализе информации выглядит одинаково: аналитик вручную выгружает данные из каждой системы, сводит их в электронные таблицы Excel, пытается сопоставить данные и построить аналитические отчеты. Этот процесс занимает колоссальное количество времени от нескольких часов до нескольких дней, при этом результат устаревает сразу после выгрузки данных.

Ключевые проблемы

• Разрозненные источники данных: каждая система хранит данные изолированно. Нет единой точки доступа к данным.
• Excel: электронные таблицы — основное средство агрегации. При сотнях тысяч строк — ошибки и невозможность масштабирования. Разрозненные файлы, данные которых устаревают после выгрузки.
• Отсутствие историчности данных: невозможно оперативно отследить динамику изменения данных, например количество устраненных уязвимостей, изменения параметров устройств, учетных записей и прочее.
• Время на анализ данных: от запроса до ответа — дни или даже недели. Критично для процессов реагирования на инциденты ИБ и управления уязвимостями.

В типичной информационной инфраструктуре количество источников данных информационной безопасности исчисляется десятками. Сканер уязвимостей генерирует от десятков тысяч до миллионов записей, SIEM обрабатывает миллиарды событий в сутки от активности пользователей и сервисов, количество устройств в инфраструктуре и их свойства постоянно меняются. Объекты в зависимости от типа в различных источниках данных могут быть представлены по-разному: как hostname, FQDN, IP-адрес, MAC-адрес, серийный номер, заводской номер, имя пользователя, его синоним, и так далее. Объединить все данные в одном месте непростая задача.

Для нашей команды информационной безопасности это был вызов, мы не хотели тратить десятки часов на анализ и поиск нужной информации. Мы решили сразу все проблемы, создав озеро данных информационной безопасности (SDL).

Решение: Security Data Lake

Ответом на проблемы стало создание озера данных информационной безопасности (Security Data Lake, SDL) — централизованной аналитической платформы данных, объединяющей все данные ИБ в единое хранилище.

Ключевой принцип: все данные, все метрики, все состояния объектов — в одном месте. Полный отказ от Excel. Обеспечение DataDriven подхода во всех процессах ИБ.

Технологический стек

Архитектура SDL

Архитектура выстроена по принципу многослойной обработки (layered data architecture). Данные проходят последовательные этапы от извлечения данных из источника до преобразования и презентации в виде аналитических витрин данных под различные задачи и потребности.

Airflow (ETL / ELT)

Apache Airflow — центральный оркестратор. Каждый источник обслуживается отдельным DAG (Directed Acyclic Graph): подключение, извлечение, валидация данных, нормализация данных, пробразование, отправка данных в Kafka. Airflow также обеспечивает контроль схемы данных и отслеживает версионность схемы, в случае изменения схемы осуществляет оповещение специалистов, одновременно сохраняет версию схемы источника и отправляет мета данные об источнике в каталог данных.

Разработан собственный стандарт создания DAG:

• Единая структура директорий, именования DAG-файлов и функций
• Обязательные этапы: извлечение (extract) → валидация (validate) → нормализация (normalize) → преобразование (transform) → загрузка (load, publish)
• Стандартизированная обработка ошибок при совершении повторяющихся операций
• Контроль изменения схемы данных источника
• Автоматическое формирование мета данных в каталоге данных
• Оповещение при сбоях и журналирование всех событий

Для потоковой обработки событий, их фильтрации, нормализации и обогащения мы используем Vector с его языком обработки VRL (Vector Remap Language). Vector позволяет принимать данные от источников, которые не умеют отправлять события напрямую в Kafka, также одновременно события обогащаются дополнительной мета информацией из централизованных справочников, сокращая в дальнейшем время на обработку. Vector позволяет также обеспечить T (transform) преобразовывая события под наши требования и шаблоны.

Vector и Airflow развернуты с возможностью горизонтального масштабирования, балансировки нагрузки, что повышает отказоустойчивость ETL / ELT потоков.

Apache Kafka (шина данных)

Apache Kafka — единая шина данных и буфер. Данные в Kafka от всех источников поступают в сыром виде (raw), сохраняя оригинальный контекст и мета информацию об источнике данных. Если потребитель не может вычитать данные из соответствующего топика, данные в нем сохраняются в течение определенного времени для возможности вычитать данные позднее без потери важных данных.

Преимущества Kafka как единой шины:

• Производители и потребители независимы друг от друга, данные возможно загружать и читать с разной скоростью, достаточно сделать сетевой доступ до Kafka
• Буферизация позволяет сглаживать пиковые нагрузки и не потерять важные данные и события, если потребитель не смог вычитать данные вовремя
• При сбоях и ошибках возможно перевычититать данные за определенный период
• Масштабирование, кластерное решение, возможность партиционирования топиков

ClickHouse (хранилище данных)

ClickHouse — колоночная СУБД, которая обеспечивает высокую производительность, эффективное сжатие, быструю вставку и чтение миллионов строк. В качестве основного хранилища данных мы решили использовать ClickHouse отказавшись от других решений.

Преимущества ClickHouse:

• Быстрая вставка миллионов строк
• Возможность масштабирования, возможность создания внутри кластера удобных слоев данных
• Единые подходы к различным слоям хранилища
• Возможность устанавливать время жизни данных TTL как для отдельных таблиц, так и колонок
• Быстрая аналитика данных и агрегация налету, используя встроенные возможности
• Сжатие данных, данные занимают до 10 раз меньше места

ClickHouse позволяет нам организовать хранилище как мы хотим, разделить кластер так, чтобы распределить нагрузку между узлами кластера, обеспечив быструю вставку миллионов строк данных и одновременное чтение, а также обеспечить различное время хранения данных. Главное не перегружать хранилище излишними JOIN запросами, правильно настроить индексы и хранение . Основное требование: данные должны быть доступны сразу (меньше 3-10 секунд). Если на извлечение данных требуется больше времени, значит они не были заранее обработаны или не верно агрегированы, для них неверно установлены индексы, skip индексы, bloom фильтры и так далее.

Часто используемые типы таблиц ClickHouse:

MergeTree - стандартный тип таблиц. Почти все сырые и историчные таблицы построены на данном типе.

ReplacingMergeTree - движок для актуального состояния. Данный тип таблицы позволяет формировать справочники или сохранять уникальные записи по определенным свойствам или признакам.

AggregatingMergeTree - агрегационные данные и метрики, которые автоматически обновляются при вставке данных.

Стандартизация хранилища, таблиц, интеграция ClickHouse c Openmetadata позволяет вести каталог данных (данные о данных) полностью в автоматизированном виде, визуализируя прохождение данных от источника, учитывая все промежуточные таблицы и витрины данных, до конечных дашбордов и чартов в BI системе.

Сопоставление данных

Одна из сложнейших задач - сопоставление записей из разных источников, описывающих один объект и дальнейшая идентификация объекта в витринах данных. Мы используем UUID7 в качестве уникального идентификатора для всех объектов. UUID7 содержит метку времени, что позволяет нам вовремя находить ошибки, если они были допущены. В качестве примера виртуальная машина в различных источниках данных может быть представлена в виде IP-адреса в сканере уязвимостей, FQDN в Active Directory, hostname в событиях аудита, серийным или заводским номером в CMDB и прочих учетных системах.

Именно единый принятый нами для всех объектов идентификатор UUID7 (SDL_ID) позволяет объединить все другие идентификаторы объекта, обеспечивая сквозную аналитику и идентификацию в различных таблицах, витринах данных и справочниках.

Решение практических задач с помощью SDL

Важным процессом информационной безопасности является процесс управления уязвимостями. Разберем практическое применение SDL на данном процессе. В каждой информационной инфраструктуре существуют десятки тысяч уникальных уязвимостей, из них несколько сотен и даже тысяч являются уязвимостями критического уровня. До SDL приоритезация устранения строилась на оценке CVSS (Common Vulnerability Scoring System) — формальной метрике, без учёта контекста инфраструктуры, результаты сканирования выгружались в Excel и далее в ручном режиме анализировались. На анализ данных уходило несколько недель, что было болью ответственных за процесс исполнителей. Кроме того невозможно было управлять данными в моменте, фильтровать по автоматизированной системе или отдельной уязвимости.

Какие возможности дал SDL для процесса управления уязвимостями:

• Аналитика приближенная к реальному времени (в зависимости от скорости сканирования инфраструктуры сканером)
• Возможность получать сведения об уязвимостях без сканирования
• Возможность делать любые срезы данных и агрегировать данные под конкретную задачу
• Реализовать гибкое управление процессом, устанавливая приоритеты в зависимости от важности информационного актива, автоматизированной системы и т.д
• Видеть уязвимости сразу, как сведения о них были опубликованы
• Автоматизировать процесс контроля за устранением уязвимостей
• Полную историчность данных и динамику устранения за все время
• Построить скоринговую модель защищенности для каждой системы

Множество справочников, сведения об уязвимостях и аналитика в реальном времени сделали процесс управления уязвимостями прозрачным, гибким и автоматизированным. Теперь процесс стал опираться на точные данные, фокусируясь на устранении важных уязвимостей, повышая киберустойчивость информационной инфраструктуры.

SDL позволил реализовать DataDriven подходы в большинство процессов информационной безопасности, сократив время на анализ данных, высвободив время у сотрудников на другие важные задачи.

Выводы и результаты

Проблема разрозненных данных ИБ не решается добавлением новых инструментов — она решается только на уровне архитектуры данных. Главное чтобы озеро данных не превратилось в болото.

Количественные результаты

Общий вывод

Система SDL стала единой платформой данных информационной безопасности, на которую опираются процессы анализа, приоритизации и принятия решений.

Внедрение SDL позволило:

1. Сократить время на анализ уязвимостей, угроз, сведений об устройствах и инцидентов в десятки и сотни раз, позволяя строить сквозную аналитику по любым данным
2. Реализовать дашборды, которые позволяют сотрудникам ИБ вручную анализировать данные и получать результат мгновенно
3. Создать микросервисы, которые используя витрины данных, оповещают об отклонениях в работе, отсутствии данных или аномальных значениях
4. Создать модели машинного обучения для поведенческого анализа.