Искусственный интеллект на службе информационной безопасности в компании - Инциденты и источники

Подробности

Создано 13.10.2013 01:10

Итак, системы SIEM используются для автоматизации обработки событий ИБ. Для этого применяются правила корреляции. Поговорим о том, как правильно составить список необходимых правил. Многие промышленные системы SIEM имеют предустановленный набор правил, например, обнаружение подбора пароля или сканирования портов, однако в большинстве случаев этого стандартного набора бывает недостаточно.

Какие конкретно инциденты нужно создавать, определяется специалистами службы информационной безопасности. Как правило, они строятся на основе тех угроз, которым наиболее подвержена ИТ-инфраструктура компании и ее основные активы. Примерами таких инцидентов являются попытки подбора паролей к учетным записям, изменение прав пользователей, подозрительная активность под привилегированными учетными записями, подозрительная сетевая активность, вирусная активность, действия с СУБД и другое.

Надо учитывать, что для одного инцидента может существовать несколько правил. Например, инцидент подбора паролей к учетной записи. Если она в ОС Windows, то там одно правило, если к Unix, то другое, если к СУБД, то третье, и так далее. Это стоит учитывать при планировании работ по составлению правил корреляции.

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

В случае если инцидент применим для данного типа источников, то для него создается правило. Например, о вирусной активности нам может сообщить антивирусная система, но не ОС, не СУБД нам об обнаружении нового вируса сообщить не могут. Аналогично СУБД нам не расскажет о сканировании портов.

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

Составленные правила необходимо применить в системе. Для этого нужно получить хотя бы одно событие, на основе которого будет создано правило. Для ОС Windows, к примеру, это Failed logon. После создания правила начнут создаваться инциденты. Однако рассчитывать, что на этом процесс работы с инцидентами будет завершен, не стоит. Далее могут возникнуть трудности следующего уровня.

Прежде всего, уместно вспомнить ложные срабатывания. Как известно, они бывают двух видов:

> false positives (ложные разрешения);

> false negatives (ложные запреты).

В данном случае это может выглядеть следующим образом: некоторые правила корреляции будут срабатывать слишком часто (ложные запреты). Например, пользователь в течение часа три раза неверно ввел пароль. А некоторые правила, наоборот, не будут срабатывать, когда это необходимо. Например, если произошло событие изменения прав пользователя.

Верным признаком ложных запретов является генерация большого числа уведомлений (несколько десятков, а то и сотен в сутки). Совершенно очевидно, что расследовать такой объем практически невозможно. Для борьбы с «мусорной» активностью необходимо пересматривать имеющиеся правила корреляции в сторону ослабления условий.

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

Ложные разрешения могут быть опаснее. Пропущенный инцидент приносит компании серьезные убытки. Поэтому важно найти баланс между жесткостью настройки правил и пороговыми значениями безопасности.

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