Стратегия 6. Часть 7. Покупка и ожидания от SIEM. Рекомендации при внедрении.

8.4.4 Покупка SIEM

SIEM – одно из самых крупных вложений для SOC. Прежде чем рассматривать вопрос о покупке SIEM, необходимо, чтобы сложились следующие основные условия:

  • У SOC уже есть инструменты сбора логов; его потребности в аналитике и корреляции данных больше, чем предлагают текущие инструменты.
  • SOC выполняет значительную часть своих обязанностей по анализу данных в реальном времени.
  • SOC выделил помимо IDS/IPS еще несколько потоков данных, которые необходимо передавать в SIEM в режиме реального времени.
  • SOC участвует в процессе регулярного управления и настройки датчиков, для чего есть выделенный персонал, тем самым демонстрируя, что он готов взять на себя управление SIEM.

Конечно, для каждого условия есть исключения, но они справедливы в подавляющем большинстве случаев, когда SOC рассматривает возможность о покупке SIEM.

Далее необходимо рассмотреть требования. Требования — это то, что движет приобретением: требования бизнеса, функциональности, производительности, системы, пользователей, эксплуатации и так далее. Какие возможности SOC хочет получить? Каковы будут основные сценарии использования? Будет ли архитектура SIEM соответствовать потребностям SOC через три или пять лет? И это только начало.

Как и в случае любого крупного приобретения, вероятно SOC может рассмотреть возможность пилотирования двух или трех SIEM основных поставщиков. Это позволит сравнить все инструменты по четко определенным, повторяемым и измеримым требованиям. Инженеры SOC могут использовать взвешенную, воспроизводимую оценочную таблицу для сравнения требований, что особенно полезно при наличии большого количества требований или в случае крупного приобретения. Вендоры часто готовы предоставить временную лицензию на 60 или 90 дней для теста. Даже если пилотируется всего один продукт, это может быть очень полезно для корректировки требований и управления ожиданиями.

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

  • Количество «ключевых узлов» (например, менеджеров, поддерживающих работу «мозгов» SIEM, таких как механизм корреляции); иногда измеряется количеством ядер CPU, принадлежащих одному или нескольким мастер-узлам.
  • Объем данных, обрабатываемых системой; обычно измеряется в гигабайтах в день, событиях в день или поддерживаемых событиях в секунду.
  • Количество пользователей, получающих доступ к системе (количество «мест»).
  • Количество приобретенных устройств (в случае виртуальных программных или аппаратных устройств).
  • Количество устройств, отправляющих данные в систему, и, возможно, количество типов устройств (Windows, системный журнал UNIX, база данных, приложение и т. д.).
  • Дополнительные функции или дополнения, такие как пакеты экспертизы.

В некоторых случаях поставщики SIEM устанавливают жесткие ограничения на свои устройства в лицензии, согласованной при приобретении продукта. В процессе эксплуатации возникают сложности, когда SOC достигает лимита на скорость загрузки событий, количество устройств, с которых оно собирает данные, или объем данных, сохраняемых системой. Порой сложно сразу оценить эти параметры при первой покупке SIEM, поэтому тщательное планирование имеет ключевое значение. SOC также должен планировать ежегодные расходы в рамках общей стоимости поддержки. Ежегодная плата за обслуживание и поддержку часто составляет от 20 до 30 процентов от первоначальной стоимости приобретения.

8.4.5 Корректировка ожиданий

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

Таблица 13. Характеристики передовых SIEM.

ХарактеристикаОписание
Пакет развертывания – агентыАгенты (также называемые коллекторами или коннекторами) обычно доступны в виде пакетов программного обеспечения, которые можно установить либо на конечное устройство в естественной точке сбора (например, на базе данных IDS или на сервере системного журнала), либо где-то еще (например, в автономной агентской системе). Хотя не существует по-настоящему «безагентской» архитектуры, передовые SIEM достаточно уважительно относятся с точки зрения требований к ресурсам хостов, которые исходно генерируют или передают данные о событиях.

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

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

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

Пакет развертывания – главный узел / менеджерМногие поставщики SIEM поставляют свой продукт как в виде аппаратного устройства, так и в виде программного обеспечения: либо в виде традиционного устанавливаемого ПО, либо в виде виртуального устройства. У каждого подхода есть свои плюсы и минусы. Чтобы масштабировать SIEM до действительно больших инсталляций, практически неизбежно развертывание пакета программного обеспечения на выбранном SOC серверном оборудовании корпоративного уровня (как правило, Linux на x86-64).

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

