Могут ли ИБ- и ИТ-аудиторы использовать SIEM для контроля комплаенса и аудита?

Обычно, когда нужно перечислить задачи аудитора, типовой ответ интегратора звучит так: собрать информацию об ИС по опросникам, провести интервью с владельцами ИС, изучить процессы, ЛНА и ОРД и соотнести это с требованиями регулятора. Иногда в число задач добавляют пентест, ISO и ITIL, составление модели угроз и модели нарушителя. На практике аудиты часто являются формальностью и могут проводиться раз в 1 – 3 года. При этом негласное пожелание аудиторам со стороны заказчиков, не желающих вносить сумятицу в отчёты ИТ- и ИБ-служб, звучит так: «скажите, что всё хорошо, или дайте красивые рекомендации, как сделать так, чтобы всё было хорошо в будущем».

Безусловно, отношение к аудиту может быть и принципиально другим. Так, есть небольшая категория компаний, которые включает в задачи аудитора DataOps, Data government, DataSecOps, DevSecOps, VM, Compliance. Но такие организации, как правило, имеют собственных, штатных специалистов по внутреннему аудиту и в целом трансформируют процессы под проактивный подход к подобным проверкам. Большая же часть компаний, зачастую, используют устаревшие подходы и инструменты. Например, имея задачу построить новую ИС, компания привлекает к этому процессу всех заинтересованных лиц, однако под неусыпным вниманием будущая ИС находится лишь на этапах составления ТЗ, проектирования и реализации проекта. После ввода ИС в эксплуатацию контроль переходит в реактивный режим, и риск нарушений информационной безопасности существенно возраст

SIEM по своей природе является идеальной платформой для помощи аудиторам, так как обладает всем необходимым для этой цели функционалом. Разберём подробнее.

Во-первых, SIEM даёт возможность централизованного сбора событий. Она освобождает аудиторов от необходимости заходить на каждую систему (FW, AD, ERP и другие СЗИ) и вручную собирать логи: SIEM уже аккумулирует их в одном месте. Это огромная экономия времени и гарантия того, что данные не были локально изменены.

Во-вторых, SIEM может проводить инвентаризацию активов. Список всех активов с тегами и уровнем критичности позволяет оперативно ответить на вопросы о том, какие у заказчика существуют ИС и где они расположены. Кроме того, с помощью SIEM можно легко и быстро понять архитектуру ИС, что сэкономит аудитору несколько дней работы. Стоит отметить, что, в отличие от привычных аудиторам инструментов – сканеров, SIEM может собирать данные не только из сканеров, но и из ITSM, NTA, а также из событий. Подобный подход повышает прозрачность и позволяет найти как устройства с закрытыми портами, не доступными для сканирования, так и «мёртвые души», указывая на проблемы в процессах инвентаризации и предоставлении оборудования.

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

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

Многие западные вендоры предлагают достаточно развитые решения – с функциями compliance-контроля как по требованиям GDPR, так и по требованиям PCI DSS. Если же говорить об отечественных решениях, то большинство из них, по сути, не собирает нужные метрики с нужных систем и не даёт наглядных и понятных дашбордов, с помощью которых CISO могли бы получить всю информацию по соблюдению необходимых правил.

С чем это связано? Основная проблема заключается в сложности отслеживания потоков данных (data-flow). Тот, кто когда-либо пробовал собрать логи с web-приложения, включающего в себя три звена – web-сервер, БД и клиентскую машину, знает, что это задача «со звёздочкой». Например, установить мониторинг на кастомизированные конфигурации 1С получится только после многомесячных «страданий» со стороны разработчиков системы. Кроме того, 400+ универсальных правил из коробки SIEM неизбежно генерируют поток «мусора», и если в SIEM нет необходимых инструментов, то инциденты и события аудита начинают тонуть в потоке ложноположительных сработок и мешают друг другу.

Масло в огонь подливает и тот факт, что для целей аудита события необходимо хранить в течение 1 – 3 лет, а для Clickhouse’like SIEM это неизбежно повышает требования к «железу». Здесь сошлюсь на коллег из «Лаборатории Касперского». В своих общих рекомендациях, рассчитанных на широкие аналитические запросы, они сообщают, что ClickHouse рекомендует придерживаться отношения RAM к объёму хранимых данных равному 1:100. Но сколько оперативной памяти потребуется, если на каждом узле предполагается хранить 50 ТБ, ведь зачастую глубина хранения событий определяется требованиями регулятора и поисковые запросы не выполняются на всю глубину хранения? Поэтому рекомендацию можно трактовать следующим образом: если средняя глубина запроса предполагает сканирование партиций суммарным объемом в 10 ТБ, то потребуется 100 ГБ RAM.

Наконец, не стоит забывать и про основополагающий момент: систем много, и данные в них содержатся в разных форматах и схемах. SIEM, получающая на входе сырые данные, не приведённые к единому формату и не имеющая инструментов для их стандартизации, на выходе даст такой же поток неструктурированной информации, который сложно будет использовать в работе. Для тех, кто использует SIEM на ClickHouse, это означает, что перед отправкой данных в БД, их придётся стандартизировать под схему, предложенную вендором. Если же ИС нуждается в дополнительных полях, то потребуется приложить дополнительные усилия: например, воспользоваться опцией отправки запроса к вендору на доработку или же обратиться к системе ETL, которая поможет перенести данные в единое хранилище. Коллеги, заменившие или заменяющие Splunk, прекрасно понимают эту проблематику.

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