Привет, Хабр!
Меня зовут Владислав Тишунин, я архитектор комплексных проектов по информационной безопасности. До этого работал на стороне клиентов и прошел карьерный путь от аналитика ИБ дежурной смены операционного центра безопасности в крупной энергетической компании до техлида и архитектора 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-решение – это комплексная система, состоящая из четырех ключевых компонентов, каждый из которых играет свою роль:
Компонент управления, предоставляющий веб-интерфейс. Здесь осуществляется управление пользователями, настройка задач по сбору событий, работа с уведомлениями и контентом (или правилами) для обработки событий. Именно здесь аналитики взаимодействуют с собранными событиями и подозрениями на инциденты.
Коллектор, обеспечивающий сбор событий из различных источников в активном (инициируя подключение к источнику для сбора логов) или пассивном (например, прослушивая syslog) режиме. Собранные данные отправляются в хост-обработчик. Может быть один или несколько таких хостов.
Хост-обработчик, принимающий на себя поток собранных событий от одного или нескольких коллекторов. Хостов-обработчиков может быть несколько. Здесь происходит обработка событий, а именно:
- нормализация: приведение различных событий к единому формату. События раскладываются по полям таксономии, заложенной в системе;
- агрегация (опционально): объединение нескольких идентичных событий в одно по заданным условиям за определенный промежуток времени;
- обогащение: добавление контекста к событиям, там, где это возможно. Например, определение страны по IP-адресу, проставление маркера о найденном в событии индикаторе компрометации или выстраивание цепочки процессов, породивших событие, – все это помогает аналитикам получить больше контекста в рамках анализа событий;
- корреляция: выявление последовательностей в полученных событиях. На основании последовательности действий генерируются корреляционные события и (или) алерты, с которыми уже могут работать аналитики.
Хост-хранилище осуществляет хранение собранных событий, а также корреляционные события. События хранятся в течение заданного периода времени или до достижения порога по занимаемому дисковому пространству, после чего происходит ротация.
Это обобщенное описание функциональности 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-системы должны убедиться в том, что события поступают в нее в нужном формате и объеме. Только после этого подключение хоста можно считать завершенным.
В общем виде процесс подключения можно описать следующим образом:
Регистрация в сервис-деске или тикет-системе задачи на выделение узла или установку необходимого программного обеспечения. Необходимый этап — как правило, финальный — настройка отправки событий со стороны ОС (и со стороны ПО, если требуется), а также организация сетевого доступа между источником и необходимым хостом-коллектором.
В соответствии с заявкой выполняются необходимые действия. По итогу настройки журналирования администраторы SIEM-системы получают уведомление о готовности и назначаются ответственными за задачу.
Администраторы SIEM-системы создают новую задачу на сбор данных или убеждаются, что события поступают в рамках уже имеющейся задачи (например, при настройке сбора логов ОС Windows через WEC средствами GPO, или с Unix-like через syslog-collector). При получении событий администраторы должны подтвердить или опровергнуть настройку логирования на источнике.
3.1. Если события не поступают или поступают в формате, отличном от ожидаемого, либо поступают не в полном объеме, заявка возвращается на доработку ИТ-службе (п. 2).
3.2. Если события поступают и вопросов к полноте и достаточности событий со стороны эксплуатантов SIEM-системы нет, то подзадача закрывается как выполненная и тикет возвращается в работу специалистам ИТ.
Задача выполнена, источник событий настроен.
Согласованный и утвержденный регламент должен соблюдаться всеми участвующими в процессе подразделениями, но для контроля качества его исполнения в рамках этого же регламента можно и даже нужно указать, что с некоторой частотой – условно, раз в год или в полгода (в зависимости от размера инфраструктуры), следует проводить проверку с помощью, например, внедренной системы ИТ-инвентаризации, которую ведут ИТ-специалисты, с фактическим перечнем узлов, которые отправляют события в 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-решения в инфраструктуре. Как и любой иной регламент, все обозначенные процессы требуют адаптации под особенность каждой конкретной организации, и их периодически нужно пересматривать, чтобы поддерживать в актуальном состоянии.
