Когда SOC есть, а реагировать некому: чего на самом деле не хватает планам реагирования

Наличие SOC, SIEM и регламентов еще не означает, что компания готова к инциденту. В реальной атаке решает не только скорость обнаружения, но и наличие человека, который имеет право изолировать узел, отключить сегмент, выбрать резервный канал связи и взять на себя ответственность за первые действия. Если план реагирования написан для аудитора, а не для дежурной смены, мониторинг превращается в систему наблюдения за развитием атаки. О том, почему планы реагирования часто не работают в критический момент, какие полномочия нельзя отдавать подрядчику и как сделать плейбук пригодным для первой линии, рассказывает Иван Бурмистров, пресейл-инженер UDV Group.

Представьте вечер. Мониторинг подсвечивает подозрительную активность на одном из серверов, дежурный инженер видит аномалию, SIEM исправно шлет оповещения. А дальше возникает пауза. В этот момент ни у кого нет права изолировать зараженный сегмент, потому что «надо согласовать», а согласовывать не с кем: руководитель недоступен, регламент эту ситуацию не описывает. Пока команда ищет ответственного, злоумышленник спокойно движется дальше по сети.

Это типичная точка отказа. Проблема не в отсутствии технологий, а в отсутствии человека с полномочиями.

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

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

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

Дальше в плане должен быть перечень того, чем именно нужно управлять. Это ключевые узлы, без которых невозможно сохранить работу инфраструктуры или восстановить ее после атаки: коммутаторы, межсетевые экраны, доменные контроллеры, серверы резервного копирования. Рядом с каждым узлом должны быть ответственный, способ доступа и резервный вариант доступа. Сами узлы лучше заранее видеть на карте сети, а не вспоминать по памяти в три часа ночи.

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

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

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

С плейбуком для технических специалистов возникает отдельная проблема. Чем детальнее он написан, тем хуже применяется в стрессе. Человек под давлением не читает абзацы, он ищет конкретное действие.

Поэтому на этапе стабилизации работает не подробная инструкция на десятки страниц, а чек-лист на одном листе А4, не больше семи пунктов. Не «изолируйте узел с учетом топологии», а буквально: зайдите на коммутатор по нужному адресу, перейдите в конфигурацию, выберите интерфейс, выполните команду отключения. Без объяснения, что такое VLAN и STP. Только действие, которое нужно выполнить сейчас.

На этапе эрадикации многие компании совершают ошибку, которая приводит ко второму инциденту. Соблазн понятен: нашли конкретный вредоносный файл, удалили, выдохнули. Но если злоумышленник успел оставить механизм возврата, так называемый бэкдор, атака через некоторое время повторится. Поэтому чистка начинается не с удаления файла, а с поиска способов закрепления в системе. В Windows это задачи в планировщике, подозрительные службы, WMI-подписки. В Linux, включая Astra Linux, РЕД ОС и Альт СП, нужно проверять SSH-ключи, задания cron, юниты systemd, измененные скрипты автозагрузки. Удалить вредонос и не тронуть бэкдор означает просто отложить продолжение атаки.

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

Рутину можно автоматизировать. Сюда относятся обнаружение аномалий и поиск уязвимостей с помощью SIEM и NTA, первичное отсеивание ложных сигналов по белым спискам и поведенческим профилям, автоматическая блокировка по индикаторам компрометации на межсетевом экране или через SOAR. Например, если система обнаруживает известный вредоносный адрес, соединение с командным центром можно перекрыть автоматически и тем самым сократить время реакции на часы. Еще один кандидат на автоматизацию: регулярная проверка резервных копий, когда раз в месяц из бэкапа поднимается тестовая среда и команда заранее убеждается, что копия пригодна для восстановления.

Внешнему провайдеру, MSSP, разумно отдавать то, что требует круглосуточного присутствия, но не предполагает необратимых решений. Это прием и разбор потока оповещений в нерабочее время, простые действия первой линии вроде блокировки подозрительного адреса или перезапуска сервиса, периодический аудит защищенности.

Но есть три вещи, которые нельзя отдавать внешнему подрядчику полностью. Первое: решение об отключении сервисов, связанных с бизнесом. Только внутренний руководитель понимает, можно ли гасить интернет-магазин в пятницу вечером. Внешний провайдер этого контекста не видит. Второе: доступ к резервным копиям и привилегированным учетным записям. Пароли от Active Directory, резервные копии и гипервизоры должны храниться в защищенном хранилище, а доступ к ним должен получать штатный сотрудник, а не подрядчик. Третье: общение с регулятором и юридическое оформление инцидента, потому что штраф за утечку данных или нарушение на объекте КИИ платит компания, а не ее аутсорсер.

К этому же относится сбор доказательств до перезагрузки: например, снятие дампа памяти с зараженного хоста. Для таких действий нужен прямой доступ к системе, и проще заранее обучить одного внутреннего инженера, пусть даже эта задача занимает у него только часть рабочего времени.

Готовность к инциденту измеряется не объемом регламента. Она видна в первую минуту атаки: есть ли человек, который имеет право действовать, и понимает ли дежурная смена, что именно нужно сделать. Если такого человека нет, все остальное, от SIEM до MSSP, работает вхолостую.