Сценарии реагирования на инциденты ИБ: пять playbook’ов для небольшой команды

В разгар инцидента не время придумывать порядок действий. Сценарий (playbook) — это короткий список шагов для конкретного типа инцидента, написанный заранее: кто, что и в каком порядке делает. Ниже пять сценариев, которые покрывают большинство случаев в небольшой компании. Они опираются на общий порядок первых 24 часов и дополняют его конкретикой по типам.

Статья опирается на логику направления «Управление инцидентами» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Общие принципы, роли, сроки уведомлений и скрипт сбора данных: реагирование на инцидент: первые 24 часа. Сценарии адаптируйте под свои системы и утвердите у руководителя.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Общая структура сценария

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

Сценарий 1. Компрометация учётной записи (фишинг, подбор пароля)

Признаки: сотрудник ввёл пароль на подозрительной странице; необычные входы с чужих адресов; правила пересылки в почте; рассылки от имени сотрудника; оповещение системы защиты.

Приоритет: высокий, если учётная запись привилегированная или есть доступ к персональным данным; средний в остальных случаях.

1. Заблокируйте учётную запись и завершите все её активные сеансы и токены (почта, VPN, облачные сервисы).
2. Сбросьте пароль с чистого устройства, перерегистрируйте второй фактор.
3. Проверьте почтовый ящик: правила пересылки и перенаправления, делегированный доступ, подключённые приложения; удалите чужое.
4. Просмотрите журналы входов и действий за период до обнаружения: куда заходили, что скачивали, что отправляли.
5. Определите, получили ли нарушители доступ к данным, и каким; расширьте проверку на другие учётные записи, которыми пользовался сотрудник.
6. Если затронуты персональные данные, начните отсчёт сроков уведомления регулятора: как уведомить Роскомнадзор.
7. Закройте причину: MFA, обучение, блокировка фишингового адреса; предупредите других сотрудников: осведомлённость.

Сценарий 2. Шифровальщик

Признаки: файлы получают странные расширения, появляются требования выкупа, недоступны общие папки, срабатывания защиты на массовое изменение файлов.

Приоритет: критический.

1. Немедленно отключите затронутые узлы от сети (отключение порта, адаптера виртуальной машины), не выключая питание, чтобы сохранить следы в памяти.
2. Отключите общие хранилища и резервные хранилища от сети, чтобы шифрование не дошло до копий; проверьте, что копии недоступны для записи с рабочих станций.
3. Определите масштаб: сколько узлов и данных, кто первым, когда началось: запрос по журналам и системе защиты.
4. Сохраните данные для расследования: образ диска и памяти по возможности, записку с требованием, образцы файлов, сетевые журналы: скрипт сбора из первых 24 часов.
5. Найдите точку входа (фишинг, открытый RDP, уязвимость) и закройте её до восстановления.
6. Восстановите из проверенных копий на чистые узлы; пересоздайте затронутые системы: копирование 3-2-1.
7. Смените учётные данные, которые могли быть украдены, включая служебные и административные.
8. Решения о контактах с вымогателями и выкупе принимают руководство и юрист; технически вы готовите восстановление.
9. Если вероятна утечка данных (шифровальщики часто копируют данные до шифрования), включите сроки уведомлений.

Сценарий 3. Веб-оболочка или взлом сайта

Признаки: неизвестные файлы в каталогах сайта, редиректы, спам-страницы, нагрузка, срабатывания защиты, оповещения от поисковых систем.

Приоритет: высокий для сайтов с данными пользователей.

1. Изолируйте сервер от внутренней сети; при необходимости переведите сайт на страницу-заглушку.
2. Сохраните копию каталога сайта, журналы веб-сервера и базы данных до очистки.
3. Найдите изменённые и новые файлы: сравните с чистой версией, проверьте недавно изменённые файлы, разделы загрузок, планировщик, пользователей приложения.
4. Определите точку входа: уязвимость плагина или приложения, слабый пароль администратора, украденный ключ.
5. Пересоберите сайт из чистого образа и проверенной копии данных; не «чистите на месте».
6. Смените пароли и ключи, включая доступы к базе данных и панели управления; закройте уязвимость и включите защиту: WAF и ограничения.
7. Проверьте, не утекли ли данные пользователей, и оцените необходимость уведомлений.

Сценарий 4. Утечка данных по вине сотрудника

Признаки: письмо с данными ушло не тому адресу, файл выложен в открытый доступ, выгрузка перед увольнением, срабатывание системы контроля каналов.

Приоритет: зависит от объёма и категории данных.

1. Остановите распространение: отзовите письмо, удалите публикацию, закройте доступ к хранилищу, отзовите общую ссылку.
2. Оцените состав и объём данных, число людей и каналы: что именно утекло и кому.
3. Зафиксируйте факты: время, кто, каким способом, куда; сохраните доказательства.
4. Свяжитесь с получателем: попросите удалить данные и подтвердить, если это возможно и согласовано с юристом.
5. Если сотрудник действовал умышленно, подключите руководство, кадровую службу и юриста; ограничьте доступ.
6. Уведомления: если утекли персональные данные и это повлекло нарушение прав субъектов, соблюдайте сроки: первичное уведомление в течение 24 часов от выявления.
7. Закройте причину: права доступа, контроль каналов, обучение: DLP и контроль каналов.

Сценарий 5. Потеря или кража устройства

Признаки: сотрудник сообщает о потере ноутбука или телефона; устройство не возвращается; оповещения о входах с утерянного устройства.

Приоритет: зависит от данных на устройстве и наличия шифрования.

1. Определите, какие данные и доступы были на устройстве: почта, документы, VPN, хранилища паролей, токены.
2. Заблокируйте учётные записи и сеансы, отзовите токены и сертификаты, сбросьте пароли.
3. Выполните удалённую блокировку или очистку, если устройство управляется; проверьте, было ли зашифровано хранилище: шифрование дисков.
4. Если на устройстве были персональные данные и шифрования не было, оцените как утечку и действуйте по срокам уведомлений.
5. Заявите в полицию при краже, если это принято в вашей организации.
6. Выдайте замену, проведите разбор: правила для устройств: BYOD и мобильные устройства.

Учёт и приоритеты

Как поддерживать сценарии в рабочем виде

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

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление инцидентами» (материалы направления, карта зрелости). Уровень 2 даёт общий план с ролями и этапами, уровень 3 добавляет сценарии по типам инцидентов, расследование и разбор с планом исправлений: эта статья закрывает именно сценарии.

Как проверить

1. Для каждого из пяти типов есть утверждённый сценарий с ответственными и контактами.
2. Журнал инцидентов ведётся по перечню полей, время выявления фиксируется.
3. В течение года разыгран хотя бы один сценарий, результаты записаны в план улучшений.
4. Сценарии хранятся в доступном вне основной инфраструктуры месте.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: csrc.nist.gov. Международная практика, не российский норматив.
• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», статья 21, часть 3.1 (уведомление об утечке): КонсультантПлюс. Проверяйте действующую редакцию.