Привет! Меня зовут Иван Прохоров, я руководитель продукта MaxPatrol SIEM. Мы продолжаем технологическое погружение в наш SIEM и сегодня расскажем об активоцентричности и хранении данных. А помогать мне в этом будет мой коллега, архитектор продукта MaхPatrol SIEM, Роман Сергеев.

В прошлой статье мы рассказали, как устроен MaхPatrol SIEM, взглянули на его пайплайн и поговорили про нормализацию и обогащение данных об инцидентах. Тогда же мы вскользь затронули тему активов и сегодня обсудим ее более детально. Разберемся, что такое цифровые активы, зачем они нужны, как их используют и защищают.

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

Что такое активы и почему все строится вокруг них

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

Изначально мы задумывали семейство продуктов MaхPatrol как экосистему, в которую будут входить продукты класса security information and event management (SIEM), vulnerability management (VM), endpoint detection and response (EDR) и др. Поэтому сразу решили выстраивать все вокруг активов, ведь одно и то же событие ИБ в зависимости от цели атаки и контекста может представлять разную угрозу.

Зачем нам нужен контекст и как с ним работать

Поскольку понятие контекста неразрывно связано с активами, давайте разберемся и с этой темой. Как разработчики SIEM мы понимаем, что наш продукт должен не просто регистрировать события и предлагать адекватные меры реагирования, но и собирать сопутствующую информацию об инциденте.

Чтобы проще понять, о чем идет речь, давайте обратимся к примеру. Представьте, что кто-то извне сканирует порты или пытается взломать учетку вашей организации перебором. Для специалистов по ИБ это вполне частая ситуация, поэтому обычно в таких случаях достаточно забанить некий блок адресов. Но все резко меняется, если та же самая активность исходит не откуда-то из-за периметра, а изнутри вашей корпоративной сети. Это уже серьезная угроза, и реагировать на нее нужно иначе. Подобную разницу между двумя технически аналогичными инцидентами мы и называем контекстом.

Если говорить о конкретных угрозах, выявить которые помогает знание контекста, то можно вспомнить атаки типа DCShadow. Ее цель — скомпрометировать протоколы обмена данными между контроллерами домена внутри Active Directory. Злоумышленник выдает себя за контроллер домена, внедряет некую информацию в базу данных, откуда она разлетается по другим контроллерам организации. Таким образом инфраструктура оказывается скомпрометирована, и хакер получает возможность для дальнейшего развития атаки. Сейчас выявление таких сценариев не представляет ничего сложного: как только вы замечаете, что действия, характерные для контроллера домена, выполняет не контроллер домена, сразу обратите на это внимание.

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

Чтобы как-то систематизировать весь этот обширный объем данных, контекст принято разделять на две группы: внешний и внутренний. Внешний контекст — это, как правило, информация из разряда threat intelligence и indicators of compromise, то есть информация о техниках и приемах злоумышленников. Как только система замечает определенные паттерны в поведении пользователя, которые ложатся на известные нам практики хакеров, срабатывает защита. С другой стороны, внутренний контекст тесно связан с активами — их значимостью, группами, атрибутами.

Теперь давайте посмотрим, как работа с активами и контекстом реализована на практике, и заглянем под капот нашего MaxPatrol SIEM.

MaxPatrol SIEM: технологии хранения данных

Что позволяет MaxPatrol SIEM защищать активы с учетом контекста? Главным образом — наличие полной информации об активах в базе данных и связь между активами и событиями, пассивный сбор данных об активах на основании событий/трафика. Не последнюю роль играет интегрированная в продукт встроенная база данных Fast Positive Tables. Рассмотрим все это подробнее.

Asset management

Итак, мы уже выяснили, что активы важны, а значит, наш SIEM должен хранить информацию о них и позволять с ней работать. MaxPatrol SIEM содержит данные о том, какие узлы в инфраструктуре являются контроллерами домена, и, если брать тот же пример с DCShadow, в случае атаки вам не составит труда обнаружить угрозу. Для этого мы используем PDQL-запросы, которые могут выглядеть примерно так:

<filter(Host.HostRoles.Role = 'Domain Controller') | 
select(Host.Fqdn as fqdn_temp, Host.@IpAddresses as ip, Host.@Id as id) | 
filter(not ip in [127.0.0.1/8, ::1/128])
>

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

