Чек-лист: о чем важно помнить при разработке плейбуков для SOC

Автор: Денис Гаврилов, консультант Центра информационной безопасности компании «Инфосистемы Джет»

В процессе создания современных SOC (Security Operations Center) рано или поздно встает вопрос повышения эффективности многочисленных процедур реагирования. Одним из инструментов их улучшения являются плейбуки (playbooks) или планы реагирования на типовые инциденты информационной безопасности. Разберем основные принципы, которые помогут сформировать рабочие плейбуки и взглянуть на существующие процессы с другой стороны.

Разбираемся в терминологии:

Часто, когда компании обращаются к нам за разработкой плейбуков для своих SOC, после выяснения деталей оказывается, что на деле им нужно совсем другое. Так происходит из-за путаницы в терминах: воркфлоу (workflow), плейбук (playbook) и ранбук (runbook). В чем их отличие, и как они могут быть связаны в процессе обработки инцидентов ИБ?

Воркфлоу описывает последовательность всех задач по обработке инцидентов для минимизации последствий от них и недопущения их возникновения в дальнейшем. Каждая компания самостоятельно определяет для себя набор таких задач. Например, такой воркфлоу под силу реализовать и совсем небольшому SOC из 2-3 человек:

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

Теперь разберемся, чем плейбук отличается от ранбука. Последний отвечает на вопрос, как решить конкретную задачу по реагированию, например, как выявлять индикаторы компрометации (Indicator of Compromise, IoC). Плейбук в общем виде не отвечает на вопрос, как их обнаружить. Для этого создается ранбук, в котором указываются конкретные источники данных, инструменты для их анализа и операции, необходимые для выявления IoC.

С чего начать разработку плейбуков

Цель выполнения плейбука

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

Тип инцидента ИБ	Описание сценария инцидента
Компрометация хоста	Выявление аномальной процессной активности на узлах: запуск процессов из нетипичных директорий создание или запуск определенных сервисов на узле нетипичное использование командных интерпретаторов

2. Инструменты

Далее нужно определиться с инструментами реагирования на выбранные типы инцидентов. К ним могут относиться:

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

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

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

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

3. Последовательность действий при выполнении плейбука

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

Жизненный цикл процесса реагирования на инцидент согласно NIST SP 800-61

4. Команда

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

• R (Responsible) – те, кто непосредственно выполняет шаг;

• A (Accountable) – те, кто несет ответственность за выполнение шага;

• C (Consulted) – те, кто оказывает консультации и помогает с выполнением шага;

• I (Informed) – те, кого необходимо информировать о выполнении шага.

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

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

5. Вспомогательные процессы

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

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

Минимальный перечень вспомогательных по отношению к реагированию процессов включает следующие:

• инвентаризация ИТ-активов;

• управление ИТ-инфраструктурой;

• управление средствами защиты информации;

• управление уязвимостями;

• анализ защищенности;

• управление рисками ИБ;

• проактивный поиск угроз (Threat Hunting);

• киберразведка (Threat Intelligence);

• форензика.

Совершенствование плейбуков с помощью инструментов автоматизации

Оптимизировать процесс реагирования помогают решения класса SOAR (Security Orchestration, Automation and Response), позволяющие автоматизировать различные действия в рамках обработки инцидентов.

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

• обогащение данных об инциденте из внешних систем-источников;

• уведомление рабочей группы или внешней организации об инциденте;

• постановка задач по реагированию на инцидент (внутри SOAR или с использованием тикетной системы);

• формирование отчетности об инцидентах (внутри SOAR или с использованием другой системы).

По мере накопления опыта работы в SOAR можно переходить к автоматизации более ответственных действий, таких как блокировка IP, URL, учетных записей, удаление электронных сообщений или ПО и др. Разумеется, принимать такие решения лучше совместно с подразделениями, вовлеченными в процесс реагирования.

Тут стоит заметить, что существует и так называемая «полуавтоматизация», когда специалисту остается лишь подтвердить решение, выданное системой. Блокировку IP-адреса или учетной записи топ-менеджера куда спокойнее отдать на откуп аналитику, чем системе SOAR. В то же время аналитику не придется вручную обращаться к межсетевым экранам или ITSM-системам для поиска нужных данных.

Таким образом, плейбук, который был ранее описан «на бумаге» и требовал немалых усилий для его выполнения (разные подразделения, многообразие инструментов реагирования, необходимость ведения оперативной отчетности и т.п.), переходит в SOAR. В свою очередь SOC получает инструмент, который позволяет:

• эффективно управлять средствами защиты в рамках реагирования на инциденты;

• назначать и отслеживать сроки выполнения задач;

• сократить время реакции и устранения инцидента ИБ и снизить негативные последствия для бизнеса;

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

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

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

Как проверить, улучшают ли плейбуки процесс реагирования

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

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

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

• Количество возникающих нетиповых инцидентов. Оцените, какова доля «новых» инцидентов, то есть тех, для которых не разработаны плейбуки. Если она превышает 10% от общего числа, необходимо обновить классификацию инцидентов и разработать новые плейбуки.

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

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

Заключение

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