В конце стати вы сможете пройти тестирование по курсу и получить сертификат от платформы TS University!
|
Для чего нужны правила корреляции
Корреляционное событие — событие информационной безопасности, представляющее собой совокупность полей, заполненных данными о возможном нарушении согласно правилам, указанным в правиле корреляции.
- Инцидент — корреляционное событие, связанное с нарушением информационной безопасности. Сведения об инцидентах оперативно передаются оператору MaxPatrol SIEM.
Корреляция событий выполняется по созданным заранее правилам.
Правила корреляции бывают:
- стандартными;
- пользовательскими.
Пользовательские правила корреляции вы можете создавать, изменять, копировать и удалять.
Правило корреляции имеет следующие параметры:
- системное название: должно совпадать с названием, указанным в коде правила в директиве rule (директива rule предназначена для описания правила корреляции) и будет совпадать с названием файла правила;
- папка: папка или пакет экспертизы для хранения правила в БД;
- набор для установки: набор объектов, в составе которого правило будет устанавливаться в MaxPatrol SIEM (правило может быть добавлено одновременно в несколько наборов);
- может иметь описание на русском или английском языке;
- правило локализации: правило, согласно которому с корреляционными событиями, зарегистрированными по правилу в веб-интерфейсе MaxPatrol SIEM связывается определенное описание на русском или английском языке
Как было описано в предыдущей статье: в пакетах экспертизы есть возможность посмотреть правила корреляции.
![](https://static.tildacdn.com/tild3264-6463-4034-a463-653438343765/_SIEM__71.png)
Структура правила корреляции
Правило корреляции состоит из последовательности директив, содержащих инструкции и команды.
Для работы правила корреляции необходимо указать обязательные директивы и инструкции:
- Директива «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»;
- тип входа или выхода: удаленный по сети (не берем локальную аутентификацию);
- и стандартная обвязка для белых списков для исключения дефолтного логина при необходимости
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"
}
В правилах локализации укажем:
- Критерии:
- Значение (английский):
- Значение (русский):
- Критерии:
- Значение (английский):
- Значение (русский):
Отладка правил корреляции
Воспользуемся утилитой PTSIEMSDK GUI для отладки данного правила корреляции.
Утилита предназначена для создания и отладки отдельных правил нормализации, агрегации, обогащения, корреляции и локализации, а также для отладки их совместной работы.
Добавление правил в MaxPatrol SIEM выполняется через веб-интерфейс Knowledge Base. Утилита входит в комплект поставки MaxPatrol SIEM.
В поле «Правило» вводим код правила, в поле «тестовый сценарий» исходное событие, взятое из MaxPatrol SIEM, и запускаем наше правило. В поле результат мы увидим сообщение о работе правила:
![](https://static.tildacdn.com/tild6631-6162-4565-b865-376666653437/_SIEM__72.png)
Как видим правило успешно прошло отладку.
Далее переходим в интерфейс Knowledge Base и добавляем наше правило и табличный список. Для этого в пакетах экспертизы создадим папку Password Policy и две вложенных папки «correlation_rules» и «tabular_lists»:
![](https://static.tildacdn.com/tild3634-6235-4561-a564-346336343762/_SIEM__73.png)
Создадим табличный список типа «Справочник». Ключевым полем будет поле «account». Добавим в табличный список записи с дефолтными логинами.
![](https://static.tildacdn.com/tild3935-6439-4262-b132-373166386661/_SIEM__75.png)
![](https://static.tildacdn.com/tild6237-6536-4333-b833-356238373061/_SIEM__74.png)
Добавим правило корреляции в редакторе кода:
![](https://static.tildacdn.com/tild3536-3335-4164-b935-666332636136/_SIEM__76.png)
Далее проводим валидацию и устанавливаем в SIEM табличный список и правило корреляции.
Проверим работу нашего правила. Для этого войдем в систему на каком-нибудь подключенном в SIEM узле под логином administrator.
![](https://static.tildacdn.com/tild3834-6638-4539-b337-356362316465/_SIEM__77.png)
![](https://optim.tildacdn.com/tild3066-6530-4330-a533-313537373032/-/format/webp/_SIEM__78.png)
Правило корреляции сработало и SIEM сгенерировал инцидент. Профит!
Заключение
В данной статье мы ознакомились с правилами корреляции и написали собственное правило. На этом наш курс подошел к концу: надеемся, что он помог вам разобраться в базовом функционале системы выявления инцидентов MaxPatrol SIEM от отечественного вендора Positive Technologies.
Смотрите вебинары, читайте статьи и проходите курсы по интересующим вендорам на потале
До встречи!
Автор курса: Кузнецова Елизавета, Инженер информационной безопасности в TS Solution.
Пройти тестирование и получить сертификат о прохождении курса можно по |