Таблицы могут содержать любые данные, например, туда можно внести информацию об индикаторах компрометации, исключениях для работы экспертизы, туда же попадают сведения из внешних фидов threat intelligence и из упомянутой выше базы активов. А еще все это можно модифицировать правилами корреляции. Все, что нужно эксперту, — написать PDQL-запрос, оформить результат в виде табличного списка и установить его в SIEM. Дальше система будет максимально прозрачно и оперативно наполнять и синхронизировать эти списки — в том числе данными о том, что в инфраструктуре, например, появился новый контроллер домена.

Asset identity и немного магии

Частью ядра asset management является asset identity — соотнесение отдельных инцидентов с определенными активами. Как можно догадаться, в любой инфраструктуре происходит намного больше инцидентов, чем существует активов. Поэтому хороший SIEM должен уметь определять, к какому узлу относится то или иное событие. Зачем это нужно?

<<?xml version="1.0"?>
<Event
    xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}"/>
        <EventID>4624</EventID>
        <TimeCreated SystemTime="2015-11-12T00:24:35.079785200Z"/>
        <Channel>Security</Channel>
        <Computer>dc-05.company.com</Computer>
        <Security/>
    </System>
    <EventData>
        <Data Name="IpAddress">10.0.43.217</Data>
        <Data Name="IpPort">50090</Data>
    </Event

Выше пример с событием 4624, в которое вовлечено минимум два актива: первый зарегистрировал успешный логин, а второй послал запрос на аутентификацию. При этом один представлен IP-адресом, а другой — FQDN (полным доменным именем). Чтобы обработать этот инцидент, нужно понимать, что в каком виде представлено, отслеживать постоянные изменения и так далее. В нашем SIEM есть специальный сервис asset identity, который превращает адреса из событий и результатов сканирования активов в идентификаторы.

Мы не случайно упомянули сканы и события, ведь различия между ними тоже очень важны и обрабатывать их нужно по-разному. Так, событий в системе может происходить сотни тысяч в секунду, и, как правило, они содержат минимум информации. В то же время сканов приходит максимум пара тысяч в день, но все они достаточно «тяжелые» и содержат много данных. Поэтому в работе с ними MaxPatrol SIEM применяет две разные стратегии: продвинутую, но относительно медленную — для обработки сканов, и очень быструю, но более простую — для привязки событий.

Теперь переходим к той самой магии, благодаря которой происходит привязка событий. После того как сервис asset identity получает результаты сканирования, включается очень сложный запатентованный алгоритм идентификации, вычисления адресов, определения того, новый это актив или старый, обновления данных в базе и так далее. На выходе мы получаем информацию для идентификации актива в виде API или других сведений, способных в этом помочь. Конечно, при потоке в сотни тысяч событий нецелесообразно каждый раз обращаться к сложному API, поэтому в MaxPatrol SIEM есть специальный компонент resolver — он также обеспечивает доступ к asset identity, но значительно ускоряет процесс.

Fast Positive Tables

Разговор о контексте был бы неполным без рассказа про FPTA — Fast Positive Tables. Это наша собственная разработка, и на сегодня она является одной из самых быстрых баз для in-memory-данных. Мы активно используем ее внутри конвейера обработки событий, в том числе для кэширования запросов к базе активов.

Отдельно хочется отметить, что это открытое решение: любой желающий может получить доступ к исходному коду и начать туда контрибьютить. Более того, мы к этому активно призываем! ?

Пассивные детекты, или Сбор информации из «труднодоступных» мест

Как мы уже упомянули, MaxPatrol SIEM изначально разрабатывался как продукт, который должен поставлять информацию об активах. Было бы странно, если бы тут обошлось без каких-то отличительных особенностей, и они у нас есть.

Внутри нашего SIEM находится сервис, который отвечает за так называемые пассивные детекты и тем самым позволяет вытаскивать данные из «труднодоступных» мест. Зачем это нужно? Конечно, в идеале нужно собирать информацию активно, то есть сканировать активы буквально каждый час. Однако это очень дорого технически и с точки зрения организации, поэтому мы часто видим, что для многих пользователей просканировать активы хотя бы раз в неделю — уже большой челлендж.

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

