Представьте ситуацию: вы потратили много времени на написание и отладку правил корреляции, а через день обнаружили, что они не работают. Как говорится, такого еще не было и вот снова! Позже выясняется, что ночью сеть еще раз модернизировали и заменили пару серверов, но правила корреляции это не учитывают. В этой статье мы расскажем, как научить ваш SIEM адаптироваться к постоянно меняющейся инфраструктурной среде.
Мы приближаемся к завершению серии статей, посвященных созданию адаптивных правил корреляции, работающих «из коробки».
Статья получилась длинная, желающий может сразу перейти к выводы .
В статье «Методология нормализации событий» Мы обобщили методы, которые помогут минимизировать проблему потери данных и неправильной нормализации исходных событий.
Однако можем ли мы сказать, что если уменьшить роль ошибок нормализации, то можно создать правила корреляции, работающие «из коробки»? Теоретически да, если бы контролируемый SIEM объект мониторинга был статическим и работал исключительно так, как написано в технических характеристиках.
Но на практике оказывается, что в реальном мире нет ничего статического.
Итак, давайте более подробно рассмотрим объект мониторинга.
SIEM собирает журналы из источников, из которых извлекает IP-адреса, учетные записи пользователей, доступ к файлам и ключам реестра, а также сетевые взаимодействия.
Если суммировать все, то это не что иное, как информация об этапах жизненного цикла автоматизированной системы (далее АС).
Таким образом, объектом SIEM-мониторинга является автоматизированная система в целом или какая-то ее часть.
Система не является статичным объектом, она имеет свойство постоянно меняться: вводятся новые рабочие станции и серверы, старое оборудование выводится из эксплуатации и заменяется новым, системы «падают» из-за ошибок и восстанавливаются из резервных копий.
Динамика на сетевом уровне, например динамическая адресация или маршрутизация, меняет облик сети каждый день.
Как я могу это проверить? Постарайтесь найти полную и актуальную схему сети L3 в вашей компании и уточните у сетевых администраторов, насколько она отражает текущее положение дел.
При разработке правил корреляции старайтесь исходить из того, как выглядит АК здесь и сейчас.
Тестируя правила корреляции, вы уточняете их до состояния, в котором они способны работать с наименьшим количеством ложных срабатываний в текущей конфигурации AS. Поскольку АС постоянно меняется, правила корреляции рано или поздно придется обновлять.
Теперь усложним задачу и рассмотрим правила, предоставляемые внешними экспертами, например, коммерческими SOC, интеграторами, внедряющими SIEM, или самими разработчиками SIEM-решений.
Эти правила не включают в себя возможности вашей AS — контекст выполнения — они под них не оптимизированы.
Эта проблема является еще одним камнем преткновения в концепции правил корреляции, которые работают «из коробки».
Решением может быть то, что SIEM внутри себя:
- Строит модель наблюдаемой АС.
- Всегда поддерживает эту модель в актуальном состоянии.
- Позволяет использовать эту модель в качестве контекста выполнения в правилах корреляции.
Важно, чтобы при внедрении информационных технологий с данными работали персонал (пользователи) и средства автоматизации.
Поскольку SIEM собирает информацию из множества различных источников, включая ИТ-инструменты, средства информационной безопасности и бизнес-приложения, все части этого определения будут «видны» нам непосредственно в событиях.
Далее мы расскажем, как выглядит модель, созданная для таких сущностей, как пользователь, набор средств автоматизации (далее сеть и вычислительные системы) и данные.
К сожалению, моделирование технологических процессов в рамках SIEM достаточно сложно, поскольку данный класс решений для этого не предназначен.
Тем не менее, некоторые процессы видны через модели поведения этих сущностей.
Общая модель динамика
Далее мы рассмотрим каждую сущность и подробно остановимся на:
- уникальная идентификация;
- состав модели;
- поиск данных, необходимых для модели;
- характер изменений данных объекта;
- обновление данных в модели при их изменении.
Модель пользователя
Идентификация
Под пользователем АС следует понимать конкретного человека: сотрудника компании, подрядчика или фрилансера.Важно, чтобы он имел авторизованный доступ к говорящему.
Информация о пользователях АС, как правило, фрагментарно разбросана по многим системам.
Чтобы собрать его, потребуются некоторые усилия.
Давайте рассмотрим на примере, где и какую информацию можно собирать для конкретного пользователя.
- Microsoft Active Directory и Microsoft Exchange. Из них мы можем узнать его основной доменный логин и адрес электронной почты.
- Cisco Identity Services Engine (ISE) хранит его второй логин для удаленного доступа через VPN.
- Во внутренней базе данных портала хранится его третий логин.
- Если пользователь является администратором базы данных, то в СУБД хранится его четвертый логин, а может и больше одного.
- База данных HR, в которой хранится его ФИО (на случай, если поленились создать пользователя в Active Directory по всем правилам).
Подведем итоги:
- В SIEM необходимо иметь один идентификатор пользователя.
- Когда учетные записи пользователей появляются в любом журнале, в любой системе, мы должны однозначно идентифицировать их и указать свой собственный единый идентификатор пользователя.
Состав модели
Создавая модель любой сущности, мы делим ее на два блока.Первый блок используется для хранения общей информации о сущности, второй отвечает за составление модели поведения сущности.
Этот профиль может использоваться правилами корреляции для выявления аномальных отклонений в поведении сущности.
Как минимум, общая модель пользователя должна включать в себя:
- единый идентификатор пользователя в SIEM;
- все его идентификаторы из различных систем, в том числе:
- внешние и внутренние адреса электронной почты;
- ПОЛНОЕ ИМЯ;
- локальная учетная запись в ОС;
- учетная запись домена;
- учетная запись доступа к VPN;
- Прокси-аккаунт;
- учетные записи СУБД;
- учетные записи в других прикладных системах.
- Организационная единица в Microsoft Active Directory, к которой принадлежит пользователь;
- группы в Microsoft Active Directory, к которым принадлежит пользователь.
- тип используемого подключения (локальное, удаленное) и тип канала связи (проводной, беспроводной);
- устройства, используемые для доступа к корпоративной сети;
- используемые приложения;
- географическая привязка, особенно для удаленных пользователей;
- ресурсы компании, к которым подключается пользователь;
- кому и какие данные он передает (информационные потоки).
Модель пользователя Профилирование информационных потоков — сложная задача, для решения которой в SIEM зачастую нет удобных и простых механизмов.
Но вы можете начать создавать такой профиль со своей электронной почтой и общими сетевыми ресурсами.
Источники данных для модели
Откуда вы берете данные, необходимые для построения модели? Давайте рассмотрим два основных принципа получения информации, доступных в большинстве SIEM, — активный и пассивный методы сбора.В активный путь SIEM сам обращается к источникам, содержащим данные, необходимые для построения модели.
В пассивный способ модель заполняется на основе данных о событиях, поступающих в SIEM от источников.
Как правило, для получения наиболее полной модели лучше комбинировать два метода.
Важно понимать, что данные, собранные в модели, должны постоянно обновляться и делать это нужно автоматически, а не вручную.
Для обновления данных подходят точно такие же методы, которые используются для их первоначального сбора.
Рассмотрим, какие источники могут предоставить данные для построения модели и какими способами из них можно получить необходимую информацию.
Для общей модели 
Для поведенческой модели 
Модель сетевых и вычислительных систем
Идентификация
Под элементами сетевых и вычислительных систем подразумеваются рабочие станции, серверное и сетевое оборудование, средства защиты информации.На данный момент в SIEM и решениях по управлению уязвимостями они называются активами.
Кажется совершенно очевидным, что такие активы можно легко идентифицировать по IP-адресу, MAC-адресу, полному доменному имени или имени хоста (далее именуемые исходными идентификационными ключами).
Всегда ли это так? Как указано выше, в АС постоянно происходят какие-то изменения.
Давайте посмотрим на некоторые из этих изменений и подумаем, как ведут себя наши исходные идентификационные ключи.
- Используйте в сети DHCP. IP-адреса активов меняются.
- Переключение узлов в конфигурации кластера.
В зависимости от типа кластеризации MAC и IP могут меняться.
- Восстановление системы из резервной копии на другом сервере в связи с критическим сбоем.
MAC-адреса, иногда IP, полное доменное имя и имя хоста меняются.
- Плановая замена, модернизация оборудования или части акустической системы.
Почти все ключи можно заменить.
Поскольку для идентификации актива вы не можете полагаться на IP, MAC, FQDN или имя хоста отдельно, вы можете попытаться идентифицировать актив, используя все 4 параметра одновременно.
Здесь мы сталкиваемся с глобальной проблемой: SIEM оперирует событиями, а они почти никогда не содержат все исходные идентификационные ключи одновременно.
Как это можно решить? Давайте рассмотрим несколько вариантов:
- Активный метод с использованием решений уровня базы данных управления конфигурациями (CMDB).
.
Информацию об оригинальных идентификационных ключах можно взять оттуда.
Но содержит ли CMDB все ключи источников активов, необходимые для идентификации? И, самое главное, учитывает ли он описанные выше ситуации по изменению АС? Также важно учитывать время обновления данных в CMDB, если данные отстают от фактического состояния системы на десятки минут или часов – скорее всего, такое решение не подойдет для использования при потоковой корреляции событий в СИЕМ.
- Активный способ использования решения по управлению уязвимостями .
Его отчеты можно выгружать в SIEM, как это делает, например, Microfocus ArcSight. Но есть ли гарантия, что сторонний сканер принесет все необходимые для идентификации данные? Насколько они будут актуальны, если сканирования будут проводиться не чаще раза в месяц (среднее значение для крупных компаний) и не охватят всю инфраструктуру.
- Пассивный способ .
Выявите активы из событий, несмотря на их неполноту и неточность данных.
События не содержат всех ключей; разные источники отправляют разные наборы ключей.
Однако это самый быстрый способ получить информацию об изменениях АС.
Источники, как правило, генерируют события во всех описанных выше ситуациях, за исключением плановой замены оборудования.
- Гибридный метод .
Воспользуйтесь преимуществами всех подходов одновременно:
- Активный сбор из CMDB позволяет быстро выполнить первоначальное заполнение активов SIEM.
- Интеграция с Управлением уязвимостями добавит недостающую информацию.
- Анализ событий позволит быстро обновить модель с учетом специфики каждого источника в отдельности.
На данный момент обе компании продолжают использовать и совершенствовать гибридный подход. Так:
- Рабочие станции, сетевое и серверное оборудование необходимо идентифицировать гибридным способом, агрегируя данные из CMDB, систем управления уязвимостями и события из самих источников.
- Для правильного объединения и обновления собранной для идентификации информации необходимо наличие экспертных механизмов, учитывающих особенности каждого источника.
Состав модели
Вычислительные системы, включая установленное на них системное и прикладное программное обеспечение, несут в себе большой объем информации, необходимой для повышения точности правил корреляции.Так же, как и модель пользователя, модель сетевых и вычислительных систем состоит из общей и поведенческой части.
Как минимум, общая модель сетевых и вычислительных систем должна включать:
- аппаратное обеспечение (включая внешние устройства);
- установленные пользователи;
- установленные сервисы и их соединение с открытыми портами;
- установленное программное обеспечение и его версии;
- установленные обновления;
- существующие уязвимости;
- дела по расписанию;
- список запускаемого программного обеспечения;
- таблицы маршрутизации;
- общие сетевые ресурсы.
- сетевые взаимодействия L3 и L4 (с чем взаимодействует и по каким протоколам);
- средний объем данных, передаваемых за неделю;
- что используют пользователи;
- с каких узлов осуществляется удаленное управление;
- статистика по активации мер защиты для данного хоста (сетевого и локального).
Модель сетевых и вычислительных систем
Источники данных для модели
Сбор информации для этой модели возможен двумя способами: активным и пассивным.
Рассмотрим общую модель: Для общей модели 
Для поведенческой модели 
Защищенная модель данных
Идентификация
Перейдем к последнему компоненту контекста — защищенной модели данных.Чаще всего SIEM не используется для мониторинга защищенных данных, поскольку для этого существуют решения класса Data Leak Prevention (DLP).
Однако эти знания помогают более точно оценить значимость происшествия.
Например, при написании правила корреляции было бы полезно знать, что инцидент происходит не просто на какой-то рабочей станции, а на той станции, которая в данный момент хранит финансовый отчет за год или другую конфиденциальную информацию.
Идентификация конфиденциальной информации реализована механизмом поиска цифровых отпечатков пальцев в самом DLP-решении.
Специфика механизма не позволяет реализовать его внутри SIEM. Таким образом, с точки зрения идентификации защищенных данных можно использовать только тесную интеграцию с решениями класса DLP.
Состав модели
Благодаря тому, что большая часть функций по мониторингу и защите конфиденциальной информации реализована DLP, состав модели в SIEM достаточно компактен.Как минимум, общая модель защищенных данных должна включать:
- на каких активах хранится конфиденциальная информация;
- какие пользователи имеют доступ к конфиденциальной информации.
- между какими активами передается конфиденциальная информация;
- между которыми пользователи переносят конфиденциальную информацию.
Защищенная модель данных
Источники данных для модели
Для построения модели защищенных данных также доступны два метода получения информации – активный и пассивный.
Рассмотрим общую модель: Для общей модели 
Для поведенческой модели 
Механизмы реализации модели в SIEM
Давайте посмотрим, как можно реализовать модель AC в SIEM. Для этого на уровне SIEM необходимо решить два основных вопроса:
- Как реализовать активный и пассивный сбор данных.
- Где и в каком виде хранить модель.
Активный сбор также может осуществляться путем загрузки данных из внешних источников, например, баз данных.
Пассивная коллекция осуществляется путем анализа событий, проходящих через SIEM. Как правило, в SIEM текущего поколения для хранения вышеуказанных данных модели используются список таблиц/активный список/набор ссылок и тому подобные механизмы.
При активном сборе данных создаются плановые задачи для их наполнения из внешних источников.
При пассивном сборе создаются отдельные правила корреляции, в рамках которых при возникновении необходимых событий (создание пользователя, удаление ПО, передача файлов и т.п.
) данные о событии вставляются в список таблиц.
В целом все современные SIEM-решения содержат все необходимые элементы для создания и наполнения данными описываемой модели AS. Историчность модели АС постоянно меняется, это важно учитывать если не в самих правилах корреляции, поскольку они работают в близком к реальному времени и оперируют текущим состоянием АС, то при расследовании инцидента.
С момента начала происшествия до его расследования могут пройти минуты, часы, а иногда и месяцы.
В некоторых атаках между внедрением злоумышленника в систему и обнаружением его деятельности SIEM может пройти до 6 месяцев ( Стоимость исследования утечки данных, проведенного Ponemon, 2018 г.
).
За это время ландшафт системы может кардинально измениться: добавляются и удаляются пользователи, меняются конфигурации оборудования, оборудование, важное для расследования инцидента, выходит из строя, а данные, скопированные злоумышленником с одного хоста, «перетекают» на другой.
Поэтому при расследовании важно смотреть на модель системы в том состоянии, в котором она находилась на момент происшествия, а не на текущую, когда мы впервые начали ее исследовать.
Вывод из всего этого такой: модель, которая построена внутри SIEM, должна иметь историю, к которой можно получить доступ в любой момент. 
Изменение модели со временем
выводы
Подведем итоги:
- Чтобы правила корреляции функционировали с минимальным количеством ложных срабатываний, они должны учитывать контекст, в котором они действуют.
- Контекстом правил корреляции является модель автоматизированной системы компании.
- SIEM обязан строить эту модель в процессе своей работы.
- Модель автоматизированной системы состоит из трех основных частей:
- модель пользователя и его поведение;
- модели сетей и вычислительных систем, их сетевых связей и поведения;
- модель защищенных данных и ее поведение.
- Сбор данных, необходимых для модели, можно осуществить двумя способами:
- активный через скачивание информации из источников;
- пассивный путем извлечения необходимой для модели информации из событий.
- Каждый метод сбора данных имеет свои плюсы и минусы, влияющие на полноту и точность модели.
Для построения максимально точной модели необходимо использовать оба метода одновременно.
- Модель не статична и меняется вслед за изменениями в автоматизированной системе.
- Начало инцидента и его расследование могут разделять дни и даже месяцы, поэтому при расследовании важно оперировать моделью системы в том состоянии, в котором она находилась на момент начала инцидента, а не ее текущей конфигурацией.
- Модель автоматизированной системы в SIEM должна иметь историчность.
Серия статей: Глубины SIEM: корреляции «из коробки».
Часть 1: Чистый маркетинг или неразрешимая проблема? Глубины SIEM: корреляции «из коробки».
Часть 2. Схема данных как отражение модели «мира» Глубины SIEM: корреляции «из коробки».
Часть 3.1. Категоризация событий Глубины SIEM: корреляции «из коробки».
Часть 3.2. Методика нормализации событий Глубины SIEM: корреляции «из коробки».
Часть 4. Модель системы как контекст правил корреляции ( Эта статья ) Глубины SIEM: корреляции «из коробки».
Часть 5. Методика разработки правил корреляции Теги: #информационная безопасность #Анализ и проектирование систем #siem #siem #SIEM #ib #нормализация данных #корреляция данных
-
Готовый Git Сбрасывается Правильно
19 Oct, 24 -
Поджечь На Расстоянии
19 Oct, 24 -
Повышение Тарифов В «Стриме»
19 Oct, 24 -
Новое В Haiku (Svn)
19 Oct, 24
