SIEM- и IRP-системы: практика работы с повторяющимися киберинцидентами

SIEM- и IRP-системы: практика работы с повторяющимися киберинцидентами

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

 

 

 

 

 

  1. Введение
  2. Работа с повторяющимися инцидентами в SIEM-системе
  3. Работа с повторяющимися инцидентами в IRP-системе
  4. Выводы

 

Введение

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

Повторяющийся инцидент — такой, для которого можно и целесообразно идентифицировать аналогичный зарегистрированный ранее инцидент. Разберёмся, что подразумевается под «можно» и «целесообразно».

Под «можно» мы понимаем то, что у инцидентов, генерируемых одним правилом корреляции, есть набор идентичных полей. Например, для регистрации сетевой атаки средствами IDS это могут быть такие поля, как источник соединения (source IP address) и приёмник соединения (destination IP address). Соответственно, два инцидента, у которых совпадают IP-адреса источника и приёмника, «можно» считать повторяющимися.

Под «целесообразно» мы понимаем то, что у инцидентов, генерируемых одним правилом корреляции, есть набор не только идентичных, но и различающихся полей. Эти различающиеся поля дают нам дополнительный контекст, например идентификатор сетевой атаки. Поэтому «нецелесообразно» считать повторяющимися два инцидента регистрации сетевой атаки средствами IDS, если у них обнаружены одинаковые адреса источника и приёмника, но при этом характер сетевой атаки в одном случае говорит нам о вирусном заражении, а в другом — о полной компрометации узла сети.

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

 

Работа с повторяющимися инцидентами в SIEM-системе

Одним из способов такой работы является агрегация инцидентов на уровне SIEM. Процесс этот может быть построен на базе нескольких основных механизмов:

  • на уровне создания инцидента (например, регистрировать происшествие при первом срабатывании правила, а потом агрегировать в него новые повторяющиеся срабатывания на протяжении настраиваемого промежутка времени),
  • на уровне записи полей инцидента, по которым можно судить о повторе регистрируемой ситуации, в специальный список (с последующим запретом на создание инцидента при наличии соответствующей записи в списке — глушением правила корреляции).

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

Для построения связей и накопления статистики по повторяющимся инцидентам можно модифицировать второй вариант агрегации — через накопление специальных списков — путём отказа от грубого глушения в пользу фиксации времени между срабатываниями правил.

Рассмотрим реализацию на том же примере регистрации сетевой атаки средствами IDS.

Для начала выделим поля, по которым мы можем идентифицировать повторяющиеся инциденты. Например, IP-адрес источника соединения (src_ip), IP-адрес приёмника соединения (dst_ip), идентификатор атаки (attack_id).

При использовании метода грубого глушения срабатывания правила список будет выглядеть примерно так (табл. 1).

 

Таблица 1. Пример списка, используемого для глушения повторяющихся срабатываний правила корреляции

Тип данных Datetime IP/string IP/string String
Колонка Last_seen Src_ip Dst_ip Attack_id
Значения 13.04.2020 16:10:45 192.168.0.52 192.168.1.63 MS17-010.Intr
Значения 16.03.2020 10:07:16 192.168.2.73 192.168.3.84 SQL.Inject

 

При этом новых срабатываний правила корреляции в виде инцидента для комбинации полей «192.168.2.73 — 192.168.3.84 — SQL.Inject» не появится, пока запись не покинет список (вручную, по TTL и т.д.). Иначе говоря, мы знаем о первом возникновении инцидента, а повторяющиеся (дочерние к первому) либо не были зарегистрированы, либо потребуют обращения к базе событий для получения статистики по ним.

Модифицированный список будет выглядеть следующим образом (табл. 2).

 

Таблица 2. Пример модифицированного списка

 

Тип данных Datetime String IP/string IP/string String Datetime Datetime Int Int
Колонка Last_seen Inc_id Src_ip Dst_ip Attack_id First_seen Last_report Count Count_rep
Значения 14.04.2020 09:16:47 736354 192.168.0.52 192.168.1.63 MS17-010.Intr 13.04.2020 16:10:45 13.04.2020 16:10:45 2 1
Значения 14.04.2020 08:24:59 743947 192.168.2.73 192.168.3.84 SQL.Inject 16.03.2020 10:07:16 14.04.2020 08:25:02 14 7

 

Рассмотрим подробнее добавленные колонки:

  • Inc_id — идентификатор первого (родительского) инцидента. Данный идентификатор будет использоваться для обогащения повторяющегося инцидента.
  • First_seen — дата первого обнаружения, т.е. дата регистрации родительского инцидента.
  • Last_report — дата последнего оповещения о повторившемся инциденте.
  • Count — количество повторяющихся срабатываний правила корреляции.
  • Count_rep — количество зарегистрированных инцидентов (первый + повторяющиеся).

Теперь для атаки «192.168.2.73 — 192.168.3.84 — SQL.Inject» мы сразу можем увидеть, что:

  • было зарегистрировано 7 инцидентов,
  • само правило корреляции сработало 14 раз,
  • первый (родительский) инцидент имеет идентификатор 743947,
  • первый (родительский) инцидент был зарегистрирован 16.03.2020 в 10:07:16.

Модификация правила корреляции для использования такого подхода будет выглядеть следующим образом.

Во-первых — определение временного интервала, на протяжении которого новые дочерние инциденты регистрироваться не будут, но будет накапливаться счётчик срабатываний правил корреляции. Данный интервал зависит от особенностей инфраструктуры и взаимодействия между службами ИТ и ИБ; он должен учитывать ориентировочные сроки реагирования на инцидент.

Во-вторых — доработка правила в части действий при регистрации повторяющегося инцидента: не регистрировать новый инцидент, если разница по времени между колонками «Last_seen» и «Last_report» не превышает выбранного ранее временного интервала, но увеличить счётчик обнаружений, и зарегистрировать новый (повторяющийся, дочерний) инцидент, если разница по времени между колонками «Last_seen» и «Last_report» превысила выбранный ранее временной интервал, увеличив счётчики обнаружения и оповещения.

Итоги такой доработки правила корреляции:

  • Установлен временной порог регистрации инцидентов между повторяющимися срабатываниями правила корреляции.
  • Не теряются данные о повторяющихся срабатываниях правила внутри выбранного временного порога.
  • Формируется наглядный список, в котором доступны статистические данные по повторяющимся инцидентам.

 

Работа с повторяющимися инцидентами в IRP-системе

На выходе из SIEM-системы в IRP попадают инциденты в сфере ИБ для осуществления дальнейшего реагирования. При использовании подхода к определению повторяющихся происшествий на уровне SIEM-системы на входе в IRP мы получим не просто новое событие, а инцидент с явным обозначением того, что он повторяющийся (дочерний), и с идентификатором, по которому сможем связать его с родительским.

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

Дополнительным «плюсом» станут отчёты из IRP-системы, в которых явно будут обозначены «хронические» проблемы в инфраструктуре. Если же подсистема отчётности в IRP не сможет дать такой аналитики, то последнюю можно забрать из статистических списков SIEM-системы и визуализировать отдельно.

 

Выводы

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

Полезные ссылки: 
Anti-Malware TelegramПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru