Comments 14
На самом деле основная проблема в плохо работающей корреляции как раз в том, что вендоры пытаются нормализовывать и категоризировать события отдельно друг от друга.
Не учитывая информацию, которая могла бы быть необходима для соответствующих корреляционных правил.
Да, верно, в этом тоже есть большая проблема. К сожалению я ее не затронул в этой статье.
Видится, что для ее решения надо выработать какой-то отраслевой стандарт. Этот цикл статей — робкая попытка начать наводить порядок хотя бы в рамках одной компании/вендоре. Если выработанные практики можно будет масштабировать, будет успех. На отраслевой стандарт, я пока не замахиваюсь. Здесь ключевое слово "пока" :)
В том же примере с Ораклом получается, что поле src.ip пустое (хотя пора бы уже научится резолвить хосты). А в других событиях оно может быть заполненным.
Или же вообще отсутствовать информация о сорс хосте
А в некоторых случаях — собираться из нескольких РАЗНЫХ событий
Либо имеем актуальные активы и захлебывающийся DNS либо работающий DNS и слегка актуальные активы.
И для того, чтобы корреляция в итоге учитывала эти варианты, «эксперты» должны делать нормализацию и категоризацию исходя из того, какие поля будут (и должны в идеале быть заполнены) использоваться в корреляции. И при необходимости не вешать категории на исходные события, а заполнять их на уровне обогащения, корреляции и т.д.
В этом случае и с поиском будет намного проще :)
В данном подходе категория отражает суть исходного события. Суть может быть определена на этапе нормализации (даже с пропущенными данными)
Категория определяет правила заполнения нужных полей. Но что делать с пропущенными данными (src.ip — действительно такой случай)? Восполнить такие пропуски можно обогащением (когда это возможно, но это далеко не всегда так). Т.о. зачем дотягивать категоризацию до обогащения?
Для того, чтобы во всех событиях одинаковой категории была вся необходимая информация (мой любимый пример с стартом\завершением vpn-сессий)
Когда мы ищем события определенной категории — хочется иметь всю информацию в событии, а не собирать ее каждый раз из разных
Когда мы делаем правило по категории событий — хочется быть уверенным, что в любом событии в этой категории будет вся необходимая информация. Как раз чтобы на этом уровне реализовывать логику детекта, а не очередной парсинг и исправление ведорских (тут я про тех, кто логи в продуктах создает) особенностей
А дьявол, как говорится, в деталях :)
И в данном случае они именно тут. Ибо если смотреть не на событие как оно есть, а на событие как оно могло бы быть — то можно и аудит где-то сделать другой. И категории вешать позже :)
Глубины SIEM: корреляции «из коробки». Часть 3.2. Методология нормализации событий