1. Допустим, вы используете Dynamic Host Configuration Protocol (DHCP) и у ваших узлов периодически меняется IP. Благодаря нашему сервису MaxPatrol SIEM увидит события выдачи новой пары MAC/IP, и вы сможете обновить данные об активе и выдать ему новый адрес, а значит, избежать искажений и сбоев в привязке событий.

2. Вы просканировали актив и обнаружили в нем уязвимость. Служба ИБ начинает готовить патчи, но сколько ждать, никто сказать не может. Windows не перестает предлагать вам плановые обновления компонентов системы и логирует соответствующую информацию. Если у вас установлен наш SIEM, он заметит это событие, и вы сможете автоматически изменить список программ и обновлений к ним. Таким образом можно закрыть уязвимость даже без постоянного активного сканирования.

3. Возвращаясь к нашим любимым контроллерам домена: не всегда есть возможность сканировать их в активном режиме. Однако если вы можете собирать с них события, то уже по этим логам MaxPatrol SIEM поймет, что является контроллером домена, а что нет, и внесет информацию в базу.

Соответственно, даже без проведения активного сканирования вы можете начать выявлять атаки. Даже если пассивный детект не решает проблему, вам будет понятно, что в первую очередь сканировать.

Хранение данных в MaxPatrol SIEM и переход на собственную базу LogSpace

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

Разумеется, в MaxPatrol много наших собственных разработок, в частности все, что вы видите слева от Elasticsearch.

Но, как и все разработчики, мы спокойно относимся к использованию сторонних компонентов, например PostgreSQL или Oracle в случае традиционных баз данных. В то же время мы видим, что все лидеры списка Gartner используют для организации хранения данных о событиях свое проприетарное ПО. Наш SIEM в 2017 году был еще относительно молодым продуктом, поэтому на тот момент мы, как и другие новички на рынке, использовали Elasticsearch просто за неимением адекватной альтернативы.

Однако наш опыт эксплуатации Elasticsearch далеко не всегда был положительным: в первую очередь нас не устраивала ресурсоемкость. Нам кажется, что это общая беда СУБД, построенных вокруг полнотекстового индекса Apache Lucene, каким и является Elasticsearch: они очень медленно обрабатывают структурированные данные. Кроме того, нас настораживал вопрос лицензий, который тогда только витал в воздухе, а сейчас встал в полный рост.

С другой стороны, примерно в то же время, в 2017 году, Яндекс выпустил свое open-source-решение ClickHouse. Для многих тогда это стало глотком свежего воздуха: скорость работы, которую он демонстрировал по сравнению с другим опенсорсом, впечатляла. Однако и этот вариант нас не устраивал. Во-первых, потому, что на тот момент он не мог работать на инсталляции all-in-one без выделенного администратора, парка серверов и круглосуточной поддержки. А во-вторых, потому, что если со структурированными данными ClickHouse справлялся отлично, то, когда информация приходила в виде куска текста (а у SIEM это бывает нередко), все было уже не так радужно.

Так мы пришли к пониманию, что нам нужно решение, которое:

• Будет способно одинаково быстро обрабатывать структурированные и неструктурированные данные. Здесь мы удачно ухватились за ClickHouse в качестве форка, поскольку тоже были под впечатлением от его скорости. На данный момент кодовая база отличается уже на 70–80%.

• Обладает низкой ресурсоемкостью. По своему опыту можем сказать, что стоимость системы хранения данных (СХД) и серверов в случае Elasticsearch составляет весьма заметную часть бюджета внедрения SIEM.

• Имеет встроенный SQL. Другие вендоры вроде Mongo и Elastic принесли собственные json-based-запросы, но это непривычно и неудобно. В конечном итоге они были вынуждены «прикручивать» к своим решениям интерфейсы, подобные SQL, которые все равно работали не так, как надо. Поэтому мы решили, что нам нужно изначально добавить в свой SIEM SQL.

