Отработка происшествий — одна из важнейших функций SOC (Security Operations Center, центра мониторинга и оперативного реагирования на инциденты в сфере информационной безопасности). Заказчикам важно понимать, насколько их SOC учитывает новые требования к реагированию, сформировавшиеся за последнее время. Наша цель — рассмотреть, как изменился процесс на стороне заказчика, что за перемены это обусловило на стороне SOC и как собирать правильную информацию об инциденте.
- Введение
- Как распределяется ответственность за своевременное реагирование на киберинциденты
- Какой должна быть информация об инциденте
- 3.1. Чёткое указание на сотрудника, отвечающего за технические меры реагирования
- 3.2. Адаптированная для специалистов с бэкграундом в ИТ и без знаний в ИБ карточка инцидента
- 3.3. Возможность обеспечить технический контроль как факта выполнения рекомендаций, так и того, что инцидент не повторится в дальнейшем
- Выводы
Введение
Можно мало что знать о SOC, но всё равно будет интуитивно понятно, что в его работе важнее всего две вещи: выявление инцидентов и реагирование на них. При этом, если не брать ситуации, когда мы имеем дело со сложным внутренним мошенничеством или признаками деятельности профессиональной группировки, реагирование, как правило, состоит из ряда очень простых технических мер (удаление вирусного тела или ПО, блокирование доступа или учётной записи) и организационных мероприятий (уточнение информации у пользователей или проверка и обогащение итогов анализа в источниках, недоступных для мониторинга). Однако в силу ряда причин в последние годы процесс реагирования на стороне заказчиков начал существенно модифицироваться, и это потребовало изменений и со стороны SOC. Причём, поскольку речь идёт о реагировании, где значимо «не только лишь всё» — и точность, и полнота, и скорость действий, — можно с высокой вероятностью говорить, что если ваш внутренний или внешний SOC не учитывает новые требования к этому процессу, то вы не сможете нормально отработать инцидент.
Как распределяется ответственность за своевременное реагирование на киберинциденты
Сейчас среди наших заказчиков много тех, кому удобнее получать реагирование как услугу «полного цикла» — в таком случае мы блокируем атаку на средствах защиты компании и сопровождаем процесс реагирования в зоне ответственности ИТ-службы. Например, помогаем с обоснованием блокировок, которые теоретически могут повлечь за собой проблемы в бизнес-процессах, или консультируем по работам, которые частично необходимо провести на их стороне — по блокировке учётных записей, изоляции хоста и т. д.
Однако большинство всё же предпочитает заниматься техническим реагированием самостоятельно, и от нас они требуют своевременного детектирования инцидента, анализа и фильтрации ложных срабатываний, а также предоставления аналитической справки с рекомендациями по первоочередным действиям в рамках реакции на инцидент.
Кто раньше был вовлечён в этот процесс и отвечал за результат со стороны заказчика? Как правило, один-два специалиста по информационной безопасности, которые совмещали работу по реагированию с другими задачами отдела и не всегда обладали глубокой нишевой экспертизой в анализе атак (как видно из предыдущего абзаца, это и не требовалось). Тем не менее речь всегда шла именно о специалистах по защите информации, понимающих риски, угрозы и контекст происходящего.
В последнее время ответственность за полноту и своевременность реагирования на стороне заказчика всё чаще распределяется между ИБ- и ИТ-службами, и вот почему.
Во-первых, инцидентов и подозрений на них стало существенно больше. Если раньше среднее количество оповещений измерялось одной-двумя сотнями в месяц, то сейчас оно увеличилось в несколько раз. Частично проблема состоит в росте энтропии в корпоративных инфраструктурах за счёт постоянных (и не всегда фиксируемых) изменений, которые вызваны тем, что сейчас принято называть модными терминами «диджитализация» или «цифровая трансформация». Побочным эффектом становится то, что действия пользователей приобретают более широкую вариативность, и технические решения чаще классифицируют их как аномалии в поведении, которые безопасник в свою очередь может ошибочно принять за активность злоумышленника. Это — ложноположительные срабатывания, скажем так, первого типа.
Во-вторых, активность злоумышленников, конечно, тоже постоянно растёт (проще говоря, атак становится больше); это отмечаем и мы, и другие игроки отрасли, и сами заказчики. В результате SOC должен постоянно изобретать всё больше хитрых сценариев детектирования атак и в обязательном порядке подключать их заказчику. Это, разумеется, тоже приводит к росту количества срабатываний, повышению недетерминированности действий заказчика и потребности в том, чтобы информация об инциденте содержала внешний контекст (чья это рабочая станция, принято ли в компании использовать средства удалённого доступа и если да, то какие именно, кто их может применять и для чего, и тому подобное).
Собственно, это и приводит к тому, что для ускорения процесса реагирования всё больше компаний стараются перевести внешний SOC на прямое взаимодействие не с ИБ-, а с ИТ-подразделениями. И это весьма логично: инциденты, требующие удаления ПО или блокировки учётных записей, напрямую направляются в ИТ, требующие сетевой изоляции хоста — в сетевые подразделения и службу поддержки (helpdesk), и так далее. Если же в компании есть собственный центр мониторинга, то его зачастую обязывают передавать в ИТ срабатывания из SIEM-системы.
Однако любое изменение процесса — это риск его замедления, неполного информирования сторон и в конечном счёте снижения эффективности. К счастью, в большинстве компаний это понимают, поэтому (а ещё иногда вследствие требований законодательства — в частности, по созданию центров ГосСОПКА) сейчас растёт спрос на проверки фактического уровня реагирования — полноты, качества и сроков выполнения рекомендаций со стороны ИТ- и ИБ-подразделений компании.
Однако прежде чем проводить проверки, надо дать людям в руки инструмент для достижения результата; иными словами — SOC должен адаптировать итоги анализа каждого инцидента для чёткой маршрутизации в ИТ. Методом проб и ошибок мы собрали список требований к информации об инциденте, направляемой заказчику.
Какой должна быть информация об инциденте
Чёткое указание на сотрудника, отвечающего за технические меры реагирования
Какие тут есть «подводные камни»: чтобы правильно определить такого ответственного, надо точно идентифицировать место возникновения инцидента — конкретное отделение, значимость хоста, его бизнес-принадлежность, тип происшествия. Это требует очень глубокого погружения в инфраструктуру заказчика на этапе инвентаризации (и, что очень важно, постоянной актуализации этих данных).
Эта же информация нужна для определения степени опасности инцидента. Например, на вирусное заражение машины в филиале в Магадане банк готов реагировать существенно медленнее и силами местного специалиста по информационной безопасности. Если же речь идёт о местном АРМ КБР (автоматизированное рабочее место клиента Банка России. — Прим. ред.), инцидент требует немедленного реагирования и вовлечения в том числе CISO заказчика для координации риска, а также специалистов узла связи на площадке для немедленной изоляции хоста.
Реагирование на атаку против веб-приложения в сегменте электронной коммерции (e-commerce), как правило, требует вовлечения не только безопасников, но и прикладников, которые могут точнее определить риски, связанные с её реализацией, а выгрузка из базы данных информации о заказах на том же хосте, наоборот, ни в коем случае не должна вовлекать ни прикладников (они — одни из потенциальных злоумышленников), ни даже айтишников, зато помимо ИБ зачастую требует участия службы экономической безопасности.
Все эти сценарии — кого когда вовлекаем, на каком этапе и для чего — должны быть заблаговременно проработаны и согласованы с заказчиком. SOC больше знает об ИБ, но заказчик лучше знает свой бизнес и то, какие риски для него наиболее существенны, поэтому скрипты разрабатываются совместно.
Адаптированная для специалистов с бэкграундом в ИТ и без знаний в ИБ карточка инцидента
Это касается и описания угрозы, и её рисков, и уровня детальности описания рекомендаций по реагированию. Причём в идеальном варианте последовательность необходимых действий должна быть разделена на дерево обязательных и вспомогательных событий. Например, если SOC зафиксировал запуск инструмента удалённого администрирования (remote admin tool) на конечном хосте, но уровня аудита недостаточно для того, чтобы отличить активность пользователя от потенциального запуска бэкдора злоумышленником, то первым и обязательным пунктом будет коммуникация с пользователем для выяснения того, он ли инициировал эту активность. При положительном ответе это — штатная активность или, как максимум, нарушение политики ИБ. При отрицательном — может быть частью хакерской атаки и требует совершенно других работ по реагированию.
Возможность обеспечить технический контроль как факта выполнения рекомендаций, так и того, что инцидент не повторится в дальнейшем
Продолжим пример с запуском RAT на хосте. Допустим, мы пошли по первой ветке — активность пользователя, нарушившая политики ИБ. В этом случае ИТ-службе будет выдана рекомендация по удалению нежелательной программы. Помимо контролируемого запуска скрипта, выполняющего это удаление, или проверки отсутствия / наличия утилиты на хосте средствами инвентаризации должно осуществляться связывание со старым инцидентом при повторном срабатывании. Это сигнализирует не только о повторном нарушении, но и о возможном некачественном выполнении рекомендации со стороны реагирования.
Наконец, большое значение имеет контекст, или дельта-окрестность инцидента. Очень важно, что именно происходило с этой машиной / учётной записью на последнем интервале времени, не было ли похожих или потенциально связанных со случившимся инцидентов, которые могут собраться в цепочку (kill chain). Эта информация позволяет быстро определить, не требуется ли сразу вовлечь в инцидент службу безопасности или команду реагирования (Incident Response Team) провайдера.
Выводы
Каждый SOC ищет свои ответы на эти вызовы и может решать такие задачи с помощью разных инструментов; главное — контролировать, что он в принципе это делает, поскольку на мелких инцидентах задержки и запинки в реагировании могут быть незаметными, а на критических неотлаженный процесс просто не отработает, и виноватых при этом словно бы и не будет.
