Путь самурая SOC: создаем надежный workflow инцидента
Путь к идеальному workflow для обработки инцидентов напоминает путь самурая — это история непрерывного самосовершенствования.
Привет! Меня зовут Кирилл Рупасов, я руковожу группой инженеров SOC (Security Operations Center) в «К2 Кибербезопасность». В этом посте я поделился нашим опытом организации понятного и эффективного процесса обработки инцидентов и преодоления типичных проблем в работе с ними.
Подводные камни
Работа с инцидентами — одна из основных задач SOC. В теории она предполагает достаточно простой и понятный набор действий:
Получили уведомление о событии;
Обработали;
Отдали информацию;
PROFIT!
Однако в процессе обработки инцидента возникает множество подводных камней, о которых узнаешь только на практике.
Основа любого SOC — триада: люди, технологии и процессы. И какими бы крутыми ни были люди и технологии, Центр мониторинга кибербезопасности не может нормально функционировать без эффективно выстроенных процессов.
На разных этапах работы примерно одни и те же сложности возникают как с MSSP-партнерами, так и между внутренними ИТ- и ИБ-командами. Типичные проблемы — отсутствие между ними диалога, непонятное и/или непрозрачное распределение ролей и зон ответственности. Это в итоге может привести к плачевным последствиям, например, к потере информации об инциденте или даже неоперативной реакции на него.
Все это результат плохо выстроенных процессов. По моему опыту, многие молодые SOC используют стандартный workflow из service desk, подходящий для различных услуг, но имеющий слабые места применительно к работе с инцидентами. В нем нет ранжирования по типам задач, все «гребутся под одну гребенку». А ведь инциденты бывают разные и реагирование на них тоже должно отличаться.
У настолько простого workflow есть серьезные минусы:
Нет нормального цикла запроса информации. Так как информация у нас не появляется моментально, необходимо её запросить, дождаться и корректно обработать. Для этого должны быть расписаны и зафиксированы соответствующие этапы работы (об этом чуть ниже).
Нет ожидания «длинных работ» — тех, которые не укладываются в стандартный SLA. Ситуация, казалось бы, не очень частая, но случается и, так как нам нужно всегда корректно закрыть инцидент, важно учитывать эту особенность. Об этом тоже расскажу чуть ниже
Нет эскалации и все процессы смешаны в одной куче. При упрощенной организации процессов, когда не учитываются этапность и контроль передачи инцидента, может легко произойти его потеря. Представьте, что первая линия SOC передает инцидент второй. Вторая говорит: «Да, окей, беру инцидент». Но у аналитика уже есть другая задача, которую нужно закончить. Когда дошла очередь до нового инцидента, он уже сбился с мысли, вынужден искать информацию и восстанавливать последовательность событий. Проблема в том, что здесь отсутствует важный этап контроля — никто не удостоверился, что инцидент действительно принят в работу.
Специализированные системы, такие как IRP, SOAR и им подобные, предлагают более развитый workflow, но и он не лишен недостатков.
Цикл запроса информации присутствует, однако недостаточно развит. В нем нет четкого механизма возврата к работе. Не всегда понятно, был ли получен ответ на запрос. Не предусмотрены работы при открытии и закрытии инцидента, нет четко прописанного процесса эскалации.
А еще на практике часто возникает непонимание зон ответственности, которое еще сильнее усугубляет ситуацию. Неразвитые и непрозрачные процессы обмена информацией приводят к тому, что заказчик не понимает, чем занимается SOC, и наоборот. В работе с инцидентами это боль.
5 основ workflow инцидента
Чтобы workflow был эффективным, нужно предусмотреть:
Процессы автоматизации. Необходимо учитывать, что скрипты требуют времени для исполнения. Если запустить процесс обогащения информации, но не дать ему достаточно времени для завершения работы, может получиться так, что скрипт и аналитик будут работать параллельно. В итоге можно повредить данные: либо входные/выходные для скрипта, либо те, которые аналитик уже нашел. Они просто перезапишутся результатами работы скрипта. Кроме того, не стоит забывать, что скрипт может «упасть». Должно быть предусмотрено обязательное получение минимальной информации или процесс возврата из блокировки.
Процессы обмена информации с потребителем: корректно отправить информацию, дождаться ее поступления и передать в обработку аналитику, вернув инцидент в работу.
Процессы эскалации с возможностью контроля того, что информация была передана и принята, кем и когда это осуществлялось. А также мониторинг «зависших» задач, которые не были приняты в работу вышестоящими линиями.
Закрытие инцидента должно сопровождаться подтверждением закрытия, а также рядом работ (об этом ниже).
Каждый этап работ должен контролироваться временными показателями, входными и выходными проверками.
Взаимодействие с бизнес-заказчиком
Может сложиться впечатление, что заказчик лишь ставит задачи и наблюдает, как дальше все само собой организуется и приносит результаты. Это не совсем так — очень важно грамотно выстроить рабочий процесс и на стороне клиента.
В первую очередь заказчику нужно подготовиться к инцидентам. Это касается не только всевозможных технических средств, например, инструментов для сбора данных, систем реагирования, но и процессов. Они должны быть приспособлены к возникновению нештатной ситуации, чтобы не возникало паники, ступора и хаотичных действий.
Также необходимы отлаженные процессы взаимодействия между командами обнаружения и реагирования, и их действия должны согласовываться с внутренними процессами. Иначе можно попасть в ситуацию, когда, например, SOC требует заблокировать пользователя, а по регламенту заказчика такая блокировка возможна только после согласования с ИБ-директором, который сейчас в отпуске.
В-третьих, должны быть согласованы и определены списки ответственных лиц или контактов на местах. Это помогает в ситуациях, когда инфраструктура большая и разветвленная, особенно есть филиальная сеть, а информация проходит довольно длинный путь до появления на местах. Так, ИБ-директор может не знать деталей об удаленном филиале, а местный админ прекрасно ориентируется в своей небольшой инфраструктуре и может все быстро прояснить.
Ну и последнее — процессы SOC и группы реагирования должны согласовываться между собой. Это касается в первую очередь коммуникации, а также, например, переходов между этапами (ожидающими и активными). Это особенно важно при взаимодействии с внешними SOC.
Этапы workflow бизнес-заказчика
Говоря о процессах заказчика сложно разработать красивый и универсальный workflow, потому что архитектура инфраструктуры и оргструктура обслуживающей ее команды уникальны для каждой организации и сильно зависит от ее задач. При этом можно выделить базовые этапы работы с инцидентами, которые подойдут всем.
1. Прием и распределение инцидента
На данном этапе происходит прием события безопасности (пока ещё не инцидента). В этот момент, особенно если SOC внешний, события передаются из одной системы регистрации в другую. Таким образом, уже здесь необходим этап работы скриптов и парсеров. Кроме того, тут происходит категоризация принятого сообщения, определение, кто будет его обрабатывать в первую очередь.
2. Проверка и подтверждение
Этот этап — один из самых масштабных. На нем происходит определение происходящего и необходимость перевода в реагирование. Соответственно, кто-то должен принять информацию в работу и, возможно, выполнить первичные рекомендации. Поэтому здесь формируется группа реагирования на инцидент информационной безопасности (ГРИИБ), которая собирает запрошенную SOC первичную информацию, чтобы определить является ли инцидент false-positive (например, в связи с проведением работ). В дальнейшем данная группа может быть скорректирована. Тут важно понимать, что на данном и следующем этапах у нас могут появляться множество параллельных процессов. Это связано с тем, что сама ГРИИБ состоит из представителей различных отделов и департаментов — не только ИТ, но и PR, HR, службы внутренней безопасности, юр. отдела и т.д. У каждого из них своя специфика работы, сроки и форматы ответа на запросы информации. При этом мы должны синхронизировать эти процессы между собой, как минимум дождавшись завершения каждого из них.
Также на этом этапе происходит уточнение статуса активов, так как, например, они могут быть ошибочно помечены как тестовые, хотя на самом деле используются в продакшене. Я неоднократно встречался с подобной ситуацией, это очень сильно мешает аналитике. Только после уточнения можно выполнять рекомендации SOC.
3. Сдерживание и нейтрализация
Убедившись, что событие действительно является инцидентом, группа реагирования может начинать полноценную работу. Происходит уточнение ГРИИБ, добавляются необходимые роли, убираются лишние специалисты. Начинается сбор и сохранение артефактов — для этого необходимо заранее подготовить ресурсы: серверы и свободное место на жестких дисках.
Важно предусмотреть возможность простого выхода из инцидента, если проблема незначительна. Например, зловред на съемном носителе, обезвреженный антивирусом. В таких случаях можно не привлекать всю команду, а просто провести дополнительную проверку антивирусом и закрыть инцидент.
4. Обмен информацией и обработка ответов SOC
Предыдущие этапы довольно жестко связаны взаимодействием с SOC. Со стороны заказчика часто появляется ответственное лицо, принимающее решения о передаче информации и определяющее участников запроса. Такой контроль необходим с обеих сторон.
Нужен человек, который может ответить на вопросы: куда в дальнейшем у нас пойдет тот или иной запрос, кому можно передавать информацию, кому она будет вредна, а кому ее в принципе нельзя передавать. Иначе может возникнуть ситуация, когда условные юристы получают десятки ненужных им уведомлений о статусах сервисов и просто перестают читать почту.
Стоит регламентировать процесс отправки информации в SOC, процесс ожидания ответа и случаи уведомления без ожидания.
Кроме того, на данном этапе возможны «длинные работ» по обработке запросов. Я говорил о них в самом начале. Например, чтобы выяснить, было ли зарегистрированное событие типичным поведением или некой исключительной ситуацией, необходимо дождаться его повторения.
Все это время со стороны SOC или заказчика тикает таймер SLA, образуются просрочки, за которыми следуют санкции. Чтобы исключить эти самые санкции, инцидент закрывают или переводят в статусы, где SLA не контролируется. Такие действия имеют накопительный эффект и в конечном итоге приводят к потере события без окончания работ. В свою очередь это может приводить к потере информации, влияющей на общие показатели защиты. Именно по этой причине нам необходим отдельный контролируемый статус, в котором как раз предусмотрены эти непредвиденные «длинные работы» с открытым SLA и ручным контролем.
5. Завершение инцидента
После прохождения пиковой фазы инцидента наступают завершающие этапы. Крайне важно четко осознавать, что никаких дальнейших работ, связанных с данным инцидентом, проводиться не будет — только регулярные процессы.
Одна из задач — документирование всего произошедшего в виде полных отчетов с сохранением и последующим анализом всех собранных данных. То же самое касается, например, форензики. При необходимости параллельно к работе привлекается внутренняя или внешняя команда форензиков для исследования и выявления глубинных причин инцидента. Хотя эти процессы могут идти в рамках отдельных потоков, когда у форензиков будет отдельный workflow. Нужно выделить время на ожидание результатов. Ведь они обязательно должны быть учтены в итоговой документации.
Это важно, т.к. есть такой этап жизненного цикла инцидента, как извлечение уроков. В русскоязычной литературе он еще называется «работы по недопущению инцидента в будущем». Соответственно, если вы теряете закрывающую документацию по инциденту, то пропускаете этот самый этап.
Игнорирование данной практики чревата высокими рисками рецидива аналогичных проблем. Поэтому вне зависимости от типа произошедшего — реальный инцидент или false positive —, закрытие нужно проводить полноценно и тщательно.
Эффективный workflow для SOC
Теперь посмотрим на наш workflow глазами SOC. Верхнеуровнево он напоминает стандартный и повсеместно распространенный в разных компаниях рабочий процесс из service desk, о котором я рассказал в начале статьи.
Однако при более детальном рассмотрении выясняется, что каждый блок на этой схеме представляет собой отдельную сущность с вложенной логикой.
Получается довольно запутанная схема, но ее можно разбить на основные блоки, взаимодействующие друг с другом. Разберем каждый из них.
1. Принятие и первичная обработка события безопасности
На этом этапе событие безопасности проходит первичную обработку и обогащение данными из различных источников.
Как вы видите, здесь у нас есть этап обогащения. Он позволяет нашим скриптам спокойно отработать и вернуться с неким результатом. Он исключает вероятность того, что аналитик случайно затрет информацию собранную скриптом, и наоборот.
Осуществляется объединение связанных событий в один инцидент для исключения дублирования работы. Это исключает ситуации, когда пара аналитиков одновременно разбирает одно и то же событие.
Важным моментом является корректная идентификация ложных срабатываний. Дело в том, что на данном этапе работает первая линия. К сожалению, она не всегда качественно отрабатывает инциденты, особенно, если дело происходит ночью ближе к концу смены. У сотрудников просто «замыливается» взгляд. Бывает такое, что первая линия делает что-то из разряда «пусть будет false».
Ситуации, когда первая линия поддержки слишком поспешно отметила событие как ложное, требуют пристального внимания и направления на доработку. Соответственно, в схеме рабочего процесса предусмотрена ситуация, в которой событие уходит на дополнительную проверку к более квалифицированной второй линии SOC. Это может происходить автоматически. Некоторые инциденты с данным статусом мы разбираем на еженедельных собраниях, если они чем-то примечательны.
Кроме того, так как false positive сработки на данном этапе часто связаны с некорректной работой правил, здесь предусмотрен статус для их доработки. В его рамках мы определяем с какими событиями работаем, также привязываем событие к задачам на разработку и доработку правил.
2. Работа с инцидентом и эскалация
После подтверждения инцидента начинается работа аналитика. На данном этапе возможна эскалация инцидента с L1. В нашем случае работа линий процессно не отличается друг от друга, поэтому наш процесс эскалации выглядит достаточно просто. При этом он уже довольно эффективен. У нас есть контролируемый статус и условия переходов в него и из него. Если имеются разные процессные составляющие у линий, например, в случае использования SOAR или иных систем реагирования, которые недоступны для младших специалистов L1, стоит развивать workflow. При этом, как только у нас появляются скрипты, снова вспоминаем, что нам нужны статусы для их работы.
Если присутствует работа с контролирующими органами, в развитом workflow можно вынести ее как отдельный этап. Он может занимать некоторое время, например, из-за ожидания реакции от контролирующего органа.
3. Обмен информацией
На этом этапе важно разделять блокирующие и неблокирующие уведомления. Неблокирующие содержат оперативную информацию о текущем статусе и не препятствуют дальнейшей работе. По сути это простые уведомления. Блокирующие же означают, что для продолжения исследования требуются дополнительные данные от заказчика. Здесь появляется этап ожидания информации.
В случае долгого отсутствия ответа необходимо инициировать повторный запрос. Важно учесть это в средствах автоматизации, service desk и IRP-системах. Там не всегда предусмотрена кнопка «Перезапросить информацию». Кроме того, здесь также можно уйти на вышеупомянутые «длинные работы».
Например, незначительный инцидент требует изменения настроек межсетевого экрана. Заказчик отвечает, что выполнит это в рамках окна обслуживания в субботу вечером, а на дворе утро понедельника. Надо ждать целую неделю, в то время как SLA истекает. Конечно, здесь стоит уйти в длительное ожидание. Нужно выставить какие-то контрольные точки, о которых вы договорились совместно с заказчиком, чтобы просто не потерять инцидент.
В развитие этого workflow можно добавить этап выбора канала уведомления. Например, заказчик может попросить отправлять сообщения в мессенджер. Но здесь потребуется контроль доставки и прочтения сообщений. Если заказчик их не читает — мы должны выбрать другой способ уведомления.
Плюс, хорошо было бы добавить этап эскалации. К сожалению, у нас исполнители со стороны заказчика не всегда могут выполнить работы по разным причинам. Например, просто из-за загрузки. Тогда мы отправляем уведомление руководству конечного исполнителя со стороны заказчика. Но этим занимается уже скорее сервис-менеджер, а не простой аналитик.
4. Закрытие инцидента
При закрытии инцидента на стороне SOC, необходимо опираться на то, что заказчик действительно готов все закрыть и не ждет никакой дополнительной информации от аналитиков.
На этом этапе создается итоговый отчет с документированием всех деталей инцидента. Процесс может занимать несколько дней непрерывной работы. Соответственно, у нас есть отдельный этап — написание отчета.
Параллельно могут проводиться работы связанные с форензикой и вспомогательные работы по нейтрализации последствий силами техподдержки уже без участия аналитиков. Все эти этапы у нас прописаны с точки зрения процессов и выделены в отдельный этап workflow.
Если дальше развивать процессы, то можно ввести этапы дополнительных работ. Например, добавить этап киберразведки (TI) для сбора, обработки и внесения обнаруженных индикаторов компрометации в нашу платформу, например, MISP. Здесь же можно добавить этап написания отчета с точки зрения TI.
Ключевые аспекты успешной работы с инцидентами
Итак, в нашем workflow:
Все работы разделены. Если какие-то работы выполняют разные люди, это разные этапы workflow.
Выделены этапы под автоматизацию, потому что ей необходимо время на работу.
Предусмотрены проверки статусов закрытых инцидентов. Это касается как false positive, так и статуса закрытых инцидентов в конце работ.
Предусмотрены SLA и контрольные метрики на каждом этапе.
Важность корректной передачи информации
Стоит обратить внимание, как взаимодействуют между собой участники обработки инцидента. Вся информация должна быть корректной, краткой и максимально точной. На изучение «воды» тратится лишнее время, к тому же она рождает неопределенность. В приоритете точная и полезная справочная информация, например, коды сообщений и т.п.
Недопустимы расплывчатые формулировки вроде «наверно, ложное срабатывание», «возможно, не критично» и т.п. Подобная коммуникация нивелирует важность проблемы и затрудняет получение оперативного и содержательного ответа.
Важное для провайдеров услуг
Не стоит недооценивать сложность workflow — там таится множество подводных камней, которые сначала не видны и требуют практического опыта. Недостатки workflow приводят к потере контроля над инцидентами.
Что важно учитывать при работе SOC:
Пренебрежение процессами — путь к потере инцидентов.
Акцент на передаче информации, как внутри команды, так и с бизнес-заказчиком.
Контроль длительных процессов во избежание потери инцидентов из виду.
Готовность к возможным задержкам и сбоям в работе систем автоматизации.
Важное для внешних и внутренних бизнес-заказчиков
Основа — это готовность к инциденту со стороны процессов и техники заказчика. Наличие SOC само по себе не гарантирует безупречную работу систем. Если запрашивается информация, следует ответить, даже если ситуация представляется очевидной. Это способствует эффективному диалогу и высокому качеству услуг.
Что важно учесть при подключении SOC:
Заблаговременную подготовку к возможным инцидентам.
Не игнорировать запросы от SOC. То, что очевидно заказчику, может быть неочевидно для SOC.
Обеспечить контроль продолжительных процессов.
Правильное закрытие инцидента не менее важно, чем его обработка.
В зависимости от зрелости SOC, в нем задействованы от 20 до 30 различных процессов, но именно качественная обработка инцидентов необходима с самого начала работы. Следуйте рекомендациям в этой статье и сможете грамотно реагировать на угрозы.
