Когда заходит речь о реагировании на инциденты, от организаций нередко можно услышать, что у них уже есть привычный Service Desk и ещё одна система — класса IRP (Incident Response Platforms) — им не нужна. Управлять кейсом с заменой принтера или карточкой киберинцидента — суть-то одна. Однако в объединении этих двух систем есть множество подводных камней.
Введение
Задач в рамках различных бизнес-процессов становится всё больше. И иногда секрет успеха кроется не только в грамотном управлении, но и в умелом делегировании задач, причём не только людям, но и системам. Многие компании используют решения класса ACM (Adaptive Case Management) — они позволяют формализовать и облегчить процессы, в которые вовлечено большое количество людей, а также подсказывают готовые решения на основании уже реализованных кейсов. Примером подобной системы является Service Desk. Внутри спрятан стандартный и понятный набор функций: фильтры, уведомления, инструменты коммуникации, статусы, возможности работы с шаблонами, различные интеграции и многое другое.
Когда подобная система внедрена, есть большой соблазн интегрировать в неё задачи связанные с реагированием на киберинциденты. Но можно ли заменить IRP (платформы Incident Response) такой системой, как Service Desk, или интегрировать их в одно решение? Наполнение кажется схожим, однако решаемые задачи и область применения систем в корне различаются. В этой статье попробуем разобраться, почему скрестить IRP и Service Desk не так просто, как кажется.
Что делает IRP?
Системы IRP ориентированы исключительно на работу с киберинцидентами и решают следующие задачи:
- повышение скорости и качества реагирования на инциденты;
- автоматизация и типизация процесса реагирования;
- обогащение выявляемых инцидентов дополнительной информацией;
- обеспечение полного цикла управления инцидентами;
- предоставление рабочего процесса (workflow) для ИБ-специалистов компании;
- экономия трудозатрат и снижение нагрузки на ИБ-специалистов компании.
С точки зрения кейс-менеджмента это весьма ограниченная функциональность. Однако она вполне обширна в части реагирования на киберинцидент. Что касается систем кейс-менеджмента, то они предназначены в первую очередь для решения задач коллективного взаимодействия сотрудников, выдачи поручений, контроля сроков их исполнения, работы с заявками пользователей различных направлений — например, если необходимо починить принтер в офисе, оформить закупку какого-то оборудования или организовать коллективную работу по другому кейсу, в который вовлечено много сотрудников. Однако задачи связанные с кибербезопасностью являются весьма специфическими и в них вовлечён ограниченный круг сотрудников компании. Такие задачи требуют своевременного реагирования и определённых компетенций.
Решения класса IRP ориентированы именно на оперативное реагирование и предотвращение негативных последствий инцидента. Одна из ключевых задач IRP — обогащение инцидента информацией на всех стадиях его жизненного цикла. Если не вдаваться в технические детали, то можно сказать, что все положительные срабатывания IRP забирает из SIEM, затем обогащает их информацией из подключённых источников, таких как антивирусное ПО, Active Directory, внешние TI и т. д. Эти данные собираются автоматически, что снижает нагрузку на специалистов и существенно сокращает время реагирования. Также в интерфейсе IRP-системы видно, кто ответственен за цифровые активы, имеющие прямое отношение к инциденту, а это — ещё несколько сэкономленных минут, если не часов.
Вишенкой же на торте являются типовые сценарии реагирования (плейбуки), которые предоставляют готовую последовательность действий для ликвидации последствий кибератаки. Это позволяет реагировать на инцидент чуть ли не парой щелчков мышью. Подробнее о том, как написать эффективный и работающий плейбук, мы уже рассказывали в этой статье. Но даже если готового сценария по реагированию нет, IRP всё равно поможет: решение предоставляет набор атомарных действий, поэтапное выполнение которых позволит оперативно выбрать способ реагирования.
Но не стоит думать, что IRP всё сделает за вас: и инцидент увидит, и нужной информацией его обогатит, а потом ещё и самостоятельно ликвидирует. Как мы уже писали выше, ни одно решение не является эффективным без квалифицированных кадров, которые умеют грамотно его применять. Специалист, работающий с системой, должен понимать, насколько инцидент критически значим и достаточно ли информации о нём собрано, на какие бизнес-процессы он мог повлиять или уже повлиял, кто в эти процессы вовлечён и т. д. Именно он принимает предлагаемое системой решение проблемы, после чего и начинается процесс реагирования. Но оперативность, эффективность и своевременность, которые обеспечивает IRP, значительно упрощают эту работу.
А если интегрировать IRP в Service Desk?
Вы можете сказать: «К чему все эти долгие и ненужные рассуждения — поручим всё Service Desk: все инциденты начнут туда сыпаться, заявка будет формироваться автоматически — и вот оно, счастье». На первый взгляд идея здравая и вполне логичная. Но правильнее будет сказать, что Service Desk — это один из источников информации об инцидентах и своего рода инструмент для оповещения.
Безусловно, произвести интеграцию IRP с Service Desk возможно. В ряде случаев это может быть крайне удобно, так как позволит ИБ-специалистам направлять заявки о возникновении инцидента сразу в Service Desk. ИТ-специалисты, в свою очередь, смогут в режиме реального времени видеть новые заявки, не выходя из привычной системы, и оперативно принимать меры (например, отключить заражённый компьютер от внутренней инфраструктуры).
Однако для полноценной бесшовной интеграции и настройки Service Desk под задачи, которые решаются с помощью IRP, необходима постоянная доработка и поддержка. Для начала нужно «подружить» Service Desk с инцидентами, которые будут туда прилетать, и научить её отображать их в корректном виде (чтобы в карточке инцидента были необходимые данные). Отдельно нужно написать плейбуки для объединённой системы. Эти сценарии важно адаптировать, настроить, периодически обновлять, а порой и писать новые, что требует немалых кадровых и финансовых ресурсов. Труд аналитиков, методологов и консультантов стоит немало, а ИТ-инфраструктура постоянно меняется, что делает обновление плейбуков почти постоянным процессом. То есть подобная интеграция — это непрерывная работа (или доработка, как вам больше нравится), которая, скорее всего, ляжет на плечи отдельной команды. А что будет, если в один прекрасный (или не очень) день эта команда уйдёт? Как известно, с разработчиками зачастую уходят и их секреты, продукты и всё то, что поддерживало жизнеспособность сервиса, решения или системы. Резюмируя, скажем, что подобная интеграция требует технической поддержки на протяжении всего периода работы системы, заниматься этим должны выделенные под задачу кадры.
Что же касается самого процесса реагирования, то он, разумеется, будет осуществляться в интерфейсе IRP, который именно для этого и предназначен. При завершении реагирования заявка в Service Desk будет закрываться вручную ИТ-специалистом, после чего произойдёт автоматическое завершение реагирования в IRP: нет необходимости несколько раз переключаться между системами и вручную проставлять статусы.
Выводы
Безусловно, механизм работы современной адаптивной системы кейс-менеджмента концептуально схож с тем, как устроена IRP. Однако в центре первой находится человек, который сам выбирает, как будет развиваться кейс. В IRP же в центре — инцидент, сценарий реагирования на который выбирается автоматически, а ИБ-специалист уже координирует этот процесс.
Если же безопасников «завести» в Service Desk, то получим следующее. Вариант первый — в системе будет работать множество людей: часть — по классической функциональности сервис-деска, часть — по инцидентам (но сначала компании придётся пройти путь нескончаемых доработок и интеграций). Вариант второй — сервис-деск исключительно для задач ИБ, которые фактически будут на уровне ИТ (как обычная техподдержка). Даже самая умная АСМ-система не сможет вовремя и правильно обработать киберинцидент без долгой (а местами — и мучительной) доработки и переноса плейбуков из IRP. Хочется верить, что те времена, когда в одной системе пытались объединить всё в буквальном смысле этого слова, уже позади. Как оно работало, если вообще работало, многие помнят или догадываются.
Словом, применение любой системы, сервиса или продукта должно быть уместным, корректным и соотноситься с поставленными задачами, особенно когда на кону большие финансовые потери (а мы отлично знаем, к каким последствиям приводит успешно реализованная кибератака). ИТ-систем много, и сначала может показаться, что их функциональность схожа. Но они предназначены для разных целей и могут лишь дополнять, но никак не заменять друг друга. Лучшим фильтром здесь станет именно разграничение на уровне оболочек: каждая система предназначена для решения своих задач, выполняемых квалифицированными специалистами.
