Привет, Хабр! 

Меня зовут Владислав Тишунин, я архитектор комплексных проектов по информационной безопасности. До этого работал на стороне клиентов и прошел карьерный путь от аналитика ИБ дежурной смены операционного центра безопасности в крупной энергетической компании до техлида и архитектора SOC в одной из крупнейших компаний по транспортировке нефти и нефтепродуктов в мире. В настоящее время тружусь на благо защиты данных клиентов из различных отраслей сегмента «large enterprise» в Positive Technologies.

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

Пререквизиты: что такое SIEM?

В операционных центрах безопасности (security operations center, SOC) базовым инструментом для работы является система, позволяющая обнаруживать признаки компрометации и иной нелегитимной и просто подозрительной деятельности на узлах инфраструктуры. Имя этому инструменту — SIEM. В переводе с оригинала — security information and events management — система управления информацией и событиями безопасности.

Представьте корпоративную ИТ-инфраструктуру как огромный город. Серверы, рабочие станции, сетевое оборудование, «облака», VPN, базы данных, приложения, пользователи с паролями «Qwerty123» и администраторы, которые клянутся, что «вчера всё работало».

И каждый из этих элементов что-то постоянно делает и оставляет следы: логи, ошибки, предупреждения, попытки входа, странные сетевые пакеты и прочие «цифровые крошки».

Проблема в том, что таких событий со всех хостов с легкостью может поступать десятки миллионов в день, а то и в час. И если их просто складывать в папку logs на каждом хосте инфраструктуры и надеяться на лучшее — рано или поздно кто-то посторонний будет гулять по вашей сети, а вы узнаете об этом последними. Иногда, — что самое печальное, — из новостей.

Чтобы автоматизированно проверять и централизованно обрабатывать огромное количество событий о происходящем в инфраструктуре, и используется SIEM — класс решений информационной безопасности, призванный анализировать события ИБ, собираемые c устройств инфраструктуры, выявлять подозрения на инциденты.

Но для правильного использования этой системы, а тем более для максимально эффективной ее эксплуатации необходимо провести ряд организационных мероприятий, направленных на выстраивание правильной работы как специалистов, непосредственно взаимодействующих с SIEM-системой (аналитиков ИБ, технических специалистов и администраторов), так и смежных подразделений организации, отвечающих за блок ИТ. 

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

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

Подытоживая лирическое вступление: SIEM без процессов — ресурсы на ветер.

Анатомия SIEM: Четыре столпа системы

SIEM-решение – это комплексная система, состоящая из четырех ключевых компонентов, каждый из которых играет свою роль:

1. Компонент управления, предоставляющий веб-интерфейс. Здесь осуществляется управление пользователями, настройка задач по сбору событий, работа с уведомлениями и контентом (или правилами) для обработки событий. Именно здесь аналитики взаимодействуют с собранными событиями и подозрениями на инциденты.

2. Коллектор, обеспечивающий сбор событий из различных источников в активном (инициируя подключение к источнику для сбора логов) или пассивном (например, прослушивая syslog) режиме. Собранные данные отправляются в хост-обработчик. Может быть один или несколько таких хостов.

3. Хост-обработчик, принимающий на себя поток собранных событий от одного или нескольких коллекторов. Хостов-обработчиков может быть несколько. Здесь происходит обработка событий, а именно:

   - нормализация: приведение различных событий к единому формату. События раскладываются по полям таксономии, заложенной в системе;

   - агрегация (опционально): объединение нескольких идентичных событий в одно по заданным условиям за определенный промежуток времени;

   - обогащение: добавление контекста к событиям, там, где это возможно. Например, определение страны по IP-адресу, проставление маркера о найденном в событии индикаторе компрометации или выстраивание цепочки процессов, породивших событие, – все это помогает аналитикам получить больше контекста в рамках анализа событий;

   - корреляция: выявление последовательностей в полученных событиях. На основании последовательности действий генерируются корреляционные события и (или) алерты, с которыми уже могут работать аналитики.

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

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

Ключевой показатель, определяющий стоимость (в случае платных решений), технические характеристики оборудования и количество требуемых серверов, — это количество событий в секунду (events per second, EPS), которые система способна обрабатывать. Эта метрика – усредненная величина, и за каждым решением стоит собственная оценка EPS от различных типов источников. Предсказать точное количество событий от серверов, АРМ, сетевого оборудования, веб-приложений и других источников довольно затруднительно. Этот параметр зависит от уровня настроенного логирования и количества выполняемых операций на узле в момент времени.

Цена беспечности: SIEM без процессов – пустая трата ресурсов SOC

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

Продуманные процессы нужны не для галочки или прокачки «paper security» (бумажная безопасность, безопасность на бумаге), а для того, чтобы работа с SIEM кардинально отличалась от хаотичной картины, вот такой:

Процессы, связанные с решением класса SIEM (как бы ни ругали специалисты термин paper security), — это не просто что-то на бумаге «про безопасность», а буквально руководство к действию. Оно является базой для выстраивания коммуникаций между специалистами разных подразделений, специалистами и эксплуатируемой системой. Эта база позволяет в более прозрачном, понятном и прогнозируемом виде обнаруживать и расследовать инциденты ИБ всеми вовлеченными в этот процесс сторонами.

Два крыла SIEM: техническая эксплуатация и аналитика

Разделим процессы, связанные с двумя основными направлениями эксплуатации SIEM-системы:

• Техническая эксплуатация и развитие инсталляции. Забота об этом направлении ложится на плечи администраторов ИБ и технических специалистов, отвечающих за поддержание работоспособности и техническое обслуживание системы.

• Аналитика и расследование. Здесь главенствуют аналитики и эксперты ИБ, которые занимаются анализом событий и расследованием инцидентов ИБ и подтвержденных инцидентов.

Техническая сторона медали 

Инвентаризация и аудит

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

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

Есть два основных способа собирать информацию:

• Запрос информации от подразделения ИТ. Это быстрый способ, но информация может быть неполной, если в инфраструктуре не проводится регулярная инвентаризация ИТ-активов. Если уверенности в полноте и достоверности информации нет, следует прибегнуть к следующему способу.

• Сканирование инфраструктуры. Поиск хостов в сети с их последующим аудитом методом «белого ящика» для сбора максимального количества информации вплоть до перечня установленного ПО, их версионности, конфигурации, пользователей на хостах с их привилегиями и т. д. Это более трудоемкий, но и более информативный подход. Такие сканирования могут поводиться как в интересах ИТ, так и ИБ – для выявления не соответствующих требованиям конфигураций и для обнаружения уязвимостей ОС и ПО на узлах, их приоритизации. Класс решений – Vulnerability Management. Подобные сканирования способствуют реализации превентивной защиты от кибератак.

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

Есть фраза, которая применима и к покрытию SIEM-системой:

«Нельзя управлять тем, что невозможно измерить, но всего, что измеримо, можно достичь».

Билл Хьюлетт

По итогам анализа следует сформировать ряд перечней и метрик. Подключение источников в соответствии с ними будет свидетельствовать о полноте покрытия инфраструктуры мониторингом со стороны SIEM:

• перечень всех инфраструктурных сервисов: DC, DNS, DHCP, Exchange, CA, SCCM/MECM, системы резервного копирования, системы виртуализации и т. д;

• общее количество узлов с типом АРМ, серверы с разбивкой по ОС;

• перечень используемых средств защиты информации: файрволл, антивирусное ПО, системы анализа трафика, веб-прокси, безопасные шлюзы электронной почты, песочницы и т. д;

• перечень сетевого оборудования;

• системы организации удаленного доступа;

• распределение узлов по сегментам сети, подсетям.

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

Регламент подключения: путь к полной видимости

Инфраструктура не статична: со временем она меняется, модернизируется, какие-то решения выводятся из эксплуатации, какие-то — масштабируются, какие-то — заменяются, в каких-то случаях принимается решение о смене используемого ПО.

А SIEM-система, которую однажды аккуратно настроили, продолжает честно ждать события:

• от серверов, которых уже нет,

• сервисов, которые переехали,

• приложений, которые заменили.

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

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

• логи Windows (расширенный аудит и Sysmon, логирование командной строки и т. д.),

• журналы Unix-подобных систем (корректную настройку auditd),

• логи основных инфраструктурных сервисов (AD, SCCM/MECM, WSUS, DHCP, DNS, CA, и т. д.),

• логи средств защиты информации (AV, NTA, AF и других),

• журналы межсетевых экранов, веб-серверов, СУБД, средств виртуализации и т. д.

Поскольку основными исполнителями этого регламента будут специалисты блока ИТ, помимо инструкций по настройке, полезно будет обозначить в регламенте сетевые сегменты и относящиеся к ним SIEM-коллекторы, а также серверы WEC и syslog-коллекторы, на которые будут отправляться события ОС и приложений. Кроме того, важно явно прописать зоны ответственности и процесс, по которому будет верифицироваться результат настройки источника и пересылки событий. Например, настройка логирования ОС выполняется специалистами ИТ, а специалисты по эксплуатации SIEM-системы должны убедиться в том, что события поступают в нее в нужном формате и объеме. Только после этого подключение хоста можно считать завершенным.

В общем виде процесс подключения можно описать следующим образом:

