Почему SIEM не решит все ваши проблемы: 5 распространенных проблем и как их избежать
Современные организации ограничены в возможностях обнаружения вторжений и других видов атак на собственную инфраструктуру. Исследования показывают, что среднее время обнаружения злоумышленника составляет 99 дней. Даже если скептически относиться к этой цифре, нет сомнений в том, что способность обнаружить злоумышленника оперативно не всегда близка к желаемой скорости. Многие организации стремятся внедрить решение, которое устраняет пробел в возможностях обнаружения инцидентов ИБ, и обращаются к SIEM. К сожалению, часто это создает больше проблем, чем решает их.
Я считаю, что SIEM является одним из самых мощных доступных решений для обнаружения инцидентов ИБ.
Однако "наиболее эффективный" не обязательно означает "лучший". Позвольте мне прояснить эту, казалось бы, противоречивую позицию.
Организации часто возлагают большие надежды на внедрение SIEM:
- Быстрое обнаружение и реагирование на инцидент
- Возможность обмениваться данными о событии и инциденте
- Информативное представление сведений об угрозах, которые описывают действия злоумышленника
- Возможность анализировать большие данные
- Автоматизированное машинное обучение и поведенческий анализ
- Автоматическая корреляция данных
Предполагаемые недостатки, как правило, включают первоначальные и периодические капитальные затраты, а также затраты на эксплуатацию системы.
Для многих современных внедрений SIEM большинство вышеперечисленных представлений являются ложными. Во-первых, мы все должны помнить о том, что даже полнофункциональная SIEM является частью комплексной системы защиты информации. То есть является верхнеуровневой системой.
В этой статье я хочу разобрать следующие вопросы:
- 5 распространенных проблем, с которыми сталкиваются организации при внедрении SIEM
- Сценарий использования организации, которая решила одну из этих проблем
- Рекомендации и требования к успеху для организаций, желающих купить SIEM
Иллюстрация rspectr.com
Проблема No1: SIEM так же хороша, как и данные, которые в нее поступают
Сам по себе факт внедрения SIEM ничего не значит для вашей реальной безопасности. Данные, которые поступают в SIEM, - это фундаментальная основа SIEM. Проблема в том, что существует много «плохих» источников данных, и большинство событий не могут быть легко классифицированы двоичным способом "хорошо/плохо". Например, журналы Windows собираются почти повсеместно, и они одновременно являются одними из «хороших» и «плохих» источников событий информационной безопасности.
Во-первых, система Windows даже не регистрирует все события, которые обычно имеют значение. По умолчанию журналирование процессов и командной строки, журналы PowerShell и журналы платформы драйверов Windows не включены. Однако включение их без настройки может перегрузить SIEM большими объемами бесполезных данных. Тем не менее, журналы Windows, которые включены по умолчанию, полезны, но также содержат большой объем шума. Сбор, синтаксический анализ и фильтрация журналов - это искусство, требующее времени и терпения, а также непрерывной переоценки на предмет достоверности.
Это даже не учитывает, как данные подаются в SIEM. Если журнал приходит через syslog, общий протокол транспорта журналов, администратор должен обеспечить синтаксический анализ. Это, вероятно, означает, что конечное состояние журнала в SIEM включает в себя потерю некоторых данных и контекста от исходного события. Возвращаясь к Windows в качестве примера, одна система Windows 10 имеет более 800 полей, найденных в собственной двоичной структуре журнала XML. Тем не менее, большинство SIEM анализируют, уменьшают и преобразуют этот источник только в 200 полей.
Проблема No2: SIEM требует реализации сценария использования
Может ли ваша организация обнаружить злоумышленника, который использовал VBScript для вызова PowerShell, который, в свою очередь, вытащил запутанный код base64, а затем установил бэкдор, наконец, закончил сканированием внутренней сети?
SIEM не может автоматизировать экспертизу в области информационной безопасности и применение ваших журналов к вашим конкретным потребностям. Как только данные попадут в SIEM, именно вы должны сказать SIEM, что с ними делать. По сути, это как купить игрушку, у которой батарейки не включены в комплект поставки.
Вы когда-нибудь спрашивали у поставщика правила или методы оповещения, чтобы поймать злоумышленника только для того, чтобы ему сказали: «каждая организация уникальна»? Хотя в этом есть доля правды, существует также куча методов, которые могут быть использованы в любой организации на основе общих методологий атак. Не верите мне? Ознакомьтесь с этими примерами:
- MITRE ATT&CK: Этот фреймворк с открытым исходным кодом является моделью методологий злоумышленников и поведения противника. Его можно использовать для определения спектра методов, которые может продемонстрировать злоумышленник, а затем просмотреть свои процессы и средства контроля, чтобы выявить пробелы в
обнаружении и предотвращении.
- Sigma: Это нейтральный язык правил SIEM, который позволяет писать правила для поддержки любой среды и любого SIEM. Чтобы эта концепция работала, процесс преобразования принимает написанное правило SIEM и переводит его конкретно для данного SIEM.
В конце концов, SIEM + заявка на сценарий использования = счастливый брак. SIEM без заявления о случае использования означает, что вы подадите на развод позже. Клятва любви, доверия и потрясающих возможностей обнаружения SIEM будет нарушена.
Проблема No3: Больше данных не означает высокую эффективность
Эпоха больших данных наступила. Команды по обеспечению безопасности пытаются собрать все данные, которые они могут получить.
Одной из наиболее распространенных неудач, которые я видел, является SIEM, перегруженный бесполезными данными. В результате получается то, что я называю "кофе-брейком SIEM". Это происходит, когда даже простой поиск занимает несколько секунд или больше. Если аналитику постоянно приходится ждать завершения поиска, то он или она со временем обучается выбирать, что стоит искать - то, что возвращается быстрее всего.
SIEM должен дополнить анализ, а не препятствовать ему. Проще говоря: меньше значит больше. Чем больше у вас данных, тем хуже работает SIEM и тем больше кроличьих нор ваши аналитики могут найти.
Проблема No4: Отсутствие контекста
SIEM должен быть построен аналитиками для аналитиков. Это означает, что когда аналитик просматривает оповещения или журналы, SIEM должен предоставлять контекст и информацию значимым образом. К счастью, наполнение журнала или искусство добавления контекста в журнал - это то, в чем SIEM чрезвычайно успешен. К сожалению, большинство внедрений SIEM отдают приоритет сбору данных, а не обогащению журналов.
Например, предположим, что аналитик рассматривает потенциально подозрительный домен, к которому осуществляется доступ под названием "covertc2.com" (воображаемый). Журнал DNS содержит домен, информацию об IP-заголовке источника и назначения, результирующий IP-адреса (адреса) и тип записи DNS. Достаточно ли этой информации, чтобы помочь аналитику решить, является ли домен вредоносным, подозрительным или доброкачественным? Очевидно, что такое определение на основе этого ограниченного набора данных было бы в лучшем случае спекулятивным.
Теперь подумайте, что вы могли бы сделать, если бы SIEM добавил контекст, например, следующий:
- Домен не входит в 1 миллион лучших сайтов, к которым обращались
- Домен был зарегистрирован 01.11.2016
- IP связана с юридическим лицом в Казани
- IP-адрес принадлежит ООО «Магелан»
- Домен не отображается в базах данных информации об угрозах
- Домен не генерируется случайным образом
Этот уровень контекста не дает 100% уверенности в характере события, но он, безусловно, предоставляет аналитику контекст для принятия более обоснованного решения о самом событии.
Проблема No5: Трудоемкое обслуживание SIEM
Как ни странно, единственное, что организации с готовностью принимают в качестве слабой стороны SIEM, это то, что она сопровождается трудовыми обязательствами - иногда огромными. В результате они нанимают преданных своему делу сотрудников или резервируют время текущей команды для поддержки потребностей в сборе данных и нежной любви и заботы о самом SIEM. Таким образом, вместо того, чтобы заботиться о них, они в конечном итоге позаботились о SIEM. Все это время тратит тонны труда, который можно было бы потратить в другом месте.
Если вы тратите 80% своего времени на выполнение задач по техническому обслуживанию, таких как развертывание агентов, анализ журналов или выполнение обновлений, то вы, скорее всего, не получите максимальную отдачу от SIEM. Автоматизация имеет решающее значение для успешного внедрения SIEM. Ваша среда постоянно меняется, и автоматизация необходима, чтобы идти в ногу с ней, чтобы вы могли лучше тратить свое время на реализацию тактических возможностей.
Хотите купить SIEM? 6 требований к успеху
SIEM может быть невероятно успешным, но она требует следующего:
- 1. Обученный персонал, обладающий знаниями в области информационной безопасности
- 2. Обученный персонал, знающий продукт SIEM
- 3. Способность обогащать SIEM данными
- 4. Поддерживать автоматизацию
- 5. Собирать и использовать важные данные
- 6. Применять сценарии использования в целях обнаружения инцидентов
Машинное обучение и поведенческий анализ также могут быть полезны. Однако не фокусируйтесь на машинном обучении или поведенческой аналитике, пока вы сначала не освоите вышеуказанные требования. Организация, которая осваивает приведенный выше список, но не имеет возможностей автоматического обнаружения, будет иметь значительно лучшие возможности обнаружения, чем организация, которая не освоила список и сосредоточилась на инструменте для автоматического выявления аномалий.
Ключевые выводы
Как правило, использование SIEM наиболее эффективно для зрелых, хорошо работающих команд информационной безопасности. Это ни в коем случае не обязательное правило; я видел ряд команд безопасности, которые далеки от эталонных, правильно внедряют SIEM и достигают положительные результаты. Они смогли использовать свои SIEM для реализации мер безопасности, таких как правила брандмауэра. Тем не менее, гораздо чаще ИБ команды переходят в SIEM и сталкиваются с проблемами, которые я изложил выше.
Ключевой вывод: SIEM не должен быть вашей отправной точкой, особенно если вы только начинаете свой отдел ИБ. Во-первых, начните с основ. Такие вещи, как защита end-point, сегментация сети и брандмауэры, имеют большое значение для обеспечения информационной безопасности. После этого следующий шаг - НЕ спешить и купить SIEM. Только когда вы будете соответствовать вышеуказанным требованиям, вы будете готовы внедрять SIEM.
Автор: Закиров А.Ф.
Смотрите также
- Security Information and Event Management (SIEM)
- Для чего нужна система SIEM и как её внедрить TADетали
- Чем полезна SIEM-система и как её внедрить?
erid: LjN8K67xp
