Сценарии реагирования («плейбуки») — важная составляющая процессов любого центра мониторинга и оперативного реагирования на инциденты информационной безопасности (Security Operations Center, SOC). Однако в случае с аутсорсинговыми SOC возникают определённые особенности создания и эксплуатации плейбуков с учётом большого количества и разнородности заказчиков, а также имеющихся активных функций реагирования. Как показывает практика, типовые сценарии не смогут решить некоторые задачи внешнего центра; в связи с этим мы хотим рассказать о сквозной реализации плейбуков при взаимодействии с аутсорсинговым SOC.
- Введение
- Типовой плейбук
- Типовые проблемы стандартных плейбуков
- Модель зрелости сценариев реагирования для аутсорсингового SOC
- Выводы
Введение
Сценарий реагирования, или плейбук (от англ. playbook) — это список необходимых шагов и действий, которые следует выполнить для успешного отклика на конкретные угрозы и разновидности инцидентов. Он может исполняться как в ручном, так и в автоматическом режиме и, в частности, распределяет операции реагирования между различными командами администраторов и аналитиков, работающих в сфере информационной безопасности.
Плейбуки помогают установить формализованные процессы и процедуры обработки инцидентов в рамках расследований и позволяют обеспечить систематическое выполнение необходимых действий.
В состав сценариев реагирования могут быть включены, например, следующие операции:
- Проверка событий безопасности на ложноположительное срабатывание.
- Действия, направленные на локализацию инцидента и минимизацию возможных последствий.
- Сбор ключевой информации для расследования инцидента.
- Отправка оповещений.
Типовой плейбук
Исследовав Всемирную паутину, можно обнаружить множество различных готовых шаблонов плейбуков для SOC. Однако их изучение приводит к мысли о том, что все они так или иначе имеют типовые фазы управления инцидентами и рассчитаны на внутренние команды и центры мониторинга. Давайте рассмотрим, как выглядит типовой плейбук. Для него характерны следующие основные этапы реагирования:
- Подготовка. На данном этапе осуществляются настройка аудита информационных систем, установка средств защиты и мониторинга.
- Детектирование и анализ. Создаются правила обнаружения компьютерных инцидентов, а также проводится исследование происшествий вкупе с возможными векторами их распространения.
- Локализация, ликвидация и восстановление. Цель этого этапа заключается в том, чтобы изолировать скомпрометированные системы, не допустить уничтожения индикаторов компрометации, которые полезны при расследовании инцидента, минимизировать возможные последствия, устранить саму угрозу и восстановить функциональность систем.
- Принятие мер после инцидента. На этом этапе подготавливаются отчёт о проведённом расследовании и рекомендации по повышению уровня информационной безопасности ИС.
Рисунок 1. Основные этапы реагирования типового плейбука
Типовые проблемы стандартных плейбуков
На практике наша команда столкнулась с ситуацией, когда подобные шаблоны не работают в случае аутсорсингового SOC. Для специалистов внешнего центра основной задачей является анализ инцидента, то есть первый и второй этапы в рамках типового плейбука, а процесс реагирования чаще всего лежит на плечах заказчика.
Вот какие основные проблемы мы обнаружили, пытаясь использовать стандартные сценарии:
- Часто встречаются обобщённые плейбуки, в которых описание этапов носит информационный характер и не подразумевает каких-либо конкретных действий.
- В связи с распространением платформ реагирования на инциденты (IRP) вендоры выпускают собственные сценарии, которые «заточены» под конкретную систему и чаще всего неприменимы в других платформах.
- В большинстве случаев плейбуки нацелены на этапы реагирования, связанные с локализацией и ликвидацией инцидента. Эти этапы подробно расписаны и имеют большее количество шагов, чем этапы детектирования и анализа, в которых детализации нет.
- Аутсорсинговый SOC и его заказчики используют разрозненные плейбуки, поэтому действия команд оказываются неслаженными.
- Индивидуальность заказчика накладывает свой отпечаток на применение однотипных сценариев реагирования: необходимо учитывать политики безопасности, используемые в компании, специфику работы, наличие передовых средств защиты.
- От предыдущего пункта производна и глубина вхождения в инфраструктуру заказчика — в части возможности осуществлять активное реагирование и использовать имеющиеся средства защиты для блокировки вредоносного воздействия.
Рисунок 2. Различные варианты представления плейбуков
Модель зрелости сценариев реагирования для аутсорсингового SOC
Отталкиваясь от этих проблем наша команда разработала модель зрелости, на которую опираются аналитики при разработке сценариев реагирования с учётом специфики работы с заказчиком. Модель зрелости состоит из трёх уровней и основывается на том, что аутсорсинговый SOC использует некую абстрактную платформу обработки инцидентов, где в том или ином виде можно реализовать шаги плейбука.
Первоочерёдным является нулевой уровень зрелости. На этом уровне SOC и его заказчик используют по отдельности собственные плейбуки, которые никак не связаны между собой. В таком случае для компании-клиента шаги на этапе детектирования и анализа остаются «чёрным ящиком»: их формирует SOC, а с заказчиком согласовывается только список сценариев мониторинга компьютерных инцидентов. Оперативный центр, в свою очередь, не привязывается к шагам локализации и ликвидации, а лишь формирует рекомендательные действия в карточке инцидента. При этом SOC и заказчик применяют различные системы для управления происшествиями: IRP, Service Desk.
Рисунок 3. Нулевой уровень зрелости
На первом уровне зрелости SOC и заказчик используют единые плейбуки. Оперативный центр формирует все процессы в составе сценариев реагирования, привлекая специалистов заказчика для учёта индивидуальных особенностей его инфраструктуры. Также SOC и заказчик применяют единую облачную IRP-платформу, поэтому плейбуки прозрачны для всех участников реагирования: заказчик видит, на каком этапе находится анализ инцидента, а аналитики SOC могут отследить, заблокированы ли вредоносные ресурсы, устранена ли угроза, проведено восстановление или нет. При этом некоторые этапы плейбука могут идти параллельно: пока специалисты заказчика изолируют скомпрометированные системы, аналитики SOC проводят расследование и выявляют первопричины инцидента на основании дополнительно собранных материалов. Модернизация сценариев реагирования происходит по согласованию со специалистами центра.
Рисунок 4. Первый уровень зрелости
Второй, он же последний, уровень зрелости предполагает использование двух разных инсталляций одной IRP-платформы и настройку нативной интеграции между ними. На этом уровне плейбуки также прозрачны для обеих сторон, однако заказчик имеет полные административные права в системе управления инцидентами. Сценарии реагирования привязываются к конкретным типам или названиям происшествий, но каждый из участников может формировать и модернизировать собственные процессы плейбука без согласования со второй стороной. На этом этапе также появляется возможность использовать оркестровку, то есть автоматизацию действий по обработке выявленных индикаторов компрометации, сбросу и блокировке скомпрометированных учётных записей, изоляции хостов и сетей, сбору дополнительных данных для расследования. При этом не возникает необходимости передавать данные функции на сторону SOC, так как они будут выполняться на платформе, полностью контролируемой администраторами заказчика.
Рисунок 5. Второй уровень зрелости
Выводы
Использование сценариев реагирования позволяет повысить управляемость деятельности по реагированию на инциденты. Чем теснее связаны процессы плейбуков, тем оперативнее происходит обработка возникающих инцидентов. Представленная модель зрелости использования сценариев реагирования аутсорсинговым SOC — лишь начало исследования нетривиальных процессов в его работе; данная статья не только имеет ознакомительный характер, но и призвана обратить внимание профессионального сообщества на нюансы, с которыми сталкиваются внешние центры мониторинга.