1. Регистрация в сервис-деске или тикет-системе задачи на выделение узла или установку необходимого программного обеспечения. Необходимый этап — как правило, финальный — настройка отправки событий со стороны ОС (и со стороны ПО, если требуется), а также организация сетевого доступа между источником и необходимым хостом-коллектором.

2. В соответствии с заявкой выполняются необходимые действия. По итогу настройки журналирования администраторы SIEM-системы получают уведомление о готовности и назначаются ответственными за задачу.

3. Администраторы SIEM-системы создают новую задачу на сбор данных или убеждаются, что события поступают в рамках уже имеющейся задачи (например, при настройке сбора логов ОС Windows через WEC средствами GPO, или с Unix-like через syslog-collector). При получении событий администраторы должны подтвердить или опровергнуть настройку логирования на источнике.

   3.1. Если события не поступают или поступают в формате, отличном от ожидаемого, либо поступают не в полном объеме, заявка возвращается на доработку ИТ-службе (п. 2).

   3.2. Если события поступают и вопросов к полноте и достаточности событий со стороны эксплуатантов SIEM-системы нет, то подзадача закрывается как выполненная и тикет возвращается в работу специалистам ИТ.

4. Задача выполнена, источник событий настроен.

Согласованный и утвержденный регламент должен соблюдаться всеми участвующими в процессе подразделениями, но для контроля качества его исполнения в рамках этого же регламента можно и даже нужно указать, что с некоторой частотой – условно, раз в год или в полгода (в зависимости от размера инфраструктуры), следует проводить проверку с помощью, например, внедренной системы ИТ-инвентаризации, которую ведут ИТ-специалисты, с фактическим перечнем узлов, которые отправляют события в SIEM-решение. Такая активность позволит выявить пробелы в покрытии и оценить наличие проблем в исполнении регламента для его последующей доработки и актуализации.

Поддержание гармонии: контроль работоспособности SIEM-решения и его масштабирование

Работа проделана масштабная. SIEM внедрен, запланированные источники событий подключены, регламент задокументирован, согласован и утвержден. ИТ-специалисты периодически уточняют по заявкам, поступают ли события, администраторы SIEM-системы не сидят сложа руки.

Но это лишь начало. Помимо обеспечения полноты покрытия, необходимо заботиться о поддержании работоспособности самого SIEM-решения.

Поскольку система состоит из множества компонентов, каждый из которых выполняет свои функции, стоит проводить регулярный «хелсчек» всей инсталляции. Этот процесс должен охватывать как программную часть, так и виртуальные машины или физические серверы, на которых развернута инсталляция. Оценка состояния может быть организована в виде ежедневной задачи, автоматически создаваемой в таск-трекере. Эта проверка может, например, включать следующие пункты с указанием допустимых значений, но не ограничиваясь ими:

• оценка потребления оперативной памяти;

• утилизация дисковой подсистемы;

• наличие свободного места на дисках;

• статус работы служб, контейнеров, подов;

• наличие ошибок в журналах сервисов;

• статус самопроверки SIEM-решения через веб-интерфейс системы (при наличии).

Для упрощения этой рутинной проверки следует настроить средства автоматического сбора метрик и визуализации данных о состоянии ИТ-инфраструктуры, например Zabbix или Grafana.

Почему регулярный контроль так важен, даже если система способна проводить самодиагностику и оповещать о проблемах через веб-интерфейс или электронную почту?

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

• Во-вторых, с проблемами нужно бороться превентивно, не дожидаясь их негативных последствий.

❓ Что делать, если, несмотря на соблюдение процесса подключения источников, SIEM-система со временем достигает пика производительности из-за роста инфраструктуры и увеличения объема обрабатываемых событий? 

В этом случае необходимо масштабировать систему. И лучше это делать заранее, если есть четкое понимание, что текущих мощностей будет недостаточно. Решение о масштабировании должно быть продумано еще на этапе проектирования (другими словами, нужно сразу определить, как система может быть масштабирована при необходимости). В пояснительной записке к техническому решению необходимо предусмотреть раздел, посвященный способам и вариантам масштабирования:

• вертикальное (путем увеличения ресурсов), если, например, для установки системы используется виртуализация и есть возможность увеличить ресурсы,

• горизонтальное (путем добавления новых хостов обработки и хранения событий, коллекторов) – если увеличение производительности за счет выделения дополнительных ресурсов невозможно.

Безопасное обновление: регламент и план отката

Обновление версии системы — одно из потенциальных мест возникновения проблем. Неполадки могут возникнуть как в процессе обновления, так и после его завершения, — в виде багов или проблем, которых в предыдущей версии не было.

❓ Что делать в такой ситуации, особенно если система находится в постоянной эксплуатации, а длительный простой нежелателен или вовсе недопустим (из-за прерывания мониторинга)? 

