Управление правилами автоматизированного выявления on Alertix

Общие сведения о правилах

Mon, 01 Jan 0001 00:00:00 +0000

Правила автоматизированного выявления (далее – "правила сигнал") – это набор инструкций в формате YAML, передаваемых сервису сигнал Платформы (подробнее о сервисе в руководстве администратора Платформы), с целью поиска в непрерывно накапливаемых данных от источников событий значимых отдельных событий, превышения заданных пороговых значений или последовательностей (цепочек) событий, являющихся признаками инцидентов ИБ. Поисковые запросы выполняются с различной, определяемой для каждого правила периодичностью и имеют заданный ожидаемый критерий результатов выполнения. Если результат выполнения запроса удовлетворяет критерию, сервис формирует подозрение на инцидент и может уведомлять аналитиков об этом посредством электронной почты или в мессенджер (настройка уведомлений о подозрении осуществляется администратором Платформы). Каждому подозрению присваивается комплексный показатель опасности, который является произведением назначенных для каждого правила значений параметров: достоверность, важность и приоритет. Подробнее об этих параметрах далее в этом разделе.

Страница управления правилами

Mon, 01 Jan 0001 00:00:00 +0000

Выполнение задач управления правилами автоматизированного выявления осуществляется под учетной записью с ролью "Аналитик".

Выберите раздел "Правила" главного меню интерфейса.

Общий вид страницы управления правилами сигнал приведен на рисунке ниже.

Рисунок 1.

Содержит следующие интерактивные элементы:

1 – статистика по правилам сигнал;
2 – вкладки для отображения правил сигнал, словарей и правил автонаполнения списков;
3 – строка поиска правил, кнопки управления и преднастроенные быстрые фильтры правил;
4 – область перечня имеющихся правил.

Добавление правил

Mon, 01 Jan 0001 00:00:00 +0000

Для добавления правила сигнал воспользуйтесь кнопкой "Добавить" и выберите нужный тип правила. Описание типов правил и их ключевые особенности приведены в разделе Общие сведения о правилах.

Откроется конструктор правил.

Выберите режим создания кода правила:

пользовательский - содержит элементы, в которых пользователь заполняет служебную информацию, и ниже - поле для формирования поискового запроса (bool) и запроса на построение агрегаций для правил типа бакет (aggs);
профессиональный - содержит шаблон полного кода правила для выбранного типа, в котором все значения атрибутов редактируются вручную.

Изменение и клонирование правил

Mon, 01 Jan 0001 00:00:00 +0000

Для изменения ранее созданного локального правила сигнал нажмите кнопку в правой части желаемого элемента в перечне правил на странице управления правилами.

Откроется конструктор правил.

Рисунок 1.

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

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

Ретроспективный поиск для правила signal

Mon, 01 Jan 0001 00:00:00 +0000

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

Рисунок 1.

Для ретроспективного поиска событий по цепочечному правилу (тип Chain) есть возможность указывать пороговое значение количества событий в звене цепочки. Результат поиска будет ограничиваться по этому порогу. Границы параметра - от 1 до 10000.

Рисунок 2.

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

Создание предопределенных списков (словарей) для правил

Mon, 01 Jan 0001 00:00:00 +0000

Редактор списков позволяет создавать специальные списки условий и ограничений по определенным атрибутам, которые можно использовать в правилах Signal. Например, использовать в поиске событий конкретные значения либо исключить определенные значения из поискового запроса правила сигнал. Это позволяет унифицировать правила, не меняя их, а внося изменения в конкретные списки (например: "Список администраторов", "Список сканеров безопасности", "Список критичных хостов" и т.п.), а в самих запросах в правилах указывать только имена нужных списков.

Для создания нового списка условий воспользуйтесь ссылкой "Списки" на странице управления правилами.

Создание правил автонаполнения списков

Mon, 01 Jan 0001 00:00:00 +0000

Вкладка "Автонаполнение списков" позволяет создавать правила для динамического формирования списков. Данные правила работают так же, как и классические правила, выявляют события по указанному запросу, и в зависимости от типа, удаляют или добавляют значение из найденного события в указанный список.

Аналогично классическим правилам, на вкладке "Автонаполнение списков" доступна сортировка, преднастроенные фильтры, действия редактирования, клонирования, остановки и запуска.

Рисунок 1.

Для добавления правила автонаполнения списков воспользуйтесь кнопкой "Добавить". В открывшемся редакторе введите необходимые критерии запроса и сохраните.

Использование информации из БД Инвентаризации для правил Сигнала (List, Chain)

Mon, 01 Jan 0001 00:00:00 +0000

Для правил типа list и звеньев цепочек такого типа есть два специальных условия, с помощью которых можно осуществлять проверку определенных данных в БД инвентаризации. Для корректной работы условий необходимо наличие установленного компонента census. Условия применяются в Condition правила.

Возможны следующие типы проверок:

проверка соответствия имени хоста и IP адреса по ранее наблюдаемым данным (принимаемым событиям) - условие host_ip_matching; может использоваться для проверки относится ли хост к контролируемой инфраструктуре и при подозрении на спуффинг;
проверка наличия уязвимости или уязвимостей на хосте - условие for_only_vulned; требует наличия настроенной интеграции census со сканерами уязвимостей; может проверяться наличие конкретной уязвимости (по идентификатору CVE или БДУ) или наличия хотя бы одной уязвимости определенного уровня критичности (в классификации БДУ или подключенного сканера).