###### tags: `INT`
# INT-2-Омаров_Джамалутин
*Выполнил Омаров Джамалутин*
## Нормализация и корреляция событий информационной безопасности

### Установка утилиты и запуск

1. Скачаем архив с утилитой и извлечем.


2. Необходимо разместить папку с утилитой по корректному пути, без недопустимых символов.


Внутри папки находятся dll и конфиги необходимые для работы утилиты.


3. Можем запускать.


### Начальная настройка

Немного информации об утилите **PTSIEMSDK**.

Вкладка **Редактор Объектов** - это область для создания, добавления правил локализации регистрируемых по правилу событий и описания правила.

Вкладка **Сценарии** - она предназначена для отладки совместной работы правил на этапах создания графов и потоковой обработки событий при нормализации, агрегации, обогащении, корреляции и локализации.

Вкладка **Настройки** - данная вкладка предназначена для настройки параметров работы утилиты.

Приступим к начальной настройке.

1. Настройка -> Пути -> Папка с результатами.


Я создал папку по пути `C:\result_ptsiem`. Там будут складываться все результаты, которые мы получим во вкладке сценариев (нормализованные, коррелированные события).

2. Откроем справочник F1.


Здесь можно посмотреть таксономию (поля, параметры и их назначения) и горячие клавиши.
Каждое событие - это субъектно-объектное взаимодействие. Субъект совершает действие над объектом.

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

### Нормализация

**Нормализация событий** - процедура приведения необработанного события к нормализованному виду в соответствии с заранее заданным для источника и типа события правилом нормализации.

**Нормализованное событие** — событие представляет собой совокупность полей, заполненных данными из необработанного события согласно правилу нормализации.

Для начала работы нам необходимо загрузить сырые события.

1. Загрузка сырых событий.


read_config_raw_events.txt


Результат.


1 событие.


2 событие.


Как мы можем видеть, это два одинаковых события, различающиеся лишь временем и путем к папке. Формат события так же одинаковый. Нет различия в синтаксисе.

2. Шаблоны.

Вставим шаблон.


Мы видим ключевые слова, определяющие каким образом мы получили данные события:
* TEXT
* JSON
* TABULAR
* EVENTLOG

**TEXT** используется для объявления форматной строки события в формате простого текста.

**JSON** используется для объявления форматной строки правила нормализации событий в формате JSON.

**TABULAR** используется для объявления форматной строки правила нормализации событий, представленных в виде ассоциативного массив в формате JSON, другими словами формат из **базы данных**.

**EVENTLOG** используется для объявления форматной строки правила нормализации событий из журнала Windows.


3. Формула.

Копируем текст события и вставляем в форматную строку.


Какие-то участки лога будут якорями (неизменяемыми), а какие-то динамическими. Динамические участки нам необходимо парсить.

Первое, на что я обратил внимание - дата и время. Эти параметры изменяются.


Заменим их специальным токеном.


Данный участок события распарсится и будет сохранен в метку времени `time`.


Из задания известно, что `OS_CONF_READ` - это идентификатор типа события. Поэтому обращаемся в справочник и находим данный параметр.


Значит, мы должны присвоить имя идентификатора параметру `msgid`. Он уникален в рамках нашего события.


`aix53` - имя узла источника события.


Откроем справочник.


`src.hostname` - имя узла источника при взаимодействии.

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


`mp` - имя пользователя.

Так как у нас событие чтения конфигурационного файла операционной системы, то пользователь выступает субъектом.

Откроем справочник.


`subject.account.name` - логин учетной записи.

Для имени пользователя используем токен `STRING`. Данный токен используется для распознавания последовательности символов до пробела.


`OK` - показатель успешности действия.


Откроем справочник.


`status` - результат действия.

В качестве токена используем `WORD`. Данный токен используется для распознавания слов.


`cat` - имя приложения, использованное для чтения.


Откроем справочник.


`subject.process.name` - имя исполняемого файла процесса.

Используем токен `STRING`.


`/etc/shadow` - путь к файлу, который читали.


Откроем справочник.


`object.fullpath` - полный путь к объекту.

Используем токен `STRING`.


`audit object read event detected` - обнаружение события чтения объекта аудита. Данная строчка является якорем.


`local0:info audit` - данная строчка говорит о том, что это информационное сообщение.


Для того, чтобы протестировать написанное, заполним основные поля.


subject = "account"
action = "view"
object = "file"
status = "success"

importance = "info"

event_src.vendor = "IBM"
event_src.title = "AIX"
event_src.category = "Operating system"
event_src.hostname = "aix53"

id = "IBM_AIX_log_OS_CONF_READ_info_audit"

Субъект - аккаунт, так как присутствует имя пользователя.
Действие - просмотр, так как используется утилита `cat`.
Объект - файл, так как `/etc/shadow` является файлом.
Статус - успешно, так как сообщение `OK`.
Важность - информирование.
Вендор - `IBM` (взято из задания).
Продукт вендора - `AIX` (взято из задания).
Категория - операционная система (взято из задания).
Имя узла - `aix53`
Идентификатор нормализованного события - `IBM_AIX_log_OS_CONF_READ_info_audit`. Вендор -> Продукт вендора -> Откуда взяли сырое событие(предположил название) -> Тип события -> Пометка для понимания.