Ответ прост: помимо обязательного составления плана обновления на основании документации вендора (где для каждого пункта действий следует предусмотреть операции по отмене, – например, возвращение значений в конфигурационных файлах к исходным или восстановление хоста из резервной копии), необходимо предварительно проверить возможность и «болезненность» процесса обновления. Для организации проверки следует как минимум организовать:

• непосредственно проверку возможности перехода на новую версию системы,

• выполнение резервного копирования.

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

Создание резервных копий необходимо рассматривать как повторяющийся процесс, относящийся как к хостам целиком, так и к составным элементам системы: конфигурациям, компонентам, данным СУБД. Например, хорошим тоном будет создание плана резервного копирования, который опишет частоту создания резервных копий, срок их хранения и способы восстановления. Точечные резервные копии (конфигурации, компоненты системы) следует создавать довольно часто, например, не реже раза в неделю. Резервное копирование хоста - реже, СУБД – в зависимости от объема и критичности информации – еще реже. Не стоит забывать о проверке технической возможности проведения резервного копирования, в частности, об объеме дискового пространства, необходимого для создания резервной копии с учетом срока ее хранения. Чем чаще делаются резервные копии, тем проще будет процесс восстановления системы в случае возникновения проблем, которые не удается решить «на ходу», а также в случае выполнения действий по отмене в ходе обновления системы.

Аналитическая часть: от верификации до threat hunting

Первый и наиболее важный процесс для аналитиков, как и в случае с технической эксплуатацией, — это подключение источников событий. Со стороны аналитиков ИБ основная задача в этом процессе — верифицировать полноту и достаточность получаемых событий либо отразить в регламенте перечень типов событий по каждому типу источника для валидации на стороне технической эксплуатации. Еще одна задача — понять, нужно ли подключать источники, не учтенные в регламенте, на основе анализа их событий.

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

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

Эти исключения перед их реализацией должны верифицироваться более опытными аналитиками (если, например, реализовано несколько линий анализа), после чего предложенные исключения вносятся в SIEM либо со стороны технической эксплуатации, либо аналитиками, проводившими верификацию, – в зависимости от организационной структуры и разделения обязанностей между подразделениями. Еще больше обобщая вышесказанное – нужен процесс по работе c детектами, обнаруженными на основании поступающих событий, и, в частности, с исключениями.

Знакомьтесь: плейбук

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

Плейбук – это пошаговый алгоритм действий, которые нужно выполнить для полноценного расследования конкретного типа инцидента.

Все плейбуки, как правило, описаны аналитиками ИБ с учетом особенностей инфраструктуры, принятого порядка взаимодействия с ИТ-подразделением (там, где это необходимо), а также с учетом доступного инструментария для расследования.

Помимо работы с инцидентами ИБ как части процесса по «охоте за угрозами» (threat hunting), стоит искать скомпрометированные ИТ-активы на основании анализа событий в разрезе индикаторов компрометации (далее – IoC), не дожидаясь генерации инцидентов.

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

В большинстве случаев индикаторами компрометации выступают IP-адреса, доменные имена вредоносных ресурсов или командных серверов вредоносного ПО, URL-ссылки на страницы, содержащие вредоносный код, или известные хеш-суммы вредоносных объектов. 

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

Другое важное направление threat hunting — профилирование активности, которое выявит аномалии, нетипичное поведение и нетипичные всплески активности. При наличии соответствующих технических возможностей в SIEM-решении создание подобных «профилей» позволяет фиксировать отклонения от стандартных паттернов: от резкого изменения количества сетевых запросов между хостами, использования нестандартных портов и протоколов до обнаружения запуска приложений, не характерных для определенной группы хостов. Например, запуск Wireshark (система захвата и анализа трафика) на хосте бухгалтера.

Составление таких «профилей» используемых приложений, выполняемых команд и прочей активности в инфраструктуре на основе получаемых событий — процесс ресурсоемкий и трудозатратный, однако он способен существенно сократить время обнаружения подозрительной активности, не дожидаясь срабатывания иных сценариев, которые создадут в системе запись об инциденте. Кстати, для автоматизации этой активности в продуктах могут использоваться ML-модели, способные «обучаться» на основе собираемых событий и выдавать свои вердикты о наличии аномалий в действиях.

И, конечно же, чтобы проверять эффективность всех предпринимаемых действий в работе c SIEM-системой, необходимо периодическое тестирование инфраструктуры на проникновение (пентест), по итогу которого аналитики ИБ смогут получить информацию о достаточности проводимых мероприятий на основании зафиксированной или незафиксированной активности пентестеров, а также при необходимости скорректировать процессы по расследованию, оптимизировать требования к настройке логирования на источниках и доработать используемые в системе сценарии или разработать новые.

Заключение

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