Управление инцидентами ИБ на основе SIEM-систем

Дмитрии Дудко
Руководитель проектов по информационной безопасности
центра компетенции ИБ, ЗАО “Фирма Аи Ти. Информационные технологии"

Что же такое инцидент?

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

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

Инцидентами информационной безопасности могут быть:

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

Каждый инцидент может быть классифицирован по множеству признаков. Я использую следующие:

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

Процесс управления инцидентами

Так как инциденты наносят ущерб работоспособности системы (реальный или потенциальный), целесообразно организовать процесс управления ими. Он включает в себя (рис. 1):

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

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

• возможность мониторинга целевых систем и средств защиты с организацией выделенного хранилища инцидентов и log-файлов;
• расследование инцидентов;
• возможность получения информации от подразделений (в первую очередь IТ) по произошедшим инцидентам с высокой важностью реагирования и предоставления информации;
• полномочия по форс-мажорному исправлению последствий инцидентов с привлечением необходимых специалистов других подразделений;
• возможность создания корректирующих мер.

Сложности реализации процесса управления инцидентами

Процесс управления инцидентами сопряжен с некоторыми трудностями:

Четкое закрепление ролей в процессе. Если в подразделении владельца процесса роли закреплены достаточно четко, то в привлекаемых подразделениях всегда возникает вопрос: кто и как должен реагировать и какие действия совершать? Без этого оперативное реагирование на инцидент и его расследование будут затруднены.

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

Ограниченность ресурсов. Это ахиллесова пята большинства организаций. Ресурсы (кадровые и технологические) стоят денег, и если вопрос с кадровыми ресурсами можно решить автоматизацией процессов, то без необходимой инфраструктуры – никуда.

Данные препятствия значительны, но не смертельны. Любое из них может быть компенсировано различными организационными мероприятиями.

Автоматизация процесса управления инцидентами

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

Система управления событиями – это глубоко интегрированная с другими процессами система. Разумеется, большинство этапов можно сделать локальными, но тогда серьезно снизится эффективность автоматизации.

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

• Подключать любые IP-системы и устройства. Если мы не можем направить поток событий в SIEM лишь потому, что у нас самописная система, дорого и трудно разрабатываются коннекторы или необходимо обращаться в штаб-квартиру на другом конце света, то зачем нужна такая система?
• Подключать отечественные средства защиты. Учитывая специфику отечественной информационной безопасности, необходимо понимать, что немногие организации могут обойтись только западными вендорами.
• Работать с Service Desk. SIEM должна уметь генерировать заявки об инцидентах и отслеживать их выполнение. Во-первых, это позволяет сократить время реагирования; во-вторых, вовремя необработанный инцидент – это тоже инцидент.
• Инициировать управляющее воздействие. Необязательная, но крайне полезная функция. Существует много ситуаций, когда решение по инциденту должно быть произведено быстро. Например, изоляция рабочей станции от локальной сети организации путем "выключения" порта на маршрутизаторе для последующего разбирательства. Данная функция требует деликатного обращения, поэтому ее использование целесообразно после прохождения этапа решения ошибок 1-го и 2-го рода.
• Организовывать инвентаризацию существующих и поиск новых информационных активов. Не существует статичных организаций, поэтому, если мы не имеем текущей картины существующих активов, наш процесс управления событиями будет иметь белые пятна, о которых он ничего не знает. Если карта активов хранится в SIEM-системе, она должна уметь поддерживать их в актуальном состоянии.

Необходимые документы

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

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