Новости

Awesome Image
Awesome Image

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


Введение 


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Автор:

Михаил Малышев,

эксперт оператора сервисов киберзащиты CyberART

Оригинал статьи опубликован на Anti-Malware.