Некоторые SIEM разделяют функцию главного узла между двумя системами: одна система выполняет корреляцию, а на другой размещается хранилище данных, СУБД. Другие SIEM могут сбалансировать хранение событий и запросы к одному или нескольким узлам с помощью распределенного сервера NoSQL. В более простых инсталляциях (например, использующих собственное хранилище данных) и практически во всех продуктах класса LM внешний менеджер запросов и внутреннее хранилище данных объединены в одной физической системе.

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

Хранение данныхПродукты SIEM и LM теоретически способны хранить события, собранные за многие годы и даже десятилетия. Но длительность хранения обычно ограничивается периодом работы с момента первой итерации. Некоторые продукты класса SIEM и LM при крупном обновлении не поддерживают перенос данных  настолько просто, как хотелось бы. В некоторых случаях SOC может предпочесть новую инсталляцию SIEM, чтобы начать с чистого листа. Это может стать проблематичным, поскольку SOC будет менять множество поколений продуктов SIEM, в то же время продолжая стремиться к долгосрочному хранению данных аудита.

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

Размер хранилища данныхНа момент написания этой книги продвинутые инсталляции SIEM обычно имели хранилища данных объемом от нескольких терабайт до 50 ТБ или более. Выход за пределы 10 или 20 ТБ – вызов для возможностей хранилищ некоторых продуктов. Многие поставщики, использующие собственные бэкэнды, рекламируют коэффициент сжатия данных 5:1 или 10:1 по сравнению с реляционной базой данных. При нагрузках в 100 миллионов событий в день СУБД нередко сохраняет данные за 60–90 дней, тогда как запатентованное сжатое хранилище данных того же размера может сохранять события за 6–12 месяцев или более.
Количество событийПравильная реализация SIEM обычно обрабатывает события, поступающие со скоростью на уровне тысяч событий в секунду, что соответствует десяткам или сотням миллионов событий в день. Как было показано на рисунке 9 ранее, это оптимальная цифра для SIEM и LM. Хотя многие поставщики SIEM рекламируют скорость приема от 10 000 до 100 000 или более событий в секунду. При этом нужно уточнить, а каков сценарий для сбора такого объема данных в одном месте? Улучшится ли работа аналитиков благодаря распределению данных по уровням, и/или не слишком ли мы неразборчивы в отношении того, какие данные мы собираем? Нет ничего необычного в том, что устройства SIEM или LM хранят много миллиардов событий онлайн; однако преодоление отметки в триллион событий встречается реже.
Количество пользователейУ большинства поставщиков SIEM и LM продукты предназначены для работы с типичным количеством аналитиков в централизованном или распределенном SOC, где обычно около 10-50 человек фактически заходят в систему и используют продукт одновременно. Крупные SOC, у которых реализованы элементы распределенной организационной модели, например, есть аналитики «передового базирования», могут столкнуться с проблемами в масштабируемости, особенно, если дополнительным пользователям требуется отличающийся контент и отчеты, дополнительно нагружающие системные ресурсы.

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

Количество устройствНа самом деле это не должно быть ограничивающим фактором (кроме искусственных ограничений, обусловленных моделями лицензирования) ни на коллекторе, ни на главном узле. SIEM должна иметь возможность обрабатывать десятки или даже сотни тысяч конечных устройств по различным каналам передачи данных (что нередко встречается у крупных предприятий). SIEM также должна иметь возможность распознавать несколько потоков данных с одной и той же конечной точки (например, антивирусные данные, журналы событий безопасности Windows и сканирования уязвимостей). Хорошо спроектированное программное обеспечение агента должно справляться со многими устройствами (возможно, десятками тысяч), чей суммарный поток событий может поддерживать более тысячи событий в секунду.
Ответ на запросыАналитик ожидает, что большинство его запросов будут обработаны устройством SIEM или LM в течение нескольких секунд или минут. В типичных сценариях, когда собирается несколько миллионов событий в день, это может означать, что правильно сформированные запросы могут обрабатываться несколько дней с бэкэндами на базе СУБД или, возможно, несколько недель с проприетарными бэкэндами. Если, например, мы ищем IP-адрес среди данных за день и не получаем ответ через минуту или две, стоит изучить политики получения данных или методики оптимизации хранилища данных.

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

