Курс MaxPatrol SIEM Getting Started. Статья 7: Правила корреляции

Приветствуем вас в заключительной статье нашего базового курса «MaxPatrol SIEM Getting Started». В прошлой статье мы поговорили о правилах нормализации и рассмотрели пример написания такого правила в MaxPatrol SIEM. В данном материале мы обсудим правила корреляции, а также напишем такое правило, используя примеры правил нормализации из предыдущей статьи.

В конце стати вы сможете пройти тестирование по курсу и получить сертификат от платформы TS University!

Для чего нужны правила корреляции

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

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

• Инцидент — корреляционное событие, связанное с нарушением информационной безопасности. Сведения об инцидентах оперативно передаются оператору MaxPatrol SIEM.
  

Настройка корреляции событий


Корреляция событий выполняется по созданным заранее правилам.
Правила корреляции бывают:

• стандартными;
  
• пользовательскими.
  

Стандартные правила корреляции разработаны специалистами по информационной безопасности Positive Technologies и не могут быть изменены. Вы можете просматривать стандартные правила корреляции и копировать их для создания пользовательских правил.

Пользовательские правила корреляции вы можете создавать, изменять, копировать и удалять.

Правило корреляции имеет следующие параметры:

• системное название: должно совпадать с названием, указанным в коде правила в директиве rule (директива rule предназначена для описания правила корреляции) и будет совпадать с названием файла правила;
  
• папка: папка или пакет экспертизы для хранения правила в БД;
  
• набор для установки: набор объектов, в составе которого правило будет устанавливаться в MaxPatrol SIEM (правило может быть добавлено одновременно в несколько наборов);
  
• может иметь описание на русском или английском языке;
  
• правило локализации: правило, согласно которому с корреляционными событиями, зарегистрированными по правилу в веб-интерфейсе MaxPatrol SIEM связывается определенное описание на русском или английском языке
  

Стандартные правила в Knowledge Base

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




Структура правила корреляции


Правило корреляции состоит из последовательности директив, содержащих инструкции и команды.

Для работы правила корреляции необходимо указать обязательные директивы и инструкции:

• Директива «event» используется для объявления события, подлежащего корреляции
  Для объявления нескольких событий с разными названиями в одном правиле можно использовать несколько директив «event». Директива может содержать инструкцию «key» для указания полей события, по значению которых разделяется поток событий, и должна содержать инструкцию «filter» для настройки условия отбора события;
  
• Директива «rule» используется для описания правила корреляции.
  В директиве нужно указать условие выполнения правила корреляции. Название, указанное в директиве, является уникальным названием правила корреляции. Все события, используемые при составлении условия правила корреляции, должны быть объявлены с помощью директив «event».
  
  Директива может содержать инструкцию «init» для объявления переменных и по одной инструкции on для каждого объявленного события. Инструкция «on» (обработчик события) используется для выполнения блока операторов при регистрации события, указанного в этой инструкции. Директива «rule» может содержать инструкции «insert_into, remove_from, clear_table» для редактирования табличного списка;
  
• Директива «emit» используется для заполнения полей корреляционного события и настройки регистрации инцидента при выполнении правила корреляции
  Правило корреляции может содержать директиву «query» для объявления запроса к табличному списку. В одном правиле можно объявить несколько запросов с разными названиями
  

Структура правила корреляции следующая:

query <Название запроса1>(<Аргументы запроса1>) from <Название табличного списка1> {
<Условие запроса1>
}

event <Название события1>:
key:
<Поле события 1>, <Поле события 2>, ...
filter {
<Условие отбора события>
}

rule <Название правила>: <Условие правила корреляции>

init {
<Блок операторов init>
}

on <Название события1> {
<Блок для заполнения полей события>
}

insert_into <Название табличного списка> {
<Блок операторов insert_into>
}
remove_from <Название табличного списка> {
<Блок операторов insert_into>
}
clear_table <Название табличного списка> {
<Блок операторов insert_into>
}

emit {
<Блок для заполнения полей события>
<Блок для настройки инцидента>
}


Пример написания правила корреляции


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

Основная идея правила: в событиях типа «action = login» проверять поле «account» по списку дефолтных логинов:

1) Объявляем директиву «query» для объявления запроса к нашему табличному списку.

query DefaultAccountQuery($account) from Default_accounts {
column::account == $account
}

Условие запроса возвращает «True» если переданная в запрос УЗ находится в табличном списке.

2) Далее объявляем событие, подлежащее корреляции. В нашем случае это события «Login» и «Logout». В поле «key» указываем поля «event_src.host», «subject.name» по значению которых будет разделяться поток событий.

В инструкции «filter» указываем поля для настройки условия отбора события:

• действие: вход или выход;
  
• субъект: УЗ (account);
  
• обязательно должно присутствовать значение УЗ, которое сохраняется в полях «subject.name» или «subject.account.name»;
  
• тип входа или выхода: удаленный по сети (не берем локальную аутентификацию);
  
• и стандартная обвязка для белых списков для исключения дефолтного логина при необходимости
  

event Login:
key:
event_src.host, subject.name
filter {
filter::NotFromCorrelator()
and action == "login"
and subject == "account"
and (subject.name != null or subject.account.name != null)
and (logon_auth_method == 'remote')
and (exec_query("DefaultAccountQuery", [subject.name]) or exec_query("DefaultAccountQuery", [subject.account.name]))
and filter::CheckWL_Specific_Only("Default_account_usage", lower(subject.account.name))
}

