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. Пример списка, используемого для глушения повторяющихся срабатываний правила корреляции

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

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

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

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

• 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-системы, который в процессе реагирования на повторяющийся инцидент в сфере ИБ будет сразу вооружён дополнительным контекстом.