Большинство исторических предположений о производительности SIEM и LM основаны на использовании жестких дисков и хранилищ данных по типу реляционной СУБД. Благодаря твердотельному хранилищу и механизмам запросов MapReduce можно создавать гораздо более сложные запросы к данным, собранным в течение более длительных периодов времени. SOC, которым нужна расширенная долгосрочная аналитика или возможности создания запросов для поддержки больших пользовательских нагрузок, могут (1) рассмотреть бэкэнды SIEM, которые располагают некоторые или все свои хранилища событий на SSD, или (2) использовать облачные технологии, которые задействуют методы MapReduce для масштабирования.

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

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

8.4.6. Рекомендации и наблюдения

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

Инструменты безопасности и управления сетью не взаимозаменяемы

SIEM и системы управления сетью (NMS) обладают во многом схожими архитектурными функциями, такими как возможность агрегировать большой объем данных журнала и оповещений, обрабатывать их и визуализировать. К журналам и оповещениям продуктов безопасности, как правило, относятся с меньшим доверием, чем в других областях ИТ, таких как сети. Когда маршрутизатор сообщает, что его вентиляторы вращаются медленно, а коммутатор сообщает, что порт не работает, это почти наверняка так. Когда IDS сообщает: «Вас взломали», скорее всего, все в порядке. У SIEM богатый набор функций для обеспечения рабочего процесса, необходимого для обработки событий и оценки истинности или ложности срабатывания.

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

Лучшие SIEM создавались с нуля как SIEM

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

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

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

Рассматривайте весь пакет

Рассматривая покупку LM или SIEM, многие SOC фокусируются на одном критерии – «Может ли продукт принимать данные такого-то типа?». Это очень напоминает покупку автомобиля исключительно исходя из того, с какими шинами он поставляется или какого он цвета. Безусловно, это важные вещи, но (1) владелец их может изменить при небольших затратах, и (2) есть гораздо более важные параметры, такие как скорость, надежность и удобство работы.

Большинство хороших SIEM-систем могут принимать практически любой возможный поток данных, относящихся к безопасности, либо из коробки, либо через какой-либо набор средств разработки программного обеспечения (SDK) агента. Что не важно: «Может ли SIEM принять мои данные?» Это само собой разумеется. Что важно: «Что я могу сделать с данными после того, как моя SIEM соберет их?»

Вы получите то, за что заплатите

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

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

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

Учитывая, что потребности SOC в сетевых IDS или сканировании уязвимостей можно удовлетворить свободными приложениями/приложениями с открытым исходным кодом (FOSS) мирового класса (Snort и Nessus соответственно), открытых SIEM существует гораздо меньше. Хотя некоторые предложения все-таки существуют (например, Open Source Security Information Management (OSSIM)), учитывайте сложность создания и поддержки надежной SIEM – не говоря уже о растущем наборе типов данных и агентов. К тому же, у большинства организаций, которым нужен качественный инструмент для сбора данных сетевой безопасности корпоративного уровня, хорошее финансирование. В случае Snort широкая база пользователей способна постоянно улучшать сложную базу кода. SIEM, для сравнения, имеет такую же или большую сложность, но меньше потенциальных клиентов. Тем не менее, есть некоторые инструменты FOSS (например, S/GUIL), которые успешно поддерживают анализ сетевой безопасности в реальном времени с несколькими потоками данных, отчасти потому, что они не пытаются реализовать весь набор функций SIEM. Инструменты FOSS, ориентированные на LM, без избыточной сложности полноценного SIEM, также обеспечивают необходимые функции и производительность (например, Logstash и Kibana).

День на установку; год на настройку

Начальная настройка SIEM довольно проста, ее можно выполнить за один или два дня для одного экземпляра корпоративного уровня. Через несколько недель или месяцев можно подключить и настроить первые несколько каналов данных и начать создание контента, обеспечивающего быстрые успехи. Однако обеспечение системы нужными данными, ее настройка, написание контента для клиентских организаций и полная интеграция в работу занимает год или более – по политическим и технологическим причинам, а не по техническим причинам. Во многих случаях получение владельцами данных надежных и устойчивых каналов журналов аудита может быть политически сложным процессом. Как правило, чем надежнее SIEM, тем круче кривая обучения – не потому, что интерфейс может быть неудобным (хотя иногда это так), а потому, что даже самым умным аналитикам требуется время, чтобы освоить инструмент. Студент-будущий программист может изучить основы C или Java за несколько недель, но чтобы стать действительно опытным специалистом в языке, потребуется намного больше времени. По сути, то же самое относится и к SIEM. Необходимо также учитывать время на интеграцию функций SIEM в операции SOC (например, обучение пользователей и написание рабочих инструкций).

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