event Logout:
key:
event_src.host, subject.name
filter {
filter::NotFromCorrelator()
and action == "logout"
and subject == "account"
and (subject.name != null or subject.account.name != null)
and (logon_auth_method == 'remote')
and (exec_query("DefaultAccountQuery", [subject.name]) or exec_query("DefaultAccountQuery", [subject.account.name]))
and filter::CheckWL_Specific_Only("Default_account_usage", lower(subject.account.name))
}

3) Следующим шагом объявляем директиву «rule» для описания правила корреляции:

rule Default_account_usage: (Login+ or Logout+) timer 10s

init {
$labels = "w_auto|default_subject_account_usage"
}

on Login {
$subject.account.name = subject.account.name
$subject.account.domain = subject.account.domain
$subject.name = subject.name

$src.host = src.host
$src.fqdn = src.fqdn
$src.hostname = src.hostname
$src.ip = src.ip
$src.asset = src.asset

if subject.name != null then
$alert.key = lower(subject.name)
elif subject.account.name != null then
$alert.key = lower(subject.account.name)
endif

$event_src.ip = event_src.ip
$event_src.hostname = event_src.hostname
$event_src.fqdn = event_src.fqdn
$event_src.host = event_src.host
$event_src.asset = event_src.asset
$event_src.vendor = event_src.vendor
$event_src.title = event_src.title
$event_src.id = event_src.id

$labels = $labels + "|CheckWL_Specific_Only"
}

on Logout {
$subject.account.name = subject.account.name
$subject.account.domain = subject.account.domain
$subject.name = subject.name

$src.host = src.host
$src.fqdn = src.fqdn
$src.hostname = src.hostname
$src.ip = src.ip
$src.asset = src.asset

if subject.name != null then
$alert.key = lower(subject.name)
elif subject.account.name != null then
$alert.key = lower(subject.account.name)
endif

$event_src.ip = event_src.ip
$event_src.hostname = event_src.hostname
$event_src.fqdn = event_src.fqdn
$event_src.host = event_src.host
$event_src.asset = event_src.asset
$event_src.vendor = event_src.vendor
$event_src.title = event_src.title
$event_src.id = event_src.id

$labels = $labels + "|CheckWL_Specific_Only"
}

4) Завершаем написание правила директивой «emit», которая используется для заполнения полей корреляционного события:

emit {
$correlation_type = "incident"

$subject = "account"
$action = "login"
$object = "system"
$status = "success"

$category.generic = "Compliance"
$category.high = "Policy Violation"
$category.low = "IM Policy Violation"

$importance = "high"

$incident.severity = "high" #уровень опасности инцидента
$incident.category = "PermissionViolation" #тип инцидента
$incident.aggregation.timeout = 2h #время агрегации инцидента

$id = "TSS_Password_Policy_Default_account_usage"
}

В правилах локализации укажем:

• Критерии:
  

id = "TSS_Password_Policy_Default_account_usage" and action = 'login'

• Значение (английский):
  

The user logged in to the system from remote host {src.ip} using default accounts {subject.name}.

• Значение (русский):
  

Пользователь с удаленного узла {src.ip} осуществил вход в систему под дефолтной учетной записью {subject.name}.

• Критерии:
  

id = "TSS_Password_Policy_Default_account_usage" and action = 'logout'

• Значение (английский):
  

The user log off the system from remote host {src.ip} using default accounts {subject.name}.

• Значение (русский):
  

Пользователь с удаленного узла {src.ip} осуществил выход из системы, используя дефолтную учетную запись {subject.name}.


Отладка правил корреляции

Воспользуемся утилитой PTSIEMSDK GUI для отладки данного правила корреляции.

Утилита предназначена для создания и отладки отдельных правил нормализации, агрегации, обогащения, корреляции и локализации, а также для отладки их совместной работы.
Добавление правил в MaxPatrol SIEM выполняется через веб-интерфейс Knowledge Base. Утилита входит в комплект поставки MaxPatrol SIEM.

В поле «Правило» вводим код правила, в поле «тестовый сценарий» исходное событие, взятое из MaxPatrol SIEM, и запускаем наше правило. В поле результат мы увидим сообщение о работе правила:





Как видим правило успешно прошло отладку.

Далее переходим в интерфейс Knowledge Base и добавляем наше правило и табличный список. Для этого в пакетах экспертизы создадим папку Password Policy и две вложенных папки «correlation_rules» и «tabular_lists»:



Создадим табличный список типа «Справочник». Ключевым полем будет поле «account». Добавим в табличный список записи с дефолтными логинами.




Добавим правило корреляции в редакторе кода:



Далее проводим валидацию и устанавливаем в SIEM табличный список и правило корреляции.

Проверим работу нашего правила. Для этого войдем в систему на каком-нибудь подключенном в SIEM узле под логином administrator.




Правило корреляции сработало и SIEM сгенерировал инцидент. Профит!


Заключение

В данной статье мы ознакомились с правилами корреляции и написали собственное правило. На этом наш курс подошел к концу: надеемся, что он помог вам разобраться в базовом функционале системы выявления инцидентов MaxPatrol SIEM от отечественного вендора Positive Technologies.

Смотрите вебинары, читайте статьи и проходите курсы по интересующим вендорам на потале TS University .
До встречи!

Автор курса: Кузнецова Елизавета, Инженер информационной безопасности в TS Solution.