# INT-2 - Макаров Дмитрий Владиславович. Нормализация и корреляция событий информационной безопасности.
[toc]
## 1. Формулы нормализации
Операционная система IBM AIX приносит в SIEM ряд событий, из которых в данном случае нас интересуют два:
1. Событие входа пользователя по 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
```
2. Событие чтения конфигурационного файла операционной системы:
```
А) 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
```
Необходимо разработать две формулы нормализации, по одной для каждого из типов событий, содержащих в себе максимум полезной информации о случившемся.
### 1.1 Правило нормализации для события входа пользователя по SSH
#### 1.1.1 Разработка формулы и заполнение полей
1. Создадим новый объект типа *Формула нормализации*
---
---
2. Импортируем исходное событие `ssh_login_raw_events.txt`
---
---
---
---
3. Вставим шаблон **TEXT**
---
---
4. Скопируем текст события в поле `TEXT`
---
---
5. Заполним правило нормализации, взяв за основу данные события. Части события будут якорями (статическими), а остальные будут меняться (динамическими). Последние необходимо распарсить:
1. Потенциально фрагмент `<134>` с номером может меняться, поэтому заменим его на токе **NUMBER**;
2. Дату и время запишем в поле `time` с помощью токена **DATATIME**;
3. Фрагмент `Message forwarded from` есть лишь в первом логе, следовательно, необходимо добавить оператор `?`;
4. Имя источника события впишем в поле `event_src.hostname` с токеном **WORD** и оператором `?`;
5. Так как имя источника указано с оператором `?`, то и двоеточие после него запишем с тем же оператором;
6. Фрагмент `audit` сделаем якорным;
7. Уникальный идентификатор типа события запишем в соответствующее поле `msgid` с токеном **WORDDASH**;
8. Фрагмент `root` тоже сделаем якорным;
9. Успешность дейсвия записывается в поле `datafield1` с токеном **WORD**, а затем обрабатывается в условном операторе;
10. Далее следует основной якорный фрагмент `sshd user:`;
11. Имя пользователя запишем в поле `subject.account.name` с токеном **STRING**;
12. Фрагмент `tty` сделаем якорным;
13. Данные о протоколе подключения запишем в поле `protocol.layer7` с токеном **WORD**.
14. Оставшиеся поля заполним аналогичным образом:
```yaml
subject = "account"
action = "login"
object = "system"
if datafield1 == "OK" then
status = "success"
else
status = "failure"
endif
importance = "info"
event_src.vendor = "ibm"
event_src.title = "aix"
event_src.category = "Operating system"
id = "IBM_AIX_SSH_LOGIN"
```
---
---
6. Проверим работу правила нормализации, проведя тесты
---
---
---
Результат обработки первого лога
---
---
Результат обработки второго лога
---
---
:::success
:+1: Тесты прошли успешно.
:::
#### 1.1.2 Заполнение пользовательской локализации и файла метаинформации с критериями локализации
Добавим метаданные для локализации в наборы данных для отладки правил нормализации, обогащения, агрегации и корреляции. Метаданные используются для хранения правил локализации регистрируемых по правилам событий и описаний правил.
1. Откроем *Редактор метаданных*
---
---
2. Здесь вставлен специальный шаблон. Поле метаданных имеет две секции:
1. Секция `Criteria` предназначена для ввода условия правила локализации. Условие может состоять из одного или нескольких предикатов;
2. Секция `LocalizationId` предназначена для ввода идентификатора (ключа) для сопоставления условия правила локализации с одним описанием событий, указанным в поле **RU**, и одним описанием, указанным в поле **EN**.
---
---
3. Поля **RU** и **EN** используются для ввода описания правила и описаний регистрируемых по правилу событий. Они также имеют несколько секций:
1. Секция `Description` предназначена для ввода описания правила. При использовании в описании двоеточия все описание нужно заключать в кавычки.
2. Секция `EventDescriptions` предназначена для ввода описаний регистрируемых по правилу событий для разных условий локализации.
3. Секция `EventDescription` предназначена для ввода описания регистрируемых по правилу событий
4. Секция `LocalizationId` предназначена для ввода идентификатора (ключа) для сопоставления описания событий с условием правила локализации, указанным в поле Метаданные.
---
---
4. Заполним поле метаданных. В секцию `Criteria` укажем два условия: в случае **OK** - `succsess`, в случаях **FAIL** или **FAILURE** - `failure`. Также заполним секцию `LocalizationId` для связи с локализацией
```yaml
EventDescriptions:
- Criteria: id = "IBM_AIX_SSH_LOGIN" and datafield1 = "OK"
LocalizationId: IBM_AIX_SSH_LOGIN_SUCCESS
- Criteria: id = "IBM_AIX_SSH_LOGIN" and datafield1 = "FAIL" or datafield1 = "FAILURE"
LocalizationId: IBM_AIX_SSH_LOGIN_FAILUR
```
---
---
5. Заполним поля локализации **RU** и **EN**
**RU:**
```yaml
Description: Авторизация пользователя
EventDescriptions:
- LocalizationId: IBM_AIX_SSH_LOGIN_SUCCESS
EventDescription: Пользователь {subject.account.name} успешно авторизировался в системе по протоколу {protocol.layer7}
- LocalizationId: IBM_AIX_SSH_LOGIN_FAILURE
EventDescription: Пользователь {subject.account.name} не смог авторизироваться в системе по протоколу {protocol.layer7}
```
**EN**:
```yaml
Description: User authorization
- LocalizationId: IBM_AIX_SSH_LOGIN_SUCCESS
EventDescription: User {subject.account.name} succesfully logged into system via {protocol.layer7}
- LocalizationId: IBM_AIX_SSH_LOGIN_FAILURE
EventDescription: User {subject.account.name} failed to logged into system via {protocol.layer7}
```
---
---
6. Проведём тесты. Перейдём во вкладку сценарии. Настроим параметры **BUILD** и **RUN**:
- Включим опцию `BUILD FORMULAS`, где выберем папку с формулой нормализации
- Включим опцию `BUILD LOCALIZATION`, где выберем папку с локализацией
- Включим опцию `NORMALIZE`
- Включим опцию `LOCALIZE`
---
---
7. Нажимаем кнопку *Запуск* и начинаем тестирование сценария
---
---
:::success
:+1: Сценарий успешно сработал
:::
**RU**-локализация
___
---
---
**EN**-локализация
---
---
---
#### 1.1.3 Файлы тестов, которые успешно нормализуются разработанной формулой
[Файлы с тестами нормализации для события входа пользователя по SSH.](https://disk.yandex.ru/d/UH3KZW1mQkOL8g)
### 1.2 Правило нормализации для события чтения конфигурационного файла операционной системы
:::info
:information_source: Аналогично напишем ещё одно правило нормализации на этот раз для события чтения конфигурационного файла.
:::
#### 1.2.1 Разработка формулы и заполнение полей
1. Создадим новый объект типа *Формула нормализации*. Импортируем исходное событие `read_config_raw_events.txt`. Вставим шаблон **TEXT**. Скопируем текст события в поле `TEXT`
---
---
2. Имеем следующие исходные события
---
---
---
3. Аналогично заполним правило нормализации, взяв за основу данные события. Проведём парсинг таким образом:
1. Дату и время запишем в поле `time` с помощью токена **DATATIME**;
2. `aix53` - имя источника события. Впишем его в поле `src.hostname` с токеном **WORDDASH** и оператором `?`, так как источник может меняться;
3. Фрагмент `local0:info audit:` сделаем якорным;
4. Уникальный идентификатор типа события запишем в соответствующее поле `msgid` с токеном **WORDDASH**;
5. Имя пользователя `mp` запишем в поле `subject.account.name` с токеном **STRING**;
6. Успешность дейсвия записывается в поле `datafield1` с токеном **WORD**, а затем обрабатывается в условном операторе;
7. Имя исполняемого файла `cat` для чтения запишем в поле `subject.process.name` с токеном **STRING**;
8. Фрагмент `audit object read event detected` сделаем якорным;
9. Полный путь файла запишем в поле `object.fullpath` с токеном **STRING**.
10. Оставшиеся поля заполним аналогичным образом:
```yaml
subject = "account"
action = "view"
object = "file_object"
if datafield1 == "OK" then
status = "success"
else
status = "failure"
endif
importance = "low"
event_src.vendor = "ibm"
event_src.title = "aix"
event_src.category = "Operating system"
id = "IBM_AIX_READ_CONF"
```
---
---
4. Проверим работу правила нормализации, проведя тесты
---
---
---
Результат обработки первого лога
---
---
Результат обработки второго лога
---
---
:::success
:+1: Тесты прошли успешно.
:::
#### 1.2.2 Заполнение пользовательской локализации и файла метаинформации с критериями локализации
Как и обработке в предыдущего события, добавим метаданные для локализации в наборы данных для отладки правил нормализации, обогащения, агрегации и корреляции..
1. Откроем *Редактор метаданных* и вставим специальный шаблон
---
---
2. Заполним поле метаданных. В секцию `Criteria` укажем два условия: в случае **OK** - `succsess`, в случаях **FAIL** или **FAILURE** - `failure`. Также заполним секцию `LocalizationId` для связи с локализацией
```yaml
EventDescriptions:
- Criteria: id = "IBM_AIX_READ_CONF" and datafield1 = "OK"
LocalizationId: IBM_AIX_CONF_READ_SUCCESS
- Criteria: id = "IBM_AIX_READ_CONF" and datafield1 = "FAIL" or datafield1 = "FAILURE"
LocalizationId: IBM_AIX_CONF_READ_FAILURE
```
---
---
5. Заполним поля локализации **RU** и **EN**
**RU:**
```yaml
Description: Событие чтения конфигурационного файла операционной системы
EventDescriptions:
- LocalizationId: IBM_AIX_CONF_READ_SUCCESS
EventDescription: Пользователь {subject.account.name} с именем узла {src.hostname} прочитал конфигурационный файл системы по пути {object.fullpath} с помощью {subject.process.name}
- LocalizationId: IBM_AIX_CONF_READ_FAILURE
EventDescription: Пользователь {subject.account.name} с именем узла {src.hostname} не смог прочитать конфигурационный файл системы по пути {object.fullpath} с помощью {subject.process.name}
```
**EN**:
```yaml
Description: Operating system configuration file read event
EventDescriptions:
- LocalizationId: IBM_AIX_CONF_READ_SUCCESS
EventDescription: The user {subject.account.name} with hostname {src.hostname} read the system configuration file at {object.fullpath} path using {subject.process.name}
- LocalizationId: IBM_AIX_CONF_READ_FAILURE
EventDescription: The user {subject.account.name} with hostname {src.hostname} could not read system configuration file at {object.fullpath} path using {subject.process.name}
```
---
---
6. Аналогично проведём тесты. Перейдём во вкладку сценарии. Настроим параметры **BUILD** и **RUN**:
- Включим опцию `BUILD FORMULAS`, где выберем папку с формулой нормализации
- Включим опцию `BUILD LOCALIZATION`, где выберем папку с локализацией
- Включим опцию `NORMALIZE`
- Включим опцию `LOCALIZE`
---
---
7. Нажимаем кнопку *Запуск* и начинаем тестирование сценария
---
---
:::success
:+1: Сценарий успешно сработал
:::
**RU**-локализация
___
---
---
**EN**-локализация
---
---
---
#### 1.2.3 файлы тестов, которые успешно нормализуются разработанной формулой
[Файлы с тестами нормализации для события чтения конфигурационного файла операционной системы.](https://disk.yandex.ru/d/Y_U5Ejjpfbg1OA)
## 2. Правило корреляции на основе нормализации
На основе предварительно написанной в п.1 нормализации разработать правило корреляции событий, описывающее следующую цепочку:
«*Пользователь сначала прочитал файл /etc/shadow, после чего успешно вошел в систему под другим пользователем, оба события произошли в течение 5
минут*»
Правило корреляции состоит из последовательности директив, содержащих инструкции и команды. Для работы правила корреляции необходимо указать обязательные директивы и инструкции.
### 2.1 Разработка правила корреляции
1. Создадим новый объект типа *Формула нормализации*
---
---
2. Добавим шаблон **SIMPLE RULE**
---
---
3. Заполним директиву **event**. Директива event используется для объявления события, подлежащего корреляции. Для объявления нескольких событий с разными названиями в одном правиле можно использовать несколько директив **event**. Содержание директивы:
1. Может содержать инструкцию **key** для указания полей события, по значению которых разделяется поток событий.
2. Должна содержать инструкцию **filter** для настройки условия отбора события.
```yaml=
event success_read_config:
key:
event_src.host
filter {
correlation_name == null
and event_src.title == "aix"
and action == "view"
and object == "file_object"
and status == "success"
and object.fullpath == "/etc/shadow"
}
event success_login:
key:
event_src.host
filter {
correlation_name == null
and event_src.title == "aix"
and action == "login"
and object == "system"
and status == "success"
}
```
4. Заполним директиву **rule**. Директива **rule** используется для описания правила корреляции. В директиве нужно указать условие выполнения правила корреляции. Название, указанное в директиве, является уникальным названием правила корреляции. Все события, используемые при составлении условия правила корреляции, должны быть объявлены с помощью директив **event**. Директива может содержать следующие инструкции:
1. **init** для объявления переменных и по одной инструкции on для каждого объявленного события.
2. **on** (обработчик события) используется для выполнения блока операторов при регистрации события, указанного в этой инструкции
3. также может содержать инструкции **insert_into**, **remove_from**, **clear_table** для редактирования табличного списка.
```yaml=
rule ibm_aix_succes_read_config_and_login: (success_read_config -> success_login) with different subject.account.name timer 5m
on success_read_config {
$event_src.hostname = event_src.hostname
$object.process.name = object.process.name
$subject.account.name = subject.account.name
}
on success_login {
$event_src.hostname = event_src.hostname
$protocol.layer7 = protocol.layer7
$datafield1 = subject.account.name
}
```
5. Заполним директиву **emit**. Директива **emit** используется для заполнения полей корреляционного события и настройки регистрации инцидента при выполнении правила корреляции.
```yaml=
emit {
$correlation_type = "event"
$subject = "account"
$action = "access"
$object = "profile"
$status = "success"
$importance = "info"
}
```
В итоге получили следующее правило:
```yaml=
event success_read_config:
key:
event_src.host
filter {
correlation_name == null
and event_src.title == "aix"
and action == "view"
and object == "file_object"
and status == "success"
and object.fullpath == "/etc/shadow"
}
event success_login:
key:
event_src.host
filter {
correlation_name == null
and event_src.title == "aix"
and action == "login"
and object == "system"
and status == "success"
}
rule ibm_aix_succes_read_config_and_login: (success_read_config -> success_login) with different subject.account.name timer 5m
on success_read_config {
$event_src.hostname = event_src.hostname
$object.process.name = object.process.name
$subject.account.name = subject.account.name
}
on success_login {
$event_src.hostname = event_src.hostname
$protocol.layer7 = protocol.layer7
$datafield1 = subject.account.name
}
emit {
$correlation_type = "event"
$subject = "account"
$action = "access"
$object = "profile"
$status = "success"
$importance = "info"
}
```
---
---
6. Добавим метаданные
Поле метаданных:
```yaml
EventDescriptions:
- Criteria: "ibm_aix_succes_read_config_and_login"
LocalizationId: succes_read_config_and_login
```
Локализация **RU**:
```yaml
Description: Чтение и авторизация
EventDescriptions:
- LocalizationId: succes_read_config_and_login
EventDescription: Пользователь {datafield1} прочитал файл /etc/shadow, после чего успешно вошел в систему по протоколу {protocol.layer7} под пользователем {subject.account.name}, оба события произошли в течение 5 минут
```
Локализация **EN**:
```yaml
Description: Read and authorization
EventDescriptions:
- LocalizationId: succes_read_config_and_login
EventDescription: The user {datafield1} first read the /etc/shadow file, after which he successfully logged via {protocol.layer7} in under {subject.account.name}, both events occurred within 5 minutes
```
---
---
### 2.2 Тестирование правила корреляции
1. Создадим следующий тестовый сценарий:
```
expect 1 {}
{"subject": "account", "action": "view", "object": "file_object", "status": "success", "datafield1": "OK", "event_src.category": "Operating system", "event_src.title": "aix", "event_src.vendor": "ibm", "id": "IBM_AIX_READ_CONF", "importance": "low", "msgid": "OS_CONF_READ", "object.fullpath": "/etc/shadow", "src.hostname": "aix53", "subject.account.name": "mp", "subject.process.name": "cat", "time": "2022-05-19T09:50:06Z"}
{"subject": "account", "action": "login", "object": "system", "status": "success", "datafield1": "OK", "event_src.category": "Operating system", "event_src.hostname": "sovma131", "event_src.title": "aix", "event_src.vendor": "ibm", "id": "IBM_AIX_SSH_LOGIN", "importance": "info", "msgid": "USER_Login", "protocol.layer7": "ssh", "subject.account.name": "ektest", "time": "2022-09-22T05:01:48Z"}
```
2. Запустим тестовый сценарий
---
---
---
---
:::success
:+1: Правило корреляции успешно сработало.
:::
### 2.3 Файлы тестов правила корреляции
[Файлы с тестами правила корреляции.](https://disk.yandex.ru/d/ugPR9x_2HycFNw)
Sign in with Wallet
Connect another wallet