• Может автоматически адаптировать движок хранения под специфику конкретных данных. Настройки «из коробки», даже самые продуманные, покроют не больше 80–90% всех возможных кейсов. При этом остаются другие ситуации, когда инфраструктура клиента устроена не так, как мы задумали при создании своего продукта. Как вендор мы это прекрасно понимаем, а также не можем рассчитывать, что у клиента в штате будет продвинутый эксперт, который сам сможет что-то подтюнить. Поэтому хотелось бы, чтобы пользователю реже приходилось обращаться в поддержку.

Но, как говорится, критикуешь — предлагай! Поэтому давайте посмотрим на реализацию нашего собственного решения LogSpace и его преимущества.

Собственная СУБД: преимущества LogSpace в теории и на практике

Начать лучше с примера по мотивам настоящего события:

Как видно, изначально событие приходит в базу в виде таблицы или, как еще говорят, «кортежа». В его колонки входит поле с временем, уникальный идентификатор UUID, Subject, ID сообщения в виде enum и некоторые другие. Собственно говоря, поэтому такие СУБД и называют колоночными.

Далее все зависит от движка хранения, например данные могут сохраняться на диск в таком же виде, как на картинке выше. Даже с учетом оптимизации и повышения степени сжатия информация будет храниться большим непрерывным куском. По нашему опыту, за сутки в SIEM может прийти около миллиарда таких событий. А теперь представьте, что вам нужно хранить их на протяжении полугода… Получается, что в базе придется держать почти 200 млрд таких записей. Отсюда и появляется безумный бюджет на СХД, который изо всех сил хочется оптимизировать.

Что происходит с этими же данными в LogSpace? Они делятся на части, каждая колонка хранится отдельно: никакого секрета здесь нет, все прозрачно — любой пользователь нашего SIEM может зайти в папку data и посмотреть, как хранится эта информация. Каждый атрибут лежит в отдельном файле — это позволяет использовать специфику данных соответствующего типа и наполнения, чтобы хранить их максимально эффективно.

Разберем разные колонки из нашей таблицы.

Например, в систему попало сто тысяч событий, у каждого есть поле TIME с TIMESTAMP внутри. Скорее всего, их время попадания в SIEM отличается на несколько минут или часов, но если мы отводим на хранение информации о времени 8 байт, то разница окажется совсем незначительной — буквально в последних 3 байтах. Зная это, мы можем достаточно сильно сжать данные и сэкономить место на диске. Для этого существуют различные техники, в частности дельта-кодирование, XOR — не будем здесь подробно на них останавливаться.

Другой случай — поля типа enum. Как видно из названия, они сохраняются в виде чисел произвольной длины. Если мы знаем, что у нас есть, скажем, десять значений, то можно хранить их с эффективностью в несколько бит на каждую запись.

Наконец, наше любимое — колонка body. Как правило, это самые сырые данные, с хранением которых традиционные колоночные базы справляются, мягко скажем, не очень хорошо. Здесь мы применили другую технику оптимизации: поскольку в случае body мы имеем дело с текстом, то сразу подумали об алгоритме словарного кодирования. Однако текст в сообщении очень короткий, типичный размер события 1 Кбайт — в таких условиях вы просто не успеете построить словарь, чтобы начать его эффективно использовать. И тут нам на помощь приходит возможность объединять информацию из отдельных колонок в большие блоки. Для каждого такого блока вы делаете общий словарь, который отлично работает.

Бывает и такое, что колонка не подходит ни под один известный нашему SIEM тип данных. Как правило, это ахиллесова пята всех колоночных СУБД, когда в поле находится некое уникальное значение. Мы научили наш LogSpace распознавать это и на ходу менять алгоритм действий, вплоть до того, что иногда лучше ничего не делать и просто подсветить нетипичное поле, чтобы не тратить процессорное время.

Согласно нашим собственным замерам, плотность хранения в LogSpace в 6 раз превосходит Elasticsearch и примерно в 2 раза выше плотности хранения в актуальной версии ClickHouse.

Развитие технологий как путь к результативному SIEM

Когда мы задумывали внедрить в MaxPatrol SIEM все эти технологии хранения и обработки данных, нашей целью было создать результативный SIEM исходя из собственного опыта работы с базами данных.

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

Иван Прохоров

Руководитель продукта MaxPatrol SIEM

Роман Сергеев

Архитектор продукта MaхPatrol SIEM