Как мы внедряем SIEM

Я работаю главным специалистом направления внедрения средств защиты информации и хочу рассказать о подходах МультиТек Инжиниринг к внедрению и созданию автоматизированных систем управления событиями информационной безопасности и обнаружения инцидентов на базе платформ класса Security information and event management (SIEM) (далее – Система).

Сейчас SIEM – это всем известный и широко используемый в информационной безопасности инструмент. Однако, внедрение SIEM – процесс непростой, требующий обширных знаний исполнителей, а также погружения в бизнес-процессы и инфраструктуру заказчика.

Именно поэтому первым этапом внедрения SIEM является – формирование команды. Мы считаем, что внедрение должно осуществляться совместными усилиями специалистов нашей компании и организации заказчика. Последним предстоит промышленно эксплуатировать SIEM, поэтому они должны овладеть необходимыми практическими навыками с первого дня внедрения. Мы рекомендуем заказчику включать в команду внедрения не менее 2-х своих сотрудников, чтобы они могли страховать друг друга (на случай болезни, ухода в отпуск).

Специалистам заказчика в команде внедрения мы предлагаем следующие роли:

Руководитель команды внедрения. Его основная задача – организация взаимодействия со смежными подразделениями для успешного выполнения задачи по эффективному внедрению SIEM.

Администратор. Отвечает за настройку:

• сетевого взаимодействия между компонентами SIEM;
• SIEM для работы с инфраструктурными сервисами, такими, как Система активных каталогов Microsoft, почтовый сервер;
• SIEM для подключения источников событий ИБ (создание учетных записей, профилей, задач и т.д.);
  ролевой модели доступа SIEM.

Аналитик. Он отвечает за:

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

После того, как сформировали команду и распределили роли (допускается совмещение ролей), переходим к следующему этапу — проектированию Системы.

На данном этапе нам необходимо:

• определить источники событий ИБ;
• определить состав информации о событиях ИБ, подлежащих регистрации;
• определить перечень инцидентов ИБ;
• спроектировать графики и отчеты;
• рассчитать необходимые вычислительные ресурсы;
• разработать на основании технического задания «Пояснительную записку к техническому проекту»
• разработать «Программу и методику испытаний Системы» (далее – ПМИ).

Опираясь на наш опыт внедрения SIEM, хочу выделить два подхода к определению источников событий ИБ и детектируемых инцидентов ИБ.

Первый подход – риск-ориентированный. Применим для организаций, проводящих оценку рисков ИБ на регулярной основе. В этом случае мы работаем с неприемлемыми рисками. Анализируем их, выстраиваем цепочку: какие инциденты ИБ приведут к реализации риска ← какие события позволят обнаружить инцидент ← из каких источников мы можем получить необходимые события. (Подробно об этом можно почитать в статье Оценка рисков ИБ. Определяем источники и перечень событий ИБ).

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

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

Завершается этап проектирования разработкой и утверждением документа «Пояснительная записка к техническому проекту», в соответствии с которым будет создаваться система.

После того, как Систему спроектировали, переходим к этапу создания Системы.

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

Практика показывает, что не все события ИБ подлежат нормализации «коробочными» правилами от производителя. В таком случае разрабатываются правила нормализации для ненормализованных событий ИБ. Важно отметить, что при разработке правил нормализации необходимо сохранять субъектно-объектную модель: субъект воздействует на объект. Это позволит не путаться в сопоставлении параметров и значений при разработке правил. Например, Пользователь аутентифицируется в операционной системе. В таком случае пользователь – субъект, операционная система – объект.

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

На этапе создания настраиваются графики для оперативного отображения имеющейся информации в SIEM, а также задачи формирования и отправки отчетов. Разрабатывается эксплуатационная документация, которая, как правило, состоит из следующих документов: «Общее описание», «Руководство администратора», «Руководство аналитика».

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

На этом этапе проводится проверка Системы на соответствие требованиям ПМИ. Происходит отладка правил корреляции детектирования инцидентов ИБ. При необходимости в правила корреляции вносятся дополнительные изменения.

На этапе опытной эксплуатации устраняем False Positive (ложно положительные) инциденты. В процессе их устранения необходимо тесно взаимодействовать с ИТ-службой, провести аудит событий на источниках с привязкой к конкретному инциденту. Аудит событий на источниках следует проводить для того, чтобы убедиться, что инцидент действительно ложный.

Как только мы определили, что инцидент является ложно положительным, нам необходимо доработать условия фильтрации срабатывания правил корреляции. Условия фильтрации рекомендуем настраивать через наполнение табличных списков. Например, в табличных списках может храниться информация об ip-адресах контроллеров домена, логины привилегированных учетных записей, ip-адреса узлов, с которых осуществляется администрирование объектов инфраструктуры и т.д.

После того, как Система прошла проверку согласно ПМИ, и устранены False Positive инциденты ИБ, начинается этап промышленной эксплуатации.

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

Если у вас есть вопросы по внедрению SIEM, пишите.

---

Часть 1. Оксана Хаблак. Наши подходы к проектированию системы защиты информации
Часть 2. Александр Захаренков. Наши подходы к созданию системы защиты информации
Часть 3. Андрей Сыч. Как мы внедряем PAM.