Привет! В первой части, «Как и чем ломали российские компании», мы рассказали о тактиках и техниках злоумышленников, а также о том, как вовремя обнаружить их в инфраструктуре вашей компании. Сегодня же поделимся второй частью нашего большого исследования — как восстанавливаться после ИБ‑инцидентов. И делать это быстро.
Оговоримся сразу — в рамках этой статьи мы будем понимать «восстановление» как именно восстановление ИТ‑систем и инфраструктуры для критичных бизнес‑систем. Иными словами — чтобы после масштабной кибератаки всё просто снова заработало (безопасно) и бизнес не простаивал. Потому что полное восстановление (расследование атаки, устранение причин компрометации и создание новых ИБ‑рекомендаций) может занимать несколько месяцев.
Итак, вот наш опыт, на основе которого можно сформировать свой собственный план кризисного реагирования.
Первая реакция
Самый важный этап реагирования на ИБ‑инцидент — это первые два дня. Само собой, чем раньше вы отреагируете, тем лучше, потому что каждые лишние 5 минут, которые злоумышленники находятся в инфре компании, это растущие риски — они успеют закрепиться посерьёзнее, смогут перемещаться по горизонтали и вертикали, получат доступ к важным данным и прочее, прочее, прочее. В общем, тут как в Tower Defense — чем меньше времени вы оставите противнику, тем лучше.
И именно в эти 24–48 часов принимаются важные управленческие решения, которые и определят в итоге, как долго компания будет восстанавливаться и какой ущерб ей успеют нанести. Мы не случайно пишем «управленческие», потому что именно руководство компании решает, что делать — как взаимодействовать с хакерами (и стоит ли вообще), как согласовать стратегию восстановления, какие простои по времени считать допустимыми, что и как написать клиентам и партнёрам.
Ключевые задачи на это время:
Локализация инцидента и его сдерживание (определение истинных масштабов атаки и реализация первичных мер по недопущению такого снова).
Организация процесса расследования.
Подготовка плана восстановления (скорее всего, его ещё не было).
Самая частая ошибка тут — слишком рано запустить системы, думая, что всё починили. В организационном хаосе и спешке такое чаще всего приводит к повторному заражению инфры и куда более длительному простою бизнес‑процессов.
Давайте по порядку.
Локализуем инцидент
Приоритет на этом этапе — адекватно определить масштабы инцидента и максимально ограничить распространение атаки по инфраструктуре. Затем — сохранить нетронутые ИТ‑активы (прежде всего — средства резервного копирования, нужные для восстановления).
Вот пять главных мер, которые стоит выполнить при локализации:
Резервные копии — проверить их состояние, изолировать СРК от основной инфры.
Ограничить общение инфры с внешней сетью, прекратить любые нелегитимные соединения.
Если у компании есть удаленный доступ к инфраструктуре для сотрудников — перевести его в VPN‑режим и обязательно включить всем многофакторку.
Сбросить все пароли для учётных записей, прежде всего — привилегированным.
Актуализировать данные об инфраструктуре и критичных системах.
Важно — не выключайте и не затирайте сразу заражённые ИТ‑активы, на них могут оставаться информация и артефакты атаки, которые пригодятся для тщательного расследования инцидента.
Затем соберите кризисный штаб, состоящий из:
Руководителя подразделения ИБ, который будет отвечать за быстрое восстановление бизнес‑процессов.
Руководителя подразделения ИТ — он будет отвечать за расследование, сопровождение восстановления и за недопущение повторного инцидента.
Глав юридического и PR‑департаментов — эти люди будут формировать тональность и смысл коммуникаций с клиентами и партнерами.
По нашей статистике, атакующие иногда получали возможность в прямом эфире отслеживать ход обсуждения инцидента и принимаемые решения — из‑за компрометаций Telegram‑сессий сотрудников, задействованных в процессе. Так что советуем вести общение по инциденту через защищённые каналы связи.
Как собрать команду реагирования и кто за что будет отвечать
Чтобы команда адекватно и оперативно реагировала на инцидент, каждый должен знать, за что именно от отвечает и что он делает, так что тут очень помогает ролевая модель. Самое главное на старте — честно оценить, хватит ли компании своих сил на расследование и восстановление, или стоит привлечь внешних специалистов.
Мы рекомендуем вот такую типовую модель построения команды реагирования.
Организуем расследование
Итак, инцидент локализован, команды собраны, роли распределены. Время запускать процесс расследования.
Есть четыре главных вопроса, на которые нужно ответить:
Как именно злоумышленники получили первичный доступ?
Как системы они успели скомпрометировать?
Произошла ли утечка данных?
Как именно по инфре распространялось вредоносное ПО?
Ещё разок отметим, что до получения хотя бы первичных результатов расследования не стоит начинать восстановление инфраструктуры, иначе с большой вероятностью последует вторичное заражение.
Вот вещи, которые команде расследования предстоит определить на практике. Это — базовый минимум:
способы получения первичного доступа;
какие техники использовали для повышения привилегий;
как закреплялись в инфре и какими доступами обладают;
как распространялось вредоносное ПО;
какие есть признаки утечки данных;
обнаруженные индикаторы компрометации.
В самые первые часы важно определить именно способы распространения ВПО. Если это сделать, то можно уже запускать процесс восстановления, с тем лишь условием, что делать это следует в изолированном контуре, пока идёт расследование.
Что восстанавливать в первую очередь
Приоритеты тут определяются не только с точки зрения ИТ‑архитектуры компании, но и с точки зрения специфики бизнеса. Поэтому надо определить:
какие именно бизнес‑процессы восстанавливать в первую очередь, чтобы снизить простои и потенциальные потери бизнеса;
какие бизнес‑системы отвечают за полноценную работу этих процессов;
какие ИТ‑сервисы нужны для запуска этих систем;
какие данных необходимы для этого.
Что можно сделать не так
Расследуя множество инцидентов, мы пришли к выводу, что многие компании именно в первые часы после обнаружения кибератаки часто совершают похожие действия, которые ощутимо усложняют само расследование и делают восстановление сильно растянутым по времени. Здесь тоже есть четыре основных вида граблей, об одном из которых мы уже писали.
1. Не восстанавливайте инфраструктуру раньше времени
Серьёзно, это очень частая ошибка. Видимо, первой реакций на упавшую инфру становится желание её поднять максимально быстро. Однако без понимания вектора атаки это приводит лишь к повторному заражению. Имейте в виду — если не определить способы распространения ВПО по инфраструктуре, то она будет скомпрометирована снова, в том числе благодаря использованию заражённых бэкапов.
2. Не выключайте заражённые системы и не перезагружайте их
Тут работает такой же паттерн поведения, «Что‑то заражено — отключу‑ка я это от греха». А зря, потому что заражённые активы — это полезный набор артефактов атаки для команды расследования: следы хакеров, временные файлы и процессы и много другое. Если просто дёрнуть рубильник и всё отключить, это можно потерять.
3. Создайте единый центр управления инцидентом
Если несколько команд или подразделений будут параллельно предпринимать собственные действия — вы окажетесь в ситуации «лебедь, рак и щука». А любой хаос в инфре сильно затруднит работу и даст больше времени злоумышленникам.
4. Уделяйте достаточно внимания бэкапам
Часто компании начинают восстановление, нормально не проверив, всё ли ОК с резервными копиями и безопасны ли они (спойлер — злоумышленники тоже о таком думают). Так что, если бэкапы были заражены, а компания попыталась из них восстановиться — ну, вы поняли.
Восстанавливаем инфраструктуру
Есть два очень разных случая. Первый — когда компания восстанавливает инфру после серьёзного сбоя или аварии, когда главная задача звучит как «просто всё поднять и запустить».
Второй — попытка сделать то же самое, но в условиях кибератаки, когда вся инфраструктура по умолчанию считается скомпрометированной средой, а работать‑то всё равно надо именно в ней. С учётом того, что у хакеров тоже есть права админа, они успели внедрить вредоносы и уже управляют часть ИТ‑инфраструктуры.
И это две совсем разные ситуации.
Поэтому процесс восстановления в условиях кибератаки должен выполняться строго по плану, который формируется в первые несколько часов после обнаружения инцидента. База плана — приоритеты бизнес‑процессов, от которых напрямую зависит работа компании.
На основе нашего исследования мы выделили несколько последовательных этапов, каждый из которых содержит свои цели и задачи. Вот как выглядит таймлайн:
Самих же этапов восстановления — четыре.
1. Сбор артефактов и передача данных команде расследования
Проводится на протяжении всего расследования. Данные и артефакты стоит собирать даже в том случае, если команда ещё не попросила об этом, просто поверьте — лишними эти собранные артефакты не будут.
2. Восстановление базовой инфраструктуры
После первичного анализа нужно восстанавливать именно опорные сервисы инфры, которые необходимы для бизнес‑процессов. В идеале на этом этапе иметь DR Toolkit, такой тревожный чемоданчик на всякий пожарный, набор инструментов и ресурсов для аварийного восстановления.
3. Восстановление данных и критичных инфосистем
Главное тут — качество, доступность и безопасность бэкапов. А ещё само восстановление следует выполнять в изолированном контуре. В зависимости от объема данных и размеров бэкапов этот этап может занимать от пары часов до нескольких суток.
4. Проверка и запуск бизнес‑процессов
Финальный этап, на котором надо проверить, что всё восстановленное на самом деле работает и работает как надо. Тут полезным будет знать, из каких именно компонентов состоит каждый бизнес‑процесс компании, чтобы проверять и запускать только нужное, без второстепенных систем. Результат процесса — полное восстановление работоспособности критичных бизнес‑процессов.
Базово — это всё. Если вам интересны подробности по каждому из пунктов, держите ссылку на полное исследование и набор рекомендаций.
Там же вы найдёте:
чеклист по инфобезу для компаний;
отдельный раздел про то, как самостоятельно реализовать антихрупкость (сделать инфру готовой к атакам и способной к восстановлению);
подробный анализ типовых причин компрометации и способов противодействия им.
Спасибо, что дочитали. Если есть вопросы — смело пишите в комментариях.