IRP (Incident Response Platform) — платформа для автоматизации процессов реагирования на киберинциденты. Является эффективным инструментом в работе безопасников, но только в случае корректной настройки. Расскажем, что умеет IRP, как наполнить её правильным контентом и что должно быть в сценариях реагирования (плейбуках).
- Введение
- Что умеет IRP?
- Как сделать IRP эффективной?
- 3.1. Этапы и стримы проекта
- 3.2. Стрим дизайна
- 3.3. Стрим технического проектирования
- 3.4. Стрим внедрения
- 3.5. Стрим обучения
- Особенности автоматизации плейбуков
- Выводы
Введение
В последние годы количество киберинцидентов только увеличивается, а сами атаки становятся сложнее. Растущая угроза заставляет государство и бизнес уделять особое внимание обеспечению собственной информационной безопасности. На этом фоне всё большее значение приобретают центры мониторинга и реагирования (SOC). Однако часто SOC приравниваются к средствам управления событиями по безопасности (то есть фактически к SIEM-системам), а фокус внимания многих специалистов по ИБ нацелен в первую очередь на этап выявления (обнаружения). И лишь немногие задумываются о том, что же делать, когда ИБ-событие квалифицировано как ИБ-инцидент. Ещё меньше организаций уже разработали и применяют планы по реагированию (плейбуки). А ведь сбор событий и регистрация инцидентов в ИБ сами по себе, без последующего анализа и реагирования, смысла не имеют. Чтобы повысить эффективность борьбы со злоумышленниками и оперативно принимать решения, необходимо перейти к автоматизации определённых задач и процедур. С этой целью были созданы платформы Incident Response (IRP).
Что умеет IRP?
IRP предоставляет массу возможностей для решения задач, которые возникают перед специалистами по защите информации.
Таблица 1. Возможности IRP
|
Задача |
Возможности IRP |
|
|---|---|---|
|
Получить единый централизованный инструмент по инвентаризации ИТ-активов (в случае когда инвентаризация не проводилась вообще либо осуществляется только ИТ-департаментом, а специалисты по ИБ не имеют доступа и инструментов контроля) |
→ |
|
|
Получить единый инструмент для регистрации инцидентов в ИБ |
→ |
|
|
Получить единый централизованный инструмент для сбора сведений в рамках реагирования на инциденты (в случае когда обогащение инцидентов в ИБ осуществляется вручную путём последовательной авторизации в каждом СЗИ) и ускорить реагирование на них |
→ |
|
|
Получить централизованный инструмент для оповещения заинтересованных лиц, в т. ч. путём автоматизированной генерации отчётов, при наступлении критически значимых событий |
→ |
|
|
Получать (периодически или постоянно) оперативный срез, текущую статистику по ИТ-активам, инцидентам, уязвимостям |
→ |
|
Как сделать IRP эффективной?
Но не всё так просто. Внедрение IRP — это полноценная проектная деятельность, в рамках которой разрабатываются:
- процессы, которые подлежат автоматизации и условно поддерживают реагирование на инциденты в ИБ по линии активов (например, от начала закупки до вывода из эксплуатации) или по линии уязвимостей (например, от выявления сканером защищённости до исправления);
- процессы реагирования по ИБ-инцидентам / рабочие процессы (workflow) / плейбуки (например, действия при обнаружении вредоносной программы, компрометации учётной записи, переполнении журнала аудита и др.);
- модели данных, а также параметры интеграции и коннекторы для используемых ИТ-систем и средств защиты информации.
К тому же в таких проектах, как правило, задействовано много специалистов из различных областей. Так, для разработки коннекторов и команд, которые должны выполняться в автоматическом режиме, необходимо учесть любые категории ИТ-активов. Это и Windows-платформы (серверы и рабочие станции), и Linux-платформы (в зависимости от операционной системы и её версии могут использоваться различные команды), и виртуальная инфраструктура, а также широкий спектр активного сетевого оборудования и СЗИ. Для каждого ИТ-актива требуется учесть политики лицензирования, так как в зависимости от приобретённой лицензии различные функции могут вызываться и выполняться по-разному.
Если говорить о методологической составляющей, то надо понимать, что процессы даже в рамках группы компаний с едиными верхнеуровневыми политиками ИТ и ИБ могут отличаться друг от друга в реализации для отдельных персоналий, а могут быть совсем не регламентированы, и все эти нюансы требуют проработки. Так или иначе, для выполнения подобных проектов необходимо сформировать определённый подход. Основываясь на нашем опыте внедрения IRP, мы в Solar JSOC выделили следующие этапы и потоки (стримы).
Этапы и стримы проекта
Внедрение IRP-системы выглядит весьма масштабно и состоит из условных шести этапов (обозначены прямоугольниками на схеме далее), или четырёх тематических проектных стримов (обозначены цветом).
Рисунок 1. Этапы и стримы проекта по внедрению IRP-системы
В зависимости от готовности ИТ-инфраструктуры и процессов в компании внедрение IRP может начинаться с различных этапов, а акценты могут быть сделаны на разных стримах. Например, где-то даже не выстроена инвентаризация ИТ-активов, а где-то уже внедрена IRP-система, определены ответственные лица на каждом этапе реагирования на типовые инциденты в ИБ и требуется только автоматизация плейбуков. Таким образом, все проекты по внедрению IRP-систем будут отличаться друг от друга как количеством этапов, так и сроками реализации, но будут соответствовать общей линии. Чтобы определить масштаб конкретного проекта, потребуется, как минимум, выяснить, каковы ожидания компании от внедрения IRP, выделить процессы, которые необходимо автоматизировать, а также проанализировать текущее состояние ИТ-инфраструктуры.
Стрим дизайна
Даже если цель внедрения IRP — автоматизация реагирования на инциденты, для начала потребуется проработать процессы связанные с ИТ-активами. Если в IRP не хранятся данные по ИТ-активам, то нет возможности оперативного обогащения инцидентов информацией и, как следствие, их корректной приоритизации и маршрутизации. Процессы, которые связаны с уязвимостями, желательны к проработке, однако необязательны, так как могут быть практически полностью автоматизированы с использованием соответствующих систем управления уязвимостями, а в IRP-систему будут поступать уже обработанные данные для регистрации или обогащения инцидента.
Дизайн рабочих процессов и плейбуков, а также метрик, панелей мониторинга (дашбордов) и отчётов является частью стрима по дизайну процессов, однако требует большей технической проработки, поэтому рассмотрим эти этапы подробнее в стриме по внедрению.
Результатом всех этапов в рамках стрима по дизайну процессов является документирование (в виде блок-схем, таблиц и т. п.) автономных или связанных между собой процессов (с указанием ответственных за каждый шаг, входными и выходными данными) на основе действующих в организации процессных нотаций и организационно-распорядительных документов, а также разработанных метрик и KPI.
Стрим технического проектирования
В рамках проектирования выполняется разработка модели данных для IRP-системы. В ней должен быть определён полный перечень ИТ-систем и СЗИ, которые будут взаимодействовать с IRP, с указанием категорий / типов информации (например, FQDN, IP-адрес, адреса электронной почты работников, рейтинг уязвимостей CVSS и др.). На основе этих данных формируется перечень сведений, которые попадут в карточки ИТ-активов (например, данные о персонале, технических средствах, сетевом оборудовании, инцидентах в ИБ и др.) с привязкой к конкретным ИТ-системам. Именно модель данных позволяет исключить захламление IRP ненужными данными.
После разработки модели данных и получения представления об объёме интеграции просчитывается допустимая нагрузка на IRP-систему, выбирается вендор системы, документируется архитектура решения, рассчитываются необходимые мощности для внедрения, а также параметры интеграции (протоколы, уровни доступов и порядок взаимодействия).
Результатом этапа проектирования является оформление документации, включающей в себя описание модели данных и настроек, которые потребуются при внедрении IRP-системы, а также параметры интеграции.
Стрим внедрения
На этапе внедрения производятся инсталляция и базовая настройка IRP, выстраивается связь со внешними ИТ-системами и СЗИ, а также настраиваются карточки ИТ-активов, инцидентов в ИБ и уязвимостей (если это предусмотрено).
На основе результатов, которые были получены на этапе дизайна, создаются рабочие процессы для IRP-системы с учётом её функциональных возможностей, интегрированных ИТ- и ИБ-систем и особенностей взаимодействия с ними. С опорой на ожидания от внедрения IRP, особенности ИТ-инфраструктуры и инциденты, выявленные в организации за последнее время, разрабатываются предложения по отслеживаемым метрикам и интерактивным дашбордам, подготавливаются шаблоны отчётов. После их согласования выполняются настройка IRP-системы и её тестирование.
Результатом этапа внедрения является успешное завершение испытаний IRP с заведёнными карточками, настроенными рабочими процессами, регистрацией пользователей, интеграцией с поставщиками и потребителями данных (внешние ИТ- и ИБ-системы), а также с комплектом рабочей и эксплуатационной документации.
Стрим обучения
Все участники процессов должны быть ознакомлены с инструкциями по использованию IRP, уметь быстро ориентироваться в интерфейсе, а также понимать свою роль в каждом разработанном ими процессе. Это особенно важно для специалистов задействованных в реагировании, так как своевременность и оперативность их действий играют в нём одну из ключевых ролей. Результатом этого этапа являются положительные итоги тестирования работников или успешно проведённые киберучения.
Особенности автоматизации плейбуков
Отдельно стоит остановиться на этом этапе, так как он вызывает множество вопросов при внедрении IRP.
В чём здесь сложность?
Сложность проектов по внедрению IRP-системы заключается не в том, чтобы развернуть продукт или нарисовать блок-схему в интерфейсе, а в создании качественного плейбука либо (при его отсутствии) в детальной проработке каждой процедуры, тестировании алгоритмов и проверке входных и выходных данных. В общем… Нельзя просто так взять и автоматизировать плейбук.
Прежде всего необходимо определить формат данных, работу с которыми надо автоматизировать. Плейбук может быть формализован в различных вариациях: тексты, таблицы, блок-схемы и даже какие-то наработки процессов в GRC или IRP.
В зависимости от организации способ подачи информации может быть любым. Однако требуется определить сущности, свойственные любому формату. В рамках описания параметров плейбука могут использоваться три их вида: субъект, объект и атрибут времени. Весьма часто можно встретить указание, что та или иная процедура выполняется «в рабочее время». Но что это значит в вашей конкретной организации? С 9:00 до 18:00 с понедельника по пятницу или с 8:00 до 20:00 семь дней в неделю? Указанные выше сущности должны быть однозначно определены.
Определиться с терминологией
Необходимо снять «очевидные вопросы». В каждой организации используется своя терминология. Даже аббревиатуру СЗИ можно понимать и как «средство защиты информации» (т. е. самостоятельное решение, например антивирус), и как «система защиты информации» (т. е. комплекс средств защиты — межсетевой экран, антивирус, сканер уязвимостей и т. д.). Что же говорить об узкоспециализированных аббревиатурах? Поэтому нужно удостовериться, что все участники проекта говорят на одном языке.
Кроме того, и субъекты (все, кто упоминается в плейбуке), и объекты (средства защиты, оборудование, документы и др.) должны иметь уникальные в рамках процесса обозначения. Если написано, что происходит информирование «работника», то именно «работник» (а не «пользователь», «оператор» или «user») должен фигурировать в плейбуке дальше. Контекст, к сожалению, далеко не всегда обеспечивает ясную картину и синонимичность понятий.
Из чего состоит плейбук?
Проанализировав процедуры, можно сформулировать повторяющиеся от плейбука к плейбуку вопросы и ошибки. Их можно избежать, если предварительно обозначить основные параметры, без которых автоматизация невозможна:
- идентификатор процедуры;
- наименование процедуры (опционально, может служить идентификатором);
- ответственный за выполнение процедуры (всегда только один!);
- привлекаемые участники (могут быть, а могут отсутствовать);
- длительность процедуры (опционально, требуется для контроля за процессом);
- входные данные;
- выходные данные;
- алгоритм действий.
Как добиться баланса информации в плейбуке?
Мы не призываем интегрироваться со всеми системами в ИТ-инфраструктуре и собирать в IRP всё, до чего можно дотянуться. «Подробное описание» значит, что в IRP-систему должны попадать только те сведения, которые требуются для решения задач, то есть необходимые и достаточные. Например, из Active Directory можно получить значения полей «Город» и «Область». Но они нужны в IRP только в том случае, если компания имеет географически распределённую ИТ-инфраструктуру и значения этих полей могут влиять на логику процессов по инвентаризации или реагированию. Иначе эта информация будет только мешать оператору IRP-системы. В то же время, если в рамках процесса нам нужны определённые сведения из конкретной ИТ-системы, эта интеграция необходима. Таким образом, при автоматизации плейбуков нужен баланс.
А что если прикинуть на глаз?
Проработка описания параметров, в том числе перечня входных и выходных данных, должна выполняться качественно. Работники группы реагирования должны иметь возможность спросить, кому отправить уведомление, или позвонить коллеге и узнать IP-адрес его рабочей станции, если он не был указан в заявке. Но IRP-система действует по заранее подготовленному алгоритму, и если его не отладить, то процессы не смогут завершаться корректно.
Такая же проблема — и с выходными данными. Фраза «Отчёт по результатам анализа событий» может быть понятной для человека, который не раз видел такой отчёт или делал его, но этого недостаточно для IRP. Отчёт в системе требует детальной настройки, а для этого нужно иметь шаблон или знать, какие данные и в каком формате должны быть в него включены.
То же самое — и с описанием алгоритма действий. Например, для поиска имени рабочей станции оператор может воспользоваться несколькими альтернативными командами (если одна из них не даст результата) и перейти к следующему шагу процесса. Но в IRP результат команды нужно привести к заранее согласованному формату (заглавными буквами или строчными, с именем домена или без), так как различный результат может требовать различной дальнейшей обработки и настройки соответствующих условий.
Для запуска плейбука в IRP-системе каждая команда должна быть проверена и отлажена. Только представьте, что может случиться, если IRP-система отправит запрос на сетевую изоляцию рабочей станции без возможности отмены. Настраивая выполнение команд, в том числе с использованием внешних ИТ-систем, необходимо заранее проанализировать дальнейшие шаги. Если возможно удалённо заблокировать сетевой доступ к рабочей станции, то как потом этот доступ вернуть? Позволят ли это сделать возможности IRP-системы? Стоит ли заранее настроить исключения по закрытию портов или предварительно задать тайм-аут, достаточный для выполнения работ? А может быть, использовать возможности интеграции с другим средством защиты информации или разработать порядок действий для получения локального / физического доступа к целевой рабочей станции? Нужно просчитывать ходы наперёд.
Выводы
IRP предоставляет массу возможностей. Но чтобы все их увидеть, потребуется не просто внедрить «из коробки» очередное СЗИ, а выполнить большую работу по подготовке ко внедрению системы и её настройке. IRP — это в первую очередь инструмент. И когда ИБ-руководитель, начальник SOC или ответственный ИБ-специалист понимает, что он хочет получить по результатам проекта, этот инструмент поможет решить многие вопросы, а заказчик проекта получит не только необходимые выгоды, но и доступный гибкий инструмент для решения перспективных ИБ-задач.
В зависимости от того, каких результатов необходимо достичь с помощью IRP, насколько масштабна ИТ-инфраструктура, какое количество средств защиты информации задействовано в реагировании на инциденты, какие процессы существуют в организации, меняется не только срок реализации проекта, но и прорабатываемая глубина автоматизации. В любом случае проекты по внедрению IRP-систем, включая автоматизацию плейбуков, являются комплексными и не дают расслабиться ни техническим специалистам, которые проводят обследование ИТ-инфраструктуры и настройку коннекторов, ни консультантам-методологам, которые выполняют дизайн необходимых процессов, учитывая возможность их технической реализации. И при выборе правильного подхода и проработке всех деталей IRP в итоге позволит повысить качество работ специалистов по защите информации и уменьшить объём задач выполняемых в ручном режиме.
Авторы:
Юлия Олексенко, архитектор внешних проектов центра противодействия кибератакам Solar JSOC компании «Ростелеком-Солар»
Александр Кузнецов, руководитель группы архитектуры Solar JSOC компании «Ростелеком-Солар»
