- PVSM.RU - https://www.pvsm.ru -
Как часто вы слышите утверждение что правила корреляции, поставляемые производителем SIEM, не работают и удаляются, или отключаются сразу же после инсталляции продукта? На мероприятиях по информационной безопасности любая секция, посвященная SIEM, так или иначе затрагивает данный вопрос.
Давайте рискнем и попробуем найти решение проблемы.
Чаще всего основной проблемой называют то, что правила корреляции производителя SIEM изначально не адаптированы под особенности инфраструктуры конкретного заказчика.
Анализируя проблемы, озвучиваемые на разных площадках, складывается ощущение, что решения у проблемы нет. Внедряя SIEM все равно придется либо очень сильно доработать то, что поставляет производитель, либо выкинуть все правила и писать свои с нуля, при этом данная проблема присуща всем решениям, из любой части квадранта Gartner.
Невольно задаешься вопросом действительно ли все так плохо и данный Гордиев узел невозможно разрубить? Неужели выражение «Правила корреляции, работающие из коробки» — всего лишь маркетинговый слоган, за которым ничего не стоит?
Статья может вас заинтересовать, если:
В рамках данной серии статей перечислим главные проблемы, которые препятствуют реализации концепции «Правил корреляции, работающих из коробки», а также попробуем описать системный подход для их решения.
Сразу оговорюсь, что техническими специалистами именно эта статья может быть охарактеризована как: «вода», «ни о чем». Все так и есть, но не совсем. Перед тем как разбираться с какой-то сложной задачей, хочется сначала выяснить почему она возникла и что нам дает ее решение.
Для лучшего понимания всего круга вопросов, которые будут изложены, приведу общую структуру всего цикла статей:
Попробуем в общих чертах, простыми словами, сформулировать нашу задачу: «Я, как клиент, купивший SIEM решение, подписку на обновлении базы правил и платящий производителю (а иногда и интегратору) за поддержку, хочу, чтобы мне оперативно поставлялись правила корреляции, которые устанавливались бы в мой SIEM и сразу же приносили пользу». Как по мне, так вполне себе здравое пожелание, не обремененное какими-то архитектурными или структурными техническими ограничениями.
А теперь, внимание, давайте допустим, что мы уже решили все проблемы и наша задача уже выполнена. Что нам это дает?
Многие технические специалисты, кто сталкивался с решением поставленной задачи и дочитавшие до этого места, сразу возразят: «Да, плюсы конечно есть, но это технически нереализуемо». Лично я считаю, что задача вполне «подъемная» и уже сейчас, как на западном, так и российском рынке есть SIEM, которые содержат все элементы, необходимы для ее решения. Хочу акцентировать на этом ваше внимание – продукты позволяют не решить задачу, а лишь содержат все необходимые блоки, из которые, как из конструктора, можно собрать искомое нами решение.
Считаю это очень важным, т.к. все, что будет описано дальше, возможно реализовать практически в любом существующим и зрелом SIEM.
Довольно лирики, далее мы поговорим более подробно о тех проблемах, которые возникают на пути решения нашей задачи.
В поисках решения поставленной выше задачи, давайте посмотрим с какими-же проблемами нам придется столкнуться. Выделение основных проблем позволит лучше понять проблематику, а также выработать системный подход для их разрешения.
Те проблемы, с которым мы столкнемся представляют собой снежный ком, каждая из которых драматически усугубляет ситуацию. Множество всех этих проблем ведет к тому что создать «Правила корреляции, работающие из коробки» крайне затруднительно.
В целом проблемы подразделяются на следующие четыре крупных блока:
Давайте теперь рассмотрим эти проблемы более подробно.
Данную проблему проще всего описать, пользуясь следующей аналогией.
Мир вокруг нас многообразен и многогранен, но наш слух и зрение фиксирует только ограниченный спектр излучений. Увидев или услышав какое-то явление, мы строим у себя в голове образ данного события, оперируя уже его урезанной моделью. К примеру, наш глаз не видит в инфракрасном спектре, а ухо не улавливает колебания ниже 16 Гц. Это первая трансформация исходного явления. Бывает в эту модель наша фантазия приносим то, чего в исходном явлении не было. Об этом явлении мы можем рассказать собеседнику, используя устную речь со всеми ее ограничениями и особенностями. Это вторая трансформация модели. Наконец собеседник, с наших слов, решит написать об этом явлении своему коллеге в мессенджере. Это третья и, скорее всего, самая драматическая с точки зрения потери информации трансформация модели.
В описанном выше примере мы наблюдаем классическую проблему, к которой исходная «концептуальная модель» (Советов Б. Я., Яковлев С. А., Моделирование систем) путем упрощения трансформируется в другую модель при этом теряя в детальности.
Ровно тоже самое происходит и в мире событий, порождаемых программным или аппаратным обеспечением.
Пояснением может служить вот такая упрощенная картина уже из нашей предметной области:
Теперь как это выглядит в рамках нашей задачи.
Мы имеем уже упрощенную модель (уже потерявшую много деталей) какого-то явления, представленного записью в лог-файле – событием. SIEM зачитывает это событие, нормализует его путем распределения данных по полям своей схемы. Количество полей в схеме априори не может содержать их столько, сколько необходимо чтобы покрыть все возможные семантики всех событий от всех источников, то есть на этом шаге также происходит трансформация модели и потеря данных.
Важно понимать, что из-за наличия этой проблемы эксперт, анализируя логи в SIEM или описывая правило корреляции, видит не само исходное событие, а его как минимум дважды искаженную модель, потерявшую достаточно много информации. И, если потерянная информация крайне важна в расследовании инцидента и, как следствии написании правила, ее придется откуда-то извлечь. Найти же недостающую информацию эксперту возможно либо путем обращения к первоисточнику (сырому событию, дампу памяти и т.д.), либо смоделировав недостающие данные у себя в голове на основе своего опыта, что сделать непосредственно из правил корреляции практически невозможно.
Хорошим индикатором данной проблемы служат, как не странно, поля типа Customer device string, Datafield или что-то иное. Эти поля представляют собой некую «свалку» куда, помещают данные, которые не знают куда положить, или когда все остальные подходящие поля попросту заполонены.
Набор полей таксономии, как правило, отражает модель «мира» так, как видит предметную область разработчик SIEM. Если модель очень «узкая», то в ней небольшое количество полей и при нормализации части событий их будет попросту не хватать. Таким проблемой часто обладают SIEM с изначально фиксированным и динамически нерасширяемым набором полей.
С другой стороны, если полей слишком много, появляются проблемы, связанные с непониманием в какое поле необходимо положить те или иные данные исходного события. Такая ситуация влечет за собой возможность появления смыслового дублирования, когда семантически одни и те же данные исходного события подходят сразу под несколько полей. Такое часто наблюдается в решениях, где набор полей схемы динамически может быть расширен любым модулем нормализации при поддержке нового источника.
Если под рукой есть «боевой» SIEM, посмотрите на свои события. Как часто при нормализации вы используете зарезервированные дополнительные поля (Custom device string, Datafield, и т.д.)? Множество типов событий с заполненными дополнительными полями говорят о том, что вы наблюдаете первую проблему. А теперь вспомните, или спросите у коллег, как часто при поддержке нового источника им приходилось добавлять новое поле, так как зарезервированных не хватило? Ответ на данный вопрос служит индикатором второй проблемы.
Важно вспомнить кто и как нормализует события, т.к. это играет немаловажную роль. Часть источников поддерживает непосредственно разработчик SIEM решения, часть интегратор, внедрявший вам SIEM, а часть вы сами. Вот тут-то нас и поджидает следующая проблема: Каждый из участников по-своему трактует смысл полей схемы событий и поэтому по-разному проводит нормализацию. Таким образом семантически одинаковые данные разные участники могут разложить в разные поля. Безусловно, есть ряд полей, название которые не допускает двойственной трактовки. Допустим src_ip или dst_ip, но даже с ними бывают трудности. Например, в сетевых событиях, надо ли менять src_ip на dst_ip при нормализации входящего и исходящего соединения в рамках одной сессии?
Исходя из вышеописанного возникает необходимость создания четкой методология поддержки источников, в рамках которой было бы явно указано:
В рамках решения поставленной задачи объектом защиты является наша автоматизированная система (АС). Да, именно АС в определении ГОСТ 34.003-90 [1], со всеми ее процессами, людьми и технологиями. Это важное замечание, к нему мы вернемся позже, в следующих статьях.
Слово «мутация» здесь выбрано не случайно. Давайте вспомним, что в биологии под мутацией понимают стойкие изменения в геноме. Что есть геном АС? В рамках данного цикла статей под геномом АС я буду понимать ее архитектуру и структуру. А «стойкие изменения» — не что иное как результат ежедневной работы системных администраторов, сетевых инженеров, инженеров информационной безопасности. Под действиями этих изменений АС каждую минуту переходит из одного состояния в другое. Какие-то состояния характеризуются большим уровнем защищенности, какие-то меньшим. Но, сейчас для нас это не важно.
Важно понимать, модель АС — не статичный, все параметры которого описаны в технической и рабочей документации, а живой, постоянно мутирующий объект. SIEM, строя у себя внутри модель объекта защиты должен это учитывать и быть способен своевременно и оперативно ее обновлять, не отставая за темпами мутации. И, если мы хотим заставить правила корреляции «работать из коробки», необходимо чтобы они учитывали эти мутации и оперировали всегда самой актуальной картиной «мира».
Из представленной выше «пирамиды» [2] видно, что разрабатывая правила корреляции мы вынуждены бороться о всеми проблемами, лежащими на более низких уровнях. В борьбе с этими проблемами правила наделяют лишней логикой: дополнительной фильтрации событий, проверки на пустые значения, приведения типов данных и трансформации этих данных (к примеру извлечение имени домена из полного имени доменного пользователя), вычленения информации о том, кто и с кем взаимодействует в рамках события.
После всего этого правила обрастают таким количеством уловных выражений, поиска подстрок и регулярных выражений, что логика их работы становится понятна только их авторам и то, до момента их ближайшего отпуска. Мало того, постоянные изменения автоматизированной системы – мутации требуют регулярной актуализации правил борьбе с фалсами. Знакомая картина?
В рамках данного цикла статей мы с вами попробуем понять, как сделать так, чтобы правила корреляции работали «из коробки».
Для решения поставленной задачи нам предстоит столкнуться со следующими проблемами:
Многие из этих проблем лежат в плоскости построения правильной схемы события – наборе полей и процессе нормализации событий – фундаменте корреляционных правил. Другая часть проблем решается организационными и методологическими методами. Если нам удастся найти решение указанных проблем, то концепция работающих «из коробки» правил даст широкий положительный эффект и поднимет экспертизу, закладываемую в SIEM производителями на новый уровень.
Что дальше? В следующей статье попробуем разобраться с потерей данных при трансформации модели «мира» и подумаем, как вообще должен выглядеть необходимый для нашей задачи набор полей – схема.
Статья уже почти готова, т.ч. опубликую ее в ближайшее время.
Автор: Николай Арефьев
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/292730
Ссылки в тексте:
[1] ГОСТ 34.003-90: http://protect.gost.ru/document.aspx?control=7&id=137473
[2] «пирамиды»: #Problems
[3] Источник: https://habr.com/post/423431/?utm_source=habrahabr&utm_medium=rss&utm_campaign=423431
Нажмите здесь для печати.