4. Запуск

Нажмем на кнопку запуска.


События нормализовались успешно. И мы видим нормализованный эквивалент в графе результат.


Также необходимо удостовериться, что все необходимые данные получилось достать.


Все, что нужно достали!

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

Теперь сохраним нашу формулу.




### Метаинформация

**Метаданные** описывают взаимосвязь нормализованного события с критериями, по которым будут применяться строки локализации.

1. Редактор метаданных.

Откроем редактор.


Вставим шаблон.



Поле `Criteria` - условия отбора нормализованных событий.
Необходимо вписать туда идентификатор события.


Для соответствия есть параметр `LocalizationID`. Это идентификатор, по которому различные блоки будут матчиться.



`Description` - описание сути формулы.

`EventDescription` - отображение события в UI.


Закрываем и сохраняем.


2. Сценарии.

Перейдем во вкладку Сценарии, чтобы проэмулировать то, как это будет работать.

В секции `BUILD`.


Добавим нашу формулу.



Добавим нашу локализацию.


В секции `RUN`.


Укажем иcходный файл событий (там откуда брали сырые события).



Ставим галочку на "Исходные события без конвертов". Когда агент собырает события с конечных узлов, то оборачивает его в конверт. Конверт содержит формат json со служебной информацией для дальнейших сервисов.


А также "Показать статистику".


И локализуем события.


Запускаем.


Продолжить.


3. Просмотр событий

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

RU



EN



Нормализованные события мы видим на обоих языках. Такие события увидит пользователь в интерфейсе SIEM, когда будет заниматься расследованием и мониторингом.

### ssh_login_raw_events

Проделаем аналогичную настройку и тесты для сырых событий файла `ssh_login_raw_events.txt`.

Если настройки будут различаться, то я приложу скриншот и опишу ход моих мыслей.

2 события имеют одинаковый формат, но в одном есть строка имени источника, а в другом ее нет.



Пользователь ektest залогинился по протоколу ssh с правами root.

`{"Message forwarded from" src.hostname = WORDDASH ":"?}` здесь я указал источник события, а также обратите внимание на `?` в конце... Это означает, что данное выражение опционально: Данная строка может присутствовать в событии, а также ее может не быть.


Финальная формула будет выглядеть так. События нормализовались успешно. И мы видим нормализованный эквивалент в графе результат.



Метаинформация.


Сценарий.


После запуска, продолжить.


RU



EN



### Корреляция

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

Задание: Пользователь сначала прочитал файл /etc/shadow, после чего успешно вошел в систему под другим пользователем, оба события произошли в течение 5 минут.

1. Формула.

Давайте по порядку, для начала необходимо создать event.
**event** - события, которые группируются по ключу и фильтруются по определенным критериям. В моем случае необходимо было, чтобы фильтрация одного события произошла по сценарию чтения пользователем определенного файла.


Далее второе событие - вход в систему под другим пользователем.


Два события есть. Теперь необходимо написать rule.
**rule** - правило корреляции или условие, куда будут вписаны события. Здесь мы переносим суть задания в код. Здесь же добавим условие, что пользователи будут разные, а также укажем время. Используем within для того, чтобы правило сработало в момент наступления нашего правила.


**init** - первое, что выполнится при первом приходе первого события.

**on** - выполняется на каждый приход события.

**emit** - выполняется при наступлении правила корреляции. То есть, если оно появится, правило сработало.

Нажимаем запуск


emit появился, значит правило сработало. Давайте выведем некоторые параметры, но для начала запишем их.


Заполнили информацию о нашей корреляции. Теперь посмотрим на вывод после запуска.


Я специально выделил эту строку, чтобы показать время наступления обоих событий.


Или развернем в JSON формате.


Также пробросил необходимые параметры.
Результат ниже! После данного этапа можно перейти к метаинформации.


2. Метаинформация.

Заполнил таким образом.


3. КОД

event Reading:
    key:
        event_src.hostname
    filter {
        correlation_name == null
        and event_src.title == "AIX"
        and object.fullpath == "/etc/shadow"
        and action == "view"
        and status == "success"
        and object == "file"
        and subject == "account"
        and importance == "info"
    }

event Successful_Login:
    key:
        event_src.hostname
    filter {
        correlation_name == null
        and event_src.title == "AIX"
        and subject == "account"
        and action == "login"
        and object == "system"
        and status == "success"
        and importance == "info"
    }

rule login_after_reading_5min: (Reading -> Successful_Login) with different subject.account.name within 5m

    init {
        $first_event = true
    }

    on Reading {
        $object.fullpath = object.fullpath
    }
    
    on Successful_Login {
        $src.hostname = src.hostname
    }

    emit {
        $correlation_type = "event" 
        $subject = "account"
        $action = "detect"
        $object = "system"
        $status = "success"
        $importance = "info"
        
    }