Каждое подразделение SOC будет использовать SIEM по-своему

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

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

Должны ли сотрудники вне SOC – персонал службы безопасности, системные администраторы и CISO – получать прямой доступ к необработанным данным безопасности в SIEM?

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

Во-первых, хочет ли SOC, чтобы кто-то вне SOC обнаружил вторжение раньше него? Некоторые CISO выразили желание в режиме реального времени просматривать состояние безопасности своего предприятия. Однако, подумайте: CISO увидит что-то в консоли и позвонит, прежде чем SOC получит все ответы или даже заметит то, что увидел CISO — это не очень хорошая ситуация. Во многих случаях CISO или ИТ-директору достаточно получать еженедельные или месячные сводки значимых событий или еженедельных показателей. И, по крайней мере, можно доверять SOC, когда действительно происходит что-то плохое.

Во-вторых, не каждому нужен доступ ко всем данным. Если SOC открывает доступ внешним сторонам, очень вероятно, что им нужно видеть только часть данных, которая относится к их зоне ответственности. Возможно, они не увидят события в реальном времени и смогут запрашивать события спустя 24 часа. Тем самым миссия SOC не потеряет в значимости – он по-прежнему предоставляет доступ к данным в реальном времени.

В-третьих, и, возможно, это самое важное: предоставление большого количества журналов безопасности различным сторонам может привести к возникновению внутренних угроз. Антивирус должен предупреждать, когда пользователи загружают известное программное обеспечение для взлома паролей и сканирования портов. Журналы FTP могут выявить утечку информации и удаление данных. Журналы приложений и веб-серверов могут указывать на злонамеренное или ненадлежащее поведение привилегированных пользователей. В некоторых случаях злоумышленник может получить доступ к журналам до того, как специалисты завершат расследование. Рекомендуется, чтобы SOC отслеживали, кому и какие необработанные данные передаются. В качестве альтернативы для снижения риска можно предоставлять сводные отчеты.

Новые инструменты = новые процессы

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

Для Линии 1 могут быть настроены представления, чтобы аналитики просматривали только самые важные события (которые составляют 0,001 процента от всех собранных данных). Эти события можно по-прежнему прокручивать в реальном времени, но система ценна тем, что частично автоматизирует сортировку данных. Аналитики должны быть свободны для анализа; монотонность препятствует любопытству и будет провоцировать самых талантливых аналитиков уходить.

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

Эффективность SIEM определяется данными

Старая поговорка «мусор на входе — мусор на выходе» идеально подходит для SIEM. Мы уже обсудили, что ценность даже самых актуальных и подробных журналов безопасности может быть снижена, если хранить все подряд. Очень важно выбирать и настраивать каналы данных, соответствующие окружению угрозам, уязвимостям и задачам. (См. Раздел 9.2.)

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

Можно обойти отсутствие единого общего стандарта данных

Развитие агрегации данных аудита и управления данными безопасности сопровождается отраслевыми стандартами, ни один из которых не получил всеобщего распространения: Common Intrusion Detection Framework (CIDF), Incident Object Description и Exchange Format (IODEF), Security Device Event Exchange (SDEE), WebTrends Enhanced Log File (WELF), Common Event Infrastructure/Common Base Event (CEI/CBE), Common Event Format (CEF), Common Event Expression (CEE). Их объединяет стремление предоставить независимый от поставщика формат для записи и приема данных, относящихся к безопасности.

Если посмотреть ведущие SIEM продукты, можно обнаружить десятки, если не сотни, анализаторов данных, каждый для своего типа устройства и поставщика. Поставщики SIEM тратят много ресурсов, чтобы поддерживать актуальность этих интерпретаторов. Это может быть особенно неприятно для SOC, которые хотят интегрировать в SIEM менее популярные или нестандартные источники данных, даже с хорошим SDK анализатора от поставщика.

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

Возможности автоматического реагирования порождают те же проблемы, что и IPS

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

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

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

SOC должны организовать сбор и хранение данных для поддержки уголовного, гражданского и административного судопроизводства

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

Поделиться записью: