Можно мало что знать о SOC, но все равно будет интуитивно понятно, что в его работе важнее всего две вещи: выявление инцидентов и реагирование на них. При этом, если не брать ситуации, когда мы имеем дело со сложным внутренним мошенничеством или признаками деятельности профессиональной группировки, реагирование, как правило, состоит из ряда очень простых технических мер (удаление вирусного тела или ПО, блокирование доступа или учетной записи) и организационных мероприятий (уточнение информации у пользователей или проверка и обогащение итогов анализа в источниках, недоступных мониторингу). Однако в силу ряда причин в последние годы процесс реагирования на стороне заказчиков начал существенно модифицироваться, и это потребовало изменений и со стороны SOC. Причем, поскольку речь идет о реагировании, где значимо «не только лишь всё» – и точность, и полнота, и скорость действий – можно с высокой вероятностью говорить, что если ваш внутренний или внешний SOC не учитывает новые требования к этому процессу, вы не сможете нормально отработать инцидент.

Сейчас среди наших заказчиков много таких, кому удобнее получать реагирование как услугу «полного цикла» – в таком случае мы блокируем атаку на средствах защиты компании и сопровождаем процесс реагирования в зоне ответственности ИТ-службы. Например, помогаем с обоснованием блокировок, которые теоретически могут повлечь проблемы в бизнес-процессах, или консультируем по работам, которые частично необходимо провести на их стороне, – блокировке учетных записей, изоляции хоста и т.д.

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

Кто раньше был вовлечен в этот процесс и отвечал за результат со стороны заказчика? Как правило, один-два специалиста информационной безопасности, которые совмещали работу по реагированию с другими задачами отдела и не всегда обладали глубокой нишевой экспертизой в анализе атак (как видно из предыдущего абзаца, это и не требовалось). Тем не менее, речь всегда шла о специалистах информационной безопасности, понимающих риски, угрозы и контекст происходящего.

В последнее время ответственность за полноту и своевременность реагирования на стороне заказчика все чаще распределяется между ИБ- и ИТ-службами, и вот почему.

Во-первых, инцидентов и подозрений на инциденты стало существенно больше. Если раньше среднее количество оповещений измерялось одной-двумя сотнями в месяц, то сейчас оно увеличилось в несколько раз. Частично проблема состоит в росте энтропии в корпоративных инфраструктурах за счет постоянных (и не всегда фиксируемых) изменений, которые вызваны тем, что сейчас принято называть модным термином «диджитализация» или «цифровая трансформация». Побочным эффектом становится то, что действия пользователей приобретают более широкую вариативность, и технические решения чаще классифицируют их как аномалии в поведении, которые безопасник, в свою очередь, может ошибочно принять за активность злоумышленника. Это ложноположительные срабатывания, скажем так, первого типа.

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

Собственно, это и приводит к тому, что для ускорения процесса реагирования все больше компаний стараются перевести внешний SOC на прямое взаимодействие не с ИБ, а с ИТ-подразделениями. И это весьма логично: инциденты, требующие удаления ПО или блокировки учетных записей, напрямую направляются в ИТ, требующие сетевой изоляции хоста – в сетевые подразделения + helpdesk и так далее. Если же в компании есть собственный центр мониторинга, то его зачастую обязуют передавать в ИТ срабатывания из SIEM-системы.

Однако любое изменение процесса – это риск его замедления, риск неполного информирования сторон и, в конечном счете, снижения эффективности. К счастью, в большинстве компаний это понимают, поэтому (а еще иногда вследствие требований законодательства – в частности, по созданию центров ГосСОПКА) сейчас растет спрос на проверки фактического уровня реагирования – полноты, качества и сроков выполнения рекомендаций со стороны ИТ- и ИБ-подразделений компании.

Однако прежде, чем проводить проверки, надо дать людям в руки инструмент для достижения результата, иными словами – SOC должен адаптировать итоги анализа каждого инцидента для четкой маршрутизации в ИТ. Методом проб и ошибок мы собрали список требований к информации об инциденте, направляемой заказчику.

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

Какие тут есть подводные камни: чтобы правильно определить такого ответственного, надо точно идентифицировать место возникновения инцидента – конкретное отделение, критичность хоста, его бизнес-принадлежность, тип инцидента. Это требует очень глубокого погружения в инфраструктуру заказчика на этапе инвентаризации (и, что очень важно, постоянной актуализации этих данных).

Эта же информация нужна для определения критичности инцидента. Например, на вирусное заражение машины в филиале в Магадане банк готов реагировать существенно медленнее и силами местного специалиста по информационной безопасности. Если же речь идет о местном АРМ КБР, инцидент требует немедленного реагирования и вовлечения, в том числе, CISO заказчика для координации риска, а также специалистов узла связи на площадке для немедленной изоляции хоста.

Реагирование на атаку на веб-приложение в сегменте e-commerce, как правило, требует вовлечения не только безопасников, но и прикладников, которые могут точнее определить риски, связанные с ее реализацией, а выгрузка из базы данных информации о заказах на том же хосте, наоборот, ни в коем случае не должна вовлекать ни прикладников (они одни из потенциальных злоумышленников), ни даже айтишников, зато помимо ИБ зачастую требует участия службы экономической безопасности.

Все эти сценарии – кого когда вовлекаем, на каком этапе и для чего – должны быть заблаговременно проработаны и согласованы с заказчиком. SOC лучше знает про ИБ, но заказчик лучше знает свой бизнес и то, какие риски для него наиболее критичны, поэтому скрипты разрабатываются совместно.

Карточка инцидента должна быть адаптирована под специалистов с бэкграундом в ИТ и без знаний в ИБ

Это касается и описания угрозы, и ее рисков, и уровня детальности описания рекомендаций по реагированию. Причем в идеальном варианте последовательность необходимых действий должна быть разделена на дерево обязательных и вспомогательных событий. Например, если SOC зафиксировал запуск Remote Admin Tool на конечном хосте, но уровня аудита недостаточно, чтобы отличить активность пользователя от потенциального запуска backdoor злоумышленником, то первым и обязательным пунктом будет коммуникация специалиста с пользователем для выяснения, он ли инициировал эту активность. При положительном ответе это штатная активность или, как максимум, нарушение политики ИБ. При отрицательном – может быть частью хакерской атаки и требует совершенно других работ по реагированию.

Проверка результатов реагирования должна содержать возможность технического контроля как факта выполнения рекомендаций (с помощью логов в SIEM или других инструментов), так и того, что инцидент не повторится в дальнейшем

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

Наконец, большое значение имеет контекст или дельта-окрестность инцидента. Очень важно, что именно происходило с этой машиной/учетной записью на последнем интервале времени, не было ли похожих или потенциально связанных с ним инцидентов, которые могут собраться в kill chain. Эта информация позволяет быстро определиться, не требуется ли сразу вовлечь в инцидент безопасность или Incident Response Team провайдера.

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