<h1>2. Нормализация и корреляция событий информационной безопасности.</h1>
Операционная система IBM AIX приносит в SIEM ряд событий, из которых в
данном случае нас интересуют два:
Событие входа пользователя по SSH:
```
А) <134>Sep 22 05:01:48 Message forwarded from sovma131: audit:USER_Login root OK sshd user: ektest tty: ssh
Б) <134>Sep 22 04:54:46 audit: USER_Login root OK sshd user: ektest tty: ssh
```
Событие чтения конфигурационного файла операционной системы:
```
А) May 19 09:50:06 aix53 local0:info audit: OS_CONF_READ mp OK cat audit
object read event detected /etc/shadow
Б) Jun 3 00:10:05 aix53 local0:info audit: OS_CONF_READ mp OK cat audit
object read event detected /etc/ssh/sshd_config
```
### Создание правила нормализации
Созададим правило нормализации для данного события:
Начнем с импорта событий
и вставки шаблона
Запишем событие в форматную строку
и начнем парсить событие
Начнем с даты события
Так как дата в каждом событии разная то необходимо ее вытянуть из события с помощью токена {time = DATETIME}
Далее в форматной строки вытянем номер события с помощью токена {NUMBER} так как номер события тоже меняется
Добавим токен {msgid=WORD} чтобы получить уникальный идентификатор события
Далее отпарсим источник от которого приходят события с помощью токена {src.asset = WORD}
Далее отпарсим субъект куда происходит подключение {subject.account.name = STRING}
Добавим токен {protocol.layer7=WORD} чтобы вытянуть протокол из события
Добавим упрощенный оператор switch для идентификации статуса Login, тут мы добавляем новую переменную, в которую будет записываться значение статуса аутентификации, а switch будет проверять переменную по всем кейсам, которые мы задали и выдаст итоговое значение 
Так как у нас в 1 событии встречаются опциональные части то мы добавляем оператор токена "?" 
Результатом мы видим, что правило нормализации срабатывает на 2 события
1
2
Далее добавим метаданные с помощью редактора метаданных
Добавим в правило еще некоторые поля, отредактируем старые и получим конечный результат
Далее создадим новое правило нормализации для второго события
Начнем с времени
Далее вытянем источник события
и так как он может быть опциональным добавим оператор токена "?"
Далее добавим логин учетной записи события с помощью токена {subject.account.name}
Добавим идентификатор утчетной записи с помощью токена {subject.account.id}
Далее с помощью оператора switch распарсим ответ
Теперь вытащим использованую команду с помощью токена {subject.process.cmdline}
Определим рабочую директорию исполняемого процесса с помощью токена {subject.process.cwd}
Как результат это правило нормализации отрабатывает для двух событий
Добавим дополнительные поля правила
Заполним метаданные
Итоговое правило №1
```
TEXT = '<{NUMBER}>{time = DATETIME} {"Message forwarded from"?} {src.hostname = WORD?} {":"?} audit: {msgid = WORD} root {$R = WORD} sshd user: {subject.account.name = STRING} tty: {protocol.layer7=WORD}'
object = "system"
importance = "info"
subject = "account"
action = "login"
status = switch $R
case "OK" "success"
case "FAIL" "failure"
case "FAILURE" "failure"
endswitch
id = "PT_IBM_AIX_syslog_USER_Login_root"
event_src.category = "AAA"
event_src.title = "AIX"
event_src.vendor = "IBM"
```
Итоговое правило №2
```
# Примеры исходных событий
TEXT = '{time = DATETIME} {src.hostname = STRING} local0:info audit: {msgid = STRING} {subject.account.name = STRING} {$R = WORD} {subject.process.cmdline = WORD} audit
object {datafield1 = STRING} event detected {subject.process.fullpath = STRING}'
object = "system"
importance = "info"
subject = "account"
action = "view"
status = switch $R
case "OK" "success"
case "FAIL" "failure"
case "FAILURE" "failure"
endswitch
importance = "high"
id = "PT_IBM_AIX_syslog_OS_CONF_READ"
event_src.category = "AAA"
event_src.title = "AIX"
event_src.vendor = "IBM"
```
### Создание правила корреляции
Запишем в тестовый сценарий содержание результата правила нормализации
Заполним информацию о событиях
Запишем правило для корреляции
rule User_read_file_then_login_ssh: (User_read_file -> User_login_ssh) within 5m
Где значения в скобках означают последовательность проверки выполнения событий а within их выполнение в течение определенного времени
Прокинем в корреляцию данные из исходного события
Добавим статические данные в коррелированное событие
Заполним метаданные
Правило корреляции
```
event User_read_file:
key:
event_src.hostname
filter {
correlation_name == null
and action == "view"
and object.account.name == "mp"
and subject == "account"
and object == "system"
}
event User_login_ssh:
key:
event_src.hostname
filter {
correlation_name == null
and subject == "account"
and object == "system"
and action == "login"
and protocol.layer7 == "ssh"
}
rule User_read_file_then_login_ssh: (User_read_file -> User_login_ssh) within 5m
init {
$first_event = true
}
on User_read_file {
$object.account.name = object.account.name
$subject.process.cwd = subject.process.cwd
}
on User_login_ssh {
if $first_event then
$first_event = false
$subject.account.name = subject.account.name
$event_src.category = event_src.category
$event_src.title = event_src.title
$event_src.vendor = event_src.vendor
$src.hostname = src.hostname
$id = id
$protocol.layer7 = protocol.layer7
endif
}
emit {
$subject = "account"
$correlation_type = "event"
$action = "access"
$object = "system"
$importance = "high"
$status = "success"
}
```
Вводимые данные
```
expect 1 {}
{"subject": "account","action": "view","object": "system","status": "success","event_src.category": "AAA","event_src.title": "AIX","event_src.vendor": "IBM","id": "PT_IBM_AIX_syslog_local10_info","importance": "info","msgid": "OS_CONF_READ","event_src.hostname": "aix53","object.account.name": "mp","subject.process.cmdline": "cat","subject.account.name": "test","subject.process.cwd": "/etc/shadow","time": "2022-09-22T04:51:04"}
{"subject": "account","action": "login","object": "system","status": "success","event_src.category": "AAA","event_src.title": "AIX","event_src.vendor": "IBM","id": "PT_IBM_AIX_syslog_USER_Login_root","importance": "info","msgid": "USER_Login","protocol.layer7": "ssh","event_src.hostname": "aix53","object.account.name": "ektest","subject.account.name": "test","time": "2022-09-22T04:52:46"}
```
Вывод
```
[WARNING] Will automatically generate increasing UUIDs for normalized events
[WARNING] Table lists schema is not provided, considering it's empty!
SUCCESS!
Got results:
{"subject.account.name": "test", "subject": "account", "_rule": "User_read_file_then_login_ssh", "id": "PT_IBM_AIX_syslog_USER_Login_root", "event_src.vendor": "IBM", "event_src.category": "AAA", "object": "system", "event_src.title": "AIX", "object.account.name": "mp", "correlation_name": "User_read_file_then_login_ssh", "action": "access", "time": "2022-09-22T04:52:46Z", "protocol.layer7": "ssh", "correlation_type": "event", "_objects": [{"AssetId": null, "Fqdn": "aix53", "IpAddress": null, "EventTimestamp": "2022-09-22T04:51:04Z"}, {"AssetId": null, "Fqdn": "aix53", "IpAddress": null, "EventTimestamp": "2022-09-22T04:52:46Z"}], "importance": "high", "count": 1, "subevents.time": ["2022-09-22T04:51:04Z", "2022-09-22T04:52:46Z"], "status": "success", "subject.process.cwd": "/etc/shadow", "subevents": ["9fff75aa-0637-4139-a024-351bd99f26af", "9fff75aa-0637-4139-a024-351bd99f26b0"], "uuid": "21767afd-ffab-425c-9336-43f7118dd26f", "origin_app_id": "00000000-0000-0000-0000-000000000005", "primary_siem_app_id": "00000000-0000-0000-0000-000000000005", "siem_id": "e1b2c118-1a86-11ea-9632-e3fa28d252ab", "normalized": true, "generator.version": "25.0.2412 (libservice v.2.0.728)", "generator.type": "correlationengine"}
```
Sign in with Wallet
Connect another wallet